summaryrefslogtreecommitdiff
path: root/arch/arm/mach-omap2/powerdomains44xx_data.c
AgeCommit message (Collapse)AuthorFilesLines
2011-09-15OMAP4: powerdomain data: add voltage domainsBenoit Cousson1-0/+16
Add voltage domain name to indicate which voltagedomain each powerdomain is in. The fixed voltage domain like ldo_wakeup for emu and wkup power domain is added too. Signed-off-by: Benoit Cousson <b-cousson@ti.com> Cc: Paul Walmsley <paul@pwsan.com> [khilman@ti.com]: renamed wakeup domain: s/ldo_wakeup/wakeup/ Signed-off-by: Kevin Hilman <khilman@ti.com>
2011-09-15OMAP: powerdomain: remove omap_chip bitmasksPaul Walmsley1-16/+0
At Tony's request, remove the omap_chip bitmasks from the powerdomain definitions. Instead, initialize powerdomains based on one or more lists that are applicable to a particular SoC family, variant, and silicon revision. Gražvydas Ignotas <notasas@gmail.com> found and reported a bug in a related patch that also applied to this patch - thanks Gražvydas. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Gražvydas Ignotas <notasas@gmail.com>
2011-09-15OMAP: powerdomain: split pwrdm_init() into two functionsPaul Walmsley1-1/+3
In preparation for OMAP_CHIP() removal, split pwrdm_init() into three functions. This allows some of them to be called multiple times: for example, pwrdm_register_pwrdms() can be called once to register powerdomains that are common to a group of SoCs, and once to register powerdomains that are specific to a single SoC. The appropriate order to call these functions - which is enforced by the code - is: 1. pwrdm_register_platform_funcs() 2. pwrdm_register_pwrdms() (can be called multiple times) 3. pwrdm_complete_init() Convert the OMAP2, 3, and 4 powerdomain init code to use these new functions. While here, improve documentation, and increase CodingStyle conformance by shortening some local variable names. Signed-off-by: Paul Walmsley <paul@pwsan.com>
2011-07-10Merge branches 'powerdomain_fixes_3.1', 'hardware_workarounds_3.1', ↵Paul Walmsley1-10/+10
'hwmod_dss_fix_3.1' and 'i2c_fixes_3.1' into prcm-fixes-3.1
2011-07-10OMAP4: powerdomain data: Remove unsupported MPU powerdomain stateSantosh Shilimkar1-1/+1
On OMAP4430 devices, because of boot ROM code bug, MPU OFF state can't be attempted independently. When coming out of MPU OFF state, ROM code disables the clocks of IVAHD, TESLA which is not desirable. Hence the MPU OFF state is not usable on OMAP4430 devices. OMAP4460 onwards, MPU OFF state will be descoped completely because the DDR firewall falls in MPU power domain. When the MPU hit OFF state, DDR won't be accessible for other initiators. The deepest state supported is open switch retention (OSWR) just like CORE and PER PD on OMAP4430. So in summary MPU power domain OFF state is not supported on OMAP4 and onwards designs. Thanks to new PRCM design, device off mode can still be achieved with power domains hitting OSWR state. Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Signed-off-by: Rajendra Nayak <rnayak@ti.com> [b-cousson@ti.com: Fix changelog typos] Signed-off-by: Benoit Cousson <b-cousson@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
2011-07-10OMAP4: powerdomain data: Fix core mem states and missing cefuse flagBenoit Cousson1-3/+4
Since ES2.0, the core ocmram does not support a different state than the main power domain anymore during both ON and RET power domain state. Since PM is not supported at all in ES1.0, update the common structure. LOWPOWERSTATECHANGE is supported by the cefuse power domain but the flag was missing. Add the PWRDM_HAS_LOWPOWERSTATECHANGE in flags field. Update the TI copyright date to 2011. Signed-off-by: Benoit Cousson <b-cousson@ti.com> Cc: Paul Walmsley <paul@pwsan.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> [paul@pwsan.com: moved the indentation changes to a different patch set] Signed-off-by: Paul Walmsley <paul@pwsan.com>
2011-07-10OMAP4: powerdomain data: Fix indentationBenoit Cousson1-9/+9
Indent flags to be aligned with other fields. Signed-off-by: Benoit Cousson <b-cousson@ti.com> Cc: Paul Walmsley <paul@pwsan.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> [paul@pwsan.com: split this patch from an earlier patch by Benoît; edited commit message] Signed-off-by: Paul Walmsley <paul@pwsan.com>
2011-03-08OMAP2+: powerdomain: fix bank power state bitfieldsPaul Walmsley1-42/+42
The bank power state bitfields in the powerdomain data are encoded incorrectly. These fields are intended to be bitfields, representing a set of power states that the memory banks support. However, when only one power state was supported by a given bank, the field was incorrectly set to the bit shift -- not the mask. While here, update some file copyrights. The OMAP4 autogeneration scripts have been updated accordingly. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
2011-03-02omap4: powerdomain: Use intended PWRSTS_* flags instead of valuesSantosh Shilimkar1-2/+2
IVAHD and ABE power domain logic state is populated using directly value instead of the capability flags. Fix the same. Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com> [paul@pwsan.com: updated to apply at a different point on the tree] Signed-off-by: Paul Walmsley <paul@pwsan.com>
2010-12-22OMAP4: powerdomain: Remove L3INIT_PD OFF stateSantosh Shilimkar1-1/+1
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-22OMAP4: powerdomain: l4per pwrdm does not support OFFRajendra Nayak1-1/+1
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-22OMAP2+: powerdomain: move header file from plat-omap to mach-omap2Paul Walmsley1-2/+1
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 <paul@pwsan.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Omar Ramirez Luna <omar.ramirez@ti.com> Cc: Felipe Contreras <felipe.contreras@gmail.com> Cc: Greg Kroah-Hartman <greg@kroah.com>
2010-12-22OMAP4: powerdomains: add PRCM partition data; use OMAP4 PRM functionsPaul Walmsley1-0/+17
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 <paul@pwsan.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Benoît Cousson <b-cousson@ti.com> Tested-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Tested-by: Rajendra Nayak <rnayak@ti.com>
2010-12-22OMAP2/3: PRCM: split OMAP2/3-specific PRCM code into OMAP2/3-specific filesPaul Walmsley1-1/+0
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: Paul Walmsley <paul@pwsan.com> Cc: Jarkko Nikula <jhnikula@gmail.com> Cc: Peter Ujfalusi <peter.ujfalusi@nokia.com> Cc: Liam Girdwood <lrg@slimlogic.co.uk> Cc: Omar Ramirez Luna <omar.ramirez@ti.com> Acked-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: Kevin Hilman <khilman@deeprootsystems.com> Tested-by: Kevin Hilman <khilman@deeprootsystems.com> Tested-by: Rajendra Nayak <rnayak@ti.com> Tested-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
2010-12-22OMAP4: PRCM: rename _MOD macros to _INSTPaul Walmsley1-16/+16
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: Paul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Reviewed-by: Kevin Hilman <khilman@deeprootsystems.com> Tested-by: Kevin Hilman <khilman@deeprootsystems.com> Tested-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Tested-by: Rajendra Nayak <rnayak@ti.com>
2010-12-22OMAP4: PRCM: reorganize existing OMAP4 PRCM header filesPaul Walmsley1-2/+2
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 <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com> Cc: Rajendra Nayak <rnayak@ti.com> Reviewed-by: Kevin Hilman <khilman@deeprootsystems.com> Tested-by: Kevin Hilman <khilman@deeprootsystems.com> Tested-by: Rajendra Nayak <rnayak@ti.com> Tested-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
2010-12-22OMAP2+: powerdomains: move powerdomain static data to .c filesPaul Walmsley1-0/+340
Static data should be declared in .c files, not .h files. It should be possible to #include .h files at any point without creating multiple copies of the same data. We converted the clock data to .c files some time ago. This patch does the same for the powerdomain data. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Reviewed-by: Kevin Hilman <khilman@deeprootsystems.com> Tested-by: Kevin Hilman <khilman@deeprootsystems.com> Tested-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Tested-by: Rajendra Nayak <rnayak@ti.com>