ARM: OMAP2+: hwmod: Fix sidle programming in _enable_sysc()/_idle_sysc()

_enable_sysc() and _idle_sysc() handle the midle mode programming correctly
and program HWMOD_IDLEMODE_SMART or HWMOD_IDLEMODE_SMART_WKUP respectively
for supported IPs (The ones which support hardware controlled midle modes)

However the same programming logic is missing when it comes to sidle mode
programming. Here they seem to just set HWMOD_IDLEMODE_SMART (Again for the
ones which support hardware controlled sidle modes)

This problem was hidden due to the fact that a call to _enable_wakeup()
in those same functions would overwrite the idlemodes and program them
correctly (to HWMOD_IDLEMODE_SMART_WKUP in the supported cases)

So fix the sidlemode handling correctly in these functions and handle the
_enable_wakeup() for SIDLEMODE supported IPs same as the way its handled
for MIDLEMODE supported ones.

Tested-by: Vaibhav Bedia <vaibhav.bedia@ti.com>
Tested-by: Sourav Poddar <sourav.poddar@ti.com>
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
ARM: OMAP2+: hwmod: Add a new flag to handle SIDLE in SWSUP only in active

Some IPs (like UART) need the sidle mode to be controlled in SW only
while they are active. Once they go inactive, they need the IP to be
put back in HW control so they are also wakeup capable.

The flag HWMOD_SWSUP_SIDLE takes care of IPs which need the sidle
mode to be *always* controlled in SWSUP. We now have a need to control
IPs sidle mode in SWSUP only while its active.

So define a new flag 'HWMOD_SWSUP_SIDLE_ACT' to help the framework
know about these new IP requirements.

Tested-by: Vaibhav Bedia <vaibhav.bedia@ti.com>
Tested-by: Sourav Poddar <sourav.poddar@ti.com>
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
ARM: OMAP2+: hwmod-data: UART IP needs software control to manage sidle modes

OMAP UART IP needs software control for slave idle modes based on functional
state of the IP. i.e The IP slave idle settings should be set to 'noidle' when
being used and then put back to 'smart_idle' when unused. Currently this is
handled by the driver with function pointers implemented in platform code.
This however breaks in case of device tree because of missing idle handling
APIs.

Previous patches in this series added a flag HWMOD_SWSUP_SIDLE_ACTIVE which
takes care of the mentioned requirement. Hence add the flag for all UART IPs
to take advantage of feature supported by framework.

Subsequent patches removes the slave idle handling from driver code.

Tested-by: Vaibhav Bedia <vaibhav.bedia@ti.com>
Tested-by: Sourav Poddar <sourav.poddar@ti.com>
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
ARM: OMAP2+: serial: Remove the un-used slave idle hooks

UART IP idle handling now taken care by runtime pm backend(hwmod) indirectly
and OMAP serial driver is also cleaned up accordingly.

So remove the un-used slave idle platforms hooks now.

Tested-by: Vaibhav Bedia <vaibhav.bedia@ti.com>
Tested-by: Sourav Poddar <sourav.poddar@ti.com>
Signed-off-by: Rajendra nayak <rnayak@ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
SERIAL: OMAP: Remove the slave idle handling from the driver

UART IP slave idle handling now taken care by runtime pm backend(hwmod layer)
so remove the hackery from the driver.

As discussed on the list, in future if dma mode needs to be brought
back to this driver, UART sysc handling needs to be updated in
framework such a way that no-idle/force idle profile can be supported.
Given the broken dma mode for OMAP uarts, its very unlikely.

Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Tested-by: Vaibhav Bedia <vaibhav.bedia@ti.com>
Tested-by: Sourav Poddar <sourav.poddar@ti.com>
Signed-off-by: Rajendra nayak <rnayak@ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
ARM: OMAP2+: hwmod: Remove sysc slave idle and auto idle apis

With the OMAP serial driver sysc cleanup patches in this series, we can
now remove the hwmod external apis for sysc fiddling.

While at this, also remove unused sysc auto idle api from hwmod code.

