On Sunday, July 31, 2011, Pavel Machek wrote:
> Hi!
>
> > > IIRC I solved it by just calling _PTS when sleepy Linux was
> > > enabled. It had side effect of lighting up moon icon, but otherwise
> > > seemed to work ok.
> > >
> > > I do not think ACPI says what can and can not be done after _PTS..
Hi!
> > IIRC I solved it by just calling _PTS when sleepy Linux was
> > enabled. It had side effect of lighting up moon icon, but otherwise
> > seemed to work ok.
> >
> > I do not think ACPI says what can and can not be done after _PTS...
>
> Yes, it does.
I have 2.0 spec here; it explains how
On Saturday, July 30, 2011, Pavel Machek wrote:
>
> > > > IIRC I solved it by just calling _PTS when sleepy Linux was
> > > > enabled. It had side effect of lighting up moon icon, but otherwise
> > > > seemed to work ok.
> > > >
> > > > I do not think ACPI says what can and can not be done after
On Saturday, July 30, 2011, Rafael J. Wysocki wrote:
> On Saturday, July 30, 2011, Pavel Machek wrote:
> > Hi!
> >
> > > > Well, auto suspending when screensaver is active would still be
> > > > useful.
> > > >
> > > > (And IIRC some machines kept screen on when in S-state unless driver
> > > > p
> > > IIRC I solved it by just calling _PTS when sleepy Linux was
> > > enabled. It had side effect of lighting up moon icon, but otherwise
> > > seemed to work ok.
> > >
> > > I do not think ACPI says what can and can not be done after _PTS...
> >
> > Yes, it does.
>
> And even if _PTS will wo
On Saturday, July 30, 2011, Pavel Machek wrote:
> Hi!
>
> > > Well, auto suspending when screensaver is active would still be
> > > useful.
> > >
> > > (And IIRC some machines kept screen on when in S-state unless driver
> > > powered it down... but that might be S1.
> > >
> > > > The reason why
Hi!
> > Well, auto suspending when screensaver is active would still be
> > useful.
> >
> > (And IIRC some machines kept screen on when in S-state unless driver
> > powered it down... but that might be S1.
> >
> > > The reason why you can't enter ACPI S-states from CPUidle is because you
> > > n
On Friday, July 29, 2011, Pavel Machek wrote:
> Hi!
>
> > > > Actually, it just occurred to me that if we're waiting for a system
> > > > timer and can hand that off to a suitable timer in the PMIC then we can
> > > > do a suspend to RAM for the deep idle state from the hardware point of
> > > > v
Hi!
> > > Actually, it just occurred to me that if we're waiting for a system
> > > timer and can hand that off to a suitable timer in the PMIC then we can
> > > do a suspend to RAM for the deep idle state from the hardware point of
> > > view.
> >
> > Yep. At LinuxCon Cambridge two years ago, w
On Wednesday, July 13, 2011, Paul Walmsley wrote:
> (cc'ing Len)
>
> Hi Mark,
>
> On Mon, 11 Jul 2011, Mark Brown wrote:
>
> > The interesting bits are things like being able to kill lots of the SoC
> > core supplies when the RAM is in retention mode - the CPU needs to go
> > through its shutdow
(cc'ing Len)
Hi Mark,
On Mon, 11 Jul 2011, Mark Brown wrote:
> The interesting bits are things like being able to kill lots of the SoC
> core supplies when the RAM is in retention mode - the CPU needs to go
> through its shutdown procedures.
This is indeed possible on OMAP3+ chips with TWL4030+
* Mark Brown [110711 04:21]:
> On Mon, Jul 11, 2011 at 04:14:24AM -0700, Tony Lindgren wrote:
> > * Mark Brown [110711 03:59]:
>
> > > Right, but it can be interesting to tell the PMIC that we went into this
> > > mode. Possibly cpuidle will end up doing this as a result of signals
> > > genera
On Mon, Jul 11, 2011 at 04:14:24AM -0700, Tony Lindgren wrote:
> * Mark Brown [110711 03:59]:
> > Right, but it can be interesting to tell the PMIC that we went into this
> > mode. Possibly cpuidle will end up doing this as a result of signals
> > generated as the CPU core goes down, but at that
* Mark Brown [110711 03:59]:
> On Mon, Jul 11, 2011 at 02:58:12AM -0700, Tony Lindgren wrote:
> > * Mark Brown [110708 21:01]:
>
> > > At least the Nexus S doesn't implmeent any of the deep idle
> > > infrastructure. However, I'd expect that you can achieve some power
> > > saving from entering
On Mon, Jul 11, 2011 at 02:58:12AM -0700, Tony Lindgren wrote:
> * Mark Brown [110708 21:01]:
> > At least the Nexus S doesn't implmeent any of the deep idle
> > infrastructure. However, I'd expect that you can achieve some power
> > saving from entering system suspend as if *everything* is off
* Mark Brown [110708 21:01]:
> On Tue, Jun 28, 2011 at 01:47:47PM -0600, Paul Walmsley wrote:
> > On Fri, 24 Jun 2011, Arve Hj?nnev?g wrote:
> > > On Fri, Jun 24, 2011 at 12:53 PM, Paul Walmsley wrote:
>
> > > > "On the hardware that shipped we enter the same power state from idle
> > > > and su
On Tue, Jun 28, 2011 at 01:47:47PM -0600, Paul Walmsley wrote:
> On Fri, 24 Jun 2011, Arve Hj?nnev?g wrote:
> > On Fri, Jun 24, 2011 at 12:53 PM, Paul Walmsley wrote:
> > > "On the hardware that shipped we enter the same power state from idle
> > > and suspend, so the only power savings we get fr
Hello Arve,
On Fri, 24 Jun 2011, Arve Hjønnevåg wrote:
> On Fri, Jun 24, 2011 at 12:53 PM, Paul Walmsley wrote:
> >
> > As I understand it, in the original Android implementation, the hardware
> > that they were using didn't have fine-grained power management. So
> > system-wide suspend made mo
On Fri, 24 Jun 2011, Paul Walmsley wrote:
> > > But suspend users don't know this either, since they can't predict when
> > > the next external wakeup can happen.
> >
> > But they do know (or should know) that they don't intend to use the
> > system in the near future. It might be good to have
Hi,
On Friday, June 24, 2011, Paul Walmsley wrote:
> (Arve cc'ed, also adding Magnus and Kevin back to cc)
Thanks, my mailer is playing tricks on me. :-)
> Hi Rafael,
>
> On Thu, 23 Jun 2011, Rafael J. Wysocki wrote:
>
> > On Thursday, June 23, 2011, Alan Stern wrote:
> > > On Thu, 23 Jun 2011
2011/6/25 Arve Hjønnevåg :
> On Fri, Jun 24, 2011 at 12:53 PM, Paul Walmsley wrote:
> ...
>>
>> As I understand it, in the original Android implementation, the hardware
>> that they were using didn't have fine-grained power management. So
>> system-wide suspend made more sense in that context. B
On Fri, Jun 24, 2011 at 12:53 PM, Paul Walmsley wrote:
...
>
> As I understand it, in the original Android implementation, the hardware
> that they were using didn't have fine-grained power management. So
> system-wide suspend made more sense in that context. But that shouldn't
> be confused wit
(Arve cc'ed, also adding Magnus and Kevin back to cc)
Hi Rafael,
On Thu, 23 Jun 2011, Rafael J. Wysocki wrote:
> On Thursday, June 23, 2011, Alan Stern wrote:
> > On Thu, 23 Jun 2011, Paul Walmsley wrote:
> > > On Wed, 15 Jun 2011, Rafael J. Wysocki wrote:
> > >
> > > > Well, the freezing of use
Hi Alan,
On Thu, 23 Jun 2011, Alan Stern wrote:
> On Thu, 23 Jun 2011, Paul Walmsley wrote:
> >
> > On Wed, 15 Jun 2011, Rafael J. Wysocki wrote:
>
> At the moment, isn't it possible for the userspace ioctl PM interface to
> freeze processes without going all the way through to a system sleep?
Hi,
On Thursday, June 23, 2011, Alan Stern wrote:
> On Thu, 23 Jun 2011, Paul Walmsley wrote:
>
> > Hi
> >
> > a few thoughts here:
> >
> > On Wed, 15 Jun 2011, Rafael J. Wysocki wrote:
> >
> > > On Tuesday, June 14, 2011, Magnus Damm wrote:
> > >
> > > > As for freezing user space, yes, I agr
On Thu, 23 Jun 2011, Paul Walmsley wrote:
> Hi
>
> a few thoughts here:
>
> On Wed, 15 Jun 2011, Rafael J. Wysocki wrote:
>
> > On Tuesday, June 14, 2011, Magnus Damm wrote:
> >
> > > As for freezing user space, yes, I agree. The other feature including
> > > a different set of wakeup sources,
26 matches
Mail list logo
