On Apr 13, 2006, at 3:55 PM, Benjamin Herrenschmidt wrote:
The above code should really look like this:
mfmsr r7
ori r7,r7,MSR_EE
oris r7,r7,[EMAIL PROTECTED]
sync
isync
mtmsr r7
isync
label:
b label
blr
Ohhh ... we always assumed mtmsr with MSR_POW was
immediate/synchronous ! That explains a lot. The problem with the
above
though is that we'll never get out unless we also hack the exception
path to change the return address once an exception happens. It's not
that difficult especially since we already have a special case to
handle
returning from NAP there, on ppc32 at least. ppc64 will need a bit
more
investigation.
Agreed, this is yuck :(
Do you see another way to loop until NAP has gone ? Maybe reading
msr in
a loop until POW gets cleared would do the trick ?
So, it makes sense to me that this would work, but I suspect there
may be hardware wierdness - the user manual is very specific about
the code sequence that should be used (although I've given you a
slightly different sequence in my last mail that is also known to
work and is cleaner, IMHO). Let me check with one of our HW
designers to see if this is OK. It might be tomorrow before I have
an answer - it's after 4:30 here and some of them are early birds,
and might have already left for the day.
FYI, the user's manual recommends this sequence:
loop:
sync
mtmsr POW
isync
b loop
Hope this helps - I don't have hardware to test this on, so I can't
be sure, but it seems to explain the behavior you're seeing if I'm
understanding the problem correctly.
It definitely does ! Thanks a lot.
NP.
Cheers!
-B
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]