1. 16 Feb, 2012 11 commits
    • Grant Likely's avatar
      irq_domain/powerpc: constify irq_domain_ops · 9f70b8eb
      Grant Likely authored
      
      
      Make all the irq_domain_ops structures in powerpc 'static const'
      Signed-off-by: default avatarGrant Likely <grant.likely@secretlab.ca>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Milton Miller <miltonm@bga.com>
      Tested-by: default avatarOlof Johansson <olof@lixom.net>
      9f70b8eb
    • Grant Likely's avatar
      irq_domain/c6x: Use library of xlate functions · c1e572e6
      Grant Likely authored
      
      
      The c6x irq controllers don't need to define custom .xlate hooks
      Signed-off-by: default avatarGrant Likely <grant.likely@secretlab.ca>
      Cc: Rob Herring <rob.herring@calxeda.com>
      Cc: Mark Salter <msalter@redhat.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      c1e572e6
    • Grant Likely's avatar
      irq_domain/c6x: constify irq_domain structures · 15a25980
      Grant Likely authored
      
      Signed-off-by: default avatarGrant Likely <grant.likely@secretlab.ca>
      Cc: Mark Salter <msalter@redhat.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      15a25980
    • Mark Salter's avatar
      irq_domain/c6x: Convert c6x to use generic irq_domain support. · 0bd761e1
      Mark Salter authored
      
      
      The C6X IRQ support was copied almost verbatim from the PowerPC virtual IRQ
      code. The PowerPC code was used as the basis for generic irq_domain support,
      so this patch mostly copies what what done to arch/powerpc by Grant Likely
      in his irq_domain patch series.
      Signed-off-by: default avatarMark Salter <msalter@redhat.com>
      Signed-off-by: default avatarGrant Likely <grant.likely@secretlab.ca>
      Cc: Aurelien Jacquiot <a-jacquiot@ti.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      0bd761e1
    • Grant Likely's avatar
      irq_domain: constify irq_domain_ops · a18dc81b
      Grant Likely authored
      
      
      Make irq_domain_ops pointer a constant to make it safer for multiple
      instances to share the same ops pointer and change the irq_domain code
      so that it does not modify the ops.
      
      v4: Fix mismatched type reference in powerpc code
      Signed-off-by: default avatarGrant Likely <grant.likely@secretlab.ca>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Milton Miller <miltonm@bga.com>
      Tested-by: default avatarOlof Johansson <olof@lixom.net>
      a18dc81b
    • Grant Likely's avatar
      irq_domain: Remove irq_domain_add_simple() · 6b783f7c
      Grant Likely authored
      
      
      irq_domain_add_simple() was a stop-gap measure until complete irq_domain
      support was complete.  This patch removes the irq_domain_add_simple()
      interface.
      
      This patch also drops the explicit irq_domain initialization performed
      by the mach-versatile code because the versatile interrupt controller
      already has irq_domain support built into it.  This was a bug that was
      hanging around quietly for a while, but with the full irq_domain which
      actually verifies that irq_domain ranges are available it would cause
      the registration to fail and the system wouldn't boot.
      
      v4: Fixed number of irqs in mx5 gpio code
      v2: Updated to pass in host_data pointer on irq_domain allocation.
      Signed-off-by: default avatarGrant Likely <grant.likely@secretlab.ca>
      Cc: Rob Herring <rob.herring@calxeda.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Milton Miller <miltonm@bga.com>
      Cc: Russell King <linux@arm.linux.org.uk>
      Tested-by: default avatarOlof Johansson <olof@lixom.net>
      6b783f7c
    • Grant Likely's avatar
      irq_domain: Remove 'new' irq_domain in favour of the ppc one · 75294957
      Grant Likely authored
      
      
      This patch removes the simplistic implementation of irq_domains and enables
      the powerpc infrastructure for all irq_domain users.  The powerpc
      infrastructure includes support for complex mappings between Linux and
      hardware irq numbers, and can manage allocation of irq_descs.
      
      This patch also converts the few users of irq_domain_add()/irq_domain_del()
      to call irq_domain_add_legacy() instead.
      
      v3: Fix bug that set up too many irqs in translation range.
      v2: Fix removal of irq_alloc_descs() call in gic driver
      Signed-off-by: default avatarGrant Likely <grant.likely@secretlab.ca>
      Cc: Rob Herring <rob.herring@calxeda.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Milton Miller <miltonm@bga.com>
      Tested-by: default avatarOlof Johansson <olof@lixom.net>
      75294957
    • Grant Likely's avatar
      irq_domain: Add support for base irq and hwirq in legacy mappings · 1bc04f2c
      Grant Likely authored
      
      
      Add support for a legacy mapping where irq = (hwirq - first_hwirq + first_irq)
      so that a controller driver can allocate a fixed range of irq_descs and use
      a simple calculation to translate back and forth between linux and hw irq
      numbers.  This is needed to use an irq_domain with many of the ARM interrupt
      controller drivers that manage their own irq_desc allocations.  Ultimately
      the goal is to migrate those drivers to use the linear revmap, but doing it
      this way allows each driver to be converted separately which makes the
      migration path easier.
      
      This patch generalizes the IRQ_DOMAIN_MAP_LEGACY method to use
      (first_irq-first_hwirq) as the offset between hwirq and linux irq number,
      and adds checks to make sure that the hwirq number does not exceed range
      assigned to the controller.
      Signed-off-by: default avatarGrant Likely <grant.likely@secretlab.ca>
      Cc: Rob Herring <rob.herring@calxeda.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Milton Miller <miltonm@bga.com>
      Tested-by: default avatarOlof Johansson <olof@lixom.net>
      1bc04f2c
    • Grant Likely's avatar
      irq_domain: Replace irq_alloc_host() with revmap-specific initializers · a8db8cf0
      Grant Likely authored
      
      
      Each revmap type has different arguments for setting up the revmap.
      This patch splits up the generator functions so that each revmap type
      can do its own setup and the user doesn't need to keep track of how
      each revmap type handles the arguments.
      
      This patch also adds a host_data argument to the generators.  There are
      cases where the host_data pointer will be needed before the function returns.
      ie. the legacy map calls the .map callback for each irq before returning.
      
      v2: - Add void *host_data argument to irq_domain_add_*() functions
          - fixed failure to compile
          - Moved IRQ_DOMAIN_MAP_* defines into irqdomain.c
      Signed-off-by: default avatarGrant Likely <grant.likely@secretlab.ca>
      Cc: Rob Herring <rob.herring@calxeda.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Milton Miller <miltonm@bga.com>
      Tested-by: default avatarOlof Johansson <olof@lixom.net>
      a8db8cf0
    • Grant Likely's avatar
      irq_domain: Move irq_domain code from powerpc to kernel/irq · cc79ca69
      Grant Likely authored
      
      
      This patch only moves the code.  It doesn't make any changes, and the
      code is still only compiled for powerpc.  Follow-on patches will generalize
      the code for other architectures.
      Signed-off-by: default avatarGrant Likely <grant.likely@secretlab.ca>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Milton Miller <miltonm@bga.com>
      Tested-by: default avatarOlof Johansson <olof@lixom.net>
      cc79ca69
    • Grant Likely's avatar
      irq_domain/powerpc: Eliminate virq_is_host() · 6d9285b0
      Grant Likely authored
      
      
      There is only one user, and it is trivial to open-code.
      Signed-off-by: default avatarGrant Likely <grant.likely@secretlab.ca>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Milton Miller <miltonm@bga.com>
      Tested-by: default avatarOlof Johansson <olof@lixom.net>
      6d9285b0
  2. 14 Feb, 2012 4 commits
    • Grant Likely's avatar
      irq_domain/powerpc: eliminate irq_map; use irq_alloc_desc() instead · 4bbdd45a
      Grant Likely authored
      
      
      This patch drops the powerpc-specific irq_map table and replaces it with
      directly using the irq_alloc_desc()/irq_free_desc() interfaces for allocating
      and freeing irq_desc structures.
      
      This patch is a preparation step for generalizing the powerpc-specific virq
      infrastructure to become irq_domains.
      
      As part of this change, the irq_big_lock is changed to a mutex from a raw
      spinlock.  There is no longer any need to use a spin lock since the irq_desc
      allocation code is now responsible for the critical section of finding
      an unused range of irq numbers.
      
      The radix lookup table is also changed to store the irq_data pointer instead
      of the irq_map entry since the irq_map is removed.  This should end up being
      functionally equivalent since only allocated irq_descs are ever added to the
      radix tree.
      
      v5: - Really don't ever allocate virq 0.  The previous version could still
            do it if hint == 0
          - Respect irq_virq_count setting for NOMAP.  Some NOMAP domains cannot
            use virq values above irq_virq_count.
          - Use numa_node_id() when allocating irq_descs.  Ideally the API should
            obtain that value from the caller, but that touches a lot of call sites
            so will be deferred to a follow-on patch.
          - Fix irq_find_mapping() to include irq numbers lower than
            NUM_ISA_INTERRUPTS.  With the switch to irq_alloc_desc*(), the lowest
            possible allocated irq is now returned by arch_probe_nr_irqs().
      v4: - Fix incorrect access to irq_data structure in debugfs code
          - Don't ever allocate virq 0
      Signed-off-by: default avatarGrant Likely <grant.likely@secretlab.ca>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Milton Miller <miltonm@bga.com>
      Tested-by: default avatarOlof Johansson <olof@lixom.net>
      4bbdd45a
    • Grant Likely's avatar
      irq_domain/powerpc: Use common irq_domain structure instead of irq_host · bae1d8f1
      Grant Likely authored
      
      
      This patch drops the powerpc-specific irq_host structures and uses the common
      irq_domain strucutres defined in linux/irqdomain.h.  It also fixes all
      the users to use the new structure names.
      
      Renaming irq_host to irq_domain has been discussed for a long time, and this
      patch is a step in the process of generalizing the powerpc virq code to be
      usable by all architecture.
      
      An astute reader will notice that this patch actually removes the irq_host
      structure instead of renaming it.  This is because the irq_domain structure
      already exists in include/linux/irqdomain.h and has the needed data members.
      Signed-off-by: default avatarGrant Likely <grant.likely@secretlab.ca>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Milton Miller <miltonm@bga.com>
      Tested-by: default avatarOlof Johansson <olof@lixom.net>
      bae1d8f1
    • Grant Likely's avatar
      irq_domain: convert microblaze from irq_host to irq_domain · 644bd954
      Grant Likely authored
      
      
      Trivial change, microblaze doesn't use irq remapping yet.
      Signed-off-by: default avatarGrant Likely <grant.likely@secretlab.ca>
      Cc: Michal Simek <monstr@monstr.eu>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      644bd954
    • Grant Likely's avatar
      irq_domain: Make irq_domain structure match powerpc's irq_host · 7bb69bad
      Grant Likely authored
      
      
      Part of the series to unify the irq remapping mechanisms in the
      kernel.  A follow up patch will copy the powerpc implementation into
      kernel/irq/irqdomain.c, which will be a lot easier if the structures
      are identical.
      
      Where they differ, I've chose to use the powerpc names since there is
      a lot more code using those names.
      Signed-off-by: default avatarGrant Likely <grant.likely@secretlab.ca>
      Cc: Rob Herring <rob.herring@calxeda.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Milton Miller <miltonm@bga.com>
      Tested-by: default avatarOlof Johansson <olof@lixom.net>
      7bb69bad
  3. 13 Feb, 2012 13 commits
    • Linus Torvalds's avatar
      i387: make irq_fpu_usable() tests more robust · 5b1cbac3
      Linus Torvalds authored
      
      
      Some code - especially the crypto layer - wants to use the x86
      FP/MMX/AVX register set in what may be interrupt (typically softirq)
      context.
      
      That *can* be ok, but the tests for when it was ok were somewhat
      suspect.  We cannot touch the thread-specific status bits either, so
      we'd better check that we're not going to try to save FP state or
      anything like that.
      
      Now, it may be that the TS bit is always cleared *before* we set the
      USEDFPU bit (and only set when we had already cleared the USEDFP
      before), so the TS bit test may actually have been sufficient, but it
      certainly was not obviously so.
      
      So this explicitly verifies that we will not touch the TS_USEDFPU bit,
      and adds a few related sanity-checks.  Because it seems that somehow
      AES-NI is corrupting user FP state.  The cause is not clear, and this
      patch doesn't fix it, but while debugging it I really wanted the code to
      be more obviously correct and robust.
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      5b1cbac3
    • Linus Torvalds's avatar
      i387: math_state_restore() isn't called from asm · be98c2cd
      Linus Torvalds authored
      
      
      It was marked asmlinkage for some really old and stale legacy reasons.
      Fix that and the equally stale comment.
      
      Noticed when debugging the irq_fpu_usable() bugs.
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      be98c2cd
    • Russell King's avatar
      ARM: omap: resolve nebulous 'Error setting wl12xx data' · 70d669de
      Russell King authored
      
      
      It's useful to print the error code when a called function fails so a
      diagnosis of why it failed is possible.  In this case, it fails because
      we try to register some data for the wl12xx driver, but as the driver
      is not configured, a stub function is used which simply returns -ENOSYS.
      
      Let's do the simple thing for -rc and print the error code.
      
      Also, the return code from platform_register_device() at each of these
      sites was not being checked.  Add some checking, and again print the
      error code.
      
      This should be fixed properly for the next merge window so we don't
      issue error messages merely because a driver is not configured.
      Acked-by: default avatarTony Lindgren <tony@atomide.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      70d669de
    • Russell King's avatar
      ARM: omap: fix wrapped error messages in omap_hwmod.c · 4f8a428d
      Russell King authored
      
      
      While trying to debug my OMAP platforms, they emitted this message:
      
      omap_hwmod: %s: enabled state can only be entered from initialized, idle, or disabled state
      
      The following backtrace said it was from a function called '_enable',
      which didn't provide much clue.  Grepping didn't find it either.
      
      The message is wrapped, so unwrap the message so grep can find it.  Do
      the same for three other messages in this file.
      Acked-by: default avatarPaul Walmsley <paul@pwsan.com>
      Acked-by: default avatarTony Lindgren <tony@atomide.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      4f8a428d
    • Russell King's avatar
      ARM: omap: fix section mismatch warnings in mux.c caused by hsmmc.c · 8930b4e3
      Russell King authored
      
      
      The previous commit causes new section mismatch warnings:
      
      WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdb30): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_gpio()
      The function omap_init_hsmmc() references
      the function __init omap_mux_init_gpio().
      This is often because omap_init_hsmmc lacks a __init
      annotation or the annotation of omap_mux_init_gpio is wrong.
      
      WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdb4c): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_gpio()
      The function omap_init_hsmmc() references
      the function __init omap_mux_init_gpio().
      This is often because omap_init_hsmmc lacks a __init
      annotation or the annotation of omap_mux_init_gpio is wrong.
      
      WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdb60): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal()
      The function omap_init_hsmmc() references
      the function __init omap_mux_init_signal().
      This is often because omap_init_hsmmc lacks a __init
      annotation or the annotation of omap_mux_init_signal is wrong.
      
      WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdb6c): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal()
      The function omap_init_hsmmc() references
      the function __init omap_mux_init_signal().
      This is often because omap_init_hsmmc lacks a __init
      annotation or the annotation of omap_mux_init_signal is wrong.
      
      WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdb78): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal()
      The function omap_init_hsmmc() references
      the function __init omap_mux_init_signal().
      This is often because omap_init_hsmmc lacks a __init
      annotation or the annotation of omap_mux_init_signal is wrong.
      
      WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdb90): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal()
      The function omap_init_hsmmc() references
      the function __init omap_mux_init_signal().
      This is often because omap_init_hsmmc lacks a __init
      annotation or the annotation of omap_mux_init_signal is wrong.
      
      WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdb9c): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal()
      The function omap_init_hsmmc() references
      the function __init omap_mux_init_signal().
      This is often because omap_init_hsmmc lacks a __init
      annotation or the annotation of omap_mux_init_signal is wrong.
      
      WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdba8): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal()
      The function omap_init_hsmmc() references
      the function __init omap_mux_init_signal().
      This is often because omap_init_hsmmc lacks a __init
      annotation or the annotation of omap_mux_init_signal is wrong.
      
      WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdbc0): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal()
      The function omap_init_hsmmc() references
      the function __init omap_mux_init_signal().
      This is often because omap_init_hsmmc lacks a __init
      annotation or the annotation of omap_mux_init_signal is wrong.
      
      WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdbcc): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal()
      The function omap_init_hsmmc() references
      the function __init omap_mux_init_signal().
      This is often because omap_init_hsmmc lacks a __init
      annotation or the annotation of omap_mux_init_signal is wrong.
      
      WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdbd8): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal()
      The function omap_init_hsmmc() references
      the function __init omap_mux_init_signal().
      This is often because omap_init_hsmmc lacks a __init
      annotation or the annotation of omap_mux_init_signal is wrong.
      
      WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdbf8): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal()
      The function omap_init_hsmmc() references
      the function __init omap_mux_init_signal().
      This is often because omap_init_hsmmc lacks a __init
      annotation or the annotation of omap_mux_init_signal is wrong.
      
      WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdc04): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal()
      The function omap_init_hsmmc() references
      the function __init omap_mux_init_signal().
      This is often because omap_init_hsmmc lacks a __init
      annotation or the annotation of omap_mux_init_signal is wrong.
      
      WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdc10): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal()
      The function omap_init_hsmmc() references
      the function __init omap_mux_init_signal().
      This is often because omap_init_hsmmc lacks a __init
      annotation or the annotation of omap_mux_init_signal is wrong.
      
      WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdc28): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal()
      The function omap_init_hsmmc() references
      the function __init omap_mux_init_signal().
      This is often because omap_init_hsmmc lacks a __init
      annotation or the annotation of omap_mux_init_signal is wrong.
      
      WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdc34): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal()
      The function omap_init_hsmmc() references
      the function __init omap_mux_init_signal().
      This is often because omap_init_hsmmc lacks a __init
      annotation or the annotation of omap_mux_init_signal is wrong.
      
      WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdc40): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal()
      The function omap_init_hsmmc() references
      the function __init omap_mux_init_signal().
      This is often because omap_init_hsmmc lacks a __init
      annotation or the annotation of omap_mux_init_signal is wrong.
      
      WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdc58): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal()
      The function omap_init_hsmmc() references
      the function __init omap_mux_init_signal().
      This is often because omap_init_hsmmc lacks a __init
      annotation or the annotation of omap_mux_init_signal is wrong.
      
      WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdc64): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal()
      The function omap_init_hsmmc() references
      the function __init omap_mux_init_signal().
      This is often because omap_init_hsmmc lacks a __init
      annotation or the annotation of omap_mux_init_signal is wrong.
      
      WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdc70): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal()
      The function omap_init_hsmmc() references
      the function __init omap_mux_init_signal().
      This is often because omap_init_hsmmc lacks a __init
      annotation or the annotation of omap_mux_init_signal is wrong.
      
      WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdc7c): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal()
      The function omap_init_hsmmc() references
      the function __init omap_mux_init_signal().
      This is often because omap_init_hsmmc lacks a __init
      annotation or the annotation of omap_mux_init_signal is wrong.
      
      Again, as for omap2_hsmmc_init(), these functions are callable at
      runtime via the gpio-twl4030.c driver, and so these can't be marked
      __init.
      Acked-by: default avatarTony Lindgren <tony@atomide.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      8930b4e3
    • Russell King's avatar
      ARM: omap: fix section mismatch warning for sdp3430_twl_gpio_setup() · a98f77bb
      Russell King authored
      
      
      WARNING: arch/arm/mach-omap2/built-in.o(.text+0xd0f0): Section mismatch in reference from the function sdp3430_twl_gpio_setup() to the function .init.text:omap2_hsmmc_init()
      The function sdp3430_twl_gpio_setup() references
      the function __init omap2_hsmmc_init().
      This is often because sdp3430_twl_gpio_setup lacks a __init
      annotation or the annotation of omap2_hsmmc_init is wrong.
      
      sdp3430_twl_gpio_setup() is called via platform data from the
      gpio-twl4030 module, which can be inserted and removed at runtime.
      This makes sdp3430_twl_gpio_setup() callable at runtime, and prevents
      it being marked with an __init annotation.
      
      As it calls omap2_hsmmc_init() unconditionally, the only resolution to
      this warning is to remove the __init markings from omap2_hsmmc_init()
      and its called functions.  This addresses the functions in hsmmc.c.
      Acked-by: default avatarTony Lindgren <tony@atomide.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      a98f77bb
    • Russell King's avatar
      ARM: omap: fix section mismatch error for omap_4430sdp_display_init() · e3958fe0
      Russell King authored
      
      
      WARNING: arch/arm/mach-omap2/built-in.o(.text+0xb798): Section mismatch in reference from the function omap_4430sdp_display_init() to the function .init.text:omap_display_init()
      The function omap_4430sdp_display_init() references
      the function __init omap_display_init().
      This is often because omap_4430sdp_display_init lacks a __init
      annotation or the annotation of omap_display_init is wrong.
      
      Fix this by adding __init to omap_4430sdp_display_init().
      Acked-by: default avatarTony Lindgren <tony@atomide.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      e3958fe0
    • Russell King's avatar
      ARM: omap: fix section mismatch warning for omap_secondary_startup() · 45176f4c
      Russell King authored
      
      
      WARNING: vmlinux.o(.text+0x1c664): Section mismatch in reference from the function omap_secondary_startup() to the function .cpuinit.text:secondary_startup()
      The function omap_secondary_startup() references
      the function __cpuinit secondary_startup().
      This is often because omap_secondary_startup lacks a __cpuinit
      annotation or the annotation of secondary_startup is wrong.
      
      Unfortunately, fixing this causes a new warning which is harder to
      solve:
      
      WARNING: arch/arm/mach-omap2/built-in.o(.text+0x5328): Section mismatch in reference from the function omap4_hotplug_cpu() to the function .cpuinit.text:omap_secondary_startup()
      The function omap4_hotplug_cpu() references
      the function __cpuinit omap_secondary_startup().
      This is often because omap4_hotplug_cpu lacks a __cpuinit
      annotation or the annotation of omap_secondary_startup is wrong.
      
      because omap4_hotplug_cpu() is used by power management code as well,
      which may not end up using omap_secondary_startup().
      Acked-by: default avatarTony Lindgren <tony@atomide.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      45176f4c
    • Russell King's avatar
      ARM: omap: preemptively fix section mismatch in omap4_sdp4430_wifi_mux_init() · d5de63f5
      Russell King authored
      
      
      Found by review.
      
      omap4_sdp4430_wifi_mux_init() is called by an __init marked function,
      and only calls omap_mux_init_gpio() and omap_mux_init_signal() which
      are both also an __init marked functions.
      
      The only reason this doesn't issue a warning is because the compiler
      inlines omap4_sdp4430_wifi_mux_init() into omap4_sdp4430_wifi_init().
      
      So, lets add the __init annotation to ensure this remains safe should
      the compiler choose not to inline.
      Acked-by: default avatarTony Lindgren <tony@atomide.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      d5de63f5
    • Russell King's avatar
      ARM: omap: fix section mismatch warning in mux.c · 27d8d3bf
      Russell King authored
      
      
      WARNING: arch/arm/mach-omap2/built-in.o(.text+0x15a4): Section mismatch in reference from the function omap_mux_init_signals() to the function .init.text:omap_mux_init_signal()
      The function omap_mux_init_signals() references
      the function __init omap_mux_init_signal().
      This is often because omap_mux_init_signals lacks a __init
      annotation or the annotation of omap_mux_init_signal is wrong.
      Acked-by: default avatarTony Lindgren <tony@atomide.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      27d8d3bf
    • Russell King's avatar
      ARM: omap: fix uninformative vc/i2c configuration error message · 0bf68f53
      Russell King authored
      
      
      On my OMAP4 platform, I'm getting this error message repeated several
      times at boot:
      
      omap_vc_i2c_init: I2C config for all channels must match.
      omap_vc_i2c_init: I2C config for all channels must match.
      
      This doesn't help identify what the problem is.  Fix this message to
      be more informative:
      
      omap_vc_i2c_init: I2C config for vdd_iva does not match other channels (0).
      omap_vc_i2c_init: I2C config for vdd_mpu does not match other channels (0).
      
      This allows us to identify which voltage domains have a problem, and
      what the I2C configuration state (a boolean, i2c_high_speed) setting
      being used actually is.
      
      From this we find that omap4_core_pmic has i2c_high_speed false, but
      omap4_iva_pmic and omap4_mpu_pmic both have it set true.
      Acked-by: default avatarTony Lindgren <tony@atomide.com>
      Acked-by: default avatarKevin Hilman <khilman@ti.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      0bf68f53
    • Russell King's avatar
      ARM: omap: fix vc.c PMIC error message · 2d5b4790
      Russell King authored
      
      
      While testing on my OMAP3430 platform, this error message was emitted:
      
      omap_vc_init_channel: PMIC info requried to configure vc forvdd_core not populated.Hence cannot initialize vc
      
      Trying to find this message was difficult because it was wrapped across
      several lines.  It also mis-spells "required", doesn't read very well,
      and has spaces lacking.  Let's replace it with a more concise:
      
      omap_vc_init_channel: No PMIC info for vdd_core
      
      While we're here, fix a simple spelling error in a comment.
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      2d5b4790
    • Russell King's avatar
      ARM: omap: fix prm44xx.c OMAP44XX_IRQ_PRCM build error · e6fa35aa
      Russell King authored
      
      
      When CONFIG_OF is disabled, the compile fails with:
      
      arch/arm/mach-omap2/prm44xx.c:41: error: 'OMAP44XX_IRQ_PRCM' undeclared here (not in a function)
      Acked-by: default avatarTony Lindgren <tony@atomide.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      e6fa35aa
  4. 09 Feb, 2012 5 commits
    • Paul Walmsley's avatar
      tty: serial: OMAP: block idle while the UART is transferring data in PIO mode · be4b0281
      Paul Walmsley authored
      
      
      Prevent OMAP UARTs from going idle while they are still transferring
      data in PIO mode.  This works around an oversight in the OMAP UART
      hardware present in OMAP34xx and earlier: an idle UART won't send a
      wakeup when the TX FIFO threshold is reached.  This causes long delays
      during data transmission when the MPU powerdomain enters a low-power
      mode.  The MPU interrupt controller is not able to respond to
      interrupts when it's in a low-power state, so the TX buffer is not
      refilled until another wakeup event occurs.
      
      This fix changes the erratum i291 DMA idle workaround.  Rather than
      toggling between force-idle and no-idle, it will toggle between
      smart-idle and no-idle.  The important part of the workaround is the
      no-idle part, so this shouldn't result in any change in behavior.
      
      This fix should work on all OMAP UARTs.  Future patches intended for
      the 3.4 merge window will make this workaround conditional on a
      "feature" flag, and will use the OMAP36xx+ TX event wakeup support.
      
      Thanks to Kevin Hilman <khilman@ti.com> for mentioning the erratum i291
      workaround, which led to the development of this approach.
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      Cc: Alan Cox <alan@linux.intel.com>
      Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
      Acked-by: default avatarGovindraj.R <govindraj.raja@ti.com>
      Reviewed-by: default avatarKevin Hilman <khilman@ti.com>
      Tested-by: default avatarKevin Hilman <khilman@ti.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      be4b0281
    • Russell King's avatar
      ARM: omap: fix oops in arch/arm/mach-omap2/vp.c when pmic is not found · d980e0f8
      Russell King authored
      
      
      When the PMIC is not found, voltdm->pmic will be NULL.  vp.c's
      initialization function tries to dereferences this, which causes an
      oops:
      
      Unable to handle kernel NULL pointer dereference at virtual address 00000000
      pgd = c0004000
      [00000000] *pgd=00000000
      Internal error: Oops: 5 [#1] PREEMPT
      Modules linked in:
      CPU: 0    Not tainted  (3.3.0-rc2+ #204)
      PC is at omap_vp_init+0x5c/0x15c
      LR is at omap_vp_init+0x58/0x15c
      pc : [<c03db880>]    lr : [<c03db87c>]    psr: 60000013
      sp : c181ff30  ip : c181ff68  fp : c181ff64
      r10: c0407808  r9 : c040786c  r8 : c0407814
      r7 : c0026868  r6 : c00264fc  r5 : c040ad6c  r4 : 00000000
      r3 : 00000040  r2 : 000032c8  r1 : 0000fa00  r0 : 000032c8
      Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
      Control: 10c5387d  Table: 80004019  DAC: 00000015
      Process swapper (pid: 1, stack limit = 0xc181e2e8)
      Stack: (0xc181ff30 to 0xc1820000)
      ff20:                                     c0381d00 c02e9c6d c0383582 c040786c
      ff40: c040ad6c c00264fc c0026868 c0407814 00000000 c03d9de4 c181ff8c c181ff68
      ff60: c03db448 c03db830 c02e982c c03fdfb8 c03fe004 c0039988 00000013 00000000
      ff80: c181ff9c c181ff90 c03d9df8 c03db390 c181ffdc c181ffa0 c0008798 c03d9df0
      ffa0: c181ffc4 c181ffb0 c0055a44 c0187050 c0039988 c03fdfb8 c03fe004 c0039988
      ffc0: 00000013 00000000 00000000 00000000 c181fff4 c181ffe0 c03d1284 c0008708
      ffe0: 00000000 c03d1208 00000000 c181fff8 c0039988 c03d1214 1077ce40 01f7ee08
      Backtrace:
      [<c03db824>] (omap_vp_init+0x0/0x15c) from [<c03db448>] (omap_voltage_late_init+0xc4/0xfc)
      [<c03db384>] (omap_voltage_late_init+0x0/0xfc) from [<c03d9df8>] (omap2_common_pm_late_init+0x14/0x54)
       r8:00000000 r7:00000013 r6:c0039988 r5:c03fe004 r4:c03fdfb8
      [<c03d9de4>] (omap2_common_pm_late_init+0x0/0x54) from [<c0008798>] (do_one_initcall+0x9c/0x164)
      [<c00086fc>] (do_one_initcall+0x0/0x164) from [<c03d1284>] (kernel_init+0x7c/0x120)
      [<c03d1208>] (kernel_init+0x0/0x120) from [<c0039988>] (do_exit+0x0/0x2cc)
       r5:c03d1208 r4:00000000
      Code: e5ca300b e5900034 ebf69027 e5994024 (e5941000)
      ---[ end trace aed617dddaf32c3d ]---
      Kernel panic - not syncing: Attempted to kill init!
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      d980e0f8
    • Stephen Boyd's avatar
      ARM: 7322/1: Print BUG instead of undefined instruction on BUG_ON() · bdf800c4
      Stephen Boyd authored
      
      
      The ARM kernel uses undefined instructions to implement
      BUG/BUG_ON(). This leads to problems where people don't read one
      line above the Oops message and see the "kernel BUG at ..."
      message and so they wrongly assume the kernel has hit an
      undefined instruction.
      
      Instead of printing:
      
       Internal error: Oops - undefined instruction: 0 [#1] PREEMPT SMP
      
      print
      
       Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
      
      This should prevent people from thinking the BUG_ON was an
      undefined instruction when it was actually intentional.
      Signed-off-by: default avatarStephen Boyd <sboyd@codeaurora.org>
      Acked-by: Simon Glass's avatarSimon Glass <sjg@chromium.org>
      Tested-by: Simon Glass's avatarSimon Glass <sjg@chromium.org>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      bdf800c4
    • Stephen Boyd's avatar
      ARM: 7321/1: cache-v7: Disable preemption when reading CCSIDR · b46c0f74
      Stephen Boyd authored
      
      
      armv7's flush_cache_all() flushes caches via set/way. To
      determine the cache attributes (line size, number of sets,
      etc.) the assembly first writes the CSSELR register to select a
      cache level and then reads the CCSIDR register. The CSSELR register
      is banked per-cpu and is used to determine which cache level CCSIDR
      reads. If the task is migrated between when the CSSELR is written and
      the CCSIDR is read the CCSIDR value may be for an unexpected cache
      level (for example L1 instead of L2) and incorrect cache flushing
      could occur.
      
      Disable interrupts across the write and read so that the correct
      cache attributes are read and used for the cache flushing
      routine. We disable interrupts instead of disabling preemption
      because the critical section is only 3 instructions and we want
      to call v7_dcache_flush_all from __v7_setup which doesn't have a
      full kernel stack with a struct thread_info.
      
      This fixes a problem we see in scm_call() when flush_cache_all()
      is called from preemptible context and sometimes the L2 cache is
      not properly flushed out.
      Signed-off-by: default avatarStephen Boyd <sboyd@codeaurora.org>
      Acked-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Reviewed-by: default avatarNicolas Pitre <nico@linaro.org>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      b46c0f74
    • Marc Zyngier's avatar
      ARM: 7320/1: Fix proc_info table alignment · b8b9987f
      Marc Zyngier authored
      
      
      With an admittedly exotic choice of configuration options
      (CC_OPTIMIZE_FOR_SIZE, THUMB2, some other size-minimizing ones)
      and compiler, the proc_info table can end up being misaligned,
      and the kernel being unbootable (Error: unrecognized/unsupported
      processor variant).
      
      Forcing the alignement to 4 bytes in the linker script fixes the
      issue.
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      b8b9987f
  5. 07 Feb, 2012 1 commit
    • Stephane Eranian's avatar
      perf: Fix double start/stop in x86_pmu_start() · f39d47ff
      Stephane Eranian authored
      The following patch fixes a bug introduced by the following
      commit:
      
              e050e3f0 ("perf: Fix broken interrupt rate throttling")
      
      The patch caused the following warning to pop up depending on
      the sampling frequency adjustments:
      
        ------------[ cut here ]------------
        WARNING: at arch/x86/kernel/cpu/perf_event.c:995 x86_pmu_start+0x79/0xd4()
      
      It was caused by the following call sequence:
      
      perf_adjust_freq_unthr_context.part() {
           stop()
           if (delta > 0) {
                perf_adjust_period() {
                    if (period > 8*...) {
                        stop()
                        ...
                        start()
                    }
                }
            }
            start()
      }
      
      Which caused a double start and a double stop, thus triggering
      the assert in x86_pmu_start().
      
      The patch fixes the problem by avoiding the double calls. We
      pass a new argument to perf_adjust_period() to indicate whether
      or not the event is already stopped. We can't just remove the
      start/stop from that function because it's called from
      __perf_event_overflow where the event needs to be reloaded via a
      stop/start back-toback call.
      
      The patch reintroduces the assertion in x86_pmu_start() which
      was removed by commit:
      
      	84f2b9b2
      
       ("perf: Remove deprecated WARN_ON_ONCE()")
      
      In this second version, we've added calls to disable/enable PMU
      during unthrottling or frequency adjustment based on bug report
      of spurious NMI interrupts from Eric Dumazet.
      Reported-and-tested-by: default avatarEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: default avatarStephane Eranian <eranian@google.com>
      Acked-by: default avatarPeter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: markus@trippelsdorf.de
      Cc: paulus@samba.org
      Link: http://lkml.kernel.org/r/20120207133956.GA4932@quad
      
      
      [ Minor edits to the changelog and to the code ]
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      f39d47ff
  6. 04 Feb, 2012 4 commits
  7. 03 Feb, 2012 2 commits
    • Will Deacon's avatar
      ARM: 7314/1: kuser: consistently use usr_ret for returning from helpers · 5a97d0ae
      Will Deacon authored
      
      
      __kuser_cmpxchg64 has a return path using bx lr to get back to the caller.
      This is actually ok since the code in question is predicated on
      CONFIG_CPU_32v6K, but for the sake of consistency using the usr_ret
      macro is probably better.
      Acked-by: default avatarDave Martin <dave.martin@linaro.org>
      Acked-by: default avatarNicolas Pitre <nico@linaro.org>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      5a97d0ae
    • Stephane Eranian's avatar
      perf: Remove deprecated WARN_ON_ONCE() · 84f2b9b2
      Stephane Eranian authored
      With the new throttling/unthrottling code introduced with
      commit:
      
        e050e3f0
      
       ("perf: Fix broken interrupt rate throttling")
      
      we occasionally hit two WARN_ON_ONCE() checks in:
      
        - intel_pmu_pebs_enable()
        - intel_pmu_lbr_enable()
        - x86_pmu_start()
      
      The assertions are no longer problematic. There is a valid
      path where they can trigger but it is harmless.
      
      The assertion can be triggered with:
      
        $ perf record -e instructions:pp ....
      
      Leading to paths:
      
        intel_pmu_pebs_enable
        intel_pmu_enable_event
        x86_perf_event_set_period
        x86_pmu_start
        perf_adjust_freq_unthr_context
        perf_event_task_tick
        scheduler_tick
      
      And:
      
        intel_pmu_lbr_enable
        intel_pmu_enable_event
        x86_perf_event_set_period
        x86_pmu_start
        perf_adjust_freq_unthr_context.
        perf_event_task_tick
        scheduler_tick
      
      cpuc->enabled is always on because when we get to
      perf_adjust_freq_unthr_context() the PMU is not totally
      disabled. Furthermore when we need to adjust a period,
      we only stop the event we need to change and not the
      entire PMU. Thus, when we re-enable, cpuc->enabled is
      already set. Note that when we stop the event, both
      pebs and lbr are stopped if necessary (and possible).
      Signed-off-by: default avatarStephane Eranian <eranian@google.com>
      Cc: peterz@infradead.org
      Link: http://lkml.kernel.org/r/20120202110401.GA30911@quad
      
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      84f2b9b2