OMAP3+: voltage: use volt_data pointer instead values

Voltage values can get confusing in meaning with various SmartReflex
classes being active. Depending on the class used, the actual voltage
selected might be a variant. For example:
With SmartReflex AVS class 3:
a) If we don't have SR enabled, we will go to volt_nominal.
b) If have SR enabled, we go to volt_nominal, then enable SR and
   expect it to adjust voltage. We don't really care about the
   resultant voltage.
Essentially, when we ask voltage layer to scale to voltage x for OPP
y, it always means x is the nominal voltage for OPP y.

Now, once we introduce SmartReflex AVS class 1.5:
a) If you are booting for the first time OR if you never enabled SR
   before, we always go to volt_nominal.
b) If you enable SR and the OPP is calibrated, we will not enable SR
   again when that OPP is accessed anymore, but when we set voltage for
   an OPP, the voltage achieved will be volt_calibrated.
c) If recalibration timeout triggers or SR is disabled after a
   calibration, the calibrated values are not valid anymore, at this point,
   setting the voltage will mean volt_dynamic_nominal.
So, depending on which state the system is at, voltage for that OPP
we are setting has not 1 single value anymore, but 3 possible valid
values.

For upper layers(DVFS/cpufreq OMAP SoC layers) to use voltage values, it
will need to know which type of voltage AVS strategy is being used and
the corresponding system state from voltage layer perspective. This
would replicate the role of voltage layer, SmartReflex AVS in the upper
layers and make the corresponding implementations complex.

Since each voltage domain contains a set of volt_data structs representing
a voltage point that is supported for that domain, volt_data is a more
accurate representation of the voltage point we are interested in going to,
and the actual translation of this voltage point to the voltage value is
done inside the voltage layer. Doing this allows the users of the voltage
layer to be blissfully ignorant of any complexity of the underneath
layers and simplify the implementation of dependent layers.

Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Vishwanath BS <vishwanath.bs@ti.com>
Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
OMAP3+: SR: introduce class start,stop and priv data

Certain class drivers such as class 1.5 drivers, will need specific
notification that they have to be started up or stopped independent
of smart reflex operation. They also may need private data to be
used for operations of their own, provide the same.
This allows the class driver to initialize it's internal data structures
on a need basis in preparation for the specific domain's autocomp usage.
The resultant operation is as follows:
when autocomp is set to 1 -> class drivers' start is called
The existing enable/disable is still used as before by the SmartReflex
core driver to enable disable the class operation.
When autocomp is set to 0 -> class drivers' stop is called, signaling
the end of usage for that domain.

Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
OMAP3+: SR: Reuse sr_[start|stop]_vddautocomp functions

sr_start_vddautocomp and sr_stop_autocomp functions can be reused from
omap_sr_enable, omap_sr_disable and omap_sr_disable_reset_volt and by
adding one additional argument sr_stop_autocomp. This allows us to have
a single point where SR enable and disable operations are controlled from.

[nm@ti.com: synced it up with class start/stop as well. autocomp flag
 should only be disabled when SR is disabled for that domain]
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Jarkko Nikula <jhnikula@xxxxxxxxx>
Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
OMAP3+: SR: introduce notifiers flags

SmartReflex IP V1 and V2 have different registers and offsets.
Currently, we pass the status as is to the class driver. However,
since we don't pass the version of the underlying SR hardware
to the Class driver, it will not be unable to make consistent
sense of the status bits coming over to it.

A class driver should be able to function without dependency
on the exact IP version it is actually running on. We hence
introduce our own translation in software level for a generic
notification flag.

As part of this change, we will now call the notifier iff we get
a match with the notifier flags that the class driver requested.

Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
OMAP3+: SR: introduce notifier_control

We need some mechanism from class drivers to control when notifiers
should be triggered and when not, currently we have none, which makes
Class driver usage of the interrupt events almost impossible.

Introduce an SmartReflex driver API for doing the same. This is useful
for SmartReflex AVS class 1.5 or 2 drivers.

Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
OMAP3+: SR: disable spamming interrupts

At times with bad SR configurations, especially during silicon bring-ups,
we could get continuous spurious interrupts which end up hanging the
platform in the form of an ISR call for status bits that are
automatically enabled by the hardware without any software clearing
option.

If we detect scenarios where ISR was called without the corresponding
notification bit being set, instead of hanging up the system,
we will disable interrupt after noting the event in the system log
to try and keep system sanity and allow developer to debug and fix
the condition.

Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
OMAP3+: SR: make enable path use volt_data pointer

Passing the volt_data pointers across allows us to save us the effort
of looking up the voltage data pointer from the voltage value at
multiple layers, we need to look at the voltage data in DVFS layer
for further processing, so modify the APIs to pass the voltage data
pointer all the way through to lower layers to the SmartReflex AVS class
drivers.

Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
OMAP3630+: SR: add support for class 1.5

