Fix some whitespace problems introduced by commit
da03ce65b5 ("OMAP3: powerdomain data:
add voltage domains"). Also, improve the documentation for the struct
powerdomain.flags field.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Add the possible logic retention states for the 24xx CORE powerdomain.
Subsequent patches use this data to avoid returning incorrect data, by
skipping reads from register bitfields that don't actually exist.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
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: Tony Lindgren <tony@atomide.com>
Create basic voltagedomains for OMAP2 and associate OMAP2 powerdomains
with the newly created voltage domains.
While here, update copyright on powerdomain data to 2011.
Signed-off-by: Kevin Hilman <khilman@ti.com>
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>
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>
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>
We want to have just CONFIG_ARCH_OMAP2, 3 and 4. The rest
are nowadays just subcategories of these.
Search and replace the following:
ARCH_OMAP2420 SOC_OMAP2420
ARCH_OMAP2430 SOC_OMAP2430
ARCH_OMAP3430 SOC_OMAP3430
No functional changes.
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Thomas Weber <weber@corscience.de>
Acked-by: Sourav Poddar <sourav.poddar@ti.com>
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>
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>
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>
