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
li...@arm.linux.org.uk wrote:
On Mon, Jan 24, 2011 at 11:06:09AM +, Russell King - ARM Linux wrote:
On Mon, Jan
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 do more ?
I can't say
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 which way? I mean the generic code issues a call
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
().
Signed-off-by: Thomas Gleixner t...@linutronix.de
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 elaborate
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 t...@linutronix.de
Cc: Tony Lindgren t...@atomide.com
Cc: linux-omap
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 with which
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 well
On Thu, 27 May 2010, Florian Mickler wrote:
On Wed, 26 May 2010 22:03:37 +0200
Vitaly Wool vitalyw...@gmail.com wrote:
On Wed, May 26, 2010 at 9:56 PM, Florian Mickler flor...@mickler.org
wrote:
Your approach definitely sounds better than the current solution.
What about mapping
On Wed, 26 May 2010, Florian Mickler wrote:
On Wed, 26 May 2010 19:22:16 +0200 (CEST)
Thomas Gleixner t...@linutronix.de wrote:
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
On Wed, 26 May 2010, Arve Hjønnevåg wrote:
2010/5/26 Alan Cox a...@lxorguk.ukuu.org.uk:
On Wed, 26 May 2010 15:30:58 -0700
Arve Hjønnevåg a...@android.com wrote:
On Wed, May 26, 2010 at 6:16 AM, Alan Cox a...@lxorguk.ukuu.org.uk wrote:
Really, what are you getting at? Do you deny that
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
- Your
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 pet...@infradead.org 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 input layer takes a suspend block
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, but I'm
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 you want
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 wakeup events. The bit that mitigates badly
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 has longer takedown and wakeup latencies
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:
The
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 based on scheduler constraints. Suspend
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 just paper over
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 as it does not evaluate
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 event?
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 to sleep.
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. And from 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 don't have any useful ability
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, the system
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.
may also
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.
Ah, now we talk about PCs. And all of a sudden
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 that wakes the system - if a system
can't be woken
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, ext Alan Stern wrote:
If people don't mind, here
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 suspend to disk is the same as force suspend
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's an
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.
Strange,
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 thing
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 most of the time it does a pretty
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 adding a hard to maintain user
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 handling
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 that
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, and therefore
On Mon, 31 May 2010, Arve Hjønnevåg wrote:
On Mon, May 31, 2010 at 2:46 PM, Thomas Gleixner t...@linutronix.de 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 idle but I'm not sure how much
On Mon, 31 May 2010, Arve Hjønnevåg wrote:
2010/5/31 Rafael J. Wysocki r...@sisk.pl:
On Monday 31 May 2010, Arve Hjønnevåg wrote:
2010/5/30 Rafael J. Wysocki r...@sisk.pl:
...
I think it makes more sense to block suspend while wakeup events are
pending than blocking it everywhere
On Tue, 1 Jun 2010, Arve Hjønnevåg wrote:
2010/6/1 Thomas Gleixner t...@linutronix.de:
On Mon, 31 May 2010, Arve Hjønnevåg wrote:
On Mon, May 31, 2010 at 2:46 PM, Thomas Gleixner t...@linutronix.de
wrote:
On Mon, 31 May 2010, James Bottomley wrote:
For MSM hardware, it looks
On Wed, 2 Jun 2010, Arve Hjønnevåg wrote:
2010/6/2 Thomas Gleixner t...@linutronix.de:
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
an error if an app
On Tue, 1 Jun 2010, Arve Hjønnevåg wrote:
2010/6/1 Thomas Gleixner t...@linutronix.de:
On Mon, 31 May 2010, Arve Hjønnevåg wrote:
2010/5/31 Rafael J. Wysocki r...@sisk.pl:
On Monday 31 May 2010, Arve Hjønnevåg wrote:
2010/5/30 Rafael J. Wysocki r...@sisk.pl:
...
I think
On Wed, 2 Jun 2010, Arve Hjønnevåg wrote:
2010/6/2 Neil Brown ne...@suse.de:
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
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 made to
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 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
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
B1;2005;0cOn Fri, 4 Jun 2010, Arve Hjønnevåg wrote:
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
On Sat, 5 Jun 2010, Florian Mickler wrote:
On Sat, 5 Jun 2010 23:26:27 +0300
Felipe Contreras felipe.contre...@gmail.com 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
On Sat, 5 Jun 2010, Florian Mickler wrote:
On Sat, 5 Jun 2010 23:24:40 +0200 (CEST)
Thomas Gleixner t...@linutronix.de wrote:
Stop that advertising campaing already.
Stop advertising that there is no problem.
No thanks,
tglx
Cheers,
Flo
(Sorry, crossfire. Caused
On Sat, 5 Jun 2010, Arve Hjønnevåg wrote:
2010/6/5 Thomas Gleixner t...@linutronix.de:
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 ?
It is not, but we have had bugs where a trusted app
On Sat, 5 Jun 2010, Arjan van de Ven wrote:
On Sat, 5 Jun 2010 15:26:36 -0700
Brian Swetland swetl...@google.com 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
On Sat, 5 Jun 2010, Arve Hjønnevåg wrote:
2010/6/5 Thomas Gleixner t...@linutronix.de:
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 unconfined and prevent
lower power states
On Sat, 5 Jun 2010, Arve Hjønnevåg wrote:
2010/6/5 Thomas Gleixner t...@linutronix.de:
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 while a trusted app still works in the background
On Sat, 5 Jun 2010, Arve Hjønnevåg wrote:
2010/6/5 Thomas Gleixner t...@linutronix.de:
On Sat, 5 Jun 2010, Arve Hjønnevåg wrote:
2010/6/5 Thomas Gleixner t...@linutronix.de:
B1;2005;0cOn Fri, 4 Jun 2010, Arve Hjønnevåg wrote:
Cross app calls do not go through a central process.
It's
On Sat, 5 Jun 2010, Arve Hjønnevåg wrote:
2010/6/5 Thomas Gleixner t...@linutronix.de:
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
was frozen beforehand
On Sat, 5 Jun 2010, Arve Hjønnevåg wrote:
2010/6/5 Thomas Gleixner t...@linutronix.de:
On Sat, 5 Jun 2010, Arve Hjønnevåg wrote:
2010/6/5 Thomas Gleixner t...@linutronix.de:
On Sat, 5 Jun 2010, Arve Hjønnevåg wrote:
That download might take a minute or two, but that's
On Sat, 5 Jun 2010, Arve Hjønnevåg wrote:
2010/6/5 Thomas Gleixner t...@linutronix.de:
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 separation of trust level works
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 kernel
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
bring the android tree close enough to the kernel so
On Sun, 6 Jun 2010, Brian Swetland wrote:
On Sun, Jun 6, 2010 at 11:04 AM, Thomas Gleixner t...@linutronix.de 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 way is to provide two stub inlines
Brian,
On Sun, 6 Jun 2010, Brian Swetland wrote:
On Sun, Jun 6, 2010 at 12:24 PM, Christoph Hellwig h...@infradead.org 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.
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 latter
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 they were
untrusted -- just
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 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 johns...@us.ibm.com wrote:
I think Thomas was suggesting that you consider creating a option for
where CLOCK_MONOTONIC included
On Fri, 9 Sep 2011, Santosh wrote:
On Thursday 08 September 2011 11:57 PM, Kevin Hilman wrote:
Santosh Shilimkarsantosh.shilim...@ti.com writes:
OMAP WakeupGen is the interrupt controller extension used along
with ARM GIC to wake the CPU out from low power states on
external
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 that function in order to have the wakeup happen
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 SUSPEND and it does not imply that you don't
need a wake
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 as another
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 maybe
On Mon, 10 Sep 2012, Shilimkar, Santosh wrote:
Thomas,
On Mon, Sep 10, 2012 at 3:58 PM, Thomas Gleixner t...@linutronix.de wrote:
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
On Tue, 11 Sep 2012, NeilBrown wrote:
On Mon, 10 Sep 2012 12:28:35 +0200 (CEST) Thomas Gleixner
t...@linutronix.de 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 suspend.
I
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 it
On Tue, 23 Oct 2012, Kevin Hilman wrote:
Russell King - ARM Linux li...@arm.linux.org.uk writes:
On Tue, Oct 16, 2012 at 03:07:49PM -0700, Kevin Hilman wrote:
From: Thomas Gleixner t...@linutronix.de
Attempts to retrigger nested threaded IRQs currently fail because they
have
Neil,
On Fri, 4 May 2012, NeilBrown wrote:
On Wed, 25 Apr 2012 14:54:54 +0200 (CEST) Thomas Gleixner
t...@linutronix.de 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 it works as
expected
On Wed, 27 Apr 2011, Menon, Nishanth wrote:
On Wed, Apr 27, 2011 at 12:49, Colin Cross ccr...@google.com 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
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
@gmail.com
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
Reviewed-by: Thomas Gleixner t...@linutronix.de
Please take this through the ARM tree. It's not conflicting with
anything in my tree.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message
acks ASAP. Thanks to Mark for pointing this out with a patch
for Samsung.
Acked-by: Thomas Gleixner t...@linutronix.de
Sorry for the confusion, that patch should have hit the arm kernel
list two weeks ago, but for whatever reason it did not.
Thanks,
tglx
--
To unsubscribe from this list
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 suspend,
On Wed, 25 Apr 2012, NeilBrown wrote:
On Wed, 25 Apr 2012 10:50:15 +0200 (CEST) Thomas Gleixner
t...@linutronix.de wrote:
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
On Tue, 13 Dec 2011, Mike Turquette wrote:
+void __clk_unprepare(struct clk *clk)
+{
+ if (!clk)
+ return;
+
+ if (WARN_ON(clk-prepare_count == 0))
+ return;
+
+ if (--clk-prepare_count 0)
+ return;
+
+ WARN_ON(clk-enable_count 0);
On Wed, 30 Mar 2011, Linus Torvalds wrote:
On Wed, Mar 30, 2011 at 10:06 AM, Arnd Bergmann a...@arndb.de 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
On Wed, 30 Mar 2011, Tony Lindgren wrote:
* Thomas Gleixner t...@linutronix.de [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 mainline. If we fail
On Wed, 30 Mar 2011, Tony Lindgren wrote:
* Thomas Gleixner t...@linutronix.de [110330 15:22]:
On Wed, 30 Mar 2011, Tony Lindgren wrote:
* Thomas Gleixner t...@linutronix.de [110330 14:07]:
So one person will be not enough, that needs to be a whole team of
experienced people
On Wed, 30 Mar 2011, Tony Lindgren wrote:
* Paul E. McKenney paul...@linux.vnet.ibm.com [110330 15:35]:
On Wed, Mar 30, 2011 at 02:54:35PM -0700, Tony Lindgren wrote:
* Thomas Gleixner t...@linutronix.de [110330 14:07]:
So one person will be not enough, that needs to be a whole
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, but
On Wed, 30 Mar 2011, Linus Torvalds wrote:
On Wed, Mar 30, 2011 at 6:15 PM, Bill Gatliff b...@billgatliff.com 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
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 terms
On Thu, 31 Mar 2011, Kevin Hilman wrote:
Thomas Gleixner t...@linutronix.de 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 for the same IP
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 SoC.
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 problem, this
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 the market and there are not soo
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.
I do
On Wed, 13 Mar 2013, Santosh Shilimkar wrote:
On Wednesday 13 March 2013 02:36 PM, Santosh Shilimkar wrote:
With recent arm broadcast time clean-up from Mark Rutland, the dummy
broadcast device is always registered with timer subsystem. And since
the rating of the dummy clock event is very
1 - 100 of 150 matches
Mail list logo
