aboutsummaryrefslogtreecommitdiff
path: root/arch/arm/plat-omap/dmtimer.c
AgeCommit message (Collapse)Author
2018-02-22ARM: OMAP: Move dmtimer driver out of plat-omap to drivers under clocksourceKeerthy
Move the dmtimer driver out of plat-omap to clocksource. So that non-omap devices also could use this. No Code changes done to the driver file only renamed to timer-ti-dm.c. Also removed the config dependencies for OMAP_DM_TIMER. Signed-off-by: Keerthy <j-keerthy@ti.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk> Tested-by: Ladislav Michl <ladis@linux-mips.org> [tony@atomide.com: add select omap_dm_timer for omap16xx] Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-02-22ARM: OMAP: Move dmtimer.h out of plat-omapKeerthy
The header file is currently under plat-omap directory under arch/omap. Move this out to an accessible place. No Code changes done to the header file and renamed to timer-ti-dm.h. Signed-off-by: Keerthy <j-keerthy@ti.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk> Tested-by: Ladislav Michl <ladis@linux-mips.org> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-02-22ARM: OMAP: dmtimer: Remove all the exportsKeerthy
Remove all the unwanted exports from the driver Signed-off-by: Keerthy <j-keerthy@ti.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk> Tested-by: Ladislav Michl <ladis@linux-mips.org> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-02-22ARM: OMAP: Fix dmtimer init for omap1Tony Lindgren
We need to enable PM runtime on omap1 also as otherwise we will get errors: omap_timer omap_timer.1: omap_dm_timer_probe: pm_runtime_get_sync failed! omap_timer: probe of omap_timer.1 failed with error -13 ... We are checking for OMAP_TIMER_NEEDS_RESET flag elsewhere so this is safe to do. Cc: Aaro Koskinen <aaro.koskinen@iki.fi> Cc: Keerthy <j-keerthy@ti.com> Cc: Ladislav Michl <ladis@linux-mips.org> Signed-off-by: Tony Lindgren <tony@atomide.com>
2017-10-11ARM: OMAP: Fix typos in two comment lines in _omap_dm_timer_request()Markus Elfring
Adjust three words in this description. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> Signed-off-by: Tony Lindgren <tony@atomide.com>
2017-10-11ARM: OMAP: Improve a size determination in two functionsMarkus Elfring
Replace the specification of data structures by pointer dereferences as the parameter for the operator "sizeof" to make the corresponding size determination a bit safer according to the Linux coding style convention. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> Signed-off-by: Tony Lindgren <tony@atomide.com>
2017-10-11ARM: OMAP: Delete an error message for a failed memory allocation in two ↵Markus Elfring
functions Omit extra messages for a memory allocation failure in these functions. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> Signed-off-by: Tony Lindgren <tony@atomide.com>
2015-11-30ARM: OMAP: dmtimer: check for fixed timers during configSuman Anna
The omap_dm_timer_set_source() function provides a means for client users to configure the mux parent for a GPTimer's functional clock. However, not all timers are configurable (Eg: Timer12 on DRA7 is fed by an internal 32k oscillator clock, and does not have configurable parent clocks). So, check for such cases and proceed with out throwing an error. Signed-off-by: Suman Anna <s-anna@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2015-11-30ARM: OMAP: add DT support for ti,dm816-timerNeil Armstrong
Adds ti,dm816-timer to the dmtimer OF match table. Cc: Brian Hutchinson <b.hutchman@gmail.com> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2015-11-30ARM: OMAP: dmtimer: Add clock source from DTNeil Armstrong
Add a function which sets the timer source from the clocks binding on dm_timer_prepare call. In case the clocks property is not valid, it falls back to the set_source() with 32_KHZ clock as default. Suggested-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2015-03-17ARM: OMAP: dmtimer: disable pm runtime on removeSuman Anna
Disable the pm_runtime of the device upon remove. This is added to balance the pm_runtime_enable() invoked in the probe. Signed-off-by: Suman Anna <s-anna@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2015-03-17ARM: OMAP: dmtimer: check for pm_runtime_get_sync() failureSuman Anna
The current OMAP dmtimer probe does not check for the return status of pm_runtime_get_sync() before initializing the timer registers. Any timer with missing hwmod data would return a failure here, and the access of registers without enabling the clocks for the timer would trigger a l3_noc interrupt and a kernel boot hang. Add proper checking so that the probe would return a failure graciously without hanging the kernel boot. Signed-off-by: Suman Anna <s-anna@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2014-05-08ARM: OMAP: dmtimer: raw read and write endian fixVictor Kamensky
All OMAP IP blocks expect LE data, but CPU may operate in BE mode. Need to use endian neutral functions to read/write h/w registers. I.e instead of __raw_read[lw] and __raw_write[lw] functions code need to use read[lw]_relaxed and write[lw]_relaxed functions. If the first simply reads/writes register, the second will byteswap it if host operates in BE mode. Changes are trivial sed like replacement of __raw_xxx functions with xxx_relaxed variant. Signed-off-by: Victor Kamensky <victor.kamensky@linaro.org> Signed-off-by: Taras Kondratiuk <taras.kondratiuk@linaro.org> Signed-off-by: Tony Lindgren <tony@atomide.com>
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>