On Tue, 21 Jul 2009, Dmitry Torokhov wrote:
On Tue, Jul 21, 2009 at 01:49:33PM +0100, Mark Brown wrote:
On Tue, Jul 21, 2009 at 06:00:07PM +0530, Trilok Soni wrote:
Hopefully, this thread can give all details about threaded irq discussion.
http://lkml.org/lkml/2009/2/27/255
Mark,
On Wed, 22 Jul 2009, Mark Brown wrote:
On Wed, Jul 22, 2009 at 12:44:01PM +0200, Thomas Gleixner wrote:
On Tue, 21 Jul 2009, Mark Brown wrote:
I'll need to have a more detailed look at that but it's not immediately
clear to me how a driver (or even machine) should use that code
On Wed, 22 Jul 2009, Peter Zijlstra wrote:
On Wed, 2009-07-22 at 14:58 +0200, Thomas Gleixner wrote:
Thinking further we should even provide some infrastructure for that
in the common code which would handle the completion and attach it to
the interrupts in question, so the driver authors
On Wed, 22 Jul 2009, Mark Brown wrote:
On Wed, Jul 22, 2009 at 04:18:26PM +0200, Thomas Gleixner wrote:
On Wed, 22 Jul 2009, Peter Zijlstra wrote:
Also, how important is it that subhandler1..n run in their own thread?
That is, can't we let them run from the thread that is otherwise
On Wed, 22 Jul 2009, Dmitry Torokhov wrote:
I don't think it belongs into the driver code. It belongs into the
platform code which sets up the system and knows what's on which
interrupt line.
I do think this should be set up by the driver - the platform/arch code
can't be 100%
On Wed, 22 Jul 2009, David Brownell wrote:
On Wednesday 22 July 2009, Peter Zijlstra wrote:
Wouldn't it be better if we could express the nesting property from
within genirq, so that we can do things like:
register_chip_nested(parent_chip, parent_irq, slave_chip);
And let genirq
Jean,
On Thu, 12 Nov 2009, Jean Delvare wrote:
As far as I can see, yield() doesn't have clear semantics attached.
It's more of a utility function everyone could use as they see fit. In
that respect, I understand your concerns about the coders' expectations
and how they could be dismissed by
On Wed, 18 Nov 2009, Jean Delvare wrote:
On Wed, 18 Nov 2009 17:28:53 +0100, Leon Woestenberg wrote:
On Wed, Nov 18, 2009 at 2:05 AM, Alan Cox a...@lxorguk.ukuu.org.uk wrote:
Our timers are very efficient and some day we will need to make jiffies a
function and stop the timer ticking for
On Wed, 18 Nov 2009, Sven-Thorsten Dietrich wrote:
On Wed, 2009-11-18 at 17:52 +0100, Jean Delvare wrote:
On Wed, 18 Nov 2009 17:28:53 +0100, Leon Woestenberg wrote:
On Wed, Nov 18, 2009 at 2:05 AM, Alan Cox a...@lxorguk.ukuu.org.uk
wrote:
Our timers are very efficient and some day
On Wed, 18 Nov 2009, Sven-Thorsten Dietrich wrote:
We are trying to get rid of __sched_yield calls from-inside-the-Kernel,
but sys_sched_yield() from user-space will remain.
This patch breaks out the in-Kernel interface for the yield()
functionality and deprecates it explicitly.
The
On Mon, 8 Apr 2013, Kevin Strasser wrote:
--- /dev/null
+++ b/drivers/mfd/kempld-core.c
+#include linux/kernel.h
+#include linux/module.h
+#include linux/init.h
+#include linux/list.h
+#include linux/device.h
+#include linux/platform_device.h
+#include linux/dmi.h
+#include linux/slab.h
On Mon, 27 Jul 2015, Matt Fleming wrote:
[BAD]
3: 1 0 0 0 IR-IO-APIC 3-edge
6: 0 0 0 0 IR-IO-APIC 6-edge
dw_dmac
7: 15 1 0 0 IR-IO-APIC 7-edge
INT3432:00,
On Tue, 25 Aug 2015, Anders Roxell wrote:
The exynos5_i2c_message_start enables interrupts while holding the i2c
lock which is sought by the irq handler. If an IRQ is received before
this lock is released then a deadlock occurs.
That's crap. The interrupt handler runs in an irq thread as RT
On Thu, 3 Sep 2015, Anders Roxell wrote:
> The current spin_lock_irqsave() protects the enabling of the device
> interrupt. In order to prevent recursion in the case of sleeping
> spinlocks (e.g. with RT patch, stacktrace below), convert the spin lock
> to a raw spin lock. No change for !RT
On Wed, 11 Nov 2015, Andy Shevchenko wrote:
> The read and write opcodes are global for all units on SoC and even across
> Intel SoCs. Remove duplication of corresponding constants. At the same time
> convert all current users.
>
> No functional change.
>
> C
On Wed, 25 Nov 2015, Andy Shevchenko wrote:
> …we are working on another fix which is based also on this patch. Can
> you provide your ACK if you are okay with the changes to arch/x86 ?
I'm fine with the patch. Once I have acks, I'll pick it up.
Thanks,
tglx
16 matches
Mail list logo
