Time for cell code reshuffle?

Time for cell code reshuffle?

[Arnd Bergmann]

We've been discussing in the past a few times where we should best put
the spufs code, and when to do it. Since Jeremy and I now have all the
current patches in powerpc.git, maybe we should do it now.

To the question, where what it should go, I'd leave the decision to
Jeremy, but my current idea would be:

arch/powerpc/platforms/cell/spufs -> arch/powerpc/spufs
arch/powerpc/platforms/cell/spu_{callbacks,base,syscalls,fault,notify}.[co]
 -> arch/powerpc/spufs/{callbacks,base,syscalls,fault,notify}.[co]

If we do it in git now, that should result in a minimal breakage of patches.

A related question is what to do about the location of the other cell
related files. platforms/ps3 is already pretty self-contained once we have
spufs outside of platforms/cell, but there is still some code shared between
platforms/cell and platforms/celleb, and each of these directories also contains
code that is only relevant for a subset of the platforms.

My position on these files is that while I find the current state a little
bit confusing, I don't have an idea how to do it better either, and I think
we should just leave the platform files where they are.

	Arnd <><

Re: Time for cell code reshuffle?

[Geoff Levand]

Arnd Bergmann wrote:
> We've been discussing in the past a few times where we should best put
> the spufs code, and when to do it. Since Jeremy and I now have all the
> current patches in powerpc.git, maybe we should do it now.
> 
> To the question, where what it should go, I'd leave the decision to
> Jeremy, but my current idea would be:
> 
> arch/powerpc/platforms/cell/spufs -> arch/powerpc/spufs
> arch/powerpc/platforms/cell/spu_{callbacks,base,syscalls,fault,notify}.[co]
>  -> arch/powerpc/spufs/{callbacks,base,syscalls,fault,notify}.[co]


I think we should consider support for SpursEngine.  At the moment I have no
idea of what it needs, and if no one else does we need to find out.


> If we do it in git now, that should result in a minimal breakage of patches.
> 
> A related question is what to do about the location of the other cell
> related files. platforms/ps3 is already pretty self-contained once we have
> spufs outside of platforms/cell, but there is still some code shared between
> platforms/cell and platforms/celleb, and each of these directories also contains
> code that is only relevant for a subset of the platforms.


It seems platforms/cell should have the shared and/or generic code, and the other
stuff moved into a new platform directory, but is it worth the effort? 

-Geoff

Re: Time for cell code reshuffle?

[Arnd Bergmann]

On Friday 21 December 2007, Geoff Levand wrote:
> Arnd Bergmann wrote:
>
> > arch/powerpc/platforms/cell/spufs -> arch/powerpc/spufs
> > arch/powerpc/platforms/cell/spu_{callbacks,base,syscalls,fault,notify}.[co]
> >  -> arch/powerpc/spufs/{callbacks,base,syscalls,fault,notify}.[co]
> 
> 
> I think we should consider support for SpursEngine.  At the moment I have no
> idea of what it needs, and if no one else does we need to find out.

Hmm, since there is not much documentation available for SpursEngine, it's
rather hard to tell what needs to be done for it.

If we think that it will hit the kernel anytime soon, we could use fs/spufs
instead of arch/powerpc/spufs right away. Interestingly, this is where it was
initially, but got moved to arch/powerpc/platforms/cell/spufs after a lot
of discussion ;-).

> It seems platforms/cell should have the shared and/or generic code, and the other
> stuff moved into a new platform directory, but is it worth the effort? 

There is very little code in platforms/cell that can not be generic, so I think
it's not worth splitting it. The only IBM blade specific files are
cbe_cpufreq_pmi.c and parts of setup.c and pervasive.c. Everything else could
be shared by about any generic implementation without a hypervisor.

	Arnd <><

Re: Time for cell code reshuffle?

[Benjamin Herrenschmidt]

> A related question is what to do about the location of the other cell
> related files. platforms/ps3 is already pretty self-contained once we have
> spufs outside of platforms/cell, but there is still some code shared between
> platforms/cell and platforms/celleb, and each of these directories also contains
> code that is only relevant for a subset of the platforms.
> 
> My position on these files is that while I find the current state a little
> bit confusing, I don't have an idea how to do it better either, and I think
> we should just leave the platform files where they are.

