summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2010-12-22watchdog: Fix null pointer dereference while accessing rdc321x platform_dataFlorian Fainelli
rdc321x-wdt currently fetches its driver specific data by using the platform_device->platform_data pointer, this is wrong because the mfd device which registers our platform_device has been added using mfd_add_device() which sets the platform_device->driver_data pointer instead. Signed-off-by: Florian Fainelli <florian@openwrt.org> CC: stable@kernel.org Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2010-12-22gpio: Fix null pointer dereference while accessing rdc321x platform_dataFlorian Fainelli
rdc321x-gpio currently fetches its driver specific data by using the platform_device->platform_data pointer, this is wrong because the mfd device which registers our platform_device has been added using mfd_add_device() which sets the platform_device->driver_data pointer instead. Signed-off-by: Florian Fainelli <florian@openwrt.org> CC: stable@kernel.org Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2010-12-22Merge branch 'perf/core' of ↵Ingo Molnar
git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux-2.6 into perf/core
2010-12-22Merge commit 'v2.6.37-rc7' into perf/coreIngo Molnar
Merge reason: Pick up the latest -rc. Signed-off-by: Ingo Molnar <mingo@elte.hu>
2010-12-22ocfs2: Fix system inodes cache overflow.Tao Ma
When we store system inodes cache in ocfs2_super, we use a array for global system inodes. But unfortunately, the range is calculated wrongly which makes it overflow and pollute ocfs2_super->local_system_inodes. This patch fix it by setting the range properly. The corresponding bug is ossbug1303. http://oss.oracle.com/bugzilla/show_bug.cgi?id=1303 Cc: stable@kernel.org Signed-off-by: Tao Ma <boyu.mt@taobao.com> Signed-off-by: Joel Becker <joel.becker@oracle.com>
2010-12-22Merge branch 'perf/urgent' of ↵Ingo Molnar
git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux-2.6 into perf/urgent
2010-12-22Input: synaptics - ignore bogus mt packetHenrik Rydberg
In multitouch mode, at least one device (fw: 7.4 id: 0x1c0b1) sometimes sends a final main packet with x == 1. Since the normal values are above 1472, this is clearly bogus. At the same time, a two-finger touch is signaled, even though only one finger was on the pad to begin with. This patch ignores the packet altogether, removing the problem. Acked-by: Chris Bagwell <chris@cnpbagwell.com> Acked-by: Chase Douglas <chase.douglas@canonical.com> Acked-by: Dmitry Torokhov <dtor@mail.ru> Signed-off-by: Henrik Rydberg <rydberg@euromail.se>
2010-12-22kthread_work: make lockdep happyYong Zhang
spinlock in kthread_worker and wait_queue_head in kthread_work both should be lockdep sensible, so change the interface to make it suiltable for CONFIG_LOCKDEP. tj: comment update Reported-by: Nicolas <nicolas.mailhot@laposte.net> Signed-off-by: Yong Zhang <yong.zhang0@gmail.com> Signed-off-by: Andy Walls <awalls@md.metrocast.net> Tested-by: Andy Walls <awalls@md.metrocast.net> Cc: Tejun Heo <tj@kernel.org> Cc: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Tejun Heo <tj@kernel.org>
2010-12-22ux500: rename modem IRQ and MBOX filesLinus Walleij
Suffix the U5500 modem IRQ and MBOX files with *-db5500* so that we clearly know the SoC they belong to, in line with the rest of the files in mach-ux500. Cc: Stefan Nilsson <stefan.xk.nilsson@stericsson.com> Cc: Martin Persson <martin.persson@stericsson.com> Signed-off-by: Linus Walleij <linus.walleij@stericsson.com>
2010-12-22ARM: mach-shmobile: Add eMMC support through MMCIF on AG5EVMTakashi YOSHII
Adding platform resources, PFC setting and release reset pin for eMMC on ag5evm. [damm@opensource.se: Add MSTP code for MMCIF] Signed-off-by: Takashi YOSHII <takashi.yoshii.zj@renesas.com> Signed-off-by: Magnus Damm <damm@opensource.se> Signed-off-by: Paul Mundt <lethal@linux-sh.org>
2010-12-22ARM: mach-shmobile: Use pullups for AG5EVM KEYSC pinsTakashi YOSHII
Follow up to pfc-sh73a0.c's pull-up support. Change GPIO_FN_KEYINx to GPIO_FN_KEYINx_PU. Signed-off-by: Takashi YOSHII <takashi.yoshii.zj@renesas.com> Signed-off-by: Magnus Damm <damm@opensource.se> Signed-off-by: Paul Mundt <lethal@linux-sh.org>
2010-12-22ARM: mach-shmobile: sh73a0 GPIO pullup improvementTakashi YOSHII
On SH-Mobile, Pull UP/Downs can be controlled independently from Function selectors (by lower nibble of PFCR). It means people may want to use GPIO_FN_xxx_PU/PD in addition to GPIO_IN_PU/PD which is currently supported. This patch adds pull-up version for some input signals on KEYSC, MMC, FSIA as well as SDHI1. Signed-off-by: Takashi YOSHII <takashi.yoshii.zj@renesas.com> Signed-off-by: Magnus Damm <damm@opensource.se> Signed-off-by: Paul Mundt <lethal@linux-sh.org>
2010-12-22ARM: mach-shmobile: sh73a0 CPGA fix for KEYSCMagnus Damm
Fix the sh73a0 KEYSC clock control by adding MSTP403 to mstp_clks[]. Use KEYSC instead of KEYSC0 in comments. Signed-off-by: Magnus Damm <damm@opensource.se> Signed-off-by: Paul Mundt <lethal@linux-sh.org>
2010-12-22fbdev: sh-mobile: retrieve and propagate display sizes from EDIDGuennadi Liakhovetski
Monitor EDID contains information about physical display sizes. Retrieve it and propagate to the framebuffer driver. Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de> Signed-off-by: Paul Mundt <lethal@linux-sh.org>
2010-12-22fbdev: sh-mobile: restore display size configurationGuennadi Liakhovetski
An earlier patch replaced open-coded video-mode configuration from platform data by a call to fb_videomode_to_var(), thereby setting ofdisplay sizes have been accidentally lost. Restore them. Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de> Signed-off-by: Paul Mundt <lethal@linux-sh.org>
2010-12-22Merge commit 'v2.6.37-rc7' into spi/nextGrant Likely
2010-12-21OMAP4: clock data: Keep L3INSTR clock domain modulemode under HW controlSantosh Shilimkar
L3INSTR clock domain is read only register and its reset value is HW_AUTO. The modules withing this clock domain needs to be kept under hardware control. MODULEMODE: - 0x0: Module is disable by software. Any INTRCONN access to module results in an error, except if resulting from a module wakeup (asynchronous wakeup). - 0x1: Module is managed automatically by hardware according to clock domain transition. A clock domain sleep transition put module into idle. A wakeup domain transition put it back into function. If CLKTRCTRL=3, any INTRCONN access to module is always granted. Module clocks may be gated according to the clock domain state. This patch keeps CM_L3INSTR_L3_3_CLKCTRL, CM_L3INSTR_L3_INSTR_CLKCTRL and CM_L3INSTR_INTRCONN_WP1_CLKCTRL module mode under hardware control by using ENABLE_ON_INIT flag. Without this the OMAP4 device OFF mode SAR restore phase aborts during interconnect register restore phase. This can be also handled by doing explicit a clock enable and disable in the low power code since there is no direct module associated with it. But that seems not necessary since the clock domain is under HW control. Signed-off-by: Rajendra Nayak <rnayak@ti.com> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Acked-by: Benoit Cousson <b-cousson@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
2010-12-21OMAP4: powerdomain: Remove L3INIT_PD OFF stateSantosh Shilimkar
On OMAP4, there is an issue when L3INIT transitions to OFF mode without device OFF. The SAR restore mechanism will not get triggered without wakeup from device OFF and hence the USB host and USB TLL context will not be restored. Hardware team recommended to remove the OFF state support for L3INIT_PD since there is no power impact. It will be removed on next OMAP revision (OMAP4440 and beyond). Hence this patch removed the OFF state from L3INIT_PD. The deepest state supported on L3INIT_PD is OSWR just like CORE_PD and PER_PD Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com> [b-cousson@ti.com: update the changelog with next OMAP info] Signed-off-by: Benoit Cousson <b-cousson@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
2010-12-21OMAP4: powerdomain: l4per pwrdm does not support OFFRajendra Nayak
The l4per power domain in ES2.0 does support only RET and ON states. The previous ES1.0 HW database was wrong and thus fixed on ES2. Change the pwrsts field to reflect that. Signed-off-by: Rajendra Nayak <rnayak@ti.com> Acked-by: Benoit Cousson <b-cousson@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
2010-12-21OMAP4: PM: Do not assume clkdm supports hw transitionsRajendra Nayak
omap_set_pwrdm_state today assumes a clkdm supports hw_auto transitions and hence leaves some which do not support this in sw wkup state preventing low power transitions. Signed-off-by: Rajendra Nayak <rnayak@ti.com> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Acked-by: Benoit Cousson <b-cousson@ti.com> Acked-by: Kevin Hilman <khilman@deeprootsystems.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
2010-12-21OMAP4: PM: Use the low-power state change feature on OMAP4Rajendra Nayak
For pwrdm's which support LOWPOWERSTATECHANGE, do not try waking up the domain to put it back to deeper sleep state. Signed-off-by: Rajendra Nayak <rnayak@ti.com> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Acked-by: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Acked-by: Kevin Hilman <khilman@deeprootsystems.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
2010-12-21USB: add support for Dream Cheeky DL100B Webmail Notifier (1d34:0004)Melchior FRANZ
So far the USBLED driver only supports Delcom's "USB Visual Signal Indicator" (http://www.delcomproducts.com/products_USBLMP.asp). The driver generates virtual files "red", "green", and "blue" under the device's /sys/ directory, where color values can be read from and written to. This patch adds support for Dream Cheeky's "DL100B Webmail Notifier" (http://www.dreamcheeky.com/webmail-notifier -- available from several shops, such as http://www.conrad.at/ce/de/product/777048/USB-WEBMAIL). This device isn't as pretty as Delcom's, but it's *far* cheaper, and its 3 LEDs can be set in 32 brightness steps each. The grey envelope contour can easily be removed, leaving a rather neutral white box (with a few small holes), which is useful for generic signalling purposes. Of course, the small circuit board can easily be put into a prettier case. The DL100B device pretends to be a HID, but the HID descriptor shows that it's not overly useful as such (see below). The patch therefore removes the "HID-ness" (hid-core.c, hid-ids.h), and adds the necessary commands to usbled.c. The protocol info comes from the developer's manual that Dream Cheeky kindly provided (815DeveloperManual.pdf). HID descriptor: 0: 05 01 Usage Page 'Generic Desktop Controls' 2: 09 10 Usage 'Reserved' 4: a1 01 Collection 'Application (mouse, keyboard)' 6: 05 00 Usage Page 'Undefined' 8: 19 10 Usage Minimum = 16 10: 29 11 Usage Maximum = 17 12: 15 00 Logical Minimum = 0 14: 25 0f Logical Maximum = 15 16: 75 08 Report Size = 8 18: 95 08 Report Count = 8 20: 91 02 Output data *var abs lin pref-state null-pos non-vol bit-field 22: 19 10 Usage Minimum = 16 24: 29 11 Usage Maximum = 17 26: 15 00 Logical Minimum = 0 28: 25 0f Logical Maximum = 15 30: 75 08 Report Size = 8 32: 95 08 Report Count = 8 34: 81 00 Input data array abs lin pref-state null-pos non-vol bit-field 36: c0 End Collection Signed-off-by: Melchior FRANZ <mfranz@aon.at> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-12-22ARM: mach-shmobile: sh73a0 TMU supportMagnus Damm
Add support for 2 TMU timer channels on sh73a0. One timer channel is used for clocksource and the other is used for clockevents. All channels in the same TMU block share MSTP bit as usual. Signed-off-by: Magnus Damm <damm@opensource.se> Signed-off-by: Paul Mundt <lethal@linux-sh.org>
2010-12-22ARM: mach-shmobile: sh73a0 INTCS supportMagnus Damm
Add INTCS support for the sh73a0 processor. The interrupts on the sh73a0 processor are managed through controllers such as GIC, INTCS and INTCA. The ARM cores use the GIC as primary interrupt controller and the INTCS and INTCA are hanging off the GIC as cascaded interrupt controllers. Peripherals connected both to the GIC and the INTC controllers should if possible only use the GIC. If no GIC connection is available then INTCS and INTCA may be used instead. Signed-off-by: Magnus Damm <damm@opensource.se> Signed-off-by: Paul Mundt <lethal@linux-sh.org>
2010-12-22ARM: mach-shmobile: mackerel: fixup default memory sizeKuninori Morimoto
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Signed-off-by: Paul Mundt <lethal@linux-sh.org>
2010-12-21OMAP: PM noop: implement context loss count for non-omap_devicesKevin Hilman
For devices which have not (yet) been converted to use omap_device, implement the context loss counter using the "brutal method" as originally proposed by Paul Walmsley[1]. The dummy context loss counter is incremented every time it is checked, but only when off-mode is enabled. When off-mode is disabled, the dummy counter stops incrementing. Tested on 36xx/Zoom3 using MMC driver, which is currently the only in-tree user of this API. This patch should be reverted after all devices are converted to using omap_device. [1] http://marc.info/?l=linux-omap&m=129176260000626&w=2 Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com> [paul@pwsan.com: fixed compile warning; fixed to compile on OMAP1] Signed-off-by: Paul Walmsley <paul@pwsan.com>
2010-12-21OMAP: PM: implement context loss count APIsKevin Hilman
Implement OMAP PM layer omap_pm_get_dev_context_loss_count() API by creating similar APIs at the omap_device and omap_hwmod levels. The omap_hwmod level call is the layer with access to the powerdomain core, so it is the place where the powerdomain is queried to get the context loss count. The new APIs return an unsigned value that can wrap as the context-loss count grows. However, the wrapping is not important as the role of this function is to determine context loss by checking for any difference in subsequent calls to this function. Note that these APIs at each level can return zero when no context loss is detected, or on errors. This is to avoid returning error codes which could potentially be mistaken for large context loss counters. NOTE: only works for devices which have been converted to use omap_device/omap_hwmod. Longer term, we could possibly remove this API from the OMAP PM layer, and instead directly use the omap_device level API. Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
2010-12-21OMAP2+: powerdomain: add API to get context loss countKevin Hilman
Add new powerdomain API u32 pwrdm_get_context_loss_count(struct powerdomain *pwrdm) for checking how many times the powerdomain has lost context. The loss count is the sum of the powerdomain off-mode counter, the logic off counter and the per-bank memory off counter. Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com> [paul@pwsan.com: removed bogus return value on error; improved kerneldoc; tweaked commit message] Signed-off-by: Paul Walmsley <paul@pwsan.com>
2010-12-21OMAP4: clocks: add dummy clock for mailboxHari Kanigeri
In omap4, there is no explicit configuration register to enable mailbox clocks. Defining dummy clock for mailbox clock module to keep the mailbox driver backward compatible with previous omaps. Signed-off-by: Hari Kanigeri <h-kanigeri2@ti.com> Acked-by: Benoît Cousson <b-cousson@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
2010-12-21OMAP: clock: fix configuration of J-Type DPLLs to work for OMAP3 and OMAP4Jon Hunter
J-Type DPLLs have additional configuration parameters that need to be programmed when setting the multipler and divider for the DPLL. These parameters being the sigma delta divider (SD_DIV) for the DPLL and the digital controlled oscillator (DCO) to be used by the DPLL. The current code is implemented specifically to configure the OMAP3630 PER J-Type DPLL. The OMAP4430 USB DPLL is also a J-Type DPLL and so this code needs to be updated to work for both OMAP3 and OMAP4 devices and any other future devices that have J-TYPE DPLLs. For the OMAP3630 PER DPLL both the SD_DIV and DCO paramenters are used but for the OMAP4430 USB DPLL only the SD_DIV field is used. The current implementation will only program the SD_DIV and DCO fields if the DPLL has both and hence this does not work for OMAP4430. In order to make the code more generic add two new fields to the dpll_data structure for the SD_DIV field and DCO field bit-masks and only program these fields if the masks are defined for a specific DPLL. This simplifies the code and allows us to remove the flag DPLL_NO_DCO_SEL. Tested on OMAP36xx Zoom3 and OMAP4 Blaze. Signed-off-by: Jon Hunter <jon-hunter@ti.com> [paul@pwsan.com: removed explicit inlining and added '_' prefix on lookup_*() functions; added testing info to commit message; added 35xx comments back in] Signed-off-by: Paul Walmsley <paul@pwsan.com>
2010-12-21OMAP3: clock: Update clock domain name for mcspi fckCharulatha V
Update clock3xxx_data for mcspi1-4 with appropriate clock domain name. Signed-off-by: Charulatha V <charu@ti.com> Signed-off-by: Govindraj.R <govindraj.raja@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
2010-12-21OMAP4: hwmod data: Add SIDLE_SMART_WKUP modes to several IPsBenoit Cousson
uart, gpio, wd_timer and i2c does support the new smart-idle with wakeup added in OMAP4. Add the flag to allow the hwmod core to enable this mode when applicable. Signed-off-by: Benoit Cousson <b-cousson@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Rajendra Nayak <rnayak@ti.com>
2010-12-21OMAP2+: hwmod: Add wakeup support for new OMAP4 IPsBenoit Cousson
The new OMAP4 IPs introduced a new idle mode named smart-idle with wakeup. This new idlemode replaces the enawakeup for the new IPs but seems to coexist as well for some legacy IPs (UART, GPIO, MCSPI...) Add the new SIDLE_SMART_WKUP flag to mark the IPs that support this capability. The omap_hwmod_44xx_data.c will have to be updated to add this new flag. Enable this new mode when applicable in _enable_wakeup, _enable_sysc and _idle_sysc. Signed-off-by: Benoit Cousson <b-cousson@ti.com> Tested-by: Sebastien Guiriec <s-guiriec@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Rajendra Nayak <rnayak@ti.com>
2010-12-21OMAP2+: hwmod: Disable clocks when hwmod enable failsRajendra Nayak
In cases where a module (hwmod) does not become accesible on enabling the main clocks (can happen if there are external clocks needed for the module to become accesible), make sure the clocks are not left enabled. This ensures that when the requisite external dependencies are met a omap_hwmod_enable and omap_hwmod_idle/shutdown would rightly enable and disable clocks using clk framework. Leaving the clocks enabled in the error case causes additional usecounting at the clock framework level leaving the clock enabled forever. Signed-off-by: Rajendra Nayak <rnayak@ti.com> Signed-off-by: Benoit Cousson <b-cousson@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Kevin Hilman <khilman@deeprootsystems.com>
2010-12-21OMAP2+: hwmod: Remove omap_hwmod_mutexBenoit Cousson
The hwmod list will be built are init time and never be modified at runtime. There is no need anymore to protect the list from concurrent accesses using a mutex. Signed-off-by: Benoit Cousson <b-cousson@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Kevin Hilman <khilman@deeprootsystems.com>
2010-12-21OMAP2+: hwmod: Mark functions used only during initialization with __initBenoit Cousson
_register, _find_mpu_port_index and _find_mpu_rt_base are static APIs that will be used only during the omap_hwmod initialization phase. There is no need to keep them for runtime. Signed-off-by: Benoit Cousson <b-cousson@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Kevin Hilman <khilman@deeprootsystems.com>
2010-12-21OMAP2+: hwmod: Make omap_hwmod_register private and remove omap_hwmod_unregisterBenoit Cousson
Do not allow omap_hwmod_register to be used outside the core hwmod code. An omap_hwmod should be registered only at init time. Remove the omap_hwmod_unregister that is not used today since the hwmod list will be built once at init time and never be modified at runtime. Signed-off-by: Benoit Cousson <b-cousson@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Kevin Hilman <khilman@deeprootsystems.com>
2010-12-21OMAP2430: hwmod data: Use common dev_attr for i2c1 and i2c2Benoit Cousson
Since i2c1 and i2c2 are using the same data, remove the two previous instances and use a common i2c_dev_attr one. Moreover, that will fix the following warning: arch/arm/mach-omap2/omap_hwmod_2430_data.c:485: warning: 'i2c_dev_attr' defined but not used Signed-off-by: Benoit Cousson <b-cousson@ti.com> Acked-by: Rajendra Nayak <rnayak@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Charulatha V <charu@ti.com>
2010-12-21OMAP2+: omap_hwmod: fix wakeup enable/disable for consistencyKevin Hilman
In the omap_hwmod core, most of the SYSCONFIG register helper functions do not directly write the register, but instead just modify a value passed in. This patch converts the _enable_wakeup() and _disable_wakeup() helper functions to take a value argument and only modify it instead of actually writing the register. This makes the wakeup helpers consistent with the other helper functions and avoids unintentional problems like the following. This problem was found after discovering that GPIO wakeups were no longer functional. The root cause was that the ENAWAKEUP bit of the SYSCONFIG register was being unintentionaly overwritten, leaving wakeups disabled after the following two commits were combined: commit: 9980ce53c97392a3dbdc9d1ac3e455d79b4167ed OMAP: hwmod: Enable module wakeup if in smartidle commit: 78f26e872f77b6312273216de1a8f836c6f2e143 OMAP: hwmod: Set autoidle after smartidle during _sysc_enable There resulting in code in _enable_sysc() was this: /* * XXX The clock framework should handle this, by * calling into this code. But this must wait until the * clock structures are tagged with omap_hwmod entries */ if ((oh->flags & HWMOD_SET_DEFAULT_CLOCKACT) && (sf & SYSC_HAS_CLOCKACTIVITY)) _set_clockactivity(oh, oh->class->sysc->clockact, &v); _write_sysconfig(v, oh); so here, 'v' has wakeups disabled. /* If slave is in SMARTIDLE, also enable wakeup */ if ((sf & SYSC_HAS_SIDLEMODE) && !(oh->flags & HWMOD_SWSUP_SIDLE)) _enable_wakeup(oh); Here wakeup is enabled in the SYSCONFIG register (but 'v' is not updated) /* * Set the autoidle bit only after setting the smartidle bit * Setting this will not have any impact on the other modules. */ if (sf & SYSC_HAS_AUTOIDLE) { idlemode = (oh->flags & HWMOD_NO_OCP_AUTOIDLE) ? 0 : 1; _set_module_autoidle(oh, idlemode, &v); _write_sysconfig(v, oh); } And here, SYSCONFIG is updated again using 'v', which does not have wakeups enabled, resulting in ENAWAKEUP being cleared. Special thanks to Benoit Cousson for pointing out that wakeups were supposed to be automatically enabled when a hwmod is enabled, and thus helping target the root cause of this problem. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Signed-off-by: Benoit Cousson <b-cousson@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2010-12-21OMAP4: hwmod & clock data: Fix GPIO opt_clks and ocp_if iclkBenoit Cousson
Fix opt clocks name in clock framework and hwmod. Add the missing iclk in the ocp_if structure. Add the HWMOD_CONTROL_OPT_CLKS_IN_RESET flag to ensure the the GPIO optional clock is enable during reset. Signed-off-by: Benoit Cousson <b-cousson@ti.com> Tested-by: Charulatha V <charu@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Rajendra Nayak <rnayak@ti.com>
2010-12-21OMAP4: hwmod data: Add IVA and DSPBenoit Cousson
Add IVA and DSP hwmods in order to allow the pm code to initialize properly the processors devices during omap2_init_processor_devices. It will avoid the following warnings. _init_omap_device: could not find omap_hwmod for iva _init_omap_device: could not find omap_hwmod for dsp Signed-off-by: Benoit Cousson <b-cousson@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Kevin Hilman <khilman@deeprootsystems.com>
2010-12-21OMAP4: hwmod data: Fix missing address in DMM and EMIF_FWBenoit Cousson
The DMM is a piece of interconnect that need to be configured properly for the tiler functionnality. It thus exposes some configuration registers that were missing previously. Signed-off-by: Benoit Cousson <b-cousson@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
2010-12-21OMAP4: hwmod data: Add SYSS_HAS_RESET_STATUS flagBenoit Cousson
Update the data for GPIO, UART, WD_TIMER and I2C in order to support the new reset status flag introduce in the following commit: commit 2cb068149c365f1c2b10f2ece6786139527dcc16 OMAP: hwmod: Fix softreset status check for some new OMAP4 IPs Without this flag properly set, the reset is done, but the hwmod core code will not wait for the reset completion to continue its excecution. Signed-off-by: Benoit Cousson <b-cousson@ti.com> Tested-by: Charulatha V <charu@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Govindraj.R <govindraj.raja@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com>
2010-12-21OMAP4: hwmod data: Fix hwmod entries orderBenoit Cousson
The original OMAP4 hwmod data files is fully generated from HW database. But since the file is introduced incrementaly along with driver that uses the data, it has to be splitted by the driver owner and then re-merged by the maintainer. Because of the similarity of the data, git is completely lost during such merge and thus the data does not look like the original one at the end. Re-order properly the structures to stay in sync with original data set. This makes it much easier to diff the autogenerated script output with what's in mainline, see differences, and generate patches for those diffs. The goal is to stay in sync with the autogenerated data from now on. Add a comment that does contain all the IPs that can have a hwmod, but do not have it in the file for the moment. It gives a good indication of the progress. Signed-off-by: Benoit Cousson <b-cousson@ti.com> [paul@pwsan.com: updated to apply against current core integration branch, commit message slightly amplified; fixed opt_clks_cnt whitespace] Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Govindraj.R <govindraj.raja@ti.com> Cc: Charulatha V <charu@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com>
2010-12-21OMAP1: clock_data: use runtime cpu / machine checksJanusz Krzysztofik
Otherwise multi-omap1 configurations may set wrong clock speed. Created and tested against l-o master on Amstrad Delta. Signed-off-by: Janusz Krzysztofik <jkrzyszt@tis.icnet.pl> Signed-off-by: Paul Walmsley <paul@pwsan.com>
2010-12-21OMAP2/3: SRAM: add comment about crashes during a TLB missPaul Walmsley
Some users were observing crashes during the execution of CORE DVFS code from OCM RAM -- a locally-modified copy of the linux-omap code. Richard Woodruff tracked this down to a DTLB miss which had been inadvertently and intermittently caused by the local modifications. (The TLB miss caused the ARM MMU to attempt to walk the page tables stored in SDRAM, which was not possible since SDRAM is off-line for a portion of the CORE DVFS OCM RAM code.) Add a note to the OMAP2 & OMAP3 CORE DVFS SRAM code to warn others that changes may result in crashes here if they are not carefully tested. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Richard Woodruff <r-woodruff2@ti.com> Cc: Jon Hunter <jon-hunter@ti.com> Cc: Nishanth Menon <nm@ti.com>
2010-12-21OMAP3: clock: fix incorrect rate display when switching MPU rate at bootPaul Walmsley
The OMAP3 clock code contains some legacy code to allow the MPU rate to be specified as a kernel command line parameter. If the 'mpurate' parameter is specified, the kernel will attempt to switch the MPU rate to this rate during boot. As part of this process, a short message "Switched to new clocking rate" is generated -- and in this message, the "Core" clock rate and "MPU" clock rate are transposed. This patch ensures that the clock rates are displayed in the correct order. Thanks to Bruno Guerin <br.guerin@free.fr> for reporting this bug and proposing a fix. Thanks to Richard Woodruff <r-woodruff2@ti.com> for reviewing the problem and passing the report on. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Bruno Guerin <br.guerin@free.fr> Cc: Richard Woodruff <r-woodruff2@ti.com>
2010-12-21OMAP3: clock: clarify usage of struct clksel_rate.flags and struct omap_clk.cpuPaul Walmsley
Clarify the usage of the struct omap_clk.cpu flags (e.g., CK_*) to use bits only for individual SoC variants (e.g., CK_3430ES1, CK_3505, etc.). Superset flags, such as CK_3XXX or CK_AM35XX, are now defined as disjunctions of individual SoC variant flags. This simplifies the definition and use of these flags. struct omap_clk record definitions can now simply specify the bitmask of actual SoCs that the records are valid for. The clock init code can simply set a single CPU type mask bit for the SoC that is currently in use, and test against that, rather than needing to set some combination of flags. Similarly, clarify the use of struct clksel_rate.flags. The bit allocated for RATE_IN_3XXX has been reassigned, and RATE_IN_3XXX has been defined as a disjunction of the 34xx and 36xx rate flags. The advantages are the same as the above. Clarify the usage of struct omap_clk.cpu flags such as CK_34XX to only apply to the SoCs that they name, e.g., OMAP34xx chips. The previous practice caused significantly different SoCs, such as OMAP36xx, to be included in CK_34XX. In my opinion, this is much more intuitive. Similarly, clarify the use of struct clksel_rate.flags, such that RATE_IN_3430ES2PLUS now only applies to 34xx chips with ES level >= 2 - it does not apply to OMAP36xx. ... At some point, it probably makes sense to collapse the CK_* and RATE_IN_* flags together into a single bitfield, and possibly use the existing CHIP_IS_OMAP* flags for platform detection. ... This all seems to work fine on OMAP34xx and OMAP36xx Beagle. Not sure if it works on Sitara or the TI816X, unfortunately I don't have any here to test with. Signed-off-by: Paul Walmsley <paul@pwsan.com>
2010-12-21OMAP2xxx clock: fix dss2_fck recalc to use clkselPaul Walmsley
dss2_fck is a clksel clock, and therefore its rate should be recalculated with the clksel mechanism. This was working in early 2009, but was one of the casualties of the big OMAP clock merge between 2.6.29 and 2.6.30. Signed-off-by: Paul Walmsley <paul@pwsan.com>
2010-12-21OMAP4: clock data: Export control to enable/disable CORE/PER M3 clocksRajendra Nayak
The CORE and PER M3 post dividers are different from the rest of the DPLL post dividers as in they go to SCRM, and are used there to export clocks for instance used by external sensor. There is no automatic HW dependency in PRCM to manage them. Hence these two clocks (dpll post dividers) should be managed by SW and explicitly enabled/disabled. Add control in clock framework to handle that. Signed-off-by: Rajendra Nayak <rnayak@ti.com> Signed-off-by: Benoit Cousson <b-cousson@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>