From: Jos Delbar <jos.delbar-Cru1EgDzd7c@public.gmane.org>
To: Len Brown <len.brown-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Cc: ACPI Developers
<acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org>,
Robert Moore
<robert.moore-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
James P Ketrenos
<james.p.ketrenos-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Subject: Re: Linux ACPI processor driver patch: user-definable power state limit
Date: Sat, 6 Nov 2004 00:21:49 +0100 [thread overview]
Message-ID: <200411060021.49794.jos.delbar@ugent.be> (raw)
In-Reply-To: <1099683907.13837.1353.camel@d845pe>
Hey,
To allow modifying the C state limit on the fly, I think we might need to use
a combination of both schemes.
In Andi Kleen's patch the C state is "permanently" disabled in
acpi_processor_get_power_info() and this is probably the best way to go for
the blacklist. However, when another module needs to limit the processor to a
certain C state, I think it would be best to handle this in
acpi_processor_set_power_policy(). This seems to make the most sense
semantically: you can change the power management policy at runtime, not the
actual capabilities of the processor.
Also, if you have both a blacklist and an option to change the limit at
runtime, there has to be some logic to prevent a module from lifting a limit
imposed by the blacklist.
Your patch just came in while I was writing this, I'll be sure to try it later
today. I'm not sure if the idle handler should be concerned with handling the
limit though, but it does make the code simpler.
Regards,
- Jos
On Friday 05 November 2004 20:45, Len Brown wrote:
> Jos,
> I agree with you that a single parameter is simpler.
>
> Another thing we need to address -- with either scheme --
> is that the parameter must be set in the kernel, not
> in the processor modules.
>
> This is because it is necessary for modules, such as ipw2100
> to be able to disable c3 automatically when they detect
> that it is interfering with their operation.
>
> so we'd export a function from the base kernel for
> modules to set the limit, and we'd simply export
> the value of acpi_cstate_limit for processor.c
> to observe at run-time.
>
> int
> acpi_set_cstate_limit(int limit)
>
> int acpi_cstate_limit;
>
> I think it can return the old limit so that
> the caller can potentially un-do its call,
> or perhaps setting the limit to 0 should
> simply mean clear any limit.
>
> cheers,
> -Len
--
Jos Delbar
jos.delbar-Cru1EgDzd7c@public.gmane.org
-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
next prev parent reply other threads:[~2004-11-05 23:21 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-10-10 16:56 Linux ACPI processor driver patch: user-definable power state limit Brown, Len
[not found] ` <F7DC2337C7631D4386A2DF6E8FB22B3001A193B6-N2PTB0HCzHKkrb+BlOpmy7fspsVTdybXVpNB7YpNyf8@public.gmane.org>
2004-10-11 21:35 ` Jos Delbar
[not found] ` <200410112335.19159.jos.delbar-Cru1EgDzd7c@public.gmane.org>
2004-10-19 17:19 ` Len Brown
2004-11-05 19:45 ` Len Brown
2004-11-05 22:54 ` Dominik Brodowski
[not found] ` <20041105225438.GA8262-X3ehHDuj6sIIGcDfoQAp7BvVK+yQ3ZXh@public.gmane.org>
2004-11-05 23:11 ` Len Brown
2004-11-05 23:41 ` Dominik Brodowski
[not found] ` <20041105234120.GA20761-X3ehHDuj6sIIGcDfoQAp7BvVK+yQ3ZXh@public.gmane.org>
2004-11-06 0:25 ` Len Brown
2004-11-06 0:29 ` Dominik Brodowski
[not found] ` <20041106002935.GA30467-X3ehHDuj6sIIGcDfoQAp7BvVK+yQ3ZXh@public.gmane.org>
2004-11-06 0:44 ` Len Brown
2004-11-06 13:15 ` Jos Delbar
2004-11-05 23:54 ` Dominik Brodowski
[not found] ` <20041105235403.GA21880-X3ehHDuj6sIIGcDfoQAp7BvVK+yQ3ZXh@public.gmane.org>
2004-11-06 0:33 ` Len Brown
2004-11-05 23:39 ` Jos Delbar
[not found] ` <200411060039.28067.jos.delbar-Cru1EgDzd7c@public.gmane.org>
2004-11-05 23:55 ` Dominik Brodowski
2004-11-05 22:58 ` Len Brown
2004-11-05 23:21 ` Jos Delbar [this message]
[not found] ` <200411060021.49794.jos.delbar-Cru1EgDzd7c@public.gmane.org>
2004-11-06 1:01 ` Len Brown
2004-11-06 2:59 ` Len Brown
[not found] <200408071959.10529.jos.delbar@ugent.be>
[not found] ` <200408071959.10529.jos.delbar-Cru1EgDzd7c@public.gmane.org>
2004-10-09 5:52 ` Len Brown
2004-10-10 14:36 ` Jos Delbar
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=200411060021.49794.jos.delbar@ugent.be \
--to=jos.delbar-cru1egdzd7c@public.gmane.org \
--cc=acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org \
--cc=james.p.ketrenos-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \
--cc=len.brown-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \
--cc=robert.moore-ral2JQCrhuEAvxtiuMwx3w@public.gmane.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.