- 08 5月, 2013 1 次提交
-
-
由 Linus Torvalds 提交于
I badly screwed up the merge in commit 6fa52ed3 ("Merge tag 'drivers-for-linus' of git://git.kernel.org/pub/.../arm-soc") by incorrectly taking the arch/arm/mach-omap2/* data fully from the merge target because the 'drivers-for-linus' branch seemed to be a proper superset of the duplicate ARM commits. That was bogus: commit ff931c82 ("ARM: OMAP: clocks: Delay clk inits atleast until slab is initialized") only existed in head, and the changes to arch/arm/mach-omap2/timer.c from that commit got list. Re-doing the merge more carefully, I do think this part was the only thing I screwed up. Knock wood. Reported-by: NTony Lindgren <tony@atomide.com> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Olof Johansson <olof@lixom.net> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 07 5月, 2013 1 次提交
-
-
由 Vaibhav Hiremath 提交于
Looks like the timer.c fixes in commit ff931c82 (ARM: OMAP: clocks: Delay clk inits atleast until slab is initialized) got lost in a merge with da4a686a (ARM: smp_twd: convert to use CLKSRC_OF init). Without the omap_clk_init() calls none of OMAP family of devices boot. Signed-off-by: NVaibhav Hiremath <hvaibhav@ti.com> [tony@atomide.com: updated comments to describe merge error] Signed-off-by: NTony Lindgren <tony@atomide.com>
-
- 03 5月, 2013 1 次提交
-
-
由 Russell 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: NTony Lindgren <tony@atomide.com> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
- 24 4月, 2013 1 次提交
-
-
由 Arnd Bergmann 提交于
Commit 0583fe47 "ARM: convert arm/arm64 arch timer to use CLKSRC_OF init" has left the omap5_realtime_timer_init() function with a stale variable and broken whitespace. This fixes both. Signed-off-by: NArnd Bergmann <arnd@arndb.de>
-
- 12 4月, 2013 1 次提交
-
-
由 Rob Herring 提交于
This converts arm and arm64 to use CLKSRC_OF DT based initialization for the arch timer. A new function arch_timer_arch_init is added to allow for arch specific setup. This has a side effect of enabling sched_clock on omap5 and exynos5. There should not be any reason not to use the arch timers for sched_clock. Signed-off-by: NRob Herring <rob.herring@calxeda.com> Cc: Russell King <linux@arm.linux.org.uk> Cc: Kukjin Kim <kgene.kim@samsung.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Simon Horman <horms@verge.net.au> Cc: Magnus Damm <magnus.damm@gmail.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Will Deacon <will.deacon@arm.com> Cc: John Stultz <john.stultz@linaro.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-samsung-soc@vger.kernel.org Cc: linux-omap@vger.kernel.org Cc: linux-sh@vger.kernel.org Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
-
- 09 4月, 2013 1 次提交
-
-
由 Jon 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: NJon Hunter <jon-hunter@ti.com> Acked-by: NTony Lindgren <tony@atomide.com> Signed-off-by: NBenoit Cousson <benoit.cousson@linaro.org>
-
- 02 4月, 2013 7 次提交
-
-
由 Jon Hunter 提交于
Commit 6bb27d73 (ARM: delete struct sys_timer) changed the function created by the macro OMAP_SYS_32K_TIMER_INIT from static void to void. For OMAP4+ devices this created the following sparse warning ... arch/arm/mach-omap2/timer.c:585:1: warning: symbol 'omap4_sync32k_timer_init' was not declared. Should it be static? The function omap4_sync32k_timer_init() is not referenced outside of the file timer.c and so make this function static. Signed-off-by: NJon Hunter <jon-hunter@ti.com>
-
由 Jon Hunter 提交于
Currently, the timer ID is being passed to the function omap_dm_timer_init_one(). Instead of passing the ID separately, store it in the omap_dm_timer structure, that is also passed, and access the ID from this structure. Signed-off-by: NJon Hunter <jon-hunter@ti.com>
-
由 Jon Hunter 提交于
When booting with device-tree for OMAP3 and AM335x devices and a gptimer is used as the clocksource (which is always the case for AM335x), a gptimer located in a power domain that is not always-on is selected. Ideally we should use a gptimer for clocksource that is located in a power domain that is always on (such as the wake-up domain) so that time can be maintained during a kernel suspend without keeping on additional power domains unnecessarily. In order to fix this so that we can select a gptimer located in a power domain that is always-on, the following changes were made ... 1. Currently, only when selecting a gptimer to use for a clockevent timer, do we pass a timer property that can be used to select a specific gptimer. Change this so that we can pass a property when selecting a gptimer to use for a clocksource timer too. 2. Currently, when selecting either a gptimer to use for a clockevent timer or a clocksource timer and no timer property is passed, then the first available timer is selected regardless of the properties it has. Change this so that if no properties are passed, then a timer that does not have additional features (such as always-on, dsp-irq, pwm, and secure) is selected. For OMAP3 and AM335x devices that use a gptimer for clocksource, change the selection of the gptimer so that by default the gptimer located in the always-on power domain is used for clocksource instead of clockevents. Please note that using a gptimer for both clocksource and clockevents can have a system power impact during idle. The reason being is that OMAP and AMxxx devices typically only have one gptimer in a power domain that is always-on. Therefore when the kernel is idle both the clocksource and clockevent timers will be active and this will keep additional power domains on. During kernel suspend, only the clocksource timer is active and therefore, it is better to use a gptimer in a power domain that is always-on for clocksource. Signed-off-by: NJon Hunter <jon-hunter@ti.com> Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com> Acked-by: NIgor Grinberg <grinberg@compulab.co.il>
-
由 Jon Hunter 提交于
There is a lot of redundancy in the definitions for the various system timers for OMAP2+ devices. For example, the omap3_am33xx_gptimer_timer_init() function is the same as the omap3_gp_gptimer_timer_init() function and the function omap4_sync32k_timer_init() can be re-used for OMAP5 devices. Therefore, consolidate the definitions to simplify the code. Signed-off-by: NJon Hunter <jon-hunter@ti.com> Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com> Acked-by: NIgor Grinberg <grinberg@compulab.co.il>
-
由 Jon Hunter 提交于
In commit c59b537d (ARM: OMAP2+: Simplify dmtimer clock aliases), new clock aliases for dmtimers were added to simplify the code. These clock aliases can also be used when configuring the system timers and allow us to remove the current definitions, simplifying the code. Please note that for OMAP4/5 devices (unlike OMAP2/3 devices), there is no clock alias for "timer_sys_ck" with NULL as the device name. Therefore we still need to use the alias "sys_clkin_ck" for these devices. Signed-off-by: NJon Hunter <jon-hunter@ti.com> Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
-
由 Jon Hunter 提交于
Currently, when configuring the clock-events and clock-source timers for OMAP2+ devices, we check whether the timer ID is 12 before attempting to set the parent clock for the timer. This test was added for OMAP3 general purpose devices (no security features enabled) that a 12th timer available but unlike the other timers only has a single functional clock source. Calling clk_set_parent() for this 12th timer would always return an error because there is only one choice for a parent clock. Therefore, this hard-coded timer ID test was added. To avoid this timer ID test, simply check to see if the timer's current parent clock is the desired parent clock and only call clk_set_parent() if this is not the case. Also if clk_get() fails, then use PTR_ERR() to return the error code. Signed-off-by: NJon Hunter <jon-hunter@ti.com> Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
-
由 Jon Hunter 提交于
Currently on boot, when displaying the name of the gptimer used for clockevents and clocksource timers, the timer ID is shown. However, when booting with device-tree, the timer ID is not used to select a gptimer but a timer property. Hence, it is possible that the timer selected when booting with device-tree does not match the ID shown. Therefore, instead display the HWMOD name of the gptimer and use the HWMOD name as the name of clockevent and clocksource timer (if a gptimer is used). Signed-off-by: NJon Hunter <jon-hunter@ti.com> Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
-
- 27 3月, 2013 1 次提交
-
-
由 Rajendra Nayak 提交于
clk inits on OMAP happen quite early, even before slab is available. The dependency comes from the fact that the timer init code starts to use clocks and hwmod and we need clocks to be initialized by then. There are various problems doing clk inits this early, one is, not being able to do dynamic clk registrations and hence the dependency on clk-private.h. The other is, inability to debug early kernel crashes without enabling DEBUG_LL and earlyprintk. Doing early clk init also exposed another instance of a kernel panic due to a BUG() when CONFIG_DEBUG_SLAB is enabled. [ 0.000000] Kernel BUG at c01174f8 [verbose debug info unavailable] [ 0.000000] Internal error: Oops - BUG: 0 [#1] SMP ARM [ 0.000000] Modules linked in: [ 0.000000] CPU: 0 Not tainted (3.9.0-rc1-12179-g72d48f9 #6) [ 0.000000] PC is at __kmalloc+0x1d4/0x248 [ 0.000000] LR is at __clk_init+0x2e0/0x364 [ 0.000000] pc : [<c01174f8>] lr : [<c0441f54>] psr: 600001d3 [ 0.000000] sp : c076ff28 ip : c065cefc fp : c0441f54 [ 0.000000] r10: 0000001c r9 : 000080d0 r8 : c076ffd4 [ 0.000000] r7 : c074b578 r6 : c0794d88 r5 : 00000040 r4 : 00000000 [ 0.000000] r3 : 00000000 r2 : c07cac70 r1 : 000080d0 r0 : 0000001c [ 0.000000] Flags: nZCv IRQs off FIQs off Mode SVC_32 ISA ARM Segment kernel [ 0.000000] Control: 10c53c7d Table: 8000404a DAC: 00000017 [ 0.000000] Process swapper (pid: 0, stack limit = 0xc076e240) [ 0.000000] Stack: (0xc076ff28 to 0xc0770000) [ 0.000000] ff20: 22222222 c0794ec8 c06546e8 00000000 00000040 c0794d88 [ 0.000000] ff40: c074b578 c076ffd4 c07951c8 c076e000 00000000 c0441f54 c074b578 c076ffd4 [ 0.000000] ff60: c0793828 00000040 c0794d88 c074b578 c076ffd4 c0776900 c076e000 c07272ac [ 0.000000] ff80: 2f800000 c074c968 c07f93d0 c0719780 c076ffa0 c076ff98 00000000 00000000 [ 0.000000] ffa0: 00000000 00000000 00000000 00000001 c074cd6c c077b1ec 8000406a c0715724 [ 0.000000] ffc0: 00000000 00000000 00000000 00000000 00000000 c074c968 10c53c7d c0776974 [ 0.000000] ffe0: c074cd6c c077b1ec 8000406a 411fc092 00000000 80008074 00000000 00000000 [ 0.000000] [<c01174f8>] (__kmalloc+0x1d4/0x248) from [<c0441f54>] (__clk_init+0x2e0/0x364) [ 0.000000] [<c0441f54>] (__clk_init+0x2e0/0x364) from [<c07272ac>] (omap4xxx_clk_init+0xbc/0x140) [ 0.000000] [<c07272ac>] (omap4xxx_clk_init+0xbc/0x140) from [<c0719780>] (setup_arch+0x15c/0x284) [ 0.000000] [<c0719780>] (setup_arch+0x15c/0x284) from [<c0715724>] (start_kernel+0x7c/0x334) [ 0.000000] [<c0715724>] (start_kernel+0x7c/0x334) from [<80008074>] (0x80008074) [ 0.000000] Code: e5883004 e1a00006 e28dd00c e8bd8ff0 (e7f001f2) [ 0.000000] ---[ end trace 1b75b31a2719ed1c ]--- [ 0.000000] Kernel panic - not syncing: Attempted to kill the idle task! It was a know issue, that slab allocations would fail when common clock core tries to cache parent pointers for mux clocks on OMAP, and hence a patch 'clk: Allow late cache allocation for clk->parents, commit 7975059d' was added to work this problem around. A BUG() within kmalloc() with CONFIG_DEBUG_SLAB enabled was completely overlooked causing this regression. More details on the issue reported can be found here, http://www.mail-archive.com/linux-omap@vger.kernel.org/msg85932.html With all these issues around clk inits happening way too early, it makes sense to at least move them to a point where dynamic memory allocations are possible. So move them to a point just before the timer code starts using clocks and hwmod. This should at least pave way for clk inits on OMAP moving to dynamic clock registrations instead of using the static macros defined in clk-private.h. The issue with kernel panic while CONFIG_DEBUG_SLAB is enabled was reported by Piotr Haber and Tony Lindgren and this patch fixes the reported issue as well. Reported-by: NPiotr Haber <phaber@broadcom.com> Reported-by: NTony Lindgren <tony@atomide.com> Signed-off-by: NRajendra Nayak <rnayak@ti.com> Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com> Reviewed-by: NMike Turquette <mturquette@linaro.org> Acked-by: NPaul Walmsley <paul@pwsan.com> Cc: stable@vger.kernel.org # v3.8 Signed-off-by: NTony Lindgren <tony@atomide.com>
-
- 19 3月, 2013 1 次提交
-
-
由 Santosh Shilimkar 提交于
OMAP5 clockdata has different sys clock node name. Fix the timer code to take care of it. Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
-
- 14 3月, 2013 1 次提交
-
-
由 Russell 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: NTony Lindgren <tony@atomide.com> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
- 11 3月, 2013 1 次提交
-
-
由 Rob Herring 提交于
Now that we have OF based init with CLKSRC_OF, convert smp_twd init function to use it and covert all callers of twd_local_timer_of_register. Signed-off-by: NRob Herring <rob.herring@calxeda.com> Cc: Shawn Guo <shawn.guo@linaro.org> Cc: Sascha Hauer <kernel@pengutronix.de> Cc: Russell King <linux@arm.linux.org.uk> Cc: Viresh Kumar <viresh.linux@gmail.com> Cc: Shiraz Hashim <shiraz.hashim@st.com> Cc: Srinidhi Kasagar <srinidhi.kasagar@stericsson.com> Cc: John Stultz <johnstul@us.ibm.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-omap@vger.kernel.org Cc: spear-devel@list.st.com Reviewed-by: NStephen Warren <swarren@nvidia.com> Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com> Acked-by: NTony Lindgren <tony@atomide.com> Acked-by: NLinus Walleij <linus.walleij@linaro.org>
-
- 02 2月, 2013 1 次提交
-
-
由 Jon Hunter 提交于
Commit 9725f445 (ARM: OMAP: Add DT support for timer driver) added device-tree support for selecting a clockevent timer by property. However, the code is currently ignoring the property passed and selecting the first available timer found. Hence, for the OMAP3 beagle board timer-12 is not being selected as expected. Fix this problem by ensuring the timer property is passed to omap_get_timer_dt(). Signed-off-by: NJon Hunter <jon-hunter@ti.com> Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com> Tested-by: NVaibhav Bedia <vaibhav.bedia@ti.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
- 26 1月, 2013 1 次提交
-
-
由 Paul Walmsley 提交于
Remove now-obsolete code from arch/arm/mach-omap2/omap_device.c. This mostly consists of removing the first attempt at device PM latency handling. This was never really used, has been replaced by the common dev_pm_qos code, and needs to go away as part of the DT conversion. Also, the early platform_device creation code has been removed, as it appears to be unused. Signed-off-by: NPaul Walmsley <paul@pwsan.com> Cc: Kevin Hilman <khilman@deeprootsystems.com>
-
- 22 1月, 2013 1 次提交
-
-
由 Pantelis Antoniou 提交于
The iterator correctly handles of_node_put() calls. Remove it before continue'ing the loop. Without this patch you get the following with CONFIG_OF_DYNAMIC set: ERROR: Bad of_node_put() on /ocp/timer@44e31000! [<c001329c>] (unwind_backtrace+0x0/0xe0) from [<c03dd8f0>] (of_node_release+0x2c/0xa0)! [<c03dd8f0>] (of_node_release+0x2c/0xa0) from [<c03ddea0>] (of_find_matching_node_and_match+0x78/0x90)! [<c03ddea0>] (of_find_matching_node_and_match+0x78/0x90) from [<c06d349c>] (omap_get_timer_dt+0x78/0x90)! [<c06d349c>] (omap_get_timer_dt+0x78/0x90) from [<c06d3664>] (omap_dm_timer_init_one.clone.2+0x34/0x2bc)! [<c06d3664>] (omap_dm_timer_init_one.clone.2+0x34/0x2bc) from [<c06d3a2c>] (omap2_gptimer_clocksource_init.clone.4+0x24/0xa8)! [<c06d3a2c>] (omap2_gptimer_clocksource_init.clone.4+0x24/0xa8) from [<c06cca58>] (time_init+0x20/0x30)! [<c06cca58>] (time_init+0x20/0x30) from [<c06c9690>] (start_kernel+0x1a8/0x2fc)! Signed-off-by: NPantelis Antoniou <panto@antoniou-consulting.com> Acked-by: NJon Hunter <jon-hunter@ti.com> [tony@atomide.com: updated description per Jon] Signed-off-by: NTony Lindgren <tony@atomide.com>
-
- 15 1月, 2013 1 次提交
-
-
由 Shawn Guo 提交于
The clockevent core is able to figure out the best mult and shift, calculate min_delta_ns and max_delta_ns, with the necessary info passed into clockevents_config_and_register(). Use this combined configure and register function where possible to make the codes less error prone and gain some positive diff stat. Signed-off-by: NShawn Guo <shawn.guo@linaro.org> Cc: Nicolas Ferre <nicolas.ferre@atmel.com> Reviewed-by: NAnton Vorontsov <cbouatmailru@gmail.com> Acked-by: NKukjin Kim <kgene.kim@samsung.com> Cc: Russell King <linux@arm.linux.org.uk> Cc: Sascha Hauer <s.hauer@pengutronix.de> Cc: Jason Cooper <jason@lakedaemon.net> Tested-by: NRoland Stigge <stigge@antcom.de> Acked-by: NEric Miao <eric.y.miao@gmail.com> Cc: Haojian Zhuang <haojian.zhuang@gmail.com> Cc: David Brown <davidb@codeaurora.org> Tested-by: NTony Lindgren <tony@atomide.com> Acked-by: NBarry Song <baohua.song@csr.com> Tested-by: NStephen Warren <swarren@nvidia.com> Acked-by: NTony Prisk <linux@prisktech.co.nz> Cc: Lennert Buytenhek <buytenh@wantstofly.org> Cc: Wan ZongShun <mcuos.com@gmail.com> Acked-by: NViresh Kumar <viresh.kumar@linaro.org> Acked-by: NArnd Bergmann <arnd@arndb.de> Acked-by: NJason Cooper <jason@lakedaemon.net> Reviewed-by: NThomas Gleixner <tglx@linutronix.de> Signed-off-by: NOlof Johansson <olof@lixom.net>
-
- 12 1月, 2013 1 次提交
-
-
由 Tony Lindgren 提交于
This way the initcalls don't run on other SoCs on multiplatform kernels. Otherwise we'll get something like this when booting on vexpress: omap_hwmod: _ensure_mpu_hwmod_is_setup: MPU initiator hwmod mpu not yet registered ... WARNING: at arch/arm/mach-omap2/pm.c:82 _init_omap_device+0x74/0x94() _init_omap_device: could not find omap_hwmod for mpu ... omap-dma-engine omap-dma-engine: OMAP DMA engine driver ... Tested-by: NEzequiel Garcia <ezequiel.garcia@free-electrons.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
- 25 12月, 2012 1 次提交
-
-
由 Stephen Warren 提交于
Now that the only field in struct sys_timer is .init, delete the struct, and replace the machine descriptor .timer field with the initialization function itself. This will enable moving timer drivers into drivers/clocksource without having to place a public prototype of each struct sys_timer object into include/linux; the intent is to create a single of_clocksource_init() function that determines which timer driver to initialize by scanning the device dtree, much like the proposed irqchip_init() at: http://www.spinics.net/lists/arm-kernel/msg203686.html Includes mach-omap2 fixes from Igor Grinberg. Tested-by: NRobert Jarzmik <robert.jarzmik@free.fr> Signed-off-by: NStephen Warren <swarren@nvidia.com>
-
- 21 12月, 2012 1 次提交
-
-
由 Peter Ujfalusi 提交于
prom_add_property() has been renamed to of_add_property() This patch fixes the following comilation error: arch/arm/mach-omap2/timer.c: In function ‘omap_get_timer_dt’: arch/arm/mach-omap2/timer.c:178:3: error: implicit declaration of function ‘prom_add_property’ [-Werror=implicit-function-declaration] cc1: some warnings being treated as errors make[1]: *** [arch/arm/mach-omap2/timer.o] Error 1 make[1]: *** Waiting for unfinished jobs.... Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: NTony Lindgren <tony@atomide.com> Signed-off-by: NOlof Johansson <olof@lixom.net>
-
- 15 12月, 2012 2 次提交
-
-
由 Vaibhav Hiremath 提交于
Sparse generates the following warnings when compiling mach-omap2/timer.c. CHECK arch/arm/mach-omap2/timer.c arch/arm/mach-omap2/timer.c:193:13: warning: symbol 'omap_dmtimer_init' was not declared. Should it be static? arch/arm/mach-omap2/timer.c:213:12: warning: symbol 'omap_dm_timer_get_errata' was not declared. Should it be static? Add static to function declaration to fix warnings. Signed-off-by: NVaibhav Hiremath <hvaibhav@ti.com> Signed-off-by: NJon Hunter <jon-hunter@ti.com>
-
由 Jon Hunter 提交于
When compiling the kernel with configuration options ... # CONFIG_ARCH_OMAP2 is not set # CONFIG_ARCH_OMAP3 is not set # CONFIG_ARCH_OMAP4 is not set # CONFIG_SOC_OMAP5 is not set CONFIG_SOC_AM33XX=y ... the following build warning is seen. CC arch/arm/mach-omap2/timer.o arch/arm/mach-omap2/timer.c:395:19: warning: ‘omap2_sync32k_clocksource_init’ defined but not used [-Wunused-function] This issue was introduced by commit 6f80b3bb (ARM: OMAP2+: timer: remove CONFIG_OMAP_32K_TIMER) where the omap2_sync32k_clocksource_init() is no longer referenced by the timer initialisation function for the AM335x device as it has no 32k-sync timer. Fix this by adding the "__maybe_unused" compiler directive to the omap2_sync32k_clocksource_init() function to indicate that this function may be used for certain configurations. Cc: Igor Grinberg <grinberg@compulab.co.il> Signed-off-by: NJon Hunter <jon-hunter@ti.com>
-
- 30 11月, 2012 1 次提交
-
-
由 Olof Johansson 提交于
Fix 32 vs 32k typo: arch/arm/mach-omap2/timer.c: In function 'omap4_local_timer_init': arch/arm/mach-omap2/timer.c:633:2: error: implicit declaration of function 'omap4_sync32_timer_init' [-Werror=implicit-function-declaration] arch/arm/mach-omap2/timer.c: At top level: arch/arm/mach-omap2/timer.c:610:2: warning: 'omap4_sync32k_timer_init' defined but not used [-Wunused-function] Also, mark the omap4_local_timer_init() stub as __init (and take off the explicit inline and let the compiler do the work instead). Signed-off-by: NOlof Johansson <olof@lixom.net> Cc: Tony Lindgren <tony@atomide.com> Cc: Igor Grinberg <grinberg@compulab.co.il>
-
- 22 11月, 2012 2 次提交
-
-
由 Igor Grinberg 提交于
cm-t3517 starting from revision 1.2 does not have the 32K oscilator wired to the AM3517 SoC. Therefore switch to use the GPTIMER for system clock. Signed-off-by: NIgor Grinberg <grinberg@compulab.co.il> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Igor Grinberg 提交于
CONFIG_OMAP_32K_TIMER is kind of standing on the single zImage way. Make OMAP2+ timer code independant from the CONFIG_OMAP_32K_TIMER setting. To remove the dependancy, several conversions/additions had to be done: 1) Timer initialization functions are named by the platform name and the clock source in use. This also makes it possible to define and use the GPTIMER as the clock source instead of the 32K timer on platforms that do not have the 32K timer ip block or the 32K timer is not wired on the board. Currently, the the timer is chosen in the machine_desc structure on per board basis. Later, DT should be used to choose the timer. 2) Settings under the CONFIG_OMAP_32K_TIMER option are used as defaults and those under !CONFIG_OMAP_32K_TIMER are removed. This removes the CONFIG_OMAP_32K_TIMER on OMAP2+ timer code. 3) Since we have all the timers defined inside machine_desc structure and we no longer need the fallback to gp_timer clock source in case 32k_timer clock source is unavailable (namely on AM33xx), we no longer need the #ifdef around omap2_sync32k_clocksource_init() function. Remove the #ifdef CONFIG_OMAP_32K_TIMER around the omap2_sync32k_clocksource_init() function. Signed-off-by: NIgor Grinberg <grinberg@compulab.co.il> Cc: Jon Hunter <jon-hunter@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Vaibhav Hiremath <hvaibhav@ti.com> Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com> Reviewed-by: NJon Hunter <jon-hunter@ti.com>
-
- 17 11月, 2012 4 次提交
-
-
由 Jon Hunter 提交于
Commit "ARM: OMAP2+: Add device-tree support for 32kHz counter" added structure omap_counter_match to the OMAP2 timer code. When CONFIG_OMAP_32K_TIMER is not defined this structure generates the following as it is not used. CC arch/arm/mach-omap2/timer.o arch/arm/mach-omap2/timer.c:163:28: warning: 'omap_counter_match' defined but not used [-Wunused-variable] Move the definition of omap_counter_match to avoid this warning when CONFIG_OMAP_32K_TIMER is not set. Thanks to Kevin Hilman for tracking down and reporting this problem. Reported-by: NKevin Hilam <khilman@deeprootsystems.com> Signed-off-by: NJon Hunter <jon-hunter@ti.com>
-
由 Jon Hunter 提交于
Move definition of dmtimer platform data structure in to its own header under <linux/platform_data>. Signed-off-by: NJon Hunter <jon-hunter@ti.com>
-
由 Jon Hunter 提交于
The function omap_dm_timer_init_one() declares two local variables of type int that are used to store the return value of functions called. One such local variable is sufficient and so remove one of these local variables. Signed-off-by: NJon Hunter <jon-hunter@ti.com>
-
由 Jon Hunter 提交于
The OMAP2+ system timer code stores the physical address of the timer but never uses it. Remove this and clean-up the code by removing the local variable "size" and changing the names of the local variables mem_rsrc and irq_rsrc to mem and irq, respectively. Signed-off-by: NJon Hunter <jon-hunter@ti.com>
-
- 13 11月, 2012 4 次提交
-
-
由 Jon Hunter 提交于
The __omap_dm_timer_set_source() function is only used by the system timer (clock-events and clock-source) code for OMAP2+ devices. Therefore, we can remove this code from the dmtimer driver and move it to the system timer code for OMAP2+ devices. The current __omap_dm_timer_set_source() function calls clk_disable() before calling clk_set_parent() and clk_enable() afterwards. We can avoid these calls to clk_disable/enable by moving the calls to omap_hwmod_setup_one() and omap_hwmod_enable() to after the call to clk_set_parent() in omap_dm_timer_init_one(). The function omap_hwmod_setup_one() will enable the timers functional clock and therefore increment the use-count of the functional clock to 1. clk_set_parent() will fail if the use-count is not 0 when called. Hence, if omap_hwmod_setup_one() is called before clk_set_parent(), we will need to call clk_disable() before calling clk_set_parent() to decrement the use-count. Hence, avoid these extra calls to disable and enable the functional clock by moving the calls to omap_hwmod_setup_one() and omap_hwmod_enable() to after clk_set_parent(). We can also remove the delay from the __omap_dm_timer_set_source() function because enabling the clock will now be handled via the HWMOD framework by calling omap_hwmod_setup_one(). Therefore, by moving the calls to omap_hwmod_setup_one() and omap_hwmod_enable() to after the call to clk_set_parent(), we can simply replace __omap_dm_timer_set_source() with clk_set_parent(). It should be safe to move these hwmod calls to later in the omap_dm_timer_init_one() because other calls to the hwmod layer that occur before are just requesting resource information. Testing includes boot testing on OMAP2420 H4, OMAP3430 SDP and OMAP4430 Blaze with the following configurations: 1. CONFIG_OMAP_32K_TIMER=y 2. CONFIG_OMAP_32K_TIMER=y and boot parameter "clocksource=gp_timer" 3. CONFIG_OMAP_32K_TIMER not set 4. CONFIG_OMAP_32K_TIMER not set and boot parameter "clocksource=gp_timer" Signed-off-by: NJon Hunter <jon-hunter@ti.com> Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
-
由 Jon Hunter 提交于
Currently OMAP2+ devices are using the function __omap_dm_timer_reset() to configure the clock-activity, idle, wakeup-enable and auto-idle fields in the timer OCP_CFG register. The name of the function is mis-leading because this function does not actually perform a reset of the timer. For OMAP2+ devices, HWMOD is responsible for reseting and configuring the timer OCP_CFG register. Therefore, do not use __omap_dm_timer_reset() for OMAP2+ devices and rely on HWMOD. Furthermore, some timer instances do not have the fields clock-activity, wakeup-enable and auto-idle and so this function could configure the OCP_CFG register incorrectly. Currently HWMOD is not configuring the clock-activity field in the OCP_CFG register for timers that have this field. Commit 0f0d0807 (ARM: OMAP: DMTimer: Use posted mode) configures the clock-activity field to keep the f-clk enabled so that the wake-up capability is enabled. Therefore, add the appropriate flags to the timer HWMOD structures to configure this field in the same way. For OMAP2/3 devices all dmtimers have the clock-activity field, where as for OMAP4 devices, only dmtimer 1, 2 and 10 have the clock-activity field. Verified on OMAP2420 H4, OMAP3430 Beagle and OMAP4430 Panda that HWMOD is configuring the dmtimer OCP_CFG register as expected for clock-events timer. Signed-off-by: NJon Hunter <jon-hunter@ti.com> Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
-
由 Jon Hunter 提交于
Errata Titles: i103: Delay needed to read some GP timer, WD timer and sync timer registers after wakeup (OMAP3/4) i767: Delay needed to read some GP timer registers after wakeup (OMAP5) Description (i103/i767): If a General Purpose Timer (GPTimer) is in posted mode (TSICR [2].POSTED=1), due to internal resynchronizations, values read in TCRR, TCAR1 and TCAR2 registers right after the timer interface clock (L4) goes from stopped to active may not return the expected values. The most common event leading to this situation occurs upon wake up from idle. GPTimer non-posted synchronization mode is not impacted by this limitation. Workarounds: 1). Disable posted mode 2). Use static dependency between timer clock domain and MPUSS clock domain 3). Use no-idle mode when the timer is active Workarounds #2 and #3 are not pratical from a power standpoint and so workaround #1 has been implemented. Disabling posted mode adds some CPU overhead for configuring and reading the timers as the CPU has to wait for accesses to be re-synchronised within the timer. However, disabling posted mode guarantees correct operation. Please note that it is safe to use posted mode for timers if the counter (TCRR) and capture (TCARx) registers will never be read. An example of this is the clock-event system timer. This is used by the kernel to schedule events however, the timers counter is never read and capture registers are not used. Given that the kernel configures this timer often yet never reads the counter register it is safe to enable posted mode in this case. Hence, for the timer used for kernel clock-events, posted mode is enabled by overriding the errata for devices that are impacted by this defect. For drivers using the timers that do not read the counter or capture registers and wish to use posted mode, can override the errata and enable posted mode by making the following function calls. __omap_dm_timer_override_errata(timer, OMAP_TIMER_ERRATA_I103_I767); __omap_dm_timer_enable_posted(timer); Both dmtimers and watchdogs are impacted by this defect this patch only implements the workaround for the dmtimer. Currently the watchdog driver does not read the counter register and so no workaround is necessary. Posted mode will be disabled for all OMAP2+ devices (including AM33xx) using a GP timer as a clock-source timer to guarantee correct operation. This is not necessary for OMAP24xx devices but the default clock-source timer for OMAP24xx devices is the 32k-sync timer and not the GP timer and so should not have any impact. This should be re-visited for future devices if this errata is fixed. Confirmed with Vaibhav Hiremath that this bug also impacts AM33xx devices. Signed-off-by: NJon Hunter <jon-hunter@ti.com> Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
-
由 Jon Hunter 提交于
For OMAP2+ devices, when using DMTIMERs for system timers (clock-events and clock-source) the posted mode configuration of the timers is used. To allow the compiler to optimise the functions for configuring and reading the system timers, the posted flag variable is hard-coded with the value 1. To make it clear that posted mode is being used add some definitions so that it is more readable. Signed-off-by: NJon Hunter <jon-hunter@ti.com> Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
-
- 03 11月, 2012 3 次提交
-
-
由 Jon Hunter 提交于
For OMAP devices, the 32kHz counter is the default clock-source for the kernel. However, this is not the only possible clock-source the kernel can use for OMAP devices. When booting with device-tree, if the 32kHz counter is the desired clock-source for the kernel, then parse the device-tree blob to ensure that the counter is present and if so map memory for the counter using the device-tree of_iomap() function so we are no longer reliant on the OMAP HWMOD framework to do this for us. Signed-off-by: NJon Hunter <jon-hunter@ti.com>
-
由 Jon Hunter 提交于
In order to add device-tree support to the timer driver the following changes were made ... 1. Allocate system timers (used for clock-events and clock-source) based upon timer properties rather than using an hard-coded timer instance ID. To allow this a new helper function called omap_dmtimer_find_by_property() has been added for finding a timer with the particular properties in the device-tree blob. Please note that this is an internal helper function for system timers only to find a timer in the device-tree blob. This cannot be used by device drivers, another API has been added for that (see below). Timers that are allocated for system timers are dynamically disabled at boot time by adding a status property with the value "disabled" to the timer's device-tree node. Please note that when allocating system timers we now pass a timer ID and timer property. The timer ID is only be used for allocating a timer when booting without device-tree. Once device-tree migration is complete, all the timer ID references will be removed. 2. System timer resources (memory and interrupts) are directly obtained from the device-tree timer node when booting with device-tree, so that system timers are no longer reliant upon the OMAP HWMOD framework to provide these resources. 3. If DT blob is present, then let device-tree create the timer devices dynamically. 4. When device-tree is present the "id" field in the platform_device structure (pdev->id) is initialised to -1 and hence cannot be used to identify a timer instance. Due to this the following changes were made ... a). The API omap_dm_timer_request_specific() is not supported when using device-tree, because it uses the device ID to request a specific timer. This function will return an error if called when device-tree is present. Users of this API should use omap_dm_timer_request_by_cap() instead. b). When removing the DMTIMER driver, the timer "id" was used to identify the timer instance. The remove function has been modified to use the device name instead of the "id". 5. When device-tree is present the platform_data structure will be NULL and so check for this. 6. The OMAP timer device tree binding has the following optional parameters ... a). ti,timer-alwon --> Timer is in an always-on power domain b). ti,timer-dsp --> Timer can generate an interrupt to the on-chip DSP c). ti,timer-pwm --> Timer can generate a PWM output d). ti,timer-secure --> Timer is reserved on a secure OMAP device Search for the above parameters and set the appropriate timer attribute flags. Signed-off-by: NJon Hunter <jon-hunter@ti.com>
-
由 Jon Hunter 提交于
OMAP3 devices may or may not have security features enabled. Security enabled devices are known as high-secure (HS) and devices without security are known as general purpose (GP). For OMAP3 devices there are 12 general purpose timers available. On secure devices the 12th timer is reserved for secure usage and so cannot be used by the kernel, where as for a GP device it is available. We can detect the OMAP device type, secure or GP, at runtime via an on-chip register. Today, when not using DT, we do not register the 12th timer as a linux device if the device is secure. When using device tree, device tree is going to register all the timer devices it finds in the device tree blob. To prevent device tree from registering 12th timer on a secure OMAP3 device we can add a status property to the timer binding with the value "disabled" at boot time. Note that timer 12 on a OMAP3 device has a property "ti,timer-secure" to indicate that it will not be available on a secure device and so for secure OMAP3 devices, we search for timers with this property and then disable them. Using the prom_add_property() function to dynamically add a property was a recommended approach suggested by Rob Herring [1]. I have tested this on an OMAP3 GP device and faking it to pretend to be a secure device to ensure that any timers marked with "ti,timer-secure" are not registered on boot. I have also made sure that all timers are registered as expected on a GP device by default. [1] http://comments.gmane.org/gmane.linux.ports.arm.omap/79203Signed-off-by: NJon Hunter <jon-hunter@ti.com>
-