25 May, 2012

1 commit

  • Every interrupt which is an active wakeup source needs the ability to
    abort suspend if there is a pending irq. Right now only edge and level
    irqs can do that.

    |
    +---------+
    | INTC |
    +---------+
    | GPIO_IRQ
    +------------+
    | gpio-exp |
    +------------+
    | |
    GPIO0_IRQ GPIO1_IRQ

    In the above diagram, gpio expander has irq number GPIO_IRQ, it is
    connected with two sub GPIO pins, GPIO0 and GPIO1.

    During suspend, we set IRQF_NO_SUSPEND for GPIO_IRQ so that gpio
    expander driver can handle the sub irq GPIO0_IRQ and GPIO1_IRQ, and
    these two irqs themselves can further be handled by simple or nested
    irq in some drivers(typically gpio and mfd driver). If they are used
    as wakeup sources during suspend, we want them to be able to abort
    suspend too.

    Setting IRQS_PENDING flag in handle_nested_irq() and handle_simple_irq()
    when the irq is disabled allows check_wakeup_irqs() to identify such
    irqs as source for aborting suspend.

    Signed-off-by: Ning Jiang
    Cc: rjw@sisk.pl
    Link: http://lkml.kernel.org/r/CAH3Oq6T905%2B3fkF43NAMMFvJvq7dsk_so6T2vQ8ZJrA5xiU3YA@mail.gmail.com
    Signed-off-by: Thomas Gleixner

    Ning Jiang
     

22 May, 2012

1 commit

  • Pull core irq changes from Ingo Molnar:
    "A collection of small fixes."

    By Thomas Gleixner
    * 'irq-core-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
    hexagon: Remove select of not longer existing Kconfig switches
    arm: Select core options instead of redefining them
    genirq: Do not consider disabled wakeup irqs
    genirq: Allow check_wakeup_irqs to notice level-triggered interrupts
    genirq: Be more informative on irq type mismatch
    genirq: Reject bogus threaded irq requests
    genirq: Streamline irq_action

    Linus Torvalds
     

15 May, 2012