Tested-by: Vaibhav Bedia <vaibhav.bedia@ti.com>
Tested-by: Sourav Poddar <sourav.poddar@ti.com>
Signed-off-by: Rajendra nayak <rnayak@ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
clk: OMAP: introduce device tree binding to kernel clock data

OMAP clock data is located in arch/arm/mach-omap2/cclockXYZ_data.c.
However, this presents an obstacle for using these clock nodes in
Device Tree definitions. This is especially true for board specific
clocks initially. The fixed clocks are currently found via clock
aliases table. There are many possible approaches to this problem as
discussed in the following thread:
http://marc.info/?t=136370325600009&r=1&w=2.
Highlights of the options:
a) device specific clk_add_alias:
   cons: driver handling required
b) using an generic clk node and indexing to reach the clock required.
   This is similar in approach taken by tegra and few other platforms.
   Example usage: clock = <&clk 5>;
   cons: potential to have mismatches in indexed table and associated
   dtb data. In addition, managing continued documentation in bindings
   as clock indexing increases. Even though readability angle could be
   improved by using preprocessing of DT using macros, indexed
   approach is inherently risky from cases like the following:
   clk indexes in kernel:
   1 - mpu_dpll
   2 - aux_clk1
   3 - core_clk
   DT entry for peripheral X uses <&clk 2> to reach aux_clk1. Now, let's
   say kernel updates indices to:
   1 - mpu_dpll
   2 - per_dpll
   3 - aux_clk1
   4 - core_clk
   using the old dtb(or dts missing an update), on new kernel which
   has updated indices will result in per_dpll now controlled for
   peripheral X without warning or any potential error detection.

   Even though we could claim this is user error, such errors are hard
   to track down and fix.

An alternate approach introduced here is to introduce device tree
bindings corresponding to the clock nodes required in DT definition
for SoC which automatically maps back to the definitions in
cclockXYZ_data.c.

The driver introduced here to do this mapping will eventually be the
place where the clock handling will migrate to. We need to consider
this angle as well so that the solution will be an valid transition
point for moving the clock data out of kernel image (into device tree
or firmware load etc..).

Overall strategy introduced here is simple: a clock node described in
device tree blob is used to identify the exact clock provided in the
SoC specific data. This is then linked back using of_clk_add_provider
to the device node to be accessible by of_clk_get.

Based on discussion contributions from Roger Quadros, Grygorii Strashko
and others.

Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Mike Turquette <mturquette@linaro.org>
Cc: Paul Walmsley <paul@pwsan.com>
[tony@atomide.com: co-developed]
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
ARM: dts: OMAP3: add clock nodes for CPU

OMAP34xx and OMAP36xx platforms use dpll1 clock. Add same to common
definition.

Cc: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
ARM: dts: OMAP4: add clock nodes for CPU

OMAP443x, OMAP446x and OMAP447x platforms use dpll_mpu clock.
Add same to common definition.

Cc: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
ARM: dts: AM33XX: add clock nodes for CPU

AM33XX based platforms use dpll_mpu clock. Add same to common dtsi
and remove the dummy clock node entry as AM33XX platform supports
only device tree based boot.

Cc: Benoit Cousson <b-cousson@ti.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Tony Lindgren <tony@atomide.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
ARM: OMAP2+: AM33XX: add lateinit hook for calling pm late init

Call OMAP2+ generic lateinit hook from AM specific late init hook.
This allows the generic late initializations such as cpufreq hooks
to be active.

Cc: Benoit Cousson <b-cousson@ti.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Tony Lindgren <tony@atomide.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
ARM: OMAP3+: use cpu0-cpufreq driver in device tree supported boot

With OMAP3+ and AM33xx supported SoC having defined CPU device tree
entries with operating-points and clock nodes defined, we can now use
the SoC generic cpufreq-cpu0 driver by registering appropriate device.

Cc: Benoit Cousson <b-cousson@ti.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Tony Lindgren <tony@atomide.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Merge branch 'push/uart-fixes-sidle-3.10' into devel/vc-vp-base
Merge branch 'master' into devel/vc-vp-base
cpufreq: cpufreq-cpu0: defer probe when regulator is not ready

