On Wed, Jun 9, 2010 at 3:48 AM, Omar Ramirez Luna omar.rami...@ti.com wrote:
Split the functions to have cleaner error handling paths, this
will aslo cover a case where bridge initialization has failed but
device entry is still available which leads to unknown behavior.
Great, I was wondering
On Wed, Jun 9, 2010 at 6:46 AM, Linus Torvalds
torva...@linux-foundation.org wrote:
On Tue, 8 Jun 2010, da...@lang.hm wrote:
having suspend blockers inside the kernel adds significant complexity, it's
worth it only if the complexity buys you enough. In this case the question is
if the suspend
On Sat, Jun 5, 2010 at 11:50 PM, Florian Mickler flor...@mickler.org wrote:
On Sat, 5 Jun 2010 23:06:03 +0300
Felipe Contreras felipe.contre...@gmail.com wrote:
How would such stats be calculated? I presume at regular intervals you
check which applications are holding suspend blockers and
On Wed, 2010-06-09 at 09:25 +0200, ext Felipe Contreras wrote:
On Wed, Jun 9, 2010 at 3:48 AM, Omar Ramirez Luna omar.rami...@ti.com wrote:
Split the functions to have cleaner error handling paths, this
will aslo cover a case where bridge initialization has failed but
device entry is still
On Wed, Jun 9, 2010 at 11:49 AM, Ameya Palande ameya.pala...@nokia.com wrote:
On Wed, 2010-06-09 at 09:25 +0200, ext Felipe Contreras wrote:
On Wed, Jun 9, 2010 at 3:48 AM, Omar Ramirez Luna omar.rami...@ti.com
wrote:
Split the functions to have cleaner error handling paths, this
will aslo
On Wednesday 09 June 2010, Felipe Contreras wrote:
On Wed, Jun 9, 2010 at 6:46 AM, Linus Torvalds
torva...@linux-foundation.org wrote:
On Tue, 8 Jun 2010, da...@lang.hm wrote:
having suspend blockers inside the kernel adds significant complexity, it's
worth it only if the complexity buys
* Tony Lindgren t...@atomide.com [100608 14:30]:
* Hiroshi DOYU hiroshi.d...@nokia.com [100607 14:45]:
Satish (1):
omap iommu: Fix Memory leak
This one looks like a genuine fix :)
I've also updated the branch against -rc2. Please merge it if no problem.
OK, thanks
* Woodruff, Richard r-woodru...@ti.com [100609 02:24]:
Sorry for the delay, here's some more info on this issue. So it looks
like starting with 3630 there are dedicated pull-up for all the I2C buses.
And the pull values are configurable with software.
Even 3430 claimed to have this
On Sun, Jun 06, 2010 at 12:58:10PM -0700, Brian Swetland wrote:
On Sun, Jun 6, 2010 at 12:24 PM, Christoph Hellwig h...@infradead.org wrote:
On the other hand I've heard
that various hardware vendors or parties closed to them are rather
annoyed by their drivers beeing stuck in the android
* Govindraj govindraj...@gmail.com [100607 17:50]:
On Mon, Jun 7, 2010 at 5:02 PM, Govindraj govindraj...@gmail.com wrote:
On Mon, Jun 7, 2010 at 3:36 PM, Tony Lindgren t...@atomide.com wrote:
* Kevin Hilman khil...@deeprootsystems.com [100604 18:30]:
+ w = ~0x7;
+ w |=
Hi,
I've just started with the linux-omap-pm branch, and are experiencing problems
with the keyboard when resuming from sleep. There seems to be an earlier post
on this matter:
4) Suspend to memory (echo mem /sys/power/state) works now, but when I
wake up the board (via a keypress), I am
On Tue, 8 Jun 2010, Arve Hjønnevåg wrote:
Wakeup event occurs, and the driver:
- report wakeup event type A
- queue event for delivery to user-space
That's not really two distinct steps. Queuing the event for delivery
to userspace involves waking up any tasks that are waiting to read
Hello Tony,
On Tue, Jun 8, 2010 at 12:04 PM, Tony Lindgren t...@atomide.com wrote:
Because of this, 3630 boards should have the mux register pull-ups disabled,
and only use the dedicated I2C pull-ups. In theory external pull-ups should
not be needed. The value configured for the dedicated I2C
I have an application (running on 2.6.29-omap1) which puts an OMAP1
system to suspend aggressively. The system wakes up every 4 seconds
and stays awake for about 35 milliseconds and sleeps again for another
4 seconds. This design is to save power on a battery operated device.
This aggressive
On Wed, 9 Jun 2010, Suresh Rajashekara wrote:
I have an application (running on 2.6.29-omap1) which puts an OMAP1
system to suspend aggressively. The system wakes up every 4 seconds
and stays awake for about 35 milliseconds and sleeps again for another
4 seconds. This design is to save power
On Wed, 9 Jun 2010 11:40:27 +0200
Rafael J. Wysocki r...@sisk.pl wrote:
On Wednesday 09 June 2010, Felipe Contreras wrote:
On Wed, Jun 9, 2010 at 6:46 AM, Linus Torvalds
torva...@linux-foundation.org wrote:
On Tue, 8 Jun 2010, da...@lang.hm wrote:
having suspend blockers inside the
Robert Lukassen wrote:
Hi,
I've just started with the linux-omap-pm branch, and are experiencing problems
with the keyboard when resuming from sleep. There seems to be an earlier post
on this matter:
4) Suspend to memory (echo mem /sys/power/state) works now, but when I
wake up the board
2010/6/9 Alan Stern st...@rowland.harvard.edu:
On Tue, 8 Jun 2010, Arve Hjønnevåg wrote:
Wakeup event occurs, and the driver:
- report wakeup event type A
- queue event for delivery to user-space
That's not really two distinct steps. Queuing the event for delivery
to userspace
On Wed, Jun 9, 2010 at 12:38 AM, Guzman Lugo, Fernando
fernando.l...@ti.com wrote:
From: Ohad Ben-Cohen [o...@wizery.com]
But now that you point me to this irq on/off thing, it looks a bit
broken in terms of multiple concurrent mbox support since it relies on
a global rq_full state. I guess it'd
On Wed, 9 Jun 2010, Arve Hj?nnev?g wrote:
The power may not see the event, the process that reads the event will
always see it. If the power manager is not in the poll call when the
event happens, the process that reads the event can read the event
before the power manager calls poll.
All
2010/6/9 da...@lang.hm:
On Wed, 9 Jun 2010, Arve Hj?nnev?g wrote:
The power may not see the event, the process that reads the event will
always see it. If the power manager is not in the poll call when the
event happens, the process that reads the event can read the event
before the power
On Wed, 9 Jun 2010 21:51:38 -0700
Arve Hjønnevåg a...@android.com wrote:
The current user space interface does not require that clients
register the file descriptors that they get wakeup events from with
another process.
However I believe they *do* register these file descriptors with the
Hi,
This RFC is for making DSS drivers not aware of omap versions and
omap2,3 specific data like base addr, and irqs.
DSS base address, irqs, and silicon specific data could be placed in
platform_device.
This avoids the base address changes in the dss specific drivers like rfbi,
dsi, sdi.
-Original Message-
From: Guruswamy, Senthilvadivu
Sent: Thursday, June 10, 2010 10:49 AM
To: linux-omap@vger.kernel.org; t...@atomide.com; tomi.valkei...@nokia.com;
Hiremath, Vaibhav
Subject: [RFC] DSS: Movement of base addr, silicon specific data from driver
to platform_device
* Leon Woestenberg leon.woestenb...@gmail.com [100609 22:20]:
Hello Tony,
On Tue, Jun 8, 2010 at 12:04 PM, Tony Lindgren t...@atomide.com wrote:
Because of this, 3630 boards should have the mux register pull-ups disabled,
and only use the dedicated I2C pull-ups. In theory external pull-ups
25 matches
Mail list logo
