All of lore.kernel.org
 help / color / mirror / Atom feed
From: Cort Dougan <cort@fsmlabs.com>
To: Matthew Locke <mlocke@mvista.com>
Cc: akuster <akuster@dslextreme.com>,
	linuxppc-dev <linuxppc-dev@lists.linuxppc.org>
Subject: Re: [RFC/Patch] 4xx idle loop
Date: Thu, 25 Jul 2002 10:53:36 -0600	[thread overview]
Message-ID: <20020725105336.F2276@host110.fsmlabs.com> (raw)
In-Reply-To: <3D402C79.5020808@mvista.com>; from mlocke@mvista.com on Thu, Jul 25, 2002 at 09:51:05AM -0700


I can only think of three ifdef's that would be necessary now but it could
grow.  If the #ifdef snarl is unattractive in idle.c it's easy enough to
move it to chipfamily-specific headers so that idle.c just needs to call
arch_idle() to enter an idle state.

The function pointer isn't desirable.  What the correct strategy for power
saving is known at compile time so there shouldn't be a function pointer
dereference.  How the #ifdef's are done doesn't really matter as long as
the inefficiency of a function pointer is avoided.

} I thought one of the linuxppc desgin goals was to keep the ifdefs to a
} minimum.  I can see idle.c growing quite large and full of #ifdefs if we
} do it that way.  Rather than using ppc_md, make power_save an
} abstraction similar to platform_init.
}
} >
} >
} >} This sounds like a good idea if we could use
} >}   if( ppc_md.powersave != NULL)
} >}        ppc_md.powersave();
} >}
} >} If it is determined that calling power_save() which is resides in an
} >} arch/processor specific file then we are talking about many files being
} >} hit.  and the current power_save seems to common for many other ppc
} >} platforms other than 4xx & 8xx

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

  reply	other threads:[~2002-07-25 16:53 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-07-24  5:55 [RFC/Patch] 4xx idle loop akuster
2002-07-24 19:50 ` Matthew Locke
2002-07-25  5:38   ` akuster
2002-07-25  5:39     ` cort
2002-07-25  6:54       ` cort
2002-07-25 16:51       ` Matthew Locke
2002-07-25 16:53         ` Cort Dougan [this message]
2002-07-25 16:20           ` Benjamin Herrenschmidt
2002-07-25 17:55             ` Cort Dougan
2002-07-25 18:04             ` Todd Poynor
2002-07-25 19:20             ` Dan Malek
2002-07-27 16:30               ` akuster

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=20020725105336.F2276@host110.fsmlabs.com \
    --to=cort@fsmlabs.com \
    --cc=akuster@dslextreme.com \
    --cc=linuxppc-dev@lists.linuxppc.org \
    --cc=mlocke@mvista.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 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.