Re: [PATCH 2/3] PERF(kernel): Cleanup power events

2010-10-24 Thread Arjan van de Ven
On 10/19/2010 4:36 AM, Thomas Renninger 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 I think you need two trace points for

Re: [PATCH 2/3] PERF(kernel): Cleanup power events

2010-10-24 Thread Arjan van de Ven
On 10/19/2010 4:36 AM, Thomas Renninger wrote: static void poll_idle(void) { - trace_power_start(POWER_CSTATE, 0, smp_processor_id()); local_irq_enable(); while (!need_resched()) cpu_relax(); - trace_power_end(0); } why did you remove the idle t

[OFF TOPIC] Out on travel for a week

2010-10-24 Thread Felipe Balbi
Hi all, I'll be out on travel for a week, back to real life in November 3rd, so if you send me mails and I don't reply, wait a bit longer and I'll catch up with the pending stuff. -- balbi -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord

RE: [PATCH v2 09/10] OMAP2/3: Convert write/read functions to raw read/write

2010-10-24 Thread G, Manjunath Kondaiah
David, > -Original Message- > From: David Woodhouse [mailto:dw...@infradead.org] > Sent: Monday, October 25, 2010 5:32 AM > To: Menon, Nishanth > Cc: Russell King - ARM Linux; G, Manjunath Kondaiah; > linux-omap@vger.kernel.org; linux-...@lists.infradead.org; > linux-arm-ker...@lists.in

Re: [PATCH v2 09/10] OMAP2/3: Convert write/read functions to raw read/write

2010-10-24 Thread David Woodhouse
On Thu, 2010-10-07 at 14:50 -0500, Nishanth Menon wrote: > my comment being that by moving {read,write}[wlb] to __raw versions dont > solve the real issue of namespace here. fix should be in > arch/arm/include/asm/io.h IMHO. so that there are no overlaps as this. Indeed. This patch is complete

Re: [PATCH 3/3] omap: add hwspinlock device

2010-10-24 Thread Ohad Ben-Cohen
Hi Tony, On Fri, Oct 22, 2010 at 6:56 PM, Tony Lindgren wrote: > Guys, let's try to come up with a generic interface for this instead of > polluting the device drivers with more omap specific interfaces. > > We really want to keep the drivers generic and platform independent. I share this concer