1. 26 1月, 2013 1 次提交
  2. 04 1月, 2013 1 次提交
    • G
      ARM: drivers: remove __dev* attributes. · 351a102d
      Greg Kroah-Hartman 提交于
      CONFIG_HOTPLUG is going away as an option.  As a result, the __dev*
      markings need to be removed.
      
      This change removes the use of __devinit, __devexit_p, __devinitdata,
      and __devexit from these drivers.
      
      Based on patches originally written by Bill Pemberton, but redone by me
      in order to handle some of the coding style issues better, by hand.
      
      Cc: Bill Pemberton <wfp5p@virginia.edu>
      Cc: Russell King <linux@arm.linux.org.uk>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      351a102d
  3. 18 12月, 2012 1 次提交
  4. 17 11月, 2012 3 次提交
    • J
      ARM: OMAP: Add platform data header for DMTIMERs · 40fc3bb5
      Jon Hunter 提交于
      Move definition of dmtimer platform data structure in to its own header
      under <linux/platform_data>.
      Signed-off-by: NJon Hunter <jon-hunter@ti.com>
      40fc3bb5
    • J
      ARM: OMAP: Define omap_dm_timer_prepare function as static · b0cadb3c
      Jon Hunter 提交于
      The omap_dm_timer_prepare function is a local function only used in the
      dmtimer.c file. Therefore, make this a static function and remove its
      declaration from the dmtimer.h file.
      Signed-off-by: NJon Hunter <jon-hunter@ti.com>
      b0cadb3c
    • J
      ARM: OMAP: Clean-up dmtimer reset code · ae6672cb
      Jon Hunter 提交于
      Only OMAP1 devices use the omap_dm_timer_reset() and so require the
      omap_dm_timer_wait_for_reset() and __omap_dm_timer_reset() functions.
      Therefore combine these into a single function called omap_dm_timer_reset()
      and simplify the code.
      
      The omap_dm_timer_reset() function is now the only place that is using the
      omap_dm_timer structure member "sys_stat". Therefore, remove this member and
      just use the register offset definition to simplify and clean-up the code. The
      TISTAT register is only present on revision 1 timers and so check for this in
      the omap_dm_timer_reset() function.
      
      Please note that for OMAP1 devices, the TIOCP_CFG register does not have the
      clock-activity field and so when we reset the timer for an OMAP1 device we
      only need to configure the idle-mode field in the TIOCP_CFG register.
      Signed-off-by: NJon Hunter <jon-hunter@ti.com>
      ae6672cb
  5. 13 11月, 2012 9 次提交
    • 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: 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
  6. 03 11月, 2012 3 次提交
    • T
      ARM: OMAP: Remove unnecessary mach and plat includes · 7136f8d8
      Tony Lindgren 提交于
      Now mach/hardware.h is empty for omap2+ and can be
      removed except for plat-omap/dmtimer.c for omap1.
      
      Also the include of mach/irqs.h can now be removed
      for shared plat-omap/i2c.c as it's no longer needed.
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      7136f8d8
    • J
      ARM: OMAP: Add DT support for timer driver · 9725f445
      Jon Hunter 提交于
      In order to add device-tree support to the timer driver the following changes
      were made ...
      
      1. Allocate system timers (used for clock-events and clock-source) based upon
         timer properties rather than using an hard-coded timer instance ID. To allow
         this a new helper function called omap_dmtimer_find_by_property() has been
         added for finding a timer with the particular properties in the device-tree
         blob. Please note that this is an internal helper function for system timers
         only to find a timer in the device-tree blob. This cannot be used by device
         drivers, another API has been added for that (see below). Timers that are
         allocated for system timers are dynamically disabled at boot time by adding
         a status property with the value "disabled" to the timer's device-tree node.
      
         Please note that when allocating system timers we now pass a timer ID and
         timer property. The timer ID is only be used for allocating a timer when
         booting without device-tree. Once device-tree migration is complete, all
         the timer ID references will be removed.
      
      2. System timer resources (memory and interrupts) are directly obtained from
         the device-tree timer node when booting with device-tree, so that system
         timers are no longer reliant upon the OMAP HWMOD framework to provide these
         resources.
      
      3. If DT blob is present, then let device-tree create the timer devices
         dynamically.
      
      4. When device-tree is present the "id" field in the platform_device structure
         (pdev->id) is initialised to -1 and hence cannot be used to identify a timer
         instance. Due to this the following changes were made ...
         a). The API omap_dm_timer_request_specific() is not supported when using
             device-tree, because it uses the device ID to request a specific timer.
             This function will return an error if called when device-tree is present.
             Users of this API should use omap_dm_timer_request_by_cap() instead.
         b). When removing the DMTIMER driver, the timer "id" was used to identify the
             timer instance. The remove function has been modified to use the device
             name instead of the "id".
      
      5. When device-tree is present the platform_data structure will be NULL and so
         check for this.
      
      6. The OMAP timer device tree binding has the following optional parameters ...
         a). ti,timer-alwon  --> Timer is in an always-on power domain
         b). ti,timer-dsp    --> Timer can generate an interrupt to the on-chip DSP
         c). ti,timer-pwm    --> Timer can generate a PWM output
         d). ti,timer-secure --> Timer is reserved on a secure OMAP device
         Search for the above parameters and set the appropriate timer attribute
         flags.
      Signed-off-by: NJon Hunter <jon-hunter@ti.com>
      9725f445
    • J
      ARM: OMAP: Add function to request a timer by capability · 373fe0bd
      Jon Hunter 提交于
      Currently OMAP timers can be requested by requesting any available or by a
      numerical device ID. If a specific timer is required because it has a particular
      capability, such as can interrupt the on-chip DSP in addition to the ARM CPU,
      then the user needs to know the device ID of the timer with this feature.
      Therefore, add a new API called omap_dm_timer_request_by_cap() that allows
      drivers to request a timer by capability.
      Signed-off-by: NJon Hunter <jon-hunter@ti.com>
      373fe0bd
  7. 01 11月, 2012 1 次提交
    • T
      ARM: OMAP: Move omap-pm-noop.c local to mach-omap2 · 6e740f9a
      Tony Lindgren 提交于
      This code should be private to mach-omap2.
      
      The only use for it in for omap1 has been in dmtimer.c
      to check for context loss. However, omap1 does not
      lose context during idle, so the code is not needed.
      Further, omap1 timer has OMAP_TIMER_ALWON set, so omap1
      was not hitting omap_pm_get_dev_context_loss_count()
      test.
      
      Cc: Jon Hunter <jon-hunter@ti.com>
      Cc: Kevin Hilman <khilman@deeprootsystems.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      6e740f9a
  8. 19 10月, 2012 1 次提交
  9. 13 8月, 2012 1 次提交
  10. 08 8月, 2012 1 次提交
    • J
      ARM: OMAP2+: Fix dmtimer set source clock failure · 54f32a35
      Jon Hunter 提交于
      Calling the dmtimer function omap_dm_timer_set_source() fails if following a
      call to pm_runtime_put() to disable the timer. For example the following
      sequence would fail to set the parent clock ...
      
      	omap_dm_timer_stop(gptimer);
      	omap_dm_timer_set_source(gptimer, OMAP_TIMER_SRC_32_KHZ);
      
      The following error message would be seen ...
      
      omap_dm_timer_set_source: failed to set timer_32k_ck as parent
      
      The problem is that, by design, pm_runtime_put() simply decrements the usage
      count and returns before the timer has actually been disabled. Therefore,
      setting the parent clock failed because the timer was still active when the
      trying to set the parent clock. Setting a parent clock will fail if the clock
      you are setting the parent of has a non-zero usage count. To ensure that this
      does not fail use pm_runtime_put_sync() when disabling the timer.
      
      Note that this will not be seen on OMAP1 devices, because these devices do
      not use the clock framework for dmtimers.
      Signed-off-by: NJon Hunter <jon-hunter@ti.com>
      Acked-by: NKevin Hilman <khilman@ti.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      54f32a35
  11. 05 7月, 2012 1 次提交
  12. 14 6月, 2012 8 次提交
    • J
      ARM: OMAP2+: Simplify dmtimer clock aliases · c59b537d
      Jon Hunter 提交于
      The OMAP dmtimer driver allows you to dynamically configure the functional
      clock that drives the timer logic. The dmtimer driver uses the device name and
      a "con-id" string to search for the appropriate functional clock.
      
      Currently, we define a clock alias for each functional clock source each timer
      supports. Some functional clock sources are common to all of the timers on a
      device and so for these clock sources we can use a single alias with a unique
      con-id string.
      
      The possible functional clock sources for an OMAP device are a 32kHz clock,
      a system (MHz range) clock and (for OMAP2 only) an external clock. By defining
      a unique con-id name for each of these (timer_32k_ck, timer_sys_ck and
      timer_ext_ck) we can eliminate a lot of the clock aliases for timers. This
      reduces code, speeds-up searches and clock initialisation time.
      Signed-off-by: NJon Hunter <jon-hunter@ti.com>
      Acked-by: NPaul Walmsley <paul@pwsan.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      c59b537d
    • J
      ARM: OMAP2+: Move dmtimer clock set function to dmtimer driver · 2b2d3523
      Jon Hunter 提交于
      OMAP1 uses an architecture specific function for setting the dmtimer clock
      source, where as the OMAP2+ devices use the clock framework. Eventually OMAP1
      device should also use the clock framework and hence we should not any
      architecture specific functions.
      
      For now move the OMAP2+ function for configuring the clock source into the
      dmtimer driver. Therefore, we do no longer need to specify an architecture
      specific function for setting the clock source for OMAP2+ devices. This will
      simplify device tree migration of the dmtimers for OMAP2+ devices.
      
      From now on, only OMAP1 devices should specify an architecture specific
      function for setting the clock source via the platform data set_dmtimer_src()
      function pointer.
      Signed-off-by: NJon Hunter <jon-hunter@ti.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      2b2d3523
    • J
      ARM: OMAP1: Fix dmtimer support · bca45808
      Jon Hunter 提交于
      OMAP1 dmtimer support is currently broken. When a dmtimer is requested by the
      omap_dm_timer_request() function fails to allocate a dmtimer because the call
      to clk_get() inside omap_dm_timer_prepare fails. The clk_get() fails simply
      because the clock data for the OMAP1 dmtimers is not present.
      
      Ideally this should be fixed by moving OMAP1 dmtimers to use the clock
      framework. For now simply fix this by using the "TIMER_NEEDS_RESET" flag to
      identify an OMAP1 device and avoid calling clk_get(). Although this is not
      the ideal fix and should be corrected, this flag has already been use for the
      same purpose in omap_dm_timer_stop().
      Signed-off-by: NJon Hunter <jon-hunter@ti.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      bca45808
    • J
      ARM: OMAP: Add flag to indicate if a timer needs a manual reset · 6615975b
      Jon Hunter 提交于
      For OMAP1 devices, it is necessary to perform a manual reset of the timer.
      Currently, this is indicating by setting the "needs_manual_reset" variable in
      the platform data. Instead of using an extra variable to indicate this add a new
      timer capabilities flag to indicate this and remove the "needs_manual_reset"
      member from the platform data.
      Signed-off-by: NJon Hunter <jon-hunter@ti.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      6615975b
    • J
      ARM: OMAP: Remove timer function pointer for context loss counter · 0b30ec1c
      Jon Hunter 提交于
      For OMAP2+ devices, a function pointer that returns the number of times a timer
      power domain has lost context is passed to the dmtimer driver. This function
      pointer is only populated for OMAP2+ devices and it is pointing to a platform
      function. Given that this is a platform function, we can simplify the code by
      removing the function pointer and referencing the function directly. We can use
      the OMAP_TIMER_ALWON flag to determine if we need to call this function for
      OMAP1 and OMAP2+ devices.
      
      The benefit of this change is the we can remove the function pointer from the
      platform data and simplifies the dmtimer migration to device-tree.
      Signed-off-by: NJon Hunter <jon-hunter@ti.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      0b30ec1c
    • J
      ARM: OMAP: Remove loses_context variable from timer platform data · 1c2d076b
      Jon Hunter 提交于
      The platform data variable loses_context is used to determine if the timer may
      lose its logic state during power transitions and so needs to be restored. This
      information is also provided in the HWMOD device attributes for OMAP2+ devices
      via the OMAP_TIMER_ALWON flag. When this flag is set the timer will not lose
      context. So use the HWMOD device attributes to determine this.
      
      For OMAP1 devices, loses_context is never set and so set the OMAP_TIMER_ALWON
      flag for OMAP1 timers to ensure that code is equivalent.
      Signed-off-by: NJon Hunter <jon-hunter@ti.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      1c2d076b
    • J
      ARM: OMAP: Add DMTIMER capability variable to represent timer features · d1c1691b
      Jon Hunter 提交于
      Although the OMAP timers share a common hardware design, there are some
      differences between the timer instances in a given device. For example, a timer
      maybe in a power domain that can be powered-of, so can lose its logic state and
      need restoring where as another may be in power domain that is always be on.
      Another example, is a timer may support different clock sources to drive the
      timer. This information is passed to the dmtimer via the following platform data
      structure.
      
      struct dmtimer_platform_data {
      	int (*set_timer_src)(struct platform_device *pdev, int source);
      	int timer_ip_version;
      	u32 needs_manual_reset:1;
      	bool loses_context;
      	int (*get_context_loss_count)(struct device *dev);
      };
      
      The above structure uses multiple variables to represent the timer features.
      HWMOD also stores the timer capabilities using a bit-mask that represents the
      features supported. By using the same format for representing the timer
      features in the platform data as used by HWMOD, we can ...
      
      1. Use the flags defined in the plat/dmtimer.h to represent the features
         supported.
      2. For devices using HWMOD, we can retrieve the features supported from HWMOD.
      3. Eventually, simplify the platform data structure to be ...
      
      struct dmtimer_platform_data {
      	int (*set_timer_src)(struct platform_device *pdev, int source);
      	u32 timer_capability;
      }
      
      Another benefit from doing this, is that it will simplify the migration of the
      dmtimer driver to device-tree. For example, in the current OMAP2+ timer code the
      "loses_context" variable is configured at runtime by calling an architecture
      specific function. For device tree this creates a problem, because we would need
      to call the architecture specific function from within the dmtimer driver.
      However, such attributes do not need to be queried at runtime and we can look up
      the attributes via HWMOD or device-tree.
      
      This changes a new "capability" variable to the platform data and timer
      structure so we can start removing and simplifying the platform data structure.
      Signed-off-by: NJon Hunter <jon-hunter@ti.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      d1c1691b
    • J
      ARM: OMAP2+: Add dmtimer platform function to reserve systimers · b7b4ff76
      Jon Hunter 提交于
      During early boot, one or two dmtimers are reserved by the kernel as system
      timers (for clocksource and clockevents). These timers are marked as reserved
      and the dmtimer driver is notified which timers have been reserved via the
      platform data information.
      
      For OMAP2+ devices the timers reserved may vary depending on device and compile
      flags. Therefore, it is not easy to assume which timers we be reserved for the
      system timers. In order to migrate the dmtimer driver to support device-tree we
      need a way to pass the timers reserved for system timers to the dmtimer driver.
      Using the platform data structure will not work in the same way as it is
      currently used because the platform data structure will be stored statically in
      the dmtimer itself and the platform data will be selected via the device-tree
      match device function (of_match_device).
      
      There are a couple ways to workaround this. One option is to store the system
      timers reserved for the kernel in the device-tree and query them on boot.
      The downside of this approach is that it adds some delay to parse the DT blob
      to search for the system timers. Secondly, for OMAP3 devices we have a
      dependency on compile time flags and the device-tree would not be aware of that
      kernel compile flags and so we would need to address that.
      
      The second option is to add a function to the dmtimer code to reserved the
      system timers during boot and so the dmtimer knows exactly which timers are
      being used for system timers. This also allows us to remove the "reserved"
      member from the timer platform data. This seemed like the simpler approach and
      so was implemented here.
      Signed-off-by: NJon Hunter <jon-hunter@ti.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      b7b4ff76
  13. 11 5月, 2012 1 次提交
  14. 18 4月, 2012 1 次提交
    • P
      ARM: OMAP2+: clean up some cppcheck warnings · eeb3711b
      Paul Walmsley 提交于
      Resolve some warnings identified by cppcheck in arch/arm/mach-omap2:
      
          [arch/arm/mach-omap2/usb-tusb6010.c:129]: (style) Checking if unsigned variable 'tmp' is less than zero.
          [arch/arm/mach-omap2/prm_common.c:241]: (error) Possible null pointer dereference: irq_setup - otherwise it is redundant to check if irq_setup is null at line 247
          [arch/arm/mach-omap2/pm34xx.c:790]: (style) Variable 'per_clkdm' is assigned a value that is never used
          [arch/arm/mach-omap2/pm34xx.c:790]: (style) Variable 'core_clkdm' is assigned a value that is never used
          [arch/arm/mach-omap2/pm24xx.c:185]: (style) Variable 'only_idle' is assigned a value that is never used
          [arch/arm/mach-omap2/mux.c:254]: (error) Possible null pointer dereference: mux
          [arch/arm/mach-omap2/mux.c:258]: (error) Possible null pointer dereference: mux
          [arch/arm/mach-omap2/gpmc-onenand.c:178]: (style) Variable 'tick_ns' is assigned a value that is never used
          [arch/arm/mach-omap2/gpio.c:56]: (error) Possible null pointer dereference: pdata - otherwise it is redundant to check if pdata is null at line 57
          [arch/arm/mach-omap2/devices.c:45]: (style) Variable 'l' is assigned a value that is never used
          [arch/arm/mach-omap2/board-omap3evm.c:641] -> [arch/arm/mach-omap2/board-omap3evm.c:639]: (style) Found duplicate branches for if and else.
          [arch/arm/mach-omap2/am35xx-emac.c:95]: (style) Variable 'regval' is assigned a value that is never used
          [arch/arm/mach-omap2/devices.c:74]: (style) Variable 'l' is assigned a value that is never used
          [arch/arm/mach-omap2/pm34xx.c:277]: (style) Variable 'per_prev_state' is assigned a value that is never used
          [arch/arm/plat-omap/dmtimer.c:352]: (error) Possible null pointer dereference: timer - otherwise it is redundant to check if timer is null at line 354
          [arch/arm/plat-omap/omap_device.c:478]: (style) Variable 'c' is assigned a value that is never used
          [arch/arm/plat-omap/usb.c:42]: (style) Variable 'status' is assigned a value that is never used
          [arch/arm/mach-omap1/clock.c:197]: (style) Variable 'dpll1_rate' is assigned a value that is never used
          [arch/arm/mach-omap1/lcd_dma.c:60]: (style) struct or union member 'lcd_dma_info::size' is never used
          [arch/arm/mach-omap1/pm.c:572]: (style) Variable 'entry' is assigned a value that is never used
      
      Some of them are pretty good catches, such as gpio.c:56 and
      usb-tusb6010.c:129.
      
      Thanks to Jarkko Nikula for some comments on the sscanf() warnings.
      It seems that the kernel sscanf() ignores the field width anyway for the
      %d format, so those changes have been dropped from this second version.
      
      Thanks to Daniel Marjamäki <daniel.marjamaki@gmail.com> for pointing
      out that a variable was unnecessarily marked static in the
      board-omap3evm.c change.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Felipe Balbi <balbi@ti.com>
      Cc: Tony Lindgren <tony@atomide.com>
      Cc: Kevin Hilman <khilman@ti.com>
      Cc: Peter Ujfalusi <peter.ujfalusi@ti.com>
      Cc: Jarkko Nikula <jarkko.nikula@bitmer.com>
      Cc: Charulatha Varadarajan <charu@ti.com>
      Cc: Daniel Marjamäki <daniel.marjamaki@gmail.com>
      Cc: Tarun Kanti DebBarma <tarun.kanti@ti.com>
      Reviewed-by: Charulatha Varadarajan <charu@ti.com> # for gpio.c
      eeb3711b
  15. 06 3月, 2012 1 次提交
  16. 25 2月, 2012 1 次提交
  17. 05 11月, 2011 1 次提交
    • A
      ARM: OMAP: dmtimer: Include linux/module.h · 869dec15
      Axel Lin 提交于
      Include linux/module.h to fix below build error:
      
        CC      arch/arm/plat-omap/dmtimer.o
      arch/arm/plat-omap/dmtimer.c:184: warning: data definition has no type or storage class
      arch/arm/plat-omap/dmtimer.c:184: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL'
      arch/arm/plat-omap/dmtimer.c:184: warning: parameter names (without types) in function declaration
      arch/arm/plat-omap/dmtimer.c:215: warning: data definition has no type or storage class
      arch/arm/plat-omap/dmtimer.c:215: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL'
      arch/arm/plat-omap/dmtimer.c:215: warning: parameter names (without types) in function declaration
      arch/arm/plat-omap/dmtimer.c:228: warning: data definition has no type or storage class
      arch/arm/plat-omap/dmtimer.c:228: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL'
      arch/arm/plat-omap/dmtimer.c:228: warning: parameter names (without types) in function declaration
      arch/arm/plat-omap/dmtimer.c:234: warning: data definition has no type or storage class
      arch/arm/plat-omap/dmtimer.c:234: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL'
      arch/arm/plat-omap/dmtimer.c:234: warning: parameter names (without types) in function declaration
      arch/arm/plat-omap/dmtimer.c:240: warning: data definition has no type or storage class
      arch/arm/plat-omap/dmtimer.c:240: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL'
      arch/arm/plat-omap/dmtimer.c:240: warning: parameter names (without types) in function declaration
      arch/arm/plat-omap/dmtimer.c:248: warning: data definition has no type or storage class
      arch/arm/plat-omap/dmtimer.c:248: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL'
      arch/arm/plat-omap/dmtimer.c:248: warning: parameter names (without types) in function declaration
      arch/arm/plat-omap/dmtimer.c:294: warning: data definition has no type or storage class
      arch/arm/plat-omap/dmtimer.c:294: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL'
      arch/arm/plat-omap/dmtimer.c:294: warning: parameter names (without types) in function declaration
      arch/arm/plat-omap/dmtimer.c:302: warning: data definition has no type or storage class
      arch/arm/plat-omap/dmtimer.c:302: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL'
      arch/arm/plat-omap/dmtimer.c:302: warning: parameter names (without types) in function declaration
      arch/arm/plat-omap/dmtimer.c:316: warning: data definition has no type or storage class
      arch/arm/plat-omap/dmtimer.c:316: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL'
      arch/arm/plat-omap/dmtimer.c:316: warning: parameter names (without types) in function declaration
      arch/arm/plat-omap/dmtimer.c:344: warning: data definition has no type or storage class
      arch/arm/plat-omap/dmtimer.c:344: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL'
      arch/arm/plat-omap/dmtimer.c:344: warning: parameter names (without types) in function declaration
      arch/arm/plat-omap/dmtimer.c:361: warning: data definition has no type or storage class
      arch/arm/plat-omap/dmtimer.c:361: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL'
      arch/arm/plat-omap/dmtimer.c:361: warning: parameter names (without types) in function declaration
      arch/arm/plat-omap/dmtimer.c:380: warning: data definition has no type or storage class
      arch/arm/plat-omap/dmtimer.c:380: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL'
      arch/arm/plat-omap/dmtimer.c:380: warning: parameter names (without types) in function declaration
      arch/arm/plat-omap/dmtimer.c:406: warning: data definition has no type or storage class
      arch/arm/plat-omap/dmtimer.c:406: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL'
      arch/arm/plat-omap/dmtimer.c:406: warning: parameter names (without types) in function declaration
      arch/arm/plat-omap/dmtimer.c:443: warning: data definition has no type or storage class
      arch/arm/plat-omap/dmtimer.c:443: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL'
      arch/arm/plat-omap/dmtimer.c:443: warning: parameter names (without types) in function declaration
      arch/arm/plat-omap/dmtimer.c:468: warning: data definition has no type or storage class
      arch/arm/plat-omap/dmtimer.c:468: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL'
      arch/arm/plat-omap/dmtimer.c:468: warning: parameter names (without types) in function declaration
      arch/arm/plat-omap/dmtimer.c:494: warning: data definition has no type or storage class
      arch/arm/plat-omap/dmtimer.c:494: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL'
      arch/arm/plat-omap/dmtimer.c:494: warning: parameter names (without types) in function declaration
      arch/arm/plat-omap/dmtimer.c:517: warning: data definition has no type or storage class
      arch/arm/plat-omap/dmtimer.c:517: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL'
      arch/arm/plat-omap/dmtimer.c:517: warning: parameter names (without types) in function declaration
      arch/arm/plat-omap/dmtimer.c:534: warning: data definition has no type or storage class
      arch/arm/plat-omap/dmtimer.c:534: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL'
      arch/arm/plat-omap/dmtimer.c:534: warning: parameter names (without types) in function declaration
      arch/arm/plat-omap/dmtimer.c:549: warning: data definition has no type or storage class
      arch/arm/plat-omap/dmtimer.c:549: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL'
      arch/arm/plat-omap/dmtimer.c:549: warning: parameter names (without types) in function declaration
      arch/arm/plat-omap/dmtimer.c:561: warning: data definition has no type or storage class
      arch/arm/plat-omap/dmtimer.c:561: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL'
      arch/arm/plat-omap/dmtimer.c:561: warning: parameter names (without types) in function declaration
      arch/arm/plat-omap/dmtimer.c:572: warning: data definition has no type or storage class
      arch/arm/plat-omap/dmtimer.c:572: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL'
      arch/arm/plat-omap/dmtimer.c:572: warning: parameter names (without types) in function declaration
      arch/arm/plat-omap/dmtimer.c:587: warning: data definition has no type or storage class
      arch/arm/plat-omap/dmtimer.c:587: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL'
      arch/arm/plat-omap/dmtimer.c:587: warning: parameter names (without types) in function declaration
      arch/arm/plat-omap/dmtimer.c:604: warning: data definition has no type or storage class
      arch/arm/plat-omap/dmtimer.c:604: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL'
      arch/arm/plat-omap/dmtimer.c:604: warning: parameter names (without types) in function declaration
      arch/arm/plat-omap/dmtimer.c:746: error: expected declaration specifiers or '...' before string constant
      arch/arm/plat-omap/dmtimer.c:746: warning: data definition has no type or storage class
      arch/arm/plat-omap/dmtimer.c:746: warning: type defaults to 'int' in declaration of 'MODULE_DESCRIPTION'
      arch/arm/plat-omap/dmtimer.c:746: warning: function declaration isn't a prototype
      arch/arm/plat-omap/dmtimer.c:747: error: expected declaration specifiers or '...' before string constant
      arch/arm/plat-omap/dmtimer.c:747: warning: data definition has no type or storage class
      arch/arm/plat-omap/dmtimer.c:747: warning: type defaults to 'int' in declaration of 'MODULE_LICENSE'
      arch/arm/plat-omap/dmtimer.c:747: warning: function declaration isn't a prototype
      arch/arm/plat-omap/dmtimer.c:748: error: expected declaration specifiers or '...' before string constant
      arch/arm/plat-omap/dmtimer.c:748: warning: data definition has no type or storage class
      arch/arm/plat-omap/dmtimer.c:748: warning: type defaults to 'int' in declaration of 'MODULE_ALIAS'
      arch/arm/plat-omap/dmtimer.c:748: warning: function declaration isn't a prototype
      arch/arm/plat-omap/dmtimer.c:749: error: expected declaration specifiers or '...' before string constant
      arch/arm/plat-omap/dmtimer.c:749: warning: data definition has no type or storage class
      arch/arm/plat-omap/dmtimer.c:749: warning: type defaults to 'int' in declaration of 'MODULE_AUTHOR'
      arch/arm/plat-omap/dmtimer.c:749: warning: function declaration isn't a prototype
      make[1]: *** [arch/arm/plat-omap/dmtimer.o] Error 1
      make: *** [arch/arm/plat-omap] Error 2
      Signed-off-by: NAxel Lin <axel.lin@gmail.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      869dec15
  18. 02 10月, 2011 1 次提交
  19. 22 9月, 2011 3 次提交