With commit 1e4b545, regulator_get will now return -EPROBE_DEFER
when the cpu0-supply node is present, but the regulator is not yet
registered.

It is possible for this to occur when the regulator registration
by itself might be defered due to some dependent interface not yet
instantiated. For example: an regulator which uses I2C and GPIO might
need both systems available before proceeding, in this case, the
regulator might defer it's registration.

However, the cpufreq-cpu0 driver assumes that any un-successful return
result is equivalent of failure.

When the regulator_get returns failure other than -EPROBE_DEFER, it
makes sense to assume that supply node is not present and proceed with
the assumption that only clock control is necessary in the platform.

With this change, we can now handle the following conditions:
a) cpu0-supply binding is not present, regulator_get will return
appropriate error result, resulting in cpufreq-cpu0 driver controlling
just the clock.
b) cpu0-supply binding is present, regulator_get returns
-EPROBE_DEFER, we retry resulting in cpufreq-cpu0 driver registering
later once the regulator is available.
c) cpu0-supply binding is present, regulator_get returns
-EPROBE_DEFER, however, regulator never registers, we retry until
cpufreq-cpu0 driver fails to register pointing at device tree
information bug. However, in this case, the fact that cpufreq-cpu0
operates with clock only when the DT binding clearly indicates need of
a supply is a bug of it's own.
d) cpu0-supply gets an regulator at probe - cpufreq-cpu0 driver
controls both the clock and regulator

Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
Acked-by: Shawn Guo <shawn.guo@linaro.org>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Nishanth Menon <nm@ti.com>
ARM:dts:omap4-panda: Update the LED support for the panda DTS

The GPIO for LED D1 on the omap4-panda a1-a3 rev and the omap4-panda-es
are different.

A1-A3 = gpio_wk7
ES = gpio_110

There is no change to LED D2

Abstract away the pinmux and the LED definitions for the two boards into
the respective DTS files.

Signed-off-by: Dan Murphy <dmurphy@ti.com>
Merge tag 'v3.10-rc2' into devel/vc-vp-base

Linux 3.10-rc2
regulator: Introduce OMAP regulator to control PMIC over VC/VP

Texas Instrument's OMAP SoC generations since OMAP3-5 introduced
an TI custom hardware block to better facilitate and standardize
integration of Power Management ICs which communicate over I2C.

In fact, many custom PMICs were designed to be usable over this
interface. On the other hand, generic PMICs which are compatible
to the I2C protocol supported by Voltage controller may also be
used.

In general, the following categories of PMICs exist:

a) PMICs which are completely controlled by voltage controller/voltage
processor pair - this implies even configuration needs to be done
over the same interface. Example: TPS62361 used on PandaBoard-ES and
many OMAP4460 based platforms. Few Maxim and Fairchild PMICs used on
certain products would fall in this category.
- Note: in this case, there may not even exist/needed to support an
"traditional Linux regulator driver"

b) PMICs which provide two views over two I2C interfaces - however,
voltage can only be set only on one of them. Example: TWL4030/5030:
allows us to use Voltage controller once we set up a bit over regular
I2C - This is used in OMAP3. TWO6030/TWL6032 - configuration *has*
to be performed over regular i2c (example smps_offset) and voltage
control *has* to be performed by using voltage controller/processor.
- Note: in this case, there may exist "traditional Linux regulator driver"
however, it may not support in any form SMPS modelling for that part of
the device which is exposed to voltage controller/processor.
c) PMICs which allow voltage and configurations over either i2c
interfaces - TWL6035/TWL6037/Palmas family of TI processor
- Note: in this case, there may exist "traditional Linux regulator driver"
and, it may support in some form SMPS modelling for that part of
the device which is exposed to voltage controller/processor.
d) custom PMICs which are setup so that no configuration is needed to be
performed and they operate with preset register offsets and minimal
conferability using voltage controller/processor.
- Note: in this case, there may not even exist/needed to support an
"traditional Linux regulator driver"

