From: Len Brown <len.brown-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
To: Pavel Machek <pavel-+ZI9xUNit7I@public.gmane.org>
Cc: Linus Torvalds <torvalds-3NddpPZAyC0@public.gmane.org>,
Kernel Mailing List
<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
ACPI Developers
<acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org>
Subject: Re: [BKPATCH] ACPI for 2.6
Date: 01 Dec 2004 18:13:48 -0500 [thread overview]
Message-ID: <1101942828.8028.371.camel@d845pe> (raw)
In-Reply-To: <20041112174248.GA4267-u08AdweFZfgxtPtxi4kahqVXKuFTiq87@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 976 bytes --]
On Fri, 2004-11-12 at 12:42, Pavel Machek wrote:
> > <len.brown-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> (04/11/05 1.1803.163.1)
> > [ACPI] Allow limiting idle C-States.
> >
> > Useful to workaround C3 ipw2100 packet loss,
> > reducing noise or boot issues on some models.
> > http://bugme.osdl.org/show_bug.cgi?id=3549
> >
> > For static processor driver, boot cmdline:
> > processor.acpi_cstate_limit=2
>
> You certainly win "ugliest parameter of the month" contest :-).
>
> What about processor.max_cstate= or something?
I agree, this is better.
> > <len.brown-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> (04/10/18 1.1803.119.24)
> > [ACPI] add module parameters: processor.c2=[0,1]
> processor.c3=[0,1]
> > to disable/enable C2 or C3
> > blacklist entries for R40e and Medion 41700
>
> So we have two independend ways to disable C states?
With the addition of the dynamic method, the
static method can go away. patch attached.
-Len
[-- Attachment #2: max_cstate.patch --]
[-- Type: text/plain, Size: 7092 bytes --]
===== Documentation/kernel-parameters.txt 1.51 vs edited =====
--- 1.51/Documentation/kernel-parameters.txt 2004-11-10 15:50:17 -05:00
+++ edited/Documentation/kernel-parameters.txt 2004-12-01 18:11:18 -05:00
@@ -960,10 +960,9 @@
(param: profile step/bucket size as a power of 2 for
statistical time based profiling)
- processor.c2= [HW, ACPI]
- processor.c3= [HW, ACPI]
- 0 - disable C2 or C3 idle power saving state.
- 1 - enable C2 or C3 (default unless DMI blacklist entry)
+ processor.max_cstate= [HW, ACPI]
+ Limit processor to maximum C-state
+ max_cstate=9 overrides any DMI blacklist limit.
prompt_ramdisk= [RAM] List of RAM disks to prompt for floppy disk
before loading.
===== drivers/acpi/osl.c 1.59 vs edited =====
--- 1.59/drivers/acpi/osl.c 2004-11-12 00:25:31 -05:00
+++ edited/drivers/acpi/osl.c 2004-12-01 14:36:24 -05:00
@@ -1152,10 +1152,10 @@
__setup("acpi_wake_gpes_always_on", acpi_wake_gpes_always_on_setup);
/*
- * acpi_cstate_limit is defined in the base kernel so modules can
+ * max_cstate is defined in the base kernel so modules can
* change it w/o depending on the state of the processor module.
*/
-unsigned int acpi_cstate_limit = ACPI_C_STATES_MAX;
+unsigned int max_cstate = ACPI_C_STATES_MAX;
-EXPORT_SYMBOL(acpi_cstate_limit);
+EXPORT_SYMBOL(max_cstate);
===== drivers/acpi/processor.c 1.63 vs edited =====
--- 1.63/drivers/acpi/processor.c 2004-11-10 15:40:29 -05:00
+++ edited/drivers/acpi/processor.c 2004-12-01 18:06:51 -05:00
@@ -101,8 +101,6 @@
},
};
-static int c2 = -1;
-static int c3 = -1;
struct acpi_processor_errata {
u8 smp;
@@ -144,8 +142,6 @@
static struct acpi_processor *processors[NR_CPUS];
static struct acpi_processor_errata errata;
-module_param_named(c2, c2, bool, 0);
-module_param_named(c3, c3, bool, 0);
static void (*pm_idle_save)(void);
@@ -338,8 +334,8 @@
{
struct acpi_processor *pr = NULL;
struct acpi_processor_cx *cx = NULL;
- int next_state = 0;
- int sleep_ticks = 0;
+ unsigned int next_state = 0;
+ unsigned int sleep_ticks = 0;
u32 t1, t2 = 0;
pr = processors[smp_processor_id()];
@@ -475,9 +471,9 @@
* Track the number of longs (time asleep is greater than threshold)
* and promote when the count threshold is reached. Note that bus
* mastering activity may prevent promotions.
- * Do not promote above acpi_cstate_limit.
+ * Do not promote above max_cstate.
*/
- if (cx->promotion.state && (cx->promotion.state <= acpi_cstate_limit)) {
+ if (cx->promotion.state && (cx->promotion.state <= max_cstate)) {
if (sleep_ticks > cx->promotion.threshold.ticks) {
cx->promotion.count++;
cx->demotion.count = 0;
@@ -515,10 +511,10 @@
end:
/*
- * Demote if current state exceeds acpi_cstate_limit
+ * Demote if current state exceeds max_cstate
*/
- if (pr->power.state > acpi_cstate_limit) {
- next_state = acpi_cstate_limit;
+ if (pr->power.state > max_cstate) {
+ next_state = max_cstate;
}
/*
@@ -672,11 +668,6 @@
else if (errata.smp)
ACPI_DEBUG_PRINT((ACPI_DB_INFO,
"C2 not supported in SMP mode\n"));
-
-
- else if (!c2)
- printk(KERN_INFO "C2 disabled\n");
-
/*
* Otherwise we've met all of our C2 requirements.
* Normalize the C2 latency to expidite policy.
@@ -732,9 +723,6 @@
ACPI_DEBUG_PRINT((ACPI_DB_INFO,
"C3 not supported on PIIX4 with Type-F DMA\n"));
}
- else if (!c3)
- printk(KERN_INFO "C3 disabled\n");
-
/*
* Otherwise we've met all of our C3 requirements.
* Normalize the C2 latency to expidite policy. Enable
@@ -995,7 +983,7 @@
struct acpi_buffer format = {sizeof("NNNNNN"), "NNNNNN"};
struct acpi_buffer state = {0, NULL};
union acpi_object *pss = NULL;
- int i = 0;
+ unsigned int i;
ACPI_FUNCTION_TRACE("acpi_processor_get_performance_states");
@@ -1117,7 +1105,7 @@
static int acpi_processor_perf_seq_show(struct seq_file *seq, void *offset)
{
struct acpi_processor *pr = (struct acpi_processor *)seq->private;
- int i = 0;
+ unsigned int i;
ACPI_FUNCTION_TRACE("acpi_processor_perf_seq_show");
@@ -1880,7 +1868,7 @@
static int acpi_processor_power_seq_show(struct seq_file *seq, void *offset)
{
struct acpi_processor *pr = (struct acpi_processor *)seq->private;
- int i = 0;
+ unsigned int i;
ACPI_FUNCTION_TRACE("acpi_processor_power_seq_show");
@@ -1889,9 +1877,11 @@
seq_printf(seq, "active state: C%d\n"
"default state: C%d\n"
+ "max_cstate: C%d\n"
"bus master activity: %08x\n",
pr->power.state,
pr->power.default_state,
+ max_cstate,
pr->power.bm_activity);
seq_puts(seq, "states:\n");
@@ -2478,17 +2468,22 @@
return_VALUE(0);
}
-/* IBM ThinkPad R40e crashes mysteriously when going into C2 or C3.
- For now disable this. Probably a bug somewhere else. */
+/*
+ * IBM ThinkPad R40e crashes mysteriously when going into C2 or C3.
+ * For now disable this. Probably a bug somewhere else.
+ *
+ * To skip this limit, boot/load with a large max_cstate limit.
+ */
static int no_c2c3(struct dmi_system_id *id)
{
- printk(KERN_INFO
- "%s detected - C2,C3 disabled. Overwrite with \"processor.c2=1 processor.c3=1\n\"",
- id->ident);
- if (c2 == -1)
- c2 = 0;
- if (c3 == -1)
- c3 = 0;
+ if (max_cstate > ACPI_C_STATES_MAX)
+ return 0;
+
+ printk(KERN_NOTICE PREFIX "%s detected - C2,C3 disabled."
+ " Override with \"processor.max_cstate=9\"\n", id->ident);
+
+ max_cstate = 1;
+
return 0;
}
@@ -2533,6 +2528,9 @@
dmi_check_system(processor_dmi_table);
+ if (max_cstate < ACPI_C_STATES_MAX)
+ printk(KERN_NOTICE "ACPI: processor limited to max C-state %d\n", max_cstate);
+
return_VALUE(0);
}
@@ -2556,6 +2554,6 @@
module_init(acpi_processor_init);
module_exit(acpi_processor_exit);
-module_param_named(acpi_cstate_limit, acpi_cstate_limit, uint, 0);
+module_param_named(max_cstate, max_cstate, uint, 0);
EXPORT_SYMBOL(acpi_processor_set_thermal_limit);
===== include/acpi/processor.h 1.8 vs edited =====
--- 1.8/include/acpi/processor.h 2004-01-29 04:57:52 -05:00
+++ edited/include/acpi/processor.h 2004-12-01 17:45:39 -05:00
@@ -17,7 +17,7 @@
struct acpi_processor_cx_policy {
u32 count;
- int state;
+ u32 state;
struct {
u32 time;
u32 ticks;
@@ -38,8 +38,8 @@
};
struct acpi_processor_power {
- int state;
- int default_state;
+ u32 state;
+ u32 default_state;
u32 bm_activity;
struct acpi_processor_cx states[ACPI_PROCESSOR_MAX_POWER];
};
===== include/linux/acpi.h 1.39 vs edited =====
--- 1.39/include/linux/acpi.h 2004-11-05 21:42:25 -05:00
+++ edited/include/linux/acpi.h 2004-12-01 14:36:25 -05:00
@@ -483,15 +483,15 @@
* 2: C2 okay, but not C3 etc.
*/
-extern unsigned int acpi_cstate_limit;
+extern unsigned int max_cstate;
static inline unsigned int acpi_get_cstate_limit(void)
{
- return acpi_cstate_limit;
+ return max_cstate;
}
static inline void acpi_set_cstate_limit(unsigned int new_limit)
{
- acpi_cstate_limit = new_limit;
+ max_cstate = new_limit;
return;
}
#else
next prev parent reply other threads:[~2004-12-01 23:13 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-11-09 7:47 [BKPATCH] ACPI for 2.6 Len Brown
2004-11-12 17:42 ` Pavel Machek
2004-11-12 18:18 ` Hiroshi Itoh
[not found] ` <20041112174248.GA4267-u08AdweFZfgxtPtxi4kahqVXKuFTiq87@public.gmane.org>
2004-12-01 23:13 ` Len Brown [this message]
-- strict thread matches above, loose matches on Subject: below --
2004-10-09 5:54 Len Brown
2004-08-14 6:55 Len Brown
2004-08-14 20:56 ` Jesse Barnes
2004-06-21 19:41 Len Brown
[not found] <E1BbPIM-00044a-0A@sc8-sf-list2.sourceforge.net>
[not found] ` <E1BbPIM-00044a-0A-ek0oC1U1TqqnvZpeIfgr/KQD96bmaF075NbjCUgZEJk@public.gmane.org>
2004-06-19 21:22 ` Carsten Rietzschel
2004-06-18 6:42 Len Brown
[not found] ` <1087540933.4487.212.camel-D2Zvc0uNKG8@public.gmane.org>
2004-06-23 13:47 ` Stefan Seyfried
2004-05-20 19:12 Len Brown
2004-05-11 16:48 Len Brown
2004-05-03 16:52 Len Brown
2004-04-01 10:40 Len Brown
2004-03-30 1:26 Manpreet Singh
2004-03-30 0:28 Manpreet Singh
2004-03-29 17:32 Moore, Robert
2004-03-27 9:18 Manpreet Singh
2004-03-27 0:59 Len Brown
[not found] ` <1080349151.16211.33.camel-D2Zvc0uNKG8@public.gmane.org>
2004-03-27 11:11 ` Marcel Holtmann
2004-03-23 10:02 Len Brown
2004-03-14 6:08 Len Brown
2004-03-06 6:37 Len Brown
2004-02-25 9:18 Len Brown
2004-02-14 4:46 Len Brown
2004-02-07 9:10 Len Brown
[not found] ` <1076145027.8682.34.camel-D2Zvc0uNKG8@public.gmane.org>
2004-02-09 9:09 ` Olaf Hering
2004-02-09 9:11 ` Olaf Hering
2004-01-27 6:03 Len Brown
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=1101942828.8028.371.camel@d845pe \
--to=len.brown-ral2jqcrhueavxtiumwx3w@public.gmane.org \
--cc=acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=pavel-+ZI9xUNit7I@public.gmane.org \
--cc=torvalds-3NddpPZAyC0@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox