Date:	Thu, 5 Aug 2010 06:21:51 -0700 (PDT)
From:	david@...g.hm
To:	"Rafael J. Wysocki" <rjw@...k.pl>
cc:	Arve Hjønnevåg <arve@...roid.com>,
	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	Arjan van de Ven <arjan@...radead.org>,
	"Ted Ts'o" <tytso@....edu>, linux-pm@...ts.linux-foundation.org,
	linux-kernel <linux-kernel@...r.kernel.org>, mjg59@...f.ucam.org,
	pavel@....cz, florian@...kler.org, stern@...land.harvard.edu,
	swetland@...gle.com, peterz@...radead.org, tglx@...utronix.de,
	alan@...rguk.ukuu.org.uk
Subject: Re: Attempted summary of suspend-blockers LKML thread

On Thu, 5 Aug 2010, Rafael J. Wysocki wrote:

> On Thursday, August 05, 2010, david@...g.hm wrote:
>> On Thu, 5 Aug 2010, Rafael J. Wysocki wrote:
>>
>>> On Thursday, August 05, 2010, david@...g.hm wrote:
>>>> On Wed, 4 Aug 2010, Rafael J. Wysocki wrote:
>>>>
>>>>> Subject: Re: Attempted summary of suspend-blockers LKML thread
>>>>>
>>>>> On Wednesday, August 04, 2010, david@...g.hm wrote:
>>>>>> On Wed, 4 Aug 2010, Rafael J. Wysocki wrote:
>>>>>>> In the suspend case, when you have frozen all applications, you can
>>>>>>> sequentially disable all interrupts except for a few selected ("wakeup") ones
>>>>>>> in a safe way.   By disabling them, you ensure that the CPU will only be
>>>>>>> "revived" by a limited set of events and that allows the system to stay
>>>>>>> low-power for extended time intervals.
>>>>>>
>>>>>> the benifit of this will depend on what wakeups you are able to avoid by
>>>>>> putting the hardware to sleep. Depending on the hardware, this may be not
>>>>>> matter that much.
>>>>>
>>>>> That's correct, but evidently it does make a difference with the hardware
>>>>> Android commonly runs on.
>>>>
>>>> Ok, but is there a way to put some of this to sleep without involving a
>>>> full suspend?
>>>
>>> Technically, maybe, but we have no generic infrastructure in the kernel for that.
>>> There may be SoC-specific implementations, but nothing general enough.
>>
>> well, I know that we have specific cases of this (drive spin-down, cpu
>> speed, display backlight for a few examples), is it worth trying to define
>> a generic way to do this sort of thing? or should it be left as a
>> per-device thing (with per-device knobs to control it)
>
> The ability to put specific devices into low-power states in certain
> well-defined situations is clearly not sufficient.  For one example, usually
> you can easily put an Ethernet adapter into a low-power state when the network
> cable is detached from it.  It is not clear, however, what criteria should be
> used for deciding to put that adapter into the low-power state when the cable
> is attached to it (and open() has been called).
>
> To mimic suspend you'll have to be able to put _all_ devices into low-power
> states and shut down the interrupts that allow the monotonic clock to advance.
> That's much more than simple runtime power management of selected devices.

true for the generic case, my thought was that for specially built 
hardware it may be possible to select hardware that lets you get very 
close.

>> I thought I had seen discussion on how to define such a generic power
>> management interface, and I thought the results had been acceptable.
>
> If you have a pointer to that discussion, I'm interested. :-)

sorry, it was several months ago.

David Lang
--
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