CCing linux-pm list.
On Wed, May 26, 2010 at 9:07 PM, uthappa utha...@mistralsolutions.com wrote:
Hello Everyone,
I am currently working with the linux 2.6.29-omap1 kernel. Right now I
am porting a legacy application code that puts the OMAP 5912 host to
sleep. The host wakes up after
Added board_data within musb as it would be required in
musb_platform_exit() also to unregister the nop transceiver.
Also changed the signature of musb_platform_init() as now
board_data can be taken from musb itself.
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
---
NOP transceiver is getting registered in board files of OMAP3EVM
and OMAP4430 SDP as they use ISP150x and internal transceivers.
This registration in board file forces NOP transceiver to be
built into the kernel.
Fixing this by adding new flag '.neednop' within board_data
structure which would
Some of the boards based on OMAP3 (like OMAP3EVM) and all the
board on OMAP4 uses nop transceiver so register and unregister
it based on '.neednop' flag passed from board files.
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
---
drivers/usb/musb/omap2430.c |7 +++
1 files changed, 7
2010/5/27 Arve Hjønnevåg a...@android.com:
On Wed, May 26, 2010 at 6:16 AM, Alan Cox a...@lxorguk.ukuu.org.uk wrote:
Really, what are you getting at? Do you deny that there are programs,
that prevent a device from sleeping? (Just think of the bouncing
cows app)
And if you have two kernels,
On Thu, May 27, 2010 at 7:14 AM, Florian Mickler flor...@mickler.org wrote:
I'm not interested in abusing processes. I just think, this is in
limbo for too long already.
Just decide something. One way or the other. The world will continue.
Oh man, you rule the world eh? :)
~Vitaly
--
To
On Wed, 2010-05-26 at 23:40 +0200, ext Russell King - ARM Linux wrote:
On Wed, May 26, 2010 at 06:51:29AM -0700, Tony Lindgren wrote:
Yeah I'll do that once the dss2 code has been verified to work.
It'd help with this patch - it seems rx51 needs some additional stuff.
Any other OMAP
On Wed, May 26, 2010 at 3:54 PM, Florian Mickler flor...@mickler.org wrote:
It really comes down to a policy decision by the distribution maker.
And I don't think kernel upstream should be the one to force one way or
the other. So merging this patch set will allow android to continue
their
-Original Message-
From: linux-usb-ow...@vger.kernel.org
[mailto:linux-usb-ow...@vger.kernel.org] On Behalf Of Gupta, Ajay Kumar
Sent: Thursday, May 27, 2010 12:35 PM
To: linux-...@vger.kernel.org
Cc: linux-omap@vger.kernel.org; felipe.ba...@nokia.com;
amit.kuche...@verdurent.com;
On Thu, May 27, 2010 at 11:52:18AM +0300, Tomi Valkeinen wrote:
On Wed, 2010-05-26 at 23:40 +0200, ext Russell King - ARM Linux wrote:
On Wed, May 26, 2010 at 06:51:29AM -0700, Tony Lindgren wrote:
Yeah I'll do that once the dss2 code has been verified to work.
It'd help with this
On Thu, May 27, 2010 at 10:07:40AM +0530, DebBarma, Tarun Kanti wrote:
Note the different registers. Change r1, r2 to r0, r1 and it
should work.
Yes, that's right. I figured that out yesterday and confirmed the test
results. Thanks!
I've now committed a fix to change those registers.
-Original Message-
From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk]
Sent: Thursday, May 27, 2010 3:00 PM
To: DebBarma, Tarun Kanti
Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org
Subject: Re: [PATCH] ARM:VFPv3:enable {d16-d31} access
On Thu, May
Define platform data and setup GPIOs so that TI wl1251 wifi chip
and it's driver can function.
Signed-off-by: Grazvydas Ignotas nota...@gmail.com
---
I could have sent this earlier but it depended on the wifi tree,
hope this can still go in for -rc2, it's just platform data anyway.
On Thu, 2010-05-27 at 11:25 +0200, ext Russell King - ARM Linux wrote:
On Thu, May 27, 2010 at 11:52:18AM +0300, Tomi Valkeinen wrote:
I tested your lmb branch on OMAP 3430SDP board, and after removing the
topmost patch (ARM: use LMB to allocate system memory MMIO resource
structures)
On Wed, 26 May 2010 10:38:50 -0400 (EDT)
Alan Stern st...@rowland.harvard.edu wrote:
On Wed, 26 May 2010, Florian Mickler wrote:
I don't think that the in-kernel suspend block is a bad idea.
You could probably use the suspend-blockers unconditionally in the
suspend framework to
Nishanth Menon n...@ti.com wrote:
sgx, iva, l2cache, sgx, neon, isp are generic features, make
them generic features, current OMAP3 detection mechanism
is still retained. 192Mhz is more specific OMAP3 feature
so it is retained as is
Cc: Tony Lindgren t...@atomide.com
Cc: Angelo Arrifano
Hi,
While compiling for omap3_evm_defconfig, at the head of linux-omap, I encounter
these errors:
arch/arm/mach-omap2/built-in.o: In function `sr_configure_vp':
/home/premi/linux-pm/arch/arm/mach-omap2/smartreflex.c:315: undefined reference
to `omap_twl_uv_to_vsel'
ext Florian Mickler wrote:
Converting a driver to using any constraint-API would require analysing
what makes a driver refuse suspending in the old suspend handler and
then specify any no suspend (or whatever) constraint before those
conditions arise and clearing of the constraints when it is
ext Florian Mickler wrote:
Converting a driver to using any constraint-API would require analysing
what makes a driver refuse suspending in the old suspend handler and
then specify any no suspend (or whatever) constraint before those
conditions arise and clearing of the constraints when it is
From: Vishwanath BS vishwanath...@ti.com
OMAP3430/3630 has a Silicon bug because of which SDRC is
released from IDLE even before Core DPLL has locked. This leads
to undefined behaviour of SDRC DLL.
Bug Descritpion: The root cause of the issue is that SDRC IDLEREQ
is deasserted before DPLL3 has
From: Vaibhav Hiremath hvaib...@ti.com
Currently VPFE Capture driver and DM6446 CCDC driver is being
reused for AM3517. So this patch is preparing the Kconfig/makefile
for re-use of such IP's.
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
---
drivers/media/video/Kconfig | 61
From: Vaibhav Hiremath hvaib...@ti.com
AM3517 uses similar VPFE-CCDC hardware IP as in Davinci, so reusing
the driver.
Currently the davinci driver is hardly tied with ARCH_DAVINCI, which
was limiting AM3517 to reuse the driver. So created seperate Kconfig
file for davinci and added AM3517 to
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Premi, Sanjeev
Sent: Thursday, May 27, 2010 4:56 PM
To: linux-omap@vger.kernel.org
Subject: omap3 pm: dependency between opp layer and cpufreq
Hi,
While
The following set of patches applies on top of for-next branch.
http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git
Patches verified on: omap3430-SDP, omap3630-sdp, zoom3 and beagle board
And these are the patches required to address the following input -
1.
few functions added in gpmc module and to be used by other drivers like NAND.
E.g.: - ioctl function
- ecc functions
Signed-off-by: Sukumar Ghorai s-gho...@ti.com
---
arch/arm/mach-omap2/gpmc.c | 219 ++--
arch/arm/plat-omap/include/plat/gpmc.h |
Board file modified for not to provide gpmc phys_base address to nand driver.
The gpmc_nand_init funciton is now used to detect the nand and required to
adopt _prob function as in nand/omap2.c
Signed-off-by: Sukumar Ghorai s-gho...@ti.com
---
arch/arm/mach-omap2/board-cm-t35.c | 20
This patch removes direct reference of gpmc address from generic nand platform
code.
Nand platform code now uses wrapper functions which are implemented in gpmc
module.
Signed-off-by: Sukumar Ghorai s-gho...@ti.com
---
arch/arm/mach-omap2/gpmc-nand.c| 39 ++
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Premi, Sanjeev
Sent: Thursday, May 27, 2010 6:50 PM
To: linux-omap@vger.kernel.org
Subject: RE: omap3 pm: dependency between opp layer and cpufreq
[snip]--[snip]
On Thu, 27 May 2010, Florian Mickler wrote:
On Wed, 26 May 2010 22:03:37 +0200
Vitaly Wool vitalyw...@gmail.com wrote:
On Wed, May 26, 2010 at 9:56 PM, Florian Mickler flor...@mickler.org
wrote:
Your approach definitely sounds better than the current solution.
What about mapping
On Wed, 26 May 2010, Florian Mickler wrote:
On Wed, 26 May 2010 19:22:16 +0200 (CEST)
Thomas Gleixner t...@linutronix.de wrote:
On Wed, 26 May 2010, Florian Mickler wrote:
On the other hand, applications can say, they don't need that much
power and userspace guaranties and not take a
The value of mpurate is currently expected to be less
than 1000 when specified in MHz.
This patch raises this limit to 2000 to support 1GHz
capable processors. The new limit should be reasonable
for quite some time.
Signed-off-by: Sanjeev Premi pr...@ti.com
---
arch/arm/plat-omap/clock.c |3
The value of mpurate is currently expected to be less
than 1000 when specified in MHz.
This patch raises this limit to 2000 to support 1GHz
capable processors. The new limit should be reasonable
for quite some time.
Signed-off-by: Sanjeev Premi pr...@ti.com
---
v2: Removed a newline introduced
On Thu, May 27, 2010 at 12:39:43AM +0100, Alan Cox wrote:
- Supporting Android needs well good
- Opportunistic suspend good
- Manner in which interface is expressed to userspace bad
- Latency constraint interface would be better
- Your existing behaviour can be implemented by a simplistic
On Thu, 2010-05-27 at 15:06 +0100, Matthew Garrett wrote:
I don't entirely see how this works. In order to deal with poorly
written applications, it's necessary to (optionally, based on some
policy) ignore them when it comes to the scheduler. The problem is how
to implement the optional
On Wed, 26 May 2010, Arve Hjønnevåg wrote:
2010/5/26 Alan Cox a...@lxorguk.ukuu.org.uk:
On Wed, 26 May 2010 15:30:58 -0700
Arve Hjønnevåg a...@android.com wrote:
On Wed, May 26, 2010 at 6:16 AM, Alan Cox a...@lxorguk.ukuu.org.uk wrote:
Really, what are you getting at? Do you deny that
On Thu, May 27, 2010 at 04:28:51PM +0200, Peter Zijlstra wrote:
On Thu, 2010-05-27 at 15:06 +0100, Matthew Garrett wrote:
one way which indicates to the scheduler that tasks in TASK_RUNNING
should be scheduled, and when the session is idle we set the flag the
other way and all processes
On Thu, 2010-05-27 at 15:35 +0100, Matthew Garrett wrote:
On Thu, May 27, 2010 at 04:28:51PM +0200, Peter Zijlstra wrote:
On Thu, 2010-05-27 at 15:06 +0100, Matthew Garrett wrote:
one way which indicates to the scheduler that tasks in TASK_RUNNING
should be scheduled, and when the
On Thu, 2010-05-27 at 16:41 +0200, Peter Zijlstra wrote:
On Thu, 2010-05-27 at 15:35 +0100, Matthew Garrett wrote:
On Thu, May 27, 2010 at 04:28:51PM +0200, Peter Zijlstra wrote:
On Thu, 2010-05-27 at 15:06 +0100, Matthew Garrett wrote:
one way which indicates to the scheduler that tasks
Now, if the user is playing this game, you want it to be scheduled. If
the user has put down their phone and the screen lock has kicked in, you
don't want it to be scheduled. So we could imagine some sort of cgroup
that contains untrusted tasks - when the session is active we set a flag
I
Heck, for all I care, simply SIGKILL the thing and report it once the
user starts looking at his screen again.
Provide incentive for Joe Clicker to improve his app, instead of cope
with the shit he created.
That isn't helpful. But if you feel like that I suggest you run with your
memory
On Thu, 2010-05-27 at 16:05 +0100, Alan Cox wrote:
What is the problem here - your device driver for the display can block
tasks it doesn't want to use the display.
Very well put again.
I bet the next example is a proglet that does: while(1); without device
interaction :-).
--
To unsubscribe
If people don't mind, here is a greatly simplified summary of the
comments and objections I have seen so far on this thread:
The in-kernel suspend blocker implementation is okay, even
beneficial.
Opportunistic suspends are okay.
The proposed userspace API is too
On Thu, 2010-05-27 at 16:10 +0100, Alan Cox wrote:
Heck, for all I care, simply SIGKILL the thing and report it once the
user starts looking at his screen again.
Provide incentive for Joe Clicker to improve his app, instead of cope
with the shit he created.
That isn't helpful. But
On Thu, 2010-05-27 at 11:06 -0400, Alan Stern wrote:
Opportunistic suspends are okay.
The proposed userspace API is too Android-specific.
I would argue opportunistic suspends are not ok, and therefore the
proposed API is utterly irrelevant.
--
To unsubscribe from this list:
The proposal I made a couple of days ago removes this API and leaves
the other things (i.e., the in-kernel suspend blockers and
opportunistic suspend) intact. In place of the userspace
kernel-blocker API, Android would have to implement a power manager
process that would essentially juggle
On Thu, 27 May 2010 17:09:16 +0200
Peter Zijlstra pet...@infradead.org wrote:
On Thu, 2010-05-27 at 11:06 -0400, Alan Stern wrote:
Opportunistic suspends are okay.
The proposed userspace API is too Android-specific.
I would argue opportunistic suspends are not ok,
On Thu, 27 May 2010, Matthew Garrett wrote:
On Thu, May 27, 2010 at 12:39:43AM +0100, Alan Cox wrote:
- Supporting Android needs well good
- Opportunistic suspend good
- Manner in which interface is expressed to userspace bad
- Latency constraint interface would be better
- Your
On Thu, 2010-05-27 at 16:33 +0100, Alan Cox wrote:
On Thu, 27 May 2010 17:09:16 +0200
Peter Zijlstra pet...@infradead.org wrote:
On Thu, 2010-05-27 at 11:06 -0400, Alan Stern wrote:
Opportunistic suspends are okay.
The proposed userspace API is too
On Thu, 27 May 2010, Peter Zijlstra wrote:
On Thu, 2010-05-27 at 16:33 +0100, Alan Cox wrote:
On Thu, 27 May 2010 17:09:16 +0200
Peter Zijlstra pet...@infradead.org wrote:
On Thu, 2010-05-27 at 11:06 -0400, Alan Stern wrote:
Opportunistic suspends are okay.
This patchset introduces an approach to eliminate the direct calls
to follow_page and to the low level cache APIs.
The patchset works by caching the page information while memory
is mapped, and then using that information later when needed
instead of calling follow_page. The low level cache API
Enhance dmm_map_object to support additional mapping
and page information. This will be used to keep
track of mapping resources needed later to invoke
DMA transfers to/from the DSP.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
If you want, you can also reach me at ohadb at ti dot com .
Every time the MM application calls proc_map to map
a memory area, remember the details of that mapping,
together with the related page structures.
Whenever a buffer is unmapped, clean up the mapping
information resources.
This information is maintained as part of the
DMM resource tracking
Eliminate the call to follow_page. Instead, use the page
information that was kept during the proc_map call.
This also has the advantage that users can now only
specify memory areas that were previously mapped.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
You can also reach me at ohadb at
Instead of using low level cache manipulation API,
use the standard DMA API. This is achieved by adding
a proc_begin_dma function that takes a generic
dma_data_direction, and then implementing proc_flush_memory
and proc_invalidate_memory by means of proc_begin_dma
in the following manner:
* flush
Now that we use standard DMA API instead of low level cache
manipulation API, mem_flush_cache can be removed.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
If you want, you can also reach me at ohadb at ti dot com .
arch/arm/plat-omap/include/dspbridge/drv.h | 15
Add new dspbridge API that ends DMA transfers.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
If you want, you can also reach me at ohadb at ti dot com .
drivers/dsp/bridge/rmgr/proc.c | 68
1 files changed, 68 insertions(+), 0 deletions(-)
diff
Add two new dspbridge ioctls that mark the
beginnind and end of a DMA transfer.
The direction of the DMA transfer is given as a parameter,
thus all three directions (DMA_BIDIRECTIONAL, DMA_TO_DEVICE
and DMA_FROM_DEVICE) are supported.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
If you want,
On Thu, May 27, 2010 at 04:05:43PM +0100, Alan Cox wrote:
Now, if the user is playing this game, you want it to be scheduled. If
the user has put down their phone and the screen lock has kicked in, you
don't want it to be scheduled. So we could imagine some sort of cgroup
that contains
On Wednesday 26 May 2010 05:48:58 pm Kevin Hilman wrote:
FYI... this also works on OMAP2.
I tested it on my n810 along with UART hwmod conversion and it works
just fine there.
Is it somehow different from the basic 8250 driver on OMAP2? I've been
struggling to figure out why my N810's GPS
On Thu, 27 May 2010, Alan Stern wrote:
On Thu, 27 May 2010, Peter Zijlstra wrote:
On Thu, 2010-05-27 at 16:33 +0100, Alan Cox wrote:
On Thu, 27 May 2010 17:09:16 +0200
Peter Zijlstra pet...@infradead.org wrote:
On Thu, 2010-05-27 at 11:06 -0400, Alan Stern wrote:
No. Suspend blockers are designed to ensure that suspend isn't racy with
respect to wakeup events. The bit that mitigates badly written
applications is the bit where the scheduler doesn't run any more.
How does having applications taking blockers fix that - it makes it
worse. They are now
On Thu, May 27, 2010 at 05:16:15PM +0100, Alan Cox wrote:
I can't speak for Thomas, but I'm certainly not arguing that you don't
need something that looks more like the blocker side of the logic *in
kernel*, because there is stuff that you want to express which isn't tied
to the task.
Sure,
On 05/27/2010 01:24 PM, S, Venkatraman wrote:
Nishanth Menonn...@ti.com wrote:
[..]
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index 809e13a..01555b6 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -161,7 +161,7 @@ static void __init
Hi Dmitry,
On Tue, May 18, 2010 at 06:13:48PM -0500, Arce, Abraham wrote:
Hi,
Here you have the list of changes done so far for OMAP4 Keyboard
Controller Support v2. I'll appreciate if someone else has more comments
to share.
I finally had a chance to review the patches and I do
On 05/27/2010 01:25 PM, Premi, Sanjeev wrote:
Hi,
While compiling for omap3_evm_defconfig, at the head of linux-omap, I encounter
these errors:
arch/arm/mach-omap2/built-in.o: In function `sr_configure_vp':
/home/premi/linux-pm/arch/arm/mach-omap2/smartreflex.c:315: undefined reference
to
On Thu, 27 May 2010 16:10:54 +0100
Alan Cox a...@lxorguk.ukuu.org.uk wrote:
The reality is you need a sane, generic, race free way to express your
requirements (eg for hard RT) and ditto for constraining the expression
(for 'crapplications')
And the thing is, even a well written app can be a
On Thu, May 27, 2010 at 05:06:23PM +0200, ext Alan Stern wrote:
If people don't mind, here is a greatly simplified summary of the
comments and objections I have seen so far on this thread:
The in-kernel suspend blocker implementation is okay, even
beneficial.
I disagree here.
On Thu, 27 May 2010 17:07:14 +0100
Matthew Garrett mj...@srcf.ucam.org wrote:
On Thu, May 27, 2010 at 04:05:43PM +0100, Alan Cox wrote:
Now, if the user is playing this game, you want it to be scheduled. If
the user has put down their phone and the screen lock has kicked in, you
don't
On Thu, 27 May 2010, Matthew Garrett wrote:
On Thu, May 27, 2010 at 05:32:56PM +0200, Thomas Gleixner wrote:
On Thu, 27 May 2010, Matthew Garrett wrote:
Now let's try this in the Android world. The user hits a key and the
system wakes up. The input layer takes a suspend block. The
On Thu, 27 May 2010, Alan Cox wrote:
That's all your need to do it right.
In kernel yes your device driver probably does need to say things like
'Don't go below C6 for a moment' just as a high speed serial port might
want to say 'Nothing over 10mS please'
I can't speak for Thomas, but I'm
On Thu, 27 May 2010, Felipe Balbi wrote:
On Thu, May 27, 2010 at 05:06:23PM +0200, ext Alan Stern wrote:
If people don't mind, here is a greatly simplified summary of the
comments and objections I have seen so far on this thread:
The in-kernel suspend blocker implementation is okay,
On Thu, 27 May 2010, Matthew Garrett wrote:
On Thu, May 27, 2010 at 05:16:15PM +0100, Alan Cox wrote:
I can't speak for Thomas, but I'm certainly not arguing that you don't
need something that looks more like the blocker side of the logic *in
kernel*, because there is stuff that you want
On Thu, May 27, 2010 at 07:04:38PM +0200, Thomas Gleixner wrote:
On Thu, 27 May 2010, Matthew Garrett wrote:
Sure, if you're not using opportunistic suspend then I don't think
there's any real need for the userspace side of this. The question is
how to implement something with the useful
On Thu, 2010-05-27 at 18:07 +0100, Matthew Garrett wrote:
On Thu, May 27, 2010 at 07:04:38PM +0200, Thomas Gleixner wrote:
On Thu, 27 May 2010, Matthew Garrett wrote:
Sure, if you're not using opportunistic suspend then I don't think
there's any real need for the userspace side of this.
On Thu, 2010-05-27 at 13:04 -0400, Alan Stern wrote:
Does this mean you believe echo mem /sys/power/state is bad and
should be removed? Or echo disk /sys/power/state? They pay no
attention to latencies or other requirements.
Those are a whole different beast, those are basically a
On Thu, 27 May 2010, Matthew Garrett wrote:
On Thu, May 27, 2010 at 06:45:25PM +0200, Thomas Gleixner wrote:
On Thu, 27 May 2010, Matthew Garrett wrote:
No. Suspend blockers are designed to ensure that suspend isn't racy with
respect to wakeup events. The bit that mitigates badly
On Thu, May 27, 2010 at 07:13:11PM +0200, Peter Zijlstra wrote:
On Thu, 2010-05-27 at 18:07 +0100, Matthew Garrett wrote:
No. The useful property of opportunistic suspend is that nothing gets
scheduled. That's fundamentally different to a deep idle state.
I think Alan and Thomas but
On Thu, May 27, 2010 at 07:04:24PM +0200, ext Alan Stern wrote:
On Thu, 27 May 2010, Felipe Balbi wrote:
On Thu, May 27, 2010 at 05:06:23PM +0200, ext Alan Stern wrote:
If people don't mind, here is a greatly simplified summary of the
comments and objections I have seen so far on this thread:
Hi,
On Thu, May 27, 2010 at 07:04:38PM +0200, ext Thomas Gleixner wrote:
Opportunistic suspend is just a deep idle state, nothing else. If the
overall QoS requirements allow to enter that deep idle state then the
kernel goes there. Same decision as for all other idle states. You
don't need any
On Thu, 2010-05-27 at 18:16 +0100, Matthew Garrett wrote:
On Thu, May 27, 2010 at 07:13:11PM +0200, Peter Zijlstra wrote:
On Thu, 2010-05-27 at 18:07 +0100, Matthew Garrett wrote:
No. The useful property of opportunistic suspend is that nothing gets
scheduled. That's fundamentally
On Thu, 27 May 2010 18:45:25 +0200 (CEST)
Thomas Gleixner t...@linutronix.de wrote:
The whole notion of treating suspend to RAM any different than a plain
idle C-State is wrong. It's not different at all. You just use a
different mechanism which has longer takedown and wakeup latencies and
On Thu, May 27, 2010 at 07:15:31PM +0200, Thomas Gleixner wrote:
On Thu, 27 May 2010, Matthew Garrett wrote:
You still need the in-kernel suspend blockers if you want to guarantee
that you can't lose wakeup events. But yes, if you're not concerned
handling badly behaved applications then
Opportunistic suspend is just a deep idle state, nothing else.
No. The useful property of opportunistic suspend is that nothing gets
scheduled. That's fundamentally different to a deep idle state.
Nothing gets scheduled in a deep idle state either - its idle. We leave
the idle state to
On Thu, 27 May 2010, Alan Stern wrote:
On Thu, 27 May 2010, Thomas Gleixner wrote:
The whole notion of treating suspend to RAM any different than a plain
idle C-State is wrong. It's not different at all. You just use a
different mechanism which has longer takedown and wakeup latencies
On Thu, May 27, 2010 at 07:20:56PM +0200, Peter Zijlstra wrote:
Suppose X (or whatever windowing system) will block all clients that try
to draw when you switch off your screen.
How would we not wake them when we do turn the screen back on and start
servicing the pending requests again?
On Thu, 2010-05-27 at 19:21 +0200, Florian Mickler wrote:
On Thu, 27 May 2010 18:45:25 +0200 (CEST)
Thomas Gleixner t...@linutronix.de wrote:
The whole notion of treating suspend to RAM any different than a plain
idle C-State is wrong. It's not different at all. You just use a
different
On Thu, 27 May 2010, Alan Stern wrote:
On Thu, 27 May 2010, Felipe Balbi wrote:
On Thu, May 27, 2010 at 05:06:23PM +0200, ext Alan Stern wrote:
If people don't mind, here is a greatly simplified summary of the
comments and objections I have seen so far on this thread:
The
On Thu, May 27, 2010 at 06:30:41PM +0100, Alan Cox wrote:
Opportunistic suspend is just a deep idle state, nothing else.
No. The useful property of opportunistic suspend is that nothing gets
scheduled. That's fundamentally different to a deep idle state.
Nothing gets scheduled in a
On Thu, 2010-05-27 at 18:23 +0100, Matthew Garrett wrote:
ACPI provides no guarantees about what level of hardware functionality
remains during S3. You don't have any useful ability to determine which
events will generate wakeups. And from a purely practical point of view,
since the latency
On Thu, 2010-05-27 at 18:25 +0100, Matthew Garrett wrote:
On Thu, May 27, 2010 at 07:20:56PM +0200, Peter Zijlstra wrote:
Suppose X (or whatever windowing system) will block all clients that try
to draw when you switch off your screen.
How would we not wake them when we do turn the
On Thu, 27 May 2010, Peter Zijlstra wrote:
On Thu, 2010-05-27 at 13:04 -0400, Alan Stern wrote:
Does this mean you believe echo mem /sys/power/state is bad and
should be removed? Or echo disk /sys/power/state? They pay no
attention to latencies or other requirements.
Those are a
On Thu, May 27, 2010 at 07:24:02PM +0200, Thomas Gleixner wrote:
Oh no. They paper over a short coming. If there is a pending event,
the kernel knows that. It just does not make use of this
information. Blockers just paper over this by sprinkling
do_not_suspend() calls all over the place.
On Thu, 27 May 2010, Peter Zijlstra wrote:
On Thu, 2010-05-27 at 18:07 +0100, Matthew Garrett wrote:
On Thu, May 27, 2010 at 07:04:38PM +0200, Thomas Gleixner wrote:
Opportunistic suspend is just a deep idle state, nothing else.
No. The useful property of opportunistic suspend is that
On Thu, 2010-05-27 at 13:29 -0400, Alan Stern wrote:
They may be different conceptually. Nevertheless, Android uses forced
suspend as a form of power saving. Until better mechanisms are in
place, it makes sense.
So let them, doesn't mean we have to merge it. Or will you saw your foot
On Thu, May 27, 2010 at 07:28:08PM +0200, Peter Zijlstra wrote:
On Thu, 2010-05-27 at 18:25 +0100, Matthew Garrett wrote:
How (and why) does the WoL (which may be *any* packet, not just a magic
one) turn the screen back on?
Why would you care about the screen for a network event?
Because
On Thu, 2010-05-27 at 18:31 +0100, Matthew Garrett wrote:
Even if we could use suspend-via-deep-idle-state on PCs,
( see Alan Cox's argument on PCs )
we still need to be able to enter suspend while the system isn't idle.
_WHY_!?
We've been trying to tell you you don't need that.
--
To
On Thu, 2010-05-27 at 18:32 +0100, Matthew Garrett wrote:
On Thu, May 27, 2010 at 07:28:08PM +0200, Peter Zijlstra wrote:
On Thu, 2010-05-27 at 18:25 +0100, Matthew Garrett wrote:
How (and why) does the WoL (which may be *any* packet, not just a magic
one) turn the screen back on?
On Thu, 27 May 2010, Thomas Gleixner wrote:
Crap. Stop beating on those lost wakeup events. If we lose them then
the drivers are broken and do not handle the switch over correctly. Or
the suspend mechanism is broken as it does not evaluate the system
state correctly. Blockers are just
On Thu, May 27, 2010 at 07:34:40PM +0200, Peter Zijlstra wrote:
we still need to be able to enter suspend while the system isn't idle.
_WHY_!?
Because if I'm running a kernel build in a tmpfs and I hit the sleep
key, I need to go to sleep. Blocking processes on driver access isn't
On Thu, 27 May 2010, Thomas Gleixner wrote:
Does this mean you believe echo mem /sys/power/state is bad and
should be removed? Or echo disk /sys/power/state? They pay no
mem should be replaced by an idle suspend to ram mechanism
In other words, you are suggesting that not only should
1 - 100 of 222 matches
Mail list logo
