On Mon, Feb 09, 2015 at 10:27:32AM +0200, Peter Ujfalusi wrote:
As I recall there is a plan to remove the hwmod static database and move it or
generate it from DT? Not sure when and how this will be done, but will it
affect the lockdep_set_class() way?
Yes, struct lock_class_key wants to be in
On Fri, Feb 06, 2015 at 02:48:34PM +0200, Peter Ujfalusi wrote:
Hi,
In case when hwmods are used in nested way the lockdep validator will print
out
a warning message about possible deadlock situation:
[4.514882] =
[4.520530] [ INFO:
On Fri, Feb 06, 2015 at 06:05:32PM +0200, Peter Ujfalusi wrote:
Certainly looks much simpler, but it adds quite a bit of data to the
omap_hwmod struct, and we have a _lot_ of them for omap2plus configuration.
ls -al vmlinux
w/o any the lockdep warning fixes:
110109168
With my series
On Fri, 2012-10-19 at 16:54 -0700, Kevin Hilman wrote:
So I did the same thing for my ARM SoC, and it definitley stops the RT
throttling.
However, it has the undesriable (IMO) side effect of making timed printk
output rather unhelpful for debugging suspend/resume since printk time
stays
On Thu, 2012-10-18 at 08:51 +0300, Felipe Balbi wrote:
So the primary question remains: is RT runtime supposed to include the
time spent suspended? I suspect not.
you might be right there, though we need Thomas or Peter to answer :-s
re, sorry both tglx and I have been traveling, he
On Thu, 2011-09-08 at 14:47 +0800, TAO HU wrote:
We seems got a schedule/migration issue in a OMAP4430 dual-core system.
The kernel base is 2.6.35.7 and we're using CFS.
step 1, try with a kernel that isn't quite as fossilized
(3.0 or even better 3.1-rc)
step 2, if no luck, report
On Mon, 2011-02-21 at 16:38 +0200, David Cohen wrote:
Currently sched.h and wait.h have circular dependency between both.
wait.h defines macros wake_up*() which use macros TASK_* defined by
sched.h. But as sched.h indirectly includes wait.h, such wait.h header
file can't include sched.h too.
On Mon, 2011-02-21 at 18:03 +0200, David Cohen wrote:
On Mon, Feb 21, 2011 at 5:54 PM, Peter Zijlstra pet...@infradead.org wrote:
On Mon, 2011-02-21 at 16:38 +0200, David Cohen wrote:
Currently sched.h and wait.h have circular dependency between both.
wait.h defines macros wake_up*() which
On Mon, 2011-02-21 at 18:29 +0200, Felipe Balbi wrote:
Hi,
On Mon, Feb 21, 2011 at 05:20:45PM +0100, Peter Zijlstra wrote:
I think Alexey already told you what you done wrong.
Also, I really don't like the task_state.h header, it assumes a lot of
things it doesn't include
On Mon, 2011-02-21 at 18:54 +0200, Felipe Balbi wrote:
What you seem to have missed is that sched.h doesn't include wait.h, it
includes completion.h and completion.h needs wait.h due the
wait_queue_head_t it uses.
Yeah, so? sched.h doesn't need completion.h, but like with wait.h I'd
argue the
On Tue, 2010-10-26 at 11:56 -0500, Pierre Tardy wrote:
+ trace_runtime_pm_usage(dev, atomic_read(dev-power.usage_count)+1);
atomic_inc(dev-power.usage_count);
That's terribly racy..
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message
On Tue, 2010-10-19 at 13:45 +0200, Ingo Molnar wrote:
* Thomas Renninger tr...@suse.de wrote:
Most definitely. It's no accident that it took such a long time for this
issue
to be raised in the first place. It's a rare occurance -
Do you agree that this occurance happened now
On Mon, 2010-10-18 at 09:44 +0200, Ohad Ben-Cohen wrote:
OMAP4 introduces a Spinlock hardware module, which provides hardware
assistance for synchronization and mutual exclusion between heterogeneous
processors and those not operating under a single, shared operating system
(e.g. OMAP4 has
On Mon, 2010-10-18 at 14:35 +0100, Russell King - ARM Linux wrote:
On Mon, Oct 18, 2010 at 02:46:55PM +0200, Peter Zijlstra wrote:
On Mon, 2010-10-18 at 09:44 +0200, Ohad Ben-Cohen wrote:
OMAP4 introduces a Spinlock hardware module, which provides hardware
assistance for synchronization
On Mon, 2010-10-18 at 16:28 +0200, Ohad Ben-Cohen wrote:
On Mon, Oct 18, 2010 at 3:43 PM, Peter Zijlstra pet...@infradead.org wrote:
Right, so the problem is that there simply is no way to do atomic memory
access from these auxiliary processing units wrt the main CPU?
Yes. There are a few
On Mon, 2010-10-18 at 16:27 +0100, Catalin Marinas wrote:
Peter Zijlstra pet...@infradead.org wrote:
On Mon, 2010-10-18 at 14:35 +0100, Russell King - ARM Linux wrote:
In any case, Linux's spinlock API (or more accurately, the ARM exclusive
access instructions) relies upon hardware
On Mon, 2010-10-18 at 17:35 +0200, Ohad Ben-Cohen wrote:
On Mon, Oct 18, 2010 at 5:32 PM, Peter Zijlstra pet...@infradead.org wrote:
Sure, but you can 'easily' extend your coherency protocols with support
In our case, there are no coherency protocols supported between the
A9, M3 and the DSP
On Mon, 2010-10-18 at 16:51 +0100, Catalin Marinas wrote:
Peter Zijlstra pet...@infradead.org wrote:
On Mon, 2010-10-18 at 16:27 +0100, Catalin Marinas wrote:
Peter Zijlstra pet...@infradead.org wrote:
On Mon, 2010-10-18 at 14:35 +0100, Russell King - ARM Linux wrote:
In any case
On Sat, 2010-10-09 at 21:39 -0400, Steven Rostedt wrote:
I've been hesitant in the pass from doing the TRACE_EVENT_ABI()
before, because Peter Zijlstra (who is currently MIA) has been strongly
against it.
I see no point in the TRACE_EVENT_ABI() because if I need to change such
a tracepoint
On Wed, 2010-09-22 at 09:32 -0700, Arjan van de Ven wrote:
What are the apps that are using it? I know about builtin-timechart,
pytimechart. Is powertop using this as well?
powertop 2.x codebase is as well.
and a bunch of tools we have internal here at Intel.
the thing with ABIs is
On Wed, 2010-09-22 at 09:32 -0700, Arjan van de Ven wrote:
Also, please don't cross-post to subscriber only lists, that's annoying
as hell.
(removed the disc...@lesswatts list)
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to
On Wed, 2010-09-22 at 10:06 -0700, Arjan van de Ven wrote:
In this case we're talking about basically a suprious rename of
something that isn't really an improvement
(because it makes it harder to subscribe to only one type of event)...
that's not a good thing.
People have been talking
On Wed, 2010-09-22 at 14:15 -0400, Steven Rostedt wrote:
On Wed, 2010-09-22 at 19:30 +0200, Peter Zijlstra wrote:
On Wed, 2010-09-22 at 10:06 -0700, Arjan van de Ven wrote:
That said, I really didn't read this discussion much, but your stance
seems to be that any tracepoint you use
On Wed, 2010-09-22 at 14:36 -0400, Steven Rostedt wrote:
I still don't see why you need TRACE_EVENT_ABI for that, if its the same
name and the format can be extended you get the same results with what
we've got. Apps need to read/parse the format thing anyway.
Just a marker that these
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 same
On Fri, 2010-06-04 at 17:10 -0700, Arve Hjønnevåg wrote:
Trusted processes are assumed to be sane and idle when there is nothing
for them to do, allowing the machine to go into deep idle states.
Neither the kernel nor our trusted user-space code currently meets
this criteria.
Then both
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 that the
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.
I
On Fri, 2010-06-04 at 01:23 +0200, Ingo Molnar wrote:
Btw., i'd like to summarize the scheduler based suspend scheme proposed by
Thomas Gleixner, Peter Zijlstra and myself. I found no good summary of it in
the big thread, and there are also new elements of the proposal:
Just to clarify, my
On Fri, 2010-06-04 at 11:43 +0200, Peter Zijlstra wrote:
I still believe containment is a cgroup problem. The freeze/snapshot/resume
container folks seem to face many of the same problems. Including the
pending timer one I suspect. Lets solve it there.
While talking to Thomas about this, we'd
On Fri, 2010-06-04 at 12:03 +0200, Ingo Molnar wrote:
The only 'interesting' issue I can see here is that if you create 1000
CLOCK_MONOTONIC namepaces, we'd need to have a tree of trees in order to
efficiently find the leftmost timer.
Realistically Android userspace would create just a
On Fri, 2010-06-04 at 12:11 +0200, Thomas Gleixner wrote:
On Fri, 4 Jun 2010, Peter Zijlstra wrote:
On Fri, 2010-06-04 at 11:43 +0200, Peter Zijlstra wrote:
I still believe containment is a cgroup problem. The
freeze/snapshot/resume
container folks seem to face many of the same
On Fri, 2010-06-04 at 01:56 -0700, Arve Hjønnevåg wrote:
On Fri, Jun 4, 2010 at 1:34 AM, Ingo Molnar mi...@elte.hu wrote:
* Arve Hj?nnev?g a...@android.com wrote:
[...]
Why do you need to track input wakeups? It's rather fragile and rather
unnecessary [...]
Because we have
On Wed, 2010-06-02 at 22:13 +0200, Florian Mickler wrote:
On Wed, 02 Jun 2010 12:21:28 +0200
Peter Zijlstra pet...@infradead.org 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
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 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
On Thu, 2010-06-03 at 16:12 +0200, Florian Mickler wrote:
On Thu, 03 Jun 2010 09:40:02 +0200
Peter Zijlstra pet...@infradead.org 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
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 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 issues
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
On Wed, 2010-06-02 at 03:00 -0700, Arve Hjønnevåg wrote:
2010/6/2 Peter Zijlstra pet...@infradead.org:
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
On Sat, 2010-05-29 at 11:10 -0500, James Bottomley wrote:
Not using suspend is exactly the point. As Alan has argued, propagating
suspend blockers up into all regions of userspace will take much longer
than fixing the hardware.
Strange, that's not what I heard as the possible solution.
On Sat, 2010-05-29 at 11:10 -0500, James Bottomley wrote:
If current hardware can't cope, too friggin bad, get better hardware.
But the truth is, all your OMAP phones really can deal with it.
That's rubbish and you know it. We do software workarounds for hardware
problems all the time
On Sat, 2010-05-29 at 11:10 -0500, James Bottomley wrote:
Correct, I strongly oppose using suspend. Not running runnable tasks is
not a sane solution.
Look, this is getting into the realms of a pointless semantic quibble.
The problem is that untrusted tasks need to be forcibly suspended
On Fri, 2010-05-28 at 23:44 +0200, Rafael J. Wysocki wrote:
Consider updatedb or another file indexing ... thing on a laptop. I certainly
don't want anything like this to run and drain my battery, even if it has
already been started when the machine was on AC power. Now, of course,
I can
On Sat, 2010-05-29 at 00:18 +0200, Rafael J. Wysocki wrote:
On Friday 28 May 2010, Peter Zijlstra wrote:
On Fri, 2010-05-28 at 00:50 +0100, Alan Cox wrote:
Today idle means no task running
If you are prepared to rephrase that as no task that matters is running
what would need
On Fri, 2010-05-28 at 17:43 -0700, Arve Hjønnevåg wrote:
On Fri, May 28, 2010 at 12:11 AM, Peter Zijlstra pet...@infradead.org wrote:
On Fri, 2010-05-28 at 00:31 -0400, ty...@mit.edu wrote:
Keep in mind, though, that a solution which is acceptable for Android
has to include making sure
On Thu, 2010-05-27 at 20:59 -0400, Alan Stern wrote:
On Fri, 28 May 2010, Rafael J. Wysocki wrote:
And the forced-suspend design relies on the fact that processes remain
frozen throughout. If we leave some processes unfrozen and one of them
somehow becomes runnable, that means we
On Fri, 2010-05-28 at 00:31 -0400, ty...@mit.edu wrote:
Keep in mind, though, that a solution which is acceptable for Android
has to include making sure that crappy applications don't cause the
battery to get drained. There seem to be some people who seem
adamently against this requirement.
On Thu, 2010-05-27 at 17:49 -0700, Mike Chan wrote:
Even if we used the proposed QoS replacement, are there suggestions on
how to keep the cpu idle for longer than 2 seconds in Linux without
using suspend?
What exactly is stopping it from being idle?
--
To unsubscribe from this list: send the
On Thu, 2010-05-27 at 17:45 -0700, Arve Hjønnevåg wrote:
What happens if the user presses the button right before you set QoS
of 'user apps' to QS_NONE?
To me it looks like this solution would result in this sequence which
may ignore the button press:
Button pushed
Button
On Fri, 2010-05-28 at 00:50 +0100, Alan Cox wrote:
Today idle means no task running
If you are prepared to rephrase that as no task that matters is running
what would need to answer ?
I'm not sure we need or want to go there.
Why not simply let upatedb block on its IO because its QoS policy
On Fri, 2010-05-28 at 13:21 +0100, Alan Cox wrote:
[Total kernel changes
Ability to mark/unmark a scheduler control group as outside of
some parts of idle consideration. Generically useful and
localised. Group latency will do most jobs fine (Zygo is correct
On Fri, 2010-05-28 at 14:02 +0100, Alan Cox wrote:
On Fri, 28 May 2010 14:30:36 +0200
Peter Zijlstra pet...@infradead.org wrote:
On Fri, 2010-05-28 at 13:21 +0100, Alan Cox wrote:
[Total kernel changes
Ability to mark/unmark a scheduler control group as outside
On Fri, 2010-05-28 at 15:20 +0200, Peter Zijlstra wrote:
On Fri, 2010-05-28 at 14:02 +0100, Alan Cox wrote:
On Fri, 28 May 2010 14:30:36 +0200
Peter Zijlstra pet...@infradead.org wrote:
On Fri, 2010-05-28 at 13:21 +0100, Alan Cox wrote:
[Total kernel changes
Ability
On Fri, 2010-05-28 at 10:35 -0400, Alan Stern wrote:
The app is busy doing something else unimportant
We do into power save
Push a button, generate an IRQ
Come out of power save
No app to poke
* System goes back to sleep and eventually wakes up
On Fri, 2010-05-28 at 13:27 -0400, Zygo Blaxell wrote:
From my reading of this thread, there's a lot of overlap between
suspendblockers and constraints. Many use cases are served equally
well with one or the other,
If using suspend-blockers,
Please explain to me how:
- I will avoid the
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 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
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
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
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:
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 Android
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, 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, 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, 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
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, 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 Thu, 2010-05-27 at 18:40 +0100, Matthew Garrett wrote:
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
On Thu, 2010-05-27 at 19:42 +0200, Florian Mickler wrote:
If in the imaginery situation where userspace can aquire certain
wakeup-constraints and loose certain wakeup-constraints, then it could
be that the system enters suspend without empty runqueues.
No. Wakeup constaints simply delay
On Thu, 2010-05-27 at 13:44 -0400, Alan Stern wrote:
You close your laptop's lid and throw the machine into a backpack. At
that time you want it to suspend even though it may not be idle.
We've been trying to tell you you don't need that.
And I'm trying to tell you that you do.
Shall
On Thu, 2010-05-27 at 18:52 +0100, Matthew Garrett wrote:
If that's what you're aiming for then you don't need to block
applications on hardware access because they should all already have
idled themselves.
Correct, a well behaved app would have. I thought we all agreed that
well behaved
On Thu, 2010-05-27 at 18:57 +0100, Matthew Garrett wrote:
On Thu, May 27, 2010 at 07:52:59PM +0200, Peter Zijlstra wrote:
Shall we henceforth stop confusing forced suspend for laptops and
powersaving a running system?
If you want to support forced suspend for laptops and you want
On Thu, 2010-05-27 at 18:54 +0100, Matthew Garrett wrote:
On Thu, May 27, 2010 at 07:52:09PM +0200, Peter Zijlstra wrote:
How so, event happens on hardware level, IRQ gets raised, CPU wakes up,
handler gets run, handler generates a task wakeup, runqueue isn't empty,
we run stuff
On Thu, 2010-05-27 at 19:14 +0100, Matthew Garrett wrote:
If I get a WoL
packet in the 0.5 of a second between userspace deciding to suspend and
actually doing so, the system shouldn't suspend.
Please re-read Thomas' description of how a driver should do the state
transition.
So either we
On Thu, 2010-05-27 at 19:17 +0100, Matthew Garrett wrote:
It's blocked on the screen being turned off. It's supposed to be reading
a network packet. How does it ever get to reading the network packet?
Its blocked because its a buggy app, who cares about misbehaviour in a
buggy app?
If it
On Thu, 2010-05-27 at 15:19 -0400, Alan Stern wrote:
On Thu, 27 May 2010, Peter Zijlstra wrote:
I still don't see how blocking applications will cause missed wakeups in
anything but a buggy application at worst, and even those will
eventually get the event when they unblock.
What
On Wed, 2010-05-26 at 02:41 -0700, Arve Hjønnevåg wrote:
On Wed, May 26, 2010 at 1:47 AM, Peter Zijlstra pet...@infradead.org wrote:
On Tue, 2010-05-25 at 01:38 +0200, Rafael J. Wysocki wrote:
This of course will lead to a scattering of suspend blockers into any
drivers/subsystems
On Wed, 2010-05-26 at 12:02 +0200, Florian Mickler wrote:
The summary is: The device this kernel is running on dosn't want to
(or can) rely on userspace to save power. This is because it is an open
system, without an app-store or the like. Everyone can run what he
wants.
So anything relying
On Wed, 2010-05-26 at 03:06 -0700, Arve Hjønnevåg wrote:
I was not talking about our user-space code. Suspend has to be called
by a running thread, so at least one runqueue is not empty.
But why would you need to suspend if the machine is fully idle?
Is it because you're using broken hardware
On Wed, 2010-05-26 at 03:25 -0700, Arve Hjønnevåg wrote:
and on systems where the
same power state can be used from idle and suspend, we use suspend so
we can stay in the low power state for minutes to hours instead of
milliseconds to seconds.
So don't you think working on making it possible
On Wed, 2010-05-26 at 03:40 -0700, Arve Hjønnevåg wrote:
2010/5/26 Peter Zijlstra pet...@infradead.org:
On Wed, 2010-05-26 at 03:25 -0700, Arve Hjønnevåg wrote:
and on systems where the
same power state can be used from idle and suspend, we use suspend so
we can stay in the low power
On Wed, 2010-05-26 at 03:53 -0700, Arve Hjønnevåg wrote:
2010/5/26 Peter Zijlstra pet...@infradead.org:
On Wed, 2010-05-26 at 03:40 -0700, Arve Hjønnevåg wrote:
2010/5/26 Peter Zijlstra pet...@infradead.org:
On Wed, 2010-05-26 at 03:25 -0700, Arve Hjønnevåg wrote:
and on systems
On Wed, 2010-05-26 at 14:33 +0200, Florian Mickler wrote:
On Wed, 26 May 2010 15:29:32 +0300
Felipe Balbi felipe.ba...@nokia.com wrote:
hi,
On Wed, May 26, 2010 at 02:24:30PM +0200, ext Florian Mickler wrote:
And if you have two kernels, one with which your device is dead after 1
On Wed, 2010-05-26 at 13:35 +0100, Alan Cox wrote:
This is an area where machines are improving and where the ability to
do stuff like autosuspend, the technology like the OLPC screen and so on
create an incentive for the BIOS and platform people to improve their
bits of it.
But do you think
On Wed, 2010-05-26 at 14:54 +0200, Florian Mickler 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.
That's exactly what we always do. If we were not to do so, the kernel
would be a
On Wed, 2010-05-26 at 15:03 +0200, Florian Mickler wrote:
The kernel can not win if it does not try to integrate any use of it.
If we'd integrate every patch that came to lkml, you'd run away
screaming.
We most certainly do not want to integrate _any_ use.
--
To unsubscribe from this list: send
On Wed, 2010-05-26 at 17:11 +0200, Florian Mickler wrote:
I'm not saying that your argument is not valid. But why don't you look
at suspend blockers as a contract between userspace and kernelspace? An
Opt-In to the current guarantees the kernel provides in the non-suspend
case.
That's
On Wed, 2010-05-26 at 17:11 +0200, Florian Mickler wrote:
If you don't want to suspend while
looking at the bouncing-cow, you have to take a suspend blocker and
make yourself a user-visible power-eater, or don't do
echo opportunistic /sys/power/policy
How about we don't merge that junk
On Wed, 2010-05-26 at 17:40 +0200, Florian Mickler wrote:
On Wed, 26 May 2010 17:15:47 +0200
Peter Zijlstra pet...@infradead.org wrote:
On Wed, 2010-05-26 at 17:11 +0200, Florian Mickler wrote:
I'm not saying that your argument is not valid. But why don't you look
at suspend blockers
On Wed, 2010-05-19 at 11:30 +0200, Thomas Renninger wrote:
This is a cleanup against current linux-2.6 Linus tree.
Having CONFIG_CGROUP_CPUACCT code in kernel/sched.c looks wrong.
Move this out to kernel/cgroup_cpuaccount.c
Test compiled with and without CONFIG_CGROUP_CPUACCT set
On Wed, 2010-05-19 at 11:37 +0200, Peter Zijlstra wrote:
On Wed, 2010-05-19 at 11:30 +0200, Thomas Renninger wrote:
This is a cleanup against current linux-2.6 Linus tree.
Having CONFIG_CGROUP_CPUACCT code in kernel/sched.c looks wrong.
Move this out to kernel/cgroup_cpuaccount.c
97 matches
Mail list logo
