linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: benh@kernel.crashing.org
To: "Kevin B. Hendricks" <kevin.hendricks@sympatico.ca>,
	Edward Swarthout <Ed.Swarthout@Motorola.com>
Cc: <yellowdog-devel@lists.yellowdoglinux.com>,
	<linuxppc-dev@lists.linuxppc.org>
Subject: Re: some questions on new dual 1Gig G4's support?
Date: Mon, 4 Feb 2002 19:23:08 +0100	[thread overview]
Message-ID: <20020204182308.21006@mailhost.mipsys.com> (raw)
In-Reply-To: <20020204175119.RDWC23298.tomts23-srv.bellnexxia.net@there>


>They clearly say that 7451 and 7455 do not have a settable DOZE state.
>Instead the DOZE state is just an intermediate state between the Full
>Power Mode state and the NAP state.   They have a nice event transition
>driven state diagram to illustrate all of this.   According to the manual
>the purpose of this transitory state (DOZE) is to allow bus snooping.
>There is also a SLEEP mode that is diferent from NAP (saves more power)
>and that does not ever enter the trasient DOZE state on its way back to
>the FULL Power State.

Yes, they don't have the specific DOZE mode (DOZE bit in HID0), which
is why we should split those 2 features. Some CPUs can DOZE & NAP,
some can NAP only, but some montherboard don't allow NAP because the
host bridge don't properly assert QACK to enforce cache coherency.

So instead of the current cruft, let's properly say which CPU can
do what in cputable.c. Then, in idle.c, the algorithm should be:

 if (powersave_nap && cpu_can_nap)
        nap
 else if (cpu_can_doze)
        doze
 else
        do nothing

(powersave_nap is set by pmac_feature and indicates if the motherboard
supports NAP mode & cache coherency or not).

>The differnces between NAP and SLEEP are as follows (according to the
>manual)

 (...)

Yup, this basically explains that SLEEP mode won't enforce cache coherency.
We currently don't use SLEEP mode (except eventually when putting the laptops
to sleep, which is a different matter).

>It is interesting to note that the recommended algo to enter either sleep
>or nap includes the following (again quoting from the revised manual)
>
>
>---
>10.2.4 Power Management Software Considerations
>Because the MPC7451 is a three-issue processor with out-of-order execution
>capability, care must be taken in how the power management mode is
>entered. Furthermore, nap and sleep modes require all outstanding bus
>operations to be completed before these modes are entered. Normally,
>during system configuration time, one of these power management
>modes would be selected by setting the appropriate HID0 bit. Later on, the
>mode is invoked by setting MSR[POW]. To ensure a clean transition into and
>out of a power-management mode, the mtmsr which sets the POW bit must be
>preceded by the proper cache flushes, instruction cache disable followed
>by isync, TLB invalidates, and then dssall and sync
>instructions. The sleep mode entry sequence is as follows:
>
>mtHIDO (NAP | SLEEP)
>...
>...
>dssall
>... cache flushes... (1)
>... instruction cache disable ... (2)
>isync (3)
>... TLB invalidates ... (4)
>loop    sync
>mtmsr[POW = 1]
>isync
>b loop

That's interesting. My understanding was that NAP didn't require that.
This might explains (or might not) some stability issues some people
are still having with dual 7450's.

>
>The dssall instruction is needed to kill any outstanding stream touch
>instructions not killed by a sync.

Ok, this one has to be added I beleive, probably also to the laptop
sleep code.
>
>So this looks pretty detailed and it clearly says to flush all caches
>before entering and disable the instruction cache but it does not  show
>any differences between NAP and SLEEP.
>
>So what advantage of bus snooping with NAP (that tranistions to DOZE and
>back) if you must flush all of the cache's before entering and leaving NAP
>or SLEEP?

Which makes few sense as the purpose of bus snooping is actually to keep
cache coherency. Can someone from MOTO explain ? Edward ?

>I don't understand the advantage of NAP unless the QACK(bar) signal to the
>processor is enabled for all memory writes by all other processors, DMA
>chips, etc.   Is this true for *everything* that accesses L1, L2, L3 cache?
>
>Can anyone explain what I am misunderstanding here?

Hrm... not me.... All I can say is that I currently do none of the above and
use NAP mode on my 7450 based laptop with no problem so far.

Ben.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

      reply	other threads:[~2002-02-04 18:23 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-02-02 14:50 some questions on new dual 1Gig G4's support? Kevin B. Hendricks
2002-02-02 20:11 ` Benjamin Herrenschmidt
2002-02-02 20:21   ` Kevin B. Hendricks
2002-02-03 12:04     ` Benjamin Herrenschmidt
2002-02-03 19:02   ` Kevin B. Hendricks
2002-02-03 22:39     ` Timothy A. Seufert
2002-02-04 18:15     ` benh
2002-02-04 18:27       ` Kevin B. Hendricks
2002-02-05 13:23         ` benh
2002-02-04 17:57   ` Kevin B. Hendricks
2002-02-04 18:23     ` benh [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20020204182308.21006@mailhost.mipsys.com \
    --to=benh@kernel.crashing.org \
    --cc=Ed.Swarthout@Motorola.com \
    --cc=kevin.hendricks@sympatico.ca \
    --cc=linuxppc-dev@lists.linuxppc.org \
    --cc=yellowdog-devel@lists.yellowdoglinux.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).