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).
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, ma
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
> > sele
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
> pat
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
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
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
> > 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
--
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 f
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!).
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 proble
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 powerpc-me
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 fo
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.
>
>
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
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,
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
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 from
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 s
> 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 t
>
> 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 wi
(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 1
22 matches
Mail list logo
