Skip to contentSkip to conversation

powerpc: add ps3 platform lpar addressing

PATCH In review Geoff Levand 4 participants 5 messages Nov 10, 2006 – Nov 13, 2006 PowerPC

lore
Share & tools
lore
#0 lore raw

PATCH 13/16 powerpc: add ps3 platform lpar addressing

Adds some needed bits for a config option PS3PF_USE_LPAR_ADDR that disables the ps3pf lpar address translation mechanism. This is a currently needed workaround for limitations in the design of the spu support.

---
 arch/powerpc/platforms/ps3pf/Kconfig |   11 +++++++++++
 include/asm-powerpc/sparsemem.h      |    6 ++++++
 2 files changed, 17 insertions(+)
arch/powerpc/platforms/ps3pf/Kconfig +11 -0
Index: cell--common--6/arch/powerpc/platforms/ps3pf/Kconfig
===================================================================
@@ -29,4 +29,15 @@
 	  This support is mainly for Linux kernel development.  If unsure,
 	  say N.
 
+config PS3PF_USE_LPAR_ADDR
+	depends on PS3PF && EXPERIMENTAL
+	bool "PS3 Platform use lpar address space"
+	default y
+	help
+	  This option is solely for experimentation by experts.  Disables
+	  translation of lpar addresses.  SPE support currently won't work
+	  without this set to y.
+
+	  If you have any doubt, choose the default y.
+
 endmenu
include/asm-powerpc/sparsemem.h +6 -0
Index: cell--common--6/include/asm-powerpc/sparsemem.h
===================================================================
@@ -9,8 +9,14 @@
  * MAX_PHYSMEM_BITS		2^N: how much memory we can have in that space
  */
 #define SECTION_SIZE_BITS       24
+
+#if defined(CONFIG_PS3PF_USE_LPAR_ADDR)
+#define MAX_PHYSADDR_BITS       47
+#define MAX_PHYSMEM_BITS        47
+#else
 #define MAX_PHYSADDR_BITS       44
 #define MAX_PHYSMEM_BITS        44
+#endif
 
 #ifdef CONFIG_MEMORY_HOTPLUG
 extern void create_section_mapping(unsigned long start, unsigned long end);
#1 lore raw
Quoted 3 lines · Geoff Levand

Adds some needed bits for a config option PS3PF_USE_LPAR_ADDR that disables the ps3pf lpar address translation mechanism. This is a currently needed workaround for limitations in the design of the spu support.

So make the code do the sane thing and don't put the config in the kernel tree.

#2 lore raw
Quoted 7 lines · Christoph Hellwig
Quoted 3 lines · Geoff Levand

Adds some needed bits for a config option PS3PF_USE_LPAR_ADDR that disables the ps3pf lpar address translation mechanism. This is a currently needed workaround for limitations in the design of the spu support.

So make the code do the sane thing and don't put the config in the kernel tree.

Well... I'd like to keep the option for a little while.

There are performances issues with sparsemem the way it's used by ps3pf.. the problem is that the memory map looks like you get a bunch of memory at 0 (the RMO, not sure exactly how much in practice) and the rest in a chunk all the way up the 48 bits or so max physical space.

So sparsemem ends up with an enormous mapping only populated at the very beginning and the very end.

Thus, I'd like Geoff to keep the option of doing the manual translation in the hash code for now until I finally get some HW and thus can do some measurements, and possibly figure out a nicer way to deal with that.

Cheers,
Ben.

#3 lore raw
Quoted 16 lines · Benjamin Herrenschmidt
Quoted 7 lines · Christoph Hellwig
Quoted 3 lines · Geoff Levand

Adds some needed bits for a config option PS3PF_USE_LPAR_ADDR that disables the ps3pf lpar address translation mechanism. This is a currently needed workaround for limitations in the design of the spu support.

So make the code do the sane thing and don't put the config in the kernel tree.

Well... I'd like to keep the option for a little while.

There are performances issues with sparsemem the way it's used by ps3pf.. the problem is that the memory map looks like you get a bunch of memory at 0 (the RMO, not sure exactly how much in practice) and the rest in a chunk all the way up the 48 bits or so max physical space.

Quoted 7 lines

So sparsemem ends up with an enormous mapping only populated at the very beginning and the very end.

Thus, I'd like Geoff to keep the option of doing the manual translation in the hash code for now until I finally get some HW and thus can do some measurements, and possibly figure out a nicer way to deal with that.

I haven't read the ps3 code very carefully, but at first glance it struck me that it has a similar problem to iSeries. It might be worth seeing if the iSeries mschunks_map gunk can help (see include/asm-powerpc/abs_addr.h)

cheers

Signature · 8 lines
Michael Ellerman
OzLabs, IBM Australia Development Lab

wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)

We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
#4 lore raw
Quoted 25 lines · Michael Ellerman
Quoted 16 lines · Benjamin Herrenschmidt
Quoted 7 lines · Christoph Hellwig
Quoted 3 lines · Geoff Levand

Adds some needed bits for a config option PS3PF_USE_LPAR_ADDR that disables the ps3pf lpar address translation mechanism. This is a currently needed workaround for limitations in the design of the spu support.

So make the code do the sane thing and don't put the config in the kernel tree.

Well... I'd like to keep the option for a little while.

There are performances issues with sparsemem the way it's used by ps3pf.. the problem is that the memory map looks like you get a bunch of memory at 0 (the RMO, not sure exactly how much in practice) and the rest in a chunk all the way up the 48 bits or so max physical space.

Quoted 7 lines

So sparsemem ends up with an enormous mapping only populated at the very beginning and the very end.

Thus, I'd like Geoff to keep the option of doing the manual translation in the hash code for now until I finally get some HW and thus can do some measurements, and possibly figure out a nicer way to deal with that.

Quoted 4 lines

I haven't read the ps3 code very carefully, but at first glance it struck me that it has a similar problem to iSeries. It might be worth seeing if the iSeries mschunks_map gunk can help (see include/asm-powerpc/abs_addr.h)

Yes, it is essentially the same as iSeries, but since the current spu code sets up the spu local stores as chunks of sparse memory, I still need this for those. To fix it properly the spu code needs to be re-worked, and Ben said he plans to do some work there. At that time I will reconsider how to manage the mem regions.

As Christoph says though, this doesn't really need to be exposed as a config option, but I wanted to include it for anyone that wanted to experiment with it. If you don't use spus you can save about 256KB with this option.

-Geoff