summaryrefslogtreecommitdiffstats
path: root/arch/arm/mach-omap2/timer.c
Commit message (Collapse)AuthorAgeFilesLines
* ARM: OMAP2+: Fix compillation error in mach-omap2/timer.cPeter Ujfalusi2012-12-201-1/+1
| | | | | | | | | | | | | | | 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: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Olof Johansson <olof@lixom.net>
* ARM: OMAP2+: Fix sparse warnings in timer.cVaibhav Hiremath2012-12-141-2/+2
| | | | | | | | | | | | | | | 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: Vaibhav Hiremath <hvaibhav@ti.com> Signed-off-by: Jon Hunter <jon-hunter@ti.com>
* ARM: AM335x: Fix warning in timer.cJon Hunter2012-12-141-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 6f80b3b (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: Jon Hunter <jon-hunter@ti.com>
* ARM: omap: fix typo on timer cleanupOlof Johansson2012-11-291-2/+2
| | | | | | | | | | | | | | | | 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: Olof Johansson <olof@lixom.net> Cc: Tony Lindgren <tony@atomide.com> Cc: Igor Grinberg <grinberg@compulab.co.il>
* ARM: OMAP3: cm-t3517: use GPTIMER for system clockIgor Grinberg2012-11-211-0/+3
| | | | | | | | | 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: Igor Grinberg <grinberg@compulab.co.il> Signed-off-by: Tony Lindgren <tony@atomide.com>
* ARM: OMAP2+: timer: remove CONFIG_OMAP_32K_TIMERIgor Grinberg2012-11-211-76/+52
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Igor 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: Santosh Shilimkar <santosh.shilimkar@ti.com> Reviewed-by: Jon Hunter <jon-hunter@ti.com>
* ARM: OMAP2+: Fix compiler warning for 32k timerJon Hunter2012-11-161-5/+5
| | | | | | | | | | | | | | | | | | | 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: Kevin Hilam <khilman@deeprootsystems.com> Signed-off-by: Jon Hunter <jon-hunter@ti.com>
* ARM: OMAP: Add platform data header for DMTIMERsJon Hunter2012-11-161-0/+2
| | | | | | | 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>
* ARM: OMAP2+: Remove unnecessary local variable in timer codeJon Hunter2012-11-161-6/+5
| | | | | | | | | 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: Jon Hunter <jon-hunter@ti.com>
* ARM: OMAP: Don't store timers physical addressJon Hunter2012-11-161-8/+5
| | | | | | | | | 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: Jon Hunter <jon-hunter@ti.com>
* ARM: OMAP: Remove __omap_dm_timer_set_source functionJon Hunter2012-11-121-5/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* ARM: OMAP2+: Don't use __omap_dm_timer_reset()Jon Hunter2012-11-121-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 0f0d080 (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: Jon Hunter <jon-hunter@ti.com> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
* ARM: OMAP3+: Implement timer workaround for errata i103 and i767Jon Hunter2012-11-121-8/+41
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* ARM: OMAP: Add DMTIMER definitions for posted modeJon Hunter2012-11-121-7/+10
| | | | | | | | | | | | 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: Jon Hunter <jon-hunter@ti.com> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
* Merge branch 'omap-for-v3.8/cleanup-headers-prepare-multiplatform-v3' into ↵Tony Lindgren2012-11-091-3/+6
|\ | | | | | | | | | | | | | | | | omap-for-v3.8/dt Conflicts: arch/arm/plat-omap/dmtimer.c Resolved as suggested by Jon Hunter.
| * ARM: OMAP: Remove plat-omap/common.hTony Lindgren2012-10-311-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Most of the prototypes in plat-omap/common.h are not common to omap1 and omap2+, they are local to omap2+ and should not be in plat-omap/common.h. The only shared function prototype in this file is omap_init_clocksource_32k(), let's put that into counter-32k.h. Note that the new plat/counter-32k.h must not be included from drivers, that will break omap2+ build for CONFIG_MULTIPLATFORM. Signed-off-by: Tony Lindgren <tony@atomide.com>
| * ARM: OMAP: Move omap-pm-noop.c local to mach-omap2Tony Lindgren2012-10-311-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * Merge tag 'omap-for-v3.8/cleanup-headers-signed' into ↵Tony Lindgren2012-10-241-3/+3
| |\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | omap-for-v3.8/cleanup-headers-serial-take2 This is the first set of omap cleanup patches for v3.8 merge window to remove most of the remaining plat includes to get us closer to ARM common zImage support. To avoid a huge amount of trivial merge conflicts with includes, this branch is based on several small topic branches coordinated with the driver subsystem maintainers. These branches are based on v3.7-rc1 and can also be merged into the related driver subsystem branches as needed: omap-for-v3.8/cleanup-headers-prepare few trivial driver changes omap-for-v3.8/cleanup-headers-dma move of the DMA header omap-for-v3.8/cleanup-headers-gpmc GPMC and MTD changes omap-for-v3.8/cleanup-headers-mmc MMC related changes omap-for-v3.8/cleanup-headers-dss DSS related changes omap-for-v3.8/cleanup-headers-asoc ASoC related changes Note that for the dma-omap.h, it was decided that it should be is completed. For the related discussion, please see: https://patchwork.kernel.org/patch/1519591/# After these patches we still have a few plat headers remaining that will be handled in later pull requests.
| | * ARM: OMAP: Make plat/omap-pm.h local to mach-omap2Tony Lindgren2012-10-181-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| | * ARM: OMAP: Make plat/omap_hwmod.h local to mach-omap2Tony Lindgren2012-10-181-1/+1
| | | | | | | | | | | | | | | | | | | | | Let's make omap_hwmod local to mach-omap2 for ARM common zImage support. Signed-off-by: Tony Lindgren <tony@atomide.com>
| | * ARM: OMAP: Make omap_device local to mach-omap2Tony Lindgren2012-10-171-1/+1
| | | | | | | | | | | | | | | | | | | | | Let's make omap_device local to mach-omap2 for ARM common zImage support. Signed-off-by: Tony Lindgren <tony@atomide.com>
* | | ARM: OMAP2+: Add device-tree support for 32kHz counterJon Hunter2012-11-021-1/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Jon Hunter <jon-hunter@ti.com>
* | | ARM: OMAP: Add DT support for timer driverJon Hunter2012-11-021-36/+111
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | | ARM: OMAP3: Dynamically disable secure timer nodes for secure devicesJon Hunter2012-11-021-0/+36
|/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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/79203 Signed-off-by: Jon Hunter <jon-hunter@ti.com>
* / ARM: OMAP4: Fix twd_local_timer_register regressionTony Lindgren2012-10-161-1/+1
|/ | | | | | | | | | | | | | | | | | Commit 7d7e1eba (ARM: OMAP2+: Prepare for irqs.h removal) changed the interrupts to allow enabling sparse IRQ, but accidentally added the omap3 INTC base to the local IRQ. This causes the following: twd: can't register interrupt 45 (-22) twd_local_timer_register failed -22 The right fix is to not add any base, as it is a local timer. For the OMAP44XX_IRQ_LOCALWDT we had defined earlier there are no users, so no need to fix that. Reported-by: Russell King <rmk+kernel@arm.linux.org.uk> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
* ARM: OMAP: fix return value check in realtime_counter_init()Wei Yongjun2012-10-081-1/+1
| | | | | | | | | | | | In case of error, the function clk_get() returns ERR_PTR() and never returns NULL. The NULL test in the return value check should be replaced with IS_ERR(). dpatch engine is used to auto generate this patch. (https://github.com/weiyj/dpatch) Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn> Signed-off-by: Tony Lindgren <tony@atomide.com>
* Merge tag 'dt' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-socLinus Torvalds2012-10-011-1/+102
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Pull ARM soc device tree updates from Olof Johansson: "Device tree conversion and enablement branch. Mostly a bunch of new bindings and setup for various platforms, but the Via/Winchip VT8500 platform is also converted over from being 100% legacy to now use device tree for probing. More of that will come for 3.8." Trivial conflicts due to removal of vt8500 files, and one documentation file that was added with slightly different contents both here and in the USb tree. * tag 'dt' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (212 commits) arm: vt8500: Fixup for missing gpio.h ARM: LPC32xx: LED fix in PHY3250 DTS file ARM: dt: mmp-dma: add binding file arm: vt8500: Update arch-vt8500 to devicetree support. arm: vt8500: gpio: Devicetree support for arch-vt8500 arm: vt8500: doc: Add device tree bindings for arch-vt8500 devices arm: vt8500: clk: Add Common Clock Framework support video: vt8500: Add devicetree support for vt8500-fb and wm8505-fb serial: vt8500: Add devicetree support for vt8500-serial rtc: vt8500: Add devicetree support for vt8500-rtc arm: vt8500: Add device tree files for VIA/Wondermedia SoC's ARM: tegra: Add Avionic Design Tamonten Evaluation Carrier support ARM: tegra: Add Avionic Design Medcom-Wide support ARM: tegra: Add Avionic Design Plutux support ARM: tegra: Add Avionic Design Tamonten support ARM: tegra: dts: Add pwm label ARM: ux500: Fix SSP register address format ARM: ux500: Apply tc3589x's GPIO/IRQ properties to HREF's DT ARM: ux500: Remove redundant #gpio-cell properties from Snowball DT ARM: ux500: Add all encompassing sound node to the HREF Device Tree ...
| * Merge branch 'for_3.7/omap5_arch_timer' of ↵Tony Lindgren2012-09-211-1/+103
| |\ | | | | | | | | | | | | | | | | | | git://github.com/SantoshShilimkar/linux into devel-dt-arch-timer Conflicts: arch/arm/mach-omap2/timer.c
| | * ARM: OMAP5: Enable arch timer supportSantosh Shilimkar2012-09-191-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | Enable Cortex A15 generic timer support for OMAP5 based SOCs. The CPU local timers run on the free running real time counter clock. Acked-by: Benoit Cousson <b-cousson@ti.com> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
| | * ARM: OMAP: Add initialisation for the real-time counter.Santosh Shilimkar2012-09-191-1/+89
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The real time counter also called master counter, is a free-running counter. It produces the count used by the CPU local timer peripherals in the MPU cluster. The timer counts at a rate of 6.144 MHz. The ratio registers needs to be configured based on system clock only onetime. After initialisation, hardware takes care of adjusting the clock in different low power modes to keep counter rate constant. Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
| * | Merge tag 'omap-cleanup-sparseirq-for-v3.7' into devel-dtTony Lindgren2012-09-161-4/+5
| |\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This branch contains changes needed to make omap2+ work properly with sparse IRQ. It also removes dependencies to mach/hardware.h. These help moving things towards ARM single zImage support. This branch is based on a commit in tty-next branch with omap-devel-gpmc-fixed-for-v3.7 and cleanup-omap-tags-for-v3.7 merged in to keep things compiling and sort out some merge conflicts. Conflicts: arch/arm/mach-omap2/omap4-common.c drivers/gpio/gpio-twl4030.c
| * | | ARM: OMAP4: Add local timer support for Device TreeSantosh Shilimkar2012-09-071-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add cortex-a9 local timer support for all OMAP4 based SOCs using DT. Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Acked-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Benoit Cousson <b-cousson@ti.com>
* | | | Merge tag 'tegra-for-3.7-dmaengine' of ↵Olof Johansson2012-09-201-0/+7
|\ \ \ \ | | |_|/ | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/swarren/linux-tegra into next/cleanup ARM: tegra: switch to dmaengine The Tegra code-base has contained both a legacy DMA and a dmaengine driver since v3.6-rcX. This series flips Tegra's defconfig to enable dmaengine rather than the legacy driver, and removes the legacy driver and all client code. * tag 'tegra-for-3.7-dmaengine' of git://git.kernel.org/pub/scm/linux/kernel/git/swarren/linux-tegra: ASoC: tegra: remove support of legacy DMA driver based access spi: tegra: remove support of legacy DMA driver based access ARM: tegra: apbio: remove support of legacy DMA driver based access ARM: tegra: dma: remove legacy APB DMA driver ARM: tegra: config: enable dmaengine based APB DMA driver + sync to 3.6-rc6
| * | | ARM: OMAP: timer: obey the !CONFIG_OMAP_32K_TIMERIgor Grinberg2012-08-301-0/+7
| |/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, omap2_sync32k_clocksource_init() function initializes the 32K timer as the system clock source regardless of the CONFIG_OMAP_32K_TIMER setting. Fix this by providing a default implementation for !CONFIG_OMAP_32K_TIMER case. Signed-off-by: Igor Grinberg <grinberg@compulab.co.il> Reviewed-by: Paul Walmsley <paul@pwsan.com> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: stable@vger.kernel.org Signed-off-by: Tony Lindgren <tony@atomide.com>
* | | Merge tag 'omap-cleanup-b-for-3.7' of ↵Tony Lindgren2012-09-121-1/+1
|\ \ \ | |_|/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending into cleanup-makefile-sparse smatch and string-wrapping cleanups for the OMAP subarch code. These changes fix some of the more meaningful warnings that smatch returns for the OMAP subarch code, and unwraps strings that are wrapped at the 80-column boundary, to conform with the current practice. Basic build, boot, and PM logs are available here: http://www.pwsan.com/omap/testlogs/warnings_a_cleanup_3.7/20120912025927/
| * | ARM: OMAP: clean up some smatch warnings, fix some printk(KERN_ERR ...Paul Walmsley2012-09-121-1/+1
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Resolve the following warnings from smatch: arch/arm/mach-omap2/gpmc.c:282 gpmc_cs_set_timings() info: why not propagate 'div' from gpmc_cs_calc_divider() instead of -1? arch/arm/mach-omap2/serial.c:328 omap_serial_init_port() error: 'pdev' dereferencing possible ERR_PTR() arch/arm/mach-omap2/timer.c:213 omap2_gp_clockevent_init() Error invalid range 4096 to -1 arch/arm/mach-omap2/gpio.c:63 omap2_gpio_dev_init() warn: possible memory leak of 'pdata' arch/arm/mach-omap2/omap_hwmod.c:1478 _assert_hardreset() warn: assigning -22 to unsigned variable 'ret' arch/arm/mach-omap2/omap_hwmod.c:1487 _assert_hardreset() warn: 4294963201 is more than 255 (max '(ret)' can be) so this is always the same. arch/arm/mach-omap2/omap_hwmod.c:1545 _read_hardreset() warn: assigning -22 to unsigned variable 'ret' arch/arm/mach-omap2/omap_hwmod.c:1554 _read_hardreset() warn: 4294963201 is more than 255 (max '(ret)' can be) so this is always the same. arch/arm/mach-omap2/dpll3xxx.c:629 omap3_clkoutx2_recalc() error: we previously assumed 'pclk' could be null (see line 627) arch/arm/mach-omap2/board-n8x0.c:422 n8x0_mmc_late_init() Error invalid range 14 to 13 arch/arm/mach-omap1/leds-h2p2-debug.c:71 h2p2_dbg_leds_event() error: potentially derefencing uninitialized 'fpga'. arch/arm/plat-omap/mux.c:79 omap_cfg_reg() Error invalid range 4096 to -1 Thanks to Tony Lindgren <tony@atomide.com> for pointing out that BUG() can be disabled. The changes in the first version that removed the subsequent return() after BUG() states have been dropped. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Tony Lindgren <tony@atomide.com>
* | ARM: OMAP: Split plat/hardware.h, use local soc.h for omap2+Tony Lindgren2012-09-121-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As the plat and mach includes need to disappear for single zImage work, we need to remove plat/hardware.h. Do this by splitting plat/hardware.h into omap1 and omap2+ specific files. The old plat/hardware.h already has omap1 only defines, so it gets moved to mach/hardware.h for omap1. For omap2+, we use the local soc.h that for now just includes the related SoC headers to keep this patch more readable. Note that the local soc.h still includes plat/cpu.h that can be dealt with in later patches. Let's also include plat/serial.h from common.h for all the board-*.c files. This allows making the include files local later on without patching these files again. Note that only minimal changes are done in this patch for the drivers/watchdog/omap_wdt.c driver to keep things compiling. Further patches are needed to eventually remove cpu_is_omap usage in the drivers. Also only minimal changes are done to sound/soc/omap/* to remove the unneeded includes and to define OMAP44XX_MCPDM_L3_BASE locally so there's no need to include omap44xx.h. While at it, also sort some of the includes in the standard way. Cc: linux-watchdog@vger.kernel.org Cc: alsa-devel@alsa-project.org Cc: Peter Ujfalusi <peter.ujfalusi@ti.com> Cc: Jarkko Nikula <jarkko.nikula@bitmer.com> Cc: Liam Girdwood <lrg@ti.com> Acked-by: Wim Van Sebroeck <wim@iguana.be> Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
* | ARM: OMAP2+: Prepare for irqs.h removalTony Lindgren2012-09-121-4/+6
|/ | | | | | | | | | | | | | | | | | | | | | | As the interrupts should only be defined in the platform_data, and eventually coming from device tree, there's no need to define them in header files. Let's remove the hardcoded references to irqs.h and fix up the includes so we don't rely on headers included in irqs.h. Note that we're defining OMAP_INTC_START as 0 to the interrupts. This will be needed when we enable SPARSE_IRQ. For some drivers we need to add #include <plat/cpu.h> for now until these drivers are fixed to remove cpu_is_omapxxxx() usage. While at it, sort som of the includes the standard way, and add the trailing commas where they are missing in the related data structures. Note that for drivers/staging/tidspbridge we just define things locally. Cc: Paul Walmsley <paul@pwsan.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
* Merge tag 'pm2' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-socLinus Torvalds2012-08-021-1/+3
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Pull arm-soc cpuidle enablement for OMAP from Olof Johansson: "Coupled cpuidle was meant to merge for 3.5 through Len Brown's tree, but didn't go in because the pull request ended up rejected. So it just got merged, and we got this staged branch that enables the coupled cpuidle code on OMAP. With a stable git workflow from the other maintainer we could have staged this earlier, but that wasn't the case so we have had to merge it late. The alternative is to hold it off until 3.7 but given that the code is well-isolated to OMAP and they are eager to see it go in, I didn't push back hard in that direction." * tag 'pm2' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: ARM: OMAP4: CPUidle: Open broadcast clock-event device. ARM: OMAP4: CPUidle: add synchronization for coupled idle states ARM: OMAP4: CPUidle: Use coupled cpuidle states to implement SMP cpuidle. ARM: OMAP: timer: allow gp timer clock-event to be used on both cpus
| * ARM: OMAP: timer: allow gp timer clock-event to be used on both cpusSantosh Shilimkar2012-07-251-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | For coupled cpuidle to work when both cpus are active, it needs a global timer that can handle events for both cpus. This timer is used as the broadcast clock-event when the per-cpu timer hardware stop in low power states. Set the cpumask of clockevent_gpt to all cpus, set the rating correctly, and set the irq to allow the clockevent core to determine the affinity of the timer. Signed-off-by: Colin Cross <ccross@android.com> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Signed-off-by: Kevin Hilman <khilman@ti.com>
* | ARM: OMAP5: timer: Add clocksource, clockevent supportR Sricharan2012-07-091-0/+5
| | | | | | | | | | | | | | | | Adding the Initialisaton for clocksource and clockevent device on OMAP5 Socs. Signed-off-by: R Sricharan <r.sricharan@ti.com> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
* | ARM: OMAP2+: dmtimer: cleanup fclk usageTarun Kanti DebBarma2012-07-061-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With omap_hwmod_get_main_clk() now available, this can be passed to clk_get() to extract the fclk and thus avoid construction of fclk name. Corrected the timer fck name mis-match between clock44xx_data.c and omap_hwmod_44xx_data.c. For other platforms this is already taken care. 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>
| |
| \
*-. \ Merge tags 'omap-cleanup-for-v3.6', 'omap-devel-dmtimer-for-v3.6' and ↵Tony Lindgren2012-07-041-78/+9
|\ \ \ | |_|/ |/| | | | | 'omap-devel-am33xx-for-v3.6' into devel-am33xx-part2
| | * ARM: OMAP2+: am33xx: Add AM335XEVM machine supportAfzal Mohammed2012-06-051-0/+5
| |/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch adds minimal support for AM335X machine init. During last merge window, two separate patches supporting am33xx machine init had been submitted, 1. Link to earlier Baseport patch submission (Legacy): http://www.mail-archive.com/linux-omap@vger.kernel.org/msg59325.html 2. Link to earlier DT based machine init support patch submission: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg61398.html And both had got accepted at that time, but got missed during merge window. But now, since we have taken decision to make am33xx as a separate class and not to follow omap3 family, these patches needs to changes accordingly (only changes), - Combine both the patches, since early init and timer init used in board-generic.c file requires them. - Remove dependency on AM3517EVM, and only use DT approach for machine init. - Change the config option (as changed recently) CONFIG_SOC_OMAPAM33XX --> CONFIG_SOC_AM33XX Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com> Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Paul Walmsley <paul@pwsan.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
| * ARM: OMAP2+: Move dmtimer clock set function to dmtimer driverJon Hunter2012-06-141-55/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * ARM: OMAP: Remove timer function pointer for context loss counterJon Hunter2012-06-141-3/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * ARM: OMAP: Remove loses_context variable from timer platform dataJon Hunter2012-06-141-3/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * ARM: OMAP2+: Fix external clock support for dmtimersJon Hunter2012-06-141-10/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, the dmtimer determines whether an timer can support an external clock source (sys_altclk) for driving the timer by the IP version. Only OMAP24xx devices can support an external clock source, but the IP version between OMAP24xx and OMAP3xxx is common and so this incorrectly indicates that OMAP3 devices can use an external clock source. Rather than use the IP version, just let the clock framework handle this. If the "alt_ck" does not exist for a timer then the clock framework will fail to find the clock and hence will return an error. By doing this we can eliminate the "timer_ip_version" variable passed as part of the platform data and simplify the code. We can also remove the timer IP version from the HWMOD data because the dmtimer driver uses the TIDR register to determine the IP version. Signed-off-by: Jon Hunter <jon-hunter@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
| * ARM: OMAP: Add DMTIMER capability variable to represent timer featuresJon Hunter2012-06-141-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * ARM: OMAP2+: Add dmtimer platform function to reserve systimersJon Hunter2012-06-141-7/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
generated by cgit v1.2.3 (git 2.25.1) at 2024-12-12 08:02:16 +0000