Hi!
> > So for people who really care about running a mainline kernel on their
> > android device doing that part first on a generic ARM board in qemu
> > might be much better first step work.
>
> > On the other hand I've heard
> > that various hardware vendors or parties closed to them are rath
On Fri, Jun 11, 2010 at 04:48:15PM -0400, Alan Stern wrote:
> On Fri, 11 Jun 2010, Mark Brown wrote:
> > The clock framework is implemented independantly for each CPU.
> That's not an impediment, since drivers' requirements regarding which
> clocks remain running in which power states are necess
On Fri, 11 Jun 2010, Arve Hjønnevåg wrote:
> > Wait a second. Maybe I have misunderstood how timeouts are supposed to
> > work with wakelocks. I thought the idea was that the wakelock would be
> > released when the timeout expires or the event queue is emptied,
>
> That is one way to use it, an
--- On Fri, 6/11/10, James Bottomley wrote:
> > Do we at least have a clean way that a driver can
> > reject a system suspend? I've lost track of
> many
> > issues, but maybe this could be phrased as a QOS
> > constraint: the current config of driver X
> needs
> > clock Y active to enter the
2010/6/11 Alan Stern :
> On Thu, 10 Jun 2010, Arve Hjønnevåg wrote:
>
>> > You've lost me. If the power manager is sitting inside a select/poll,
>> > how can it miss the event (given that the event will make data
>> > available to be read on one of the descriptors being polled)?
>> >
>>
>> It cann
On Fri, 2010-06-11 at 16:48 -0400, Alan Stern wrote:
> On Fri, 11 Jun 2010, Mark Brown wrote:
>
> > On Fri, Jun 11, 2010 at 10:46:27AM -0400, Alan Stern wrote:
> > > On Fri, 11 Jun 2010, James Bottomley wrote:
> >
> > > > The one thing that does look difficult is that these power constraints
> >
On Fri, 11 Jun 2010, Mark Brown wrote:
> On Fri, Jun 11, 2010 at 10:46:27AM -0400, Alan Stern wrote:
> > On Fri, 11 Jun 2010, James Bottomley wrote:
>
> > > The one thing that does look difficult is that these power constraints
> > > are device (and sometimes SoC) specific. Expressing them in a
On Fri, 2010-06-11 at 10:46 -0400, Alan Stern wrote:
> On Fri, 11 Jun 2010, James Bottomley wrote:
>
> > On Thu, 2010-06-10 at 21:21 -0700, David Brownell wrote:
> > > Do we at least have a clean way that a driver can
> > > reject a system suspend? I've lost track of many
> > > issues, but maybe
On Fri, Jun 11, 2010 at 10:46:27AM -0400, Alan Stern wrote:
> On Fri, 11 Jun 2010, James Bottomley wrote:
> > The one thing that does look difficult is that these power constraints
> > are device (and sometimes SoC) specific. Expressing them in a generic
> > way for the cpu govenors to make sense
On Fri, 11 Jun 2010, James Bottomley wrote:
> On Thu, 2010-06-10 at 21:21 -0700, David Brownell wrote:
> > Do we at least have a clean way that a driver can
> > reject a system suspend? I've lost track of many
> > issues, but maybe this could be phrased as a QOS
> > constraint: the current confi
On Thu, 10 Jun 2010, David Brownell wrote:
> This is a bit off the topic of Android
> flamage, but I thought it would be worth
> highlighting an example where the current
> frameworks may still have a deficiency...
> one that likewise relates to needing to
> block entry ot a system suspend state,
On Thu, 10 Jun 2010, Arve Hjønnevåg wrote:
> > You've lost me. If the power manager is sitting inside a select/poll,
> > how can it miss the event (given that the event will make data
> > available to be read on one of the descriptors being polled)?
> >
>
> It cannot sit inside of select/poll al
On Thu, 2010-06-10 at 21:21 -0700, David Brownell wrote:
> Do we at least have a clean way that a driver can
> reject a system suspend? I've lost track of many
> issues, but maybe this could be phrased as a QOS
> constraint: the current config of driver X needs
> clock Y active to enter the targ
This is a bit off the topic of Android
flamage, but I thought it would be worth
highlighting an example where the current
frameworks may still have a deficiency...
one that likewise relates to needing to
block entry ot a system suspend state, but
in this case user-space isn't very involved
(just dr
2010/6/10 Alan Stern :
> On Thu, 10 Jun 2010, Arve Hjønnevåg wrote:
>
>> >> For that to work the wakeup events would have to be reported to the
>> >> power manager in a reliable way in the first place. Passing the file
>> >> descriptor that the app uses to the power manager does not work for
>> >>
On Thu, 10 Jun 2010, Arve Hjønnevåg wrote:
> >> For that to work the wakeup events would have to be reported to the
> >> power manager in a reliable way in the first place. Passing the file
> >> descriptor that the app uses to the power manager does not work for
> >> this, since the app could read
2010/6/10 Alan Stern :
> On Wed, 9 Jun 2010, Arve Hjønnevåg wrote:
>
>> > I think this is where you misunderstood. There is no "report wakeup
>> > event" as such. All that happens is that data becomes available to be
>> > read from the input device file. However the power manager process
>> > is
On Thu, Jun 10, 2010 at 05:46:46PM +0200, Rafael J. Wysocki wrote:
> On Thursday, June 10, 2010, Mark Brown wrote:
> > On Thu, Jun 10, 2010 at 10:59:43AM +0200, Rafael J. Wysocki wrote:
> > > So, for a phone-like system, where you'd generally want to simplify user
> > > space,
> > > having a "pow
On Thursday, June 10, 2010, Neil Brown wrote:
> On Thu, 10 Jun 2010 10:59:43 +0200
> "Rafael J. Wysocki" wrote:
>
> > On Thursday, June 10, 2010, Neil Brown wrote:
> > > On Wed, 9 Jun 2010 11:40:27 +0200
> > > "Rafael J. Wysocki" wrote:
> > >
> > > > On Wednesday 09 June 2010, Felipe Contreras
On Thursday, June 10, 2010, Mark Brown wrote:
> On Thu, Jun 10, 2010 at 10:59:43AM +0200, Rafael J. Wysocki wrote:
>
> > So, for a phone-like system, where you'd generally want to simplify user
> > space,
> > having a "power manager" in the kernel seems to make sense to me.
>
> I'm not clear whe
On Thursday, June 10, 2010, Alan Stern wrote:
> On Thu, 10 Jun 2010, Rafael J. Wysocki wrote:
>
> > Moreover, having thought a bit more about the "power manager in user space"
> > concept I'm not sure if it really is that better than the original wakelocks
> > idea. Namely, it only repaces a kern
On Thu, 10 Jun 2010, Rafael J. Wysocki wrote:
> Moreover, having thought a bit more about the "power manager in user space"
> concept I'm not sure if it really is that better than the original wakelocks
> idea. Namely, it only repaces a kernel-based mechanism with a user space
> task doing basica
On Wed, 9 Jun 2010 da...@lang.hm wrote:
> why could the suspend blocker process see all events, but the power
> manager process not see the events?
>
> have the userspace talk to the power manager the way it does to the
> suspend blocker now and what's the difference?
>
> effectivly think s/su
On Wed, 9 Jun 2010, Arve Hjønnevåg wrote:
> > I think this is where you misunderstood. There is no "report wakeup
> > event" as such. All that happens is that data becomes available to be
> > read from the input device file. However the power manager process
> > isn't polling the device file at
Hi!
> >> We started here because it's possibly the only api level change we have --
> >> almost everything else is driver or subarch type work or controversial but
> >> entirely self-contained (like the binder, which I would be shocked to see
> >> ever hit mainline). [...]
> >
> > So why arent tho
On Thu, Jun 10, 2010 at 10:59:43AM +0200, Rafael J. Wysocki wrote:
> So, for a phone-like system, where you'd generally want to simplify user
> space,
> having a "power manager" in the kernel seems to make sense to me.
I'm not clear where this requirement to simplify user space specifically
for
On Thu, 10 Jun 2010 10:59:43 +0200
"Rafael J. Wysocki" wrote:
> On Thursday, June 10, 2010, Neil Brown wrote:
> > On Wed, 9 Jun 2010 11:40:27 +0200
> > "Rafael J. Wysocki" wrote:
> >
> > > On Wednesday 09 June 2010, Felipe Contreras wrote:
> > > > On Wed, Jun 9, 2010 at 6:46 AM, Linus Torvalds
On Thursday, June 10, 2010, Neil Brown wrote:
> On Wed, 9 Jun 2010 11:40:27 +0200
> "Rafael J. Wysocki" wrote:
>
> > On Wednesday 09 June 2010, Felipe Contreras wrote:
> > > On Wed, Jun 9, 2010 at 6:46 AM, Linus Torvalds
> > > wrote:
> > > > On Tue, 8 Jun 2010, da...@lang.hm wrote:
> > > >>
> >
On Wed, 9 Jun 2010 21:51:38 -0700
Arve Hjønnevåg wrote:
> The current user space interface does not require that clients
> register the file descriptors that they get wakeup events from with
> another process.
>
However I believe they *do* register these file descriptors with the kernel,
via so
2010/6/9 :
> On Wed, 9 Jun 2010, Arve Hj?nnev?g wrote:
>
>>
>> The power may not see the event, the process that reads the event will
>> always see it. If the power manager is not in the poll call when the
>> event happens, the process that reads the event can read the event
>> before the power ma
On Wed, 9 Jun 2010, Arve Hj?nnev?g wrote:
The power may not see the event, the process that reads the event will
always see it. If the power manager is not in the poll call when the
event happens, the process that reads the event can read the event
before the power manager calls poll.
All
2010/6/9 Alan Stern :
> On Tue, 8 Jun 2010, Arve Hjønnevåg wrote:
>
>> >> Wakeup event occurs, and the driver:
>> >> - report wakeup event type A
>> >> - queue event for delivery to user-space
>> >
>> > That's not really two distinct steps. Queuing the event for delivery
>> > to userspace involves
On Wed, 9 Jun 2010 11:40:27 +0200
"Rafael J. Wysocki" wrote:
> On Wednesday 09 June 2010, Felipe Contreras wrote:
> > On Wed, Jun 9, 2010 at 6:46 AM, Linus Torvalds
> > wrote:
> > > On Tue, 8 Jun 2010, da...@lang.hm wrote:
> > >>
> > >> having suspend blockers inside the kernel adds significant
On Tue, 8 Jun 2010, Arve Hjønnevåg wrote:
> >> Wakeup event occurs, and the driver:
> >> - report wakeup event type A
> >> - queue event for delivery to user-space
> >
> > That's not really two distinct steps. Queuing the event for delivery
> > to userspace involves waking up any tasks that are w
On Sun, Jun 06, 2010 at 12:58:10PM -0700, Brian Swetland wrote:
> On Sun, Jun 6, 2010 at 12:24 PM, Christoph Hellwig wrote:
> > On the other hand I've heard
> > that various hardware vendors or parties closed to them are rather
> > annoyed by their drivers beeing stuck in the android tree - but t
On Wednesday 09 June 2010, Felipe Contreras wrote:
> On Wed, Jun 9, 2010 at 6:46 AM, Linus Torvalds
> wrote:
> > On Tue, 8 Jun 2010, da...@lang.hm wrote:
> >>
> >> having suspend blockers inside the kernel adds significant complexity, it's
> >> worth it only if the complexity buys you enough. In t
On Wed, Jun 9, 2010 at 6:46 AM, Linus Torvalds
wrote:
> On Tue, 8 Jun 2010, da...@lang.hm wrote:
>>
>> having suspend blockers inside the kernel adds significant complexity, it's
>> worth it only if the complexity buys you enough. In this case the question is
>> if the suspend blockers would exten
On Tue, 8 Jun 2010, da...@lang.hm wrote:
>
> having suspend blockers inside the kernel adds significant complexity, it's
> worth it only if the complexity buys you enough. In this case the question is
> if the suspend blockers would extend the sleep time enough more to matter. As
> per my other
2010/6/8 Alan Stern :
> On Mon, 7 Jun 2010, Arve Hjønnevåg wrote:
>
>> The patch that modifies evdev (posted in this patchset) uses an ioctl
>> to enable the suspend blocker. Not all input devices are used for
>> wakeup events and those don't need to block suspend.
>
> But you do have a 1-1 corresp
On Mon, 7 Jun 2010, Florian Mickler wrote:
On Sun, 6 Jun 2010 04:14:09 -0700 (PDT)
da...@lang.hm wrote:
On Sun, 6 Jun 2010, Florian Mickler wrote:
On Sun, 6 Jun 2010 12:19:08 +0200
Vitaly Wool wrote:
2010/6/6 :
as an example (taken from this thread).
system A needs to wake up to get a
On Mon, 7 Jun 2010, Arve Hjønnevåg wrote:
> The patch that modifies evdev (posted in this patchset) uses an ioctl
> to enable the suspend blocker. Not all input devices are used for
> wakeup events and those don't need to block suspend.
But you do have a 1-1 correspondence, right? That is, the i
On Mon, 7 Jun 2010 20:05:56 -0700
Arve Hjønnevåg wrote:
Hi,
>
> If you read an event that occurred after you blocked the task
> freezing, then tasks will never get frozen again (until more events
> occur). I think my original description was less confusing, but it
> seems you got completely dist
On Tuesday 08 June 2010, Arve Hjønnevåg wrote:
> 2010/6/6 Rafael J. Wysocki :
> > On Sunday 06 June 2010, Arve Hjønnevåg wrote:
...
> If individual processes are frozen, we run into problems that we
> cannot run into if we freeze and thaw all processes.
Not individual processes, but the processes
2010/6/7 Alan Stern :
> On Mon, 7 Jun 2010, Arve Hjønnevåg wrote:
>
>> > It's true that under some exceptional circumstances the system would
>> > never remove a wakeup source from the "active" list and then would
>> > never go idle. But exactly the same problem exists with wakelocks, if
>> > the
On Mon, 7 Jun 2010, Arve Hjønnevåg wrote:
> > It's true that under some exceptional circumstances the system would
> > never remove a wakeup source from the "active" list and then would
> > never go idle. But exactly the same problem exists with wakelocks, if
> > the kernel activates a wakelock a
On Tue, 08 Jun 2010 01:17:13 +0200, Linus Walleij said:
> So I would really like to know from the Android people why the
> binder is in the kernel, after all. Could it *theoretically* be in
> userspace, on top of some unix domain sockets, running as a
> real-time scheduled daemon or whatever, stil
2010/6/7 Alan Stern :
> On Mon, 7 Jun 2010, Arve Hjønnevåg wrote:
>
>> > In fact it's possible to do this with only minimal changes to the
>> > userspace, providing you can specify all your possible hardware wakeup
>> > sources. (On the Android this list probably isn't very large -- I
>> > imagine
On Mon, 7 Jun 2010, Arve Hjønnevåg wrote:
> > Remember that suspend takes place in several phases, the first of which
> > is to freeze tasks. The phases can be controlled individually by the
> > process carrying out a suspend, and there's nothing to prevent you from
> > stopping after the freezer
On Mon, 7 Jun 2010, Arve Hjønnevåg wrote:
> > In fact it's possible to do this with only minimal changes to the
> > userspace, providing you can specify all your possible hardware wakeup
> > sources. (On the Android this list probably isn't very large -- I
> > imagine it includes the keypad, the
On Sun, Jun 6, 2010 at 5:01 PM, Alan Stern wrote:
> On Sun, 6 Jun 2010, Matthew Garrett wrote:
>
>> The difference between idle-based suspend and opportunistic suspend is
>> that the former will continue to wake up for timers and will never be
>> entered if something is using CPU, whereas the latt
On Sun, Jun 6, 2010 at 7:43 AM, Matt Helsley wrote:
> On Sun, Jun 06, 2010 at 12:36:21PM +0200, Thomas Gleixner wrote:
>> On Sat, 5 Jun 2010, Arve Hjønnevåg wrote:
>
>
>
>> > events like input event go though a single thread in our system
>> > process, while other events like network packets (whi
2010/6/6 Rafael J. Wysocki :
> On Sunday 06 June 2010, Arve Hjønnevåg wrote:
>> 2010/6/5 Rafael J. Wysocki :
>> > On Saturday 05 June 2010, Arve Hjønnevåg wrote:
>> >> 2010/6/5 Thomas Gleixner :
>> >> > B1;2005;0cOn Fri, 4 Jun 2010, Arve Hjønnevåg wrote:
> ...
>> >
>> > Arve, we're still learning y
2010/6/6 Alan Stern :
> On Sat, 5 Jun 2010, Alan Stern wrote:
>
>> > If you are referring to the approach that we don't use suspend but
>> > freeze a cgroup instead, this only solves the problem of bad apps. It
>> > does not help pause timers in trusted user space code and in the
>> > kernel, so it
2010/6/6 Thomas Gleixner :
> On Sat, 5 Jun 2010, Arve Hjønnevåg wrote:
>> 2010/6/5 Thomas Gleixner :
>> >
>> > Can you please explain in a consistent way how the application stack
>> > and the underlying framework (which exists according to android docs)
>> > is handling events and how the separati
On Mon, Jun 7, 2010 at 4:17 PM, Linus Walleij
wrote:
>
> So I would really like to know from the Android people why the
> binder is in the kernel, after all. Could it *theoretically* be in
> userspace, on top of some unix domain sockets, running as a
> real-time scheduled daemon or whatever, still
2010/6/6 Thomas Gleixner :
> On Sat, 5 Jun 2010, Arve Hjønnevåg wrote:
>> 2010/6/5 Thomas Gleixner :
>> > On Sat, 5 Jun 2010, Arve Hjønnevåg wrote:
>> >> 2010/6/5 Thomas Gleixner :
>> >> > On Sat, 5 Jun 2010, Arve Hjønnevåg wrote:
>> >> >> >> > That download might take a minute or two, but that's n
2010/6/7 Peter Zijlstra :
> On Sun, 2010-06-06 at 12:58 -0700, Brian Swetland wrote:
>> Somebody will have to broker a deal with the frameworks/apps folks to
>> get rid of the binder. They like it a lot. Of course if somebody
>> built a drop-in replacement for the userspace side that didn't requi
2010/6/5 Alan Stern :
> On Sat, 5 Jun 2010, Arve Hjønnevåg wrote:
>
>> Yes, we can keep all our user space suspend blockers and thaw the
>> frozen cgroup when any suspend blocker is held, but this would
>> eliminate any power advantage that freezing a cgroup has over using
>> suspend to freeze all
--- On Mon, 6/7/10, Peter Zijlstra wrote:
> So what's up with this Binder stuff, from what I can see
> its just
> yet-another-CORBA. Why does it need a kernel part at all,
> can't you
> simply run with a user-space ORB instead?
>
> I really don't get why people keep re-inventing CORBA,
That m
On Sun, 6 Jun 2010 20:01:56 -0400 (EDT)
Alan Stern wrote:
> And since Android can reach essentially the same low-power
> state from idle as from suspend, it appears that they really don't need
> any kernel changes at all.
Well, perhaps a hint to the scheduler to fall through as fast as
possible
On Sun, 2010-06-06 at 12:58 -0700, Brian Swetland wrote:
> Somebody will have to broker a deal with the frameworks/apps folks to
> get rid of the binder. They like it a lot. Of course if somebody
> built a drop-in replacement for the userspace side that didn't require
> a kernel driver, had the s
On Sun, 6 Jun 2010 19:21:49 +0200
Vitaly Wool wrote:
> 2010/6/6 Matthew Garrett :
>
> > Suspend blocks prevent system suspend, not any per-device suspend.
>
> Can you suspend a device which is holding a wake lock?
>
> ~Vitaly
If you look at the suspend blocker patchset, you'll see that the on
On Sun, 6 Jun 2010 04:14:09 -0700 (PDT)
da...@lang.hm wrote:
> On Sun, 6 Jun 2010, Florian Mickler wrote:
>
> > On Sun, 6 Jun 2010 12:19:08 +0200
> > Vitaly Wool wrote:
> >
> >> 2010/6/6 :
> >>
> >>> as an example (taken from this thread).
> >>>
> >>> system A needs to wake up to get a battery
2010/6/6 Matthew Garrett :
> On Sun, Jun 06, 2010 at 07:21:49PM +0200, Vitaly Wool wrote:
>> 2010/6/6 Matthew Garrett :
>>
>> > Suspend blocks prevent system suspend, not any per-device suspend.
>>
>> Can you suspend a device which is holding a wake lock?
>
> Yes. Suspend blocks are orthogonal to r
On Mon, Jun 7, 2010 at 1:03 AM, Christoph Hellwig wrote:
> On Sun, Jun 06, 2010 at 12:58:10PM -0700, Brian Swetland wrote:
>> The group ID stuff works incredibly well for gating device access --
>> we ensure that devices that need access from various processes end up
>> with perms like 0660 root a
On Sun, Jun 06, 2010 at 12:58:10PM -0700, Brian Swetland wrote:
> Somebody will have to broker a deal with the frameworks/apps folks to
> get rid of the binder. They like it a lot. Of course if somebody
> built a drop-in replacement for the userspace side that didn't require
> a kernel driver, ha
On Mon, Jun 07, 2010 at 12:26:55AM +0200, Thomas Gleixner wrote:
> That takes a lot of the bullshit arguments about downstream users
> being hurt out of the discussion. The above problems are way more
> complex to resolve than the suspend blocker details.
>
> That's another prove why we can let th
On Sun, 6 Jun 2010, Matthew Garrett wrote:
> The difference between idle-based suspend and opportunistic suspend is
> that the former will continue to wake up for timers and will never be
> entered if something is using CPU, whereas the latter will be entered
> whenever no suspend blocks are he
Brian,
On Sun, 6 Jun 2010, Brian Swetland wrote:
> On Sun, Jun 6, 2010 at 12:24 PM, Christoph Hellwig wrote:
> >
> > Yes. That's what makes me wonder about some parts of the discussion
> > here. Getting the drivers for one or more of the android plattforms
> > in is not a problem. I'd say it
On Sun, Jun 6, 2010 at 12:24 PM, Christoph Hellwig wrote:
>
> Yes. That's what makes me wonder about some parts of the discussion
> here. Getting the drivers for one or more of the android plattforms
> in is not a problem. I'd say it could have easily been done with the
> manweeks spent arguing
On Sun, 6 Jun 2010, Brian Swetland wrote:
> On Sun, Jun 6, 2010 at 11:04 AM, Thomas Gleixner wrote:
> >>
> >> Right, so the sooner we make it easier for the drivers to use the kernel
> >> as their main repository, the better.
> >
> > Yep, the fastest way is to provide two stub inlines in pm.h and
On Sun, Jun 06, 2010 at 12:15:10PM -0700, Brian Swetland wrote:
> I was shocked when Greg pulled the binder driver and some of the other
> "generic" android drivers into staging, because it was always my
> assumption that nobody upstream would want them. We did get some
> bugfixes for the binder d
On Sun, Jun 6, 2010 at 12:05 PM, Christoph Hellwig wrote:
> On Sun, Jun 06, 2010 at 12:08:34PM -0500, James Bottomley wrote:
>> Well, we sort of tried this when Greg pulled some of them into the
>> staging tree. The problem is that without the annotations, the drivers
>> are still different, and
On Sun, Jun 06, 2010 at 12:08:34PM -0500, James Bottomley wrote:
> Well, we sort of tried this when Greg pulled some of them into the
> staging tree. The problem is that without the annotations, the drivers
> are still different, and patches won't apply, so, unsurprisingly, they
> didn't get impro
On Sunday 06 June 2010, Matthew Garrett wrote:
> On Sun, Jun 06, 2010 at 07:21:49PM +0200, Vitaly Wool wrote:
> > 2010/6/6 Matthew Garrett :
> >
> > > Suspend blocks prevent system suspend, not any per-device suspend.
> >
> > Can you suspend a device which is holding a wake lock?
>
> Yes. Suspen
On Sun, Jun 6, 2010 at 11:04 AM, Thomas Gleixner wrote:
>>
>> Right, so the sooner we make it easier for the drivers to use the kernel
>> as their main repository, the better.
>
> Yep, the fastest way is to provide two stub inlines in pm.h and let
> the driver flood come in.
As mentioned previous
James,
On Sun, 6 Jun 2010, James Bottomley wrote:
> On Sun, 2010-06-06 at 17:46 +0200, Thomas Gleixner wrote:
> > On Sun, 6 Jun 2010, James Bottomley wrote:
> > >
> > > 3. We've lost sight of one of the original goals, which was to
> > > bring the android tree close enough to the ker
On Sun, Jun 06, 2010 at 07:21:49PM +0200, Vitaly Wool wrote:
> 2010/6/6 Matthew Garrett :
>
> > Suspend blocks prevent system suspend, not any per-device suspend.
>
> Can you suspend a device which is holding a wake lock?
Yes. Suspend blocks are orthogonal to runtime PM.
--
Matthew Garrett | m
2010/6/6 Matthew Garrett :
> Suspend blocks prevent system suspend, not any per-device suspend.
Can you suspend a device which is holding a wake lock?
~Vitaly
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More major
On Sun, 2010-06-06 at 17:46 +0200, Thomas Gleixner wrote:
> On Sun, 6 Jun 2010, James Bottomley wrote:
> >
> > 3. We've lost sight of one of the original goals, which was to
> > bring the android tree close enough to the kernel so that the
> > android downstream driver and boar
On Sun, Jun 06, 2010 at 05:47:10PM +0200, Vitaly Wool wrote:
> 2010/6/6 Matthew Garrett :
> > The difference between idle-based suspend and opportunistic suspend is
> > that the former will continue to wake up for timers and will never be
> > entered if something is using CPU, whereas the latter wi
2010/6/6 Matthew Garrett :
> On Sun, Jun 06, 2010 at 05:26:09PM +0200, Vitaly Wool wrote:
>> 2010/6/6 Matthew Garrett :
>> > Holding a suspend blocker is entirely orthogonal to runtime pm. The
>> > "whole kernel" will not be "active" - it can continue to hit the same
>> > low power state in the idl
On Sun, 6 Jun 2010, James Bottomley wrote:
>
> 3. We've lost sight of one of the original goals, which was to
> bring the android tree close enough to the kernel so that the
> android downstream driver and board producers don't have to
> choose between the android kerne
On Sun, Jun 06, 2010 at 05:26:09PM +0200, Vitaly Wool wrote:
> 2010/6/6 Matthew Garrett :
> > Holding a suspend blocker is entirely orthogonal to runtime pm. The
> > "whole kernel" will not be "active" - it can continue to hit the same
> > low power state in the idle loop, and any runtime pm implem
2010/6/6 Matthew Garrett :
> On Sun, Jun 06, 2010 at 12:00:47PM +0200, Vitaly Wool wrote:
>
>> Sure, but my point was, some non-trivial (still kind of natural for a
>> smartphone) activities with the device will prevent it from suspending
>> for quite some time. Even worse, the suspend wakelock wil
On Sun, Jun 06, 2010 at 12:36:21PM +0200, Thomas Gleixner wrote:
> On Sat, 5 Jun 2010, Arve Hjønnevåg wrote:
> > events like input event go though a single thread in our system
> > process, while other events like network packets (which are also
> > wakeup events) goes directly to the app.
If y
On Sun, 2010-06-06 at 12:05 +0100, Alan Cox wrote:
> On Sun, 6 Jun 2010 12:46:01 +0200
> Florian Mickler wrote:
>
> > On Sun, 6 Jun 2010 12:00:47 +0200
> > Vitaly Wool wrote:
> >
> > > Even worse, the suspend wakelock will keep the
> > > whole kernel active, as opposed to powering off unused de
On Sunday 06 June 2010, Arve Hjønnevåg wrote:
> 2010/6/5 Rafael J. Wysocki :
> > On Saturday 05 June 2010, Arve Hjønnevåg wrote:
> >> 2010/6/5 Thomas Gleixner :
> >> > B1;2005;0cOn Fri, 4 Jun 2010, Arve Hjønnevåg wrote:
...
> >
> > Arve, we're still learning you have some more requirements we had n
On Sun, Jun 06, 2010 at 12:05:57PM +0100, Alan Cox wrote:
> On Sun, 6 Jun 2010 12:46:01 +0200
> Florian Mickler wrote:
> > That is not true. While the kernel is not suspended it does
> > runtime pm.
>
> On several of our platforms runtime PM already includes suspend so a
> suspend wakelock does i
On Sun, Jun 06, 2010 at 12:00:47PM +0200, Vitaly Wool wrote:
> Sure, but my point was, some non-trivial (still kind of natural for a
> smartphone) activities with the device will prevent it from suspending
> for quite some time. Even worse, the suspend wakelock will keep the
> whole kernel active,
On Sunday 06 June 2010, Arve Hjønnevåg wrote:
> 2010/6/5 Rafael J. Wysocki :
> > On Sunday 06 June 2010, Arve Hjønnevåg wrote:
> >> 2010/6/5 Rafael J. Wysocki :
> >> > On Saturday 05 June 2010, Arve Hjønnevåg wrote:
> >> >> 2010/6/4 Matt Helsley :
> >> >> > On Fri, Jun 04, 2010 at 05:39:17PM -0700,
On Sun, 6 Jun 2010, Felipe Contreras wrote:
2010/6/6 Arjan van de Ven :
On Sat, 5 Jun 2010 14:26:14 -0700
Arve Hj?nnev?g wrote:
the kernel has a set of infrastructure already to help here (range
timers, with which you can wakeup-limit untrusted userspace crap),
timer slack for legacy backgrou
2010/6/6 Arjan van de Ven :
> On Sat, 5 Jun 2010 14:26:14 -0700
> Arve Hjønnevåg wrote:
>> > the kernel has a set of infrastructure already to help here (range
>> > timers, with which you can wakeup-limit untrusted userspace crap),
>> > timer slack for legacy background timers, etc etc.
>>
>> Rang
On Sun, 6 Jun 2010, Florian Mickler wrote:
On Sun, 6 Jun 2010 12:19:08 +0200
Vitaly Wool wrote:
2010/6/6 :
as an example (taken from this thread).
system A needs to wake up to get a battery reading, store it and go back to
sleep, It does so every 10 seconds. But when it does so it only ru
2010/6/6 :
> On Sun, 6 Jun 2010, Brian Swetland wrote:
> if you could shrink the time awake to 0.01 second per wakeup you would shift
> this all up a category (and avoiding the need to wake everything up to
> service a timer would help do this)
>
> this effort very definantly has diminishing retur
On Sat, 5 Jun 2010, Alan Stern wrote:
> > If you are referring to the approach that we don't use suspend but
> > freeze a cgroup instead, this only solves the problem of bad apps. It
> > does not help pause timers in trusted user space code and in the
> > kernel, so it does not lower our average p
2010/6/6 Florian Mickler :
> Suspend_blockers allow the system to suspend ("mem">/sys/power/state
> suspend), when the userspace decides that the device is not in use.
Sorry. What? Blockers allow the system to suspend?
> So implementing suspend_blockers support does not impact any
> optimization
On Sun, 6 Jun 2010 12:46:01 +0200
Florian Mickler wrote:
> On Sun, 6 Jun 2010 12:00:47 +0200
> Vitaly Wool wrote:
>
> > Even worse, the suspend wakelock will keep the
> > whole kernel active, as opposed to powering off unused devices
> > separately as it's done in runtime PM.
>
> That is not
On Sat, 5 Jun 2010, Arve Hjønnevåg wrote:
> 2010/6/5 Thomas Gleixner :
> >
> > Can you please explain in a consistent way how the application stack
> > and the underlying framework (which exists according to android docs)
> > is handling events and how the separation of trust level works ?
> >
>
>
On Sun, 6 Jun 2010 12:19:08 +0200
Vitaly Wool wrote:
> 2010/6/6 :
>
> > as an example (taken from this thread).
> >
> > system A needs to wake up to get a battery reading, store it and go back to
> > sleep, It does so every 10 seconds. But when it does so it only runs the one
> > process and th
1 - 100 of 192 matches
Mail list logo
