1. 22 Oct, 2009 1 commit
  2. 14 Oct, 2009 4 commits
  3. 05 Oct, 2009 8 commits
    • Amit Kucheria's avatar
      Input: fix rx51 board keymap · acf442dc
      Amit Kucheria authored
      
      
      The original driver was written with the KEY() macro defined as (col,
      row) instead of (row, col) as defined by the matrix keypad
      infrastructure. So the keymap was defined accordingly. Since the
      driver that was merged upstream uses the matrix keypad infrastructure,
      modify the keymap accordingly.
      
      While we are at it, fix the comments in twl4030.h and define
      PERSISTENT_KEY as (r,c) instead of (c, r)
      
      Tested on a RX51 (N900) device.
      Signed-off-by: default avatarAmit Kucheria <amit.kucheria@verdurent.com>
      Acked-by: default avatarTony Lindgren <tony@atomide.com>
      Signed-off-by: default avatarDmitry Torokhov <dtor@mail.ru>
      acf442dc
    • Rajendra Nayak's avatar
      omap: Lock DPLL5 at boot · 7a66a39b
      Rajendra Nayak authored
      
      
      Lock DPLL5 at 120MHz at boot. The USBHOST 120MHz f-clock and
      USBTLL f-clock are the only users of this DPLL, and 120MHz is
      is the only recommended rate for these clocks.
      
      With this patch, the 60 MHz ULPI clock is generated correctly.
      
      Tested on an OMAP3430 SDP.
      Signed-off-by: default avatarRajendra Nayak <rnayak@ti.com>
      Signed-off-by: default avatarAnand Gadiyar <gadiyar@ti.com>
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      7a66a39b
    • Artem Bityutskiy's avatar
      OMAP3: PM: introduce a new powerdomain walk helper · ee894b18
      Artem Bityutskiy authored
      
      
      The 'pwrdm_for_each()' function walks powerdomains with a spinlock
      locked, so the the callbacks cannot do anything which may sleep.
      This patch introduces a 'pwrdm_for_each_nolock()' helper which does
      the same, but without the spinlock locked. This fixes the following
      lockdep warning:
      
      [    0.000000] WARNING: at kernel/lockdep.c:2460 lockdep_trace_alloc+0xac/0xec()
      [    0.000000] Modules linked in:
      (unwind_backtrace+0x0/0xdc) from [<c0045464>] (warn_slowpath_common+0x48/0x60)
      (warn_slowpath_common+0x48/0x60) from [<c0067dd4>] (lockdep_trace_alloc+0xac/0xec)
      (lockdep_trace_alloc+0xac/0xec) from [<c009da14>] (kmem_cache_alloc+0x1c/0xd0)
      (kmem_cache_alloc+0x1c/0xd0) from [<c00b21d8>] (d_alloc+0x1c/0x1a4)
      (d_alloc+0x1c/0x1a4) from [<c00a887c>] (__lookup_hash+0xd8/0x118)
      (__lookup_hash+0xd8/0x118) from [<c00a9f20>] (lookup_one_len+0x84/0x94)
      (lookup_one_len+0x84/0x94) from [<c010d12c>] (debugfs_create_file+0x8c/0x20c)
      (debugfs_create_file+0x8c/0x20c) from [<c010d320>] (debugfs_create_dir+0x1c/0x20)
      (debugfs_create_dir+0x1c/0x20) from [<c000e8cc>] (pwrdms_setup+0x60/0x90)
      (pwrdms_setup+0x60/0x90) from [<c002e010>] (pwrdm_for_each+0x30/0x80)
      (pwrdm_for_each+0x30/0x80) from [<c000e79c>] (pm_dbg_init+0x7c/0x14c)
      (pm_dbg_init+0x7c/0x14c) from [<c00232b4>] (do_one_initcall+0x5c/0x1b8)
      (do_one_initcall+0x5c/0x1b8) from [<c00083f8>] (kernel_init+0x90/0x10c)
      (kernel_init+0x90/0x10c) from [<c00242c4>] (kernel_thread_exit+0x0/0x8)
      Signed-off-by: default avatarArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
      Signed-off-by: default avatarKevin Hilman <khilman@deeprootsystems.com>
      ee894b18
    • Kevin Hilman's avatar
      OMAP3: PM: Enable GPIO module-level wakeups · eb350f74
      Kevin Hilman authored
      Currently, only GPIOs in the wakeup domain (GPIOs in bank 0) are
      enabled as wakups.  This patch also enables GPIOs in the PER
      powerdomain (banks 2-6) to be used as possible wakeup sources.
      
      In addition, this patch ensures that all GPIO wakeups can wakeup
      the MPU using the PM_MPUGRPSEL_<pwrdm> registers.
      
      NOTE: this doesn't enable the individual GPIOs as wakeups, this simply
      enables the per-bank wakeups at the powerdomain level.
      
      This problem was discovered by Mike Chan when preventing the CORE
      powerdomain from going into retention/off.  When CORE was allowed to
      hit retention, GPIO wakeups via IO pad were working fine, but when
      CORE remained on, GPIO module-level wakeups were not working properly.
      
      To test, prevent CORE from going inactive/retention/off, thus
      preventing the IO chain from being armed:
      
        # echo 3 > /debug/pm_debug/core_pwrdm/suspend
      
      This ensures that GPIO wakeups happen via module-level wakeups and
      not via IO pad.
      
      Tested on 3430SDP using the touchscreen GPIO (gpio 2, in WKUP)
      Tested on Zoom2 using the QUART interrup GPIO  (gpio 102, in PER)
      
      Also, c.f. OMAP PM wiki for troubleshooting GPIO wakeup issues:
      http://elinux.org/OMAP_Power_Management
      
      Reported-by: default avatarMike Chan <mikechan@google.com>
      Signed-off-by: default avatarKevin Hilman <khilman@deeprootsystems.com>
      eb350f74
    • Vikram Pandita's avatar
      OMAP3: PM: USBHOST: clear wakeup events on both hosts · 71a80775
      Vikram Pandita authored
      
      
      USBHOST module has 2 fclocks (for HOST1 and HOST2), only one iclock
      and only a single bit in the WKST register to indicate a wakeup event.
      
      Because of the single WKST bit, we cannot know whether a wakeup event
      was on HOST1 or HOST2, so enable both fclocks before clearing the
      wakeup event to ensure both hosts can properly clear the event.
      Signed-off-by: default avatarVikram Pandita <vikram.pandita@ti.com>
      Signed-off-by: default avatarKevin Hilman <khilman@deeprootsystems.com>
      71a80775
    • Paul Walmsley's avatar
      OMAP3: PM: PRCM interrupt: only handle selected PRCM interrupts · 8cb0ac99
      Paul Walmsley authored
      
      
      Clearing wakeup sources is now only done when the PRM indicates a
      wakeup source interrupt.  Since we don't handle any other types of
      PRCM interrupts right now, warn if we get any other type of PRCM
      interrupt.  Either code needs to be added to the PRCM interrupt
      handler to react to these, or these other interrupts should be masked
      off at init.
      
      Updated after Jon Hunter's PRCM IRQ rework by Kevin Hilman.
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      Signed-off-by: default avatarKevin Hilman <khilman@deeprootsystems.com>
      8cb0ac99
    • Paul Walmsley's avatar
      OMAP3: PM: PRCM interrupt: check MPUGRPSEL register · 5d805978
      Paul Walmsley authored
      
      
      PM_WKST register contents should be ANDed with the contents of the
      MPUGRPSEL registers.  Otherwise the MPU PRCM interrupt handler could
      wind up clearing wakeup events meant for the IVA PRCM interrupt
      handler. A future revision to this code should be to read a cached
      version of MPUGRPSEL from the powerdomain code, since PRM reads are
      relatively slow.
      
      Updated after Jon Hunter's PRCM IRQ change by Kevin Hilman
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      Signed-off-by: default avatarKevin Hilman <khilman@deeprootsystems.com>
      5d805978
    • Jon Hunter's avatar
      OMAP3: PM: Prevent hang in prcm_interrupt_handler · 77da2d91
      Jon Hunter authored
      
      
      There are two scenarios where a race condition could result in a hang
      in the prcm_interrupt handler. These are:
      
      1). Waiting for PRM_IRQSTATUS_MPU register to clear.
      Bit 0 of the PRM_IRQSTATUS_MPU register indicates that a wake-up event
      is pending for the MPU. This bit can only be cleared if the all the
      wake-up events latched in the various PM_WKST_x registers have been
      cleared. If a wake-up event occurred during the processing of the prcm
      interrupt handler, after the corresponding PM_WKST_x register was
      checked but before the PRM_IRQSTATUS_MPU was cleared, then the CPU
      would be stuck forever waiting for bit 0 in PRM_IRQSTATUS_MPU to be
      cleared.
      
      2). Waiting for the PM_WKST_x register to clear.
      Some power domains have more than one wake-up source. The PM_WKST_x
      registers indicate the source of a wake-up event and need to be cleared
      after a wake-up event occurs. When the PM_WKST_x registers are read and
      before they are cleared, it is possible that another wake-up event
      could occur causing another bit to be set in one of the PM_WKST_x
      registers. If this did occur after reading a PM_WKST_x register then
      the CPU would miss this event and get stuck forever in a loop waiting
      for that PM_WKST_x register to clear.
      
      This patch address the above race conditions that would result in a
      hang.
      Signed-off-by: default avatarJon Hunter <jon-hunter@ti.com>
      Reviewed-by: default avatarPaul Walmsley <paul@pwsan.com>
      Signed-off-by: default avatarKevin Hilman <khilman@deeprootsystems.com>
      77da2d91
  4. 28 Sep, 2009 1 commit
  5. 24 Sep, 2009 8 commits
  6. 23 Sep, 2009 7 commits
  7. 19 Sep, 2009 2 commits
  8. 17 Sep, 2009 1 commit
  9. 03 Sep, 2009 8 commits
    • Paul Walmsley's avatar
      OMAP: omap_hwmod: call omap_hwmod init at boot; create interconnects · 02bfc030
      Paul Walmsley authored
      
      
      Connect the omap_hwmod code to the kernel boot.  Create some basic
      interconnect and device structures for OMAP2/3 chips.
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      02bfc030
    • Paul Walmsley's avatar
      OMAP2/3/4: create omap_hwmod layer · 63c85238
      Paul Walmsley authored
      
      
      OMAP SoCs can be considered a collection of hardware IP blocks
      connected by various interconnects.  The bus topology and device
      integration data is somewhat more complex than platform_device can
      encode.  This patch creates code and structures to manage information
      about OMAP on-chip devices ("hardware modules") and their integration
      to the rest of the chip.  Hardware module data is intended to be
      generated dynamically from the TI hardware database for the OMAP4
      chips and beyond, easing Linux support for new chip variants.
      
      This code currently:
      
      - resets and configures all hardware modules upon startup, reducing bootloader
        dependencies;
      
      - provides hooks for Linux driver model code to enable, idle, and shutdown
        hardware modules (forthcoming patch);
      
      - waits for hardware modules to leave idle once their clocks
        are enabled and OCP_SYSCONFIG bits are set appropriately.
      
      - provides a means to pass arbitrary IP block configuration data (e.g.,
        FIFO size) to the device driver (via the dev_attr void pointer)
      
      In the future this code is intended to:
      
      - estimate interconnect bandwidth and latency characteristics to
        ensure constraints are satisfied during DVFS
      
      - provide *GRPSEL bit data to the powerdomain code
      
      - handle pin/ball muxing for devices
      
      - generate IO mapping information dynamically
      
      - supply device firewall configuration data
      
      - provide hardware module data to other on-chip coprocessor software
      
      - allow the removal of the "disable unused clocks" code in the OMAP2/3
        clock code
      
      This patch represents a collaborative effort involving many people from TI,
      Nokia, and the Linux-OMAP community.
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      Cc: Benoit Cousson <b-cousson@ti.com>
      Cc: Kevin Hilman <khilman@deeprootsystems.com>
      Cc: Tony Lindgren <tony@atomide.com>
      Cc: Rajendra Nayak <rnayak@ti.com>
      Cc: Vikram Pandita <vikram.pandita@ti.com>
      Cc: Sakari Poussa <sakari.poussa@nokia.com>
      Cc: Anand Sawant <sawant@ti.com>
      Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
      Cc: Eric Thomas <ethomas@ti.com>
      Cc: Richard Woodruff <r-woodruff2@ti.com>
      63c85238
    • Paul Walmsley's avatar
      OMAP2/3 board-*.c files: read bootloader configuration earlier · b3c6df3a
      Paul Walmsley authored
      
      
      Most board-*.c files read configuration data from the bootloader in
      their .init_machine() function.  This needs to happen earlier, at some
      point before omap2_init_common_hw() is called.  This is because a
      future patch will use the bootloader serial console port information
      to enable the UART clocks earlier, immediately after omap2_clk_init().
      This is in turn necessary since otherwise clock tree usecounts on
      clocks like dpll4_m2x2_ck will be bogus, which can cause the
      currently-active console UART clock to be disabled during boot.
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      b3c6df3a
    • Paul Walmsley's avatar
      OMAP2/3/4 PRCM: add module IDLEST wait code · 71348bca
      Paul Walmsley authored
      
      
      After a hardware module's clocks are enabled, Linux must wait for it
      to indicate readiness via its IDLEST bit before attempting to access
      the device, otherwise register accesses to the device may trigger an
      abort.  This has traditionally been implemented in the clock
      framework, but this is the wrong place for it: the clock framework
      doesn't know which module clocks must be enabled for a module to leave
      idle; and if a module is not in smart-idle mode, it may never leave
      idle at all.  This type of information is best stored in a
      per-hardware module data structure (coming in a following patch),
      rather than a per-clock data structure.  The new code will use these new
      functions to handle waiting for modules to enable.
      
      Once hardware module data is filled in for all of the on-chip devices,
      the clock framework code to handle IDLEST waiting can be removed.
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      71348bca
    • Paul Walmsley's avatar
      OMAP2/3 PM: create the OMAP PM interface and add a default OMAP PM no-op layer · c0407a96
      Paul Walmsley authored
      
      
      The interface provides device drivers, CPUFreq, and DSPBridge with a
      means of controlling OMAP power management parameters that are not yet
      supported by the Linux PM PMQoS interface.  Copious documentation is
      in the patch in Documentation/arm/OMAP/omap_pm and the interface
      header file, arch/arm/plat-omap/include/mach/omap-pm.h.
      
      Thanks to Rajendra Nayak <rnayak@ti.com> for adding CORE (VDD2) OPP
      support and moving the OPP table initialization earlier in the event
      that the clock code needs them.  Thanks to Tero Kristo
      <tero.kristo@nokia.com> for fixing the parameter check in
      omap_pm_set_min_bus_tput().  Jouni signed off on Tero's patch.
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      Signed-off-by: default avatarKevin Hilman <khilman@deeprootsystems.com>
      Signed-off-by: default avatarRajendra Nayak <rnayak@ti.com>
      Signed-off-by: default avatarTero Kristo <tero.kristo@nokia.com>
      Signed-off-by: default avatarJouni Högander <jouni.hogander@nokia.com>
      Cc: Tony Lindgren <tony@atomide.com>
      Cc: Igor Stoppa <igor.stoppa@nokia.com>
      Cc: Richard Woodruff <r-woodruff2@ti.com>
      Cc: Anand Sawant <sawant@ti.com>
      Cc: Sakari Poussa <sakari.poussa@nokia.com>
      Cc: Veeramanikandan Raju <veera@ti.com>
      Cc: Karthik Dasu <karthik-dp@ti.com>
      c0407a96
    • Paul Walmsley's avatar
      OMAP3 clock: remove superfluous calls to omap2_init_clk_clkdm · 08e3d5f2
      Paul Walmsley authored
      
      
      omap2_init_clk_clkdm() is called as part of the chip architecture-specific
      initialization code, so calling it again from the struct clk init pointer
      just wastes cycles.
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      08e3d5f2
    • Paul Walmsley's avatar
      OMAP clock: associate MPU clocks with the mpu_clkdm · 19f4d3a9
      Paul Walmsley authored
      
      
      All MPU-related clocks should be in the mpu_clkdm.  This is needed for the
      upcoming omap_hwmod patches, which needs to know the clockdomain that arm_fck
      is in.
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      19f4d3a9
    • Sanjeev Premi's avatar
      OMAP3 clock: Fixed processing of bootarg 'mpurate' · 11b66383
      Sanjeev Premi authored
      
      
      The argument 'mpurate' had no effect on the MPU
      frequency. This patch fixes the same.
      Signed-off-by: default avatarSanjeev Premi <premi@ti.com>
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      11b66383