| Age | Commit message (Collapse) | Author |
|---|
|
Move twd_evt declaration up to before its first use.
Signed-off-by: David A. Long <dave.long@linaro.org>
|
|
Palmas communications can get confused if multiple threads are wanting to do IO to it at the moment.
Normally i2c layer would serialize it OK but in case of palmas_i2c_read_block(), the io is not atomic, it first sends dat and then performs a second transaction.
This was seen to be occurring at boot when one thread is doing regulator_init_complete() which iterates all the regulator statuses calling palmas_i2c_read_block, and other things like mmc might want to set their regulator. Without any locking, the two actions can interrupt each other.
This patch uses the already defined and inited but not used io_mutex member of palmas struct to protect palmas IO from itself.
Signed-off-by: Andy Green <andy.green@linaro.org>
|
|
Signed-off-by: Dave Long <dave.long@linaro.org>
|
|
Host/tll clocks are managed from hwmod framework,
remove the host/tll clock management from clock
framework else, reset unsed clocks will gate it.
As hwmod manages these module bits without calling
clock api's.
Signed-off-by: Govindraj.R <govindraj.raja@ti.com>
|
|
Fix wrong error check. Enable wakeup on irq if the request_irq succeeds.
Signed-off-by: Girish S G <girishsg@ti.com>
|
|
This patch makes sys_nirq1 wakeup capable which is required for waking up
omap via Palmas events.
Signed-off-by: Vishwanath Sripathy <vishwanath.bs@ti.com>
Signed-off-by: Girish S G <girishsg@ti.com>
|
|
Instead of using seperate config entry for DVFS, use CPUFREQ to enable/disable
DVFS. There is no pointing in having DVFS w/o CPUFREQ and visa versa.
Signed-off-by: Vishwanath BS <vishwanath.bs@ti.com>
|
|
Spurious thermal alert interrupt is generated when restoring the context
of OMAP temperature sensor driver upon a wake-up from CORE OSWRet/OFF modes.
This spurious interrupt is due to the fact that current SW implementation
restores all HW registers without any specific sequence.
Finally, the thermal alert interrupt handler prints error message because
the temperature reported by the sensor is invalid.
This patch applies a SW sequence taking into the HW constraints to avoid
the generation of cold thermal alert.
HW constraints:
- The HW logic decrements the counter and then starts the temperature
measurement.
- An immediate temperature measurement is possible only if counter is set to
low value.
- The HW logic compares the BGAP_TEMP_SENSOR_DTEMP bitfield with threshold as
soon as the clock is enabled.
- To avoid spurious interrupt, it is mandatory to unmask interrupts (cold
and/or hot) when BGAP_TEMP_SENSOR_DTEMP bitfield is different than 0.
New SW implementation:
1/ If all registers have been reset:
- Force immediate temperature measurement and wait until
BGAP_TEMP_SENSOR_DTEMP bitfield is updated before completing the full context
restoration.
- Ensure that the BGAP_TEMPSOFF bit is not set to 1 during context restoration.
- Complete the context restoration (mask bits and counter).
2/ If registers have not been reset:
- Force immediate temperature measurement and wait until
BGAP_TEMP_SENSOR_DTEMP bitfield is different than 0.
Signed-off-by:Sebastien Sabatier <s-sabatier1@ti.com>
Signed-off-by: Keerthy <j-keerthy@ti.com>
|
|
Reduce the bgap counter to 250ms since updating
the hw counter on the fly might result in unexpected
behavior. Hence keeping the counter constant at 250ms.
Signed-off-by: Keerthy <j-keerthy@ti.com>
|
|
Change the time for Long press Key from 12S to 6S
Signed-off-by: J Keerthy <j-keerthy@ti.com>
|
|
Provide a config option to disable/enable DVFS via menuconfig.
DVFS is disabled by default now till all drivers are DVFS adapted.
Signed-off-by: Vishwanath BS <vishwanath.bs@ti.com>
|
|
Signed-off-by: Andy Green <andy.green@linaro.org>
|
|
Warm reset could be triggered by normal reboot sequence or with
various OMAP watchdog timers. Watchdog timers introduce unplanned
reset sequence which could, in theory occur at any point of time.
OMAP provides two registers to control the length that reset is
held low allowing for the voltages and oscillator to reach stable
state. PRM_RSTTIME::RSTTIME1 which is a default duration which is
added and PRM_VOLTSETUP_WARMRESET depending on which voltage domains
are in LP state. Considering watchdog, it is really not practical
to optimally program PRM_VOLTSETUP_WARMRESET, hence we use the
worst case latency in the worst case scenario in RSTTIME1.
From a latency consideration, system restarting from an OFF mode
would be the worst case for watchdog. Here, we need to consider
ramping of each voltage domains + Oscillator which could have been
caught at the worst possible time - at the start of oscillator
shutdown sequence.
Since all these information is already available in the
datastructures maintained by PM framework, it is not necessary for
board files to provide any further information.
Reported-by: Baek.Kyung-Han <wildtaz.baek@samsung.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
|
|
OMAP5 Voltage processor and PRM is reset only with a cold reset.
So we hook the VP's recovery api to cold reset.
Signed-off-by: Vishwanath BS <vishwanath.bs@ti.com>
|
|
OMAP4 Voltage processor and PRM is reset only with a cold reset.
So we hook the VP's recovery api to cold reset.
Signed-off-by: Nishanth Menon <nm@ti.com>
|
|
Provide hook so that we can attempt to populate a arch specific
recovery mechanism
Signed-off-by: Nishanth Menon <nm@ti.com>
|
|
OMAP4 has support for cold resetting the device. It is not
recommended to use this as the default behavior, however
certain modules in OMAP have no other mechanism to reset
themselves once certain bad states have been hit.
Signed-off-by: Nishanth Menon <nm@ti.com>
|
|
MMC OPPs have to be enabled for non pm standalone build.
Signed-off-by: Vishwanath BS <vishwanath.bs@ti.com>
|
|
As Device latency constraints are not yet supported, let's disable low power
states being activated via constrainst framework.
Once latency for each of the low powerstates are profiled, lower power states
will be enabled.
Signed-off-by: Vishwanath BS <vishwanath.bs@ti.com>
|
|
Add Palmas Power button config option in Kconfig.
Change-Id: I10f9d90128a5322432fd5cd54a9e82184a51b681
Signed-off-by: Girish S G <girishsg@ti.com>
Signed-off-by: Keerthy <j-keerthy@ti.com>
|
|
This patch adds palmas power button as a input event driver. This
will be mapped as power button key in the userland.
Change-Id: Ifedb13322cf1fc8658247fe47eeca423657497b3
Signed-off-by: Girish S G <girishsg@ti.com>
Signed-off-by: Keerthy <j-keerthy@ti.com>
|
|
This patch adds power button as a resource to palmas.
Change-Id: I1385fae7fd2c0a7903d8b7c0be72e7d406c50cdf
Signed-off-by: Girish S G <girishsg@ti.com>
Signed-off-by: Keerthy <j-keerthy@ti.com>
|
|
Update next state logic to accomodate the following scenarios
where the power domain does not support the requested power state:
a) if this power domain is a parent power domain, we do not intend
for it to go to a lower power state(because we are not targetting it),
select the next higher power state which is supported is returned.
b) However, for all children power domains, we first try to match
with a lower power domain state before attempting a higher state.
This is because a combination of system power states where the
parent PD's state is not in line with expectation can result in
system instabilities.
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Axel Haslam <axelhaslam@ti.com>
|
|
OMAP4 TRM chapter "Power domain transitions" clearly indicate
the approved states that each power domain can transition to.
As part of this programming, stepping down is possible to
lower power state, however, step up is required to ON mode.
Enumerating this:
PWRDM_POWER_ON ->PWRDM_POWER_INACTIVE, PWRDM_POWER_RET, PWRDM_POWER_OFF
PWRDM_POWER_INACTIVE -> PWRDM_POWER_RET, PWRDM_POWER_OFF
PWRDM_POWER_RET -> PWRDM_POWER_OFF
PWRDM_POWER_INACTIVE, PWRDM_POWER_RET, PWRDM_POWER_OFF -> PWRDM_POWER_ON
We currently ignore this transition limitation while programming to
suspend path. This can cause issues if we attempt OSWR/CSWR after
achieving a module level OFF previously (saved_state would be OFF
but achievable state might indicate point to a retention transition)
in such cases, it is better than we dont program the state.
Reported-by: Todd Poynor <toddpoynor@google.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
|
|
OMAP4 TRM chapter "Power domain transitions" clearly indicate
the approved states that each power domain can transition to.
As part of this programming, stepping down is possible to
lower power state, however, step up is required to ON mode.
Enumerating this:
PWRDM_POWER_ON ->PWRDM_POWER_INACTIVE, PWRDM_POWER_RET, PWRDM_POWER_OFF
PWRDM_POWER_INACTIVE -> PWRDM_POWER_RET, PWRDM_POWER_OFF
PWRDM_POWER_RET -> PWRDM_POWER_OFF
PWRDM_POWER_INACTIVE, PWRDM_POWER_RET, PWRDM_POWER_OFF -> PWRDM_POWER_ON
Exit condition from suspend does not currently obey the requirement, and allows
transition to last saved state which could have been an intermediate
saved low power state. This is not allowed per PRCM state machine.
This caused issue with DSS power domain attempting to wakeup from Suspend
mode.
Reported by: Baek.Kyung-Han <wildtaz.baek@samsung.com>
[nm@ti.com: improvement of the patch]
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Vinay Amancha <vinaykumar@ti.com>
Signed-off-by: Devaraj Rangasamy <dev@ti.com>
|
|
Some of the powerst control/logic_st_ctrl registers such as
CAM, EMU, ABE, etc. are reserved registers, we shouldn't be
writing to them in the first place. The ALWAYS_ON power domains
(wakeup, those of core, DSP, MPU), STD_EFUSE are not under
software control, hence for the purposes of this patch, considered as
not modifiable by software.
Signed-off-by: Nishanth Menon <nm@ti.com>
|
|
If the state we plan on restoring is precisely the state that the
domain is already at on resume, don't bother to reprogram the domain.
Signed-off-by: Nishanth Menon <nm@ti.com>
|
|
If the power domain state is ON - e.g. wakeup dependency,
don't reprogram the domain back to LP state it entered suspend into.
If the domain wokeup, it should finish it's work
before going back down, let the relevant subsystem deal with it.
Signed-off-by: Nishanth Menon <nm@ti.com>
|
|
Move the resume power domain programming into it's own
function as a staging for additional logic.
Signed-off-by: Nishanth Menon <nm@ti.com>
|
|
This is taken care of by the common gic code and is not needed within
wakeupgen.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
|
|
This reverts commit ee893b5625f4d7210c4a365d552d5e6326f33e21.
Not needed as common gic code takes care of this.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
|
|
Some of the EMIF settings need to have a safer value when
voltage is ramping. So, add a notifier in EMIF for core
voltage change notifications and take appropriate actions
Signed-off-by: Aneesh V <aneesh@ti.com>
|
|
zebu crashes during boot because it does not have proper support for
voltage control and does not have PMIC data. Fixed this by adding
a check for PMIC data presence in boot.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
|
|
Add GPU governor for OMAP5.
Signed-off-by: J Keerthy <j-keerthy@ti.com>
|
|
Add MPU Cooling device based on frequency scaling.
Signed-off-by: J Keerthy <j-keerthy@ti.com>
|
|
The patch adds kernel thermal framework and on die
CPU governer support.
Signed-off-by: Dan Murphy <dmurphy@ti.com>
Signed-off-by: Moiz Sonasath <m-sonasath@ti.com>
Signed-off-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: J Keerthy <j-keerthy@ti.com>
|
|
The hwmon driver is client to omap4 system control module driver.
Signed-off-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: J Keerthy <j-keerthy@ti.com>
|
|
This adds temperature sensor support for OMAP4460+
processors. This comprises of TALERT configuring and handling
and also TSHUT handling.
Signed-off-by: J Keerthy <j-keerthy@ti.com>
|
|
The omap core pm code, before doing a SAR save for USB,
enables its clocks and later disables it.
Requesting a clock is done by passing a NULL dev pointer
and the clock-name as the con_id.
Hence add the entries with in the clkdev table which make
this possible.
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
|
|
This allows ABE powerdomain to idle properly.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
|
|
Signed-off-by: Tero Kristo <t-kristo@ti.com>
|
|
Fix the EFUSE register offsets for Smartreflex ntarget values for OMAP5.
Signed-off-by: J Keerthy <j-keerthy@ti.com>
|
|
As omap5 does not have proper mux support yet, we enable wakeup for
this pad manually.
To be removed once MUX framework is added for OMAP5.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
|
|
OMAP5 IO chain does not reset itself unless the GLOBAL_WUEN is toggled.
This is now done inside omap4_trigger_wuclk_ctrl. pm_io interrupt handler
is also removed, as we want to arm the io chain just before entering idle,
to avoid having wrong setup for pads in the chain in case someone changes
pad setup between sleep cycles.
This should be removed once MUX framework is in place for OMAP5.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
|
|
Signed-off-by: Tero Kristo <t-kristo@ti.com>
|
|
This enabled IO daisy chain.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
|
|
Currently we consider Core and MPU dvfs transitions independently.
In the case of core PD:
With frequency dependency on core domain, we have almost all devices
depending to scale core domain frequency scaling. Currently, we restrict
ourselves to checking just core or IVA domain before deciding the domains
should remain ON, instead we should be checking for all devices scaling.
In the case of MPU PD:
If we interrupt dvfs scaling executing on MPU for a different domain(e.g IVA),
we should let it complete rather than go through the motions of programming
and exiting the transition, and leaving the dvfs transition which had started
half done and mpu hitting idle state. In cases such as IVA dvfs, this might
tend to become even fatal as clk configurations need to go through syslink
on A9 when requested from Ducati - So even if A9 is not really busy, Ducati
could be waiting for the action to complete.
Currently we can create all kind of weird cases with DVFS Vs LP
use cases such as MPUSS successfully in OSWR but CORE in ON because
we interrupted SGX dvfs scale or something similar. Instead,
simplify sequencing by denying transition to LP if DVFS was caught
when we dont want to be interrupted.
We do this after clearing the previous states to allow the callers
to detect a failed transition.
Also suspend is prevented if there is an ongoing DVFS.
If we interrupt an device scale operation, it is possible that
we might have caught the operation off-guard such as in the middle
of voltage scale or even frequency change operation. we might be
unable to guarentee that all cross domain dependencies are taken
care as well. Instead, we will abort suspend and priortize device
scale operation and allow the system to re-attempt suspend when
the conditions are right for the operation to proceed.
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Vishwanath BS <vishwanath.bs@ti.com>
|
|
Currently omap_dvfs_is_any_dev_scaling is dummy. Instead it should
return if there is any DVFS ongoing. Fix the same.
Signed-off-by: Vishwanath BS <vishwanath.bs@ti.com>
|
|
Signed-off-by: Tero Kristo <t-kristo@ti.com>
|
|
Signed-off-by: Tero Kristo <t-kristo@ti.com>
|
