From: Tom Rini <trini@kernel.crashing.org>
To: Dan Malek <dan@embeddededge.com>
Cc: linuxppc-dev <linuxppc-dev@lists.linuxppc.org>
Subject: Re: [RFC/PATCH] idle loop changes
Date: Wed, 31 Jul 2002 13:38:10 -0700 [thread overview]
Message-ID: <20020731203810.GE17472@opus.bloom.county> (raw)
In-Reply-To: <3D4847D5.9030404@embeddededge.com>
On Wed, Jul 31, 2002 at 04:25:57PM -0400, Dan Malek wrote:
> Tom Rini wrote:
>
> >I'm not totally sure if it's better to do it this way, or to not provide
> >a default power_save(), so that if we don't set pm_idle to something, we
> >just never call power_save() (as opposed to a call, check for a bit &
> >return). Comments?
>
> I think whether we force everything to have a power_save() function,
> even if it is empty, or initialize a pointer and have an indirect call
> doesn't make much difference. What does make a difference, is there could
> be power save functions that are unique to a board. Some processors have
> power save options that can cause a lower frequency clock to be used which
> will affect external devices. In such cases, the devices on a board may
> need some adjustment when these power save modes are entered/exited.
Well, this gets us part of the way there. This allows for the
power_save() functionalility to be totally overridden. For things such
as modifiying the clock, which may require additional device changes, I
think that falls in as another problem, but this should allow for that
problem to be taken care of.
--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
next prev parent reply other threads:[~2002-07-31 20:38 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-07-31 19:32 [RFC/PATCH] idle loop changes Tom Rini
2002-07-31 20:25 ` Dan Malek
2002-07-31 20:38 ` Tom Rini [this message]
2002-07-31 20:41 ` Tom Rini
2002-07-31 21:33 ` Matt Porter
2002-07-31 21:29 ` Dan Malek
2002-07-31 21:48 ` Mark A. Greer
2002-07-31 22:23 ` Dan Malek
2002-08-01 0:11 ` Tom Rini
2002-07-31 21:24 ` Matt Porter
2002-08-01 0:09 ` Tom Rini
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=20020731203810.GE17472@opus.bloom.county \
--to=trini@kernel.crashing.org \
--cc=dan@embeddededge.com \
--cc=linuxppc-dev@lists.linuxppc.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.