1. 12 11月, 2009 16 次提交
  2. 23 10月, 2009 1 次提交
    • K
      omap3: PM: enable UART3 module wakeups · b427f92f
      Kevin Hilman 提交于
      UART3 is in the PER powerdomain.  If PER goes idle/inactive
      independently of CORE, for UART3 to wakeup it must have its wakeup
      enable bits setup in PM_WKEN_PER.  This patch enables these bits.
      
      The reason it works when PER and CORE work together is because when
      CORE goes inactive/retention, the IOPAD wakeups are enabled and
      trigger UART3 wakeup.
      
      Without this patch, when the UART inactivity timer fires for UART3,
      its clocks are disabled and it's unable to wakeup so will be unusable
      until PER is awoken by another source.
      
      Another way of testing is by keeping CORE on during suspend but
      allowing PER to hit retention
      
        # echo 3 > /debug/pm_debug/core_pwrdm/suspend
      
      then enter suspend
      
        # echo mem > /sys/power/state
      
      Without this patch, UART3 will be unable to wakeup the system.
      Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      b427f92f
  3. 21 10月, 2009 1 次提交
    • T
      omap: headers: Move remaining headers from include/mach to include/plat · ce491cf8
      Tony Lindgren 提交于
      Move the remaining headers under plat-omap/include/mach
      to plat-omap/include/plat. Also search and replace the
      files using these headers to include using the right path.
      
      This was done with:
      
      #!/bin/bash
      mach_dir_old="arch/arm/plat-omap/include/mach"
      plat_dir_new="arch/arm/plat-omap/include/plat"
      headers=$(cd $mach_dir_old && ls *.h)
      omap_dirs="arch/arm/*omap*/ \
      drivers/video/omap \
      sound/soc/omap"
      other_files="drivers/leds/leds-ams-delta.c \
      drivers/mfd/menelaus.c \
      drivers/mfd/twl4030-core.c \
      drivers/mtd/nand/ams-delta.c"
      
      for header in $headers; do
      	old="#include <mach\/$header"
      	new="#include <plat\/$header"
      	for dir in $omap_dirs; do
      		find $dir -type f -name \*.[chS] | \
      			xargs sed -i "s/$old/$new/"
      	done
      	find drivers/ -type f -name \*omap*.[chS] | \
      		xargs sed -i "s/$old/$new/"
      	for file in $other_files; do
      		sed -i "s/$old/$new/" $file
      	done
      done
      
      for header in $(ls $mach_dir_old/*.h); do
      	git mv $header $plat_dir_new/
      done
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      ce491cf8
  4. 06 10月, 2009 5 次提交
    • K
      OMAP3: PM: Enable GPIO module-level wakeups · eb350f74
      Kevin Hilman 提交于
      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_ManagementReported-by: NMike Chan <mikechan@google.com>
      Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>
      eb350f74
    • V
      OMAP3: PM: USBHOST: clear wakeup events on both hosts · 71a80775
      Vikram Pandita 提交于
      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: NVikram Pandita <vikram.pandita@ti.com>
      Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>
      71a80775
    • P
      OMAP3: PM: PRCM interrupt: only handle selected PRCM interrupts · 8cb0ac99
      Paul Walmsley 提交于
      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: NPaul Walmsley <paul@pwsan.com>
      Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>
      8cb0ac99
    • P
      OMAP3: PM: PRCM interrupt: check MPUGRPSEL register · 5d805978
      Paul Walmsley 提交于
      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: NPaul Walmsley <paul@pwsan.com>
      Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>
      5d805978
    • J
      OMAP3: PM: Prevent hang in prcm_interrupt_handler · 77da2d91
      Jon Hunter 提交于
      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: NJon Hunter <jon-hunter@ti.com>
      Reviewed-by: NPaul Walmsley <paul@pwsan.com>
      Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>
      77da2d91
  5. 03 9月, 2009 4 次提交
  6. 06 8月, 2009 7 次提交
  7. 29 5月, 2009 6 次提交