On Sat, 5 Jun 2010, Arve Hjønnevåg wrote:
> 2010/6/5 Thomas Gleixner :
> > B1;2005;0cOn Fri, 4 Jun 2010, Arve Hjønnevåg wrote:
> >> > Why is it a BUG in the trusted app, when I initiate a download and put
> >> > the phone down ?
> >> >
> >>
&g
On Sat, 5 Jun 2010, Florian Mickler wrote:
> On Sat, 5 Jun 2010 23:24:40 +0200 (CEST)
> Thomas Gleixner wrote:
>
> > Stop that advertising campaing already.
>
> Stop advertising that there is no problem.
>
> >
> > No thanks,
> >
> >
On Sat, 5 Jun 2010, Florian Mickler wrote:
> On Sat, 5 Jun 2010 23:26:27 +0300
> Felipe Contreras wrote:
>
> > Supposing there's a perfect usage of suspend blockers from user-space
> > on current x86 platforms (in theory Android would have that), is the
> > benefit that big to consider this a str
B1;2005;0cOn Fri, 4 Jun 2010, Arve Hjønnevåg wrote:
> 2010/6/4 Thomas Gleixner :
> > Arve,
> >
> > On Fri, 4 Jun 2010, Arve Hjønnevåg wrote:
> >
> >> On Fri, Jun 4, 2010 at 5:05 PM, Thomas Gleixner wrote:
> >> > On Sat, 5 Jun 2010, Rafael J. Wys
Arve,
On Fri, 4 Jun 2010, Arve Hjønnevåg wrote:
> On Fri, Jun 4, 2010 at 5:05 PM, Thomas Gleixner 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
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
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
On Thu, 3 Jun 2010, James Bottomley wrote:
> On Thu, 2010-06-03 at 11:03 +0100, Alan Cox wrote:
> > > [mtg: ] This has been a pain point for the PM_QOS implementation. They
> > > change the constrain back and forth at the transaction level of the i2c
> > > driver. The pm_qos code really wasn't
On Wed, 2 Jun 2010, Arve Hjønnevåg wrote:
> 2010/6/2 Thomas Gleixner :
> > On Wed, 2 Jun 2010, Arve Hjønnevåg wrote:
> >> 2010/6/2 Neil Brown :
> >> > There would still need to be some sort of communication between the the
> >> > suspend daemon on any
On Wed, 2 Jun 2010, Arve Hjønnevåg wrote:
> 2010/6/2 Neil Brown :
> > There would still need to be some sort of communication between the the
> > suspend daemon on any event daemon to ensure that the events had been
> > processed. This could be very light weight interaction. The point though
> >
On Wed, 2 Jun 2010, Arve Hjønnevåg wrote:
> 2010/6/2 Thomas Gleixner :
> > On Tue, 1 Jun 2010, Arve Hjønnevåg wrote:
> >>
> >> Because suspend itself causes you to not be idle you cannot abort
> >> suspend just because you are not idle anymore.
> >
> &g
On Tue, 1 Jun 2010, Arve Hjønnevåg wrote:
> 2010/6/1 Thomas Gleixner :
> > On Mon, 31 May 2010, Arve Hjønnevåg wrote:
> >
> >> 2010/5/31 Rafael J. Wysocki :
> >> > On Monday 31 May 2010, Arve Hjønnevåg wrote:
> >> >> 2010/5/30 Rafael J. Wysocki
On Wed, 2 Jun 2010, Arve Hjønnevåg wrote:
> 2010/6/2 Thomas Gleixner :
> > On Tue, 1 Jun 2010, Arve Hjønnevåg wrote:
> >> Deferring the the timers forever without stopping the clock can cause
> >> problems. Our user space code has a lot of timeouts that will trigger
&
On Tue, 1 Jun 2010, Arve Hjønnevåg wrote:
> 2010/6/1 Thomas Gleixner :
> >
> > On Mon, 31 May 2010, Arve Hjønnevåg wrote:
> >
> >> On Mon, May 31, 2010 at 2:46 PM, Thomas Gleixner
> >> wrote:
> >> > On Mon, 31 May 2010, James Bottomley wrote:
On Mon, 31 May 2010, Arve Hjønnevåg wrote:
> 2010/5/31 Rafael J. Wysocki :
> > On Monday 31 May 2010, Arve Hjønnevåg wrote:
> >> 2010/5/30 Rafael J. Wysocki :
> > ...
> >>
> >> I think it makes more sense to block suspend while wakeup events are
> >> pending than blocking it everywhere timers are
On Mon, 31 May 2010, Arve Hjønnevåg wrote:
> On Mon, May 31, 2010 at 2:46 PM, Thomas Gleixner wrote:
> > On Mon, 31 May 2010, James Bottomley wrote:
> >>
> >> For MSM hardware, it looks possible to unify the S and C states by doing
> >> suspend to ram from
On Tue, 1 Jun 2010, Neil Brown wrote:
>
> I think you have acknowledged that there is a race with suspend - thanks.
> Next step was "can it be closed".
> You seem to suggest that it can, but you describe it as a "work around"
> rather than a "bug fix"...
>
> Do you agree that the race is a "bug",
On Tue, 1 Jun 2010, Neil Brown wrote:
> And if you are right that the race window cannot be closed, then the whole
> suspend-blocker infrastructure is pointless as the purpose of it is simply to
> close that window. If it really does not and cannot work, then it would be
> best to reject it for th
On Tue, 1 Jun 2010, Rafael J. Wysocki wrote:
> On Tuesday 01 June 2010, Neil Brown wrote:
> > My freerunner has a single core so without CONFIG_PREEMPT it may be that
> > there is no actual race-window - maybe the PRE_SUSPENDs will all run before
> > a
> > soft_irq thread has a chance to finish ha
On Tue, 1 Jun 2010, Rafael J. Wysocki wrote:
> On Monday 31 May 2010, Thomas Gleixner wrote:
> > So that allows to use the same mechanism for more than the android
> > sledge hammer approach and confines the controversial use cases into
> > android specific files without addi
On Mon, 31 May 2010, James Bottomley wrote:
> On Mon, 2010-05-31 at 22:49 +0200, Thomas Gleixner wrote:
> > On Sat, 29 May 2010, James Bottomley wrote:
> > > The job of the kernel is to accommodate hardware as best it can ...
> > > sometimes it might not be able to, but
On Mon, 31 May 2010, James Bottomley wrote:
>
> For MSM hardware, it looks possible to unify the S and C states by doing
> suspend to ram from idle but I'm not sure how much work that is.
On ARM, it's not rocket science and we have in tree support for this
already (OMAP). I have done the same thi
On Sat, 29 May 2010, James Bottomley wrote:
> On Sat, 2010-05-29 at 10:10 +0200, Peter Zijlstra wrote:
> >
> > Not using suspend is exactly the point. As Alan has argued, propagating
> > suspend blockers up into all regions of userspace will take much longer
> > than fixing the hardware.
>
> Stra
On Sat, 29 May 2010, James Bottomley wrote:
> The job of the kernel is to accommodate hardware as best it can ...
> sometimes it might not be able to, but most of the time it does a pretty
> good job.
>
> The facts are that C states and S states are different and are entered
> differently.
That'
On Thu, 27 May 2010, Alan Stern wrote:
> On Thu, 27 May 2010, Thomas Gleixner wrote:
>
> > > The two of you are talking at cross purposes. Thomas is referring to
> > > idle-based suspend and Matthew is talking about forced suspend.
> >
> > Yes, and forced
On Thu, 27 May 2010, Rafael J. Wysocki wrote:
> On Thursday 27 May 2010, Thomas Gleixner wrote:
> > On Thu, 27 May 2010, Alan Stern wrote:
> >
> > > On Thu, 27 May 2010, Felipe Balbi wrote:
> > >
> > > > On Thu, May 27, 2010 at 05:06:23PM +0200, e
On Thu, 27 May 2010, Alan Stern wrote:
> On Thu, 27 May 2010, Matthew Garrett wrote:
>
> > On Thu, May 27, 2010 at 10:23:50PM +0200, Thomas Gleixner wrote:
> > > On Thu, 27 May 2010, Matthew Garrett wrote:
> > > > A wakeup event is defined as one th
On Thu, 27 May 2010, Matthew Garrett wrote:
> On Thu, May 27, 2010 at 08:53:11PM +0200, Thomas Gleixner wrote:
> > On Thu, 27 May 2010, Matthew Garrett wrote:
> > > We were talking about PCs. Suspend-as-c-state is already implemented for
> > > OMAP.
> >
>
On Thu, 27 May 2010, Alan Cox wrote:
> > No, it's not. Forced suspend may be in response to hitting a key, but it
>
> You are the only person here talking about 'forced' suspends. The rest of
> us are talking about idling down and ensuring we are always in a state we
> un-idle correctly.
>
> >
On Thu, 27 May 2010, Matthew Garrett wrote:
> On Thu, May 27, 2010 at 08:18:11PM +0200, Peter Zijlstra wrote:
> > On Thu, 2010-05-27 at 19:14 +0100, Matthew Garrett wrote:
> > > If I get a WoL
> > > packet in the 0.5 of a second between userspace deciding to suspend and
> > > actually doing so,
On Thu, 27 May 2010, Matthew Garrett wrote:
> On Thu, May 27, 2010 at 07:59:02PM +0200, Thomas Gleixner wrote:
> > On Thu, 27 May 2010, Matthew Garrett wrote:
> > > ACPI provides no guarantees about what level of hardware functionality
> > > remains during S3. You do
On Thu, 27 May 2010, Matthew Garrett wrote:
> On Thu, May 27, 2010 at 06:49:18PM +0100, Alan Cox wrote:
> > > ACPI provides no guarantees about what level of hardware functionality
> > > remains during S3. You don't have any useful ability to determine which
> > > events will generate wakeups. A
On Thu, 27 May 2010, Matthew Garrett wrote:
> On Thu, May 27, 2010 at 07:34:40PM +0200, Peter Zijlstra wrote:
> > > we still need to be able to enter suspend while the system isn't idle.
> >
> > _WHY_!?
>
> Because if I'm running a kernel build in a tmpfs and I hit the sleep
> key, I need to go
On Thu, 27 May 2010, Matthew Garrett wrote:
> On Thu, May 27, 2010 at 07:35:50PM +0200, Peter Zijlstra wrote:
> > On Thu, 2010-05-27 at 18:32 +0100, Matthew Garrett wrote:
> > > On Thu, May 27, 2010 at 07:28:08PM +0200, Peter Zijlstra wrote:
> > > > Why would you care about the screen for a network
On Thu, 27 May 2010, Alan Stern wrote:
> On Thu, 27 May 2010, Thomas Gleixner wrote:
>
> > Crap. Stop beating on those lost wakeup events. If we lose them then
> > the drivers are broken and do not handle the switch over correctly. Or
> > the suspend mechanism is broken
On Thu, 27 May 2010, Matthew Garrett wrote:
> On Thu, May 27, 2010 at 07:24:02PM +0200, Thomas Gleixner wrote:
>
> > Oh no. They paper over a short coming. If there is a pending event,
> > the kernel knows that. It just does not make use of this
> > information. Blockers
On Thu, 27 May 2010, Matthew Garrett wrote:
> On Thu, May 27, 2010 at 07:15:31PM +0200, Thomas Gleixner wrote:
> > On Thu, 27 May 2010, Matthew Garrett wrote:
> > > My question was about explicit suspend states, not implicitly handling
> > > an identical state bas
On Thu, 27 May 2010, Alan Stern wrote:
> On Thu, 27 May 2010, Felipe Balbi wrote:
>
> > On Thu, May 27, 2010 at 05:06:23PM +0200, ext Alan Stern wrote:
> > >If people don't mind, here is a greatly simplified summary of the
> > >comments and objections I have seen so far on this thread:
> > >
> >
On Thu, 27 May 2010, Alan Stern wrote:
> On Thu, 27 May 2010, Thomas Gleixner wrote:
>
> > The whole notion of treating suspend to RAM any different than a plain
> > idle C-State is wrong. It's not different at all. You just use a
> > different mechanism which h
On Thu, 27 May 2010, Matthew Garrett wrote:
> On Thu, May 27, 2010 at 06:45:25PM +0200, Thomas Gleixner wrote:
> > On Thu, 27 May 2010, Matthew Garrett wrote:
> > > No. Suspend blockers are designed to ensure that suspend isn't racy with
> > > respect to wakeu
On Thu, 27 May 2010, Matthew Garrett wrote:
> On Thu, May 27, 2010 at 05:16:15PM +0100, Alan Cox wrote:
>
> > I can't speak for Thomas, but I'm certainly not arguing that you don't
> > need something that looks more like the blocker side of the logic *in
> > kernel*, because there is stuff that y
On Thu, 27 May 2010, Alan Cox wrote:
> That's all your need to do it right.
>
> In kernel yes your device driver probably does need to say things like
> 'Don't go below C6 for a moment' just as a high speed serial port might
> want to say 'Nothing over 10mS please'
>
> I can't speak for Thomas, b
On Thu, 27 May 2010, Matthew Garrett wrote:
> On Thu, May 27, 2010 at 05:32:56PM +0200, Thomas Gleixner wrote:
> > On Thu, 27 May 2010, Matthew Garrett wrote:
> > > Now let's try this in the Android world. The user hits a key and the
> > > system wakes up. The i
On Thu, 27 May 2010, Alan Stern wrote:
> On Thu, 27 May 2010, Peter Zijlstra wrote:
>
> > On Thu, 2010-05-27 at 16:33 +0100, Alan Cox wrote:
> > > On Thu, 27 May 2010 17:09:16 +0200
> > > Peter Zijlstra wrote:
> > >
> > > > On Thu, 2010-05-27 at 11:06 -0400, Alan Stern wrote:
> > > > >
> > > >
On Thu, 27 May 2010, Matthew Garrett wrote:
> On Thu, May 27, 2010 at 12:39:43AM +0100, Alan Cox wrote:
>
> > - Supporting Android needs well good
> > - Opportunistic suspend good
> > - Manner in which interface is expressed to userspace bad
> > - Latency constraint interface would be better
> > -
On Wed, 26 May 2010, Arve Hjønnevåg wrote:
> 2010/5/26 Alan Cox :
> > On Wed, 26 May 2010 15:30:58 -0700
> > Arve Hjønnevåg wrote:
> >
> >> On Wed, May 26, 2010 at 6:16 AM, Alan Cox wrote:
> >> >> Really, what are you getting at? Do you deny that there are programs,
> >> >> that prevent a device
On Wed, 26 May 2010, Florian Mickler wrote:
> On Wed, 26 May 2010 19:22:16 +0200 (CEST)
> Thomas Gleixner wrote:
> > On Wed, 26 May 2010, Florian Mickler wrote:
> > >
> > > On the other hand, applications can say, they don't need that much
> > > p
On Thu, 27 May 2010, Florian Mickler wrote:
> On Wed, 26 May 2010 22:03:37 +0200
> Vitaly Wool wrote:
>
> > On Wed, May 26, 2010 at 9:56 PM, Florian Mickler
> > wrote:
> >
> > > Your approach definitely sounds better than the current solution.
> > > What about mapping suspend blocker function
On Wed, 26 May 2010, Alan Cox wrote:
> > The power efficiency of a mobile device is depending on a sane overall
> > software stack and not on the ability to mitigate crappy software in
> > some obscure way which is prone to malfunction and disappoint users.
>
> Even if you believe the kernel shou
Florian,
On Wed, 26 May 2010, Florian Mickler wrote:
>
> On the other hand, applications can say, they don't need that much
> power and userspace guaranties and not take a suspend blocker.
>
> This is an option which they currently don't have.
Wrong. A well coded power aware application is very
Alan,
On Wed, 26 May 2010, Alan Cox wrote:
> > Really, what are you getting at? Do you deny that there are programs,
> > that prevent a device from sleeping? (Just think of the bouncing
> > cows app)
> >
> > And if you have two kernels, one with which your device is dead after 1
> > hour and one
On Tue, 2 Mar 2010, Madhusudhan wrote:
> > Conditional locking on (!in_interrupt()) is broken by design and there
> > is no reason to keep the host->irq_lock across the call to
> > mmc_request_done(). Also the host->protect_card magic hack does not
> > depend on the context
> >
>
> Can you please
uest_done().
Signed-off-by: Thomas Gleixner
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 4b23225..99a3383 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -468,14 +468,6 @@ omap_hsmmc_start_command(struct omap_hsmmc_host *host
On Mon, 1 Mar 2010, Uwe Kleine-König wrote:
> You might want to report that to the author(s) of
> drivers/mmc/host/omap_hsmmc.c.
FYI, thats fixed in 33-rt3 and the fix is going mainline as well.
Thanks,
tglx
On Wed, 16 Dec 2009, Felipe Balbi wrote:
> commit 239007b8440abff689632f50cdf0f2b9e895b534 converted
> the spinlock_t to raw_spinlock_t. Unfortunately twl4030-irq
> was left aside on the conversion.
>
> Cc: Thomas Gleixner
> Cc: Tony Lindgren
> Cc: linux-omap@vger.kerne
On Thu, 20 Mar 2008, Kevin Hilman wrote:
> Russell King - ARM Linux <[EMAIL PROTECTED]> writes:
>
> > On Mon, Mar 17, 2008 at 11:42:36AM +0200, Tony Lindgren wrote:
> >> This patch fixes timer32k for clockevents and syncs it with
> >> linux-omap tree.
> >>
> >> Signed-off-by: Tony Lindgren <[EMA
101 - 156 of 156 matches
Mail list logo
