On Mon, Oct 22, 2012 at 09:47:06AM -0700, Kevin Hilman wrote:
Peter Zijlstra pet...@infradead.org writes:
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
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
Peter Zijlstra pet...@infradead.org writes:
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
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
Hi,
On Fri, Oct 19, 2012 at 04:00:27PM +0200, Peter Zijlstra wrote:
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 Zijlstra pet...@infradead.org writes:
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,
Peter Zijlstra pet...@infradead.org writes:
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,
Hi,
On Tue, Oct 16, 2012 at 02:39:50PM -0700, Kevin Hilman wrote:
+ peterz, tglx
Felipe Balbi ba...@ti.com writes:
[...]
The problem I see is that even though we properly return IRQ_WAKE_THREAD
and wake_up_process() manages to wakeup the IRQ thread (it returns 1),
the thread is
Felipe Balbi ba...@ti.com writes:
On Wed, Oct 17, 2012 at 05:00:02PM +0300, Felipe Balbi wrote:
On Tue, Oct 16, 2012 at 02:39:50PM -0700, Kevin Hilman wrote:
+ peterz, tglx
Felipe Balbi ba...@ti.com writes:
[...]
The problem I see is that even though we properly return
On Wed, Oct 17, 2012 at 04:06:54PM -0700, Kevin Hilman wrote:
Felipe Balbi ba...@ti.com writes:
On Wed, Oct 17, 2012 at 05:00:02PM +0300, Felipe Balbi wrote:
On Tue, Oct 16, 2012 at 02:39:50PM -0700, Kevin Hilman wrote:
+ peterz, tglx
Felipe Balbi ba...@ti.com writes:
On Mon, Oct 15, 2012 at 7:21 AM, Paul Walmsley p...@pwsan.com wrote:
Commit 3b2f8f82dad7d1f79cdc8fc05bd1c94baf109bde (i2c: omap: switch to
threaded IRQ support) causes communication with I2C devices to fail
after system suspend/resume on all OMAP3 devices:
Could you tell me which omap3
Hi,
+ Thomas Gleixner
On Tue, Oct 16, 2012 at 06:28:13PM +0530, Shubhrajyoti Datta wrote:
On Mon, Oct 15, 2012 at 7:21 AM, Paul Walmsley p...@pwsan.com wrote:
Commit 3b2f8f82dad7d1f79cdc8fc05bd1c94baf109bde (i2c: omap: switch to
threaded IRQ support) causes communication with I2C devices
Hi again,
On Tue, Oct 16, 2012 at 04:33:56PM +0300, Felipe Balbi wrote:
Hi,
+ Thomas Gleixner
On Tue, Oct 16, 2012 at 06:28:13PM +0530, Shubhrajyoti Datta wrote:
On Mon, Oct 15, 2012 at 7:21 AM, Paul Walmsley p...@pwsan.com wrote:
Commit 3b2f8f82dad7d1f79cdc8fc05bd1c94baf109bde
Hi,
On Mon, Oct 15, 2012 at 01:51:08AM +, Paul Walmsley wrote:
Commit 3b2f8f82dad7d1f79cdc8fc05bd1c94baf109bde (i2c: omap: switch to
threaded IRQ support) causes communication with I2C devices to fail
after system suspend/resume on all OMAP3 devices:
...
[ 40.228576] PM: noirq
Hi
On Mon, 15 Oct 2012, Felipe Balbi wrote:
On Mon, Oct 15, 2012 at 01:51:08AM +, Paul Walmsley wrote:
Commit 3b2f8f82dad7d1f79cdc8fc05bd1c94baf109bde (i2c: omap: switch to
threaded IRQ support) causes communication with I2C devices to fail
after system suspend/resume on all OMAP3
Commit 3b2f8f82dad7d1f79cdc8fc05bd1c94baf109bde (i2c: omap: switch to
threaded IRQ support) causes communication with I2C devices to fail
after system suspend/resume on all OMAP3 devices:
...
[ 40.228576] PM: noirq resume of devices complete after 3.723 msecs
[ 40.233184] PM: early resume of
16 matches
Mail list logo
