| Age | Commit message (Collapse) | Author |
|---|
|
ftrace requires sched_clock() to be notrace. Ensure that all
implementations are so marked. Also make sure that they include
linux/sched.h
Also ensure OMAP clocksource read functions are marked notrace as
they're used for sched_clock() too.
Tested-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Tested-by: Will Deacon <will.deacon@arm.com>
Tested-by: Mikael Pettersson <mikpe@it.uu.se>
Tested-by: Eric Miao <eric.y.miao@gmail.com>
Tested-by: Olof Johansson <olof@lixom.net>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
|
|
In d7e81c2 (clocksource: Add clocksource_register_hz/khz interface) new
interfaces were added which simplify (and optimize) the selection of the
divisor shift/mult constants. Switch over to using this new interface.
Tested-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
|
|
This patch extends the smartreflex framework to support
OMAP4. The changes are minor like compiling smartreflex Kconfig
option for OMAP4 also, and a couple of OMAP4 checks in
the smartreflex framework.
The change in sr_device.c where new logic has to be introduced
for reading the efuse registers is due to the fact that in OMAP4
the efuse registers are 24 bit aligned. A __raw_readl will
fail for non-32 bit aligned address and hence the 8-bit read
and shift.
Signed-off-by: Thara Gopinath <thara@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
|
|
OMAP4 has three scalable voltage domains vdd_mpu, vdd_iva
and vdd_core. This patch adds the voltage tables and other
configurable voltage processor and voltage controller
settings to control these three scalable domains in OMAP4.
Signed-off-by: Thara Gopinath <thara@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
|
|
Smartreflex Class3 implementation continuously monitors
silicon performance and instructs the Voltage Processors
to increase or decrease the voltage.
This patch adds smartreflex class 3 driver. This driver hooks
up with the generic smartreflex driver smartreflex.c to abstract
out class specific implementations out of the generic driver.
Class3 driver is chosen as the default class driver for smartreflex.
If any other class driver needs to be implemented, the init of that
driver should be called from the board file. That way the new class driver
will over-ride the Class3 driver.
Signed-off-by: Thara Gopinath <thara@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
|
|
SmartReflex modules do adaptive voltage control for real-time
voltage adjustments. With Smartreflex the power supply voltage
can be adapted to the silicon performance(manufacturing process,
temperature induced performance, age induced performance etc).
There are differnet classes of smartreflex implementation.
Class-0: Manufacturing Test Calibration
Class-1: Boot-Time Software Calibration
Class-2: Continuous Software Calibration
Class-3: Continuous Hardware Calibration
Class-4: Fully Integrated Power Management
OMAP3 has two smartreflex modules one associated with VDD MPU and the
other associated with VDD CORE.
This patch adds support for smartreflex driver. The driver is designed
for Class-1 , Class-2 and Class-3 support and is a platform driver.
Smartreflex driver can be enabled through a Kconfig option
"SmartReflex support" under "System type"->"TI OMAP implementations" menu.
Smartreflex autocompensation feature can be enabled runtime through
a debug fs option.
To enable smartreflex autocompensation feature
echo 1 > /debug/voltage/vdd_<X>/smartreflex/autocomp
To disable smartreflex autocompensation feature
echo 0 > /debug/voltage/vdd_<X>/smartreflex/autocomp
where X can be mpu, core , iva etc.
This patch contains code originally in linux omap pm branch.
Major contributors to this driver are
Lesly A M, Rajendra Nayak, Kalle Jokiniemi, Paul Walmsley,
Nishant Menon, Kevin Hilman.
Signed-off-by: Thara Gopinath <thara@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
|
|
This patch extends the device hwmod structure to contain
info about the voltage domain to which the device belongs to.
This is needed to support a device based DVFS where the
device knows which voltage domain it belongs to.
Signed-off-by: Thara Gopinath <thara@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
|
|
This patch adds voltage driver support for OMAP3. The driver
allows configuring the voltage controller and voltage
processors during init and exports APIs to enable/disable
voltage processors, scale voltage and reset voltage.
The driver maintains the global voltage table on a per
VDD basis which contains the various voltages supported by the
VDD along with per voltage dependent data like smartreflex
efuse offset, errminlimit and voltage processor errorgain.
The driver also allows the voltage parameters dependent on the
PMIC to be passed from the PMIC file through an API.
The driver allows scaling of VDD voltages either through
"vc bypass method" or through "vp forceupdate method" the
choice being configurable through the board file.
This patch contains code originally in linux omap pm branch
smartreflex driver. Major contributors to this driver are
Lesly A M, Rajendra Nayak, Kalle Jokiniemi, Paul Walmsley,
Nishant Menon, Kevin Hilman. The separation of PMIC parameters
into a separate structure which can be populated from
the PMIC file is based on the work of Lun Chang from Motorola
in an internal tree.
Signed-off-by: Thara Gopinath <thara@ti.com>
[khilman: fixed link error for OMAP2-only defconfig]
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
|
|
into omap-for-linus
|
|
|
|
Most keypad drivers make use of the <linux/input/matrix_keypad.h>
defined macros, structures and inline functions.
Convert omap-keypad driver to use those as well, as suggested by a
compile time warning, hardcoded into the OMAP <palt/keypad.h>.
Created against linux-2.6.37-rc5.
Tested on Amstrad Delta.
Compile tested with omap1_defconfig and omap2plus_defconfig shrinked to
board-h4.
Signed-off-by: Janusz Krzysztofik <jkrzyszt@tis.icnet.pl>
Reviewed-by: Aaro Koskinen <aaro.koskinen@nokia.com>
Acked-by: Dmitry Torokhov <dtor@mail.ru>
Signed-off-by: Tony Lindgren <tony@atomide.com>
|
|
Conflicts:
MAINTAINERS
arch/arm/mach-omap2/pm24xx.c
drivers/scsi/bfa/bfa_fcpim.c
Needed to update to apply fixes for which the old branch was too
outdated.
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Tony Lindgren <tony@atomide.com>
Tested-by: Rajendra Nayak <rnayak@ti.com>
Tested-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"
|
|
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>
|
|
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 <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>
Tested-by: Rajendra Nayak <rnayak@ti.com>
Tested-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
|
|
register accesses
Reverse some of the effects of commit
84c0c39aec31a09571fc08a752a2f4da0fe9fcf2 ("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 <paul@pwsan.com>
Tested-by: Rajendra Nayak <rnayak@ti.com>
Tested-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
|
|
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 <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: Rajendra Nayak <rnayak@ti.com>
Tested-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
|
|
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>
|
|
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 <paul@pwsan.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Jarkko Nikula <jhnikula@gmail.com>
Cc: Peter Ujfalusi <peter.ujfalusi@nokia.com>
Cc: Liam Girdwood <lrg@slimlogic.co.uk>
Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>
Tested-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Tested-by: Rajendra Nayak <rnayak@ti.com>
|
|
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 <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
|
|
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 <paul@pwsan.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Cc: Tero Kristo <tero.kristo@nokia.com>
Cc: Kalle Jokiniemi <kalle.jokiniemi@digia.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>
|
|
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 clockdomain data.
Signed-off-by: Paul Walmsley <paul@pwsan.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>
|
|
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>
|
|
Put infrastructure in place, so arch specific func pointers
can be hooked up to the platform-independent part of the
framework.
This is in preparation of splitting the powerdomain framework into
platform-independent part (for all omaps) and platform-specific
parts.
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Benoit Cousson <b-cousson@ti.com>
Cc: Kevin Hilman <khilman@deeprootsystems.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>
|
|
powerdomains.h header today has only static definitions. Adding any
function declarations into it and including it in multiple source file
is expected to cause issues. Hence move all the static definitions
from powerdomains.h file into powerdomains_data.c file.
Also, create a new powerdomain section of the mach-omap2/Makefile, and
rearrange the prcm-common part of the Makefile, now that the
powerdomain code is in its own Makefile section.
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
[paul@pwsan.com: rearrange Makefile changes, tweaked commit message]
Signed-off-by: Paul Walmsley <paul@pwsan.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>
|
|
Trivial cleanup and documentation changes on the hwmod code and data:
- add some hwmod documentation to indicate flags that should be moved
outside the static hwmod data in a future patch
- remove some unused fields in the struct omap_hwmod_ocp_if and
struct omap_hwmod structures
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>
|
|
Change the per-hwmod mutex to a spinlock. (The per-hwmod lock
serializes most post-initialization hwmod operations such as enable,
idle, and shutdown.) Spinlocks are needed, because in some cases,
hwmods must be enabled from timer interrupt disabled-context, such as
an ISR. The current use-case that is driving this is the OMAP GPIO
block ISR: it can trigger interrupts even with its clocks disabled,
but these clocks are needed for register accesses in the ISR to succeed.
This patch also effectively reverts commit
848240223c35fcc71c424ad51a8e8aef42d3879c - this patch makes
_omap_hwmod_enable() and _omap_hwmod_init() static, renames them back
to _enable() and _idle(), and changes their callers to call the
spinlocking versions. Previously, since omap_hwmod_{enable,init}()
attempted to take mutexes, these functions could not be called while
the timer interrupt was disabled; but now that the functions use
spinlocks and save and restore the IRQ state, it is appropriate to
call them directly.
Kevin Hilman <khilman@deeprootsystems.com> originally proposed this
patch - thanks Kevin.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Benoît Cousson <b-cousson@ti.com>
|
|
The standard omap_hwmod.c _reset() code relies on an IP block's
OCP_SYSCONFIG.SOFTRESET register bit to reset the IP block. This
works for most IP blocks on the chip, but unfortunately not all. For
example, initiator-only IP blocks often don't have any MPU-accessible
OCP-header registers, and therefore the MPU can't write to any
OCP_SYSCONFIG registers in that block. Other IP blocks, such as the
IVA and I2C, require a specialized reset sequence.
Since we need to be able to reset these IP blocks as well, allow
custom IP block reset functions to be passed into the hwmod code via a
per-hwmod-class reset function pointer, struct omap_hwmod_class.reset.
If .reset is non-null, then the hwmod _reset() code will call the custom
function instead of the standard OCP SOFTRESET-based code.
As part of this change, rename most of the existing _reset() function
code to _ocp_softreset(), to indicate more clearly that it does not work
for all cases.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>
Cc: Paul Hunt <hunt@ti.com>
Cc: Stanley Liu <stanley_liu@ti.com>
|
|
Allow board files and OMAP core code to control the state that some or
all of the hwmods end up in at the end of _setup() (called by
omap_hwmod_late_init() ). Reimplement the old skip_setup_idle code in
terms of this new postsetup state code.
There are two use-cases for this patch: the !CONFIG_PM_RUNTIME case,
in which all IP blocks should stay enabled after _setup() finishes;
and the MPU watchdog case, in which the watchdog IP block should enter
idle if watchdog coverage of kernel initialization is desired, and
should be disabled otherwise.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Charulatha Varadarajan <charu@ti.com>
|
|
Some OMAP IP blocks, such as the watchdog timers, cannot be completely
shut down via the standard hwmod shutdown mechanism. This patch
enables the hwmod data files to supply a pointer to a custom
pre-shutdown function via the struct omap_hwmod_class.pre_shutdown
function pointer. If the struct omap_hwmod_class.pre_shutdown
function pointer is non-null, the function will be executed before the
existing hwmod shutdown code runs.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>
|
|
Split omap2_init_common_hw() into two functions. The first,
omap2_init_common_infrastructure(), initializes the hwmod code and
data, the OMAP PM code, and the clock code and data. The second,
omap2_init_common_devices(), handles any other early device
initialization that, for whatever reason, has not been or cannot be
moved to initcalls or early platform devices.
This patch is required for the hwmod postsetup patch, which allows
board files to change the state that hwmods should be placed into at
the conclusion of the hwmod _setup() function. For example, for a
board whose creators wish to ensure watchdog coverage across the
entire kernel boot process, code to change the watchdog's postsetup
state will be added in the board-*.c file between the
omap2_init_common_infrastructure() and omap2_init_common_devices() function
calls.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Tony Lindgren <tony@atomide.com>
|
|
Add support for DEBUG_LL for Devkit8000.
Devkit8000 uses uart 3 for debug output.
Signed-off-by: Thomas Weber <weber@corscience.de>
Signed-off-by: Tony Lindgren <tony@atomide.com>
|
|
ssh://master.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm into omap-for-linus
|
|
ssh://master.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm into omap-for-linus
|
|
|
|
The SRAM PA addresses are locally defined and used at
different places, i.e. SRAM management code and idle sleep code.
The macros are now defined at a centralized place, for
easier maintenance.
Tested on N900 and Beagleboard with full RET and OFF modes,
using cpuidle and suspend.
Signed-off-by: Jean Pihet <j-pihet@ti.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Tested-by: Nishanth Menon<nm@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
|
|
With new OPP layer, OPP users will access OPP API directly instead of
using OMAP PM layer, so remove all notions of OPPs from the OMAP PM
layer.
Acked-by: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
|
|
The calculations done with sync_clk are anyway in picoseconds
and switching to picoseconds allows sync_clk values that are
not a whole number of nanoseconds - which is sometimes the
case.
Signed-off-by: Adrian Hunter <adrian.hunter@nokia.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
|
|
|
|
No need to call this early from init_irq. Also recent changes
initialize GPIO now later, so calling gpio_request from init_irq
will make it fail.
While at it, also remove the unnecessary EXPORT_SYMBOL.
Signed-off-by: Tony Lindgren <tony@atomide.com>
|
|
Convert DMA library into DMA platform driver and make use of
platform data provided by hwmod data base for OMAP2+ onwards.
For OMAP1 processors, the DMA driver in mach-omap uses resource
structures for getting platform data.
Thanks to Tony Lindgren <tony@atomide.com> for fixing various
omap1 issues and testing the same on OSK5912 board.
Signed-off-by: G, Manjunath Kondaiah <manjugk@ti.com>
Tested-by: Kevin Hilman <khilman@deeprootsystems.com>
Acked-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
|
|
Add OMAP2430 DMA hwmod data and also add required
DMA device attributes.
Signed-off-by: G, Manjunath Kondaiah <manjugk@ti.com>
Acked-by: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
|
|
Add OMAP2420 DMA hwmod data and also add required
DMA device attributes.
Signed-off-by: G, Manjunath Kondaiah <manjugk@ti.com>
Acked-by: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
|
