- 09 Jan, 2009 1 commit
-
-
Aaro Koskinen authored
When 32 kHz timer is used the min_delta_ns should be initialized so that it reflects the timer programming cost. A write to the timer device will be usually posted, but it takes roughly 3 cycles before it is effective. If the timer is reprogrammed before that, the CPU will stall until the previous write completes. This was pointed out by Richard Woodruff. Since the lower bound for min_delta_ns is 1000, the change is visible only with tick rates less than 3 MHz. Also note that the old value is incorrect for 32 kHz also due to a rounding error, and it can cause the timer queue to hang (due to clockevent code trying to program the timer with zero ticks). Signed-off-by: Aaro Koskinen <Aaro.Koskinen@nokia.com> Reviewed-by: Richard Woodruff <r-woodruff2@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
-
- 08 Jan, 2009 9 commits
-
-
Lopez Cruz, Misael authored
This patch enables writing to McBSP Transmit Configuration Control Register (XCCR) and Receive Configuration Control Register (RCCR) for 2430/34xx platforms. It also adds XCCR, RCCR entries in McBSP register configuration structure and bit definitions for both registers. Signed-off-by: Misael Lopez Cruz <x0052729@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
-
Paul Walmsley authored
The McBSP driver uses virtual clocks to handle enabling and disabling its hardware clocks. These virtual clocks have no associated clockdomain. After commit 60b8b431, this prevents the McBSP clocks from registering correctly. Resolve this for the short term by using virt_opp_clkdm for these clocks. These McBSP virtual clocks should be removed, but such a fix would require significant changes to the McBSP drivers that would require testing on OMAP1, 2, and 3 platforms. Tested on 2430SDP and 3430SDP GP ES2.1. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Eero Nurkkala <ext-eero.nurkkala@nokia.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
-
Josh Karabin authored
This patch adds support for detecting NAND flash on OMAP3 EVM boards. It clones similar code from the 3430 SDP board files. Signed-off-by: Josh Karabin <gkarabin@vocollect.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
-
Eero Nurkkala authored
The prescalers for 100 kHz and 400 kHz mode are wrong for omap 3430 and omap 2430. The internal clock is the fclock divided by the prescaler. The PSC is an 8 bit field in omap3430 and omap2430. Moreover, the scll and sclh values should be adjusted properly. Having the correct prescaler is important in the process of getting a finite i2c clock. In addition, the prescaler is used in the process of activating the correct noise filter and thus, lets more error resilient i2c communications. Signed-off-by: Eero Nurkkala <ext-eero.nurkkala@nokia.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
-
Eero Nurkkala authored
The number of bytes to be received is read from wrong place with all OMAPs with highspeed I2C support, which involves a FIFO and BUFSTAT_REG. It is the 6 bits starting from the bit 8 in the BUFSTAT_REG that indicate this amount of bytes to be read. Moreover, only the 6 LSB:s are relevant for the TXSTAT field. Signed-off-by: Eero Nurkkala <ext-eero.nurkkala@nokia.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
-
Anand Gadiyar authored
Bug in existing code causes synchro control to be set +32 if request line greater than 63 is used. Reported by Wenbiao Wang Signed-off-by: Anand Gadiyar <gadiyar@ti.com> +++ linux-omap-2.6/arch/arm/plat-omap/dma.c 2009-01-08 14:44:46.000000000 +0200 @@ -279,10 +279,7 @@ void omap_set_dma_transfer_params(int lc val = dma_read(CCR(lch)); val &= ~(3 << 19); - if (dma_trigger > 63) - val |= 1 << 20; - if (dma_trigger > 31) - val |= 1 << 19; + val |= ((dma_trigger & ~(0x1f)) << 14); val &= ~(0x1f); val |= (dma_trigger & 0x1f); Signed-off-by: Tony Lindgren <tony@atomide.com>
-
matti.halme@nokia.com authored
A triggering RTC alarm should be able to power on a device that has been powered off. This patch enables that on twl4030 by not masking the alarm interrupt at shutdown. Signed-off-by: Matti Halme <matti.halme@nokia.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
-
Manikandan Pillai authored
Default MUX configurations for GPIO on OMAP3 EVM boards are added. Fixed for "_UP" naming convention for GPIOs comment. Signed-off-by: Manikandan Pillai <mani.pillai@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
-
Tony Lindgren authored
This patch should be merged into the "MAP3: PM: UART: disable clocks when idle" patch for omap-pm-upstream. Signed-off-by: Tony Lindgren <tony@atomide.com>
-
- 07 Jan, 2009 30 commits
-
-
Kevin Hilman authored
Rogue bootloaders may enable the modem and thus keep the D2D power- and clock-domains from going into retention. Reset modem on boot to be sure it is in known state. Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
-
Kevin Hilman authored
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
-
Tero Kristo authored
Current implementation will disable clocks in the order defined in clock34xx.h, at least DPLL4_M2X2 will hang in certain cases (and prevent retention / off) if clocks are not disabled in correct order. This patch makes sure the parent clocks will be active when disabling a clock. Signed-off-by: Tero Kristo <tero.kristo@nokia.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
-
Jouni Hogander authored
This patch makes it possible to change uart sleep timeout. New sysfs entry is added (/sys/devices/platform/serial8250.0/sleep_timeout) Also default timeout is increased to 5 second to make serial console more usable. Original patch was written by Tero Kristo some time ago. Signed-off-by: Jouni Hogander <jouni.hogander@nokia.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
-
Kevin Hilman authored
If OFF-mode is enabled, each enabled UART will save its context whenever clocks are disabled and restore it when clocks are re-enabled. Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
-
Kevin Hilman authored
This patch allows the UART clocks to be disabled when the OMAP UARTs are inactive, thus permitting the chip to hit retention in idle. After the timeout of an activity timer, each UART is allowed to disable its clocks so the system can enter retention. The activity timer is (re)activated on any UART interrupt, UART wake event or any IO pad wakeup. The actual disable of the UART clocks is done in the 'prepare_idle' hook called from the OMAP idle loop. While the activity timer is active, the smart-idle mode of the UART is also disabled. This is due to a "feature" of the UART module that after a UART wakeup, the smart-idle mode may be entered before the UART has communicated the interrupt, or upon TX, an idle mode may be entered before the TX FIFOs are emptied. Upon suspend, the 'prepare_suspend' hook cancels any pending activity timers and allows the clocks to be disabled. To enable the clock-disabling feature of this patch, do # echo 1 > /sys/power/clocks_off_while_idle Special thanks to Tero Kristo for the initial ideas and first versions of UART idle support, and to Jouni Hogander for extra testing and bugfixes. Tested on OMAP3 (Beagle, custom HW) and OMAP2 (n810) Cc: Tero Kristo <tero.kristo@nokia.com> Cc: Jouni Hogander <jouni.hogander@nokia.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
-
Kevin Hilman authored
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
-
Kevin Hilman authored
GPT12 is in the WKUP powerdomain and can be useful as the system timer and thus a wakeup source for sleep while idle. Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
-
Kevin Hilman authored
All GP timers on OMAP2/3 can be wakeup events. The wakeup status is cleared in the PRCM interrupt handler. Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
-
Kevin Hilman authored
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
-
Paul Walmsley authored
smartreflex.c defines some custom clocks that don't have clockdomains associated with them, which is now disallowed. The custom clocks are not actually needed, so remove them. This patch should not cause any functional change. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Kalle Jokiniemi <ext-kalle.jokiniemi@nokia.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
-
Paul Walmsley authored
Clock rate change code executes inside a spinlock with hardirqs disabled. The only code that should be messing around with the hardirq state should be the plat-omap/clock.c code. In the omap2_reprogram_dpllcore() case, this probably just wastes cycles, but in the omap3_core_dpll_m2_set_rate() case, this is a nasty bug. Signed-off-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
-
Paul Walmsley authored
Rearrange the parent clock enable status check code so it actually makes sense. No functional change. Signed-off-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
-
Paul Walmsley authored
If _omap2_clk_enable() fails, the clock's usecount must be decremented by one no matter whether the clock has a parent or not. Signed-off-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
-
Paul Walmsley authored
omap2_clk_enable() should enable a clock's clockdomain before attempting to enable its parent clock's clockdomain. Similarly, in the unlikely event that the parent clock enable fails, the clockdomain should be disabled. Signed-off-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
-
Paul Walmsley authored
Clean up omap2_clk_enable() by moving most of the function body out of the usecount check. Should result in no functional change. Signed-off-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
-
Paul Walmsley authored
Every OMAP2/3 clock must now have an assigned clockdomain, so we can remove the checks from clk_enable()/clk_disable(). Instead, verify that the clockdomain is present only at clock init time via the arch_clock clk_register() hook. Signed-off-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
-
Paul Walmsley authored
Provide a mechanism for OMAP chip family (e.g., OMAP1, 2, 3) clock code to define a clk_register function via struct clk_functions. This is currently only used for OMAP2/3, to handle clock->clockdomain registration. Signed-off-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
-
Paul Walmsley authored
This function is race-prone and mistakenly conveys the impression to drivers that it is part of the clock interface. Get rid of it: core code that absolutely needs this can just check clk->usecount. Drivers should not use it at all. Signed-off-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
-
Paul Walmsley authored
Several parts of the OMAP2/3 clock code use wmb() to try to ensure that the hardware write completes before continuing. This approach is problematic: wmb() only ensures that the write leaves the ARM. It does not ensure that the write actually reaches the endpoint device. The endpoint device in this case - either the PRM, CM, or SCM - is three interconnects away from the ARM - and the final interconnect is low-speed. And the OCP interconnects will post the write, and who knows how long that will take to complete. So the wmb() is not what we want. Worse, the wmb() is indiscriminate; it causes the ARM to flush any other unrelated buffered writes and wait for the local interconnect to acknowledge them - potentially very expensive. Fix this by converting the wmb()s into readbacks of the same PRM/CM/SCM register. Since the PRM/CM/SCM devices use a single OCP thread, this will cause the MPU to block while waiting for posted writes to that device to complete. Signed-off-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
-
Paul Walmsley authored
Consolidate the commit code for DELAYED_APP clocks into a subroutine, _omap2xxx_clk_commit(). Also convert the MPU barrier wmb() into an OCP barrier, since with an MPU barrier, we have no guarantee that the write actually reached the endpoint device. Signed-off-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
-
Paul Walmsley authored
clk_disable() previously used an ARM barrier, wmb(), to try to ensure that the hardware write completed before continuing. There are some problems with this approach. The first problem is that wmb() only ensures that the write leaves the ARM -- not that it actually reaches the endpoint device. In this case, the endpoint device - either the PRM, CM, or SCM - is three interconnects away from the ARM, and the final interconnect is low-speed. And the OCP interconnects will post the write, who knows how long that will take to complete. So the wmb() is not really what we want. Worse, the wmb() is indiscriminate; it will cause the ARM to flush any other unrelated buffered writes and wait for the local interconnect to acknowledge them - potentially very expensive. This first problem could be fixed by doing a readback of the same PRM/CM/SCM register. Since these devices use a single OCP thread, this will cause the MPU to wait for the write to complete. But the primary problem is a conceptual one: clk_disable() should not need any kind of barrier. clk_enable() needs one since device driver code must not access a device until its clocks are known to be enabled. But clk_disable() has no such restriction. Since blocking the MPU on a PRM/CM/SCM write can be a very high-latency operation - several hundred MPU cycles - it's worth avoiding this barrier if possible. Signed-off-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
-
Russell King authored
... to eliminate unnecessary padding. We have rather a lot of these structures, so eliminating unnecessary padding results in a saving of 1488 bytes. [paul@pwsan.com: updated against current linux-omap clock tree, now saves 1512 bytes on OMAP3 builds] Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
-
Russell King authored
clk->owner is always NULL, so its existence doesn't serve any useful function other than bloating the kernel by 992 bytes. Remove it. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
-
Paul Walmsley authored
The CONFIG_PARTICIPANT flags indicates to the clock rate and parent changing functions that they should not be used on this clock. Better just to remove the clock function pointers that operate on those clocks. The name of the flag is just terrible: its meaning has almost nothing to do with its name, and the use of the CONFIG_ prefix makes it appear to be a Kconfig option. Get rid of it. Signed-off-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
-
Russell King authored
Nothing tests the clock flags for this bit, so it serves no purpose. Remove it. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
-
Paul Walmsley authored
The RATE_FIXED flag currently has no useful purpose. Fixed rate clocks should simply not implement the recalc, set_rate, set_parent, and round_rate function pointers. Signed-off-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
-
Paul Walmsley authored
Now that clocks keep track of their children, the RATE_PROPAGATES flag is no longer necessary. Signed-off-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
-
Paul Walmsley authored
Track child clocks for each struct clk. This optimizes traversals of the clock tree from parent to child, which happens during rate propagation, and in the future, clock notifiers. Previously, parent-to-child traversals sequentially scanned the entire clock list at each step to determine the children of a particular clock node. Now each struct clk maintains a clock list of its children. For a DPLL3_M2_CK rate change, this converts what were about O(6*180*2) operations into O(6*6*2) operations. The savings will be even more significant after the future notifier patches: something like O(6*180*6) to O(6*6*6). The price paid is additional runtime memory consumption - 8 bytes per clock and 16 bytes per child clock - roughly 4.5KiB on OMAP3. The memory comes mostly from bootmem, since initial clock registration takes place before slab is ready. Several other operations will take slightly more time due the extra bookkeeping: clk_register(), clk_unregister(), clk_set_parent(), and omap2_init_clksel_parent(). Signed-off-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
-
Paul Walmsley authored
For upcoming notifier support, modify the rate recalculation code to take parent rate and rate storage parameters. The goal here is to allow the clock code to determine what the clock's rate would be after a parent change or a rate change, without actually changing the hardware registers. This is used by the upcoming notifier patches to pass a clock's current and planned rates to the notifier callbacks. Also add a new clock flag, RECALC_ON_ENABLE, which causes the clock framework code to recalculate the current clock's rate and propagate down the tree after a clk_enable() or clk_disable(). This is used by the OMAP3 DPLLs, which change rates when they enable or disable, unlike most clocks. Signed-off-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
-