Skip to contentSkip to conversation

Support 36-bit iomem on 32-bit Au1x00

RFC In review [email protected] 3 participants 6 messages Jan 3, 2010 – Jan 28, 2010 MIPS

lore
Share & tools
lore

[email protected]

author
#0 lore raw

RFC 1/1 Support 36-bit iomem on 32-bit Au1x00

Hi,

I believe these changes are needed on Alchemy SoCs in order to use iomem above 4G with the usual platform_device machinery:

- Set CONFIG_ARCH_PHYS_ADDR_T_64BIT to make resource_size_t 64-bit.
- Increase IOMEM_RESOURCE_END so that platforms can register resources.

arch/mips/Kconfig 2009-12-30 22:05:38.000000000 +0100 renamed from arch/mips/Kconfig.orig 2009-12-30 18:06:02.000000000 +0100 +3 -0
@@ -1725,6 +1725,9 @@
 config 64BIT_PHYS_ADDR
        bool
 
+config ARCH_PHYS_ADDR_T_64BIT
+       def_bool 64BIT_PHYS_ADDR
+
 config CPU_HAS_SMARTMIPS
        depends on SYS_SUPPORTS_SMARTMIPS
        bool "Support for the SmartMIPS ASE"
arch/mips/include/asm/mach-au1x00/au1000.h 2010-01-03 13:28:50.000000000 +0100 renamed from arch/mips/include/asm/mach-au1x00/au1000.h.orig 2009-12-30 19:45:35.000000000 +0100 +1 -1
@@ -1728,7 +1728,7 @@
 #define IOPORT_RESOURCE_START  0x10000000
 #define IOPORT_RESOURCE_END    0xffffffff
 #define IOMEM_RESOURCE_START   0x10000000
-#define IOMEM_RESOURCE_END     0xffffffff
+#define IOMEM_RESOURCE_END     0xfffffffffLL
 
 #define PCI_IO_START   0
 #define PCI_IO_END     0
#1 lore raw

Hi Pascal,

Quoted 7 lines · On Sun, Jan 3, 2010 at 1:39 PM, [email protected] <[email protected]> wrote:

Hi,

I believe these changes are needed on Alchemy SoCs in order to use iomem above 4G with the usual platform_device machinery:

- Set CONFIG_ARCH_PHYS_ADDR_T_64BIT to make resource_size_t 64-bit.
- Increase IOMEM_RESOURCE_END so that platforms can register resources.

Have you tried to register a platform device above the 4G line? I get an oops inside the platform device match code when I do. I'll try to figure out why.

Manuel

author
#2 lore raw
Quoted 2 lines · Manuel Lauss

Have you tried to register a platform device above the 4G line? I get an oops inside the platform device match code when I do. I'll try to figure out why.

Yes, I used these patches on top of 2.6.33-rc2 and 2.6.33-rc2-next-20100101 for an ethernet chip at 0xd:1000:0000 on a Au1250 board.

I don't remember seeing oopses while I was figuring out how to get 36-bit I/O working. arch/x86 and arch/powerpc have been supporting 32-bit processors with 64-bit physical addresses for a long time, so I would expect the generic resource management code to be reliable. There are other changes in my tree, but I can't think of anything which might affect this. Let me know if I can help further.

Pascal

#3 lore raw

On Tue, Jan 26, 2010 at 10:19:22PM +0100, [email protected] wrote:

The whole fixing up of I/O addresses was necessary because the generic code was written to assume that sizeof(unsigned long) == sizeof(void *) and that mostly because it was handy for Linus' i386 world.

Today I think it would be preferable to get rid of the the fixups, pay the small price for the larger resources and get sanity in exchange. My gut feeling is that the bloat factor should be small. Either way, I'll let you two sort this out for Alchemy and mark this patch as defered.

Ralf

#4 lore raw
Quoted 10 lines · Ralf Baechle

On Tue, Jan 26, 2010 at 10:19:22PM +0100, [email protected] wrote:

The whole fixing up of I/O addresses was necessary because the generic code was written to assume that sizeof(unsigned long) == sizeof(void *) and that mostly because it was handy for Linus' i386 world.

Today I think it would be preferable to get rid of the the fixups, pay the small price for the larger resources and get sanity in exchange.  My gut feeling is that the bloat factor should be small.  Either way, I'll let you two sort this out for Alchemy and mark this patch as defered.

I'm fine with it as-is; it doesn't break anything. I was experimenting with extending the PCMCIA socket code to pass on 36bit addresses and got bitten by the driver core.

Manuel

#5 lore raw
Quoted 8 lines · Manuel Lauss
Quoted 4 lines

Today I think it would be preferable to get rid of the the fixups, pay the small price for the larger resources and get sanity in exchange.  My gut feeling is that the bloat factor should be small.  Either way, I'll let you two sort this out for Alchemy and mark this patch as defered.

I'm fine with it as-is; it doesn't break anything. I was experimenting with extending the PCMCIA socket code to pass on 36bit addresses and got bitten by the driver core.

Fine, so I applied the patch and fixed up the reject.

Pascal, please include a Signed-off-by: line in future patches.

Ralf