However, no matter the type of PMIC used, the OMAP view of a PMIC is
generic when used over voltage controller/processor. We attempt to
model this generic view of the regulator represented by OMAP SoC.

Alternative to this approach would be to "hack" into the get
voltage/set voltage interfaces of regulator drivers which represent
the rest of the PMIC controlled over regular I2C interface and
re-route the requests to voltage controller/processor. But, by doing
that, we needlessly create additional code which may be abstracted out
into device tree node information.

Since the regulator node representing PMIC, voltage controller,
processors are probed at varied points in time, probe deferral is used
to sequence in the right order. It is expected by the driver to register
omap_pmic_register_controller_ops providing mandatory operations at the
earliest possible opportunity.

Despite the current SoCs implementing the solution based on voltage
controller and voltage processor (which are part of the OMAP SoC modules
which enable Adaptive Voltage Scaling class support), the interfaces are
generic enough to handle future equivalent modules.

[grygorii.strashko@ti.com: co-developer]
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
PM / AVS: Introduce support for OMAP Voltage Controller(VC) with device tree nodes

Texas Instrument's OMAP SoC generations since OMAP3-5 introduced an TI
custom hardware block to better facilitate and standardize integration
of Power Management ICs which communicate over I2C called Voltage
Controller(VC).

This is an specialized hardware block meant to support PMIC chips and
is customized to that requirement. Even though it functions as an I2C
controller, it is a write-only interface whose configurations are custom
to PMICs.

We have an existing implementation in mach-omap2 which has been
re factored and moved out as a separate driver. This new driver is DT
only and the separation was meant to get a maintainable driver which
does not have to deal with legacy platform_data dependencies. The legacy
driver is retained to support non-DT boot and functionality will be
migrated to the DT-only version as we enable features.

Currently, this implementation considers only the basic steps needed for
voltage scaling and exposing voltage controller as a device whose
child devices are voltage controller channel devices.

We may need to do additional timing configurations to enable Low power
mode voltage transitions, but this will be completed in a following
series. We may need a few tweaks to hook the Adaptive Voltage
Scaling(AVS) implementation for OMAP which also uses the same voltage
controller to talk to PMICs.

This driver is meant to interface with voltage processor when the
voltage processor attempts devm_omap_vc_channel_get for the
VC channel corresponding to the voltage processor.

[grygorii.strashko@ti.com: co-developer]
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
PM / AVS: Introduce support for OMAP Voltage Processor(VP) with device tree nodes

Texas Instrument's OMAP SoC generations since OMAP3-5 introduced an TI
custom hardware block to better facilitate and standardize integration
of Power Management ICs which communicate over I2C called Voltage
Processor(VP).

This is an specialized hardware block meant to support PMIC chips only
over Voltage Controller(VC) interface. This provides an interface for
SmartReflex AVS module to send adjustment steps which is converted into
voltage values and send onwards by VP to VC. VP is also used to set the
voltage of the PMIC by commanding using "forceupdate".

We have an existing implementation in mach-omap2 which has been
re factored and moved out as a separate driver. This new driver is DT
only and the separation was meant to get a maintainable driver which
does not have to deal with legacy platform_data dependencies. The legacy
driver is retained to support non-DT boot and functionality will be
migrated to the DT-only version as we enable features.

Currently, this implementation considers only the basic steps needed for
voltage scaling and exposing voltage processor which hooks on to Voltage
Controller driver and OMAP PMIC driver to provide an regulator interface
over OMAP PMIC driver.

We may need to do additional timing configurations to enable Low power
mode voltage transitions and to hook the Adaptive Voltage
Scaling(AVS) implementation for OMAP which also uses the same voltage
controller to talk to PMICs. This needs to be addressed in a later
series.

This driver is meant to interface with OMAP PMIC driver when the
controller driver registers it's operations with OMAP PMIC driver and
associates with an voltage controller channel. This enables the full
communication path between the OMAP PMIC regulator to the external PMIC
hardware over OMAP Voltage Processor and OMAP Voltage Controller.

[grygorii.strashko@ti.com: co-developer]
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>