linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
* [PATCH 13/16] powerpc: add ps3 platform lpar addressing
@ 2006-11-10 20:03 Geoff Levand
  2006-11-11 11:28 ` Christoph Hellwig
  0 siblings, 1 reply; 5+ messages in thread
From: Geoff Levand @ 2006-11-10 20:03 UTC (permalink / raw)
  To: Paul Mackerras; +Cc: linuxppc-dev

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.

Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>

---
 arch/powerpc/platforms/ps3pf/Kconfig |   11 +++++++++++
 include/asm-powerpc/sparsemem.h      |    6 ++++++
 2 files changed, 17 insertions(+)

Index: cell--common--6/arch/powerpc/platforms/ps3pf/Kconfig
===================================================================
--- cell--common--6.orig/arch/powerpc/platforms/ps3pf/Kconfig
+++ 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
Index: cell--common--6/include/asm-powerpc/sparsemem.h
===================================================================
--- cell--common--6.orig/include/asm-powerpc/sparsemem.h
+++ 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);

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH 13/16] powerpc: add ps3 platform lpar addressing
  2006-11-10 20:03 [PATCH 13/16] powerpc: add ps3 platform lpar addressing Geoff Levand
@ 2006-11-11 11:28 ` Christoph Hellwig
  2006-11-12  0:45   ` Benjamin Herrenschmidt
  0 siblings, 1 reply; 5+ messages in thread
From: Christoph Hellwig @ 2006-11-11 11:28 UTC (permalink / raw)
  To: Geoff Levand; +Cc: linuxppc-dev, Paul Mackerras

On Fri, Nov 10, 2006 at 12:03:32PM -0800, Geoff Levand wrote:
> 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.

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH 13/16] powerpc: add ps3 platform lpar addressing
  2006-11-11 11:28 ` Christoph Hellwig
@ 2006-11-12  0:45   ` Benjamin Herrenschmidt
  2006-11-13  0:41     ` Michael Ellerman
  0 siblings, 1 reply; 5+ messages in thread
From: Benjamin Herrenschmidt @ 2006-11-12  0:45 UTC (permalink / raw)
  To: Christoph Hellwig; +Cc: linuxppc-dev, Paul Mackerras

On Sat, 2006-11-11 at 12:28 +0100, Christoph Hellwig wrote:
> On Fri, Nov 10, 2006 at 12:03:32PM -0800, Geoff Levand wrote:
> > 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.

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH 13/16] powerpc: add ps3 platform lpar addressing
  2006-11-12  0:45   ` Benjamin Herrenschmidt
@ 2006-11-13  0:41     ` Michael Ellerman
  2006-11-13  2:05       ` Geoff Levand
  0 siblings, 1 reply; 5+ messages in thread
From: Michael Ellerman @ 2006-11-13  0:41 UTC (permalink / raw)
  To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Paul Mackerras

[-- Attachment #1: Type: text/plain, Size: 1712 bytes --]

On Sun, 2006-11-12 at 11:45 +1100, Benjamin Herrenschmidt wrote:
> On Sat, 2006-11-11 at 12:28 +0100, Christoph Hellwig wrote:
> > On Fri, Nov 10, 2006 at 12:03:32PM -0800, Geoff Levand wrote:
> > > 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.

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

-- 
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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH 13/16] powerpc: add ps3 platform lpar addressing
  2006-11-13  0:41     ` Michael Ellerman
@ 2006-11-13  2:05       ` Geoff Levand
  0 siblings, 0 replies; 5+ messages in thread
From: Geoff Levand @ 2006-11-13  2:05 UTC (permalink / raw)
  To: michael; +Cc: Paul Mackerras, linuxppc-dev

Michael Ellerman wrote:
> On Sun, 2006-11-12 at 11:45 +1100, Benjamin Herrenschmidt wrote:
>> On Sat, 2006-11-11 at 12:28 +0100, Christoph Hellwig wrote:
>> > On Fri, Nov 10, 2006 at 12:03:32PM -0800, Geoff Levand wrote:
>> > > 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.
> 
> 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

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2006-11-13  2:05 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-11-10 20:03 [PATCH 13/16] powerpc: add ps3 platform lpar addressing Geoff Levand
2006-11-11 11:28 ` Christoph Hellwig
2006-11-12  0:45   ` Benjamin Herrenschmidt
2006-11-13  0:41     ` Michael Ellerman
2006-11-13  2:05       ` Geoff Levand

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).