1 commit

  • Export handle_edge_irq() and irq_to_desc() to modules to allow them to
    do things such as

    __irq_set_handler_locked(...., handle_edge_irq);

    This fixes

    ERROR: "handle_edge_irq" [drivers/gpio/gpio-pch.ko] undefined!
    ERROR: "irq_to_desc" [drivers/gpio/gpio-pch.ko] undefined!

    when gpio-pch is being built as a module.

    This was introduced by commit df9541a60af0 ("gpio: pch9: Use proper flow
    type handlers") that added

    __irq_set_handler_locked(d->irq, handle_edge_irq);

    but handle_edge_irq() was not exported for modules (and inlined
    __irq_set_handler_locked() requires irq_to_desc() exported as well)

    Signed-off-by: Jiri Kosina
    Signed-off-by: Linus Torvalds

    Jiri Kosina
     

05 May, 2012

1 commit

  • Level triggered interrupts do not cause IRQS_PENDING to be set when
    they fire while "disabled" as the 'pending' state is always present in
    the level - they automatically refire where re-enabled.

    However the IRQS_PENDING flag is also used to abort a suspend cycle -
    if any 'is_wakeup_set' interrupt is PENDING, check_wakeup_irqs() will
    cause suspend to abort. Without IRQS_PENDING, suspend won't abort.

    Consequently, level-triggered interrupts that fire during the 'noirq'
    phase of suspend do not currently abort suspend.

    So set IRQS_PENDING even for level triggered interrupts, and make sure
    to clear the flag in check_irq_resend.

    [ Changelog by courtesy of Neil ]

    Tested-by: NeilBrown
    Signed-off-by: Thomas Gleixner

    Thomas Gleixner
     

21 Mar, 2012

1 commit

  • Pull perf events changes for v3.4 from Ingo Molnar:

    - New "hardware based branch profiling" feature both on the kernel and
    the tooling side, on CPUs that support it. (modern x86 Intel CPUs
    with the 'LBR' hardware feature currently.)

    This new feature is basically a sophisticated 'magnifying glass' for
    branch execution - something that is pretty difficult to extract from
    regular, function histogram centric profiles.

    The simplest mode is activated via 'perf record -b', and the result
    looks like this in perf report:

    $ perf record -b any_call,u -e cycles:u branchy

    $ perf report -b --sort=symbol
    52.34% [.] main [.] f1
    24.04% [.] f1 [.] f3
    23.60% [.] f1 [.] f2
    0.01% [k] _IO_new_file_xsputn [k] _IO_file_overflow
    0.01% [k] _IO_vfprintf_internal [k] _IO_new_file_xsputn
    0.01% [k] _IO_vfprintf_internal [k] strchrnul
    0.01% [k] __printf [k] _IO_vfprintf_internal
    0.01% [k] main [k] __printf

    This output shows from/to branch columns and shows the highest
    percentage (from,to) jump combinations - i.e. the most likely taken
    branches in the system. "branches" can also include function calls
    and any other synchronous and asynchronous transitions of the
    instruction pointer that are not 'next instruction' - such as system
    calls, traps, interrupts, etc.

    This feature comes with (hopefully intuitive) flat ascii and TUI
    support in perf report.

    - Various 'perf annotate' visual improvements for us assembly junkies.
    It will now recognize function calls in the TUI and by hitting enter
    you can follow the call (recursively) and back, amongst other
    improvements.

    - Multiple threads/processes recording support in perf record, perf
    stat, perf top - which is activated via a comma-list of PIDs:

    perf top -p 21483,21485
    perf stat -p 21483,21485 -ddd
    perf record -p 21483,21485

    - Support for per UID views, via the --uid paramter to perf top, perf
    report, etc. For example 'perf top --uid mingo' will only show the
    tasks that I am running, excluding other users, root, etc.

    - Jump label restructurings and improvements - this includes the
    factoring out of the (hopefully much clearer) include/linux/static_key.h
    generic facility:

    struct static_key key = STATIC_KEY_INIT_FALSE;

    ...

    if (static_key_false(&key))
    do unlikely code
    else
    do likely code

    ...
    static_key_slow_inc();
    ...
    static_key_slow_inc();
    ...

    The static_key_false() branch will be generated into the code with as
    little impact to the likely code path as possible. the
    static_key_slow_*() APIs flip the branch via live kernel code patching.

    This facility can now be used more widely within the kernel to
    micro-optimize hot branches whose likelihood matches the static-key
    usage and fast/slow cost patterns.

    - SW function tracer improvements: perf support and filtering support.

    - Various hardenings of the perf.data ABI, to make older perf.data's
    smoother on newer tool versions, to make new features integrate more
    smoothly, to support cross-endian recording/analyzing workflows
    better, etc.

    - Restructuring of the kprobes code, the splitting out of 'optprobes',
    and a corner case bugfix.

    - Allow the tracing of kernel console output (printk).

    - Improvements/fixes to user-space RDPMC support, allowing user-space
    self-profiling code to extract PMU counts without performing any
    system calls, while playing nice with the kernel side.

    - 'perf bench' improvements

    - ... and lots of internal restructurings, cleanups and fixes that made
    these features possible. And, as usual this list is incomplete as
    there were also lots of other improvements

    * 'perf-core-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (120 commits)
    perf report: Fix annotate double quit issue in branch view mode
    perf report: Remove duplicate annotate choice in branch view mode
    perf/x86: Prettify pmu config literals
    perf report: Enable TUI in branch view mode
    perf report: Auto-detect branch stack sampling mode
    perf record: Add HEADER_BRANCH_STACK tag
    perf record: Provide default branch stack sampling mode option
    perf tools: Make perf able to read files from older ABIs
    perf tools: Fix ABI compatibility bug in print_event_desc()
    perf tools: Enable reading of perf.data files from different ABI rev
    perf: Add ABI reference sizes
    perf report: Add support for taken branch sampling
    perf record: Add support for sampling taken branch
    perf tools: Add code to support PERF_SAMPLE_BRANCH_STACK
    x86/kprobes: Split out optprobe related code to kprobes-opt.c
    x86/kprobes: Fix a bug which can modify kernel code permanently
    x86/kprobes: Fix instruction recovery on optimized path
    perf: Add callback to flush branch_stack on context switch
    perf: Disable PERF_SAMPLE_BRANCH_* when not supported
    perf/x86: Add LBR software filter support for Intel CPUs
    ...

    Linus Torvalds
     

13 Mar, 2012

1 commit


06 Mar, 2012

1 commit

  • In 2008, commit 0c5d1eb77a8be ("genirq: record trigger type") modified the
    way set_irq_type() handles the 'no trigger' condition. However, this has
    an adverse effect on PCMCIA support on Intel StrongARM and probably PXA
    platforms.

    PCMCIA has several status signals on the socket which can trigger
    interrupts; some of these status signals depend on the card's mode
    (whether it is configured in memory or IO mode). For example, cards have
    a 'Ready/IRQ' signal: in memory mode, this provides an indication to
    PCMCIA that the card has finished its power up initialization. In IO
    mode, it provides the device interrupt signal. Other status signals
    switch between on-board battery status and loud speaker output.

    In classical PCMCIA implementations, where you have a specific socket
    controller, the controller provides a method to mask interrupts from the
    socket, and importantly ignore any state transitions on the pins which
    correspond with interrupts once masked. This masking prevents unwanted
    events caused by the removal and application of socket power being
    forwarded.

    However, on platforms where there is no socket controller, the PCMCIA
    status and interrupt signals are routed to standard edge-triggered GPIOs.
    These GPIOs can be configured to interrupt on rising edge, falling edge,
    or never. This is where the problems start.

    Edge triggered interrupts are required to record events while disabled via
    the usual methods of {free,request,disable,enable}_irq() to prevent
    problems with dropped interrupts (eg, the 8390 driver uses disable_irq()
    to defer the delivery of interrupts). As a result, these interfaces can
    not be used to implement the desired behaviour.

    The side effect of this is that if the 'Ready/IRQ' GPIO is disabled via
    disable_irq() on suspend, and enabled via enable_irq() after resume, we
    will record the state transitions caused by powering events as valid
    interrupts, and foward them to the card driver, which may attempt to
    access a card which is not powered up.

    This leads delays resume while drivers spin in their interrupt handlers,
    and complaints from drivers before they realize what's happened.

    Moreover, in the case of the 'Ready/IRQ' signal, this is requested and
    freed by the card driver itself; the PCMCIA core has no idea whether the
    interrupt is requested, and, therefore, whether a call to disable_irq()
    would be valid. (We tried this around 2.4.17 / 2.5.1 kernel era, and
    ended up throwing it out because of this problem.)

    Therefore, it was decided back in around 2002 to disable the edge
    triggering instead, resulting in all state transitions on the GPIO being
    ignored. That's what we actually need the hardware to do.

    The commit above changes this behaviour; it explicitly prevents the 'no
    trigger' state being selected.

    The reason that request_irq() does not accept the 'no trigger' state is
    for compatibility with existing drivers which do not provide their desired
    triggering configuration. The set_irq_type() function is 'new' and not
    used by non-trigger aware drivers.

    Therefore, revert this change, and restore previously working platforms
    back to their former state.

    Signed-off-by: Russell King
    Cc: linux@arm.linux.org.uk
    Cc: Ingo Molnar
    Cc: stable@vger.kernel.org
    Signed-off-by: Andrew Morton
    Signed-off-by: Thomas Gleixner

    Russell King
     

05 Mar, 2012

1 commit


15 Feb, 2012

2 commits

  • An interrupt might be pending when irq_startup() is called, but the
    startup code does not invoke the resend logic. In some cases this
    prevents the device from issuing another interrupt which renders the
    device non functional.

    Call the resend function in irq_startup() to keep things going.

    Reported-and-tested-by: Russell King
    Cc: stable@vger.kernel.org
    Signed-off-by: Thomas Gleixner

    Thomas Gleixner
     
  • When the primary handler of an interrupt which is marked IRQ_ONESHOT
    returns IRQ_HANDLED or IRQ_NONE, then the interrupt thread is not
    woken and the unmask logic of the interrupt line is never
    invoked. This keeps the interrupt masked forever.

    This was not noticed as most IRQ_ONESHOT users wake the thread
    unconditionally (usually because they cannot access the underlying
    device from hard interrupt context). Though this behaviour was nowhere
    documented and not necessarily intentional. Some drivers can avoid the
    thread wakeup in certain cases and run into the situation where the
    interrupt line s kept masked.

    Handle it gracefully.

    Reported-and-tested-by: Lothar Wassmann
    Cc: stable@vger.kernel.org
    Signed-off-by: Thomas Gleixner

    Thomas Gleixner
     

03 Feb, 2012

1 commit

  • The __raise_softirq_irqoff() contains a tracepoint. As tracepoints in headers
    can cause issues, and not to mention, bloats the kernel when they are
    in a static inline, it is best to move the function that contains the
    tracepoint out of the header and into softirq.c.

    Link: http://lkml.kernel.org/r/20120118120711.GB14863@elte.hu

    Suggested-by: Ingo Molnar
    Signed-off-by: Steven Rostedt

    Steven Rostedt
     

03 Oct, 2011

1 commit

  • The ARM GIC interrupt controller offers per CPU interrupts (PPIs),
    which are usually used to connect local timers to each core. Each CPU
    has its own private interface to the GIC, and only sees the PPIs that
    are directly connect to it.

    While these timers are separate devices and have a separate interrupt
    line to a core, they all use the same IRQ number.

    For these devices, request_irq() is not the right API as it assumes
    that an IRQ number is visible by a number of CPUs (through the
    affinity setting), but makes it very awkward to express that an IRQ
    number can be handled by all CPUs, and yet be a different interrupt
    line on each CPU, requiring a different dev_id cookie to be passed
    back to the handler.

    The *_percpu_irq() functions is designed to overcome these
    limitations, by providing a per-cpu dev_id vector:

    int request_percpu_irq(unsigned int irq, irq_handler_t handler,
    const char *devname, void __percpu *percpu_dev_id);
    void free_percpu_irq(unsigned int, void __percpu *);
    int setup_percpu_irq(unsigned int irq, struct irqaction *new);
    void remove_percpu_irq(unsigned int irq, struct irqaction *act);
    void enable_percpu_irq(unsigned int irq);
    void disable_percpu_irq(unsigned int irq);

    The API has a number of limitations:
    - no interrupt sharing
    - no threading
    - common handler across all the CPUs

    Once the interrupt is requested using setup_percpu_irq() or
    request_percpu_irq(), it must be enabled by each core that wishes its
    local interrupt to be delivered.

    Based on an initial patch by Thomas Gleixner.

    Signed-off-by: Marc Zyngier
    Cc: linux-arm-kernel@lists.infradead.org
    Link: http://lkml.kernel.org/r/1316793788-14500-2-git-send-email-marc.zyngier@arm.com
    Signed-off-by: Thomas Gleixner

    Marc Zyngier
     

12 Sep, 2011

1 commit

  • If an irq_chip provides .irq_shutdown(), but neither of .irq_disable() or
    .irq_mask(), free_irq() crashes when jumping to NULL.
    Fix this by only trying .irq_disable() and .irq_mask() if there's no
    .irq_shutdown() provided.

    This revives the symmetry with irq_startup(), which tries .irq_startup(),
    .irq_enable(), and irq_unmask(), and makes it consistent with the comment for
    irq_chip.irq_shutdown() in , which says:

    * @irq_shutdown: shut down the interrupt (defaults to ->disable if NULL)

    This is also how __free_irq() behaved before the big overhaul, cfr. e.g.
    3b56f0585fd4c02d047dc406668cb40159b2d340 ("genirq: Remove bogus conditional"),
    where the core interrupt code always overrode .irq_shutdown() to
    .irq_disable() if .irq_shutdown() was NULL.

    Signed-off-by: Geert Uytterhoeven
    Cc: linux-m68k@lists.linux-m68k.org
    Link: http://lkml.kernel.org/r/1315742394-16036-2-git-send-email-geert@linux-m68k.org
    Cc: stable@kernel.org
    Signed-off-by: Thomas Gleixner

    Geert Uytterhoeven
     

18 May, 2011

1 commit

  • Export handle_simple_irq, irq_modify_status, irq_alloc_descs,
    irq_free_descs and generic_handle_irq to allow their usage in
    modules. First user is IIO, which wants to be built modular, but needs
    to be able to create irq chips, allocate and configure interrupt
    descriptors and handle demultiplexing interrupts.

    [ tglx: Moved the uninlinig of generic_handle_irq to a separate patch ]

    Signed-off-by: Jonathan Cameron
    Link: http://lkml.kernel.org/r/%3C1305711544-505-1-git-send-email-jic23%40cam.ac.uk%3E
    Signed-off-by: Thomas Gleixner

    Jonathan Cameron
     

23 Apr, 2011

1 commit

  • This adds support for disabling threading on a per-IRQ basis via the IRQ
    status instead of the IRQ flow, which is necessary for interrupts that
    don't follow the natural IRQ flow channels, such as those that are
    virtually created.

    The new APIs added are simply:

    irq_set_thread()
    irq_set_nothread()

    which follow the rest of the IRQ status routines.

    Chained handlers also have IRQ_NOTHREAD set on them automatically, making
    the lack of threading explicit rather than implicit. Subsequently, the
    nothread flag can be viewed through the standard genirq debugging
    facilities.

    [ tglx: Fixed cleanup fallout ]

    Signed-off-by: Paul Mundt
    Link: http://lkml.kernel.org/r/%3C20110406210135.GF18426%40linux-sh.org%3E
    Signed-off-by: Thomas Gleixner

    Paul Mundt
     

31 Mar, 2011

1 commit


30 Mar, 2011

1 commit


29 Mar, 2011

2 commits


28 Mar, 2011

2 commits


27 Mar, 2011

4 commits


02 Mar, 2011

1 commit


22 Feb, 2011

1 commit


19 Feb, 2011

13 commits