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
On Tue, 25 Jan 2011, Russell King - ARM Linux wrote:
> On Mon, Jan 24, 2011 at 11:39:13PM -0800, Colin Cross wrote:
> > On Mon, Jan 24, 2011 at 3:11 AM, Russell King - ARM Linux
> > wrote:
> > > On Mon, Jan 24, 2011 at 11:06:09AM +, Russell King - ARM Linux wrote:
> > >> On Mon, Jan 24, 2011 a
On Tue, 25 Jan 2011, Russell King - ARM Linux wrote:
> On Tue, Jan 25, 2011 at 02:23:10PM +0100, Thomas Gleixner wrote:
> > In which way? I mean the generic code issues a call to the set_mode
> > function when we leave the broadcast mode. So what should the generic
> > code d
On Tue, 25 Jan 2011, Russell King - ARM Linux wrote:
> On Tue, Jan 25, 2011 at 03:12:24PM +0100, Thomas Gleixner wrote:
> > On Tue, 25 Jan 2011, Russell King - ARM Linux wrote:
> > > On Tue, Jan 25, 2011 at 02:23:10PM +0100, Thomas Gleixner wrote:
> > > > In whic
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 pow
On Mon, 14 Jun 2010, john stultz wrote:
> On Mon, 2010-06-14 at 00:46 -0700, Suresh Rajashekara wrote:
> > On Thu, Jun 10, 2010 at 12:52 PM, john stultz wrote:
> > > I think Thomas was suggesting that you consider creating a option for
> > > where CLOCK_MONOTONIC included total_sleep_time.
> > >
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
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
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
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
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, 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 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 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 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 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 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: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, 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, 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, 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, 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, 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, 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: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, 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 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: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 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, 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: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 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, 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, 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 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 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 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 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 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 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, 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, 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 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 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 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 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:
> >
> >> 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:
> >>
> >> Because suspend itself causes you to not be idle you cannot abort
> >> suspend just because you are not idle anymore.
> >
> &g
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 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 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 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 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
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
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
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
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, 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, Arjan van de Ven wrote:
> On Sat, 5 Jun 2010 15:26:36 -0700
> Brian Swetland wrote:
>
> >
> > I'm continually surprised by answers like this. We run on hardware
> > that power gates very aggressively and draws in the neighborhood of
> > 1-2mA at the battery when in the lowe
On Sat, 5 Jun 2010, Arve Hjønnevåg wrote:
> 2010/6/5 Thomas Gleixner :
> > On Sat, 5 Jun 2010, Arve Hjønnevåg wrote:
> >> >> > That download might take a minute or two, but that's not an
> >> >> > justification for the crapplication to run u
On Sat, 5 Jun 2010, Arve Hjønnevåg wrote:
> 2010/6/5 Thomas Gleixner :
> >> > Well, that's simply an application bug which sucks battery with or
> >> > without suspend blockers. So it's unrelated to the freezing of
> >> > untrusted apps
On Sat, 5 Jun 2010, Arve Hjønnevåg wrote:
> 2010/6/5 Thomas Gleixner :
> > 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:
> >> Cross app calls do not go through a central pr
On Sat, 5 Jun 2010, Arve Hjønnevåg wrote:
> 2010/6/5 Thomas Gleixner :
> > On Sat, 5 Jun 2010, Arve Hjønnevåg wrote:
> >> That is too simple. You also have to prevent A from being frozen while
> >> it is processing the event or the result would be the same as if it
On Sat, 5 Jun 2010, Arve Hjønnevåg wrote:
> 2010/6/5 Thomas Gleixner :
> > On Sat, 5 Jun 2010, Arve Hjønnevåg wrote:
> >> 2010/6/5 Thomas Gleixner :
> >> > On Sat, 5 Jun 2010, Arve Hjønnevåg wrote:
> >> >> >> > That download might take a minut
On Sat, 5 Jun 2010, Arve Hjønnevåg wrote:
> 2010/6/5 Thomas Gleixner :
> >
> > Can you please explain in a consistent way how the application stack
> > and the underlying framework (which exists according to android docs)
> > is handling events and how the sepa
On Sun, 6 Jun 2010, James Bottomley wrote:
>
> 3. We've lost sight of one of the original goals, which was to
> bring the android tree close enough to the kernel so that the
> android downstream driver and board producers don't have to
> choose between the android kerne
James,
On Sun, 6 Jun 2010, James Bottomley wrote:
> On Sun, 2010-06-06 at 17:46 +0200, Thomas Gleixner wrote:
> > On Sun, 6 Jun 2010, James Bottomley wrote:
> > >
> > > 3. We've lost sight of one of the original goals, which was to
> > > b
On Sun, 6 Jun 2010, Brian Swetland wrote:
> On Sun, Jun 6, 2010 at 11:04 AM, Thomas Gleixner wrote:
> >>
> >> Right, so the sooner we make it easier for the drivers to use the kernel
> >> as their main repository, the better.
> >
> > Yep, the fastest
Brian,
On Sun, 6 Jun 2010, Brian Swetland wrote:
> On Sun, Jun 6, 2010 at 12:24 PM, Christoph Hellwig wrote:
> >
> > Yes. That's what makes me wonder about some parts of the discussion
> > here. Getting the drivers for one or more of the android plattforms
> > in is not a problem. I'd say it
Alan,
On Sun, 6 Jun 2010, Alan Stern wrote:
> On Sun, 6 Jun 2010, Matthew Garrett wrote:
>
> > The difference between idle-based suspend and opportunistic suspend is
> > that the former will continue to wake up for timers and will never be
> > entered if something is using CPU, whereas the lat
Alan,
On Mon, 7 Jun 2010, Alan Stern wrote:
> On Mon, 7 Jun 2010, Thomas Gleixner wrote:
> > #2 is a tad harder, as it requires to fix the trusted apps not to fire
> >timers when there is nothing to do.
>
> No; all you have to do is handle the trusted apps as though t
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
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 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
On Wed, 30 Mar 2011, Linus Torvalds wrote:
> On Wed, Mar 30, 2011 at 10:06 AM, Arnd Bergmann wrote:
> >
> > I'm still new to the ARM world, but I think one real problem is the way
> > that all platforms have their own trees with a very flat hierarchy --
> > a lot of people directly ask Linus to pu
On Wed, 30 Mar 2011, Tony Lindgren wrote:
> * Thomas Gleixner [110330 14:07]:
> >
> > So one person will be not enough, that needs to be a whole team of
> > experienced people in the very near future to deal with the massive
> > tsunami of crap which is targeted at
On Wed, 30 Mar 2011, Tony Lindgren wrote:
> * Thomas Gleixner [110330 15:22]:
> > On Wed, 30 Mar 2011, Tony Lindgren wrote:
> >
> > > * Thomas Gleixner [110330 14:07]:
> > > >
> > > > So one person will be not enough, that needs to be a whol
On Wed, 30 Mar 2011, Tony Lindgren wrote:
> * Paul E. McKenney [110330 15:35]:
> > On Wed, Mar 30, 2011 at 02:54:35PM -0700, Tony Lindgren wrote:
> > > * Thomas Gleixner [110330 14:07]:
> > > >
> > > > So one person will be not enough, that needs
B1;2401;0cOn Thu, 31 Mar 2011, Nicolas Pitre wrote:
> On Wed, 30 Mar 2011, Linus Torvalds wrote:
> > And ARM fanbois can say "oh, but arm is special" all they want, but
> > they need to realize that the lack of common platform for ARM is a
> > real major issue. It's not a "feature", and I'm sorry,
On Thu, 31 Mar 2011, Russell King - ARM Linux wrote:
> On Thu, Mar 31, 2011 at 10:06:34AM +0200, Ingo Molnar wrote:
> > Having strong, effective platform abstractions inside the kernel really
> > helps
> > even if the hardware space itself is inevitably fragmented: both powerpc
> > and
> > x86
On Wed, 30 Mar 2011, Linus Torvalds wrote:
> On Wed, Mar 30, 2011 at 6:15 PM, Bill Gatliff wrote:
> >
> > I'm not sure this metric is completely fair to ARM. If you want to
> > level the field, I think you have to divide each result by the number
> > of SoC's
>
> But that's the problem with ARM
On Thu, 31 Mar 2011, Russell King - ARM Linux wrote:
> And I'm not going to be merging anything into my tree for the time being.
> I know there's no way for me to continue without being moaned at by someone.
> So I'm just going to take the easy option at the moment and do precisely
> nothing in ter
On Thu, 31 Mar 2011, Kevin Hilman wrote:
> Thomas Gleixner writes:
>
> > But the current SoC maintainer model does not work either. The SoC
> > maintainers care about their sandbox and have exactly zero incentive
> > to look at the overall picture, e.g reuse of code fo
On Thu, 31 Mar 2011, Arnd Bergmann wrote:
> On Thursday 31 March 2011, Kevin Hilman wrote:
> > Some SoCs families (like OMAP) have huge amount of diversity even within
> > the SoC family, so better abstractions and generic infrastrucure
> > improvements are an obvious win, even staying within the
On Thu, 31 Mar 2011, Nicolas Pitre wrote:
> On Thu, 31 Mar 2011, da...@lang.hm wrote:
>
> > I think that part of the issue is that when Linus points out a problem, the
> > response isn't "we agree and are working on it, here's what we are doing",
> > instead it seems to be mostly "there is no prob
On Thu, 31 Mar 2011, Nicolas Pitre wrote:
> On Thu, 31 Mar 2011, Thomas Gleixner wrote:
>
> > Start off with such a trivial, but immense effective cleanup and see
> > what it helps to share code even accross SoC vendors. They all glue
> > together random IP blocks from
On Thu, 31 Mar 2011, Nicolas Pitre wrote:
> On Thu, 31 Mar 2011, Linus Torvalds wrote:
> > What I'm _not_ seeing is a lot of cross-platform maintenance or sense
> > of people trying to reign things in and look for solutions to the
> > proliferation of random stupid and mindless platform code.
>
>
On Fri, 9 Sep 2011, Santosh wrote:
> On Thursday 08 September 2011 11:57 PM, Kevin Hilman wrote:
> > Santosh Shilimkar writes:
> >
> > > OMAP WakeupGen is the interrupt controller extension used along
> > > with ARM GIC to wake the CPU out from low power states on
> > > external interrupts.
> >
On Fri, 9 Sep 2011, Santosh wrote:
> On Friday 09 September 2011 12:49 PM, Thomas Gleixner wrote:
> >
> > The flag says: MASK ON SUSPEND and it does not imply that you don't
> > need a wake function. There might be cases where you want to setup
> > stuff in th
On Fri, 9 Sep 2011, Santosh wrote:
> On Friday 09 September 2011 01:48 PM, Thomas Gleixner wrote:
> > On Fri, 9 Sep 2011, Santosh wrote:
> > > On Friday 09 September 2011 12:49 PM, Thomas Gleixner wrote:
> > > >
> > > > The flag says: MASK ON SU
On Fri, 7 Oct 2011, Arnd Bergmann wrote:
> On Friday 07 October 2011, Kevin Hilman wrote:
> > > I've pulled in rmk/devel-stable as a dependency now, thanks for
> > > reminding me of that.
> > >
> > > Thomas, where should I get the irq-core branch (or whichever
> > > I should wait for) to pull in a
Linus,
On Tue, 23 Aug 2011, Linus Torvalds wrote:
> but the "there is no difference for others" seems to be total crap,
> exactly because it results in this IRQF mismatch.
>
> So I think that commit should just be reverted. Thomas?
Yes. I missed that detail when I applied that patch. Reverting i
On Wed, 25 Apr 2012, NeilBrown wrote:
> Level triggered interrupts do not cause IRQS_PENDING to be set, so
> check_wakeup_irqs ignores them.
> They don't need to set IRQS_PENDING as the level stays high which
> shows that they must be pending. However if such an interrupt fired
> during late susp
On Wed, 25 Apr 2012, NeilBrown wrote:
> On Wed, 25 Apr 2012 10:50:15 +0200 (CEST) Thomas Gleixner
> wrote:
>
> > On Wed, 25 Apr 2012, NeilBrown wrote:
> >
> > > Level triggered interrupts do not cause IRQS_PENDING to be set, so
> > > check_wakeup_irqs ign
Neil,
On Fri, 4 May 2012, NeilBrown wrote:
> On Wed, 25 Apr 2012 14:54:54 +0200 (CEST) Thomas Gleixner
> wrote:
>
> > Why not simply managing the pending bit for level irqs ?
> >
>
> Hi Thomas,
> thanks again for the patch. I finally made time to test it and
On Mon, 10 Sep 2012, NeilBrown wrote:
>
> The IRQCHIP_MASK_ON_SUSPEND flag seems to be hard to use correctly, so either
> I'm understanding it wrongly, or it could be made easier to use.
> If the first case, I'm hoping that some improvement to documentation might
> result. If the second, then may
On Mon, 10 Sep 2012, Shilimkar, Santosh wrote:
> Thomas,
>
> On Mon, Sep 10, 2012 at 3:58 PM, Thomas Gleixner wrote:
> > On Mon, 10 Sep 2012, NeilBrown wrote:
> >>
> >> The IRQCHIP_MASK_ON_SUSPEND flag seems to be hard to use correctly, so
> >> eithe
On Tue, 11 Sep 2012, NeilBrown wrote:
> On Mon, 10 Sep 2012 12:28:35 +0200 (CEST) Thomas Gleixner
> wrote:
> > You might be looking for a different functionality. Can you explain
> > what you need?
>
> I want as particular GPIO interrupt to be masked before entering suspe
On Wed, 27 Apr 2011, Menon, Nishanth wrote:
> On Wed, Apr 27, 2011 at 12:49, Colin Cross wrote:
> > I proposed in a different thread on LKML that DVFS be handled within
> > the generic clock implementation. Platforms would register a
> > regulator and a table of voltages for each struct clock tha
On Wed, 27 Apr 2011, Menon, Nishanth wrote:
> OPP table is just a storage and retrieval mechanism, it is upto SoC
> frameworks to choose the most adequate of solutions - e.g. OMAP has
> omap_device, hwmod and a clock framework for more intricate control to
> work in conjunction with cpuidle framew
1 - 100 of 156 matches
Mail list logo
