Hi!
(ok, so I'm little late to the party).
> > Nonsense, if we want to push the system into suspend from the idle
> > state we can do that. It's just not implemented and we've never tried
> > to do it as it requires a non trivial amount of work, but I have done
> > it on an ARM two years ago as a
On Sat, Jun 5, 2010 at 11:50 PM, Florian Mickler wrote:
> On Sat, 5 Jun 2010 23:06:03 +0300
> Felipe Contreras wrote:
>> How would such stats be calculated? I presume at regular intervals you
>> check which applications are holding suspend blockers and increase a
>> counter.
>>
>> How would you d
On Sat, 5 Jun 2010 22:56:45 +0300
Felipe Contreras wrote:
> On Sat, Jun 5, 2010 at 10:49 PM, Florian Mickler wrote:
> > On Sat, 5 Jun 2010 20:16:33 +0300
> > Felipe Contreras wrote:
> >> New users will see it has low score; they will not install it. That's
> >> a network effect.
> >>
> >> Havin
On Sat, 5 Jun 2010, Florian Mickler wrote:
> On Sat, 5 Jun 2010 23:24:40 +0200 (CEST)
> Thomas Gleixner wrote:
>
> > Stop that advertising campaing already.
>
> Stop advertising that there is no problem.
>
> >
> > No thanks,
> >
> > tglx
>
> Cheers,
> Flo
>
> (Sorry, crossfire. Caused
On Sat, 5 Jun 2010 23:24:40 +0200 (CEST)
Thomas Gleixner wrote:
> Stop that advertising campaing already.
Stop advertising that there is no problem.
>
> No thanks,
>
> tglx
Cheers,
Flo
(Sorry, crossfire. Caused
by you answering in the wrong subthread. I know that you are
engineering
On Sat, 5 Jun 2010, Florian Mickler wrote:
> On Sat, 5 Jun 2010 23:26:27 +0300
> Felipe Contreras wrote:
>
> > Supposing there's a perfect usage of suspend blockers from user-space
> > on current x86 platforms (in theory Android would have that), is the
> > benefit that big to consider this a str
On Sat, 5 Jun 2010 23:26:27 +0300
Felipe Contreras wrote:
> Supposing there's a perfect usage of suspend blockers from user-space
> on current x86 platforms (in theory Android would have that), is the
> benefit that big to consider this a strong argument in favor of
> suspend blockers? Considerin
On Sat, 5 Jun 2010 23:06:03 +0300
Felipe Contreras wrote:
> On Sat, Jun 5, 2010 at 10:56 PM, Florian Mickler wrote:
> > On Sat, 5 Jun 2010 20:30:40 +0300
> > Felipe Contreras wrote:
> >> I don't think the suspend blockers solve much. A bad application will
> >> behave bad on any system. Suppose
On Sat, Jun 5, 2010 at 11:01 PM, Florian Mickler wrote:
> On Sat, 5 Jun 2010 20:44:24 +0300
> Felipe Contreras wrote:
>
>> 2010/6/2 Arve Hjønnevåg :
>> > 2010/6/2 Peter Zijlstra :
>> >> (and please don't mention @#$@ up x86 ACPI again, Intel knows, they're
>> >> fixing it, get over it already).
>
On Sat, Jun 5, 2010 at 10:56 PM, Florian Mickler wrote:
> On Sat, 5 Jun 2010 20:30:40 +0300
> Felipe Contreras wrote:
>> I don't think the suspend blockers solve much. A bad application will
>> behave bad on any system. Suppose somebody decides to port Firefox to
>> Android, and forgets to listen
On Sat, 5 Jun 2010 20:44:24 +0300
Felipe Contreras wrote:
> 2010/6/2 Arve Hjønnevåg :
> > 2010/6/2 Peter Zijlstra :
> >> (and please don't mention @#$@ up x86 ACPI again, Intel knows, they're
> >> fixing it, get over it already).
> >>
> >
> > I don't think it is realistic to drop support for all
On Sat, Jun 5, 2010 at 10:49 PM, Florian Mickler wrote:
> On Sat, 5 Jun 2010 20:16:33 +0300
> Felipe Contreras wrote:
>> New users will see it has low score; they will not install it. That's
>> a network effect.
>>
>> Having users is the quintessential reason people write code.
>
> That is nice.
On Sat, 5 Jun 2010 20:30:40 +0300
Felipe Contreras wrote:
> On Thu, Jun 3, 2010 at 6:28 PM, Peter Zijlstra wrote:
> > On Thu, 2010-06-03 at 16:12 +0200, Florian Mickler wrote:
> >> On Thu, 03 Jun 2010 09:40:02 +0200
> >> Peter Zijlstra wrote:
> >>
> >> > Fix the friggin apps, don't kludge with
On Sat, Jun 5, 2010 at 10:04 PM, Rafael J. Wysocki wrote:
> On Saturday 05 June 2010, Felipe Contreras wrote:
>> On Mon, May 31, 2010 at 11:47 PM, Florian Mickler
>> wrote:
>> > On Mon, 31 May 2010 22:12:19 +0200
>> > Florian Mickler wrote:
>> >> If I have a simple shell script then I don't wan
On Sat, 2010-06-05 at 21:39 +0200, Rafael J. Wysocki wrote:
>
> There is a number of kernel users that depend on Android user space
> (phone vendors using Android on their hardware, but providing their own
> drivers), so I don't think we really can identify Android with Google in that
> respect.
On Sat, 5 Jun 2010 20:16:33 +0300
Felipe Contreras wrote:
> On Tue, Jun 1, 2010 at 12:14 AM, Rafael J. Wysocki wrote:
> > Do you realistically think that by hurting the _user_ you will make the
> > _developer_ write better code? No, really.
>
> As an application writer, if my users complain th
On Saturday 05 June 2010, Peter Zijlstra wrote:
> On Sat, 2010-06-05 at 21:04 +0200, Rafael J. Wysocki wrote:
> >
> > > I have seen recent proposals that don't require changing the whole
> > > user-space. That might actually be used by other players.
> >
> > Sure, an approach benefitting more pla
On Sat, 2010-06-05 at 21:04 +0200, Rafael J. Wysocki wrote:
>
> > I have seen recent proposals that don't require changing the whole
> > user-space. That might actually be used by other players.
>
> Sure, an approach benefitting more platforms than just Android would be
> better,
> but saying th
On Saturday 05 June 2010, Felipe Contreras wrote:
> On Mon, May 31, 2010 at 11:47 PM, Florian Mickler wrote:
> > On Mon, 31 May 2010 22:12:19 +0200
> > Florian Mickler wrote:
> >> If I have a simple shell script then I don't wanna jump through
> >> hoops just to please your fragile kernel.
> >
>
2010/6/2 Arve Hjønnevåg :
> 2010/6/2 Peter Zijlstra :
>> (and please don't mention @#$@ up x86 ACPI again, Intel knows, they're
>> fixing it, get over it already).
>>
>
> I don't think it is realistic to drop support for all existing hardware.
We are talking about mainline here, there's no support
On Thu, Jun 3, 2010 at 6:28 PM, Peter Zijlstra wrote:
> On Thu, 2010-06-03 at 16:12 +0200, Florian Mickler wrote:
>> On Thu, 03 Jun 2010 09:40:02 +0200
>> Peter Zijlstra wrote:
>>
>> > Same for firefox, you can teach it to not render animated gifs and run
>> > javascript for invisible tabs, and o
On Tue, Jun 1, 2010 at 12:14 AM, Rafael J. Wysocki wrote:
> Do you realistically think that by hurting the _user_ you will make the
> _developer_ write better code? No, really.
As an application writer, if my users complain that their battery is
being drained (as it happened), they stop using it
On Mon, May 31, 2010 at 11:47 PM, Florian Mickler wrote:
> On Mon, 31 May 2010 22:12:19 +0200
> Florian Mickler wrote:
>> If I have a simple shell script then I don't wanna jump through
>> hoops just to please your fragile kernel.
>
> Also why should that code on one device kill my uptime and on
On Mon, May 31, 2010 at 8:55 AM, Igor Stoppa wrote:
> ext Felipe Contreras wrote:
>
>> I think this information can be obtained dynamically while the
>> application is running,
>
> yes, that was the idea
>
>> and perhaps the limits can be stored. It would
>> be pretty difficult for the applicatio
On Thu, 03 Jun 2010 17:28:01 +0200
Peter Zijlstra wrote:
> On Thu, 2010-06-03 at 16:12 +0200, Florian Mickler wrote:
> > On Thu, 03 Jun 2010 09:40:02 +0200
> > Peter Zijlstra wrote:
> >
> > > Same for firefox, you can teach it to not render animated gifs and run
> > > javascript for invisible t
2010/6/4 Dmitry Torokhov :
> On Wed, Jun 02, 2010 at 07:44:59PM -0700, Arve Hjønnevåg wrote:
>> On Wed, Jun 2, 2010 at 4:32 PM, Dmitry Torokhov
>> wrote:
>> > On Wed, Jun 02, 2010 at 09:05:21PM +0200, Florian Mickler wrote:
>> >> On Wed, 2 Jun 2010 21:02:24 +1000
>> >> Neil Brown wrote:
>> >> >
>
On Wed, Jun 02, 2010 at 07:44:59PM -0700, Arve Hjønnevåg wrote:
> On Wed, Jun 2, 2010 at 4:32 PM, Dmitry Torokhov
> wrote:
> > On Wed, Jun 02, 2010 at 09:05:21PM +0200, Florian Mickler wrote:
> >> On Wed, 2 Jun 2010 21:02:24 +1000
> >> Neil Brown wrote:
> >> >
> >> > And this decision (to block s
Yes, having a QoS parameter per-subsystem (or even per-device) is very
important for SoCs that have independently controlled powerdomains.
If all devices/subsystems in a particular powerdomain have QoS
parameters that permit, the power state of that powerdomain can be
lowered independently from sy
James Bottomley; Thomas Gleixner; Linux OMAP Mailing List;
Linux PM; Alan Cox
Subject: Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
"Gross, Mark" writes:
>>-Original Message-
>>From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
>>Sent: Thursday,
gt; >>Cc: Alan Cox; Gross, Mark; Florian Mickler; James Bottomley; Arve
> >>Hjønnevåg; Neil Brown; ty...@mit.edu; LKML; Thomas Gleixner; Linux OMAP
> >>Mailing List; Linux PM; felipe.ba...@nokia.com
> >>Subject: Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
nevåg; Neil Brown; ty...@mit.edu; LKML; Thomas Gleixner; Linux OMAP
>>Mailing List; Linux PM; felipe.ba...@nokia.com
>>Subject: Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
>>
>>Peter Zijlstra writes:
>>
>>> On Thu, 2010-06-03 at 11:03 +0100, Al
inux OMAP
>Mailing List; Linux PM; felipe.ba...@nokia.com
>Subject: Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
>
>Peter Zijlstra writes:
>
>> On Thu, 2010-06-03 at 11:03 +0100, Alan Cox wrote:
>>> > [mtg: ] This has been a pain point for the PM_QOS imp
On Thu, 2010-06-03 at 10:21 -0400, ty...@mit.edu wrote:
> And let's be blunt. If in the future the Android team (which I'm not
> a member of) decides that they have invested more engineering time
> than they can justify from a business perspective, the next time
> someone starts whining on a blog
On Thu, 2010-06-03 at 16:12 +0200, Florian Mickler wrote:
> On Thu, 03 Jun 2010 09:40:02 +0200
> Peter Zijlstra wrote:
>
> > Same for firefox, you can teach it to not render animated gifs and run
> > javascript for invisible tabs, and once the screen-saver kicks in,
> > nothing is visible (and wi
On Thu, 2010-06-03 at 16:35 +0200, Thomas Gleixner wrote:
> On Thu, 3 Jun 2010, James Bottomley wrote:
>
> > On Thu, 2010-06-03 at 11:03 +0100, Alan Cox wrote:
> > > > [mtg: ] This has been a pain point for the PM_QOS implementation. They
> > > > change the constrain back and forth at the transa
Peter Zijlstra writes:
> On Thu, 2010-06-03 at 11:03 +0100, Alan Cox wrote:
>> > [mtg: ] This has been a pain point for the PM_QOS implementation.
>> They change the constrain back and forth at the transaction level of
>> the i2c driver. The pm_qos code really wasn't made to deal with such
>> ho
On Thu, 3 Jun 2010, James Bottomley wrote:
> On Thu, 2010-06-03 at 11:03 +0100, Alan Cox wrote:
> > > [mtg: ] This has been a pain point for the PM_QOS implementation. They
> > > change the constrain back and forth at the transaction level of the i2c
> > > driver. The pm_qos code really wasn't
ng
>List; Linux PM; felipe.ba...@nokia.com
>Subject: Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
>
>On Thu, 2010-06-03 at 11:03 +0100, Alan Cox wrote:
>> > [mtg: ] This has been a pain point for the PM_QOS implementation. They
>change the constrain back and forth a
On Wed, Jun 02, 2010 at 11:43:06PM -0700, Brian Swetland wrote:
> > I guess it becomes an question of economics for you then. Does the cost of
> > whatever user-space changes are required exceed the value of using an
> > upstream
> > kernel? Both the cost and the value would be very hard to esti
On Thu, 03 Jun 2010 08:24:31 -0500
James Bottomley wrote:
> On Thu, 2010-06-03 at 11:03 +0100, Alan Cox wrote:
> > > [mtg: ] This has been a pain point for the PM_QOS implementation. They
> > > change the constrain back and forth at the transaction level of the i2c
> > > driver. The pm_qos co
On Thu, 03 Jun 2010 09:40:02 +0200
Peter Zijlstra wrote:
> Same for firefox, you can teach it to not render animated gifs and run
> javascript for invisible tabs, and once the screen-saver kicks in,
> nothing is visible (and with X telling apps their window is visible or
> not it knows), so it sh
> > > If "suspend" is the thing we are used to via
> /sys/power/state then the
> > > race will persist forever except for the suspend blocker workaround,
True, because device wakeups are enabled
by device.driver.suspend() methods, which are
invoked towards the end of the activities
triggered by w
On Thu, 2010-06-03 at 11:03 +0100, Alan Cox wrote:
> > [mtg: ] This has been a pain point for the PM_QOS implementation. They
> > change the constrain back and forth at the transaction level of the i2c
> > driver. The pm_qos code really wasn't made to deal with such hot path use,
> > as each s
On Thu, 2010-06-03 at 11:03 +0100, Alan Cox wrote:
> > [mtg: ] This has been a pain point for the PM_QOS implementation.
> They change the constrain back and forth at the transaction level of
> the i2c driver. The pm_qos code really wasn't made to deal with such
> hot path use, as each such change
> [mtg: ] This has been a pain point for the PM_QOS implementation. They
> change the constrain back and forth at the transaction level of the i2c
> driver. The pm_qos code really wasn't made to deal with such hot path use,
> as each such change triggers a re-computation of what the aggregate
On Wed, 2010-06-02 at 23:58 -0700, Brian Swetland wrote:
>
> I haven't poked around too much with how things work in SMP
> environments -- are there per-cpu idle threads?
Yes, and we recently grew the infrastructure for asymmetric MP in the
processing capacity sense.
--
To unsubscribe from this
On Wed, 2010-06-02 at 22:13 +0200, Florian Mickler wrote:
> On Wed, 02 Jun 2010 12:21:28 +0200
> Peter Zijlstra wrote:
> Do you switch your pc on and off manually? Sometimes? Really?
> (if not, you are probably a kernel hacker *g*)
Yeah, when my Radeon GPU locks up the bus _again_, and yeah to
On Wed, Jun 2, 2010 at 9:24 PM, Paul Mundt wrote:
>
> On the other hand, while this isn't that difficult for the UP case it
> does pose more problems for the SMP case. Presently the suspend paths
> (suspend-to-RAM/hibernate/kexec jump) all deal with disabling and
> enabling of non-boot CPUs via CP
On Wed, Jun 2, 2010 at 11:33 PM, Neil Brown wrote:
>>
>> The current suspend-blocker proposal already involves userspace
>> changes (it's different than our existing wakelock interface), and
>> we're certainly not opposed to any/all userspace changes on principle,
>> but on the other hand we're no
On Wed, 2 Jun 2010 11:05:18 -0700
Brian Swetland wrote:
> On Wed, Jun 2, 2010 at 1:06 AM, Neil Brown wrote:
> > On Wed, 2 Jun 2010 00:05:14 -0700
> > Arve Hjønnevåg wrote:
> >> > The user-space suspend daemon avoids losing wake-events by using
> >> > fcntl(F_OWNER) to ensure it gets a signal wh
On Thu, May 27, 2010 at 06:06:43PM +0200, Thomas Gleixner wrote:
> On Thu, 27 May 2010, Alan Stern wrote:
> > And to answer Thomas's question: The whole reason for having in-kernel
> > suspend blockers is so that userspace can tell the system to suspend
> > without losing wakeup events.
> >
> >
On Wed, 2 Jun 2010 19:44:59 -0700
Arve Hjønnevåg wrote:
> On Wed, Jun 2, 2010 at 4:32 PM, Dmitry Torokhov
> wrote:
> > On Wed, Jun 02, 2010 at 09:05:21PM +0200, Florian Mickler wrote:
> >> On Wed, 2 Jun 2010 21:02:24 +1000
> >> Neil Brown wrote:
> >> >
> >> > And this decision (to block suspend
On Wed, Jun 2, 2010 at 4:32 PM, Dmitry Torokhov
wrote:
> On Wed, Jun 02, 2010 at 09:05:21PM +0200, Florian Mickler wrote:
>> On Wed, 2 Jun 2010 21:02:24 +1000
>> Neil Brown wrote:
>> >
>> > And this decision (to block suspend) really needs to be made in the driver,
>> > not in userspace?
>>
>> We
On Wed, 2 Jun 2010 16:32:44 -0700
Dmitry Torokhov wrote:
> On Wed, Jun 02, 2010 at 09:05:21PM +0200, Florian Mickler wrote:
> > On Wed, 2 Jun 2010 21:02:24 +1000
> > Neil Brown wrote:
> > >
> > > And this decision (to block suspend) really needs to be made in the
> > > driver,
> > > not in use
On Wed, Jun 02, 2010 at 09:05:21PM +0200, Florian Mickler wrote:
> On Wed, 2 Jun 2010 21:02:24 +1000
> Neil Brown wrote:
> >
> > And this decision (to block suspend) really needs to be made in the driver,
> > not in userspace?
>
> Well, it fits. The requirement is a direct consequence of the int
On Wed, 2 Jun 2010 21:05:21 +0200
Florian Mickler wrote:
> Could someone perhaps make a recap on what are the problems with the
> API? I have no clear eye (experience?) for that (or so it seems).
Good interface design is an acquired taste. And it isn't always easy to
explain satisfactorily. Bu
ing List; Linux PM;
>felipe.ba...@nokia.com
>Subject: Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
>
>On Wed, 02 Jun 2010 15:41:11 -0500
>James Bottomley wrote:
>
>> On Wed, 2010-06-02 at 21:47 +0200, Florian Mickler wrote:
>> > On Wed, 02 Jun 2010 10:05:11 -0
On Wed, 02 Jun 2010 15:41:11 -0500
James Bottomley wrote:
> On Wed, 2010-06-02 at 21:47 +0200, Florian Mickler wrote:
> > On Wed, 02 Jun 2010 10:05:11 -0500
> > James Bottomley wrote:
> >
> > > On Tue, 2010-06-01 at 21:41 -0700, Arve Hjønnevåg wrote:
> > > > No, they have to be two separate con
On Wed, 2010-06-02 at 15:27 -0700, Arve Hjønnevåg wrote:
> On Wed, Jun 2, 2010 at 1:41 PM, James Bottomley
> wrote:
> > On Wed, 2010-06-02 at 21:47 +0200, Florian Mickler wrote:
> >> On Wed, 02 Jun 2010 10:05:11 -0500
> >> James Bottomley wrote:
> >>
> >> > On Tue, 2010-06-01 at 21:41 -0700, Arv
On Wed, Jun 2, 2010 at 1:41 PM, James Bottomley wrote:
> On Wed, 2010-06-02 at 21:47 +0200, Florian Mickler wrote:
>> On Wed, 02 Jun 2010 10:05:11 -0500
>> James Bottomley wrote:
>>
>> > On Tue, 2010-06-01 at 21:41 -0700, Arve Hjønnevåg wrote:
>> > > No, they have to be two separate constraints,
On Thursday 03 June 2010, Neil Brown wrote:
> On Wed, 2 Jun 2010 22:41:14 +0200
> "Rafael J. Wysocki" wrote:
>
> > On Wednesday 02 June 2010, Neil Brown wrote:
> > > - Would this fix the "bug"??
> > > - and address the issues that suspend-blockers was created to address?
> > > - or are the requir
On Wed, 2 Jun 2010 22:41:14 +0200
"Rafael J. Wysocki" wrote:
> On Wednesday 02 June 2010, Neil Brown wrote:
> > - Would this fix the "bug"??
> > - and address the issues that suspend-blockers was created to address?
> > - or are the requirements on user-space too onerous?
>
> In theory wakeup ev
On Wednesday 02 June 2010, Neil Brown wrote:
> On Tue, 1 Jun 2010 10:47:49 -0400 (EDT)
> Alan Stern wrote:
...
> So yes, there are different use cases and we should support all of them,
> both "I shut the lid and my laptop really stays asleep" and "I never miss a
> TXT because my phone went to sle
On Wednesday 02 June 2010, Neil Brown wrote:
> On Tue, 1 Jun 2010 12:50:01 +0200 (CEST)
> Thomas Gleixner wrote:
>
> > On Tue, 1 Jun 2010, Neil Brown wrote:
> > >
> > > I think you have acknowledged that there is a race with suspend - thanks.
> > > Next step was "can it be closed".
> > > You see
On Wed, 2010-06-02 at 21:47 +0200, Florian Mickler wrote:
> On Wed, 02 Jun 2010 10:05:11 -0500
> James Bottomley wrote:
>
> > On Tue, 2010-06-01 at 21:41 -0700, Arve Hjønnevåg wrote:
> > > No, they have to be two separate constraints, otherwise a constraint
> > > to block suspend would override a
On Wed, 02 Jun 2010 12:21:28 +0200
Peter Zijlstra wrote:
> On Wed, 2010-06-02 at 03:00 -0700, Arve Hjønnevåg wrote:
> > 2010/6/2 Peter Zijlstra :
> > > On Wed, 2010-06-02 at 01:54 -0700, Arve Hjønnevåg wrote:
> > >> No I want you to stop confusing low power idle modes with suspend.
> > >
> > > I
On Wed, 02 Jun 2010 10:05:11 -0500
James Bottomley wrote:
> On Tue, 2010-06-01 at 21:41 -0700, Arve Hjønnevåg wrote:
> > No, they have to be two separate constraints, otherwise a constraint
> > to block suspend would override a constraint to block a low power idle
> > mode or the other way around
On Wed, 2 Jun 2010 21:02:24 +1000
Neil Brown wrote:
>
> And this decision (to block suspend) really needs to be made in the driver,
> not in userspace?
Well, it fits. The requirement is a direct consequence of the intimate
knowledge the driver has about the driven devices.
Or if you get in an u
On Wed, Jun 2, 2010 at 1:06 AM, Neil Brown wrote:
> On Wed, 2 Jun 2010 00:05:14 -0700
> Arve Hjønnevåg wrote:
>> > The user-space suspend daemon avoids losing wake-events by using
>> > fcntl(F_OWNER) to ensure it gets a signal whenever any important wake-event
>> > is ready to be read by user-spa
On Tue, 2010-06-01 at 21:41 -0700, Arve Hjønnevåg wrote:
> 2010/6/1 James Bottomley :
> > On Tue, 2010-06-01 at 18:10 -0700, Arve Hjønnevåg wrote:
> >> On Tue, Jun 1, 2010 at 3:36 PM, James Bottomley
> >> wrote:
> >> > On Wed, 2010-06-02 at 00:24 +0200, Rafael J. Wysocki wrote:
> >> >> On Tuesday
On Wed, 2 Jun 2010, Arve Hjønnevåg wrote:
> 2010/6/2 Thomas Gleixner :
> > On Wed, 2 Jun 2010, Arve Hjønnevåg wrote:
> >> 2010/6/2 Neil Brown :
> >> > There would still need to be some sort of communication between the the
> >> > suspend daemon on any event daemon to ensure that the events had bee
On Wed, 02 Jun 2010 11:10:51 +0200
Peter Zijlstra wrote:
> On Wed, 2010-06-02 at 10:29 +0200, Thomas Gleixner wrote:
>
>
> > If I understood you correctly then you can shutdown the CPU in idle
> > completelty already, but that's not enough due to:
> >
> > 1) crappy applications keeping the
On Wed, 2 Jun 2010 02:12:10 -0700
Arve Hjønnevåg wrote:
> 2010/6/2 Neil Brown :
> > On Wed, 2 Jun 2010 00:05:14 -0700
> > Arve Hjønnevåg wrote:
> >
> >> On Tue, Jun 1, 2010 at 10:32 PM, Neil Brown wrote:
> >> > On Tue, 1 Jun 2010 12:50:01 +0200 (CEST)
> >> > Thomas Gleixner wrote:
> >> >
> >>
On Wed, 2 Jun 2010 10:50:39 +0200
Florian Mickler wrote:
> On Wed, 2 Jun 2010 18:06:14 +1000
> Neil Brown wrote:
>
> > I cannot imagine why it would take multiple seconds to scan a keypad.
> > Can you explain that?
> >
> > Do you mean while keys are held pressed? Maybe you don't get a wake-up
On Wed, 2010-06-02 at 03:00 -0700, Arve Hjønnevåg wrote:
> 2010/6/2 Peter Zijlstra :
> > On Wed, 2010-06-02 at 01:54 -0700, Arve Hjønnevåg wrote:
> >> No I want you to stop confusing low power idle modes with suspend.
> >
> > I think it is you who is confused. For power management purposes suspend
2010/6/2 Peter Zijlstra :
> On Wed, 2010-06-02 at 01:54 -0700, Arve Hjønnevåg wrote:
>> No I want you to stop confusing low power idle modes with suspend.
>
> I think it is you who is confused. For power management purposes suspend
> is nothing more but a deep idle state.
No, idle is transparent,
2010/6/2 Thomas Gleixner :
> On Wed, 2 Jun 2010, Arve Hjønnevåg wrote:
>> 2010/6/2 Neil Brown :
>> > There would still need to be some sort of communication between the the
>> > suspend daemon on any event daemon to ensure that the events had been
>> > processed. This could be very light weight in
On Wed, 2010-06-02 at 01:54 -0700, Arve Hjønnevåg wrote:
> No I want you to stop confusing low power idle modes with suspend.
I think it is you who is confused. For power management purposes suspend
is nothing more but a deep idle state.
(and please don't mention @#$@ up x86 ACPI again, Intel kno
On Wed, 2 Jun 2010, Arve Hjønnevåg wrote:
> 2010/6/2 Neil Brown :
> > There would still need to be some sort of communication between the the
> > suspend daemon on any event daemon to ensure that the events had been
> > processed. This could be very light weight interaction. The point though
> >
2010/6/2 Thomas Gleixner :
> On Wed, 2 Jun 2010, Arve Hjønnevåg wrote:
>> 2010/6/2 Thomas Gleixner :
>> > On Tue, 1 Jun 2010, Arve Hjønnevåg wrote:
>> >>
>> >> Because suspend itself causes you to not be idle you cannot abort
>> >> suspend just because you are not idle anymore.
>> >
>> > You still
2010/6/2 Neil Brown :
> On Wed, 2 Jun 2010 00:05:14 -0700
> Arve Hjønnevåg wrote:
>
>> On Tue, Jun 1, 2010 at 10:32 PM, Neil Brown wrote:
>> > On Tue, 1 Jun 2010 12:50:01 +0200 (CEST)
>> > Thomas Gleixner wrote:
>> >
>> >> On Tue, 1 Jun 2010, Neil Brown wrote:
>> >> >
>> >> > I think you have ac
On Wed, 2010-06-02 at 10:29 +0200, Thomas Gleixner wrote:
> If I understood you correctly then you can shutdown the CPU in idle
> completelty already, but that's not enough due to:
>
> 1) crappy applications keeping the cpu away from idle
> 2) timers firing
>
> Would solving those two i
On Wed, 2 Jun 2010, Arve Hjønnevåg wrote:
> 2010/6/2 Thomas Gleixner :
> > On Tue, 1 Jun 2010, Arve Hjønnevåg wrote:
> >>
> >> Because suspend itself causes you to not be idle you cannot abort
> >> suspend just because you are not idle anymore.
> >
> > You still are addicted to the current suspend
2010/6/2 Thomas Gleixner :
> On Tue, 1 Jun 2010, Arve Hjønnevåg wrote:
>> 2010/6/1 Thomas Gleixner :
>> > On Mon, 31 May 2010, Arve Hjønnevåg wrote:
>> >
>> >> 2010/5/31 Rafael J. Wysocki :
>> >> > On Monday 31 May 2010, Arve Hjønnevåg wrote:
>> >> >> 2010/5/30 Rafael J. Wysocki :
>> >> > ...
>> >>
On Wed, 2 Jun 2010 18:06:14 +1000
Neil Brown wrote:
> I cannot imagine why it would take multiple seconds to scan a keypad.
> Can you explain that?
>
> Do you mean while keys are held pressed? Maybe you don't get a wake-up event
> on key-release? In that case your user-space daemon could block
On Tue, 1 Jun 2010, Arve Hjønnevåg wrote:
> 2010/6/1 Thomas Gleixner :
> > On Mon, 31 May 2010, Arve Hjønnevåg wrote:
> >
> >> 2010/5/31 Rafael J. Wysocki :
> >> > On Monday 31 May 2010, Arve Hjønnevåg wrote:
> >> >> 2010/5/30 Rafael J. Wysocki :
> >> > ...
> >> >>
> >> >> I think it makes more sen
On Wed, 2 Jun 2010 00:05:14 -0700
Arve Hjønnevåg wrote:
> On Tue, Jun 1, 2010 at 10:32 PM, Neil Brown wrote:
> > On Tue, 1 Jun 2010 12:50:01 +0200 (CEST)
> > Thomas Gleixner wrote:
> >
> >> On Tue, 1 Jun 2010, Neil Brown wrote:
> >> >
> >> > I think you have acknowledged that there is a race wi
On Wed, 2 Jun 2010, Arve Hjønnevåg wrote:
> 2010/6/2 Thomas Gleixner :
> > On Tue, 1 Jun 2010, Arve Hjønnevåg wrote:
> >> Deferring the the timers forever without stopping the clock can cause
> >> problems. Our user space code has a lot of timeouts that will trigger
> >> an error if an app does not
2010/6/2 Thomas Gleixner :
> On Tue, 1 Jun 2010, Arve Hjønnevåg wrote:
>> 2010/6/1 Thomas Gleixner :
>> >
>> > On Mon, 31 May 2010, Arve Hjønnevåg wrote:
>> >
>> >> On Mon, May 31, 2010 at 2:46 PM, Thomas Gleixner
>> >> wrote:
>> >> > On Mon, 31 May 2010, James Bottomley wrote:
>> >> >>
>> >> >>
On Tue, Jun 1, 2010 at 10:32 PM, Neil Brown wrote:
> On Tue, 1 Jun 2010 12:50:01 +0200 (CEST)
> Thomas Gleixner wrote:
>
>> On Tue, 1 Jun 2010, Neil Brown wrote:
>> >
>> > I think you have acknowledged that there is a race with suspend - thanks.
>> > Next step was "can it be closed".
>> > You see
On Tue, 1 Jun 2010, Arve Hjønnevåg wrote:
> 2010/6/1 Thomas Gleixner :
> >
> > On Mon, 31 May 2010, Arve Hjønnevåg wrote:
> >
> >> On Mon, May 31, 2010 at 2:46 PM, Thomas Gleixner
> >> wrote:
> >> > On Mon, 31 May 2010, James Bottomley wrote:
> >> >>
> >> >> For MSM hardware, it looks possible to
On Tue, 1 Jun 2010 12:50:01 +0200 (CEST)
Thomas Gleixner wrote:
> On Tue, 1 Jun 2010, Neil Brown wrote:
> >
> > I think you have acknowledged that there is a race with suspend - thanks.
> > Next step was "can it be closed".
> > You seem to suggest that it can, but you describe it as a "work arou
2010/6/1 James Bottomley :
> On Tue, 2010-06-01 at 18:10 -0700, Arve Hjønnevåg wrote:
>> On Tue, Jun 1, 2010 at 3:36 PM, James Bottomley
>> wrote:
>> > On Wed, 2010-06-02 at 00:24 +0200, Rafael J. Wysocki wrote:
>> >> On Tuesday 01 June 2010, James Bottomley wrote:
>> >> > On Tue, 2010-06-01 at 1
On Tue, 2010-06-01 at 19:45 -0700, mark gross wrote:
> On Tue, Jun 01, 2010 at 04:01:25PM -0500, James Bottomley wrote:
> > On Tue, 2010-06-01 at 14:51 +0100, Matthew Garrett wrote:
> > > On Mon, May 31, 2010 at 04:21:09PM -0500, James Bottomley wrote:
> > >
> > > > You're the one mentioning x86,
On Tue, 2010-06-01 at 18:10 -0700, Arve Hjønnevåg wrote:
> On Tue, Jun 1, 2010 at 3:36 PM, James Bottomley
> wrote:
> > On Wed, 2010-06-02 at 00:24 +0200, Rafael J. Wysocki wrote:
> >> On Tuesday 01 June 2010, James Bottomley wrote:
> >> > On Tue, 2010-06-01 at 14:51 +0100, Matthew Garrett wrote:
2010/6/1 Thomas Gleixner :
>
> On Mon, 31 May 2010, Arve Hjønnevåg wrote:
>
>> On Mon, May 31, 2010 at 2:46 PM, Thomas Gleixner wrote:
>> > On Mon, 31 May 2010, James Bottomley wrote:
>> >>
>> >> For MSM hardware, it looks possible to unify the S and C states by doing
>> >> suspend to ram from idl
OMAP
>Mailing List; felipe.ba...@nokia.com; Alan Cox; Alan Stern; Neil Brown
>Subject: Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
>
>2010/6/1 Gross, Mark :
>...
>>>4. It would be useful to change pm_qos_add_request to not allocate
>>>anything so can
2010/6/1 Thomas Gleixner :
> On Mon, 31 May 2010, Arve Hjønnevåg wrote:
>
>> 2010/5/31 Rafael J. Wysocki :
>> > On Monday 31 May 2010, Arve Hjønnevåg wrote:
>> >> 2010/5/30 Rafael J. Wysocki :
>> > ...
>> >>
>> >> I think it makes more sense to block suspend while wakeup events are
>> >> pending th
2010/6/1 Gross, Mark :
...
>>4. It would be useful to change pm_qos_add_request to not allocate
>>anything so can add constraints from init functions that currently
>>cannot fail.
> [mtg: ] I'm not sure how to do this but I agree it would be good. I guess we
> could have a block of pm_qos request
On Tue, Jun 01, 2010 at 04:01:25PM -0500, James Bottomley wrote:
> On Tue, 2010-06-01 at 14:51 +0100, Matthew Garrett wrote:
> > On Mon, May 31, 2010 at 04:21:09PM -0500, James Bottomley wrote:
> >
> > > You're the one mentioning x86, not me. I already explained that some
> > > MSM hardware (the
1 - 100 of 481 matches
Mail list logo
