[Cbe-oss-dev] [PATCH 1/2] Add support for stopping spus from xmon

[Michael Ellerman]

On Fri, 2006-10-13 at 01:18 -0200, Luke Browning wrote:
> 
> linuxppc-dev-bounces+lukebrowning=us.ibm.com at ozlabs.org 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
URL: <http://lists.ozlabs.org/pipermail/cbe-oss-dev/attachments/20061018/1f198cbb/attachment.pgp>