Some of these files could do to syslib, like the io workarounds, rename
them spider-io-hacks :-)

Ben.

Re: Time for cell code reshuffle?

[Benjamin Herrenschmidt]

On Fri, 2007-12-21 at 09:23 -0800, Geoff Levand wrote:
> 
> It seems platforms/cell should have the shared and/or generic code,
> and the other
> stuff moved into a new platform directory, but is it worth the
> effort? 

No, platforms/xxx isn't supposed to be shared code. That's was syslib is
for.

Ben.

Re: Time for cell code reshuffle?

[Benjamin Herrenschmidt]

On Fri, 2007-12-21 at 20:15 +0100, Arnd Bergmann wrote:
> > It seems platforms/cell should have the shared and/or generic code,
> and the other
> > stuff moved into a new platform directory, but is it worth the
> effort? 
> 
> There is very little code in platforms/cell that can not be generic,
> so I think
> it's not worth splitting it. The only IBM blade specific files are
> cbe_cpufreq_pmi.c and parts of setup.c and pervasive.c. Everything
> else could
> be shared by about any generic implementation without a hypervisor.

Another option is to have:

platforms/celleb -> platforms/beat

and withing platforms/cell, rename blade specific files to
something (can't find what, works on CAB too) and add celleb
"bare metal" files.

A platform directly doesn't have to deal with one platform. For example,
platforms/44x contains a lot of board support.

Now, one question is how far can we merge celleb support with the common
blade/CAB code...

Cheers,
Ben.

Re: Time for cell code reshuffle?

[Josh Boyer]

On Sun, 23 Dec 2007 07:58:02 +1100
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:

> 
> On Fri, 2007-12-21 at 09:23 -0800, Geoff Levand wrote:
> > 
> > It seems platforms/cell should have the shared and/or generic code,
> > and the other
> > stuff moved into a new platform directory, but is it worth the
> > effort? 
> 
> No, platforms/xxx isn't supposed to be shared code. That's was syslib is
> for.

I think you mean sysdev?

josh

Re: Time for cell code reshuffle?

[Benjamin Herrenschmidt]

On Sat, 2007-12-22 at 15:11 -0600, Josh Boyer wrote:
> > 
> > No, platforms/xxx isn't supposed to be shared code. That's was
> syslib is
> > for.
> 
> I think you mean sysdev?

Yeah, whatever the name of the day for that thing is.

(It's syslib in arch/ppc ?)

Ben.

Re: [Cbe-oss-dev] Time for cell code reshuffle?

[Jeremy Kerr]

Hi all,

> To the question, where what it should go, I'd leave the decision to
> Jeremy, but my current idea would be:
>
> arch/powerpc/platforms/cell/spufs -> arch/powerpc/spufs

I'd suggest arch/powerpc/sysdev/spufs to keep arch/powerpc clean.

However, this may also depend on the (intended) structure of SPURSEngine 
support, which may mean that fs/spufs might be a better place. It would 
suck to have to move things twice, so maybe someone from Tosihba could 
provide some input? Would the powerpc spufs code be suitable for 
SPURSEngine?

As thers have posted earlier, i gthink that arch/powerpc/sysdev/cell 
would be good for the generic cell support, then we could have 
arch/powerpc/platforms/{cell,ps3,beat} containing only the individual 
platform code.

Cheers,


Jeremy

Re: [Cbe-oss-dev] Time for cell code reshuffle?

[Christoph Hellwig]

On Sun, Dec 23, 2007 at 12:47:42PM +0900, Jeremy Kerr wrote:
> Hi all,
> 
> > To the question, where what it should go, I'd leave the decision to
> > Jeremy, but my current idea would be:
> >
> > arch/powerpc/platforms/cell/spufs -> arch/powerpc/spufs
> 
> I'd suggest arch/powerpc/sysdev/spufs to keep arch/powerpc clean.
> 
> However, this may also depend on the (intended) structure of SPURSEngine 
> support, which may mean that fs/spufs might be a better place. It would 
> suck to have to move things twice, so maybe someone from Tosihba could 
> provide some input? Would the powerpc spufs code be suitable for 
> SPURSEngine?

Strong NACK for fs/spufs/  fs code is the smallest part of the spu
support, and all this nasty lowlevel code doesn't belong into fs/ at
all.

Re: [Cbe-oss-dev] Time for cell code reshuffle?

[Geert Uytterhoeven]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1460 bytes --]

On Sun, 23 Dec 2007, Christoph Hellwig wrote:
> On Sun, Dec 23, 2007 at 12:47:42PM +0900, Jeremy Kerr wrote:
> > > To the question, where what it should go, I'd leave the decision to
> > > Jeremy, but my current idea would be:
> > >
> > > arch/powerpc/platforms/cell/spufs -> arch/powerpc/spufs
> > 
> > I'd suggest arch/powerpc/sysdev/spufs to keep arch/powerpc clean.
> > 
> > However, this may also depend on the (intended) structure of SPURSEngine 
> > support, which may mean that fs/spufs might be a better place. It would 
> > suck to have to move things twice, so maybe someone from Tosihba could 
> > provide some input? Would the powerpc spufs code be suitable for 
> > SPURSEngine?
> 
> Strong NACK for fs/spufs/  fs code is the smallest part of the spu
> support, and all this nasty lowlevel code doesn't belong into fs/ at
> all.

drivers/spu/?

With kind regards,
 
Geert Uytterhoeven
Software Architect

Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
 
Phone:    +32 (0)2 700 8453	
Fax:      +32 (0)2 700 8622	
E-mail:   Geert.Uytterhoeven@sonycom.com	
Internet: http://www.sony-europe.com/
 	
Sony Network and Software Technology Center Europe	
A division of Sony Service Centre (Europe) N.V.	
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium	
VAT BE 0413.825.160 · RPR Brussels	
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619

Re: [Cbe-oss-dev] Time for cell code reshuffle?

[Luca Barbato]

Geert Uytterhoeven wrote:
> On Sun, 23 Dec 2007, Christoph Hellwig wrote:
>> Strong NACK for fs/spufs/  fs code is the smallest part of the spu
>> support, and all this nasty lowlevel code doesn't belong into fs/ at
>> all.
> 
> drivers/spu/?
> 

arch/spu/?

-- 

Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

Re: Time for cell code reshuffle?

[Ishizaki Kou]

Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> On Fri, 2007-12-21 at 20:15 +0100, Arnd Bergmann wrote:
> > > It seems platforms/cell should have the shared and/or generic code,
> > and the other
> > > stuff moved into a new platform directory, but is it worth the
> > effort? 
> > 
> > There is very little code in platforms/cell that can not be generic,
> > so I think
> > it's not worth splitting it. The only IBM blade specific files are
> > cbe_cpufreq_pmi.c and parts of setup.c and pervasive.c. Everything
> > else could
> > be shared by about any generic implementation without a hypervisor.
> 
> Another option is to have:
> 
> platforms/celleb -> platforms/beat
> 
> and withing platforms/cell, rename blade specific files to
> something (can't find what, works on CAB too) and add celleb
> "bare metal" files.
> 
> A platform directly doesn't have to deal with one platform. For example,
> platforms/44x contains a lot of board support.
> 
> Now, one question is how far can we merge celleb support with the common
> blade/CAB code...

Celleb-native needs own machine definition and setup code due to HW
and FW deferences between CellBlade and Celleb. Of course, because
Celleb-native and Celleb-Beat use some codes commonly, we need a place
to put Celleb common codes.

But I don't know your idea is better or not.

Best regards,
Kou Ishizaki

Re: Time for cell code reshuffle?

[Arnd Bergmann]

On Wednesday 26 December 2007, Ishizaki Kou wrote:
> Celleb-native needs own machine definition and setup code due to HW
> and FW deferences between CellBlade and Celleb. Of course, because
> Celleb-native and Celleb-Beat use some codes commonly, we need a place
> to put Celleb common codes.
> 
> But I don't know your idea is better or not.

The two more sensible options I can see are

* leave everything where it is, live with the problem that the
  separation between celleb-native, celleb-beat and ibm-native
  is unclear.
* put both celleb and the ibm blades into the cell subdirectory,
  now with three different machine descriptions in there and only
  make sure that platforms/cell doesn't share any code with ps3,
  which is more clearly separated already (once we move spufs out).

I'm fine either way, and will accept patches from Toshiba to merge
the two directories if you prefer that, but I won't do it myself.

	Arnd <><