Felipe,
On Tue, 29 Dec 2015, Felipe Balbi wrote:
> Anyway, the interesting part is that PRUSS has 64 events (on current
> incarnations at least) and PRUSS has 10 physical IRQ lines to the ARM
> land. Each of these 64 events can be routed to any of these 10 IRQ
> lines. This might not be very
Felipe,
On Wed, 30 Dec 2015, Felipe Balbi wrote:
> Thomas Gleixner <t...@linutronix.de> writes:
> > - Is there a "mapping" block between PRUSS and the host interrupt
> > controller
> >or is this "mapping" block part of PRUSS?
>
> The de
On Fri, 20 Nov 2015, John Stultz wrote:
> So its unlikely that the hardware both stays running through suspend,
> but also might halt in idle. That would be "unique".
The amount of creativity put into the next variants of differently
broken timers is amazing. So I wouldn't be too surprised if
On Mon, 19 Oct 2015, Sekhar Nori wrote:
> + /*
> + * A spurious IRQ can result if interrupt that triggered the
> + * sorting is no longer active during the sorting (10 INTC
> + * functional clock cycles after interrupt assertion). Or a
> + * change in interrupt mask
Grygorii,
On Tue, 13 Oct 2015, Grygorii Strashko wrote:
> I'd very appreciate for any advice of how to better proceed with your request.
> - I can try to apply and re-send only patches marked by '*'
> - I can prepare branch with all above patches
Please provide a branch on top of 4.1.10 which
Grygorii,
can you please provide a patch set against 4.1-RT? That stuff rejects
left and right.
Thanks,
tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at
Mans,
On Fri, 9 Oct 2015, Mans Rullgard wrote:
> This passes a data pointer specified in the sched_clock_register()
> call to the read callback allowing simpler implementations thereof.
>
> In this patch, existing uses of this interface are simply updated
> with a null pointer.
I can't see any
On Tue, 25 Aug 2015, Felipe Balbi wrote:
Hi Ingo,
Thanks for not cc'ing the irq maintainer
I'm facing an issue with CONFIG_DEBUG_SHIRQ and pm_runtime when using
devm_request_*irq().
If we using devm_request_*irq(), that irq will be freed after device
drivers' -remove() gets called.
On Mon, 27 Jul 2015, Sebastian Andrzej Siewior wrote:
On 07/27/2015 02:50 PM, Linus Walleij wrote:
Patch applied.
thanks.
Now this question appear in my head:
Is drivers/gpio full of stuff that will not work with the -RT kernel,
and is this a change that should be done mutatis
On Mon, 20 Jul 2015, Felipe Balbi wrote:
+ irqnr = intc_readl(INTC_SIR);
+ irqnr = ACTIVEIRQ_MASK;
+ WARN(!irqnr, Spurious IRQ ?\n);
Shouldn't that be WARN_ONCE?
Thanks,
tglx
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message
On Wed, 15 Jul 2015, Tony Lindgren wrote:
Felipe,
* Tony Lindgren t...@atomide.com [150119 13:41]:
* Felipe Balbi ba...@ti.com [150102 10:50]:
as it turns out the current IRQ number will
*always* be available from SIR register which
renders the reads of PENDING registers as plain
On Mon, 6 Jul 2015, Tony Lindgren wrote:
* Thomas Gleixner t...@linutronix.de [150706 07:20]:
On Mon, 6 Jul 2015, Tony Lindgren wrote:
The timekeeping accuracy issue certainly needs some thinking, and
also the resolution between the clocksources can be different.. In the
test case I have
On Mon, 6 Jul 2015, John Stultz wrote:
On Mon, Jul 6, 2015 at 12:12 AM, Tony Lindgren t...@atomide.com wrote:
Some persistent clocksources can be on a slow external bus. For shorter
latencies for RT use, let's allow toggling the clocksource during idle
between a faster non-persistent
On Mon, 6 Jul 2015, Tony Lindgren wrote:
Some persistent clocksources can be on a slow external bus. For shorter
latencies for RT use, let's allow toggling the clocksource during idle
between a faster non-persistent runtime clocksource and a slower persistent
clocksource.
I really cannot
On Fri, 19 Jun 2015, Kevin Hilman wrote:
On Wed, Jun 17, 2015 at 1:33 AM, Sebastian Andrzej Siewior
A handful of boot test failures on ARM/OMAP were found by kernelci.org
in next-20150619[1] and were bisected down to this patch, which hit
next-20150619 in the form of commit 881bd58d6e9e
On Wed, 20 May 2015, Jiang Liu wrote:
On 2015/5/20 23:28, Thomas Gleixner wrote:
On Wed, 20 May 2015, Jiang Liu wrote:
-static void locomo_handler(unsigned int irq, struct irq_desc *desc)
+static void locomo_handler(struct irq_desc *desc)
{
struct locomo *lchip
On Wed, 20 May 2015, Jiang Liu wrote:
-static void locomo_handler(unsigned int irq, struct irq_desc *desc)
+static void locomo_handler(struct irq_desc *desc)
{
struct locomo *lchip = irq_desc_get_chip_data(desc);
+ unsigned int irq;
int req, i;
That leaves irq unitialized
On Wed, 10 Dec 2014, Joe Perches wrote:
As far as I can tell, there's no value indirecting
the cpu passed to this function via a void *.
Update all the callers and called functions from within
clockevents_notify.
Aside of that there is no value for this 'notification' function at
all. This
Tony,
On Thu, 6 Nov 2014, Tony Lindgren wrote:
Any comments on the patch below? Let me know if you want to keep the
devm stuff out of kernel/irq/manage.c.
Sorry, this slipped through the cracks.
+static int setup_wakeirq(struct device *dev, unsigned int wakeirq,
+
On Thu, 13 Nov 2014, Tony Lindgren wrote:
Oops thanks for catching that. As the devres stuff is separate, I've
updated the patch to keep it that way by adding a minimal manage.h.
This avoids including internals.h in devres.c. Does that seem usable
for you?
What's wrong with internals.h?
On Thu, 18 Sep 2014, Nishanth Menon wrote:
On 17:57-20140918, Thomas Gleixner wrote:
I suppose I can improve the commit message to elaborate this better?
Will that help?
You also want to improve the comment in the empty handler.
+ */
+ return IRQ_NONE;
And it still does
On Fri, 19 Sep 2014, Nishanth Menon wrote:
On 08:37-20140919, Thomas Gleixner wrote:
The other omap drivers using this have the same issue ... And of
course they are subtly different.
The uart one handles the actual device interrupt, which is violating
the general rule of possible
On Fri, 19 Sep 2014, Tony Lindgren wrote:
* Thomas Gleixner t...@linutronix.de [140919 10:37]:
From hardware point of view the wake-up events behave like interrupts
and could also be used as the only interrupt in some messed up cases.
That avoids all kinds of custom APIs from driver point
On Fri, 19 Sep 2014, Tony Lindgren wrote:
* Thomas Gleixner t...@linutronix.de [140919 12:47]:
Why on earth are you wanting tasklets in there? That's just silly,
really.
Lack of a framework on driver side to cope with this in a generic
way? :p
So instead of creating such a thing we
On Thu, 18 Sep 2014, Nishanth Menon wrote:
+static irqreturn_t palmas_wake_irq(int irq, void *_palmas)
+{
+ /*
+ * Return Not handled so that interrupt is disabled.
And how is that interrupt disabled by returning IRQ_NONE? You mean it
gets disabled after it got reraised 10 times
On Fri, 5 Sep 2014, Nishanth Menon wrote:
+ if (!palmas-wakeirq)
+ goto no_wake_irq;
+
+ ret = devm_request_irq(palmas-dev, palmas-wakeirq,
+palmas_wake_irq,
+IRQF_ONESHOT | pdata-irq_flags,
Why is this marked
On Wed, 3 Sep 2014, Jason Cooper wrote:
On Wed, Aug 27, 2014 at 10:33:44AM +0100, Marc Zyngier wrote:
Hi Thomas,
On Tue, Aug 26 2014 at 10:34:51 pm BST, Thomas Gleixner
t...@linutronix.de wrote:
On Tue, 26 Aug 2014, Marc Zyngier wrote:
A number of irqchip drivers are directly
On Wed, 3 Sep 2014, Marc Zyngier wrote:
[Dropping li...@openrisc.net from the CC list]
On 03/09/14 13:09, Thomas Gleixner wrote:
On Wed, 3 Sep 2014, Jason Cooper wrote:
On Wed, Aug 27, 2014 at 10:33:44AM +0100, Marc Zyngier wrote:
Hi Thomas,
On Tue, Aug 26 2014 at 10:34:51 pm BST
On Tue, 26 Aug 2014, Marc Zyngier wrote:
A number of irqchip drivers are directly calling irq_find_mapping,
which may use a rcu_read_lock call when walking the radix tree.
Turns out that if you hit that point with CONFIG_PROVE_RCU enabled,
the kernel will shout at you, as using RCU in this
On Fri, 13 Jun 2014, Jason Cooper wrote:
On Fri, Jun 13, 2014 at 09:48:24AM -0700, Joe Perches wrote:
On Fri, 2014-06-13 at 12:37 -0400, Jason Cooper wrote:
On Fri, Jun 13, 2014 at 09:14:34AM -0700, Joe Perches wrote:
On Fri, 2014-06-13 at 11:01 -0400, Jason Cooper wrote:
Please
On Tue, 10 Jun 2014, Brian Norris wrote:
Other random thought: it seems like any irqchip driver which does lazy IRQ
masking ought to use IRQCHIP_MASK_ON_SUSPEND. So maybe the IRQ core should
just
do something like:
if (!chip-irq_disable)
chip-flags |=
On Tue, 3 Jun 2014, Sricharan R wrote:
Please Cc all maintainers on such changes plus the relevant
mailinglist. See MAINTAINERS.
Thanks,
tglx
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info
Use the proper functions. There is no need to fiddle with irq_desc.
Signed-off-by: Thomas Gleixner t...@linutronix.de
Cc: Shawn Guo shawn@linaro.org
Cc: arm linux-arm-ker...@lists.infradead.org
Cc: omap linux-omap@vger.kernel.org
Cc: Tony Lindgren t...@atomide.com
Cc: Russell King rmk+ker
On Mon, 3 Feb 2014, Sricharan R wrote:
I already have your reviewed-by tag for the first patch in this series.
Kevin was pointing out that irqchip maintainer tag is needed for this patch
as well
to be merged. We are planning to take this series through arm-soc tree.
Can i please
On Thu, 14 Nov 2013, Sricharan R wrote:
[V3] Addressed unnecessary warn-on and updated default
xlate function as per Thomas Gleixner comments
Reviewed-by: Thomas Gleixner t...@linutronix.de
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message
On Wed, 30 Oct 2013, Sricharan R wrote:
@@ -700,11 +709,22 @@ static int gic_irq_domain_xlate(struct irq_domain *d,
*out_hwirq = intspec[1] + 16;
/* For SPIs, we need to add 16 more to get the GIC irq ID number */
- if (!intspec[0])
+ if (!intspec[0]) {
On Wed, 30 Oct 2013, Sricharan R wrote:
+static inline const u32 allocate_free_irq(int cb_no)
I understand the static inline part, but const u32 is more than
fishy. What's wrong with static inline int ?
+{
+ int i;
+
+ for (i = 0; i cb-int_max; i++) {
+ if
On Tue, 1 Oct 2013, Rob Herring wrote:
On 10/01/2013 06:13 AM, Sricharan R wrote:
Is there an actual usecase on a single h/w design that you run out of
interrupts and it is a user decision which interrupts to use?
I don't think that matters. What matters is that you have a single DT
entry
On Mon, 30 Sep 2013, Sricharan R wrote:
diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
index 1760ceb..c5778ab 100644
--- a/drivers/irqchip/irq-gic.c
+++ b/drivers/irqchip/irq-gic.c
@@ -72,6 +72,8 @@ struct gic_chip_data {
static
On Mon, 30 Sep 2013, Sricharan R wrote:
+/*
+ * @int_max: maximum number of supported interrupts
+ * @irq_map: array of interrupts to crossbar number mapping
+ * @crossbar_base: crossbar base address
+ * @register_offsets: offsets for each irq number
+ */
+struct crossbar_device {
+
On Wed, 18 Sep 2013, Sricharan R wrote:
On Wednesday 18 September 2013 07:22 PM, Sricharan R wrote:
Hi Thomas,
On Tuesday 17 September 2013 05:56 PM, Linus Walleij wrote:
On Fri, Sep 13, 2013 at 4:24 PM, Thomas Gleixner t...@linutronix.de
wrote:
So why can't you make use of irq
On Wed, 18 Sep 2013, Santosh Shilimkar wrote:
On Friday 13 September 2013 10:55 AM, Santosh Shilimkar wrote:
On Friday 13 September 2013 10:24 AM, Thomas Gleixner wrote:
[...]
Before you dig into MSI, lets talk about irq domains first.
GIC implements a legacy irq domain, i.e
On Thu, 12 Sep 2013, Santosh Shilimkar wrote:
On Thursday 12 September 2013 08:26 PM, Thomas Gleixner wrote:
Let me summarize:
- GIC supports up to 160 interrupts
- CROSSBAR supports up to 250 interrupts
- CROSSBAR routes up to 160 out of 250 interrupts to the GIC ones
On Thu, 12 Sep 2013, Sricharan R wrote:
Signed-off-by: Sricharan R r.sricha...@ti.com
---
There is lockdep warning during the boot. This is because we try to
do one request_irq with in another and that results in kmalloc being
called from an atomic context, which generates the warning.
Any
On Thu, 12 Sep 2013, Felipe Balbi wrote:
On Thu, Sep 12, 2013 at 09:09:08PM +0530, Sricharan R wrote:
+unsigned int crossbar_request_irq(struct irq_data *d)
+{
+ int cb_no = d-hwirq;
+ int virq = allocate_free_irq(cb_no);
+ void *irq = cb-crossbar_map[cb_no].hwirq;
+ int err;
On Thu, 12 Sep 2013, Thomas Gleixner wrote:
On Thu, 12 Sep 2013, Felipe Balbi wrote:
On Thu, Sep 12, 2013 at 09:09:08PM +0530, Sricharan R wrote:
+unsigned int crossbar_request_irq(struct irq_data *d)
+{
+ int cb_no = d-hwirq;
+ int virq = allocate_free_irq(cb_no);
+ void *irq
On Thu, 12 Sep 2013, Santosh Shilimkar wrote:
Specifically for the IRQ case addressed here, the cross-bar IP
sits between the interrupt controller and peripheral interrupts.
CPU -- GIC - CROSSBAR - PERIPHERAL IRQs
Just to expand it better, cross-bar input IRQ lines are more than
On Thu, 12 Sep 2013, Santosh Shilimkar wrote:
On Thursday 12 September 2013 06:22 PM, Thomas Gleixner wrote:
Now the real question is, how that expansion mechanism is supposed to
work. There are two possible scenarios:
1) Expand the number of handled interrupts beyond the GIC capacity
the rating of the dummy clockevent so that
real clockevent device is selected when available.
Acked-by: Mark Rutland mark.rutl...@arm.com
Acked-by: Thomas Gleixner t...@linutronix.de
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/kernel/smp.c |2 +-
1 file changed
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
On Wed, 13 Mar 2013, Santosh Shilimkar wrote:
On Wednesday 13 March 2013 07:49 PM, Thomas Gleixner wrote:
Though making the rating of the dummy lower is definitely a good
thing, so a real hardware device which is detected later can replace
the dummy device. So yes, the rating should be low
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
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
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
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, 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 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 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, 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
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
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
@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
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
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, 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
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, 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 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
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 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
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
1 - 100 of 150 matches
Mail list logo
