- 22 Dec, 2010 40 commits
-
-
Rajendra Nayak authored
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>
-
Benoit Cousson authored
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 authored
_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 authored
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 authored
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:
-
Kevin Hilman authored
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: 9980ce53 OMAP: hwmod: Enable module wakeup if in smartidle commit: 78f26e87 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:
Kevin Hilman <khilman@deeprootsystems.com>
-
Benoit Cousson authored
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:
Charulatha V <charu@ti.com> Signed-off-by:
-
Benoit Cousson authored
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 authored
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 authored
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 2cb06814 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 authored
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:
-
Janusz Krzysztofik authored
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 authored
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 authored
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 authored
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 authored
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: -
Rajendra Nayak authored
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 authored
Add support for auxiliary clocks nodes which are part of SCRM. Signed-off-by:
-
Jonathan Bergsagel authored
Add register address, mask and link to the clksel structure that were missing in the IVA DPLL mux clock node. Signed-off-by:
Jonathan Bergsagel <jbergsagel@ti.com> Signed-off-by:
-
Thara Gopinath authored
This patch extends the OMAP4 clock data to include various x2 clock nodes between DPLL and HS dividers as the clock framework skips a x2 while calculating the dpll locked frequency. The clock database extensions are autogenerated using the scripts maintained by Benoit Cousson. Signed-off-by:
Thara Gopinath <thara@ti.com> [paul@pwsan.com: fixed merge conflicts against v2.6.37-rc5; dropped dpll_mpu_x2_ck on advice from Benoît] Signed-off-by:
-
Benoit Cousson authored
The smartreflex modules belong to an ALWON_FCLK clock domain that does not have any SW control. The gating of that interface clock is triggered by a transition of the WKUP clock domain to idle. Attach both smartreflex instances on OMAP3 to the WKUP clock domain. The missing clock domain field in srX_fck clock nodes was reported by Kevin during the discussion about smartreflex on OMAP3: https://patchwork.kernel.org/patch/199342/Signed-off-by:
-
Benoit Cousson authored
The gating of pad_clks and slimbus_ck is controlled by the PRCM, but since the clock source is external, this is the SW responsability to gate / un-gate it when the mcpdm or slimbus module need to be used. There is no autogating possible with such external clock. Add SW control to enable / disable this SW gating in the pad_clks_ck and slimbus_clk clock node. Signed-off-by:
Sebastien Guiriec <s-guiriec@ti.com> Signed-off-by:
-
Paul Walmsley authored
Move the padconf save code from pm34xx.c to the System Control Module code in mach-omap2/control.c. This is part of the general push to move direct register access from middle-layer core code to low-level core code, so the middle-layer code can be abstracted to work on multiple platforms and cleaned up. In the medium-to-long term, this code should be called by the mux layer code, not the PM idle code. This is because, according to the TRM, saving the padconf only needs to be done when the padconf changes[1]. Signed-off-by:
Santosh Shilimkar <santosh.shilimkar@ti.com> 1. OMAP34xx Multimedia Device Silicon Revision 3.1.x [Rev. ZH] [SWPU222H] Section 4.11.4 "Device Off-Mode Sequences"
-
Paul Walmsley authored
The OMAP powerdomain code and data is all OMAP2+-specific. This seems unlikely to change any time soon. Move plat-omap/include/plat/powerdomain.h to mach-omap2/powerdomain.h. The primary point of doing this is to remove the temptation for unrelated upper-layer code to access powerdomain code and data directly. As part of this process, remove the references to powerdomain data from the GPIO "driver" and the OMAP PM no-op layer, both in plat-omap. Change the DSPBridge code to point to the new location for the powerdomain headers. The DSPBridge code should not be including the powerdomain headers; these should be removed. Signed-off-by: -
Paul Walmsley authored
The OMAP clockdomain code and data is all OMAP2+-specific. This seems unlikely to change any time soon. Move plat-omap/include/plat/clockdomain.h to mach-omap2/clockdomain.h. The primary point of doing this is to remove the temptation for unrelated upper-layer code to access clockdomain code and data directly. DSPBridge also uses the clockdomain headers for some reason, so, modify it also. The DSPBridge code should not be including the clockdomain headers; these should be removed. Signed-off-by:
-
Paul Walmsley authored
Reverse some of the effects of commit 84c0c39a ("ARM: OMAP4: PM: Make OMAP3 Clock-domain framework compatible for OMAP4"). On OMAP2/3, the CM_CLKSTCTRL register is at a constant offset from the powerdomain's CM instance. Also, remove some of the direct CM register access from the clockdomain code, moving it to the OMAP2/3 CM code instead. The intention here is to simplify the clockdomain code. (The long-term goal is to move all direct CM register access across the OMAP core code to the appropriate cm*.c file.) Signed-off-by:
-
Paul Walmsley authored
Add PRCM partition, CM instance register address offset, and clockdomain register address offset to each OMAP4 struct clockdomain record. Add OMAP4 clockdomain code to use this new data to access registers properly. While here, clean up some nearby clockdomain code to allocate auto variables in my recollection of Linus's preferred style. The autogeneration scripts have been updated. Signed-off-by:
-
Paul Walmsley authored
In OMAP4 CM instances, some registers (CM_CLKSTCTRL, CM_STATICDEP, CM_DYNAMICDEP, and the module-specific registers underneath) are organized by clockdomain. Add the clockdomain offset macros to the appropriate PRCM module header files. This data was almost completely autogenerated from the TI hardware database; the autogeneration scripts have been updated. Signed-off-by:
-
Paul Walmsley authored
Split _omap2_clkdm_set_hwsup() into _disable_hwsup() and _enable_hwsup(). While here, also document that the autodeps are deprecated and that they should be removed at the earliest opportunity. The documentation has been fixed for _{enable,disable}_hwsup(), thanks to Kevin Hilman <khilman@deeprootsystems.com> for pointing out that those functions still had placeholder documentation in an earlier patch revision. Signed-off-by: -
Paul Walmsley authored
OMAP4 powerdomain control registers are split between the PRM hardware module and the PRCM_MPU local PRCM. Add this PRCM partition information to each OMAP4 powerdomain record, and convert the OMAP4 powerdomain function implementations to use the OMAP4 PRM instance functions. Also fixes a potential null pointer dereference of pwrdm->name. The autogeneration scripts have been updated. Signed-off-by:
-
Paul Walmsley authored
Now that OMAP4-specific PRCM functions have been added, distinguish the existing OMAP2/3-specific PRCM functions by prefixing them with "omap2_". This patch should not result in any functional change. Signed-off-by:
-
Paul Walmsley authored
Move the OMAP4 global software reset function to the OMAP4-specific prm44xx.c file, where it belongs. Part of the long-term process of moving all of the direct PRCM register writes into lower-layer code. Also add OCP barriers on OMAP2/3/4 to reduce the chance that the MPU will continue executing while the system is supposed to be resetting itself. Signed-off-by:
-
Paul Walmsley authored
In some ways, the OMAP4 PRCM register layout is quite different than the OMAP2/3 PRCM register layout. For example, on OMAP2/3, from a register layout point of view, all CM instances were located in the CM subsystem, and all PRM instances were located in the PRM subsystem. OMAP4 changes this. Now, for example, some CM instances, such as WKUP_CM and EMU_CM, are located in the system PRM subsystem. And a "local PRCM" exists for the MPU - this PRCM combines registers that would normally appear in both CM and PRM instances, but uses its own register layout which matches neither the OMAP2/3 PRCM layout nor the OMAP4 PRCM layout. To try to deal with this, introduce some new functions, omap4_cminst* and omap4_prminst*. The former is to be used when writing to a CM instance register (no matter what subsystem or hardware module it exists in), and the latter, similarly, with PRM instance registers. To determine which "PRCM partition" to write to, the functions take a PRCM instance ID argument. Subsequent patches add these partition IDs to the OMAP4 powerdomain and clockdomain definitions. As far as I can see, there's really no good way to handle these types of register access inconsistencies. This patch seemed like the least bad approach. Moving forward, the long-term goal is to remove all direct PRCM register access from the PM code. PRCM register access should go through layers such as the powerdomain and clockdomain code that can hide the details of how to interact with the specific hardware variant. While here, rename cm4xxx.c to cm44xx.c to match the naming convention of the other OMAP4 PRCM files. Thanks to Santosh Shilimkar <santosh.shilimkar@ti.com>, Rajendra Nayak <rnayak@ti.com>, and Benoît Cousson <b-cousson@ti.com> for some comments. Signed-off-by: -
Paul Walmsley authored
The OMAP3 PRM module is in the WKUP powerdomain, which is always powered when the chip is powered, so it shouldn't be necessary to save and restore those PRM registers. Remove the PRM register save/restore code, which should save several microseconds during off-mode entry/exit, since PRM register accesses are relatively slow. While doing so, move the CM register save/restore code into CM-specific code. The CM module has been distinct from the PRM module since 2430. This patch includes some minor changes to pm34xx.c. Signed-off-by:
-
Paul Walmsley authored
In preparation for adding OMAP4-specific PRCM accessor/mutator functions, split the existing OMAP2/3 PRCM code into OMAP2/3-specific files. Most of what was in mach-omap2/{cm,prm}.{c,h} has now been moved into mach-omap2/{cm,prm}2xxx_3xxx.{c,h}, since it was OMAP2xxx/3xxx-specific. This process also requires the #includes in each of these files to be changed to reference the new file name. As part of doing so, add some comments into plat-omap/sram.c and plat-omap/mcbsp.c, which use "sideways includes", to indicate that these users of the PRM/CM includes should not be doing so. Thanks to Felipe Contreras <felipe.contreras@gmail.com> for comments on this patch. Signed-off-by:Omar Ramirez Luna <omar.ramirez@ti.com> Cc: Felipe Contreras <felipe.contreras@gmail.com> Acked-by:
Felipe Contreras <felipe.contreras@gmail.com> Cc: Greg Kroah-Hartman <greg@kroah.com> Acked-by:
Mark Brown <broonie@opensource.wolfsonmicro.com> Reviewed-by:
-
Paul Walmsley authored
Back in the OMAP2/3 PRCM interface days, the macros that referred to the offsets of individual PRM/CM instances from the top of the PRM/CM hardware modules were incorrectly suffixed with "_MOD". (They should have been suffixed with something like "_INST" or "_INSTANCE".) These days, now that we have better contact with the OMAP hardware people, we know that this naming is wrong. And in fact in OMAP4, there are actual hardware module offsets inside the instances, so the incorrect naming gets confusing very quickly for anyone who knows the hardware. Fix this naming for OMAP4, before things get too far along, by changing "_MOD" to "_INST" on the end of these macros. So, for example, OMAP4430_CM2_INSTR_MOD becomes OMAP4430_CM2_INSTR_INST. This unfortunately creates quite a large diff, but it is a straightforward rename. This patch should not result in any functional changes. The autogeneration scripts have been updated accordingly. Signed-off-by:
-
Benoit Cousson authored
Add the header file with scrm registers absolute address, offset and bitfields. Signed-off-by:
-
Paul Walmsley authored
Split the existing cm44xx.h file into cm1_44xx.h and cm2_44xx.h files so they match their underlying OMAP hardware modules. Add clockdomain offset information. Add header files for the MPU local PRCM, prcm_mpu44xx.h, and for the SCRM, scrm44xx.h. SCRM register offsets still need to be added; TI should do this. Move the "_MOD" macros out of the prcm-common.h header file, into the header file of the hardware module that they belong to. For example, OMAP4430_PRM_*_MOD macros have been moved into the prm44xx.h header. Adjust #includes of all files that used the old PRCM header file names to point to the new filenames. The autogeneration scripts have been updated accordingly. Signed-off-by:
-
Paul Walmsley authored
For some reason, the PRCM context save/restore code also saves and restores a single System Control Module register, CONTROL_PADCONF_SYS_NIRQ. This is probably just an error -- the register should be handled by SCM code -- so this patch moves it there. If this register really does need to be saved and restored before the rest of the PRCM registers, the code to do so should live in the SCM code, and the PM code should call this separate function. This register pertains to devices with a stacked modem, so this patch is unlikely to affect most OMAP devices out there. Signed-off-by:
-
Paul Walmsley authored
Get rid of the open-coded scratchpad write in mach-omap2/prcm.c and replace it with an actual API, omap3_ctrl_write_boot_mode(). While there, get rid of the gratuitous omap_writel(). There's not much documentation available for what should wind up in the scratchpad here, so more documentation would be appreciated. Also, at some point, we should formalize our treatment of the scratchpad; right now, accesses to the scratchpad are not well-documented. Signed-off-by:
-
