15 Dec, 2009
1 commit
-
Convert locks which cannot be sleeping locks in preempt-rt to
raw_spinlocks.Signed-off-by: Thomas Gleixner
Acked-by: Peter Zijlstra
Acked-by: Ingo Molnar
09 Dec, 2009
1 commit
-
…el.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip
* 'timers-for-linus-ntp' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
ntp: Provide compability defines (You say MOD_NANO, I say ADJ_NANO)* 'irq-core-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
genirq: do not execute DEBUG_SHIRQ when irq setup failed
12 Sep, 2009
1 commit
-
…el/git/tip/linux-2.6-tip
* 'irq-threaded-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
genirq: Do not mask oneshot edge type interrupts
genirq: Support nested threaded irq handling
genirq: Add buslock support
genirq: Add oneshot support
18 Aug, 2009
1 commit
-
The wake_up_process() of the new irq thread in __setup_irq() is too
early as the irqaction is not yet fully initialized especially
action->irq is not yet set. The interrupt thread might dereference the
wrong irq descriptor.Move the wakeup after the action is installed and action->irq has been
set.Reported-by: Michael Buesch
Signed-off-by: Thomas Gleixner
Tested-by: Michael Buesch
17 Aug, 2009
3 commits
-
Interrupt chips which are behind a slow bus (i2c, spi ...) and
demultiplex other interrupt sources need to run their interrupt
handler in a thread.The demultiplexed interrupt handlers need to run in thread context as
well and need to finish before the demux handler thread can reenable
the interrupt line. So the easiest way is to run the sub device
handlers in the context of the demultiplexing handler thread.To avoid that a separate thread is created for the subdevices the
function set_nested_irq_thread() is provided which sets the
IRQ_NESTED_THREAD flag in the interrupt descriptor.A driver which calls request_threaded_irq() must not be aware of the
fact that the threaded handler is called in the context of the
demultiplexing handler thread. The setup code checks the
IRQ_NESTED_THREAD flag which was set from the irq chip setup code and
does not setup a separate thread for the interrupt. The primary
function which is provided by the device driver is replaced by an
internal dummy function which warns when it is called.For the demultiplexing handler a helper function handle_nested_irq()
is provided which calls the demux interrupt thread function in the
context of the caller and does the proper interrupt accounting and
takes the interrupt disabled status of the demultiplexed subdevice
into account.Signed-off-by: Thomas Gleixner
Cc: Mark Brown
Cc: Dmitry Torokhov
Cc: Trilok Soni
Cc: Pavel Machek
Cc: Brian Swetland
Cc: Joonyoung Shim
Cc: m.szyprowski@samsung.com
Cc: t.fujak@samsung.com
Cc: kyungmin.park@samsung.com,
Cc: David Brownell
Cc: Daniel Ribeiro
Cc: arve@android.com
Cc: Barry Song -
Some interrupt chips are connected to a "slow" bus (i2c, spi ...). The
bus access needs to sleep and therefor cannot be called in atomic
contexts.Some of the generic interrupt management functions like disable_irq(),
enable_irq() ... call interrupt chip functions with the irq_desc->lock
held and interrupts disabled. This does not work for such devices.Provide a separate synchronization mechanism for such interrupt
chips. The irq_chip structure is extended by two optional functions
(bus_lock and bus_sync_and_unlock).The idea is to serialize the bus access for those operations in the
core code so that drivers which are behind that bus operated interrupt
controller do not have to worry about it and just can use the normal
interfaces. To achieve this we add two function pointers to the
irq_chip: bus_lock and bus_sync_unlock.bus_lock() is called to serialize access to the interrupt controller
bus.Now the core code can issue chip->mask/unmask ... commands without
changing the fast path code at all. The chip implementation merily
stores that information in a chip private data structure and
returns. No bus interaction as these functions are called from atomic
context.After that bus_sync_unlock() is called outside the atomic context. Now
the chip implementation issues the bus commands, waits for completion
and unlocks the interrupt controller bus.The irq_chip implementation as pseudo code:
struct irq_chip_data {
struct mutex mutex;
unsigned int irq_offset;
unsigned long mask;
unsigned long mask_status;
}static void bus_lock(unsigned int irq)
{
struct irq_chip_data *data = get_irq_desc_chip_data(irq);mutex_lock(&data->mutex);
}static void mask(unsigned int irq)
{
struct irq_chip_data *data = get_irq_desc_chip_data(irq);irq -= data->irq_offset;
data->mask |= (1 << irq);
}static void unmask(unsigned int irq)
{
struct irq_chip_data *data = get_irq_desc_chip_data(irq);irq -= data->irq_offset;
data->mask &= ~(1 << irq);
}static void bus_sync_unlock(unsigned int irq)
{
struct irq_chip_data *data = get_irq_desc_chip_data(irq);if (data->mask != data->mask_status) {
do_bus_magic_to_set_mask(data->mask);
data->mask_status = data->mask;
}
mutex_unlock(&data->mutex);
}The device drivers can use request_threaded_irq, free_irq, disable_irq
and enable_irq as usual with the only restriction that the calls need
to come from non atomic context.Signed-off-by: Thomas Gleixner
Cc: Mark Brown
Cc: Dmitry Torokhov
Cc: Trilok Soni
Cc: Pavel Machek
Cc: Brian Swetland
Cc: Joonyoung Shim
Cc: m.szyprowski@samsung.com
Cc: t.fujak@samsung.com
Cc: kyungmin.park@samsung.com,
Cc: David Brownell
Cc: Daniel Ribeiro
Cc: arve@android.com
Cc: Barry Song -
For threaded interrupt handlers we expect the hard interrupt handler
part to mask the interrupt on the originating device. The interrupt
line itself is reenabled after the hard interrupt handler has
executed.This requires access to the originating device from hard interrupt
context which is not always possible. There are devices which can only
be accessed via a bus (i2c, spi, ...). The bus access requires thread
context. For such devices we need to keep the interrupt line masked
until the threaded handler has executed.Add a new flag IRQF_ONESHOT which allows drivers to request that the
interrupt is not unmasked after the hard interrupt context handler has
been executed and the thread has been woken. The interrupt line is
unmasked after the thread handler function has been executed.Note that for now IRQF_ONESHOT cannot be used with IRQF_SHARED to
avoid complex accounting mechanisms.For oneshot interrupts the primary handler simply returns
IRQ_WAKE_THREAD and does nothing else. A generic implementation
irq_default_primary_handler() is provided to avoid useless copies all
over the place. It is automatically installed when
request_threaded_irq() is called with handler=NULL and
thread_fn!=NULL.Signed-off-by: Thomas Gleixner
Cc: Mark Brown
Cc: Dmitry Torokhov
Cc: Trilok Soni
Cc: Pavel Machek
Cc: Brian Swetland
Cc: Joonyoung Shim
Cc: m.szyprowski@samsung.com
Cc: t.fujak@samsung.com
Cc: kyungmin.park@samsung.com,
Cc: David Brownell
Cc: Daniel Ribeiro
Cc: arve@android.com
Cc: Barry Song
14 Aug, 2009
1 commit
-
free_irq() can remove an irqaction while the corresponding interrupt
is in progress, but free_irq() sets action->thread to NULL
unconditionally, which might lead to a NULL pointer dereference in
handle_IRQ_event() when the hard interrupt context tries to wake up
the handler thread.Prevent this by moving the thread stop after synchronize_irq(). No
need to set action->thread to NULL either as action is going to be
freed anyway.This fixes a boot crash reported against preempt-rt which uses the
mainline irq threads code to implement full irq threading.[ tglx: removed local irqthread variable ]
Signed-off-by: Linus Torvalds
Signed-off-by: Thomas Gleixner
23 Jul, 2009
1 commit
-
Since genirq: Delegate irq affinity setting to the irq thread
(591d2fb02ea80472d846c0b8507007806bdd69cc) compilation with
CONFIG_SMP=n fails with following error:/usr/src/linux-2.6/kernel/irq/manage.c:
In function 'irq_thread_check_affinity':
/usr/src/linux-2.6/kernel/irq/manage.c:475:
error: 'struct irq_desc' has no member named 'affinity'
make[4]: *** [kernel/irq/manage.o] Error 1That commit adds a new function irq_thread_check_affinity() which
uses struct irq_desc.affinity which is only available for CONFIG_SMP=y.
Move that function under #ifdef CONFIG_SMP.[ tglx@brownpaperbag: compile and boot tested on UP and SMP ]
Signed-off-by: Bruno Premont
LKML-Reference:
Signed-off-by: Thomas Gleixner
21 Jul, 2009
1 commit
-
irq_set_thread_affinity() calls set_cpus_allowed_ptr() which might
sleep, but irq_set_thread_affinity() is called with desc->lock held
and can be called from hard interrupt context as well. The code has
another bug as it does not hold a ref on the task struct as required
by set_cpus_allowed_ptr().Just set the IRQTF_AFFINITY bit in action->thread_flags. The next time
the thread runs it migrates itself. Solves all of the above problems
nicely.Add kerneldoc to irq_set_thread_affinity() while at it.
Signed-off-by: Thomas Gleixner
LKML-Reference:
21 Jun, 2009
1 commit
-
…git/tip/linux-2.6-tip
* 'irq-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
genirq, irq.h: Fix kernel-doc warnings
genirq: fix comment to say IRQ_WAKE_THREAD
13 May, 2009
1 commit
-
Trying to implement a driver to use threaded irqs, I was confused when the
return value to use that was described in the comment above
request_threaded_irq was not defined.Turns out that the enum is IRQ_WAKE_THREAD where as the comment said
IRQ_THREAD_WAKE.[Impact: do not confuse developers with wrong comments ]
Signed-off-by: Steven Rostedt
LKML-Reference:
Signed-off-by: Thomas Gleixner
28 Apr, 2009
1 commit
-
irq_set_affinity() and move_masked_irq() try to assign affinity
before calling chip set_affinity(). Some archs are assigning it
in ->set_affinity() again.We do something like:
cpumask_cpy(desc->affinity, mask);
desc->chip->set_affinity(mask);But in the failure path, affinity should not be touched - otherwise
we'll end up with a different affinity mask despite the failure to
migrate the IRQ.So try to update the afffinity only if set_affinity returns with 0.
Also call irq_set_thread_affinity accordingly.v2: update after "irq, x86: Remove IRQ_DISABLED check in process context IRQ move"
v3: according to Ingo, change set_affinity() in irq_chip should return int.
v4: update comments by removing moving irq_desc code.[ Impact: fix /proc/irq/*/smp_affinity setting corner case bug ]
Signed-off-by: Yinghai Lu
Cc: Andrew Morton
Cc: Suresh Siddha
Cc: "Eric W. Biederman"
Cc: Rusty Russell
LKML-Reference:
Signed-off-by: Ingo Molnar
23 Apr, 2009
1 commit
-
When requesting an IRQ, the DEBUG_SHIRQ code executes a fake IRQ just to make
sure the driver is ready to receive an IRQ immediately. The problem was that
this fake IRQ was being executed even if interrupt line failed to be allocated
by __setup_irq.Signed-off-by: Luis Henriques
LKML-Reference:
Signed-off-by: Thomas Gleixner
[ fixed bug pointed out by a warning reported by Stephen Rothwell ]
Cc: Stephen Rothwell
Signed-off-by: Ingo Molnar
14 Apr, 2009
1 commit
-
As discussed in the thread here:
http://marc.info/?l=linux-kernel&m=123964468521142&w=2
Eric W. Biederman observed:
> It looks like some additional bugs have slipped in since last I looked.
>
> set_irq_affinity does this:
> ifdef CONFIG_GENERIC_PENDING_IRQ
> if (desc->status & IRQ_MOVE_PCNTXT || desc->status & IRQ_DISABLED) {
> cpumask_copy(desc->affinity, cpumask);
> desc->chip->set_affinity(irq, cpumask);
> } else {
> desc->status |= IRQ_MOVE_PENDING;
> cpumask_copy(desc->pending_mask, cpumask);
> }
> #else
>
> That IRQ_DISABLED case is a software state and as such it has nothing to
> do with how safe it is to move an irq in process context.[...]
>
> The only reason we migrate MSIs in interrupt context today is that there
> wasn't infrastructure for support migration both in interrupt context
> and outside of it.Yes. The idea here was to force the MSI migration to happen in process
context. One of the patches in the series diddisable_irq(dev->irq);
irq_set_affinity(dev->irq, cpumask_of(dev->cpu));
enable_irq(dev->irq);with the above patch adding irq/manage code check for interrupt disabled
and moving the interrupt in process context.IIRC, there was no IRQ_MOVE_PCNTXT when we were developing this HPET
code and we ended up having this ugly hack. IRQ_MOVE_PCNTXT was there
when we eventually submitted the patch upstream. But, looks like I did a
blind rebasing instead of using IRQ_MOVE_PCNTXT in hpet MSI code.Below patch fixes this. i.e., revert commit 932775a4ab622e3c99bd59f14cc
and add PCNTXT to HPET MSI setup. Also removes copying of desc->affinity
in generic code as set_affinity routines are doing it internally.Reported-by: "Eric W. Biederman"
Signed-off-by: Venkatesh Pallipadi
Acked-by: "Eric W. Biederman"
Cc: "Li Shaohua"
Cc: Gary Hade
Cc: "lcm@us.ibm.com"
Cc: suresh.b.siddha@intel.com
LKML-Reference:
Signed-off-by: Ingo Molnar
06 Apr, 2009
1 commit
-
Conflicts:
include/linux/irq.h
kernel/irq/handle.c
31 Mar, 2009
1 commit
-
Introduce helper functions allowing us to prevent device drivers from
getting any interrupts (without disabling interrupts on the CPU)
during suspend (or hibernation) and to make them start to receive
interrupts again during the subsequent resume. These functions make it
possible to keep timer interrupts enabled while the "late" suspend and
"early" resume callbacks provided by device drivers are being
executed. In turn, this allows device drivers' "late" suspend and
"early" resume callbacks to sleep, execute ACPI callbacks etc.The functions introduced here will be used to rework the handling of
interrupts during suspend (hibernation) and resume. Namely,
interrupts will only be disabled on the CPU right before suspending
sysdevs, while device drivers will be prevented from receiving
interrupts, with the help of the new helper function, before their
"late" suspend callbacks run (and analogously during resume).Signed-off-by: Rafael J. Wysocki
Acked-by: Ingo Molnar
28 Mar, 2009
1 commit
-
Conflicts:
arch/parisc/kernel/irq.c
arch/x86/include/asm/fixmap_64.h
arch/x86/include/asm/setup.h
kernel/irq/handle.cSemantic merge:
arch/x86/include/asm/fixmap.hSigned-off-by: Ingo Molnar
24 Mar, 2009
3 commits
-
Delta patch to address the review comments.
- Implement warning when IRQ_WAKE_THREAD is requested and no
thread handler installed
- coding style fixesPointed-out-by: Christoph Hellwig
Signed-off-by: Thomas Gleixner -
Add support for threaded interrupt handlers:
A device driver can request that its main interrupt handler runs in a
thread. To achive this the device driver requests the interrupt with
request_threaded_irq() and provides additionally to the handler a
thread function. The handler function is called in hard interrupt
context and needs to check whether the interrupt originated from the
device. If the interrupt originated from the device then the handler
can either return IRQ_HANDLED or IRQ_WAKE_THREAD. IRQ_HANDLED is
returned when no further action is required. IRQ_WAKE_THREAD causes
the genirq code to invoke the threaded (main) handler. When
IRQ_WAKE_THREAD is returned handler must have disabled the interrupt
on the device level. This is mandatory for shared interrupt handlers,
but we need to do it as well for obscure x86 hardware where disabling
an interrupt on the IO_APIC level redirects the interrupt to the
legacy PIC interrupt lines.Signed-off-by: Thomas Gleixner
Reviewed-by: Ingo Molnar -
Conflicts:
arch/parisc/kernel/irq.c
kernel/irq/handle.cSigned-off-by: Thomas Gleixner
16 Mar, 2009
1 commit
13 Mar, 2009
2 commits
-
Impact: simplification
Signed-off-by: Thomas Gleixner
Reviewed-by: Peter Zijlstra -
Impact: cleanup
The code is only compiled if CONFIG_GENERIC_HARDIRQS=y so another
check for this define in the code is redundant. Remove it.Signed-off-by: Thomas Gleixner
12 Mar, 2009
3 commits
-
Export the setup_irq() and remove_irq() symbols.
I'd like to export these functions since I have timer
code that needs to use setup_irq() early on (too early
for request_irq()), and the same code can also be
compiled as a module.Signed-off-by: Magnus Damm
LKML-Reference:
[ changed to _GPL as these are special APIs deep inside the irq layer. ]
Signed-off-by: Ingo Molnar -
Modify remove_irq() to match setup_irq().
Signed-off-by: Magnus Damm
LKML-Reference:
Signed-off-by: Ingo Molnar -
Impact: add new API
This patch adds a remove_irq() function for releasing
interrupts requested with setup_irq().Without this patch we have no way of releasing such
interrupts since free_irq() today tries to kfree()
the irqaction passed with setup_irq().Signed-off-by: Magnus Damm
LKML-Reference:
Signed-off-by: Ingo Molnar
03 Mar, 2009
1 commit
18 Feb, 2009
2 commits
-
'p' stands for pointer - make it clear in setup_irq() and free_irq()
what kind of pointer it is.Cc: Linus Torvalds
Signed-off-by: Ingo Molnar -
Linus noticed that the 'pp' variable can be eliminated
altogether, and the loop can be cleaned up further.Cc: Linus Torvalds
Signed-off-by: Ingo Molnar
15 Feb, 2009
2 commits
-
Impact: cleanup
- separate out the loop from the actual freeing logic, this wins us
two indentation levels allowing a number of followup prettifications- turn the WARN_ON() into a more informative WARN().
- clean up the comments and the code flow some more
Cc: Linus Torvalds
Signed-off-by: Ingo Molnar -
- make printk message git-greppable
- fix a few style detailsSigned-off-by: Ingo Molnar
13 Feb, 2009
2 commits
-
request_irq() calls into proc code via __setup_irq() which is not safe
in an atomic context, so request_irq() can itself use the more
reliable GFP_KERNEL allocation for the action descriptor.Signed-off-by: Johannes Weiner
Signed-off-by: Ingo Molnar
09 Feb, 2009
1 commit
-
While being at it make every occurrence of 'do_irq_select_affinity'
have the same signature in terms of signedness of the first argument.Fix this sparse warning:
kernel/irq/manage.c:112:5: warning: symbol 'do_irq_select_affinity' was not declared. Should it be static?Also rename do_irq_select_affinity() to setup_affinity() - shorter name
and clearer naming.Signed-off-by: Hannes Eder
Acked-by: Matthew Wilcox
Signed-off-by: Ingo Molnar
31 Jan, 2009
1 commit
-
Conflicts:
kernel/irq/handle.c
29 Jan, 2009
1 commit
-
Conflicts:
kernel/irq/handle.c
28 Jan, 2009
2 commits
-
Move the initialization of irq_default_affinity to early_irq_init as
core_initcall is too late.irq_default_affinity can be used in init_IRQ and potentially timer and
SMP init as well. All of these happen before core_initcall. Moving
the initialization to early_irq_init ensures that it is initialized
before it is used.Signed-off-by: David Daney
Acked-by: Mike Travis
Signed-off-by: Linus Torvalds -
In interrupt.h these functions are declared only if
CONFIG_GENERIC_HARDIRQS is set. We should define them under identical
conditions.Signed-off-by: David Daney
Signed-off-by: Linus Torvalds
12 Jan, 2009
1 commit
-
Impact: reduce memory usage, use new cpumask API.
Replace the affinity and pending_masks with cpumask_var_t's. This adds
to the significant size reduction done with the SPARSE_IRQS changes.The added functions (init_alloc_desc_masks & init_copy_desc_masks) are
in the include file so they can be inlined (and optimized out for the
!CONFIG_CPUMASKS_OFFSTACK case.) [Naming chosen to be consistent with
the other init*irq functions, as well as the backwards arg declaration
of "from, to" instead of the more common "to, from" standard.]Includes a slight change to the declaration of struct irq_desc to embed
the pending_mask within ifdef(CONFIG_SMP) to be consistent with other
references, and some small changes to Xen.Tested: sparse/non-sparse/cpumask_offstack/non-cpumask_offstack/nonuma/nosmp on x86_64
Signed-off-by: Mike Travis
Cc: Chris Wright
Cc: Jeremy Fitzhardinge
Cc: KOSAKI Motohiro
Cc: Venkatesh Pallipadi
Cc: virtualization@lists.osdl.org
Cc: xen-devel@lists.xensource.com
Cc: Yinghai Lu