Traditional SmartReflex AVS(Automatic Voltage Scaling) classes are:
* Class 0 - Product test calibration
        Silicon is calibration at production floor and fused with voltages
        for each OPP
* Class 1 - Boot time calibration
        Silicon is calibrated once at boot time and voltages are stored for
        the lifetime of operation.
* Class 2 - Continuous s/w calibration
        SR module notifies s/w for any change in the system which is desired
        and the s/w makes runtime decisions in terms of setting the voltage,
        this mechanism could be used in the system which does not have PMIC
        capable of SR without using the voltage controller and voltage
        processor blocks.
* Class 3 - Continuous h/w calibration
        SR module is switch on after reaching a voltage level and SR
        continuously monitors the system and makes runtime adjustments without
        s/w involvement.

OMAP3430 has used SmartReflex AVS and with a a PMIC which understands the SR
protocol, Class 3 has been used. With OMAP3630 onwards, a new SmartReflex AVS
class of operation Class 1.5 was introduced.
* Class 1.5 - Periodic s/w calibration
        This uses the h/w calibration loop and at the end of calibration
        stores the voltages to be used run time, periodic recalibration is
        performed as well.

The operational mode is describes as the following:
* SmartReflex AVS h/w calibration loop is essential to identify the optimal
        voltage for a given OPP.
* Once this optimal voltage is detected, SmartReflex AVS loop is disabled in
        class 1.5 mode of operation.
* Until there is a need for a recalibration, any further transition to an OPP
        voltage which is calibrated can use the calibrated voltage and does not
       require enabling the SR AVS h/w loop.
* On a periodic basis (recommendation being once approximately every 24 hours),
        software is expected to perform a recalibration to find a new optimal
        voltage which is compensated for device aging.
        - For performing this recalibration, the start voltage does not need to
        be the nominal voltage anymore. instead, the system can start with a
        voltage which is 50mV higher than the previously calibrated voltage to
        identify the new optimal voltage as the aging factor within a period of
        1 day is not going to be anywhere close to 50mV.
        - This "new starting point" for recalibration is called a dynamic
        nominal voltage for that voltage point.
In short, with the introduction of SmartReflex class 1.5, there are three new
voltages possible in a system's DVFS transition:
* Nominal Voltage - The maximum voltage needed for a worst possible device
        in the worst possible conditions. This is the voltage we choose as
        the starting point for the h/w loop to optimize for the first time
        calibration on system bootup.
* Dynamic Nominal Voltage - Worst case voltage for a specific device in
        considering the system aging on the worst process device.
* Calibrated Voltage - Best voltage for the current device at a given point
        of time.

In terms of the implementation, doing calibration involves waiting for the
SmartReflex h/w loop to settle down, and doing this as part of the DVFS flow
itself is to increase the latency of DVFS transition when there is a need to
calibrate that opp. instead, the calibration is performed "out of path" using
a workqueue statemachine. The workqueue waits for the system stabilization,
then enables VP interrupts to monitor for system instability interms of voltage
oscillations that are reported back to the system as interrupts, in case of
prolonged system oscillations, nominal voltage is chosen as a safe voltage and
this event is logged in the system log for developer debug and fixing.
For the recalibration, a common workqueue for all domains is started at the
start of the class initialization and it resets the calibrated voltages
on a periodic basis. For distros that may choose not to do the recommended
periodic recalibration, instead choose to perform boot time calibration,
kconfig configuration option is provided to do so.

TODO:
a) Cpuidle and suspend paths are not integrated with SmartReflex driver at
   this point.
b) Since the SR registers are accessed and controlled in parallel to DVFS
   some sort of mechanism is necessary to be introduced along with OMAP
   DVFS layer to ensure mutual exclusivity
c) Additional debug interfaces for vmin analysis for platform characterization
   and addition of system margin needs to be introduced from SmartReflex
   perspective.

This implementation also includes the following contributors:
Tony Lindgren for suggestion on using interrupt based mechanism instead of
polling to detect voltage oscillations.
Peter 'p2' De Schrijver for debating alternatives on recalibration mechanisms
Paul Walmsey, Eduardo Valentin, Ambresh K, Igor Dmitriev and quiet a few others
for patient review, testing and reporting of issues of a previous incarnation
of this implemenation. Last, but not the least, the TI H/w team in introducing
this new SR AVS class and patiently debating it's various facets.

Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
OMAP: SR: menu changes for selecting the SmartReflex operating mode

Kconfig changes to add menu option for selecting between the SmartReflex
operating modes (class 3.0 / class 1.5).

Signed-off-by: Lesly A M <leslyam@ti.com>
Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
OMAP3PLUS PM: Fix issue with calibration reset

volt_data was was wrongly received in function omap_voltage_calib_reset.
Patch fixes the same.

