aboutsummaryrefslogtreecommitdiffstats
path: root/arch/arm/plat-omap/include
diff options
context:
space:
mode:
authorJon Hunter <jon-hunter@ti.com>2012-06-05 13:34:52 -0400
committerTony Lindgren <tony@atomide.com>2012-06-14 05:39:07 -0400
commitd1c1691be5290bf7e5b11b63b6fda0d63a9f4937 (patch)
tree84510073dc3d056c19c1db60457f1e7c2b2f482b /arch/arm/plat-omap/include
parentb7b4ff764f7bf903e47eebdab661b1c38e791c6d (diff)
ARM: OMAP: Add DMTIMER capability variable to represent timer features
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: Jon Hunter <jon-hunter@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
Diffstat (limited to 'arch/arm/plat-omap/include')
-rw-r--r--arch/arm/plat-omap/include/plat/dmtimer.h2
1 files changed, 2 insertions, 0 deletions
diff --git a/arch/arm/plat-omap/include/plat/dmtimer.h b/arch/arm/plat-omap/include/plat/dmtimer.h
index 1e5ce5d5624..48e54caf900 100644
--- a/arch/arm/plat-omap/include/plat/dmtimer.h
+++ b/arch/arm/plat-omap/include/plat/dmtimer.h
@@ -101,6 +101,7 @@ struct dmtimer_platform_data {
101 bool loses_context; 101 bool loses_context;
102 102
103 int (*get_context_loss_count)(struct device *dev); 103 int (*get_context_loss_count)(struct device *dev);
104 u32 timer_capability;
104}; 105};
105 106
106int omap_dm_timer_reserve_systimer(int id); 107int omap_dm_timer_reserve_systimer(int id);
@@ -273,6 +274,7 @@ struct omap_dm_timer {
273 bool loses_context; 274 bool loses_context;
274 int ctx_loss_count; 275 int ctx_loss_count;
275 int revision; 276 int revision;
277 u32 capability;
276 struct platform_device *pdev; 278 struct platform_device *pdev;
277 struct list_head node; 279 struct list_head node;
278 280