1. 14 11月, 2012 1 次提交
  2. 13 11月, 2012 13 次提交
    • J
      ARM: OMAP: Remove __omap_dm_timer_set_source function · b1538832
      Jon Hunter 提交于
      The __omap_dm_timer_set_source() function is only used by the system timer
      (clock-events and clock-source) code for OMAP2+ devices. Therefore, we can
      remove this code from the dmtimer driver and move it to the system timer
      code for OMAP2+ devices.
      
      The current __omap_dm_timer_set_source() function calls clk_disable() before
      calling clk_set_parent() and clk_enable() afterwards. We can avoid these calls
      to clk_disable/enable by moving the calls to omap_hwmod_setup_one() and
      omap_hwmod_enable() to after the call to clk_set_parent() in
      omap_dm_timer_init_one().
      
      The function omap_hwmod_setup_one() will enable the timers functional clock
      and therefore increment the use-count of the functional clock to 1.
      clk_set_parent() will fail if the use-count is not 0 when called. Hence, if
      omap_hwmod_setup_one() is called before clk_set_parent(), we will need to call
      clk_disable() before calling clk_set_parent() to decrement the use-count.
      Hence, avoid these extra calls to disable and enable the functional clock by
      moving the calls to omap_hwmod_setup_one() and omap_hwmod_enable() to after
      clk_set_parent().
      
      We can also remove the delay from the __omap_dm_timer_set_source() function
      because enabling the clock will now be handled via the HWMOD framework by
      calling omap_hwmod_setup_one(). Therefore, by moving the calls to
      omap_hwmod_setup_one() and omap_hwmod_enable() to after the call to
      clk_set_parent(), we can simply replace __omap_dm_timer_set_source() with
      clk_set_parent().
      
      It should be safe to move these hwmod calls to later in the
      omap_dm_timer_init_one() because other calls to the hwmod layer that occur
      before are just requesting resource information.
      
      Testing includes boot testing on OMAP2420 H4, OMAP3430 SDP and OMAP4430 Blaze
      with the following configurations:
      1. CONFIG_OMAP_32K_TIMER=y
      2. CONFIG_OMAP_32K_TIMER=y and boot parameter "clocksource=gp_timer"
      3. CONFIG_OMAP_32K_TIMER not set
      4. CONFIG_OMAP_32K_TIMER not set and boot parameter "clocksource=gp_timer"
      Signed-off-by: NJon Hunter <jon-hunter@ti.com>
      Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
      b1538832
    • J
      ARM: OMAP: Remove unnecessary call to clk_get() · d7aba554
      Jon Hunter 提交于
      Whenever we call the function omap_dm_timer_set_source() to set the clock
      source of a dmtimer we look-up the dmtimer functional clock source by
      calling clk_get(). This is not necessary because on requesting a dmtimer
      we look-up the functional clock source and store it in the omap_dm_timer
      structure. So instead of looking up the clock again used the clock handle
      that stored in the omap_dm_timer structure.
      Signed-off-by: NJon Hunter <jon-hunter@ti.com>
      Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
      d7aba554
    • J
      ARM: OMAP: Add dmtimer interrupt disable function · 4249d96c
      Jon Hunter 提交于
      The OMAP dmtimer driver does not currently have a function to disable the
      timer interrupts. For some timer instances the timer interrupt enable
      function can be used to disable the interrupts because the same interrupt
      enable register is used to disable interrupts. However, some timer instances
      have separate interrupt enable/disable registers and so this will not work.
      Therefore, add a dedicated function to disable interrupts.
      
      This change is required for OMAP4+ devices. For OMAP4, all timers apart from 1,
      2 and 10 need this function and for OMAP5 all timers need this function.
      Please note that the interrupt disable function has been written so that it
      can be used by all OMAP devices.
      Signed-off-by: NJon Hunter <jon-hunter@ti.com>
      Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
      4249d96c
    • J
      ARM: OMAP: Fix spurious interrupts when using timer match feature · 991ad16a
      Jon Hunter 提交于
      The OMAP DMTIMERs can generate an interrupt when the timer counter value
      matches the value stored in the timer's match register. When using this
      feature spurious interrupts were seen, because the compare logic is being
      enabled before the match value is loaded and according to the documentation
      the match value must be loaded before the compare logic is enable.
      
      The reset value for the timer counter and match registers is 0 and hence,
      by enabling the compare logic before the actual match value is loaded a
      spurious interrupt can be generated as the reset values match.
      Signed-off-by: NJon Hunter <jon-hunter@ti.com>
      Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
      991ad16a
    • J
      ARM: OMAP: Don't restore DMTIMER interrupt status register · 1eaff710
      Jon Hunter 提交于
      Restoring the timer interrupt status is not possible because writing a 1 to any
      bit in the register clears that bit if set and writing a 0 has no affect.
      Furthermore, if an interrupt is pending when someone attempts to disable a
      timer, the timer will fail to transition to the idle state and hence it's
      context will not be lost. Users should take care to service all interrupts
      before disabling the timer.
      Signed-off-by: NJon Hunter <jon-hunter@ti.com>
      Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
      1eaff710
    • J
      ARM: OMAP: Don't restore of DMTIMER TISTAT register · d3004bb4
      Jon Hunter 提交于
      The timer TISTAT register is a read-only register and therefore restoring the
      context is not needed. Furthermore, the context of TISTAT is never saved
      anywhere in the current code. The TISTAT register is read-only for all OMAP
      devices from OMAP1 to OMAP4. OMAP5 timers no longer have this register.
      Signed-off-by: NJon Hunter <jon-hunter@ti.com>
      Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
      d3004bb4
    • J
      ARM: OMAP: Fix dmtimer reset for timer1 · ffc957bd
      Jon Hunter 提交于
      In commit e32f7ec2 (ARM: OMAP: Fix 32 kHz timer and modify GP timer to use GPT1)
      a fix was added to prevent timer1 being reset in the function
      omap_dm_timer_reset() because timer1 was being used as the system timer for
      OMAP2 devices. Although timer1 is still used by most OMAP2+ devices as a system
      timer, the function omap_dm_timer_reset() is now only being called for OMAP1
      devices and OMAP1 does not use timer1 as a system timer. Therefore, remove the
      check in omap_dm_timer_reset() so that timer1 is reset for OMAP1 devices.
      Signed-off-by: NJon Hunter <jon-hunter@ti.com>
      Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
      ffc957bd
    • J
      ARM: OMAP2+: Don't use __omap_dm_timer_reset() · 10759e82
      Jon Hunter 提交于
      Currently OMAP2+ devices are using the function __omap_dm_timer_reset() to
      configure the clock-activity, idle, wakeup-enable and auto-idle fields in the
      timer OCP_CFG register. The name of the function is mis-leading because this
      function does not actually perform a reset of the timer.
      
      For OMAP2+ devices, HWMOD is responsible for reseting and configuring the
      timer OCP_CFG register. Therefore, do not use __omap_dm_timer_reset() for
      OMAP2+ devices and rely on HWMOD. Furthermore, some timer instances do not
      have the fields clock-activity, wakeup-enable and auto-idle and so this
      function could configure the OCP_CFG register incorrectly.
      
      Currently HWMOD is not configuring the clock-activity field in the OCP_CFG
      register for timers that have this field. Commit 0f0d0807 (ARM: OMAP: DMTimer:
      Use posted mode) configures the clock-activity field to keep the f-clk enabled
      so that the wake-up capability is enabled. Therefore, add the appropriate flags
      to the timer HWMOD structures to configure this field in the same way.
      
      For OMAP2/3 devices all dmtimers have the clock-activity field, where as for
      OMAP4 devices, only dmtimer 1, 2 and 10 have the clock-activity field.
      
      Verified on OMAP2420 H4, OMAP3430 Beagle and OMAP4430 Panda that HWMOD is
      configuring the dmtimer OCP_CFG register as expected for clock-events timer.
      Signed-off-by: NJon Hunter <jon-hunter@ti.com>
      Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
      10759e82
    • J
      ARM: OMAP2/3: Define HWMOD software reset status for DMTIMERs · f3a13e72
      Jon Hunter 提交于
      For OMAP2/3 devices, the HWMOD data does not define a software reset status
      field for the DMTIMERs. Therefore, when HWMOD performs a soft-reset of the
      DMTIMER we don't check and wait for the reset to complete. For OMAP2/3 devices,
      the software reset status for a DMTIMER can be read from bit 0 of the DMTIMER
      TISTAT register (referred to as the SYSS register in HWMOD). Add the
      appropriate HWMOD definitions so that HWMOD will check the software reset
      status when performing a software reset of the DMTIMER.
      Signed-off-by: NJon Hunter <jon-hunter@ti.com>
      Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
      f3a13e72
    • J
      ARM: OMAP3: Correct HWMOD DMTIMER SYSC register declarations · 725a8fe3
      Jon Hunter 提交于
      Currently, the OMAP3 HWMOD data defines two TIOCP_CFG register structures
      (referred to as the SYSC register in the HWMOD data) where timers 1, 2 and 10
      use one of the defintions and the other timers use the other definition. For
      OMAP3 devices the structure of the DMTIMER TIOCP_CFG register is the same for
      all 12 instances of the DMTIMER. Please note that this is a difference between
      OMAP3 and OMAP4 and could be the source of the confusion.
      
      For OMAP3 devices, the DMTIMER TIOCP_CFG register has the fields,
      clock-activity, emufree, idlemode, enwakeup, softreset and autoidle for all
      12 timers. Therefore, remove one of the SYSC register definitions for the
      DMTIMERs and ensure the appropriate register fields are defined for all
      DMTIMERs.
      Signed-off-by: NJon Hunter <jon-hunter@ti.com>
      Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
      725a8fe3
    • J
      ARM: OMAP: Fix timer posted mode support · 7b44cf2c
      Jon Hunter 提交于
      Currently the dmtimer posted mode is being enabled when the function
      omap_dm_timer_enable_posted() is called. This function is only being called
      for OMAP1 timers and OMAP2+ timers that are being used as system timers. Hence,
      for OMAP2+ timers that are NOT being used as a system timer, posted mode is
      not enabled but the "timer->posted" variable is still set (incorrectly) in
      the omap_dm_timer_prepare() function.
      
      This is a regression introduced by commit 3392cdd3 (ARM: OMAP: dmtimer:
      switch-over to platform device driver) which was before the
      omap_dm_timer_enable_posted() function was introduced. Although this is a
      regression from the original code it only impacts performance and so is not
      needed for stable.
      Signed-off-by: NJon Hunter <jon-hunter@ti.com>
      Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
      7b44cf2c
    • J
      ARM: OMAP3+: Implement timer workaround for errata i103 and i767 · bfd6d021
      Jon Hunter 提交于
      Errata Titles:
      i103: Delay needed to read some GP timer, WD timer and sync timer
            registers after wakeup (OMAP3/4)
      i767: Delay needed to read some GP timer registers after wakeup (OMAP5)
      
      Description (i103/i767):
      If a General Purpose Timer (GPTimer) is in posted mode
      (TSICR [2].POSTED=1), due to internal resynchronizations, values read in
      TCRR, TCAR1 and TCAR2 registers right after the timer interface clock
      (L4) goes from stopped to active may not return the expected values. The
      most common event leading to this situation occurs upon wake up from
      idle.
      
      GPTimer non-posted synchronization mode is not impacted by this
      limitation.
      
      Workarounds:
      1). Disable posted mode
      2). Use static dependency between timer clock domain and MPUSS clock
          domain
      3). Use no-idle mode when the timer is active
      
      Workarounds #2 and #3 are not pratical from a power standpoint and so
      workaround #1 has been implemented. Disabling posted mode adds some CPU
      overhead for configuring and reading the timers as the CPU has to wait
      for accesses to be re-synchronised within the timer. However, disabling
      posted mode guarantees correct operation.
      
      Please note that it is safe to use posted mode for timers if the counter
      (TCRR) and capture (TCARx) registers will never be read. An example of
      this is the clock-event system timer. This is used by the kernel to
      schedule events however, the timers counter is never read and capture
      registers are not used. Given that the kernel configures this timer
      often yet never reads the counter register it is safe to enable posted
      mode in this case. Hence, for the timer used for kernel clock-events,
      posted mode is enabled by overriding the errata for devices that are
      impacted by this defect.
      
      For drivers using the timers that do not read the counter or capture
      registers and wish to use posted mode, can override the errata and
      enable posted mode by making the following function calls.
      
      	__omap_dm_timer_override_errata(timer, OMAP_TIMER_ERRATA_I103_I767);
      	__omap_dm_timer_enable_posted(timer);
      
      Both dmtimers and watchdogs are impacted by this defect this patch only
      implements the workaround for the dmtimer. Currently the watchdog driver
      does not read the counter register and so no workaround is necessary.
      
      Posted mode will be disabled for all OMAP2+ devices (including AM33xx)
      using a GP timer as a clock-source timer to guarantee correct operation.
      This is not necessary for OMAP24xx devices but the default clock-source
      timer for OMAP24xx devices is the 32k-sync timer and not the GP timer
      and so should not have any impact. This should be re-visited for future
      devices if this errata is fixed.
      
      Confirmed with Vaibhav Hiremath that this bug also impacts AM33xx
      devices.
      Signed-off-by: NJon Hunter <jon-hunter@ti.com>
      Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
      bfd6d021
    • J
      ARM: OMAP: Add DMTIMER definitions for posted mode · 971d0254
      Jon Hunter 提交于
      For OMAP2+ devices, when using DMTIMERs for system timers (clock-events and
      clock-source) the posted mode configuration of the timers is used. To allow
      the compiler to optimise the functions for configuring and reading the system
      timers, the posted flag variable is hard-coded with the value 1. To make it
      clear that posted mode is being used add some definitions so that it is more
      readable.
      Signed-off-by: NJon Hunter <jon-hunter@ti.com>
      Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
      971d0254
  3. 10 11月, 2012 4 次提交
  4. 07 11月, 2012 7 次提交
  5. 06 11月, 2012 14 次提交
  6. 05 11月, 2012 1 次提交