kernel/linux
0
Fork 0
mirror of https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ synced 2026-09-26 18:16:26 +00:00
Code Issues Releases Packages Activity
linux/drivers/mtd/maps/physmap.c

322 lines
7.6 KiB
Raw Normal View History

Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[MTD] Make functions static, include header files with prototypes This patch contains the following possible cleanups: - every file should #include the headers containing the prototypes for it's global functions - make needlessly global functions static Signed-off-by: Adrian Bunk <bunk@stusta.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-11-29 14:49:38 +00:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[MTD] Convert physmap to platform driver After dwmw2 let me know it ought to be done, I rewrote the physmap map driver to be a platform driver. I know zilch about the driver model, so I probably botched it in some way, but I've done some tests on an ixp23xx board which uses physmap, and it all seems to work. In order to not break existing physmap users, I've added some compat code that will instantiate a platform device iff CONFIG_MTD_PHYSMAP_LEN is defined and != 0. Also, I've changed the default value for CONFIG_MTD_PHYSMAP_LEN to zero, so that people who inadvertently compile in physmap (or new, platform-style, users of physmap) don't get burned. This works pretty well -- the new physmap driver is a drop-in replacement for the old one, and works on said ixp23xx board without any code changes needed. (This should hold as long as users don't touch 'physmap_map' directly.) Once all physmap users have been converted to instantiate their own platform devices, the compat code can go. (Or we decide that we can change all the in-tree users at the same time, and never merge the compat code.) Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-05-07 17:16:36 +01:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[MTD] Make functions static, include header files with prototypes This patch contains the following possible cleanups: - every file should #include the headers containing the prototypes for it's global functions - make needlessly global functions static Signed-off-by: Adrian Bunk <bunk@stusta.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-11-29 14:49:38 +00:00
[MTD] physmap.c: Add support for multiple resources This patch extends the physmap mapping driver to support multiple resources for non-identical NOR chips that will be concatenated together when selected. This is needed for example for Intel 48F4400 512MBit chips, since they consist of 2 single different NOR chips with different geometries. The first (lower) one has botton boot sectors and the 2nd (upper) has top boot sectors. This currently isn't handled correctly by calling the physmap driver once with only one resource covering both chips in one memory region. The same geometrie is used for both chips. With this patch the following resource structure can be used to describe the 48F4400 chip correctly: static struct resource board_nor_resource[] = { [0] = { .start = 0xf8000000, .end = 0xfbffffff, .flags = IORESOURCE_MEM, }, [1] = { .start = 0xfc000000, .end = 0xffffffff, .flags = IORESOURCE_MEM, } }; Signed-off-by: Stefan Roese <sr@denx.de> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2008-02-01 15:26:54 +01:00
[MTD] Convert physmap to platform driver After dwmw2 let me know it ought to be done, I rewrote the physmap map driver to be a platform driver. I know zilch about the driver model, so I probably botched it in some way, but I've done some tests on an ixp23xx board which uses physmap, and it all seems to work. In order to not break existing physmap users, I've added some compat code that will instantiate a platform device iff CONFIG_MTD_PHYSMAP_LEN is defined and != 0. Also, I've changed the default value for CONFIG_MTD_PHYSMAP_LEN to zero, so that people who inadvertently compile in physmap (or new, platform-style, users of physmap) don't get burned. This works pretty well -- the new physmap driver is a drop-in replacement for the old one, and works on said ixp23xx board without any code changes needed. (This should hold as long as users don't touch 'physmap_map' directly.) Once all physmap users have been converted to instantiate their own platform devices, the compat code can go. (Or we decide that we can change all the in-tree users at the same time, and never merge the compat code.) Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-05-07 17:16:36 +01:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[MTD] physmap.c: Add support for multiple resources This patch extends the physmap mapping driver to support multiple resources for non-identical NOR chips that will be concatenated together when selected. This is needed for example for Intel 48F4400 512MBit chips, since they consist of 2 single different NOR chips with different geometries. The first (lower) one has botton boot sectors and the 2nd (upper) has top boot sectors. This currently isn't handled correctly by calling the physmap driver once with only one resource covering both chips in one memory region. The same geometrie is used for both chips. With this patch the following resource structure can be used to describe the 48F4400 chip correctly: static struct resource board_nor_resource[] = { [0] = { .start = 0xf8000000, .end = 0xfbffffff, .flags = IORESOURCE_MEM, }, [1] = { .start = 0xfc000000, .end = 0xffffffff, .flags = IORESOURCE_MEM, } }; Signed-off-by: Stefan Roese <sr@denx.de> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2008-02-01 15:26:54 +01:00
[MTD] Convert physmap to platform driver After dwmw2 let me know it ought to be done, I rewrote the physmap map driver to be a platform driver. I know zilch about the driver model, so I probably botched it in some way, but I've done some tests on an ixp23xx board which uses physmap, and it all seems to work. In order to not break existing physmap users, I've added some compat code that will instantiate a platform device iff CONFIG_MTD_PHYSMAP_LEN is defined and != 0. Also, I've changed the default value for CONFIG_MTD_PHYSMAP_LEN to zero, so that people who inadvertently compile in physmap (or new, platform-style, users of physmap) don't get burned. This works pretty well -- the new physmap driver is a drop-in replacement for the old one, and works on said ixp23xx board without any code changes needed. (This should hold as long as users don't touch 'physmap_map' directly.) Once all physmap users have been converted to instantiate their own platform devices, the compat code can go. (Or we decide that we can change all the in-tree users at the same time, and never merge the compat code.) Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-05-07 17:16:36 +01:00
[MTD] physmap.c: Add support for multiple resources This patch extends the physmap mapping driver to support multiple resources for non-identical NOR chips that will be concatenated together when selected. This is needed for example for Intel 48F4400 512MBit chips, since they consist of 2 single different NOR chips with different geometries. The first (lower) one has botton boot sectors and the 2nd (upper) has top boot sectors. This currently isn't handled correctly by calling the physmap driver once with only one resource covering both chips in one memory region. The same geometrie is used for both chips. With this patch the following resource structure can be used to describe the 48F4400 chip correctly: static struct resource board_nor_resource[] = { [0] = { .start = 0xf8000000, .end = 0xfbffffff, .flags = IORESOURCE_MEM, }, [1] = { .start = 0xfc000000, .end = 0xffffffff, .flags = IORESOURCE_MEM, } }; Signed-off-by: Stefan Roese <sr@denx.de> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2008-02-01 15:26:54 +01:00
[MTD] Convert physmap to platform driver After dwmw2 let me know it ought to be done, I rewrote the physmap map driver to be a platform driver. I know zilch about the driver model, so I probably botched it in some way, but I've done some tests on an ixp23xx board which uses physmap, and it all seems to work. In order to not break existing physmap users, I've added some compat code that will instantiate a platform device iff CONFIG_MTD_PHYSMAP_LEN is defined and != 0. Also, I've changed the default value for CONFIG_MTD_PHYSMAP_LEN to zero, so that people who inadvertently compile in physmap (or new, platform-style, users of physmap) don't get burned. This works pretty well -- the new physmap driver is a drop-in replacement for the old one, and works on said ixp23xx board without any code changes needed. (This should hold as long as users don't touch 'physmap_map' directly.) Once all physmap users have been converted to instantiate their own platform devices, the compat code can go. (Or we decide that we can change all the in-tree users at the same time, and never merge the compat code.) Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-05-07 17:16:36 +01:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[MTD] Convert physmap to platform driver After dwmw2 let me know it ought to be done, I rewrote the physmap map driver to be a platform driver. I know zilch about the driver model, so I probably botched it in some way, but I've done some tests on an ixp23xx board which uses physmap, and it all seems to work. In order to not break existing physmap users, I've added some compat code that will instantiate a platform device iff CONFIG_MTD_PHYSMAP_LEN is defined and != 0. Also, I've changed the default value for CONFIG_MTD_PHYSMAP_LEN to zero, so that people who inadvertently compile in physmap (or new, platform-style, users of physmap) don't get burned. This works pretty well -- the new physmap driver is a drop-in replacement for the old one, and works on said ixp23xx board without any code changes needed. (This should hold as long as users don't touch 'physmap_map' directly.) Once all physmap users have been converted to instantiate their own platform devices, the compat code can go. (Or we decide that we can change all the in-tree users at the same time, and never merge the compat code.) Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-05-07 17:16:36 +01:00
[MTD] physmap.c: Add support for multiple resources This patch extends the physmap mapping driver to support multiple resources for non-identical NOR chips that will be concatenated together when selected. This is needed for example for Intel 48F4400 512MBit chips, since they consist of 2 single different NOR chips with different geometries. The first (lower) one has botton boot sectors and the 2nd (upper) has top boot sectors. This currently isn't handled correctly by calling the physmap driver once with only one resource covering both chips in one memory region. The same geometrie is used for both chips. With this patch the following resource structure can be used to describe the 48F4400 chip correctly: static struct resource board_nor_resource[] = { [0] = { .start = 0xf8000000, .end = 0xfbffffff, .flags = IORESOURCE_MEM, }, [1] = { .start = 0xfc000000, .end = 0xffffffff, .flags = IORESOURCE_MEM, } }; Signed-off-by: Stefan Roese <sr@denx.de> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2008-02-01 15:26:54 +01:00
[MTD] Convert physmap to platform driver After dwmw2 let me know it ought to be done, I rewrote the physmap map driver to be a platform driver. I know zilch about the driver model, so I probably botched it in some way, but I've done some tests on an ixp23xx board which uses physmap, and it all seems to work. In order to not break existing physmap users, I've added some compat code that will instantiate a platform device iff CONFIG_MTD_PHYSMAP_LEN is defined and != 0. Also, I've changed the default value for CONFIG_MTD_PHYSMAP_LEN to zero, so that people who inadvertently compile in physmap (or new, platform-style, users of physmap) don't get burned. This works pretty well -- the new physmap driver is a drop-in replacement for the old one, and works on said ixp23xx board without any code changes needed. (This should hold as long as users don't touch 'physmap_map' directly.) Once all physmap users have been converted to instantiate their own platform devices, the compat code can go. (Or we decide that we can change all the in-tree users at the same time, and never merge the compat code.) Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-05-07 17:16:36 +01:00
[MTD] physmap.c: Add support for multiple resources This patch extends the physmap mapping driver to support multiple resources for non-identical NOR chips that will be concatenated together when selected. This is needed for example for Intel 48F4400 512MBit chips, since they consist of 2 single different NOR chips with different geometries. The first (lower) one has botton boot sectors and the 2nd (upper) has top boot sectors. This currently isn't handled correctly by calling the physmap driver once with only one resource covering both chips in one memory region. The same geometrie is used for both chips. With this patch the following resource structure can be used to describe the 48F4400 chip correctly: static struct resource board_nor_resource[] = { [0] = { .start = 0xf8000000, .end = 0xfbffffff, .flags = IORESOURCE_MEM, }, [1] = { .start = 0xfc000000, .end = 0xffffffff, .flags = IORESOURCE_MEM, } }; Signed-off-by: Stefan Roese <sr@denx.de> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2008-02-01 15:26:54 +01:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[MTD] physmap.c: Add support for multiple resources This patch extends the physmap mapping driver to support multiple resources for non-identical NOR chips that will be concatenated together when selected. This is needed for example for Intel 48F4400 512MBit chips, since they consist of 2 single different NOR chips with different geometries. The first (lower) one has botton boot sectors and the 2nd (upper) has top boot sectors. This currently isn't handled correctly by calling the physmap driver once with only one resource covering both chips in one memory region. The same geometrie is used for both chips. With this patch the following resource structure can be used to describe the 48F4400 chip correctly: static struct resource board_nor_resource[] = { [0] = { .start = 0xf8000000, .end = 0xfbffffff, .flags = IORESOURCE_MEM, }, [1] = { .start = 0xfc000000, .end = 0xffffffff, .flags = IORESOURCE_MEM, } }; Signed-off-by: Stefan Roese <sr@denx.de> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2008-02-01 15:26:54 +01:00
[MTD] Convert physmap to platform driver After dwmw2 let me know it ought to be done, I rewrote the physmap map driver to be a platform driver. I know zilch about the driver model, so I probably botched it in some way, but I've done some tests on an ixp23xx board which uses physmap, and it all seems to work. In order to not break existing physmap users, I've added some compat code that will instantiate a platform device iff CONFIG_MTD_PHYSMAP_LEN is defined and != 0. Also, I've changed the default value for CONFIG_MTD_PHYSMAP_LEN to zero, so that people who inadvertently compile in physmap (or new, platform-style, users of physmap) don't get burned. This works pretty well -- the new physmap driver is a drop-in replacement for the old one, and works on said ixp23xx board without any code changes needed. (This should hold as long as users don't touch 'physmap_map' directly.) Once all physmap users have been converted to instantiate their own platform devices, the compat code can go. (Or we decide that we can change all the in-tree users at the same time, and never merge the compat code.) Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-05-07 17:16:36 +01:00
[MTD] physmap.c: Add support for multiple resources This patch extends the physmap mapping driver to support multiple resources for non-identical NOR chips that will be concatenated together when selected. This is needed for example for Intel 48F4400 512MBit chips, since they consist of 2 single different NOR chips with different geometries. The first (lower) one has botton boot sectors and the 2nd (upper) has top boot sectors. This currently isn't handled correctly by calling the physmap driver once with only one resource covering both chips in one memory region. The same geometrie is used for both chips. With this patch the following resource structure can be used to describe the 48F4400 chip correctly: static struct resource board_nor_resource[] = { [0] = { .start = 0xf8000000, .end = 0xfbffffff, .flags = IORESOURCE_MEM, }, [1] = { .start = 0xfc000000, .end = 0xffffffff, .flags = IORESOURCE_MEM, } }; Signed-off-by: Stefan Roese <sr@denx.de> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2008-02-01 15:26:54 +01:00
[MTD] Convert physmap to platform driver After dwmw2 let me know it ought to be done, I rewrote the physmap map driver to be a platform driver. I know zilch about the driver model, so I probably botched it in some way, but I've done some tests on an ixp23xx board which uses physmap, and it all seems to work. In order to not break existing physmap users, I've added some compat code that will instantiate a platform device iff CONFIG_MTD_PHYSMAP_LEN is defined and != 0. Also, I've changed the default value for CONFIG_MTD_PHYSMAP_LEN to zero, so that people who inadvertently compile in physmap (or new, platform-style, users of physmap) don't get burned. This works pretty well -- the new physmap driver is a drop-in replacement for the old one, and works on said ixp23xx board without any code changes needed. (This should hold as long as users don't touch 'physmap_map' directly.) Once all physmap users have been converted to instantiate their own platform devices, the compat code can go. (Or we decide that we can change all the in-tree users at the same time, and never merge the compat code.) Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-05-07 17:16:36 +01:00
[MTD] physmap.c: Add support for multiple resources This patch extends the physmap mapping driver to support multiple resources for non-identical NOR chips that will be concatenated together when selected. This is needed for example for Intel 48F4400 512MBit chips, since they consist of 2 single different NOR chips with different geometries. The first (lower) one has botton boot sectors and the 2nd (upper) has top boot sectors. This currently isn't handled correctly by calling the physmap driver once with only one resource covering both chips in one memory region. The same geometrie is used for both chips. With this patch the following resource structure can be used to describe the 48F4400 chip correctly: static struct resource board_nor_resource[] = { [0] = { .start = 0xf8000000, .end = 0xfbffffff, .flags = IORESOURCE_MEM, }, [1] = { .start = 0xfc000000, .end = 0xffffffff, .flags = IORESOURCE_MEM, } }; Signed-off-by: Stefan Roese <sr@denx.de> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2008-02-01 15:26:54 +01:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[MTD] physmap.c: Add support for multiple resources This patch extends the physmap mapping driver to support multiple resources for non-identical NOR chips that will be concatenated together when selected. This is needed for example for Intel 48F4400 512MBit chips, since they consist of 2 single different NOR chips with different geometries. The first (lower) one has botton boot sectors and the 2nd (upper) has top boot sectors. This currently isn't handled correctly by calling the physmap driver once with only one resource covering both chips in one memory region. The same geometrie is used for both chips. With this patch the following resource structure can be used to describe the 48F4400 chip correctly: static struct resource board_nor_resource[] = { [0] = { .start = 0xf8000000, .end = 0xfbffffff, .flags = IORESOURCE_MEM, }, [1] = { .start = 0xfc000000, .end = 0xffffffff, .flags = IORESOURCE_MEM, } }; Signed-off-by: Stefan Roese <sr@denx.de> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2008-02-01 15:26:54 +01:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[MTD] Convert physmap to platform driver After dwmw2 let me know it ought to be done, I rewrote the physmap map driver to be a platform driver. I know zilch about the driver model, so I probably botched it in some way, but I've done some tests on an ixp23xx board which uses physmap, and it all seems to work. In order to not break existing physmap users, I've added some compat code that will instantiate a platform device iff CONFIG_MTD_PHYSMAP_LEN is defined and != 0. Also, I've changed the default value for CONFIG_MTD_PHYSMAP_LEN to zero, so that people who inadvertently compile in physmap (or new, platform-style, users of physmap) don't get burned. This works pretty well -- the new physmap driver is a drop-in replacement for the old one, and works on said ixp23xx board without any code changes needed. (This should hold as long as users don't touch 'physmap_map' directly.) Once all physmap users have been converted to instantiate their own platform devices, the compat code can go. (Or we decide that we can change all the in-tree users at the same time, and never merge the compat code.) Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-05-07 17:16:36 +01:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[MTD] Convert physmap to platform driver After dwmw2 let me know it ought to be done, I rewrote the physmap map driver to be a platform driver. I know zilch about the driver model, so I probably botched it in some way, but I've done some tests on an ixp23xx board which uses physmap, and it all seems to work. In order to not break existing physmap users, I've added some compat code that will instantiate a platform device iff CONFIG_MTD_PHYSMAP_LEN is defined and != 0. Also, I've changed the default value for CONFIG_MTD_PHYSMAP_LEN to zero, so that people who inadvertently compile in physmap (or new, platform-style, users of physmap) don't get burned. This works pretty well -- the new physmap driver is a drop-in replacement for the old one, and works on said ixp23xx board without any code changes needed. (This should hold as long as users don't touch 'physmap_map' directly.) Once all physmap users have been converted to instantiate their own platform devices, the compat code can go. (Or we decide that we can change all the in-tree users at the same time, and never merge the compat code.) Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-05-07 17:16:36 +01:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[MTD] Convert physmap to platform driver After dwmw2 let me know it ought to be done, I rewrote the physmap map driver to be a platform driver. I know zilch about the driver model, so I probably botched it in some way, but I've done some tests on an ixp23xx board which uses physmap, and it all seems to work. In order to not break existing physmap users, I've added some compat code that will instantiate a platform device iff CONFIG_MTD_PHYSMAP_LEN is defined and != 0. Also, I've changed the default value for CONFIG_MTD_PHYSMAP_LEN to zero, so that people who inadvertently compile in physmap (or new, platform-style, users of physmap) don't get burned. This works pretty well -- the new physmap driver is a drop-in replacement for the old one, and works on said ixp23xx board without any code changes needed. (This should hold as long as users don't touch 'physmap_map' directly.) Once all physmap users have been converted to instantiate their own platform devices, the compat code can go. (Or we decide that we can change all the in-tree users at the same time, and never merge the compat code.) Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-05-07 17:16:36 +01:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[MTD] Convert physmap to platform driver After dwmw2 let me know it ought to be done, I rewrote the physmap map driver to be a platform driver. I know zilch about the driver model, so I probably botched it in some way, but I've done some tests on an ixp23xx board which uses physmap, and it all seems to work. In order to not break existing physmap users, I've added some compat code that will instantiate a platform device iff CONFIG_MTD_PHYSMAP_LEN is defined and != 0. Also, I've changed the default value for CONFIG_MTD_PHYSMAP_LEN to zero, so that people who inadvertently compile in physmap (or new, platform-style, users of physmap) don't get burned. This works pretty well -- the new physmap driver is a drop-in replacement for the old one, and works on said ixp23xx board without any code changes needed. (This should hold as long as users don't touch 'physmap_map' directly.) Once all physmap users have been converted to instantiate their own platform devices, the compat code can go. (Or we decide that we can change all the in-tree users at the same time, and never merge the compat code.) Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-05-07 17:16:36 +01:00
[MTD] physmap.c: Add support for multiple resources This patch extends the physmap mapping driver to support multiple resources for non-identical NOR chips that will be concatenated together when selected. This is needed for example for Intel 48F4400 512MBit chips, since they consist of 2 single different NOR chips with different geometries. The first (lower) one has botton boot sectors and the 2nd (upper) has top boot sectors. This currently isn't handled correctly by calling the physmap driver once with only one resource covering both chips in one memory region. The same geometrie is used for both chips. With this patch the following resource structure can be used to describe the 48F4400 chip correctly: static struct resource board_nor_resource[] = { [0] = { .start = 0xf8000000, .end = 0xfbffffff, .flags = IORESOURCE_MEM, }, [1] = { .start = 0xfc000000, .end = 0xffffffff, .flags = IORESOURCE_MEM, } }; Signed-off-by: Stefan Roese <sr@denx.de> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2008-02-01 15:26:54 +01:00
[MTD] Convert physmap to platform driver After dwmw2 let me know it ought to be done, I rewrote the physmap map driver to be a platform driver. I know zilch about the driver model, so I probably botched it in some way, but I've done some tests on an ixp23xx board which uses physmap, and it all seems to work. In order to not break existing physmap users, I've added some compat code that will instantiate a platform device iff CONFIG_MTD_PHYSMAP_LEN is defined and != 0. Also, I've changed the default value for CONFIG_MTD_PHYSMAP_LEN to zero, so that people who inadvertently compile in physmap (or new, platform-style, users of physmap) don't get burned. This works pretty well -- the new physmap driver is a drop-in replacement for the old one, and works on said ixp23xx board without any code changes needed. (This should hold as long as users don't touch 'physmap_map' directly.) Once all physmap users have been converted to instantiate their own platform devices, the compat code can go. (Or we decide that we can change all the in-tree users at the same time, and never merge the compat code.) Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-05-07 17:16:36 +01:00
[MTD] replace kmalloc+memset with kzalloc Signed-off-by: Yan Burman <yan_952@hotmail.com> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-11-15 21:10:29 +02:00
[MTD] Convert physmap to platform driver After dwmw2 let me know it ought to be done, I rewrote the physmap map driver to be a platform driver. I know zilch about the driver model, so I probably botched it in some way, but I've done some tests on an ixp23xx board which uses physmap, and it all seems to work. In order to not break existing physmap users, I've added some compat code that will instantiate a platform device iff CONFIG_MTD_PHYSMAP_LEN is defined and != 0. Also, I've changed the default value for CONFIG_MTD_PHYSMAP_LEN to zero, so that people who inadvertently compile in physmap (or new, platform-style, users of physmap) don't get burned. This works pretty well -- the new physmap driver is a drop-in replacement for the old one, and works on said ixp23xx board without any code changes needed. (This should hold as long as users don't touch 'physmap_map' directly.) Once all physmap users have been converted to instantiate their own platform devices, the compat code can go. (Or we decide that we can change all the in-tree users at the same time, and never merge the compat code.) Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-05-07 17:16:36 +01:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[MTD] Convert physmap to platform driver After dwmw2 let me know it ought to be done, I rewrote the physmap map driver to be a platform driver. I know zilch about the driver model, so I probably botched it in some way, but I've done some tests on an ixp23xx board which uses physmap, and it all seems to work. In order to not break existing physmap users, I've added some compat code that will instantiate a platform device iff CONFIG_MTD_PHYSMAP_LEN is defined and != 0. Also, I've changed the default value for CONFIG_MTD_PHYSMAP_LEN to zero, so that people who inadvertently compile in physmap (or new, platform-style, users of physmap) don't get burned. This works pretty well -- the new physmap driver is a drop-in replacement for the old one, and works on said ixp23xx board without any code changes needed. (This should hold as long as users don't touch 'physmap_map' directly.) Once all physmap users have been converted to instantiate their own platform devices, the compat code can go. (Or we decide that we can change all the in-tree users at the same time, and never merge the compat code.) Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-05-07 17:16:36 +01:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[MTD] physmap.c: Add support for multiple resources This patch extends the physmap mapping driver to support multiple resources for non-identical NOR chips that will be concatenated together when selected. This is needed for example for Intel 48F4400 512MBit chips, since they consist of 2 single different NOR chips with different geometries. The first (lower) one has botton boot sectors and the 2nd (upper) has top boot sectors. This currently isn't handled correctly by calling the physmap driver once with only one resource covering both chips in one memory region. The same geometrie is used for both chips. With this patch the following resource structure can be used to describe the 48F4400 chip correctly: static struct resource board_nor_resource[] = { [0] = { .start = 0xf8000000, .end = 0xfbffffff, .flags = IORESOURCE_MEM, }, [1] = { .start = 0xfc000000, .end = 0xffffffff, .flags = IORESOURCE_MEM, } }; Signed-off-by: Stefan Roese <sr@denx.de> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2008-02-01 15:26:54 +01:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[MTD] physmap.c: Add support for multiple resources This patch extends the physmap mapping driver to support multiple resources for non-identical NOR chips that will be concatenated together when selected. This is needed for example for Intel 48F4400 512MBit chips, since they consist of 2 single different NOR chips with different geometries. The first (lower) one has botton boot sectors and the 2nd (upper) has top boot sectors. This currently isn't handled correctly by calling the physmap driver once with only one resource covering both chips in one memory region. The same geometrie is used for both chips. With this patch the following resource structure can be used to describe the 48F4400 chip correctly: static struct resource board_nor_resource[] = { [0] = { .start = 0xf8000000, .end = 0xfbffffff, .flags = IORESOURCE_MEM, }, [1] = { .start = 0xfc000000, .end = 0xffffffff, .flags = IORESOURCE_MEM, } }; Signed-off-by: Stefan Roese <sr@denx.de> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2008-02-01 15:26:54 +01:00
[MTD] Convert physmap to platform driver After dwmw2 let me know it ought to be done, I rewrote the physmap map driver to be a platform driver. I know zilch about the driver model, so I probably botched it in some way, but I've done some tests on an ixp23xx board which uses physmap, and it all seems to work. In order to not break existing physmap users, I've added some compat code that will instantiate a platform device iff CONFIG_MTD_PHYSMAP_LEN is defined and != 0. Also, I've changed the default value for CONFIG_MTD_PHYSMAP_LEN to zero, so that people who inadvertently compile in physmap (or new, platform-style, users of physmap) don't get burned. This works pretty well -- the new physmap driver is a drop-in replacement for the old one, and works on said ixp23xx board without any code changes needed. (This should hold as long as users don't touch 'physmap_map' directly.) Once all physmap users have been converted to instantiate their own platform devices, the compat code can go. (Or we decide that we can change all the in-tree users at the same time, and never merge the compat code.) Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-05-07 17:16:36 +01:00
[MTD] physmap.c: Add support for multiple resources This patch extends the physmap mapping driver to support multiple resources for non-identical NOR chips that will be concatenated together when selected. This is needed for example for Intel 48F4400 512MBit chips, since they consist of 2 single different NOR chips with different geometries. The first (lower) one has botton boot sectors and the 2nd (upper) has top boot sectors. This currently isn't handled correctly by calling the physmap driver once with only one resource covering both chips in one memory region. The same geometrie is used for both chips. With this patch the following resource structure can be used to describe the 48F4400 chip correctly: static struct resource board_nor_resource[] = { [0] = { .start = 0xf8000000, .end = 0xfbffffff, .flags = IORESOURCE_MEM, }, [1] = { .start = 0xfc000000, .end = 0xffffffff, .flags = IORESOURCE_MEM, } }; Signed-off-by: Stefan Roese <sr@denx.de> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2008-02-01 15:26:54 +01:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[MTD] physmap.c: Add support for multiple resources This patch extends the physmap mapping driver to support multiple resources for non-identical NOR chips that will be concatenated together when selected. This is needed for example for Intel 48F4400 512MBit chips, since they consist of 2 single different NOR chips with different geometries. The first (lower) one has botton boot sectors and the 2nd (upper) has top boot sectors. This currently isn't handled correctly by calling the physmap driver once with only one resource covering both chips in one memory region. The same geometrie is used for both chips. With this patch the following resource structure can be used to describe the 48F4400 chip correctly: static struct resource board_nor_resource[] = { [0] = { .start = 0xf8000000, .end = 0xfbffffff, .flags = IORESOURCE_MEM, }, [1] = { .start = 0xfc000000, .end = 0xffffffff, .flags = IORESOURCE_MEM, } }; Signed-off-by: Stefan Roese <sr@denx.de> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2008-02-01 15:26:54 +01:00
[MTD] Convert physmap to platform driver After dwmw2 let me know it ought to be done, I rewrote the physmap map driver to be a platform driver. I know zilch about the driver model, so I probably botched it in some way, but I've done some tests on an ixp23xx board which uses physmap, and it all seems to work. In order to not break existing physmap users, I've added some compat code that will instantiate a platform device iff CONFIG_MTD_PHYSMAP_LEN is defined and != 0. Also, I've changed the default value for CONFIG_MTD_PHYSMAP_LEN to zero, so that people who inadvertently compile in physmap (or new, platform-style, users of physmap) don't get burned. This works pretty well -- the new physmap driver is a drop-in replacement for the old one, and works on said ixp23xx board without any code changes needed. (This should hold as long as users don't touch 'physmap_map' directly.) Once all physmap users have been converted to instantiate their own platform devices, the compat code can go. (Or we decide that we can change all the in-tree users at the same time, and never merge the compat code.) Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-05-07 17:16:36 +01:00
[MTD] physmap.c: Add support for multiple resources This patch extends the physmap mapping driver to support multiple resources for non-identical NOR chips that will be concatenated together when selected. This is needed for example for Intel 48F4400 512MBit chips, since they consist of 2 single different NOR chips with different geometries. The first (lower) one has botton boot sectors and the 2nd (upper) has top boot sectors. This currently isn't handled correctly by calling the physmap driver once with only one resource covering both chips in one memory region. The same geometrie is used for both chips. With this patch the following resource structure can be used to describe the 48F4400 chip correctly: static struct resource board_nor_resource[] = { [0] = { .start = 0xf8000000, .end = 0xfbffffff, .flags = IORESOURCE_MEM, }, [1] = { .start = 0xfc000000, .end = 0xffffffff, .flags = IORESOURCE_MEM, } }; Signed-off-by: Stefan Roese <sr@denx.de> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2008-02-01 15:26:54 +01:00
[MTD] Convert physmap to platform driver After dwmw2 let me know it ought to be done, I rewrote the physmap map driver to be a platform driver. I know zilch about the driver model, so I probably botched it in some way, but I've done some tests on an ixp23xx board which uses physmap, and it all seems to work. In order to not break existing physmap users, I've added some compat code that will instantiate a platform device iff CONFIG_MTD_PHYSMAP_LEN is defined and != 0. Also, I've changed the default value for CONFIG_MTD_PHYSMAP_LEN to zero, so that people who inadvertently compile in physmap (or new, platform-style, users of physmap) don't get burned. This works pretty well -- the new physmap driver is a drop-in replacement for the old one, and works on said ixp23xx board without any code changes needed. (This should hold as long as users don't touch 'physmap_map' directly.) Once all physmap users have been converted to instantiate their own platform devices, the compat code can go. (Or we decide that we can change all the in-tree users at the same time, and never merge the compat code.) Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-05-07 17:16:36 +01:00
[MTD] physmap.c: Add support for multiple resources This patch extends the physmap mapping driver to support multiple resources for non-identical NOR chips that will be concatenated together when selected. This is needed for example for Intel 48F4400 512MBit chips, since they consist of 2 single different NOR chips with different geometries. The first (lower) one has botton boot sectors and the 2nd (upper) has top boot sectors. This currently isn't handled correctly by calling the physmap driver once with only one resource covering both chips in one memory region. The same geometrie is used for both chips. With this patch the following resource structure can be used to describe the 48F4400 chip correctly: static struct resource board_nor_resource[] = { [0] = { .start = 0xf8000000, .end = 0xfbffffff, .flags = IORESOURCE_MEM, }, [1] = { .start = 0xfc000000, .end = 0xffffffff, .flags = IORESOURCE_MEM, } }; Signed-off-by: Stefan Roese <sr@denx.de> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2008-02-01 15:26:54 +01:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[MTD] physmap.c: Add support for multiple resources This patch extends the physmap mapping driver to support multiple resources for non-identical NOR chips that will be concatenated together when selected. This is needed for example for Intel 48F4400 512MBit chips, since they consist of 2 single different NOR chips with different geometries. The first (lower) one has botton boot sectors and the 2nd (upper) has top boot sectors. This currently isn't handled correctly by calling the physmap driver once with only one resource covering both chips in one memory region. The same geometrie is used for both chips. With this patch the following resource structure can be used to describe the 48F4400 chip correctly: static struct resource board_nor_resource[] = { [0] = { .start = 0xf8000000, .end = 0xfbffffff, .flags = IORESOURCE_MEM, }, [1] = { .start = 0xfc000000, .end = 0xffffffff, .flags = IORESOURCE_MEM, } }; Signed-off-by: Stefan Roese <sr@denx.de> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2008-02-01 15:26:54 +01:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[MTD] physmap.c: Add support for multiple resources This patch extends the physmap mapping driver to support multiple resources for non-identical NOR chips that will be concatenated together when selected. This is needed for example for Intel 48F4400 512MBit chips, since they consist of 2 single different NOR chips with different geometries. The first (lower) one has botton boot sectors and the 2nd (upper) has top boot sectors. This currently isn't handled correctly by calling the physmap driver once with only one resource covering both chips in one memory region. The same geometrie is used for both chips. With this patch the following resource structure can be used to describe the 48F4400 chip correctly: static struct resource board_nor_resource[] = { [0] = { .start = 0xf8000000, .end = 0xfbffffff, .flags = IORESOURCE_MEM, }, [1] = { .start = 0xfc000000, .end = 0xffffffff, .flags = IORESOURCE_MEM, } }; Signed-off-by: Stefan Roese <sr@denx.de> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2008-02-01 15:26:54 +01:00
[MTD] Convert physmap to platform driver After dwmw2 let me know it ought to be done, I rewrote the physmap map driver to be a platform driver. I know zilch about the driver model, so I probably botched it in some way, but I've done some tests on an ixp23xx board which uses physmap, and it all seems to work. In order to not break existing physmap users, I've added some compat code that will instantiate a platform device iff CONFIG_MTD_PHYSMAP_LEN is defined and != 0. Also, I've changed the default value for CONFIG_MTD_PHYSMAP_LEN to zero, so that people who inadvertently compile in physmap (or new, platform-style, users of physmap) don't get burned. This works pretty well -- the new physmap driver is a drop-in replacement for the old one, and works on said ixp23xx board without any code changes needed. (This should hold as long as users don't touch 'physmap_map' directly.) Once all physmap users have been converted to instantiate their own platform devices, the compat code can go. (Or we decide that we can change all the in-tree users at the same time, and never merge the compat code.) Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-05-07 17:16:36 +01:00
[MTD] physmap.c: Add support for multiple resources This patch extends the physmap mapping driver to support multiple resources for non-identical NOR chips that will be concatenated together when selected. This is needed for example for Intel 48F4400 512MBit chips, since they consist of 2 single different NOR chips with different geometries. The first (lower) one has botton boot sectors and the 2nd (upper) has top boot sectors. This currently isn't handled correctly by calling the physmap driver once with only one resource covering both chips in one memory region. The same geometrie is used for both chips. With this patch the following resource structure can be used to describe the 48F4400 chip correctly: static struct resource board_nor_resource[] = { [0] = { .start = 0xf8000000, .end = 0xfbffffff, .flags = IORESOURCE_MEM, }, [1] = { .start = 0xfc000000, .end = 0xffffffff, .flags = IORESOURCE_MEM, } }; Signed-off-by: Stefan Roese <sr@denx.de> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2008-02-01 15:26:54 +01:00
[MTD] Convert physmap to platform driver After dwmw2 let me know it ought to be done, I rewrote the physmap map driver to be a platform driver. I know zilch about the driver model, so I probably botched it in some way, but I've done some tests on an ixp23xx board which uses physmap, and it all seems to work. In order to not break existing physmap users, I've added some compat code that will instantiate a platform device iff CONFIG_MTD_PHYSMAP_LEN is defined and != 0. Also, I've changed the default value for CONFIG_MTD_PHYSMAP_LEN to zero, so that people who inadvertently compile in physmap (or new, platform-style, users of physmap) don't get burned. This works pretty well -- the new physmap driver is a drop-in replacement for the old one, and works on said ixp23xx board without any code changes needed. (This should hold as long as users don't touch 'physmap_map' directly.) Once all physmap users have been converted to instantiate their own platform devices, the compat code can go. (Or we decide that we can change all the in-tree users at the same time, and never merge the compat code.) Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-05-07 17:16:36 +01:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[MTD] Convert physmap to platform driver After dwmw2 let me know it ought to be done, I rewrote the physmap map driver to be a platform driver. I know zilch about the driver model, so I probably botched it in some way, but I've done some tests on an ixp23xx board which uses physmap, and it all seems to work. In order to not break existing physmap users, I've added some compat code that will instantiate a platform device iff CONFIG_MTD_PHYSMAP_LEN is defined and != 0. Also, I've changed the default value for CONFIG_MTD_PHYSMAP_LEN to zero, so that people who inadvertently compile in physmap (or new, platform-style, users of physmap) don't get burned. This works pretty well -- the new physmap driver is a drop-in replacement for the old one, and works on said ixp23xx board without any code changes needed. (This should hold as long as users don't touch 'physmap_map' directly.) Once all physmap users have been converted to instantiate their own platform devices, the compat code can go. (Or we decide that we can change all the in-tree users at the same time, and never merge the compat code.) Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-05-07 17:16:36 +01:00
[MTD] physmap.c: Add support for multiple resources This patch extends the physmap mapping driver to support multiple resources for non-identical NOR chips that will be concatenated together when selected. This is needed for example for Intel 48F4400 512MBit chips, since they consist of 2 single different NOR chips with different geometries. The first (lower) one has botton boot sectors and the 2nd (upper) has top boot sectors. This currently isn't handled correctly by calling the physmap driver once with only one resource covering both chips in one memory region. The same geometrie is used for both chips. With this patch the following resource structure can be used to describe the 48F4400 chip correctly: static struct resource board_nor_resource[] = { [0] = { .start = 0xf8000000, .end = 0xfbffffff, .flags = IORESOURCE_MEM, }, [1] = { .start = 0xfc000000, .end = 0xffffffff, .flags = IORESOURCE_MEM, } }; Signed-off-by: Stefan Roese <sr@denx.de> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2008-02-01 15:26:54 +01:00
[MTD] Convert physmap to platform driver After dwmw2 let me know it ought to be done, I rewrote the physmap map driver to be a platform driver. I know zilch about the driver model, so I probably botched it in some way, but I've done some tests on an ixp23xx board which uses physmap, and it all seems to work. In order to not break existing physmap users, I've added some compat code that will instantiate a platform device iff CONFIG_MTD_PHYSMAP_LEN is defined and != 0. Also, I've changed the default value for CONFIG_MTD_PHYSMAP_LEN to zero, so that people who inadvertently compile in physmap (or new, platform-style, users of physmap) don't get burned. This works pretty well -- the new physmap driver is a drop-in replacement for the old one, and works on said ixp23xx board without any code changes needed. (This should hold as long as users don't touch 'physmap_map' directly.) Once all physmap users have been converted to instantiate their own platform devices, the compat code can go. (Or we decide that we can change all the in-tree users at the same time, and never merge the compat code.) Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-05-07 17:16:36 +01:00
[MTD] physmap.c: Add support for multiple resources This patch extends the physmap mapping driver to support multiple resources for non-identical NOR chips that will be concatenated together when selected. This is needed for example for Intel 48F4400 512MBit chips, since they consist of 2 single different NOR chips with different geometries. The first (lower) one has botton boot sectors and the 2nd (upper) has top boot sectors. This currently isn't handled correctly by calling the physmap driver once with only one resource covering both chips in one memory region. The same geometrie is used for both chips. With this patch the following resource structure can be used to describe the 48F4400 chip correctly: static struct resource board_nor_resource[] = { [0] = { .start = 0xf8000000, .end = 0xfbffffff, .flags = IORESOURCE_MEM, }, [1] = { .start = 0xfc000000, .end = 0xffffffff, .flags = IORESOURCE_MEM, } }; Signed-off-by: Stefan Roese <sr@denx.de> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2008-02-01 15:26:54 +01:00
[MTD] Convert physmap to platform driver After dwmw2 let me know it ought to be done, I rewrote the physmap map driver to be a platform driver. I know zilch about the driver model, so I probably botched it in some way, but I've done some tests on an ixp23xx board which uses physmap, and it all seems to work. In order to not break existing physmap users, I've added some compat code that will instantiate a platform device iff CONFIG_MTD_PHYSMAP_LEN is defined and != 0. Also, I've changed the default value for CONFIG_MTD_PHYSMAP_LEN to zero, so that people who inadvertently compile in physmap (or new, platform-style, users of physmap) don't get burned. This works pretty well -- the new physmap driver is a drop-in replacement for the old one, and works on said ixp23xx board without any code changes needed. (This should hold as long as users don't touch 'physmap_map' directly.) Once all physmap users have been converted to instantiate their own platform devices, the compat code can go. (Or we decide that we can change all the in-tree users at the same time, and never merge the compat code.) Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-05-07 17:16:36 +01:00
[MTD] physmap: add power management support Implement PM handling for physmap. Idea from Steven Scholz, patch by David Anders. Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-09-21 23:16:48 +02:00
[MTD] physmap.c: Add support for multiple resources This patch extends the physmap mapping driver to support multiple resources for non-identical NOR chips that will be concatenated together when selected. This is needed for example for Intel 48F4400 512MBit chips, since they consist of 2 single different NOR chips with different geometries. The first (lower) one has botton boot sectors and the 2nd (upper) has top boot sectors. This currently isn't handled correctly by calling the physmap driver once with only one resource covering both chips in one memory region. The same geometrie is used for both chips. With this patch the following resource structure can be used to describe the 48F4400 chip correctly: static struct resource board_nor_resource[] = { [0] = { .start = 0xf8000000, .end = 0xfbffffff, .flags = IORESOURCE_MEM, }, [1] = { .start = 0xfc000000, .end = 0xffffffff, .flags = IORESOURCE_MEM, } }; Signed-off-by: Stefan Roese <sr@denx.de> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2008-02-01 15:26:54 +01:00
[MTD] physmap: add power management support Implement PM handling for physmap. Idea from Steven Scholz, patch by David Anders. Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-09-21 23:16:48 +02:00
[MTD] physmap.c: Add support for multiple resources This patch extends the physmap mapping driver to support multiple resources for non-identical NOR chips that will be concatenated together when selected. This is needed for example for Intel 48F4400 512MBit chips, since they consist of 2 single different NOR chips with different geometries. The first (lower) one has botton boot sectors and the 2nd (upper) has top boot sectors. This currently isn't handled correctly by calling the physmap driver once with only one resource covering both chips in one memory region. The same geometrie is used for both chips. With this patch the following resource structure can be used to describe the 48F4400 chip correctly: static struct resource board_nor_resource[] = { [0] = { .start = 0xf8000000, .end = 0xfbffffff, .flags = IORESOURCE_MEM, }, [1] = { .start = 0xfc000000, .end = 0xffffffff, .flags = IORESOURCE_MEM, } }; Signed-off-by: Stefan Roese <sr@denx.de> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2008-02-01 15:26:54 +01:00
[MTD] Fix maps/physmap.c compilation with CONFIG_PM Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2008-02-03 12:56:03 -08:00
[MTD] physmap: add power management support Implement PM handling for physmap. Idea from Steven Scholz, patch by David Anders. Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-09-21 23:16:48 +02:00
[MTD] physmap.c: Add support for multiple resources This patch extends the physmap mapping driver to support multiple resources for non-identical NOR chips that will be concatenated together when selected. This is needed for example for Intel 48F4400 512MBit chips, since they consist of 2 single different NOR chips with different geometries. The first (lower) one has botton boot sectors and the 2nd (upper) has top boot sectors. This currently isn't handled correctly by calling the physmap driver once with only one resource covering both chips in one memory region. The same geometrie is used for both chips. With this patch the following resource structure can be used to describe the 48F4400 chip correctly: static struct resource board_nor_resource[] = { [0] = { .start = 0xf8000000, .end = 0xfbffffff, .flags = IORESOURCE_MEM, }, [1] = { .start = 0xfc000000, .end = 0xffffffff, .flags = IORESOURCE_MEM, } }; Signed-off-by: Stefan Roese <sr@denx.de> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2008-02-01 15:26:54 +01:00
[MTD] physmap: add power management support Implement PM handling for physmap. Idea from Steven Scholz, patch by David Anders. Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-09-21 23:16:48 +02:00
[MTD] physmap.c: Add support for multiple resources This patch extends the physmap mapping driver to support multiple resources for non-identical NOR chips that will be concatenated together when selected. This is needed for example for Intel 48F4400 512MBit chips, since they consist of 2 single different NOR chips with different geometries. The first (lower) one has botton boot sectors and the 2nd (upper) has top boot sectors. This currently isn't handled correctly by calling the physmap driver once with only one resource covering both chips in one memory region. The same geometrie is used for both chips. With this patch the following resource structure can be used to describe the 48F4400 chip correctly: static struct resource board_nor_resource[] = { [0] = { .start = 0xf8000000, .end = 0xfbffffff, .flags = IORESOURCE_MEM, }, [1] = { .start = 0xfc000000, .end = 0xffffffff, .flags = IORESOURCE_MEM, } }; Signed-off-by: Stefan Roese <sr@denx.de> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2008-02-01 15:26:54 +01:00
[MTD] Fix maps/physmap.c compilation with CONFIG_PM Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2008-02-03 12:56:03 -08:00
[MTD] physmap: add power management support Implement PM handling for physmap. Idea from Steven Scholz, patch by David Anders. Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-09-21 23:16:48 +02:00
[MTD] physmap.c: Add support for multiple resources This patch extends the physmap mapping driver to support multiple resources for non-identical NOR chips that will be concatenated together when selected. This is needed for example for Intel 48F4400 512MBit chips, since they consist of 2 single different NOR chips with different geometries. The first (lower) one has botton boot sectors and the 2nd (upper) has top boot sectors. This currently isn't handled correctly by calling the physmap driver once with only one resource covering both chips in one memory region. The same geometrie is used for both chips. With this patch the following resource structure can be used to describe the 48F4400 chip correctly: static struct resource board_nor_resource[] = { [0] = { .start = 0xf8000000, .end = 0xfbffffff, .flags = IORESOURCE_MEM, }, [1] = { .start = 0xfc000000, .end = 0xffffffff, .flags = IORESOURCE_MEM, } }; Signed-off-by: Stefan Roese <sr@denx.de> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2008-02-01 15:26:54 +01:00
[MTD] Fix maps/physmap.c compilation with CONFIG_PM Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2008-02-03 12:56:03 -08:00
[MTD] physmap: add power management support Implement PM handling for physmap. Idea from Steven Scholz, patch by David Anders. Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-09-21 23:16:48 +02:00
[MTD] Fix maps/physmap.c compilation with CONFIG_PM Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2008-02-03 12:56:03 -08:00
[MTD] physmap: add power management support Implement PM handling for physmap. Idea from Steven Scholz, patch by David Anders. Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-09-21 23:16:48 +02:00
[MTD] Convert physmap to platform driver After dwmw2 let me know it ought to be done, I rewrote the physmap map driver to be a platform driver. I know zilch about the driver model, so I probably botched it in some way, but I've done some tests on an ixp23xx board which uses physmap, and it all seems to work. In order to not break existing physmap users, I've added some compat code that will instantiate a platform device iff CONFIG_MTD_PHYSMAP_LEN is defined and != 0. Also, I've changed the default value for CONFIG_MTD_PHYSMAP_LEN to zero, so that people who inadvertently compile in physmap (or new, platform-style, users of physmap) don't get burned. This works pretty well -- the new physmap driver is a drop-in replacement for the old one, and works on said ixp23xx board without any code changes needed. (This should hold as long as users don't touch 'physmap_map' directly.) Once all physmap users have been converted to instantiate their own platform devices, the compat code can go. (Or we decide that we can change all the in-tree users at the same time, and never merge the compat code.) Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-05-07 17:16:36 +01:00
[MTD] physmap: add power management support Implement PM handling for physmap. Idea from Steven Scholz, patch by David Anders. Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-09-21 23:16:48 +02:00
[MTD] Convert physmap to platform driver After dwmw2 let me know it ought to be done, I rewrote the physmap map driver to be a platform driver. I know zilch about the driver model, so I probably botched it in some way, but I've done some tests on an ixp23xx board which uses physmap, and it all seems to work. In order to not break existing physmap users, I've added some compat code that will instantiate a platform device iff CONFIG_MTD_PHYSMAP_LEN is defined and != 0. Also, I've changed the default value for CONFIG_MTD_PHYSMAP_LEN to zero, so that people who inadvertently compile in physmap (or new, platform-style, users of physmap) don't get burned. This works pretty well -- the new physmap driver is a drop-in replacement for the old one, and works on said ixp23xx board without any code changes needed. (This should hold as long as users don't touch 'physmap_map' directly.) Once all physmap users have been converted to instantiate their own platform devices, the compat code can go. (Or we decide that we can change all the in-tree users at the same time, and never merge the compat code.) Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-05-07 17:16:36 +01:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[MTD] Convert physmap to platform driver After dwmw2 let me know it ought to be done, I rewrote the physmap map driver to be a platform driver. I know zilch about the driver model, so I probably botched it in some way, but I've done some tests on an ixp23xx board which uses physmap, and it all seems to work. In order to not break existing physmap users, I've added some compat code that will instantiate a platform device iff CONFIG_MTD_PHYSMAP_LEN is defined and != 0. Also, I've changed the default value for CONFIG_MTD_PHYSMAP_LEN to zero, so that people who inadvertently compile in physmap (or new, platform-style, users of physmap) don't get burned. This works pretty well -- the new physmap driver is a drop-in replacement for the old one, and works on said ixp23xx board without any code changes needed. (This should hold as long as users don't touch 'physmap_map' directly.) Once all physmap users have been converted to instantiate their own platform devices, the compat code can go. (Or we decide that we can change all the in-tree users at the same time, and never merge the compat code.) Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-05-07 17:16:36 +01:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[MTD] Convert physmap to platform driver After dwmw2 let me know it ought to be done, I rewrote the physmap map driver to be a platform driver. I know zilch about the driver model, so I probably botched it in some way, but I've done some tests on an ixp23xx board which uses physmap, and it all seems to work. In order to not break existing physmap users, I've added some compat code that will instantiate a platform device iff CONFIG_MTD_PHYSMAP_LEN is defined and != 0. Also, I've changed the default value for CONFIG_MTD_PHYSMAP_LEN to zero, so that people who inadvertently compile in physmap (or new, platform-style, users of physmap) don't get burned. This works pretty well -- the new physmap driver is a drop-in replacement for the old one, and works on said ixp23xx board without any code changes needed. (This should hold as long as users don't touch 'physmap_map' directly.) Once all physmap users have been converted to instantiate their own platform devices, the compat code can go. (Or we decide that we can change all the in-tree users at the same time, and never merge the compat code.) Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-05-07 17:16:36 +01:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[MTD] Convert physmap to platform driver After dwmw2 let me know it ought to be done, I rewrote the physmap map driver to be a platform driver. I know zilch about the driver model, so I probably botched it in some way, but I've done some tests on an ixp23xx board which uses physmap, and it all seems to work. In order to not break existing physmap users, I've added some compat code that will instantiate a platform device iff CONFIG_MTD_PHYSMAP_LEN is defined and != 0. Also, I've changed the default value for CONFIG_MTD_PHYSMAP_LEN to zero, so that people who inadvertently compile in physmap (or new, platform-style, users of physmap) don't get burned. This works pretty well -- the new physmap driver is a drop-in replacement for the old one, and works on said ixp23xx board without any code changes needed. (This should hold as long as users don't touch 'physmap_map' directly.) Once all physmap users have been converted to instantiate their own platform devices, the compat code can go. (Or we decide that we can change all the in-tree users at the same time, and never merge the compat code.) Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-05-07 17:16:36 +01:00
[MTD] Fix off-by-one error in physmap.c This patch fixes a simple off-by-one error in the mtd physmap driver. Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-06-27 14:38:15 +01:00
[MTD] Convert physmap to platform driver After dwmw2 let me know it ought to be done, I rewrote the physmap map driver to be a platform driver. I know zilch about the driver model, so I probably botched it in some way, but I've done some tests on an ixp23xx board which uses physmap, and it all seems to work. In order to not break existing physmap users, I've added some compat code that will instantiate a platform device iff CONFIG_MTD_PHYSMAP_LEN is defined and != 0. Also, I've changed the default value for CONFIG_MTD_PHYSMAP_LEN to zero, so that people who inadvertently compile in physmap (or new, platform-style, users of physmap) don't get burned. This works pretty well -- the new physmap driver is a drop-in replacement for the old one, and works on said ixp23xx board without any code changes needed. (This should hold as long as users don't touch 'physmap_map' directly.) Once all physmap users have been converted to instantiate their own platform devices, the compat code can go. (Or we decide that we can change all the in-tree users at the same time, and never merge the compat code.) Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-05-07 17:16:36 +01:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[MTD] Convert physmap to platform driver After dwmw2 let me know it ought to be done, I rewrote the physmap map driver to be a platform driver. I know zilch about the driver model, so I probably botched it in some way, but I've done some tests on an ixp23xx board which uses physmap, and it all seems to work. In order to not break existing physmap users, I've added some compat code that will instantiate a platform device iff CONFIG_MTD_PHYSMAP_LEN is defined and != 0. Also, I've changed the default value for CONFIG_MTD_PHYSMAP_LEN to zero, so that people who inadvertently compile in physmap (or new, platform-style, users of physmap) don't get burned. This works pretty well -- the new physmap driver is a drop-in replacement for the old one, and works on said ixp23xx board without any code changes needed. (This should hold as long as users don't touch 'physmap_map' directly.) Once all physmap users have been converted to instantiate their own platform devices, the compat code can go. (Or we decide that we can change all the in-tree users at the same time, and never merge the compat code.) Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-05-07 17:16:36 +01:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[MTD] Convert physmap to platform driver After dwmw2 let me know it ought to be done, I rewrote the physmap map driver to be a platform driver. I know zilch about the driver model, so I probably botched it in some way, but I've done some tests on an ixp23xx board which uses physmap, and it all seems to work. In order to not break existing physmap users, I've added some compat code that will instantiate a platform device iff CONFIG_MTD_PHYSMAP_LEN is defined and != 0. Also, I've changed the default value for CONFIG_MTD_PHYSMAP_LEN to zero, so that people who inadvertently compile in physmap (or new, platform-style, users of physmap) don't get burned. This works pretty well -- the new physmap driver is a drop-in replacement for the old one, and works on said ixp23xx board without any code changes needed. (This should hold as long as users don't touch 'physmap_map' directly.) Once all physmap users have been converted to instantiate their own platform devices, the compat code can go. (Or we decide that we can change all the in-tree users at the same time, and never merge the compat code.) Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-05-07 17:16:36 +01:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[MTD] Convert physmap to platform driver After dwmw2 let me know it ought to be done, I rewrote the physmap map driver to be a platform driver. I know zilch about the driver model, so I probably botched it in some way, but I've done some tests on an ixp23xx board which uses physmap, and it all seems to work. In order to not break existing physmap users, I've added some compat code that will instantiate a platform device iff CONFIG_MTD_PHYSMAP_LEN is defined and != 0. Also, I've changed the default value for CONFIG_MTD_PHYSMAP_LEN to zero, so that people who inadvertently compile in physmap (or new, platform-style, users of physmap) don't get burned. This works pretty well -- the new physmap driver is a drop-in replacement for the old one, and works on said ixp23xx board without any code changes needed. (This should hold as long as users don't touch 'physmap_map' directly.) Once all physmap users have been converted to instantiate their own platform devices, the compat code can go. (Or we decide that we can change all the in-tree users at the same time, and never merge the compat code.) Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-05-07 17:16:36 +01:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[MTD] Convert physmap to platform driver After dwmw2 let me know it ought to be done, I rewrote the physmap map driver to be a platform driver. I know zilch about the driver model, so I probably botched it in some way, but I've done some tests on an ixp23xx board which uses physmap, and it all seems to work. In order to not break existing physmap users, I've added some compat code that will instantiate a platform device iff CONFIG_MTD_PHYSMAP_LEN is defined and != 0. Also, I've changed the default value for CONFIG_MTD_PHYSMAP_LEN to zero, so that people who inadvertently compile in physmap (or new, platform-style, users of physmap) don't get burned. This works pretty well -- the new physmap driver is a drop-in replacement for the old one, and works on said ixp23xx board without any code changes needed. (This should hold as long as users don't touch 'physmap_map' directly.) Once all physmap users have been converted to instantiate their own platform devices, the compat code can go. (Or we decide that we can change all the in-tree users at the same time, and never merge the compat code.) Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-05-07 17:16:36 +01:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[MTD] Convert physmap to platform driver After dwmw2 let me know it ought to be done, I rewrote the physmap map driver to be a platform driver. I know zilch about the driver model, so I probably botched it in some way, but I've done some tests on an ixp23xx board which uses physmap, and it all seems to work. In order to not break existing physmap users, I've added some compat code that will instantiate a platform device iff CONFIG_MTD_PHYSMAP_LEN is defined and != 0. Also, I've changed the default value for CONFIG_MTD_PHYSMAP_LEN to zero, so that people who inadvertently compile in physmap (or new, platform-style, users of physmap) don't get burned. This works pretty well -- the new physmap driver is a drop-in replacement for the old one, and works on said ixp23xx board without any code changes needed. (This should hold as long as users don't touch 'physmap_map' directly.) Once all physmap users have been converted to instantiate their own platform devices, the compat code can go. (Or we decide that we can change all the in-tree users at the same time, and never merge the compat code.) Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-05-07 17:16:36 +01:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[MTD] Convert physmap to platform driver After dwmw2 let me know it ought to be done, I rewrote the physmap map driver to be a platform driver. I know zilch about the driver model, so I probably botched it in some way, but I've done some tests on an ixp23xx board which uses physmap, and it all seems to work. In order to not break existing physmap users, I've added some compat code that will instantiate a platform device iff CONFIG_MTD_PHYSMAP_LEN is defined and != 0. Also, I've changed the default value for CONFIG_MTD_PHYSMAP_LEN to zero, so that people who inadvertently compile in physmap (or new, platform-style, users of physmap) don't get burned. This works pretty well -- the new physmap driver is a drop-in replacement for the old one, and works on said ixp23xx board without any code changes needed. (This should hold as long as users don't touch 'physmap_map' directly.) Once all physmap users have been converted to instantiate their own platform devices, the compat code can go. (Or we decide that we can change all the in-tree users at the same time, and never merge the compat code.) Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-05-07 17:16:36 +01:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00