summaryrefslogtreecommitdiff
path: root/arch/arm/plat-omap/include/plat/dmtimer.h
AgeCommit message (Collapse)AuthorFilesLines
2014-05-08ARM: OMAP: dmtimer: raw read and write endian fixVictor Kamensky1-8/+8
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-11-27ARM: OMAP2+: Disable POSTED mode for errata i103 and i767Joel Fernandes1-1/+4
Enabling of Posted mode is seen to cause problems on dmtimer modules on AM33xx (much like other OMAPs). Reference discussions on forums [1] [2]. Earlier patch solving this on other OMAPs [3]. For OMAP SoCs with this errata, the fix has been to not enable Posted mode. However, on some SoCs (atleast AM33xx) which carry this errata, Posted mode is enabled on reset. So we not only need to ignore enabling of the POSTED bit when the timer is requested, but also disable Posted mode if errata is present. [1] http://e2e.ti.com/support/arm/sitara_arm/f/791/t/285744.aspx [2] http://e2e.ti.com/support/arm/sitara_arm/f/791/t/270632.aspx [3] http://www.spinics.net/lists/linux-omap/msg81770.html Cc: stable@vgerk.kernel.org Reported-by: Russ Dill <russ.dill@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Signed-off-by: Joel Fernandes <joelf@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2013-04-09ARM: OMAP: Add function to request timer by nodeJon Hunter1-0/+1
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>
2012-11-16ARM: OMAP: Add platform data header for DMTIMERsJon Hunter1-8/+0
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: Remove unnecessary omap_dm_timer structure declarationJon Hunter1-27/+25
Remove unnecessary declaration of structure omap_dm_timer from dmtimer.h and move the actual declaration of structure omap_dm_timer towards top of dmtimer.h to avoid any compilation errors. Signed-off-by: Jon Hunter <jon-hunter@ti.com>
2012-11-16ARM: OMAP: Don't store timers physical addressJon Hunter1-1/+0
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>
2012-11-16ARM: OMAP: Define omap_dm_timer_prepare function as staticJon Hunter1-2/+0
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 Hunter1-23/+0
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-13ARM: OMAP: Remove __omap_dm_timer_set_source functionJon Hunter1-19/+0
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-13ARM: OMAP: Add dmtimer interrupt disable functionJon Hunter1-1/+2
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-13ARM: OMAP: Don't restore DMTIMER interrupt status registerJon Hunter1-1/+0
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-13ARM: OMAP: Don't restore of DMTIMER TISTAT registerJon Hunter1-1/+0
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-13ARM: OMAP3+: Implement timer workaround for errata i103 and i767Jon Hunter1-2/+50
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-13ARM: OMAP: Add DMTIMER definitions for posted modeJon Hunter1-0/+4
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>
2012-11-10Merge branch 'omap-for-v3.8/cleanup-headers-prepare-multiplatform-v3' into ↵Tony Lindgren1-0/+2
omap-for-v3.8/dt Conflicts: arch/arm/plat-omap/dmtimer.c Resolved as suggested by Jon Hunter.
2012-11-02ARM: OMAP: Add function to request a timer by capabilityJon Hunter1-0/+1
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-11-01ARM: OMAP: Move omap-pm-noop.c local to mach-omap2Tony Lindgren1-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>
2012-09-24ARM: OMAP: Add a timer attribute for timers that can interrupt the DSPJon Hunter1-0/+1
Some instances of the DMTIMER peripheral on OMAP devices have the ability to interrupt the on-chip DSP in addition to the ARM CPU. Add a DMTIMER attribute to indicate which timers can interrupt the DSP. By using the omap_dm_timer_request_by_cap() API, driver will now be able to allocate a DMTIMER that can interrupt the DSP based upon this attribute and not require the driver to know which instance has this capability. DMTIMERs that have the ability to interrupt the DSP on OMAP devices are as follows ... - OMAP1 (OMAP5912/16xx/17xx) devices - All 8 DMTIMERs - OMAP2/3/4 devices - DMTIMERs 5-8 Please note that for OMAP3+, timer8 has the ability to interrupt the DSP and generate a PWM output. Signed-off-by: Jon Hunter <jon-hunter@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
2012-06-14ARM: OMAP2+: Move dmtimer clock set function to dmtimer driverJon Hunter1-0/+1
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: OMAP: Add flag to indicate if a timer needs a manual resetJon Hunter1-1/+1
For OMAP1 devices, it is necessary to perform a manual reset of the timer. Currently, this is indicating by setting the "needs_manual_reset" variable in the platform data. Instead of using an extra variable to indicate this add a new timer capabilities flag to indicate this and remove the "needs_manual_reset" member from the platform data. Signed-off-by: Jon Hunter <jon-hunter@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2012-06-14ARM: OMAP: Remove timer function pointer for context loss counterJon Hunter1-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>
2012-06-14ARM: OMAP: Remove loses_context variable from timer platform dataJon Hunter1-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>
2012-06-14ARM: OMAP2+: Fix external clock support for dmtimersJon Hunter1-7/+0
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>
2012-06-14ARM: OMAP: Add DMTIMER capability variable to represent timer featuresJon Hunter1-0/+2
Although the OMAP timers share a common hardware design, there are some differences between the timer instances in a given device. For example, a timer maybe in a power domain that can be powered-of, so can lose its logic state and need restoring where as another may be in power domain that is always be on. Another example, is a timer may support different clock sources to drive the timer. This information is passed to the dmtimer via the following platform data structure. struct dmtimer_platform_data { int (*set_timer_src)(struct platform_device *pdev, int source); int timer_ip_version; u32 needs_manual_reset:1; bool loses_context; int (*get_context_loss_count)(struct device *dev); }; The above structure uses multiple variables to represent the timer features. HWMOD also stores the timer capabilities using a bit-mask that represents the features supported. By using the same format for representing the timer features in the platform data as used by HWMOD, we can ... 1. Use the flags defined in the plat/dmtimer.h to represent the features supported. 2. For devices using HWMOD, we can retrieve the features supported from HWMOD. 3. Eventually, simplify the platform data structure to be ... struct dmtimer_platform_data { int (*set_timer_src)(struct platform_device *pdev, int source); u32 timer_capability; } Another benefit from doing this, is that it will simplify the migration of the dmtimer driver to device-tree. For example, in the current OMAP2+ timer code the "loses_context" variable is configured at runtime by calling an architecture specific function. For device tree this creates a problem, because we would need to call the architecture specific function from within the dmtimer driver. However, such attributes do not need to be queried at runtime and we can look up the attributes via HWMOD or device-tree. This changes a new "capability" variable to the platform data and timer structure so we can start removing and simplifying the platform data structure. Signed-off-by: Jon Hunter <jon-hunter@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2012-06-14ARM: OMAP2+: Add dmtimer platform function to reserve systimersJon Hunter1-2/+1
During early boot, one or two dmtimers are reserved by the kernel as system timers (for clocksource and clockevents). These timers are marked as reserved and the dmtimer driver is notified which timers have been reserved via the platform data information. For OMAP2+ devices the timers reserved may vary depending on device and compile flags. Therefore, it is not easy to assume which timers we be reserved for the system timers. In order to migrate the dmtimer driver to support device-tree we need a way to pass the timers reserved for system timers to the dmtimer driver. Using the platform data structure will not work in the same way as it is currently used because the platform data structure will be stored statically in the dmtimer itself and the platform data will be selected via the device-tree match device function (of_match_device). There are a couple ways to workaround this. One option is to store the system timers reserved for the kernel in the device-tree and query them on boot. The downside of this approach is that it adds some delay to parse the DT blob to search for the system timers. Secondly, for OMAP3 devices we have a dependency on compile time flags and the device-tree would not be aware of that kernel compile flags and so we would need to address that. The second option is to add a function to the dmtimer code to reserved the system timers during boot and so the dmtimer knows exactly which timers are being used for system timers. This also allows us to remove the "reserved" member from the timer platform data. This seemed like the simpler approach and so was implemented here. Signed-off-by: Jon Hunter <jon-hunter@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2012-06-14ARM: OMAP: Remove unnecessary clk structureJon Hunter1-1/+0
In the plat/dmtimer.h there is a structure named "clk" declared. This structure is not used and appears to be left over from previous code. Hence, remove this unused structure. Verified that both omap1 and omap2plus kernel configurations build with this change. Signed-off-by: Jon Hunter <jon-hunter@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2012-05-26Merge tag 'cleanup2' of ↵Linus Torvalds1-1/+0
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc Pull arm-soc cleanups (part 2) from Olof Johansson: "More cleanups, continuing an earlier set with omap and samsung specific cleanups. These could not go into the first set because they have dependencies on various other series that in turn depend on the first cleanups." Fixed up conflicts in arch/arm/plat-omap/counter_32k.c due to commit bd0493eaaf5c: "move read_{boot,persistent}_clock to the architecture level" that changed how the persistent clocks were handled. And trivial conflicts in arch/arm/mach-omap1/common.h due to just independent changes close to each other. * tag 'cleanup2' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (35 commits) ARM: SAMSUNG: merge plat-s5p into plat-samsung ARM: SAMSUNG: move options for common s5p into plat-samsung/Kconfig ARM: SAMSUNG: move setup code for s5p mfc and mipiphy into plat-samsung ARM: SAMSUNG: move platform device for s5p uart into plat-samsung ARM: SAMSUNG: move hr timer for common s5p into plat-samsung ARM: SAMSUNG: move pm part for common s5p into plat-samsung ARM: SAMSUNG: move interrupt part for common s5p into plat-samsung ARM: SAMSUNG: move clock part for common s5p into plat-samsung ARM: S3C24XX: Use common macro to define resources on dev-uart.c ARM: S3C24XX: move common clock init into common.c ARM: S3C24XX: move common power-management code to mach-s3c24xx ARM: S3C24XX: move plat-s3c24xx/dev-uart.c into common.c ARM: S3C24XX: move plat-s3c24xx/cpu.c ARM: OMAP2+: Kconfig: convert SOC_OMAPAM33XX to SOC_AM33XX ARM: OMAP2+: Kconfig: convert SOC_OMAPTI81XX to SOC_TI81XX GPMC: add ECC control definitions ARM: OMAP2+: dmtimer: remove redundant sysconfig context restore ARM: OMAP: AM35xx: convert 3517 detection/flags to AM35xx ARM: OMAP: AM35xx: remove redunant cpu_is checks for AM3505 ARM: OMAP1: Pass dma request lines in platform data to MMC driver ...
2012-05-22Merge tag 'pm' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-socLinus Torvalds1-1/+1
Pull arm-soc power management changes from Olof Johansson: "Power management changes here are mostly for the omap platform, but also include cpuidle changes for ux500 and suspend/resume code for mmp." * tag 'pm' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (48 commits) ARM: OMAP2+: WDTIMER integration: fix !PM boot crash, disarm timer after hwmod reset ARM: OMAP2/3: hwmod data: Add 32k-sync timer data to hwmod database ARM: OMAP4: hwmod_data: Name the common irq for McBSP ports ARM: OMAP4: hwmod data: I2C: add flag for context restore ARM: OMAP3: hwmod_data: Rename the common irq for McBSP ports ARM: OMAP2xxx: hwmod data: add HDQ/1-wire hwmod ARM: OMAP3: hwmod data: add HDQ/1-wire hwmod ARM: OMAP2+: hwmod data: add HDQ/1-wire hwmod shared data ARM: OMAP2+: HDQ1W: add custom reset function ARM: OMAP2420: hwmod data: Add MMC hwmod data for 2420 arm: omap3: clockdomain data: Remove superfluous commas from gfx_sgx_3xxx_wkdeps[] ARM: OMAP2+: powerdomain: Get rid off duplicate pwrdm_clkdm_state_switch() API ARM: OMAP3: clock data: add clockdomain for HDQ functional clock ARM: OMAP3+: dpll: Configure autoidle mode only if it's supported ARM: OMAP2+: dmtimer: cleanup iclk usage ARM: OMAP4+: Add prm and cm base init function. ARM: OMAP2/3: Add idle_st bits for ST_32KSYNC timer to prcm-common header ARM: OMAP3: Fix CM register bit masks ARM: OMAP: clock: convert AM3517/3505 detection/flags to AM35xx ARM: OMAP3: clock data: treat all AM35x devices the same ...
2012-05-11Merge tag 'omap-cleanup-devices-for-v3.5' of ↵Olof Johansson1-1/+1
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into next/cleanup2 Changes to split plat-omap/devices.c into mach-omap1 and mach-omap2 except for the RNG driver that will be done later on. As this depends on omap-devel-hwmod-data-for-v3.5 and causes merge conflict with omap-fixes-non-critical-for-v3.5, this branch is based on merge of the two. By Tony Lindgren (7) and others via Tony Lindgren (4) and Paul Walmsley (1) * tag 'omap-cleanup-devices-for-v3.5' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap: (27 commits) ARM: OMAP1: Pass dma request lines in platform data to MMC driver ARM: OMAP: Move omap_mmc_add() to mach-omap1 ARM: OMAP2: Use hwmod to initialize mmc for 2420 ARM: OMAP2+: Move omap_dsp_reserve_sdram_memblock() to mach-omap2 ARM: OMAP1: Move omap_init_uwire to mach-omap1 ARM: OMAP1: Move omap_init_audio() to keep the devices in alphabetical order ARM: OMAP2+: WDTIMER integration: fix !PM boot crash, disarm timer after hwmod reset ARM: OMAP2/3: hwmod data: Add 32k-sync timer data to hwmod database ARM: OMAP4: hwmod_data: Name the common irq for McBSP ports ARM: OMAP4: hwmod data: I2C: add flag for context restore ARM: OMAP3: hwmod_data: Rename the common irq for McBSP ports ARM: OMAP2xxx: hwmod data: add HDQ/1-wire hwmod ARM: OMAP3: hwmod data: add HDQ/1-wire hwmod ARM: OMAP2+: hwmod data: add HDQ/1-wire hwmod shared data ARM: OMAP2+: HDQ1W: add custom reset function ARM: OMAP2420: hwmod data: Add MMC hwmod data for 2420 arm: omap3: clockdomain data: Remove superfluous commas from gfx_sgx_3xxx_wkdeps[] ARM: OMAP2+: powerdomain: Get rid off duplicate pwrdm_clkdm_state_switch() API ARM: OMAP3: clock data: add clockdomain for HDQ functional clock ARM: OMAP3+: dpll: Configure autoidle mode only if it's supported ...
2012-05-10ARM: OMAP2+: dmtimer: remove redundant sysconfig context restoreTarun Kanti DebBarma1-1/+0
Since hwmod framework now manages sysconfig context save/restore there is no more need to touch this register in driver. Hence, remove restore of sysconfig register in omap_timer_restore_context. This was causing incorrect context restore of sysconfig register. Signed-off-by: Tarun Kanti DebBarma <tarun.kanti@ti.com> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Acked-by: Kevin Hilman <khilman@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2012-05-08ARM: OMAP2+: dmtimer: cleanup iclk usageTarun Kanti DebBarma1-1/+1
We do not use iclk anywhere in the dmtimer driver and so removing it. Hence removing the timer iclk entries from OMAP4 clkdev table as well. Signed-off-by: Tarun Kanti DebBarma <tarun.kanti@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
2012-04-13ARM: OMAP: fix 'using plain integer as NULL pointer' sparse warningsPaul Walmsley1-2/+2
sparse warns when 0 is passed to a function expecting a pointer argument. Resolve these warnings by replacing the 0 with NULL. arch/arm/plat-omap/include/plat/dmtimer.h:319:34: warning: Using plain integer as NULL pointer arch/arm/plat-omap/include/plat/dmtimer.h:324:35: warning: Using plain integer as NULL pointer arch/arm/mach-omap2/irq.c:294:22: warning: Using plain integer as NULL pointer arch/arm/mach-omap1/board-palmz71.c:292:50: warning: Using plain integer as NULL pointer arch/arm/mach-omap1/board-palmz71.c:295:73: warning: Using plain integer as NULL pointer arch/arm/mach-omap1/ams-delta-fiq.c:105:63: warning: Using plain integer as NULL pointer Signed-off-by: Paul Walmsley <paul@pwsan.com>
2011-11-05ARM: OMAP: change get_context_loss_count ret value to intTomi Valkeinen1-2/+2
get_context_loss_count functions return context loss count as u32, and zero means an error. However, zero is also returned when context has never been lost and could also be returned when the context loss count has wrapped and goes to zero. Change the functions to return an int, with negative value meaning an error. OMAP HSMMC code uses omap_pm_get_dev_context_loss_count(), but as the hsmmc code handles the returned value as an int, with negative value meaning an error, this patch actually fixes hsmmc code also. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Acked-by: Kevin Hilman <khilman@ti.com> Acked-by: Paul Walmsley <paul@pwsan.com> [tony@atomide.com: updated to fix a warning with recent dmtimer changes] Signed-off-by: Tony Lindgren <tony@atomide.com>
2011-09-22ARM: OMAP: dmtimer: add error handling to export APIsTarun Kanti DebBarma1-12/+12
Add error handling code to export APIs. Signed-off-by: Tarun Kanti DebBarma <tarun.kanti@ti.com> Reviewed-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2011-09-22ARM: OMAP: dmtimer: low-power mode supportTarun Kanti DebBarma1-0/+35
Clock is enabled only when timer is started and disabled when the the timer is stopped. Therefore before accessing registers in functions clock is enabled and then disabled back at the end of access. Context save is done dynamically whenever the registers are modified. Context restore is called when context is lost. Signed-off-by: Tarun Kanti DebBarma <tarun.kanti@ti.com> Reviewed-by: Santosh Shilimkar <santosh.shilimkar@ti.com> [tony@atomide.com: updated to use revision instead of tidr] Signed-off-by: Tony Lindgren <tony@atomide.com>
2011-09-22ARM: OMAP: dmtimer: skip reserved timersTony Lindgren1-1/+1
Pass the reserved flag in pdata and use it. We can now make sys_timer_reserved static to mach-omap2/timer.c. Signed-off-by: Tony Lindgren <tony@atomide.com>
2011-09-22ARM: OMAP: dmtimer: pm_runtime supportTarun Kanti DebBarma1-1/+0
Add pm_runtime feature to dmtimer whereby *_runtime_get_sync() is called within omap_dm_timer_enable(), pm_runtime_put() is called in omap_dm_timer_disable(). In addition to calling pm_runtime_enable, we are calling pm_runtime_irq_safe so that they can be called from interrupt context. Signed-off-by: Tarun Kanti DebBarma <tarun.kanti@ti.com> Signed-off-by: Partha Basak <p-basak2@ti.com> Reviewed-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Acked-by: Cousson, Benoit <b-cousson@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2011-09-22ARM: OMAP: dmtimer: switch-over to platform device driverTarun Kanti DebBarma1-3/+2
Register timer devices by going through hwmod database using hwmod API. The driver probes each of the registered devices. Functionality which are already performed by hwmod framework are removed from timer code. New set of timers present on OMAP4 are now supported. Signed-off-by: Tarun Kanti DebBarma <tarun.kanti@ti.com> Acked-by: Cousson, Benoit <b-cousson@ti.com> [tony@atomide.com: folded in spinlock changes, left out is_omap2] Signed-off-by: Tony Lindgren <tony@atomide.com>
2011-09-22ARM: OMAP: dmtimer: platform driverTarun Kanti DebBarma1-0/+2
Add dmtimer platform driver functions which include: (1) platform driver initialization (2) driver probe function (3) driver remove function Signed-off-by: Tarun Kanti DebBarma <tarun.kanti@ti.com> Signed-off-by: Thara Gopinath <thara@ti.com> Reviewed-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Acked-by: Cousson, Benoit <b-cousson@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2011-09-22ARM: OMAP2+: dmtimer: convert to platform devicesTarun Kanti DebBarma1-1/+11
Add routines to converts dmtimers to platform devices. The device data is obtained from hwmod database of respective platform and is registered to device model after successful binding to driver. In addition, capability attribute of each of the timers is added in hwmod database. Signed-off-by: Tarun Kanti DebBarma <tarun.kanti@ti.com> Signed-off-by: Thara Gopinath <thara@ti.com> Reviewed-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Acked-by: Cousson, Benoit <b-cousson@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2011-09-22ARM: OMAP1: dmtimer: conversion to platform devicesTarun Kanti DebBarma1-0/+8
Convert OMAP1 dmtimers into a platform devices and then registers with device model framework so that it can be bound to corresponding driver. Signed-off-by: Thara Gopinath <thara@ti.com> Signed-off-by: Tarun Kanti DebBarma <tarun.kanti@ti.com> Reviewed-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Acked-by: Cousson, Benoit <b-cousson@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2011-09-19ARM: OMAP: Add support for dmtimer v2 ipTony Lindgren1-55/+89
The registers are slightly different between v1 and v2 ip that is available in omap4 and later for some timers. Add support for v2 ip by mapping the interrupt related registers separately and adding func_base for the functional registers. Also disable dmtimer driver features on omap4 for now as those need the hwmod conversion series to deal with enabling the timers properly in omap_dm_timer_init. Signed-off-by: Afzal Mohammed <afzal@ti.com> Tested-by: Hemant Pedanekar <hemantp@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2011-07-10OMAP: dmtimer: add missing includePaul Walmsley1-0/+1
After commit caf64f2fdc48472995d40656eb1a75524c464447 ("omap: Make a subset of dmtimer functions into inline functions"), arch/arm/plat-omap/include/plat/dmtimer.h is missing an include of linux/io.h - add it. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Tony Lindgren <tony@atomide.com>
2011-06-27omap2+: Reserve clocksource and timesource and initialize dmtimer laterTony Lindgren1-2/+1
There's no need to initialize the dmtimer framework early. Just mark the clocksource and timesource as reserved, and initialize dmtimer with an arch_initcall. Signed-off-by: Tony Lindgren <tony@atomide.com> Reviewed-by: Kevin Hilman <khilman@ti.com>
2011-06-20omap2+: Remove gptimer_wakeup for nowTony Lindgren1-1/+0
This removes the support for setting the wake-up timer for debugging. Later on we can reserve gptimer1 for PM code only and have similar functionality. Signed-off-by: Tony Lindgren <tony@atomide.com> Reviewed-by: Kevin Hilman <khilman@ti.com>
2011-06-20omap2+: Use dmtimer macros for clockeventTony Lindgren1-0/+1
This patch makes timer-gp.c to use only a subset of dmtimer functions without the need to initialize dmtimer code early. Also note that now with the inline functions, timer_set_next_event becomes more efficient in the lines of assembly code. Signed-off-by: Tony Lindgren <tony@atomide.com> Reviewed-by: Kevin Hilman <khilman@ti.com>
2011-06-20omap: Make a subset of dmtimer functions into inline functionsTony Lindgren1-0/+119
This will allow us to share the code between system timer and dmtimer device driver code without having to initialize all the dmtimers early. This change will also make the timer_set_next_event more efficient as the inline functions will optimize the code better for the timer reprogramming. Signed-off-by: Tony Lindgren <tony@atomide.com> Reviewed-by: Kevin Hilman <khilman@ti.com>
2011-06-20omap: Move dmtimer defines to dmtimer.hTony Lindgren1-0/+125
These will be needed when dmtimer platform init code gets split for omap1 and omap2+. These will also be needed for separate sys_timer init and driver init for the rest of the hardware timers in the following patches. No functional changes. Signed-off-by: Tony Lindgren <tony@atomide.com> Reviewed-by: Kevin Hilman <khilman@ti.com>
2011-06-20omap: Set separate timer init functions to avoid cpu_is_omap testsTony Lindgren1-1/+0
This is needed for the following patches so we can initialize the rest of the hardware timers later on. As with the init_irq calls, there's no need to do cpu_is_omap calls during the timer init as we only care about the major omap generation. This means that we can initialize the sys_timer with the .timer entries alone. Note that for now we just set stubs for the various sys_timer entries that will get populated in a later patch. The following patches will also remove the omap_dm_timer_init calls and change the init for the rest of the hardware timers to happen with an arch_initcall. Signed-off-by: Tony Lindgren <tony@atomide.com> Reviewed-by: Kevin Hilman <khilman@ti.com>
2011-02-28OMAP2420: hwmod data: add dmtimerThara Gopinath1-0/+11
Add dmtimer data. Signed-off-by: Thara Gopinath <thara@ti.com> Signed-off-by: Tarun Kanti DebBarma <tarun.kanti@ti.com> Acked-by: Benoit Cousson <b-cousson@ti.com>