[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100525124325.GC7876@srcf.ucam.org>
Date: Tue, 25 May 2010 13:43:25 +0100
From: Matthew Garrett <mjg59@...f.ucam.org>
To: "Yu, Luming" <luming.yu@...el.com>
Cc: Len Brown <lenb@...nel.org>, Philip Langdale <philipl@...rt.org>,
Jeff Garrett <jeff@...rrett.org>,
Andi Kleen <andi@...stfloor.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
"linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
"venki@...gle.com" <venki@...gle.com>
Subject: Re: acpi_idle: Very idle Core i7 machine never enters C3
On the other hand, the relevant section of spec is:
"OSPM uses the BM_STS bit to determine the power state to enter when
considering a transition to or from the C2/C3 power state. The BM_STS is
an optional bit that indicates when bus masters are active. OSPM uses
this bit to determine the policy between the C2 and C3 power states: a
lot of bus master activity demotes the CPU power state to the C2 (or C1
if C2 is not supported), no bus master activity promotes the CPU power
state to the C3 power state. OSPM keeps a running history of the BM_STS
bit to determine CPU power state policy."
while the description of the bit itself is:
"This is the bus master status bit. This bit is set any time a system
bus master requests the system bus, and can only be cleared by writing a
“1” to this bit position. Notice that this bit reflects bus master
activity, not CPU activity (this bit monitors any bus master that can
cause an incoherent cache for a processor in the C3 state when the bus
master performs a memory transaction)."
which implies that as long as you don't have any cache coherency
concerns, it's acceptable (if potentially suboptimal) to enter C3 even
if the bit is set.
--
Matthew Garrett | mjg59@...f.ucam.org
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists