- 19 9月, 2014 1 次提交
-
-
由 Joe Perches 提交于
Use the more common pr_warn. Other miscellanea: o Realign arguments Signed-off-by: NJoe Perches <joe@perches.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
- 04 7月, 2014 7 次提交
-
-
由 Tero Kristo 提交于
Control module related PM initializations are now moved within control module driver. Done in preparation to isolate the code to its own driver. Signed-off-by: NTero Kristo <t-kristo@ti.com>
-
由 Tero Kristo 提交于
Done in preparation to move PRM into its own driver. Signed-off-by: NTero Kristo <t-kristo@ti.com>
-
由 Tero Kristo 提交于
This patch moves the functionality from PM core to control driver. Signed-off-by: NTero Kristo <t-kristo@ti.com>
-
由 Tero Kristo 提交于
Helps to isolate the PRM driver. Signed-off-by: NTero Kristo <t-kristo@ti.com>
-
由 Tero Kristo 提交于
This is a more proper isolation of the code. Done in preparation of making PRM an individual driver. Signed-off-by: NTero Kristo <t-kristo@ti.com>
-
由 Tero Kristo 提交于
This is a more proper isolation of the code. Done in preparation of making PRM an individual driver. Signed-off-by: NTero Kristo <t-kristo@ti.com>
-
由 Tero Kristo 提交于
Done in preparation to make the prm an individual driver. Signed-off-by: NTero Kristo <t-kristo@ti.com>
-
- 20 5月, 2014 1 次提交
-
-
由 Dave Gerlach 提交于
In omap2_common_pm_late_init suspend_set_ops was called to set common suspend handling functions for all omap platforms. This created two problems. First, these suspend ops were being set for all platforms, regardless of whether or not suspend support has been integrated so in the case of AM33XX, suspend to mem was presented as available but failed every time. Second, some platforms will need to define a completely separate set of suspend ops, such as AM33XX, due to differences from previous omap platforms so there is no need to always set the common omap ops. This patch moves the suspend_set_ops call from omap2_common_pm_late_init into a separate function that then gets called in the omap*_pm_init functions for each platform. Signed-off-by: NDave Gerlach <d-gerlach@ti.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
- 07 5月, 2014 1 次提交
-
-
由 Tony Lindgren 提交于
While debugging legacy mode vs device tree booted PM regressions, I noticed that omap3 is not toggling sys_clkreq and sys_off_mode pins like it should. The sys_clkreq and sys_off_mode pins are not toggling because of the following issues: 1. The default polarity for the sys_off_mode pin is wrong. OFFMODE_POL needs to be cleared for sys_off_mode to go down when hitting off-idle, while CLKREQ_POL needs to be set so sys_clkreq goes down when hitting retention. 2. The values for voltctrl register need to be updated dynamically. We need to set either the retention idle bits, or off idle bits in the voltctrl register depending the idle mode we're targeting to hit. Let's fix these two issues as otherwise the system will just hang if any twl4030 PMIC idle scripts are loaded. The only case where the system does not hang is if only retention idle over I2C4 is configured by the bootloader. Note that even without the twl4030 PMIC scripts, these fixes will do the proper signaling of sys_clkreq and sys_off_mode pins, so the fixes are needed to fix monitoring of PM states with LEDs or an oscilloscope. Cc: Kevin Hilman <khilman@linaro.org> Cc: Nishanth Menon <nm@ti.com> Cc: Paul Walmsley <paul@pwsan.com> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
- 11 4月, 2014 1 次提交
-
-
由 Tero Kristo 提交于
There is a solitary write to this register every wakeup from off-mode, which isn't doing anything, so remove it. Also note that modifying this register trashes any attempted voltage scaling configuration and the change probably should never have gotten merged in the first place. Cc: Nishanth Menon <nm@ti.com> Cc: Kevin Hilman <khilman@linaro.org> Cc: Paul Walmsley <paul@pwsan.com> Signed-off-by: NTero Kristo <t-kristo@ti.com> [tony@atomide.com: updated comments to describe regression] Signed-off-by: NTony Lindgren <tony@atomide.com>
-
- 26 11月, 2013 1 次提交
-
-
由 Olof Johansson 提交于
Some omap3 code is throwing a warning: arch/arm/mach-omap2/pm34xx.c: In function 'omap3_save_secure_ram_context': arch/arm/mach-omap2/pm34xx.c:123:32: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] In reality this code will never actually execute with LPAE=y, since Cortex-A8 doesn't support it. So downcasting the __pa() is safe in this case. Signed-off-by: NOlof Johansson <olof@lixom.net> Acked-by: NTony Lindgren <tony@atomide.com>
-
- 20 10月, 2013 1 次提交
-
-
由 Tero Kristo 提交于
OMAP3 PM core requires IVA2 bootmode to be set to idle during init. Currently, a direct register write is used for this. Add a new ctrl API for this purpose instead. Signed-off-by: NTero Kristo <t-kristo@ti.com> Signed-off-by: NPaul Walmsley <paul@pwsan.com>
-
- 31 5月, 2013 1 次提交
-
-
由 Tony Lindgren 提交于
Commit a819c4f1 (ARM: OMAP3: PM: Only access IVA if one exists) changed PM to not access IVA registers on omaps that don't have them. Turns out we still need to idle iva2 as otherwise iva2_pwrdm will stay on and block deeper idle states. It seems that the only part of the reset that may not be needed is the setting of the iva2 boot mode to idle. But as that register seems to be there and is harmless if no iva2 is on the SoC, it's probably safest to do the complete reset. Acked-by: NMark A. Greer <mgreer@animalcreek.com> Acked-by: NKevin Hilman <khilman@linaro.org> Tested-by: NYegor Yefremov <yegorslists@googlemail.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
- 28 3月, 2013 1 次提交
-
-
由 Santosh Shilimkar 提交于
On OMAP platform, FIQ is reserved for secure environment only. If at all the FIQ needs to be disabled, it involves going through security API call. Hence the local_fiq_[enable/disable]() in the OMAP code is bogus. On GP devices too, the fiq is disabled for non-secure software. So just get rid of it. Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
-
- 26 1月, 2013 1 次提交
-
-
由 Paul Gortmaker 提交于
The text in Documentation said it would be removed in 2.6.41; the text in the Kconfig said removal in the 3.1 release. Either way you look at it, we are well past both, so push it off a cliff. Note that the POWER_CSTATE and the POWER_PSTATE are part of the legacy tracing API. Remove all tracepoints which use these flags. As can be seen from context, most already have a trace entry via trace_cpu_idle anyways. Also, the cpufreq/cpufreq.c PSTATE one is actually unpaired, as compared to the CSTATE ones which all have a clear start/stop. As part of this, the trace_power_frequency also becomes orphaned, so it too is deleted. Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com> Acked-by: NSteven Rostedt <rostedt@goodmis.org> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 01 12月, 2012 1 次提交
-
-
由 Tony Lindgren 提交于
Based on earlier discussions[1] we attempted to find a suitable location for the omap DMA header in commit 2b6c4e73 (ARM: OMAP: DMA: Move plat/dma.h to plat-omap/dma-omap.h) until the conversion to dmaengine is complete. Unfortunately that was before I was able to try to test compile of the ARM multiplatform builds for omap2+, and the end result was not very good. So I'm creating yet another all over the place patch to cut the last dependency for building omap2+ for ARM multiplatform. After this, we have finally removed the driver dependencies to the arch/arm code, except for few drivers that are being worked on. The other option was to make the <plat-omap/dma-omap.h> path to work, but we'd have to add some new header directory to for multiplatform builds. Or we would have to manually include arch/arm/plat-omap/include again from arch/arm/Makefile for omap2+. Neither of these alternatives sound appealing as they will likely lead addition of various other headers exposed to the drivers, which we want to avoid for the multiplatform kernels. Since we already have a minimal include/linux/omap-dma.h, let's just use that instead and add a note to it to not use the custom omap DMA functions any longer where possible. Note that converting omap DMA to dmaengine depends on dmaengine supporting automatically incrementing the FIFO address at the device end, and converting all the remaining legacy drivers. So it's going to be few more merge windows. [1] https://patchwork.kernel.org/patch/1519591/# cc: Russell King <linux@arm.linux.org.uk> cc: Kevin Hilman <khilman@ti.com> cc: "Benoît Cousson" <b-cousson@ti.com> cc: Herbert Xu <herbert@gondor.apana.org.au> cc: "David S. Miller" <davem@davemloft.net> cc: Vinod Koul <vinod.koul@intel.com> cc: Dan Williams <djbw@fb.com> cc: Mauro Carvalho Chehab <mchehab@infradead.org> cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> cc: Guennadi Liakhovetski <g.liakhovetski@gmx.de> cc: David Woodhouse <dwmw2@infradead.org> cc: Kyungmin Park <kyungmin.park@samsung.com> cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> cc: Tomi Valkeinen <tomi.valkeinen@ti.com> cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de> cc: Hans Verkuil <hans.verkuil@cisco.com> cc: Vaibhav Hiremath <hvaibhav@ti.com> cc: Lokesh Vutla <lokeshvutla@ti.com> cc: Rusty Russell <rusty@rustcorp.com.au> cc: Artem Bityutskiy <artem.bityutskiy@linux.intel.com> cc: Afzal Mohammed <afzal@ti.com> cc: linux-crypto@vger.kernel.org cc: linux-media@vger.kernel.org cc: linux-mtd@lists.infradead.org cc: linux-usb@vger.kernel.org cc: linux-fbdev@vger.kernel.org Acked-by: NFelipe Balbi <balbi@ti.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
- 09 11月, 2012 1 次提交
-
-
由 Paul Walmsley 提交于
arch/arm/mach-omap2/prcm.c and arch/arm/plat-omap/include/plat/prcm.h are now completely unused and can be removed. Signed-off-by: NPaul Walmsley <paul@pwsan.com> Tested-by: NVaibhav Hiremath <hvaibhav@ti.com>
-
- 01 11月, 2012 1 次提交
-
-
由 Tony Lindgren 提交于
Most of the defines are specific to omap1 and omap2+, and should be in the local headers. Only minimal function prototypes need to be shared. As discussed on linux-arm-kernel, we want to avoid relative includes for the arch/arm/*omap* shared code: http://www.spinics.net/lists/linux-omap/msg80520.html So this patch re-adds a minimal plat/sram.h. The new plat/sram.h must not be included from drivers, that will break build for omap2+ CONFIG_MULTIPLATFORM. Note that this patch temporarily adds two more relative includes; Those will be removed in the following patch. Signed-off-by: NTony Lindgren <tony@atomide.com>
-
- 23 10月, 2012 1 次提交
-
-
由 Paul Walmsley 提交于
On OMAP34xx/35xx, and OMAP36xx chips with ES < 1.2, if the PER powerdomain goes to OSWR or OFF while CORE stays at CSWR or ON, or if, upon chip wakeup from OSWR or OFF, the CORE powerdomain goes ON before PER, the UART3/4 FIFOs and McBSP2/3 SIDETONE memories will be unusable. This is erratum i582 in the OMAP36xx Silicon Errata document. This patch implements one of several parts of the workaround: the addition of the wakeup dependency between the PER and WKUP clockdomains, such that PER will wake up at the same time CORE_L3 does. This is not a complete workaround. For it to be complete: 1. the PER powerdomain's next power state must not be set to OSWR or OFF if the CORE powerdomain's next power state is set to CSWR or ON; 2. the UART3/4 FIFO and McBSP2/3 SIDETONE loopback tests should be run if the LASTPOWERSTATEENTERED bits for PER and CORE indicate that PER went OFF while CORE stayed on. If loopback tests fail, then those devices will be unusable until PER and CORE can undergo a transition from ON to OSWR/OFF and back ON. Signed-off-by: NPaul Walmsley <paul@pwsan.com> Cc: Tero Kristo <t-kristo@ti.com> Cc: Kevin Hilman <khilman@ti.com> Signed-off-by: NKevin Hilman <khilman@ti.com>
-
- 21 10月, 2012 2 次提交
-
-
由 Paul Walmsley 提交于
Move OMAP3xxx-specific CM functions & macros into cm3xxx.[ch] and OMAP2xxx-specific macros into cm2xxx.[ch]. Move basic CM register access functions into static inline functions in cm2xxx_3xxx.h, leaving only OMAP2/3 hardreset functions in cm2xxx_3xxx.c. As part of this, split the CM and hwmod code that waits for devices to become ready into SoC-specific functions. This is in preparation for the upcoming move of this code to drivers/. Signed-off-by: NPaul Walmsley <paul@pwsan.com> Reviewed-by: NRuss Dill <Russ.Dill@ti.com> Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
-
由 Paul Walmsley 提交于
Move OMAP3xxx-specific PRM functions & macros into prm3xxx.[ch] and OMAP2xxx-specific macros into prm2xxx.h. (prm2xxx.c will be created by a subsequent patch when it's needed.) Move basic PRM register access functions into static inline functions in prm2xxx_3xxx.h, leaving only OMAP2/3 hardreset functions in prm2xxx_3xxx.c. Also clarify the initcall function naming to reinforce that this code is specifically for the PRM IP block. This is in preparation for the upcoming powerdomain series and the upcoming move of this code to drivers/. Signed-off-by: NPaul Walmsley <paul@pwsan.com> Reviewed-by: NRuss Dill <Russ.Dill@ti.com> Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
-
- 19 10月, 2012 1 次提交
-
-
由 Tony Lindgren 提交于
We want to remove plat/cpu.h. To do this, let's first split it to private soc.h to mach-omap1 and mach-omap2. We have to keep plat/cpu.h around until the remaining drivers are fixed, so let's include the local soc.h in plat/cpu.h and for drivers still including plat/cpu.h. Once the drivers are fixed not to include plat/cpu.h, we can remove the file. This is needed for the ARM common zImage support. [tony@atomide.com: updated to not print a warning] Signed-off-by: NTony Lindgren <tony@atomide.com>
-
- 18 10月, 2012 2 次提交
-
-
由 Tony Lindgren 提交于
We can move this from plat to be local to plat-omap for common ARM zImage support. Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Paul Walmsley 提交于
Remove arch/arm/plat-omap/include/plat/sdrc.h by folding its contents into arch/arm/mach-omap2/sdrc.h. The objective is to assist Tony in cleaning out arch/arm/plat-omap/, as his upstreams request. Signed-off-by: NPaul Walmsley <paul@pwsan.com> Cc: Tony Lindgren <tony@atomide.com> [tony@atomide.com: updated to remove rotate macros] Signed-off-by: NTony Lindgren <tony@atomide.com>
-
- 16 10月, 2012 1 次提交
-
-
由 Lokesh Vutla 提交于
Move plat/dma.h to plat-omap/dma-omap.h as part of single zImage work Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
- 15 10月, 2012 1 次提交
-
-
由 Afzal Mohammed 提交于
Requirement of gpmc header outside of mach-omap2 has been cutoff, move gpmc header file in plat-omap folder to local mach-omap2 folder Objective - common zImage participation of omap Signed-off-by: NAfzal Mohammed <afzal@ti.com>
-
- 13 9月, 2012 1 次提交
-
-
由 Tony Lindgren 提交于
This way we can remove includes of plat/gpio.h which won't work with the single zImage support. Note that we also remove the cpu_class_is_omap2() check in gpio-omap.c as the drivers should not call it as we need to make it local to arch/arm/mach-omap2 for single zImage support. While at it, arrange the related includes in the standard way. Cc: Grant Likely <grant.likely@secretlab.ca> Cc: linux-mtd@lists.infradead.org Cc: alsa-devel@alsa-project.org Acked-by: NLinus Walleij <linus.walleij@linaro.org> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
- 12 9月, 2012 1 次提交
-
-
由 Paul Walmsley 提交于
Find and unwrap wrapped strings in the style: pr_debug("clockdomain: hardware cannot set/clear wake up of " "%s when %s wakes up\n", clkdm1->name, clkdm2->name); Keeping these strings contiguous seems to be the current Linux kernel policy. The offending lines were found with the following command: pcregrep -rnM '"\s*$\s*"' arch/arm/*omap* While here, some messages have been clarified, some pr_warning( ... calls have been converted to pr_warn( ..., and some printk(KERN_* ... have been converted to pr_*. Signed-off-by: NPaul Walmsley <paul@pwsan.com>
-
- 08 8月, 2012 1 次提交
-
-
由 Kevin Hilman 提交于
This reverts commit 58f0829b. Converstion to per-pwrdm per/post transition calls was a bit premature. Only tracking MPU, PER & CORE in the idle path means we lose the accounting for all the other powerdomains which may also transition in idle. On OMAP3, due to autodeps, several powerdomains transition along with MPU (e.g. DSS, USBHOST), and the accounting for these was lost with this patch. Since the accounting includes the context loss counters, drivers for devices in those power domains would never notice context lost, so would likely hang after any off-mode transitions. This patch should be revisited when the upcoming clkdm/pwrmdm/voltdm use-counting seires is merged since then we can properly do accounting without relying on a call in the idle path. In addition, the original patch had another bug because the PER powerdomain accounting was not updated until after the GPIO resume hook is called. Since gpio_resume_after_idle() checks the context loss count (which is not yet updated) it would not properly restore context, leaving the GPIO banks in an undefined state. Cc: Jean Pihet <jean.pihet@newoldbits.com> Cc: Tero Kristo <t-kristo@ti.com> Cc: Rajendra Nayak <rnayak@ti.com> Reported-by: NPaul Walmsley <paul@pwsan.com> Signed-off-by: NKevin Hilman <khilman@ti.com>
-
- 26 6月, 2012 3 次提交
-
-
由 Kevin Hilman 提交于
commit e7410cf7 (OMAP3: PM: move device-specific special cases from PM core into CPUidle) moved mangement of cam_pwrdm to CPUidle but left some remnants behind, namely the call to clkcm_allo_idle() for the clockdomains in the MPU pwrdm. Remove these since they are not necessary and cause unwanted latency in the idle path. Acked-by: NTero Kristo <Tero Kristo <t-kristo@ti.com> Reviewed-by: NSantosh Shilimkar <santosh.shilimkar@ti.com> Tested-by: NSantosh Shilimkar <santosh.shilimkar@ti.com> Tested-by: NGrazvydas Ignotas <notasas@gmail.com> Signed-off-by: NKevin Hilman <khilman@ti.com>
-
由 Kevin Hilman 提交于
We only need to call the pre/post transtion methods when we know the power state is changing. First, split up the pre/post transition calls to be per-powerdomain, and then make them conditional on whether the power domain is actually changing states. Reviewed-by: NSantosh Shilimkar <santosh.shilimkar@ti.com> Tested-by: NSantosh Shilimkar <santosh.shilimkar@ti.com> Tested-by: NGrazvydas Ignotas <notasas@gmail.com> Signed-off-by: NKevin Hilman <khilman@ti.com>
-
由 Kevin Hilman 提交于
Iteration over all power domains in the idle path is unnecessary since only power domains that are transitioning need to be accounted for. Also PRCM register accesses are known to be expensive, so the additional latency added to the idle path is signficiant. In order allow the pre/post transitions to be isolated and called per-pwrdm, change the API so passing in a specific power domain will trigger the pre/post transtion accounting for only that specific power domain. Passing NULL means iterating over all power domains as is current behavior. Reviewed-by: NSantosh Shilimkar <santosh.shilimkar@ti.com> Tested-by: NSantosh Shilimkar <santosh.shilimkar@ti.com> Tested-by: NGrazvydas Ignotas <notasas@gmail.com> Acked-by: NPaul Walmsley <paul@pwsan.com> Signed-off-by: NKevin Hilman <khilman@ti.com>
-
- 22 6月, 2012 3 次提交
-
-
由 Vishwanath BS 提交于
As IO Daisy chain sequence is triggered via hwmod mux, there is no need to control it from cpuidle path for OMAP3. Also as omap3_disable_io_chain is no longer being used, just remove the function. Signed-off-by: NVishwanath BS <vishwanath.bs@ti.com> Signed-off-by: NTero Kristo <t-kristo@ti.com> Reviewed-by: NRajendra Nayak <rnayak@ti.com> Signed-off-by: NPaul Walmsley <paul@pwsan.com>
-
由 Vishwanath BS 提交于
Since IO Daisychain modifies only PRM registers, it makes sense to move it to PRM File. Also changed the timeout value for IO chain enable to 100us and added a wait for status disable at the end. Thanks to Nishanth Menon <nm@ti.com> for contributing a fix to the timeout code waiting for WUCLKOUT to go high. Signed-off-by: NVishwanath BS <vishwanath.bs@ti.com> Signed-off-by: NTero Kristo <t-kristo@ti.com> Cc: Nishanth Menon <nm@ti.com> Reviewed-by: NRajendra Nayak <rnayak@ti.com> [paul@pwsan.com: renamed omap3_trigger_io_chain() to better describe the end result and to match other PRM functions; removed omap3_disable_io_chain(); moved MAX_IOPAD_LATCH_TIME to prcm-common as it will also be used by the OMAP4 code; removed unnecessary barrier; added kerneldoc; added credit for fix from Nishanth] Signed-off-by: NPaul Walmsley <paul@pwsan.com>
-
由 Mohan V 提交于
Currently the enabling and disabling of IO Daisy chain is not according to the TRM. The below steps are followed to enable/ disable the IO chain, based loosely on the "Sec 3.5.7.2.2 I/O Wake-Up Mechanism" section in OMAP3630 Public TRM[1]. Steps to enable IO chain: [a] Set PM_WKEN_WKUP.EN_IO bit [b] Set the PM_WKEN_WKUP.EN_IO_CHAIN bit [c] Poll for PM_WKST_WKUP.ST_IO_CHAIN. [d] When ST_IO_CHAIN bit set to 1, clear PM_WKEN_WKUP.EN_IO_CHAIN [e] Clear ST_IO_CHAIN bit. Steps to disable IO chain: [a] Clear PM_WKEN_WKUP.EN_IO_CHAIN bit [b] Clear PM_WKEN_WKUP.EN_IO bit [c] Clear PM_WKST_WKUP.ST_IO bit by writing 1 to it. Step [e] & [c] in each case can be skipped, as these are handled by the PRCM interrupt handler later. [1] http://focus.ti.com/pdfs/wtbu/OMAP36xx_ES1.x_PUBLIC_TRM_vV.zipSigned-off-by: NMohan V <mohanv@ti.com> Signed-off-by: NVishwanath BS <vishwanath.bs@ti.com> [paul@pwsan.com: modified commit message to clarify that these steps are based loosely on the TRM section, rather than documented exactly] Reviewed-by: NRajendra Nayak <rnayak@ti.com> [paul@pwsan.com: resolved new warnings from checkpatch] Signed-off-by: NPaul Walmsley <paul@pwsan.com>
-
- 20 6月, 2012 1 次提交
-
-
由 Mark A. Greer 提交于
prcm_setup_regs() blindly accesses IVA bits in the PRM and calls omap3_iva_idle() which does more IVA related register accesses. Only do this if the IVA hardware actually exists. Signed-off-by: NMark A. Greer <mgreer@animalcreek.com> Signed-off-by: NKevin Hilman <khilman@ti.com>
-
- 12 5月, 2012 1 次提交
-
-
由 Kevin Hilman 提交于
By default, request_irq() will auto-enable the requested IRQ. For PRCM interrupts, we may want to avoid that until the PM core code is fully ready to handle the interrupts. This is particularily true for IO pad interrupts on OMAP3, which are shared between the hwmod core and the PRM core. In order to avoid PRCM IO-chain interrupts until the PM core is ready to handle them, ready, set the IRQ_NOAUTOEN flag for the PRCM IO-chain interrupt, which means it will remain disabled after request_irq(). Then, explicitly enable the PRCM interrupts after the request_irq() in the PM core (but not in the hwmod core.) Special thanks to Tero Kristo for suggesting to isolate the fix to only the IO-chain interrupt on OMAP3 instead of all PRCM interrupts. Cc: Tero Kristo <t-kristo@ti.com> Acked-by: NPaul Walmsley <paul@pwsan.com> Signed-off-by: NKevin Hilman <khilman@ti.com>
-
- 08 5月, 2012 1 次提交
-
-
由 Shawn Guo 提交于
Signed-off-by: NShawn Guo <shawn.guo@linaro.org> Acked-by: NTony Lindgren <tony@atomide.com>
-
- 18 4月, 2012 1 次提交
-
-
由 Paul Walmsley 提交于
Resolve some warnings identified by cppcheck in arch/arm/mach-omap2: [arch/arm/mach-omap2/usb-tusb6010.c:129]: (style) Checking if unsigned variable 'tmp' is less than zero. [arch/arm/mach-omap2/prm_common.c:241]: (error) Possible null pointer dereference: irq_setup - otherwise it is redundant to check if irq_setup is null at line 247 [arch/arm/mach-omap2/pm34xx.c:790]: (style) Variable 'per_clkdm' is assigned a value that is never used [arch/arm/mach-omap2/pm34xx.c:790]: (style) Variable 'core_clkdm' is assigned a value that is never used [arch/arm/mach-omap2/pm24xx.c:185]: (style) Variable 'only_idle' is assigned a value that is never used [arch/arm/mach-omap2/mux.c:254]: (error) Possible null pointer dereference: mux [arch/arm/mach-omap2/mux.c:258]: (error) Possible null pointer dereference: mux [arch/arm/mach-omap2/gpmc-onenand.c:178]: (style) Variable 'tick_ns' is assigned a value that is never used [arch/arm/mach-omap2/gpio.c:56]: (error) Possible null pointer dereference: pdata - otherwise it is redundant to check if pdata is null at line 57 [arch/arm/mach-omap2/devices.c:45]: (style) Variable 'l' is assigned a value that is never used [arch/arm/mach-omap2/board-omap3evm.c:641] -> [arch/arm/mach-omap2/board-omap3evm.c:639]: (style) Found duplicate branches for if and else. [arch/arm/mach-omap2/am35xx-emac.c:95]: (style) Variable 'regval' is assigned a value that is never used [arch/arm/mach-omap2/devices.c:74]: (style) Variable 'l' is assigned a value that is never used [arch/arm/mach-omap2/pm34xx.c:277]: (style) Variable 'per_prev_state' is assigned a value that is never used [arch/arm/plat-omap/dmtimer.c:352]: (error) Possible null pointer dereference: timer - otherwise it is redundant to check if timer is null at line 354 [arch/arm/plat-omap/omap_device.c:478]: (style) Variable 'c' is assigned a value that is never used [arch/arm/plat-omap/usb.c:42]: (style) Variable 'status' is assigned a value that is never used [arch/arm/mach-omap1/clock.c:197]: (style) Variable 'dpll1_rate' is assigned a value that is never used [arch/arm/mach-omap1/lcd_dma.c:60]: (style) struct or union member 'lcd_dma_info::size' is never used [arch/arm/mach-omap1/pm.c:572]: (style) Variable 'entry' is assigned a value that is never used Some of them are pretty good catches, such as gpio.c:56 and usb-tusb6010.c:129. Thanks to Jarkko Nikula for some comments on the sscanf() warnings. It seems that the kernel sscanf() ignores the field width anyway for the %d format, so those changes have been dropped from this second version. Thanks to Daniel Marjamäki <daniel.marjamaki@gmail.com> for pointing out that a variable was unnecessarily marked static in the board-omap3evm.c change. Signed-off-by: NPaul Walmsley <paul@pwsan.com> Cc: Felipe Balbi <balbi@ti.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Kevin Hilman <khilman@ti.com> Cc: Peter Ujfalusi <peter.ujfalusi@ti.com> Cc: Jarkko Nikula <jarkko.nikula@bitmer.com> Cc: Charulatha Varadarajan <charu@ti.com> Cc: Daniel Marjamäki <daniel.marjamaki@gmail.com> Cc: Tarun Kanti DebBarma <tarun.kanti@ti.com> Reviewed-by: Charulatha Varadarajan <charu@ti.com> # for gpio.c
-