* Roedel, Joerg joerg.roe...@amd.com wrote:
(Cc'ing Ingo)
On Wed, Jun 08, 2011 at 04:34:18AM -0400, Ohad Ben-Cohen wrote:
Create a dedicated iommu drivers folder, put the base iommu code there,
and move the existing IOMMU API users as well (msm-iommu, amd_iommu and
intel-iommu).
* Jean Pihet jean.pi...@newoldbits.com wrote:
Adding l-o and linux-pm MLs. The original post is at
http://www.spinics.net/lists/kernel/msg1186554.html
On Fri, May 13, 2011 at 4:48 PM, Ingo Molnar mi...@elte.hu wrote:
* jean.pi...@newoldbits.com jean.pi...@newoldbits.com wrote:
From
* David Brown dav...@codeaurora.org wrote:
When we push back, there is a good chance they just won't bother, not because
they don't want to do it, but because it doesn't fit a schedule, and there is
already something else for them to work on.
So what's the right answer here. [...]
IMO
* Nicolas Pitre n...@fluxnic.net wrote:
On Wed, 30 Mar 2011, da...@lang.hm wrote:
back in the early days of the PCs, different systems from different vendors
had different bus types, peripherals at different addresses, etc. that
didn't
make all of those vendors systems different
* Russell King - ARM Linux li...@arm.linux.org.uk wrote:
On Thu, Mar 31, 2011 at 10:06:34AM +0200, Ingo Molnar wrote:
Having strong, effective platform abstractions inside the kernel really
helps
even if the hardware space itself is inevitably fragmented: both powerpc
and
x86 has
* jean.pi...@newoldbits.com jean.pi...@newoldbits.com wrote:
From: Jean Pihet j-pi...@ti.com
Uses the machine_suspend trace point, called from the
generic kernel suspend_enter function.
Signed-off-by: Jean Pihet j-pi...@ti.com
CC: Thomas Renninger tr...@suse.de
---
* Thomas Renninger tr...@suse.de wrote:
Changes in V2:
- Introduce PWR_EVENT_EXIT instead of 0 to mark non-power state
- Use u32 instead of u64 for cpuid, state which is by far enough
New power trace events:
power:processor_idle
power:processor_frequency
power:machine_suspend
* Arjan van de Ven ar...@linux.intel.com wrote:
On 10/26/2010 12:10 AM, Ingo Molnar wrote:
+
+ TP_STRUCT__entry(
+ __field(u32,state )
+ __field(u32,cpu_id )
Trace entries can carry a cpu_id of the current
* Thomas Renninger tr...@suse.de wrote:
On Tuesday 26 October 2010 09:10:20 Ingo Molnar wrote:
* Thomas Renninger tr...@suse.de wrote:
Changes in V2:
- Introduce PWR_EVENT_EXIT instead of 0 to mark non-power state
- Use u32 instead of u64 for cpuid, state which is by far
* Jean Pihet jean.pi...@newoldbits.com wrote:
Ingo,
On Tue, Oct 26, 2010 at 9:10 AM, Ingo Molnar mi...@elte.hu wrote:
* Thomas Renninger tr...@suse.de wrote:
Changes in V2:
- Introduce PWR_EVENT_EXIT instead of 0 to mark non-power state
- Use u32 instead of u64 for cpuid
* Thomas Renninger tr...@suse.de wrote:
On Tuesday 26 October 2010 13:21:29 Ingo Molnar wrote:
* Jean Pihet jean.pi...@newoldbits.com wrote:
..
+#ifndef _TRACE_POWER_ENUM_
+#define _TRACE_POWER_ENUM_
+enum {
+ POWER_NONE = 0,
+ POWER_CSTATE = 1
* Thomas Renninger tr...@suse.de wrote:
New power trace events:
power:processor_idle
power:processor_frequency
power:machine_suspend
C-state/idle accounting events:
power:power_start
power:power_end
are replaced with:
power:processor_idle
Well, most power saving hw models
* Thomas Renninger tr...@suse.de wrote:
On Monday 25 October 2010 12:04:28 Ingo Molnar wrote:
* Thomas Renninger tr...@suse.de wrote:
New power trace events:
power:processor_idle
power:processor_frequency
power:machine_suspend
C-state/idle accounting events
* 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 and these events should get
cleaned
up before ARM and other
* Peter Zijlstra pet...@infradead.org wrote:
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
* Arjan van de Ven ar...@linux.intel.com wrote:
On 10/19/2010 4:52 AM, Ingo Molnar wrote:
* Peter Zijlstrapet...@infradead.org wrote:
On Tue, 2010-10-19 at 13:45 +0200, Ingo Molnar wrote:
* Thomas Renningertr...@suse.de wrote:
Most definitely. It's no accident that it took
* Anand Gadiyar gadi...@ti.com wrote:
armpmu is a pointer to a structure - We need to use the structure
pointer operator to access num_events, and not the structure member
operator.
This fixes the following build break when building for OMAP4.
Yeah - i already fixed it earlier today and
* Arjan van de Ven ar...@linux.intel.com wrote:
On 10/8/2010 11:28 PM, Ingo Molnar wrote:
* Mathieu Desnoyersmathieu.desnoy...@efficios.com wrote:
* Arjan van de Ven (ar...@linux.intel.com) wrote:
On 10/8/2010 1:38 AM, Ingo Molnar wrote:
The fundamental thing about tracing
* Mathieu Desnoyers mathieu.desnoy...@efficios.com wrote:
* Arjan van de Ven (ar...@linux.intel.com) wrote:
On 10/8/2010 1:38 AM, Ingo Molnar wrote:
The fundamental thing about tracing/instrumentation is that there
are no deep ABI needs: it's all about analyzing development kernels
* Tejun Heo t...@kernel.org wrote:
Hello,
On 10/07/2010 05:58 PM, Frederic Weisbecker wrote:
I really feel uncomfortable with this tracepoint/ABI problem
Mathieu suggested we start a user library that could handle these
changes when they are really necessary.
Thoughts?
* Steven Rostedt rost...@goodmis.org wrote:
We could add a TRACE_EVENT_ABI() as Ingo has been suggesting. [...]
That would be rather useful.
We could still be flexible about experimental tracepoints (they dont
hurt), but apps should stick to ABI bits - or at least not complain when
non-ABI
* Jean Pihet jean.pi...@newoldbits.com wrote:
Apropos documentation..., are the power trace events documented
somewhere?
No. We need something like Documentation/trace/events-kmem.txt. I can
write that with for the new power API.
Such a patch introducing events-power.txt would be most
* Thomas Renninger tr...@suse.de wrote:
On Friday 17 September 2010 16:24:59 Ingo Molnar wrote:
* Jean Pihet jean.pi...@newoldbits.com wrote:
Apropos documentation..., are the power trace events documented
somewhere?
No. We need something like Documentation/trace/events
* Jean Pihet jean.pi...@newoldbits.com wrote:
On Wed, Sep 8, 2010 at 8:53 AM, Ingo Molnar mi...@elte.hu wrote:
* Jean Pihet jean.pi...@newoldbits.com wrote:
Hi,
Here is a patch proposal for adding new trace events for power management.
Note: thread restarted after the initial
* Jean Pihet jean.pi...@newoldbits.com wrote:
Hi,
Here is a patch proposal for adding new trace events for power management.
Note: thread restarted after the initial discussions on LKML.
Also mind including the ACPI tracepoints we talked about? That way a lot
more people could test it,
* Linus Torvalds torva...@linux-foundation.org wrote:
[...]
And those two things go together. The /sys/power/state thing is a global
suspend - which I don't think is appropriate for a opportunistic thing in
the first place, especially for multi-core.
A well-designed opportunistic
* Arve Hj?nnev?g a...@android.com wrote:
On Thu, Jun 3, 2010 at 4:23 PM, Ingo Molnar mi...@elte.hu wrote:
...
?- Controlled auto-suspend: drivers (such as input) could on wakeup
? automatically set the 'minimum wakeup latency' value of wakee tasks to a
? lower value. This automatically
* Brian Swetland swetl...@google.com wrote:
On Thu, Jun 3, 2010 at 12:30 PM, Ingo Molnar mi...@elte.hu wrote:
Sadly the response from the Android team has been 100% uncompromising:
either
suspend blockers or nothing.
Well, we're willing to accept something that gives us the same
* Linus Torvalds torva...@linux-foundation.org wrote:
On Fri, 4 Jun 2010, Ingo Molnar wrote:
What you say is absolutely true, hence this would be driven via
sched_tick() + TIF notifiers - i.e. only ever treat user-mode tasks as
'idle-able'. This can be done with no overhead
* Arjan van de Ven ar...@infradead.org wrote:
On Thu, 3 Jun 2010 19:26:50 -0700 (PDT)
Linus Torvalds torva...@linux-foundation.org wrote:
If the system is idle (or almost idle) for long times, I would heartily
recommend actively shutting down unused cores. Some CPU's are hopefully
* 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 keys that should always turn the screen on, but the problem
is not specific to input events. If we enabled a wakeup event it
* Brian Swetland swetl...@google.com wrote:
On Fri, Jun 4, 2010 at 12:57 AM, Ingo Molnar mi...@elte.hu wrote:
* Brian Swetland swetl...@google.com wrote:
We started here because it's possibly the only api level change we have
-- almost everything else is driver or subarch type work
* Brian Swetland swetl...@google.com wrote:
On Fri, Jun 4, 2010 at 1:55 AM, Ingo Molnar mi...@elte.hu wrote:
* Brian Swetland swetl...@google.com wrote:
After basically two years of growing your fork (and some attempts to get
your drivers into drivers/staging/ - from where they have
* Peter Zijlstra pet...@infradead.org 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 problems. Including the
pending timer one I suspect. Lets solve
* ty...@mit.edu ty...@mit.edu wrote:
[...] Not only has the source code been made available, but hundreds of
engineering hours have been made trying to accomodate the demands of LKML
--- and LKML has said no to suspend blockers/wakelocks.
I dont think you are being fair here, at all.
* Ingo Molnar mi...@elte.hu wrote:
* ty...@mit.edu ty...@mit.edu wrote:
[...] Not only has the source code been made available, but hundreds of
engineering hours have been made trying to accomodate the demands of LKML
--- and LKML has said no to suspend blockers/wakelocks.
I dont
* Linus Torvalds torva...@linux-foundation.org wrote:
On Fri, 4 Jun 2010, Ingo Molnar wrote:
This allows a task to 'exclude' other tasks that dont have low-latency
requirements. Crappy apps would have a large latency value, so they'd
be idled out when a privileged task sets
* Ingo Molnar mi...@elte.hu wrote:
- Create a 'deep idle' mode that suspends. This, if all constraints
are met, is triggered by the scheduler automatically: just like the other
idle modes are triggered currently. This approach fixes the wakeup
races because an incoming wakeup event
* Arve Hj?nnev?g a...@android.com wrote:
On Thu, May 27, 2010 at 3:23 PM, Alan Cox a...@lxorguk.ukuu.org.uk wrote:
On Thu, 27 May 2010 23:09:49 +0100
Matthew Garrett mj...@srcf.ucam.org wrote:
On Thu, May 27, 2010 at 11:08:06PM +0100, Alan Cox wrote:
This is I believe robust (and
* Stephen Rothwell s...@canb.auug.org.au wrote:
Hi all,
Today's linux-next build (powerpc allyesconfig) failed like this:
drivers/mfd/twl4030-codec.c:29:31: error: linux/i2c/twl4030.h: No such file
or directory
FYI, x86 allyesconfig fails to build too so this doesnt only affect
40 matches
Mail list logo
