On Tue, 2006-04-18 at 15:45 +1000, Paul Mackerras wrote:
Benjamin Herrenschmidt writes:
Looks good to me except that we need the same for ppc64 since the 970
theorically has the same problem...
OK, does this look OK to everyone, before I send it off to Linus? I
now use a bit in the
On Tue, 2006-04-18 at 16:32 +1000, Paul Mackerras wrote:
Benjamin Herrenschmidt writes:
The 970 version bloats the exception prolog significantly... I
Four instructions, in the external and decrementer interrupt entry
paths - I don't think that's really significant bloat.
Yeah well..
Benjamin Herrenschmidt writes:
Looks good to me except that we need the same for ppc64 since the 970
theorically has the same problem...
OK, does this look OK to everyone, before I send it off to Linus? I
now use a bit in the thread_info rather than using the HID0 bits
themselves to indicate
Benjamin Herrenschmidt writes:
The 970 version bloats the exception prolog significantly... I
Four instructions, in the external and decrementer interrupt entry
paths - I don't think that's really significant bloat.
understand now why you were talking about putting the code in the exit
path
On Tue, Apr 18, 2006 at 04:32:46PM +1000, Paul Mackerras wrote:
understand now why you were talking about putting the code in the exit
path on irc ... I don't like it that way Also, if you want to keep
it, maybe use a separate CONFIG_PPC_970STYLE_NAP or something that gets
selected by
On Tue, Apr 18, 2006 at 09:56:00AM -0500, Olof Johansson wrote:
On Tue, Apr 18, 2006 at 04:32:46PM +1000, Paul Mackerras wrote:
understand now why you were talking about putting the code in the exit
path on irc ... I don't like it that way Also, if you want to keep
it, maybe use a
Paul,
This new version of the patch breaks 32-bit arch/ppc builds. The changes
to the idle_6xx code are shared between architectures, but the entry.S
code and asm-offsets.c are not.
Here's a patch that puts the changes in arch/ppc as well. Builds and
boots on 834x (which is CONFIG_6xx).
Actually, I think the problem is that the code linux is using to turn
on nap mode is not guaranteed to put the processor in nap mode by the
time the blr in ppc6xx_idle occurs.
Thanks, Becky.
This patch fixes it for me. Comments, anyone?
Works for me :-)
Michael
--
To
On Apr 13, 2006, at 5:20 AM, Benjamin Herrenschmidt wrote:
(For those who haven't followed the beginning, current git locks up at
boot on most recent powermacs. It was tracked down to a weird problem
with the idle code. My latest experiments seem to show something dodgy
with MSR_POW). Help
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
orisr7,r7,[EMAIL PROTECTED]
sync
isync
mtmsr r7
isync
label:
b label
Hi,
On Fri, Apr 14, 2006 at 12:07:23PM -0700, Paul Mackerras wrote:
Becky Bruce writes:
Actually, I think the problem is that the code linux is using to turn
on nap mode is not guaranteed to put the processor in nap mode by the
time the blr in ppc6xx_idle occurs.
Thanks, Becky.
On Fri, Apr 14, 2006 at 01:19:36PM -0700, Paul Mackerras wrote:
Olof Johansson writes:
Where is cr0 set now -- you took the dot off of rlwinm?
transfer_to_handler does mfspr r11,SPRN_HID0; mtcr r11 before jumping
to power_save_6xx_restore. The rlwinm. was wrong anyway since it was
On Fri, 2006-04-14 at 12:07 -0700, Paul Mackerras wrote:
Becky Bruce writes:
Actually, I think the problem is that the code linux is using to turn
on nap mode is not guaranteed to put the processor in nap mode by the
time the blr in ppc6xx_idle occurs.
Thanks, Becky.
This patch
On Fri, 2006-04-14 at 15:00 -0500, Becky Bruce wrote:
He's being sneaky - there's a copy of HID0 in the CR at this point
from the caller, and bit 9 is the position for NAP.
It's a trick I learned from Darwin :) They do that regulary when code is
very cpu-feature dependant, like cache code for
Becky Bruce writes:
Actually, I think the problem is that the code linux is using to turn
on nap mode is not guaranteed to put the processor in nap mode by the
time the blr in ppc6xx_idle occurs.
Thanks, Becky.
This patch fixes it for me. Comments, anyone?
Paul.
diff -urN
He's being sneaky - there's a copy of HID0 in the CR at this point
from the caller, and bit 9 is the position for NAP.
-B
On Apr 14, 2006, at 2:54 PM, Olof Johansson wrote:
Hi,
On Fri, Apr 14, 2006 at 12:07:23PM -0700, Paul Mackerras wrote:
Becky Bruce writes:
Actually, I think the
Olof Johansson writes:
Where is cr0 set now -- you took the dot off of rlwinm?
transfer_to_handler does mfspr r11,SPRN_HID0; mtcr r11 before jumping
to power_save_6xx_restore. The rlwinm. was wrong anyway since it was
setting cr0.eq based on all the *other* bits in HID0, not HID0_NAP
(doh!).
On Fri, 2006-04-14 at 12:07 -0700, Paul Mackerras wrote:
Becky Bruce writes:
Actually, I think the problem is that the code linux is using to turn
on nap mode is not guaranteed to put the processor in nap mode by the
time the blr in ppc6xx_idle occurs.
Thanks, Becky.
This patch fixes it
(For those who haven't followed the beginning, current git locks up at
boot on most recent powermacs. It was tracked down to a weird problem
with the idle code. My latest experiments seem to show something dodgy
with MSR_POW). Help from Freescale folks would be appreciated.
On Sat, 2006-04-08 at
The above code should really look like this:
mfmsr r7
ori r7,r7,MSR_EE
orisr7,r7,[EMAIL PROTECTED]
sync
isync
mtmsr r7
isync
label:
b label
blr
Ohhh ... we always assumed mtmsr with MSR_POW
FYI, the user's manual recommends this sequence:
loop:
sync
mtmsr POW
isync
b loop
Ok, that's what OS X does... I always wondered ...
So ideally, we should do something similar to the above and set some
global bit somewhere telling the exception path to
On Fri, Apr 14, 2006 at 08:37:21AM +1000, Benjamin Herrenschmidt wrote:
I need to verify what's up with the 970. I noticed Apple has some
970 keeps executing too. I guess it's never bitten hard enough to
trigger anything serious.
-Olof
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a
22 matches
Mail list logo
