1. 14 6月, 2012 9 次提交
    • 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: OMAP2+: Fix external clock support for dmtimers · 67d2e760
      Jon Hunter 提交于
      Currently, the dmtimer determines whether an timer can support an external
      clock source (sys_altclk) for driving the timer by the IP version. Only
      OMAP24xx devices can support an external clock source, but the IP version
      between OMAP24xx and OMAP3xxx is common and so this incorrectly indicates
      that OMAP3 devices can use an external clock source.
      
      Rather than use the IP version, just let the clock framework handle this.
      If the "alt_ck" does not exist for a timer then the clock framework will fail
      to find the clock and hence will return an error. By doing this we can eliminate
      the "timer_ip_version" variable passed as part of the platform data and simplify
      the code.
      
      We can also remove the timer IP version from the HWMOD data because the dmtimer
      driver uses the TIDR register to determine the IP version.
      Signed-off-by: NJon Hunter <jon-hunter@ti.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      67d2e760
    • J
      ARM: OMAP2+: HWMOD: Correct timer device attributes · 139486fa
      Jon Hunter 提交于
      Fix the following issues with the timer device attributes for OMAP2+ devices:
      
      1. For OMAP24xx devices, timers 2-8 have the ALWAYS-ON attribute indicating
         that these timers are in an ALWAYS-ON power domain. This is not the case
         only timer1 is in an ALWAYS-ON power domain.
      2. For OMAP3xxx devices, timers 2-7 have the ALWAYS-ON attribute indicating
         that these timers are in an ALWAYS-ON power domain. This is not the case
         only timer1 and timer12 are in an ALWAYS-ON power domain.
      3. For OMAP3xxx devices, timer12 does not have the ALWAYS-ON attribute but
         is in an always-on power domain.
      Signed-off-by: NJon Hunter <jon-hunter@ti.com>
      Acked-by: NPaul Walmsley <paul@pwsan.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      139486fa
    • 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
    • J
      ARM: OMAP2+: Remove unused max number of timers definition · 26fe4e45
      Jon Hunter 提交于
      The OMAP2+ timer code has a definition for the maximum number of timers that
      OMAP2+ devices have. This defintion is not used anywhere in the code and
      appears to be left over. Furthermore the definition is not accurate for OMAP4
      devices that only have 11 timers available because the 12th timer is reserved
      as a secure timer and for OMAP3 devices the 12th timer is not available on
      secure devices. Therefore, remove this definition.
      Signed-off-by: NJon Hunter <jon-hunter@ti.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      26fe4e45
    • J
      ARM: OMAP: Remove unnecessary clk structure · b8fd7331
      Jon Hunter 提交于
      In the plat/dmtimer.h there is a structure named "clk" declared. This structure
      is not used and appears to be left over from previous code. Hence, remove this
      unused structure.
      
      Verified that both omap1 and omap2plus kernel configurations build with this
      change.
      Signed-off-by: NJon Hunter <jon-hunter@ti.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      b8fd7331
  2. 04 6月, 2012 1 次提交
  3. 02 6月, 2012 5 次提交
  4. 01 6月, 2012 15 次提交
  5. 31 5月, 2012 2 次提交
  6. 30 5月, 2012 1 次提交
  7. 25 5月, 2012 3 次提交
  8. 24 5月, 2012 2 次提交
  9. 22 5月, 2012 2 次提交
    • A
      new helper: sigsuspend() · 68f3f16d
      Al Viro 提交于
      guts of saved_sigmask-based sigsuspend/rt_sigsuspend.  Takes
      kernel sigset_t *.
      
      Open-coded instances replaced with calling it.
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      68f3f16d
    • T
      timers: Fixup the Kconfig consolidation fallout · 764e0da1
      Thomas Gleixner 提交于
      Sigh, I missed to check which architecture Kconfig files actually
      include the core Kconfig file. There are a few which did not. So we
      broke them.
      
      Instead of adding the includes to those, we are better off to move the
      include to init/Kconfig like we did already with irqs and others.
      
      This does not change anything for the architectures using the old
      style periodic timer mode. It just solves the build wreckage there.
      
      For those architectures which use the clock events infrastructure it
      moves the include of the core Kconfig file to "General setup" which is
      a way more logical place than having it at random locations specified
      by the architecture specific Kconfigs.
      Reported-by: NIngo Molnar <mingo@kernel.org>
      Cc: Anna-Maria Gleixner <anna-maria@glx-um.de>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      764e0da1
新手
引导
客服 返回
顶部