Subject: Re: [PATCH 1/2] Add support for stopping spus from xmon

From: Michael Ellerman <[email-masked]>
Date: Wed, 18 Oct 2006 17:14:56 +1000

On Fri, 2006-10-13 at 01:18 -0200, Luke Browning wrote:
> 
> linuxppc-dev-bounces+lukebrowning=[email-masked] wrote on
> 10/12/2006 09:03:08 AM:
> 
> > This patch adds support for stopping, and restarting, spus
> > from xmon. We use the spu master runcntl bit to stop execution,
> > this is apparently the "right" way to control spu execution and
> > spufs will be changed in the future to use this bit.
> > 
> > Testing has shown that to restart execution we have to turn the
> > master runcntl bit on and also rewrite the spu runcntl bit, even
> > if it is already set to 1 (running).
> > 
> > Stopping spus is triggered by the xmon command 'ss' - "spus stop"
> > perhaps. Restarting them is triggered via 'sr'. Restart doesn't
> > start execution on spus unless they were running prior to being
> > stopped by xmon.
> > 
> > Walking the spu->full_list in xmon after a panic, would mean
> > corruption of any spu struct would make all the others
> > inaccessible. To avoid this, and also to make the next patch
> > easier, we cache pointers to all spus during boot.
> 
> The spe affinity code drop created an array of spu pointers that 
> is indexed by spu->number.  We have a couple of other fields in 
> there that are needed for multiple spu scheduling operations.   
> Maybe, you can use this array.  The name of the arry is lspu[] 
> for logical spus. 

I'll have a look at it, but part of the rationale for xmon keeping its
own array is that there should be no code during normal kernel operation
that touches that array, and therefore less chance that a programming
error will corrupt the array.

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