[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <878w7zog3e.fsf@deeprootsystems.com>
Date: Tue, 04 May 2010 08:13:09 -0700
From: Kevin Hilman <khilman@...prootsystems.com>
To: Matthew Garrett <mjg@...hat.com>
Cc: "Rafael J. Wysocki" <rjw@...k.pl>,
Mark Brown <broonie@...nsource.wolfsonmicro.com>,
Arve Hjønnevåg <arve@...roid.com>,
linux-pm@...ts.linux-foundation.org, linux-kernel@...r.kernel.org,
Alan Stern <stern@...land.harvard.edu>,
Tejun Heo <tj@...nel.org>, Oleg Nesterov <oleg@...hat.com>,
Paul Walmsley <paul@...an.com>, magnus.damm@...il.com,
mark gross <mgross@...ux.intel.com>,
Arjan van de Ven <arjan@...radead.org>,
Geoff Smith <geoffx.smith@...el.com>
Subject: Re: [PATCH 0/8] Suspend block api (version 6)
Matthew Garrett <mjg@...hat.com> writes:
> On Mon, May 03, 2010 at 04:37:22PM -0700, Kevin Hilman wrote:
>
>> Please forgive the ignorance of ACPI (in embedded, we thankfully live
>> in magical world without ACPI) but doesn't that already happen with
>> CPUidle and C-states? I think of CPUidle as basically runtime PM for
>> the CPU. IOW, runtime PM manages the devices, CPUidle manages the CPU
>> (via C-states), resulting in dynaimc PM for the entire system. What
>> am I missing?
>
> ACPI doesn't provide any functionality for cutting power to most
> devices other than shifting into full system suspend. The number of
> wakeup events available to us on a given machine is usually small
> and the wakeup latency large, so it's not terribly practical to do
> this transparently on most hardware.
OK, that's a major difference with embedded SoCs where the kernel must
directly manage the power state of all devices using runtime PM.
So basically, on ACPI systems, runtime PM doesn't get you any power
savings for most devices.
Kevin
--
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