spufs platform dependent code

[Arnd Bergmann]

On Saturday 28 January 2006 00:46, Geoff Levand wrote:
> Arnd Bergmann wrote:

> > I agree that in the long term, we may want to optimize for the case
> > where we have a single kernel binary that has all possible options
> > enabled, which would work better with a function pointer.
> 
> 
> I started some work on this.   I'll post a patch for comment, maybe
> next week.

Ok, great. I'll be mostly offline during the next few weeks so
I might not be able to comment on your patches. 

> > I'm not sure I could follow you. My idea of the cell platform
> > code is that it ought to be generic enough to work with all
> > hardware that has some SPU support in it. Right now, a lot of
> > stuff is hardwired to use the stuff we have on the Cell Blade,
> > but that only means that so far nobody has submitted a patch
> > to extend this to any other hardware.
> 
> I found you have some stuff in there specific to your platform.
> It assumes there is a certain south bridge, and that spu
> interrupts are serviced by that south bridge.  It also makes
> assumptions of how the spu's are represented in the device tree.
> 
> I've got a first cut patch to break those things out.  I'll post
> it soon for comment.

The stuff that is specific to our south bridge should be fairly
independant from anything that is related to spu code. If you have
http://patchwork.ozlabs.org/linuxppc64/patch?id=4188 applied,
it should already become a bit cleaner.

Since the base code is just using the internal interrupt controller
interfaces that are specified in the CBE Architecture documents,
I assumed they were pretty universal, even when using hcall interfaces
instead of mmio access. Is that different for your implementation?

Regarding the device tree representation of SPUs, we failed to
document this properly in the past, but I strongly feel that we should
standardize on a common representation before any system ships in
large quantaties. Of course I would rather not have to make changes
to our current firmware, but if you have requirements that can not
be met with what we are doing now, we might get convinced to adapt
to what you are doing or some compromize.

> > Did I get you right that you instead want to add a separate
> > platform directory for your hypervisor abstraction?
> > Since I haven't seen your code, I don't know how much it differs
> > from what we have so far and can't really tell which would be
> > better.
> > 
> > For the spu_priv1.c file, it's proably easiest to do it similar
> > to the abstraction we already have for spu_context_ops, the files
> > could e.g. be named spu_priv1_mmio.c and spu_priv1_hvcall.c.
> 
> 
> Sorry for the confusion, what I meant was that if we move the
> interrupt code, etc. to spu_priv1.c, it becomes more than just
> priv1 wrappers, so I thought it might be better to name it
> something else.
> 
> I was also thinking to put support for all platforms into
> arch/powerpc/platforms/cell, each in a different file.  But
> on consideration it might work better to put them into a
> separate directory.  Let's not decide that now though, and
> just focus on splitting out the platform code from spu_base.c
> and doing the wrappers.
> 
ok, agreed.

	Arnd <><