On Thu, Jun 03, 2010 at 08:58:25PM +0200, ext Kevin Hilman wrote:
This doesn't look right for OMAP1. With a device name, you should
just drop the arm_cpio_ck part, so you can do a clk_get(dev, NULL).
I guess it doesn't matter. clkdev will try to match device and clk
names, if that fails 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
FYI, there's been dicussion on LKML and LAKML about getting
rid of the ARM defconfigs:
http://comments.gmane.org/gmane.linux.ports.arm.kernel/81611
Cheers,
Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More
* 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
On Wed, Jun 02, 2010 at 07:44:59PM -0700, Arve Hjønnevåg wrote:
On Wed, Jun 2, 2010 at 4:32 PM, Dmitry Torokhov
dmitry.torok...@gmail.com wrote:
On Wed, Jun 02, 2010 at 09:05:21PM +0200, Florian Mickler wrote:
On Wed, 2 Jun 2010 21:02:24 +1000
Neil Brown ne...@suse.de wrote:
And this
Hi Kevin,
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Thursday, June 03, 2010 10:47 PM
To: Lesly A M
Cc: linux-omap@vger.kernel.org; Lesly A M; Nishanth Menon; David Derrick;
Samuel Ortiz
Subject: Re: [PATCH v6 1/7] omap3: pm: fix for twl4030
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Thursday, June 03, 2010 11:10 PM
To: Lesly A M
Cc: linux-omap@vger.kernel.org; Lesly A M; Nishanth Menon; David Derrick;
Samuel Ortiz
Subject: Re: [PATCH v6 2/7] omap3: pm: Using separate clk/volt
On Fri, Jun 4, 2010 at 12:13 AM, Ingo Molnar mi...@elte.hu wrote:
* 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
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 ++
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
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 |
Hi Kevin,
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Thursday, June 03, 2010 11:12 PM
To: Lesly A M
Cc: linux-omap@vger.kernel.org; Lesly A M; Nishanth Menon; David Derrick;
Samuel Ortiz
Subject: Re: [PATCH v6 3/7] omap3: pm: re-programing the
2010/6/4 Dmitry Torokhov dmitry.torok...@gmail.com:
On Wed, Jun 02, 2010 at 07:44:59PM -0700, Arve Hjønnevåg wrote:
On Wed, Jun 2, 2010 at 4:32 PM, Dmitry Torokhov
dmitry.torok...@gmail.com wrote:
On Wed, Jun 02, 2010 at 09:05:21PM +0200, Florian Mickler wrote:
On Wed, 2 Jun 2010 21:02:24
Hi Kevin,
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Thursday, June 03, 2010 11:15 PM
To: Lesly A M
Cc: linux-omap@vger.kernel.org; Lesly A M; Nishanth Menon; David Derrick;
Samuel Ortiz
Subject: Re: [PATCH v6 4/7] omap3: pm: changing
* 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 to the
* 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
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 or controversial but
entirely self-contained (like the
* 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 or
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 keys that should always turn the screen on, but the problem
is not
On Fri, Jun 4, 2010 at 11:55 AM, Ingo Molnar mi...@elte.hu wrote:
In any case, this is not to suggest that the suspend-blocker bits are
'impossible' to merge. I just say that if you start with your most difficult
feature you should not be surprised to be on the receiving end of a 1000+
mails
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 meanwhile
dropped out again) you re-started with
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
* 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
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, Jun 4, 2010 at 2:59 AM, Ingo Molnar mi...@elte.hu wrote:
You can certainly put in a suspend_blockers.h thing into some Android
directory, and populate it with empty wrappers - as long as you only use it
within Android drivers and not core kernel code or other subsystems you dont
On Fri, Jun 4, 2010 at 3:08 AM, Peter Zijlstra pet...@infradead.org wrote:
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
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 problems. Including the
pending timer one I suspect. Lets solve it
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
Linus Torvalds torva...@linux-foundation.org writes:
On Thu, 3 Jun 2010, Arjan van de Ven wrote:
And because there's then no power saving (but a performance cost), it's
actually a negative for battery life/total energy.
Including the UP optimizations we do (ie lock prefix removal)? It's
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of
Gadiyar, Anand
Sent: Friday, June 04, 2010 8:32 AM
To: Kevin Hilman; Mike Chan
Cc: linux-omap@vger.kernel.org; Paul Walmsley
Subject: RE: Future of resource framework?
Kevin
From: Gopinath, Thara
Sent: Friday, June 04, 2010 4:20 PM
To: Gadiyar, Anand; Kevin Hilman; Mike Chan
Cc: linux-omap@vger.kernel.org; Paul Walmsley
Subject: RE: Future of resource framework?
-Original Message-
From:
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
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Kevin
Hilman
Sent: Thursday, June 03, 2010 5:31 AM
To: Nishanth Menon
Cc: Premi, Sanjeev; Menon, Nishanth; Koen Kooi; linux-omap@vger.kernel.org;
eduardo.valen...@nokia.com
Patch series is based on remotes/origin/pm-wip/uart
branch from Kevin's PM tree.
1.) Add support for UART4 for 3630.
2.) Modify Serial hwmod to avoid hwmod lookup using name string.
Govindraj.R (4):
OMAP3: PRCM: Consider UART4 for 3630 chip in prcm_setup_regs
OMAP3: serial: Fix uart4
To standarize among other uarts (1 to 3), we shall now:
- Enable uart4 autodile bit.
- Enable uart4 wakeup in PER.
- Allow uart4 to wakeup the MPU.
Cc: Kevin Hilman khil...@deeprootsystems.com
Signed-off-by: Sergio Aguirre saagui...@ti.com
Signed-off-by: Govindraj.R govindraj.r...@ti.com
---
This patch makes the following:
- Adds missing wakeup padding register handling.
- Fixes a hardcode to use PER module ONLY on UART3.
- Muxmode usage needed for uart4 for 3630 for padconf
wakeup on rx line.
Cc: Kevin Hilman khil...@deeprootsystems.com
Signed-off-by: Sergio Aguirre
Avoid using hwmod lookup using name string rather
retreive port info using the hwmod class interface.
Cc: Kevin Hilman khil...@deeprootsystems.com
Signed-off-by: Govindraj.R govindraj.r...@ti.com
---
arch/arm/mach-omap2/serial.c | 76 --
1 files changed,
Add prepare idle and resume idle call for uart4 used by 3630.
Cc: Kevin Hilman khil...@deeprootsystems.com
Signed-off-by: Govindraj.R govindraj.r...@ti.com
---
arch/arm/mach-omap2/pm34xx.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c
This patch adds driver support for OMAP2/3/4 high speed UART.
The driver is made separate from 8250 driver as we cannot
over load 8250 driver with omap platform specific configuration for
features like DMA, it makes easier to implement features like DMA and
hardware flow control and software flow
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of
Govindraj.R
Sent: Friday, June 04, 2010 7:14 PM
To: linux-omap@vger.kernel.org
Cc: Kevin Hilman; Aguirre, Sergio
Subject: [pm-wip/uart][PATCH 2/4] OMAP3: serial: Fix uart4
On Fri, Jun 4, 2010 at 7:33 PM, Gopinath, Thara th...@ti.com wrote:
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of
Govindraj.R
Sent: Friday, June 04, 2010 7:14 PM
To: linux-omap@vger.kernel.org
Cc: Kevin Hilman; Aguirre,
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Raja,
Govindraj
Sent: Friday, June 04, 2010 7:14 PM
To: linux-omap@vger.kernel.org
Cc: Kevin Hilman
Subject: [pm-wip/uart][PATCH 3/4] Serial: Avoid using hwmod lookup using
On Fri, 2010-06-04 at 11:59 +0200, Ingo Molnar wrote:
* 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:
[...]
In any case, this is not to suggest that the suspend-blocker bits are
On Fri, 4 Jun 2010, Ingo Molnar wrote:
Note that this does not necessarily have to be implemented as 'execute
suspend
from the idle task' code: scheduling from the idle task, while can certainly
be made to work, is a somewhat recursive concept that we might want to avoid
for robustness
On Fri, 04 Jun 2010 09:24:06 -0500
James Bottomley james.bottom...@suse.de wrote:
On Fri, 2010-06-04 at 11:59 +0200, Ingo Molnar wrote:
Anyway, i'm not pessimistic at all: _some_ sort of scheme appears to be
crystalising out today. Everyone seems to agree now that the main usecases
are
Lesly Arackal Manuel lesl...@ti.com writes:
@@ -510,18 +502,6 @@ void omap_sram_idle(void)
}
omap_uart_resume_idle(0);
omap_uart_resume_idle(1);
- if (core_next_state == PWRDM_POWER_OFF) {
- u32 voltctrl = OMAP3430_AUTO_OFF;
Lesly Arackal Manuel lesl...@ti.com writes:
Hi Kevin,
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Thursday, June 03, 2010 11:15 PM
To: Lesly A M
Cc: linux-omap@vger.kernel.org; Lesly A M; Nishanth Menon; David Derrick;
Samuel Ortiz
Subject:
Govindraj.R govindraj.r...@ti.com writes:
This patch makes the following:
- Adds missing wakeup padding register handling.
- Fixes a hardcode to use PER module ONLY on UART3.
- Muxmode usage needed for uart4 for 3630 for padconf
wakeup on rx line.
The need for this muxmode needs to be
Gopinath, Thara th...@ti.com writes:
-uart = kzalloc(sizeof(struct omap_uart_state), GFP_KERNEL);
-if (WARN_ON(!uart))
-return;
+/*
+ * NOTE: omap_hwmod_init() has not yet been called,
+ * so no hwmod functions will work yet.
+ */
On Thu, 03 Jun 2010 17:28:01 +0200
Peter Zijlstra pet...@infradead.org wrote:
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
From: Eric Dumazet eric.duma...@gmail.com
Date: Wed, 26 May 2010 22:48:53 +0200
Le mercredi 26 mai 2010 à 15:19 -0500, Arce, Abraham a écrit :
By increasing the allocation length of our rx skbuff the corruption issue is
fixed... I have increased it by 2... Were we writing outside our
On Friday 04 June 2010, Peter Zijlstra wrote:
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
On Sat, 5 Jun 2010, Rafael J. Wysocki wrote:
I kind of agree here, so I'd like to focus a bit on that.
Here's my idea in the very general terms:
(1) Use the cgroup freezer to suspend the untrusted apps (ie. the ones
that don't use suspend blockers aka wakelocks in the Android world) at
2010/6/4 Peter Zijlstra pet...@infradead.org:
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
On Fri, Jun 4, 2010 at 5:05 PM, Thomas Gleixner t...@linutronix.de wrote:
On Sat, 5 Jun 2010, Rafael J. Wysocki wrote:
I kind of agree here, so I'd like to focus a bit on that.
Here's my idea in the very general terms:
(1) Use the cgroup freezer to suspend the untrusted apps (ie. the ones
On Fri, Jun 04, 2010 at 05:39:17PM -0700, Arve Hjønnevåg wrote:
On Fri, Jun 4, 2010 at 5:05 PM, Thomas Gleixner t...@linutronix.de wrote:
On Sat, 5 Jun 2010, Rafael J. Wysocki wrote:
snip
With the cgroup freezer you can suspend them right away and
just keep the trusted
Arve,
On Fri, 4 Jun 2010, Arve Hjønnevåg wrote:
On Fri, Jun 4, 2010 at 5:05 PM, Thomas Gleixner t...@linutronix.de wrote:
On Sat, 5 Jun 2010, Rafael J. Wysocki wrote:
I kind of agree here, so I'd like to focus a bit on that.
Here's my idea in the very general terms:
(1) Use the
2010/6/4 Thomas Gleixner t...@linutronix.de:
Arve,
On Fri, 4 Jun 2010, Arve Hjønnevåg wrote:
On Fri, Jun 4, 2010 at 5:05 PM, Thomas Gleixner t...@linutronix.de wrote:
On Sat, 5 Jun 2010, Rafael J. Wysocki wrote:
I kind of agree here, so I'd like to focus a bit on that.
Here's my idea
2010/6/4 Matt Helsley matth...@us.ibm.com:
On Fri, Jun 04, 2010 at 05:39:17PM -0700, Arve Hjønnevåg wrote:
On Fri, Jun 4, 2010 at 5:05 PM, Thomas Gleixner t...@linutronix.de wrote:
On Sat, 5 Jun 2010, Rafael J. Wysocki wrote:
snip
With the cgroup freezer you can suspend them right
64 matches
Mail list logo
