1. 16 Sep, 2015 1 commit
    • Thomas Gleixner's avatar
      genirq: Remove irq argument from irq flow handlers · bd0b9ac4
      Thomas Gleixner authored
      Most interrupt flow handlers do not use the irq argument. Those few
      which use it can retrieve the irq number from the irq descriptor.
      Remove the argument.
      Search and replace was done with coccinelle and some extra helper
      scripts around it. Thanks to Julia for her help!
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: Julia Lawall <Julia.Lawall@lip6.fr>
      Cc: Jiang Liu <jiang.liu@linux.intel.com>
  2. 28 Jul, 2015 1 commit
  3. 23 Jul, 2015 1 commit
  4. 31 Mar, 2015 6 commits
  5. 27 Mar, 2015 5 commits
  6. 25 Mar, 2015 4 commits
  7. 30 Jan, 2015 1 commit
  8. 17 Jan, 2015 1 commit
    • Marc Zyngier's avatar
      ARM: OMAP: Work around hardcoded interrupts · 0fb22a8f
      Marc Zyngier authored
      Commit 9a1091ef ("irqchip: gic: Support hierarchy irq domain")
      changed the GIC driver to use a non-legacy IRQ domain on DT
      platforms. This patch assumes that DT-driven systems are getting
      all of their interrupts from device tree.
      Turns out that OMAP has quite a few hidden gems, and still uses
      hardcoded interrupts despite having fairly complete DTs.
      This patch attempts to work around these by offering a translation
      method that can be called directly from the hwmod code, if present.
      The same hack is sprinkled over PRCM and TWL.
      It isn't pretty, but it seems to do the job without having to add
      more hacks to the interrupt controller code.
      Tested on OMAP4 (Panda-ES) and OMAP5 (UEVM5432).
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      Acked-by: default avatarNishanth Menon <nm@ti.com>
      [tony@atomide.com: updated to fix make randconfig issue]
      Signed-off-by: Tony Lindgren's avatarTony Lindgren <tony@atomide.com>
  9. 15 Jan, 2015 1 commit
  10. 27 Oct, 2014 5 commits
  11. 29 Sep, 2014 1 commit
    • Tero Kristo's avatar
      clk: ti: change clock init to use generic of_clk_init · c08ee14c
      Tero Kristo authored
      Previously, the TI clock driver initialized all the clocks hierarchically
      under each separate clock provider node. Now, each clock that requires
      IO access will instead check their parent node to find out which IO range
      to use.
      This patch allows the TI clock driver to use a few new features provided
      by the generic of_clk_init, and also allows registration of clock nodes
      outside the clock hierarchy (for example, any external clocks.)
      Signed-off-by: default avatarTero Kristo <t-kristo@ti.com>
      Cc: Mike Turquette <mturquette@linaro.org>
      Cc: Paul Walmsley <paul@pwsan.com>
      Cc: Tony Lindgren <tony@atomide.com>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: Peter Ujfalusi <peter.ujfalusi@ti.com>
      Cc: Jyri Sarha <jsarha@ti.com>
      Cc: Stefan Assmann <sassmann@kpanic.de>
      Acked-by: Tony Lindgren's avatarTony Lindgren <tony@atomide.com>
  12. 11 Sep, 2014 1 commit
  13. 02 Jul, 2014 1 commit
  14. 16 May, 2014 3 commits
  15. 17 Jan, 2014 1 commit
  16. 10 Oct, 2013 1 commit
  17. 21 Nov, 2012 1 commit
    • Rajendra Nayak's avatar
      ARM: OMAP2+: hwmod: Add support for per hwmod/module context lost count · e6d3a8b0
      Rajendra Nayak authored
      OMAP4 has module specific context lost registers which makes it now
      possible to have module level context loss count, instead of relying
      on the powerdomain level context count.
      Add 2 private hwmod api's to update/clear the hwmod/module specific
      context lost counters/register.
      Update the module specific context_lost_counter and clear the hardware
      bits just after enabling the module.
      omap_hwmod_get_context_loss_count() now returns the hwmod context loss
      count them on platforms where they exist (OMAP4), else fall back on
      the pwrdm level counters for older platforms.
      Signed-off-by: default avatarRajendra Nayak <rnayak@ti.com>
      [paul@pwsan.com: added function kerneldoc, fixed structure kerneldoc,
       rearranged structure to avoid memory waste, marked fns as OMAP4-specific,
       prevent fn entry on non-OMAP4 chips, reduced indentation, merged update
       and clear, merged patches]
      [t-kristo@ti.com: added support for arch specific hwmod ops, and changed
       the no context offset indicator to USHRT_MAX]
      Signed-off-by: default avatarTero Kristo <t-kristo@ti.com>
      [paul@pwsan.com: use NO_CONTEXT_LOSS_BIT flag rather than USHRT_MAX;
       convert unsigned context lost counter to int to match the return type;
       get rid of hwmod_ops in favor of the existing soc_ops mechanism;
       move context loss low-level accesses to the PRM code]
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
  18. 08 Nov, 2012 2 commits
  19. 31 Oct, 2012 1 commit
    • Tony Lindgren's avatar
      ARM: OMAP: Remove plat-omap/common.h · 5c2e8852
      Tony Lindgren authored
      Most of the prototypes in plat-omap/common.h are not
      common to omap1 and omap2+, they are local to omap2+
      and should not be in plat-omap/common.h.
      The only shared function prototype in this file is
      omap_init_clocksource_32k(), let's put that into
      Note that the new plat/counter-32k.h must not be
      included from drivers, that will break omap2+ build
      Signed-off-by: Tony Lindgren's avatarTony Lindgren <tony@atomide.com>
  20. 21 Oct, 2012 2 commits
    • Paul Walmsley's avatar
      ARM: OMAP2+: PRM: create PRM reset source API for the watchdog timer driver · 2bb2a5d3
      Paul Walmsley authored
      The OMAP watchdog timer driver needs to determine what caused the SoC
      to reset for its GETBOOTSTATUS ioctl.  So, define a set of standard
      reset sources across OMAP SoCs.  For OMAP2xxx, 3xxx, and 4xxx SoCs,
      define mappings from the SoC-specific reset source register bits to
      the standardized reset source IDs.  Create SoC-specific PRM functions
      that read the appropriate per-SoC register and use the mapping to
      return the standardized reset bits.  Register the SoC-specific PRM
      functions with the common PRM code via prm_register().  Create a
      function in the common PRM code, prm_read_reset_sources(), that
      calls the SoC-specific function, registered during boot.
      This patch does not yet handle some SoCs, such as AM33xx.  Those SoCs
      were not handled by the code this will replace.
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
    • Paul Walmsley's avatar
      ARM: OMAP2+: PRM: prepare for use of prm_ll_data function pointers · e24c3573
      Paul Walmsley authored
      There are several PRM operations which behave similarly across OMAP2+
      SoCs, but which have slight differences in their underlying
      implementations.  For example, to fetch the SoC's last reset sources,
      different registers are read across OMAP2xxx, 3xxx, and 44xx, and
      different bits are used on each SoC.  But the information returned is
      so similar that a single, common interface for drivers is useful.
      This patch creates the support code for this function pointer
      registration process.  No function pointers are included yet, but a
      subsequent patch will create one for the reset source API.
      To illustrate the end goal with the above reset source example, each
      per-SoC driver will use its own low-level implementation function --
      e.g., prm2xxx.c would contain omap2xxx_prm_read_reset_sources().  This
      function would read the appropriate register and remap the register
      bits to a standard set of reset source bits.  When the prm2xxx.c
      driver is loaded, it would register this function with the common PRM
      driver, prm.c.  prm.c would then export a common function,
      omap_prm_read_reset_sources().  Calling it would call through to the
      function pointer for the currently-registered SoC PRM driver.  This
      will allow other drivers to use PRM-provided data and operations
      without needing to know which SoC is currently in use.
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>