Signed-off-by: Vishwanath BS <vishwanath.bs@ti.com>
Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
OMAP2+ PM: Add support for TPS62361

    TPS62361 is a new PMIC used with OMAP4460 on SDP4430 platform
    to supply MPU VDD.
    Rest of the VDDs continue to be supplied via TWL6030.

    As part of this, the following have been moved to common
    location in voltage.h
    OMAP4_VP_CONFIG_ERROROFFSET, OMAP4_VP_VSTEPMIN_VSTEPMIN,
    OMAP4_VP_VSTEPMAX_VSTEPMAX, OMAP4_VP_VLIMITTO_TIMEOUT_US

[nm@ti.com: cleaned up TPS to handle board variations]
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Vishwanath BS <vishwanath.bs@ti.com>
Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
OMAP4460 OPP: Add OMAP4460 OPP Data

Add OMAP4460 OPP Data.

Signed-off-by: Vishwanath BS <vishwanath.bs@ti.com>
Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
OMAP4 HWMOD: Do not reset GPIO1

Since OMAP4460 GPIO8 is used to select TPS Voltage, do not reset GPIO1 bank to avoid boot
failures.

Signed-off-by: Vishwanath BS <vishwanath.bs@ti.com>
Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
OMAP2PLUS CPUFREQ: Add support for OMAP4460 MPU DVFS

Add right clock node details for OMAP4460.

Signed-off-by: Vishwanath BS <vishwanath.bs@ti.com>
Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
OMAP4460 OPP: Add OPP support for OMAP4460

Patch does the following.
1. Add OMAP4460 specific voltage data
2. Remove OPP entries for devices which do not have omap_device

Signed-off-by: Vishwanath BS <vishwanath.bs@ti.com>
Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
OMAP3PLUS DVFS: Remove frequency based usecounting in DVFS

Now it is confirmed that as part of DVFS, both frequency and Voltages have
to be scaled as part of dependency VDD handling. So there is no need to keep
track of frequency user list now.

Signed-off-by: Vishwanath BS <vishwanath.bs@ti.com>
Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
OMAP: DVFS: Adding volt request for dep domain should be based on user value

The volt request for dependent domain should be added based on the user requested value but _not_ from the plist of the voltdm.

There is a corner case issue, where two req_dev which share the same voltdm does device_scale.
And that voltdm has dependency on other voltdm. In this scenario,
one of the req_dev will end up not releasing the request from the _dependent_ volt domain.

For example:
rpres requests for 266MHz => 1.14V on IVA.
aess requests  for 196MHz => 1.14V on IVA.

If we follow the code flow. rpres will add user request on IVA voltdm. As IVA has
dependency on CORE, this will add a user request on CORE. And something similar for aess
as well. aess adds user requst on IVA and IVA adds user request on CORE.

So far so good. Now, rpress releases the request by requesting OPP50 freq. Assume, aess didn't
release the request yet. So the code flow will be, rpress requests for OPP50 freq and updates
the existing user request to OPP50 volt on IVA. However, IVA ends up updating user request for OPP100
on CORE instead of OPP50. Because the dependent domain volt request is taken from the plist. And in
the plist for IVA voltdm the higest volt is still OPP100, as aess is still active. So, this will
end up rpress to have OPP100 request on CORE voltdm always.

Fix:
Move the scaning of dependent volt at the early stage in device_scale and update the request
for dependent domain with user requested rate and not the plist value.

Signed-off-by: Girish S G <girishsg@ti.com>
Signed-off-by: Vishwanath BS <vishwanath.bs@ti.com>
Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
OMAP2+: powerdomain: control power domains next state

When a PM QoS device latency constraint is requested or removed the
PM QoS layer notifies the underlying layer with the updated aggregated
constraint value. The constraint is stored in the powerdomain constraints
list and then applied to the corresponding power domain.
The power domains get the next power state programmed directly in the
registers via pwrdm_wakeuplat_update_pwrst.

Tested on OMAP3 Beagleboard and OMAP4 Pandaboard in RET/OFF using
wake-up latency constraints on MPU, CORE and PER.

Signed-off-by: Jean Pihet <j-pihet@ti.com>
Reviewed-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
OMAP2+: omap_hwmod: manage the wake-up latency constraints

Hwmod is queried from the OMAP_PM layer to manage the power domains
wake-up latency constraints. Hwmod retrieves the correct power domain
and if it exists it calls the corresponding power domain function.

Tested on OMAP3 Beagleboard and OMAP4 Pandaboard in RET/OFF using wake-up
latency constraints on MPU, CORE and PER.

Signed-off-by: Jean Pihet <j-pihet@ti.com>
Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
OMAP: PM: register to the per-device PM QoS framework

Implement the devices wake-up latency constraints using the global
device PM QoS notification handler which applies the constraints to the
underlying layer by calling the corresponding function at hwmod level.

Tested on OMAP3 Beagleboard and OMAP4 Pandaboard in RET/OFF using wake-up
latency constraints on MPU, CORE and PER.

Signed-off-by: Jean Pihet <j-pihet@ti.com>
Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>