Re: [PATCH 6/16] cell: abstract spu management routines

[Michael Ellerman <michael@ellerman.id.au>]

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

On Sun, 2006-11-12 at 20:34 -0800, Geoff Levand wrote:
> Michael Ellerman wrote:
> > On Fri, 2006-11-10 at 12:01 -0800, Geoff Levand wrote:
> >> This adds a platform specific spu management abstraction and the coresponding
> >> routines to support the IBM Cell Blade.  It also removes the hypervisor only
> >> resources that were included in struct spu.
> >> 
> >> Three new platform specific routines are introduced, spu_enumerate_spus(),
> >> spu_create_spu() and spu_destroy_spu().  The underlining design uses a new
> >> type, struct spu_management_ops, to hold function pointers that the platform
> >> setup code is expected to initialize to instances appropriate to that platform.
> >> 
> >> For the IBM Cell Blade support, I put the hypervisor only resources that were
> >> in struct spu into a platform specific data structure struct spu_pdata.
> > 
> > As far as I can see you haven't posted your HV-backed management ops, is
> > that right?
> 
> 
> Yes, that is in '[PATCH 15/16] cell: add ps3 platform spu support' posted
> with the other ps3pf patches.

OK, I'll have a look at it.

> > Why can't your PS3 platform code fake-up device nodes for SPUs? It seems
> > that would simplify this quite a lot.
> 
> 
> Seems like a hack to me.  My concern is that I just have to keep adding some
> extra hack for every new spu feature that comes out.  I would prefer to make
> a proper design from the start, but if anyone can be more convincing I am
> open to suggestions.

Well the whole thrust of the flattened-device-tree model, is that we do
as much platform-specific hackery in a boot-loader/early-init, and
present the hardware in as standard a way as possible to the kernel via
the device tree.

The hope is that this isolates most of the kernel from platform specific
details, as far as is possible - there will always be some things that
need to be abstracted out - for that we have ppc_md and a few other
callbacks.

The priv1_ops serve that purpose, providing callbacks, and there's
really no way around that - you can't tap the priv1 area when you're
running under a HV - fine. But for just finding the spus it strikes me
that it would be _nicer_, perhaps not easier :), to have your
"enumerate_spus" populate the flat device tree early on - which would
leave more of the spu code untouched by the hv/bare-metal issue.

But as I said before, I haven't looked thoroughly at the code, so
perhaps there's some obvious reason why that wouldn't work.

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