summaryrefslogtreecommitdiff
path: root/arch/arm/plat-omap/dmtimer.c
AgeCommit message (Collapse)Author
2013-05-07Merge tag 'dt-for-linus-2' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc Pull ARM SoC device tree updates (part 2) from Arnd Bergmann: "These are mostly new device tree bindings for existing drivers, as well as changes to the device tree source files to add support for those devices, and a couple of new boards, most notably Samsung's Exynos5 based Chromebook. The changes depend on earlier platform specific updates and touch the usual platforms: omap, exynos, tegra, mxs, mvebu and davinci." * tag 'dt-for-linus-2' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (169 commits) ARM: exynos: dts: cros5250: add EC device ARM: dts: Add sbs-battery for exynos5250-snow ARM: dts: Add i2c-arbitrator bus for exynos5250-snow ARM: dts: add mshc controller node for Exynos4x12 SoCs ARM: dts: Add chip-id controller node on Exynos4/5 SoC ARM: EXYNOS: Create virtual I/O mapping for Chip-ID controller using device tree ARM: davinci: da850-evm: add SPI flash support ARM: davinci: da850: override SPI DT node device name ARM: davinci: da850: add SPI1 DT node spi/davinci: add DT binding documentation spi/davinci: no wildcards in DT compatible property ARM: dts: mvebu: Convert mvebu device tree files to 64 bits ARM: dts: mvebu: introduce internal-regs node ARM: dts: mvebu: Convert all the mvebu files to use the range property ARM: dts: mvebu: move all peripherals inside soc ARM: dts: mvebu: fix cpus section indentation ARM: davinci: da850: add EHRPWM & ECAP DT node ARM/dts: OMAP3: fix pinctrl-single configuration ARM: dts: Add OMAP3430 SDP NOR flash memory binding ARM: dts: Add NOR flash bindings for OMAP2420 H4 ...
2013-05-02Merge branch 'cleanup' into for-linusRussell King
Conflicts: arch/arm/plat-omap/dmtimer.c
2013-05-02ARM: OMAP: use consistent error checkingRussell King
Consistently check errors using the usual method used in the kernel for much of its history. For instance: int gpmc_cs_set_timings(int cs, const struct gpmc_timings *t) { int div; div = gpmc_calc_divider(t->sync_clk); if (div < 0) return div; static int gpmc_set_async_mode(int cs, struct gpmc_timings *t) { ... return gpmc_cs_set_timings(cs, t); ..... ret = gpmc_set_async_mode(gpmc_onenand_data->cs, &t); if (IS_ERR_VALUE(ret)) return ret; So, gpmc_cs_set_timings() thinks any negative return value is an error, but where we check that in higher levels, only a limited range are errors... There is only _one_ use of IS_ERR_VALUE() in arch/arm which is really appropriate, and that is in arch/arm/include/asm/syscall.h: static inline long syscall_get_error(struct task_struct *task, struct pt_regs *regs) { unsigned long error = regs->ARM_r0; return IS_ERR_VALUE(error) ? error : 0; } because this function really does have to differentiate between error return values and addresses which look like negative numbers (eg, from mmap()). So, here's a patch to remove them from OMAP, except for the above. Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2013-04-09ARM: OMAP2+: Populate DMTIMER errata when using device-treeJon Hunter
Currently the DMTIMER errata flags are not being populated when using device-tree. Add static platform data to populate errata flags when using device-tree. Please note that DMTIMER erratum i767 is applicable to OMAP3-5 devices as well as AM335x devices. Signed-off-by: Jon Hunter <jon-hunter@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Benoit Cousson <benoit.cousson@linaro.org>
2013-04-09ARM: dts: OMAP2+: Update DMTIMER compatibility propertyJon Hunter
Update the DMTIMER compatibility property to reflect the register level compatibilty between devices and update the various OMAP/AM timer bindings with the appropriate compatibility string. By doing this we can add platform specific data applicable to specific timer versions to the driver. For example, errata flags can be populated for the timer versions that are impacted. Signed-off-by: Jon Hunter <jon-hunter@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Benoit Cousson <benoit.cousson@linaro.org>
2013-04-09ARM: OMAP: Add function to request timer by nodeJon Hunter
Add a function so that OMAP dmtimers can be requested by device-tree node. This allows for devices, such as the internal DSP, or drivers, such as PWM, to reference a specific dmtimer node via the device-tree. Given that there are several APIs available for requesting dmtimers (by ID, by capability or by node) consolidate the code for all these functions into a single helper function that can be used by these request functions. Signed-off-by: Jon Hunter <jon-hunter@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Benoit Cousson <benoit.cousson@linaro.org>
2013-04-09ARM: OMAP: Force dmtimer restore if context loss is not detectableJon Hunter
When booting with device-tree the function pointer for detecting context loss is not populated. Ideally, the pm_runtime framework should be enhanced to allow a means for reporting context/state loss and we could avoid populating such function pointers altogether. In the interim until a generic non-device specific solution is in place, force a restore of the dmtimer when enabling the timer. Signed-off-by: Jon Hunter <jon-hunter@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Benoit Cousson <benoit.cousson@linaro.org>
2013-04-09ARM: OMAP: Simplify dmtimer context-loss handlingNeilBrown
The context loss handling in dmtimer appears to assume that omap_dm_timer_set_load_start() or omap_dm_timer_start() and omap_dm_timer_stop() bracket all interactions. Only the first two restore the context and the last updates the context loss counter. However omap_dm_timer_set_load() or omap_dm_timer_set_match() can reasonably be called outside this bracketing, and the fact that they call omap_dm_timer_enable() / omap_dm_timer_disable() suggest that is expected. So if, after a transition into and out of off-mode which would cause the dm timer to loose all state, omap_dm_timer_set_match() is called before omap_dm_timer_start(), the value read from OMAP_TIMER_CTRL_REG will be 'wrong' and this wrong value will be stored context.tclr so a subsequent omap_dm_timer_start() can fail (As the control register is wrong). Simplify this be doing the restore-from-context in omap_dm_timer_enable() so that whenever the timer is enabled, the context is correct. Also update the ctx_loss_count at the same time as we notice it is wrong - these is no value in delaying this until the omap_dm_timer_disable() as it cannot change while the timer is enabled. Signed-off-by: NeilBrown <neilb@suse.de> [jon-hunter@ti.com: minor update to subject and changed variable name] Signed-off-by: Jon Hunter <jon-hunter@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Benoit Cousson <benoit.cousson@linaro.org>
2013-02-24ARM: cleanup: clk_get() error handlingRussell King
Use the correct IS_ERR() to determine if clk_get() returned an error. Set timer->fclk to be an error value initially, and check everywhere using IS_ERR(). This keeps the range of valid values for 'struct clk' consistent. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2013-01-25ARM: Convert to devm_ioremap_resource()Thierry Reding
Convert all uses of devm_request_and_ioremap() to the newly introduced devm_ioremap_resource() which provides more consistent error handling. Signed-off-by: Thierry Reding <thierry.reding@avionic-design.de> Cc: Russell King <linux@arm.linux.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-01-03ARM: drivers: remove __dev* attributes.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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-12-17ARM/omap: use module_platform_driver macroSrinivas Kandagatla
This patch removes some code duplication by using module_platform_driver. Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@st.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2012-11-16ARM: OMAP: Add platform data header for DMTIMERsJon Hunter
Move definition of dmtimer platform data structure in to its own header under <linux/platform_data>. Signed-off-by: Jon Hunter <jon-hunter@ti.com>
2012-11-16ARM: OMAP: Define omap_dm_timer_prepare function as staticJon 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: Jon Hunter <jon-hunter@ti.com>
2012-11-16ARM: OMAP: Clean-up dmtimer reset codeJon 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: Jon Hunter <jon-hunter@ti.com>
2012-11-12ARM: OMAP: Remove __omap_dm_timer_set_source functionJon 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: Jon Hunter <jon-hunter@ti.com> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
2012-11-12ARM: OMAP: Remove unnecessary call to clk_get()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: Jon Hunter <jon-hunter@ti.com> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
2012-11-12ARM: OMAP: Add dmtimer interrupt disable functionJon 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: Jon Hunter <jon-hunter@ti.com> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
2012-11-12ARM: OMAP: Fix spurious interrupts when using timer match featureJon 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: Jon Hunter <jon-hunter@ti.com> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
2012-11-12ARM: OMAP: Don't restore DMTIMER interrupt status registerJon 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: Jon Hunter <jon-hunter@ti.com> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
2012-11-12ARM: OMAP: Don't restore of DMTIMER TISTAT registerJon 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: Jon Hunter <jon-hunter@ti.com> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
2012-11-12ARM: OMAP: Fix dmtimer reset for timer1Jon 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: Jon Hunter <jon-hunter@ti.com> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
2012-11-12ARM: OMAP: Fix timer posted mode supportJon 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: Jon Hunter <jon-hunter@ti.com> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
2012-11-12ARM: OMAP3+: Implement timer workaround for errata i103 and i767Jon 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: Jon Hunter <jon-hunter@ti.com> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
2012-11-09Merge branch 'omap-for-v3.8/cleanup-headers-prepare-multiplatform-v3' into ↵Tony Lindgren
omap-for-v3.8/dt Conflicts: arch/arm/plat-omap/dmtimer.c Resolved as suggested by Jon Hunter.
2012-11-02ARM: OMAP: Remove unnecessary mach and plat includesTony 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: Tony Lindgren <tony@atomide.com>
2012-11-02ARM: OMAP: Add DT support for timer driverJon 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: Jon Hunter <jon-hunter@ti.com>
2012-11-02ARM: OMAP: Add function to request a timer by capabilityJon 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: Jon Hunter <jon-hunter@ti.com>
2012-10-31ARM: OMAP: Move omap-pm-noop.c local to mach-omap2Tony 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: Tony Lindgren <tony@atomide.com>
2012-10-18ARM: OMAP: Make plat/omap-pm.h local to mach-omap2Tony Lindgren
We must move this for ARM common zImage support. Note that neither drivers/media/rc/ir-rx51.c or drivers/media/platform/omap3isp/ispvideo.c need to include omap-pm.h, so this patch removes the include for those files. Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Mauro Carvalho Chehab <mchehab@infradead.org> Cc: Timo Kokkonen <timo.t.kokkonen@iki.fi> Cc: linux-media@vger.kernel.org Signed-off-by: Tony Lindgren <tony@atomide.com>
2012-08-13ARM: OMAP: dmtimers: Fix locking issue in omap_dm_timer_request*()Timo Kokkonen
Calling omap_dm_timer_prepare while the spinlock is held is not allowed as sleeping functions are called later on during the preparation (namely within clk_get()). dm_timer_lock is only required for protecting the omap_timer_list. After the timer is marked as reserved, the lock is no longer needed and should be freed. Signed-off-by: Timo Kokkonen <timo.t.kokkonen@iki.fi> Cc: Tarun Kanti DebBarma <tarun.kanti@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2012-08-07ARM: OMAP2+: Fix dmtimer set source clock failureJon 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: Jon Hunter <jon-hunter@ti.com> Acked-by: Kevin Hilman <khilman@ti.com> Cc: stable@vger.kernel.org Signed-off-by: Tony Lindgren <tony@atomide.com>
2012-07-05ARM: OMAP: dmtimer: use devm_ API and do some cleanup in probe()Tarun Kanti DebBarma
Replace the regular kzalloc and ioremap with the devm_ equivalent to simplify error handling. We don't need kree() any more in omap_dm_timer_remove(). Also added *dev* pointer to reference pdev->dev which makes the usage shorter in code. Cc: Cousson, Benoit <b-cousson@ti.com> Cc: Paul Walmsley <paul@pwsan.com> Cc: Kevin Hilman <khilman@ti.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Signed-off-by: Tarun Kanti DebBarma <tarun.kanti@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2012-06-14ARM: OMAP2+: Simplify dmtimer clock aliasesJon 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: Jon Hunter <jon-hunter@ti.com> Acked-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2012-06-14ARM: OMAP2+: Move dmtimer clock set function to dmtimer driverJon 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: Jon Hunter <jon-hunter@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2012-06-14ARM: OMAP1: Fix dmtimer supportJon 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: Jon Hunter <jon-hunter@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2012-06-14ARM: OMAP: Add flag to indicate if a timer needs a manual resetJon 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: Jon Hunter <jon-hunter@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2012-06-14ARM: OMAP: Remove timer function pointer for context loss counterJon 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: Jon Hunter <jon-hunter@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2012-06-14ARM: OMAP: Remove loses_context variable from timer platform dataJon 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: Jon Hunter <jon-hunter@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2012-06-14ARM: OMAP: Add DMTIMER capability variable to represent timer featuresJon 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: Jon Hunter <jon-hunter@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2012-06-14ARM: OMAP2+: Add dmtimer platform function to reserve systimersJon 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: Jon Hunter <jon-hunter@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2012-05-26Merge tag 'cleanup2' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc Pull arm-soc cleanups (part 2) from Olof Johansson: "More cleanups, continuing an earlier set with omap and samsung specific cleanups. These could not go into the first set because they have dependencies on various other series that in turn depend on the first cleanups." Fixed up conflicts in arch/arm/plat-omap/counter_32k.c due to commit bd0493eaaf5c: "move read_{boot,persistent}_clock to the architecture level" that changed how the persistent clocks were handled. And trivial conflicts in arch/arm/mach-omap1/common.h due to just independent changes close to each other. * tag 'cleanup2' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (35 commits) ARM: SAMSUNG: merge plat-s5p into plat-samsung ARM: SAMSUNG: move options for common s5p into plat-samsung/Kconfig ARM: SAMSUNG: move setup code for s5p mfc and mipiphy into plat-samsung ARM: SAMSUNG: move platform device for s5p uart into plat-samsung ARM: SAMSUNG: move hr timer for common s5p into plat-samsung ARM: SAMSUNG: move pm part for common s5p into plat-samsung ARM: SAMSUNG: move interrupt part for common s5p into plat-samsung ARM: SAMSUNG: move clock part for common s5p into plat-samsung ARM: S3C24XX: Use common macro to define resources on dev-uart.c ARM: S3C24XX: move common clock init into common.c ARM: S3C24XX: move common power-management code to mach-s3c24xx ARM: S3C24XX: move plat-s3c24xx/dev-uart.c into common.c ARM: S3C24XX: move plat-s3c24xx/cpu.c ARM: OMAP2+: Kconfig: convert SOC_OMAPAM33XX to SOC_AM33XX ARM: OMAP2+: Kconfig: convert SOC_OMAPTI81XX to SOC_TI81XX GPMC: add ECC control definitions ARM: OMAP2+: dmtimer: remove redundant sysconfig context restore ARM: OMAP: AM35xx: convert 3517 detection/flags to AM35xx ARM: OMAP: AM35xx: remove redunant cpu_is checks for AM3505 ARM: OMAP1: Pass dma request lines in platform data to MMC driver ...
2012-05-10ARM: OMAP2+: dmtimer: remove redundant sysconfig context restoreTarun Kanti DebBarma
Since hwmod framework now manages sysconfig context save/restore there is no more need to touch this register in driver. Hence, remove restore of sysconfig register in omap_timer_restore_context. This was causing incorrect context restore of sysconfig register. Signed-off-by: Tarun Kanti DebBarma <tarun.kanti@ti.com> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Acked-by: Kevin Hilman <khilman@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2012-04-17ARM: OMAP2+: clean up some cppcheck warningsPaul 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: Paul 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
2012-03-27Merge tag 'cleanup' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-socLinus Torvalds
Pull "ARM: global cleanups" from Arnd Bergmann: "Quite a bit of code gets removed, and some stuff moved around, mostly the old samsung s3c24xx stuff. There should be no functional changes in this series otherwise. Some cleanups have dependencies on other arm-soc branches and will be sent in the second round. Signed-off-by: Arnd Bergmann <arnd@arndb.de>" Fixed up trivial conflicts mainly due to #include's being changes on both sides. * tag 'cleanup' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (121 commits) ep93xx: Remove unnecessary includes of ep93xx-regs.h ep93xx: Move EP93XX_SYSCON defines to SoC private header ep93xx: Move crunch code to mach-ep93xx directory ep93xx: Make syscon access functions private to SoC ep93xx: Configure GPIO ports in core code ep93xx: Move peripheral defines to local SoC header ep93xx: Convert the watchdog driver into a platform device. ep93xx: Use ioremap for backlight driver ep93xx: Move GPIO defines to gpio-ep93xx.h ep93xx: Don't use system controller defines in audio drivers ep93xx: Move PHYS_BASE defines to local SoC header file ARM: EXYNOS: Add clock register addresses for EXYNOS4X12 bus devfreq driver ARM: EXYNOS: add clock registers for exynos4x12-cpufreq PM / devfreq: update the name of EXYNOS clock registers that were omitted PM / devfreq: update the name of EXYNOS clock register ARM: EXYNOS: change the prefix S5P_ to EXYNOS4_ for clock ARM: EXYNOS: use static declaration on regarding clock ARM: EXYNOS: replace clock.c for other new EXYNOS SoCs ARM: OMAP2+: Fix build error after merge ARM: S3C24XX: remove call to s3c24xx_setup_clocks ...
2012-03-05ARM: OMAP: dmtimer: fix missing content/correction in low-power mode supportTarun Kanti DebBarma
Since omap_dm_timer_write_reg/__omap_dm_timer_write is now modified to use timer->func_base OCP_CFG should not use this wrapper anymore. Instead use __raw_writel() directly and use timer->io_base instead to write to OCP_CFG. The timer->sys_stat is valid only if timer->revision is 1. In the context restore function make this correction. Save the contexts and loss count when timer is stopped. Also, disable the clock. Else, clock usecount would become imbalanced. Signed-off-by: Tarun Kanti DebBarma <tarun.kanti@ti.com> Tested-by: Omar Ramirez Luna <omar.ramirez@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2012-02-24ARM: OMAP: Remove plat/io.h by splitting it into mach/io.h and mach/hardware.hTony Lindgren
This is needed to minimize io.h so the SoC specific io.h for ARMs can removed. Note that minimal driver changes for DSS and RNG are needed to include cpu.h for SoC detection macros. Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: Matt Mackall <mpm@selenic.com> Cc: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Tony Lindgren <tony@atomide.com>
2011-11-04ARM: OMAP: dmtimer: Include linux/module.hAxel 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: Axel Lin <axel.lin@gmail.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2011-10-01ARM: omap: use __devexit_p in dmtimer driverArnd Bergmann
The omap_dm_timer_remove function gets discarded when CONFIG_HOTPLUG is not set, so we must not reference it unconditionally. Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2011-09-21ARM: OMAP: dmtimer: add error handling to export APIsTarun Kanti DebBarma
Add error handling code to export APIs. Signed-off-by: Tarun Kanti DebBarma <tarun.kanti@ti.com> Reviewed-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>