thermal: expose thermal_zone_get_temp API

This patch exports the thermal_zone_get_temp API so that driver
writers can fetch temperature of thermal zones managed by other
drivers.

Acked-by: Zhang Rui <rui.zhang@intel.com>
Acked-by: Durgadoss R <durgadoss.r@intel.com>
Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>

thermal: introduce thermal_zone_get_zone_by_name helper function

This patch adds a helper function to get a reference of
a thermal zone, based on the zone type name.

It will perform a zone name lookup and return a reference
to a thermal zone device that matches the name requested.
In case the zone is not found or when several zones match
same name or if the required parameters are invalid, it will return
the corresponding error code (ERR_PTR).

Acked-by: Zhang Rui <rui.zhang@intel.com>
Acked-by: Durgadoss R <durgadoss.r@intel.com>
Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>

staging: ti-soc-thermal: add dra752 chip to device table

Add support to TI dra752 chips by adapting the driver
device table.

Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>

staging: ti-soc-thermal: add thermal data for DRA752 chips

This patch adds the thermal data for TI DRA752 chips.
In this change it includes (autogen):
. Register offset definitions
. Bitfields and masks for all registers
. Conversion table

Also, the thermal limits, thresholds and extrapolation
rules are included. The extrapolation rule is simply
add +2C as margin.

All 5 sensors, MPU, GPU, CORE, DSPEVE and IVA, are defined
and exposed. Only MPU has cooling device.

Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>

regulator: introduce TI AVS class 0 driver

OMAP5 technology based processors such as DRA7XX[1] has an simplified AVS
strategy called SmartReflex[2] Class 0. Texas Instrument's nomenclature for
this is: Class - 0: Production Test Calibration

This, in it's simplistic form implies that the voltage value for each OPP
is now encoded into an efuse location.

On entering an OPP, the voltage value to be selected is no longer the
traditional nominal voltage, but the voltage meant from the efuse offset
encoded in millivolts. Each device will have it's own unique voltage for a
given OPP. Therefore, it is not possible to encode a range of voltage
representing an OPP voltage.

DRA processors may be powered using various PMICs - I2C based ones such
as TPS659039 or SPI / GPIO controlled ones as well.

cpufreq/devfreq driver which controls voltage and frequency pairs traditionally
used:
cpufreq/devfreq --> PMIC regulator
                \-> clock framework
This opens up a few issues:
a) PMIC regulator is designed for platforms that maynot use SmartReflex class 0
   based SoCs, encoding the efuse offsets into every possible PMIC regulator
   driver is practically in-efficient.
b) Voltage values are not known a-priori to be encoded into DTB as they are
   device specific.

Another option might have been to start off with the nominal voltages in
DT and then fixup the voltage entries in the OPP table by reading the
eFuse information.

However, such an approach introduces formidable constraints:
A) OPP tables once added are not modifiable beyond enable/disable - that
was the entire design constraint we wanted on OPP tables
B) We need some indexing value for uniquely identifying what to do for
an given OPP voltage - if OPP voltage by itself changes, how do we index
various subsystems? - read abb/avs class 2 based class 1.
C) We have n voltage domains and m devices per domain. - we no longer
want to maintain an centralized OPP table.
D) We also need to support multiple platforms which have "ganged voltage
rails" each domain with variable voltages.
E) Modification of the OPP data itself is hard - considering that we do
not have a centralized OPP repository, architecture independent drivers
like cpufreq-cpu0 driver does the "adding of OPPs".

Options:
a) modify arch generic drivers such as cpufreq-cpu0 driver with an OMAP
specific an efuse offset and OMAP specific handling is a bad idea.
b) we are able to overlay OPP table entried *before* cpufreq driver
comes active
- I am not sure we have ability to do that in kernel yet
- I am not even sure we can modify the dtb being loaded by all
bootloaders we may have (thinking beyond u-boot).

To simplify this, we introduce:
cpufreq/devfreq --> SmartReflex Class 0 regulator --> PMIC regulator
                \-> clock framework

Class 0 Regulator has information of translating the "nominal voltage" into
voltage value stored in efuse offset.
Example encoding:
uVolts mVolt  --> stored as 16 bit hex value of mV
975000 975 --> 0x03CF
1075000 1075 --> 0x0433
1200000 1200 --> 0x04B0

[1] http://www.ti.com/lit/ds/sprt659/sprt659.pdf
[2] http://www.ti.com/lit/wp/swpy015a/swpy015a.pdf

Signed-off-by: Nishanth Menon <nm@ti.com>

regulator: introduce regulator chain locking scheme

In some cases the regulators may be organized in a chain like:
  ->regA->regB->regC
where regA is supplier for regB and regB is supplier for regC.

Currently it would be possible to reconfigure regA and regC at same time
form different contexts, because each regulator has it own mutex.
But in some cases, the only the whole chain is allowed be reconfigured
because of dependencies between regulators - to change regB
configuration the regA need to be updated first.

Hence, introduce regulator chain locking scheme to lock whole Regulator
chain in case if any part of it has been accessed from outside. To
achieve this goal the root Regulator (which has no supply defined, like
regA) in chain is used to protect the whole chain.

In addition, such locking scheme allows to have access to the supplier
regulator API from inside child's (consumer) regulator API.

Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>

regulators: abstract locking out into helper functions

Create locking helpers for the regulator mutex. These helpers will be
needed for the next patch which introduces Regulator chain locking
scheme.

Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>

rtc: palmas: Enable device tree support for Palmas RTC.

Enable device tree support for Palmas RTC.
The Documentation is updated here:
Documentation/devicetree/bindings/rtc/palmas-rtc.txt

Signed-off-by: J Keerthy <j-keerthy@ti.com>

rtc: palmas: Add RTC driver Palmas series PMIC

TI Palmas series PMIC support the RTC and alarm functionality.
Add RTC driver with alarm support for this device.

This patch is picked from the mainline kernel.
https://patchwork.kernel.org/patch/1926921/
Commit id: 0101e53cbb1c653738de8dfddc80c0faa5a4fd39

Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
[j-keerthy@ti.com: backport from upstream 0101e53cbb1c653738de8dfddc80c0faa5a4fd39]
Signed-off-by: J Keerthy <j-keerthy@ti.com>

rtc: Revert rtc-palmas driver for palmas PMIC

This reverts commit 5e3935c6e9d8d1bd05d39fde55b913f85a1b42a4.
(rtc: rtc-palmas a new driver for palmas PMIC). Removing
the intermediate version of the driver to absorb the upstreamed
driver.

Signed-off-by: J Keerthy <j-keerthy@ti.com>

mfd: palmas: Add rtc irq number as irq resource for palmas-rtc

Palma RTC is capable of generating alarm interrupt. Pass the alarm interrupt
as IRQ_RESOURCE for palmas-rtc sub device driver so that rtc driver can get
irq as platform_get_irq().

Also pass the irq domain in mfd_add_devices() to properly offset the irqs for
sub devices. This is needed when adding device through DT.

This patch is absorbed from the Mainline kernel:
http://lkml.indiana.edu/hypermail/linux/kernel/1301.0/00559.html
Commit id: a36516b016f52f0f6e5284025e3487f63b4be33b

Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
[j-keerthy@ti.com: backport from upstream a36516b016f52f0f6e5284025e3487f63b4be33b]
Signed-off-by: J Keerthy <j-keerthy@ti.com>

mfd: palmas: Add APIs to access the Palmas' registers

Palmas register set is divided into different blocks (base and offset)
and hence different i2c addresses. The i2c address offsets are derived
from base address of block of registers.

Add inline APIs to access the Palma's registers which takes the base of
register block and register offset. The i2c address offset is  derived
from the base address of register blocks.

This patch is picked up from Mainline kernel:
https://patchwork.kernel.org/patch/1926911/
Commit id: 60c185f059c88ad4b9b170b1f9322e3adcccca07

Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
[j-keerthy@ti.com: backport from upstream 60c185f059c88ad4b9b170b1f9322e3adcccca07]
Signed-off-by: J Keerthy <j-keerthy@ti.com>

ARM/dts: add dtsi file for TPS659038 device

Add dtsi file for TPS659038 device.

The Documents referred:
1) TPS659039-Q1 POWER MANAGEMENT UNIT (PMU) FOR PROCESSOR Data Manual
2) TPS659038/39-Q1 Functional Register Descriptions.

Signed-off-by: J Keerthy <j-keerthy@ti.com>

regulators: palmas: Add TPS659038 support

Add TPS659038 support. The TPS659038 belongs to PALMAS family.
The only difference between TPS659038 and TWL6035 w.r.t
regulators is the SMPS10 is not present in TPS659038.

Signed-off-by: J Keerthy <j-keerthy@ti.com>

mfd: Palmas: Add TPS659038 PMIC support

The Patch adds TPS659038 PMIC support in the palmas mfd driver.
The TPS659038 has almost the same registers as of the earlier
supported variants of PALMAS family such as the TWL6035.

The critical differences between TPS659038 and TWL6035 being:

1) TPS659038 has nothing related to battery charging and back up battery stuff.
2) TPS659038 does not have does not have SMPS10(Boost) step up convertor.
3) TPS659038 does not have Battery detection and anything related to battery.
4) TPS659038 has something more than Palmas in one case it is called
   Sync clock Functionality.
5) can use an external crystal unit or 16MHz oscillator to generate clock.
6) SD card detection, Battery presence detection, Vibrator, USB OTG are missing
   when compared to TWL6035.

Hence some of the IRQs are reserved in case of TPS659038 but the
remaining are bit exact compared to TWL6035.

Signed-off-by: J Keerthy <j-keerthy@ti.com>

mfd: Palmas: Introduce palmas_pmic_data structure

Introduce palmas_pmic_data structure so that Palmas variants
like TWL6035, TWL6037, TPS65913 can populate data specific
to them. This enables driver to support variants.

Signed-off-by: J Keerthy <j-keerthy@ti.com>

mfd: DT bindings for the palmas family MFD (v10)

Add the various binding files for the palmas family of chips.
There is a top level MFD binding then a seperate binding for IP blocks on chips.

This patch is picked up from v10 of the palmas patch set:
https://patchwork.kernel.org/patch/2321171/

Signed-off-by: Graeme Gregory <gg@slimlogic.co.uk>
[j-keerthy@ti.com: backport from v10 of the palmas patch set:
https://patchwork.kernel.org/patch/2321171/]
Signed-off-by: J Keerthy <j-keerthy@ti.com>
Signed-off-by: Ian Lartey <ian@slimlogic.co.uk>

Merge remote-tracking branch 'rnayak/platform-base-vayu-3.8.y' into vayu-pm-linux-3.8.y

Conflicts:
arch/arm/mach-omap2/clockdomain.h
arch/arm/mach-omap2/control.h
arch/arm/mach-omap2/omap-hotplug.c
arch/arm/mach-omap2/omap-mpuss-lowpower.c
arch/arm/mach-omap2/pm_omap4plus.c

Signed-off-by: Tero Kristo <t-kristo@ti.com>

ARM: DRA7: Prevent any low power entry in suspend

On DRA7 we do not support low power for MPU in either suspend or
cpuidle.

Signed-off-by: Rajendra Nayak <rnayak@ti.com>

ARM: DRA7: Add the build support

Adding the build support required for DRA7xx soc
in to omap2+ config.

Signed-off-by: R Sricharan <r.sricharan@ti.com>

ARM: DRA7: Add PRM dev_inst module offset in global_warm_reset function

Currently omap4_prminst_global_warm_reset function is invoked by
OMAP4/5 socs upon a system reboot command. Add the right PRM module
device_inst offset for DRA_7xx devices, to reuse it for
DRA7xx as well.

Signed-off-by: Sricharan R <r.sricharan@ti.com>

ARM: DRA7: Enable framework initializations

Initialise the power, HWMOD, clock domains and the clock tree.

Signed-off-by: Ambresh K <ambresh@ti.com>

ARM: DRA7: hwmod data: Create initial DRA7XX SOC hwmod data

Adding the hwmod data for DRA7XX platforms.

Signed-off-by: Ambresh K <ambresh@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>

ARM: DRA7: clock data: Add DRA7XX full clock tree and headers

Add the clock tree related data for DRA7XX platforms.

Signed-off-by: Ambresh K <ambresh@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>

ARM: DRA7: powerdomain data: Add DRA7XX data and update the header

Add the data file to describe all power domains inside the DRA7XX soc.

Signed-off-by: Ambresh K <ambresh@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>

ARM: DRA7: clockdomain data: Add DRA7XX data and update the header

Add the data file to describe all clock domains inside the DRA7XX SOC

Signed-off-by: Ambresh K <ambresh@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>

ARM: DRA7: PRCM: Add DRA7XX local MPU PRCM regsiters

Add the PRCM MPU registers for DRA7XX platforms

Signed-off-by: Ambresh K <ambresh@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
[rnayak@ti.com: Added PRCM partition information]
Signed-off-by: Rajendra Nayak <rnayak@ti.com>

ARM: DRA7: CM: Add DRA7XX register and bitfield files

Add the new defines for DRA7XX CM registers.

Signed-off-by: Ambresh K <ambresh@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>

ARM: DRA7: PRM: Add DRA7XX register and bitfield files

Add the new defines for DRA7xx prm module registers.

Signed-off-by: Ambresh K <ambresh@ti.com>

ARM: DRA7: dts: Add the dts files for dra7 SoC and dra7-evm board

The DRA7xx is a high-performance, infotainment application
device, based on enhanced OMAP architecture integrated on a
28-nm technology.

DRA75x, DRA74x belong to the DRA7xx family.
DRA75x and DRA74x are dual core CORTEX A15 SOCs with GIC used
for interrupt handling and with an integrated L2 cache
controller.

Adding the minimum device tree files required for
DRA7xx based socs.

Signed-off-by: R Sricharan <r.sricharan@ti.com>

ARM: DRA7: PM: Avoid all SAR save on dra7

Get rid of all assumptions about always having a sar base on *all*
omap4+ platforms. We dont need one on DRA7.

Signed-off-by: Rajendra Nayak <rnayak@ti.com>

ARM: DRA7: Add static dep from EMIF to MPU

Enable the static dependency between EMIF and MPU.

Signed-off-by: Rajendra Nayak <rnayak@ti.com>

ARM: OMAP2+: Powerdomains: Remove the hard requirement to always have a voltdm assocaited to a pwrdm

The powerdomain framework expects all powerdomains to be asoociated with
a corresponding voltage domain. For some SoCs (like the DRA7 family) which
does not have a Voltage controller/Voltage Processor (neither the SR I2C
bus to communicate with the PMIC) there is no need for a Powerdomain to have
a voltage domain association (since they are really non scalable, even
though the volatge domains exist in place).

Extend the arch operations to add an api which the powerdomain core can
then use to identify if a voltdm lookup and association for a powerdomain
is really needed.

Signed-off-by: Rajendra Nayak <rnayak@ti.com>

ARM: DRA7: Kconfig: Increase the default gpio count

DRA7xx has 8 GPIO banks so that there are 32x8 = 256 GPIOs.
In order for the gpiolib to detect and initialize these
additional GPIOs and other TWL GPIOs, ARCH_NR_GPIO is set
to 512 instead of present 256.

Signed-off-by: R Sricharan <r.sricharan@ti.com>

ARM: DRA7: board-generic: Add device tree support

Adding the minimal support for DRA7xx soc with
device tree.

Signed-off-by: R Sricharan <r.sricharan@ti.com>

ARM: DRA7: timer: Add clocksource, clockevent support

Reusing all the OMAP5 timer code here.
So just adding SOC_DRA7XX check to enable on single
platform build.

Signed-off-by: R Sricharan <r.sricharan@ti.com>

ARM: DRA7: Add minimal support for DRA7xx SOC

The DRA7xx is a high-performance, infotainment application
device, based on enhanced OMAP architecture integrated on a
28-nm technology.

The architecture is designed for advanced graphical HMI and
Navigation, Digital and Analog Radio, Rear Seat Entertainment
and Multimedia playback, providing Advanced Driver Assistance
integration capabilities with Video analytics support, and
best-in-class CPU performance, video, image, and graphics
processing.

DRA75x, DRA74x belong to the DRA7xx family.
DRA75x and DRA74x are dual core CORTEX A15 SOCs with GIC used
for interrupt handling and with an integrated L2 cache
controller.

In this patch:
  Most of the minimal support code is reused from OMAP5.
  - A new early init function is added.
  - The machine specific header is updated for base address
    changes.
  - Makefile updates
  - hwmod file is updated to include the common functions.
  - Updated the sram size

Signed-off-by: R Sricharan <r.sricharan@ti.com>

ARM: DRA7: id: Add cpu detection support for DRA7xx based socs

The DRA7xx is a high-performance, infotainment application device,
based on enhanced OMAP architecture. DRA7xx family is composed
of DRA75x and DRA74x devices.

Adding the DRA752 ES1.0 cpu revision detection support.

Signed-off-by: R Sricharan <r.sricharan@ti.com>

arm: omap2+: omap_device: remove no_idle_on_suspend

Remove "no_idle_on_suspend" check, since respective
driver should be able to prevent idling of an
omap device whenever required.

Driver's can get same behavior by just returning -EBUSY
from their ->runtime_suspend only during suspend.

Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Felipe Balbi <balbi@ti.com>
Cc: Rajendra nayak <rnayak@ti.com>
Cc: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Sourav Poddar <sourav.poddar@ti.com>
Reviewed-by: Felipe Balbi <balbi@ti.com>

arm: omap2+: serial: remove no_console_suspend support

"no_console_suspend" is no longer handled in platform file,
Since the omap serial driver is now adapted to prevent
console UART idleing during suspend.

Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Felipe Balbi <balbi@ti.com>
Cc: Rajendra nayak <rnayak@ti.com>
Signed-off-by: Sourav Poddar <sourav.poddar@ti.com>
Reviewed-by: Felipe Balbi <balbi@ti.com>

driver: serial: omap: prevent runtime PM for "no_console_suspend"

The driver manages "no_console_suspend" by preventing runtime PM
during the suspend path, which forces the console UART to stay awake.

Signed-off-by: Sourav Poddar <sourav.poddar@ti.com>
Reviewed-by: Felipe Balbi <balbi@ti.com>

driver: tty: serial: Move "uart_console" def to core header file.

Move "uart_console" definition to serial core header file, so that it can be
used by serial drivers.
Get rid of the uart_console defintion from mpc52xx_uart driver.

Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Felipe Balbi <balbi@ti.com>
Cc: Rajendra nayak <rnayak@ti.com>
Signed-off-by: Sourav Poddar <sourav.poddar@ti.com>
Reviewed-by: Felipe Balbi <balbi@ti.com>

Merge branch 'platform-base-3.8.y' of git://github.com/hvaibhav/am335x-linux into platform-base-3.8.y

ARM: dts: AM33XX: Set pinmux for clkout2 pad used for clock output

xdma_event_intr1.clkout2 pad can be used to source clock
from either 32K OSC or any of the PLL (except MPU) outputs.
On the existing AM335x based boards (EVM, EVM-SK and Bone),
this pad is used to feed the clock to audio codes.

So, this patch configures the pinmux to get clkout2 on the pad.

Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>

ARM: OMAP AM33XX: clock data: Enable clkout2 as part of init

clkout2 comes out on the pad and is being used by various
external on-board peripherals like, Audio codecs and stuff.
So enable the clkout2 by default during init sequence itself.

Also, add the missing entry of "clkout2_ck" to the clock table.

Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>

ARM: dts: AM33XX: Add support for AM335x BeagleBone-Black

Add DT support for AM335X based (>PG2.x) BeagleBone-Black
board (am335x-boneblack.dts), it is different than original
Bone in terms of on-board peripherals -

- On board HDMI A/V support
- On board eMMC support
- DDR3 support (4Gbit)
- Removal of FTDI chip - So no on board JTAG

This patch adds support all the peripherals reused and
supported on older Bone platforms.

Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>

ARM: compressed/head.S: work around new binutils warning

In August 2012, Matthew Gretton-Dann checked a change
into binutils labelled "Error on obsolete & warn on
deprecated registers", apparently as part of ARMv8
support. Apparently, this was supposed to emit
the message "Warning: This coprocessor register access
is deprecated in ARMv8" when using certain mcr/mrc
instructions and building for ARMv8. Unfortunately,
the message that is actually emitted appears to be
'(null)', which is less helpful in comparison.

Even more unfortunately, this is biting us on
every single kernel build with a new gas, because
arch/arm/boot/compressed/head.S and some other files
in that directory are built with -march=all since
kernel commit 80cec14a8 "[ARM] Add -march=all to
assembly file build in arch/arm/boot/compressed"
back in v2.6.28.

This patch reverts Russell's nice solution and
replaces it with a more complex one that sprinkles
.arch statements inside of the head.S file in
functions that are executed in different architecture
levels, which seems to solve the original problem
just as well, and gets rid of the new one, too.

Without this patch, building anything results in:

arch/arm/boot/compressed/head.S: Assembler messages:
arch/arm/boot/compressed/head.S:565: Warning: (null)
arch/arm/boot/compressed/head.S:676: Warning: (null)
arch/arm/boot/compressed/head.S:698: Warning: (null)
arch/arm/boot/compressed/head.S:722: Warning: (null)
arch/arm/boot/compressed/head.S:726: Warning: (null)
arch/arm/boot/compressed/head.S:957: Warning: (null)
arch/arm/boot/compressed/head.S:996: Warning: (null)
arch/arm/boot/compressed/head.S:997: Warning: (null)
arch/arm/boot/compressed/head.S:1027: Warning: (null)
arch/arm/boot/compressed/head.S:1035: Warning: (null)
arch/arm/boot/compressed/head.S:1046: Warning: (null)
arch/arm/boot/compressed/head.S:1060: Warning: (null)
arch/arm/boot/compressed/head.S:1092: Warning: (null)
arch/arm/boot/compressed/head.S:1094: Warning: (null)
arch/arm/boot/compressed/head.S:1095: Warning: (null)
arch/arm/boot/compressed/head.S:1102: Warning: (null)
arch/arm/boot/compressed/head.S:1134: Warning: (null)

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Matthew Gretton-Dann <matthew.gretton-dann@arm.com>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>

ARM: OMAP3+: am33xx id: Check dev_feature register for available features

Layout of DEV_FEATURE register (offset = 0x604) is different
between TI81xx and AM33xx device, so create separate function
which will check for features available on specific AM33xx SoC
and set the flags accordingly.

Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>

ARM: OMAP2+: AM33XX: omap2plus_defconfig: Add support for few drivers

Adds tps65910 PMIC, lis3lv02d accelerometer, tsl2550 ambient light sensor,
tmp275 temperature sensor, matrix keypad, gbio based leds and D_CAN drivers
support. These peripherals are present on AM33XX family of devices (EVM,
BeagleBone and EVMSK). One has to manually enable these support to use the
drivers, so this patch enables all the drivers in omap2plus_defconfig

Signed-off-by: AnilKumar Ch <anilkumar@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>

staging: ti-soc-thermal: fix device removal

While removing, the device needs to unregister
the sensor from thermal framework. Before
calling the call back the driver needs to check
if the call back is registered. This patch
fix the check by checking the right callback.

Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>

staging: ti-soc-thermal: update OMAP5 extrapolation rules

Update the constants to the correct hotspot extrapolation
equation constants. OMAP4 constants are revisited and correct.

Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>

staging: ti-soc-thermal: introduce OMAP4430 extrapolation constants

This patch defines and utilizes the extrapolation constants for OMAP4430.

Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>

staging: ti-soc-thermal: Remove TC1/TC2 TODO (already done)

TC1/TC2 are not needed anymore, API has been upgraded.
This is a TODO left-over.

Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>

staging: ti-soc-thermal: fix min/max TODO (already done)

Min/Max cooling state are defined by registration helper
function, if no specific limits are passed. No need to change
this code.

Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>

staging: ti-soc-thermal: update TODO list

This patch removes out of the TODO list those already completed.

Here is the status and why they are removed:
 on ti-bandgap.c:
-- Add support to hwmon: REMOVED, no need to have hwmon interfaces
as the control is done via thermal framework.
-- Test every exposed API to userland: DONE, via thermal fw APIs
By now, no specific API is exposed by this driver
-- Revisit data structures and simplify them: DONE, all
unused fields are flagged for future removal.
-- Once SCM-core api settles, update this driver accordingly: DONE,
the BG driver can exist without SCM driver by ioremapping its own
registers and doing its own locking.

 on ti-thermal-common.c/ti-thermal.h:
-- Revisit trips and its definitions: DONE, for now there is no
need to change current definition. Alert based policy will be add
in future.
-- Revisit trending: DONE, OMAP5 history buffer support has been
implemented. Devices without history buffer will use thermal fw
trending capability.

on omap5-thermal.c
-- Add support for GPU cooling: REMOVED: this will not be part
of this driver. Must be done in a separated cooling device.

 generally:
-- make checkpatch.pl and sparse happy: DONE, sparse remaining
warning is not an issue.
-- update documentation: DONE, kernel-doc for ti-bandgap is now
available.

Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>

staging: ti-soc-thermal: Add get_trend support

Patch adds get_trend functionality for OMAP Bandgap thermal devices.

Signed-off-by: J Keerthy <j-keerthy@ti.com>
Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>

staging: ti-soc-thermal:Introduce ti_bandgap_get_trend function for OMAP5

The patch adds ti_bandgap_get_trend function. This is specific
to OMAP5 for now it computes the trend from the temp values stored
in the hardware history buffer.

Formula: (T1 - T2) / P.

Where:
                T1: Last read valid temperature.
                T2: Last but one read valid temperature.
                P:  Update Interval.

Signed-off-by: J Keerthy <j-keerthy@ti.com>
Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>

staging: ti-soc-thermal: Enable HISTORY_BUFFER Feature for OMAP5

This patch enables the HISTORY_BUFFER eature for OMAP5.

Signed-off-by: J Keerthy <j-keerthy@ti.com>
Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>

staging: ti-soc-thermal: Introduce HAS_HISTORY_BUFFER feature for bandgap

The patch introduces HISTORY_BUFFER feature. This is present in OMAP5 bandgap
and it is a hardware history buffer of previously read temperatures.

Signed-off-by: J Keerthy <j-keerthy@ti.com>
Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>

staging: ti-soc-thermal: Modify update_interval r/w functions to incorporate the OMAP5 feature of COUNTER_DELAY.

Update ti_bandgap_write_update_interval and ti_bandgap_read_update_interval
functions to incorporate the OMAP5 feature of COUNTER_DELAY. The way we
program the delay between two successive temperature conversions
is different for OMAP5 as when compared with OMAP4. Incorporating
the changes required to program the delay for OMAP5.

Signed-off-by: J Keerthy <j-keerthy@ti.com>
Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>

staging: ti-soc-thermal: Enable COUNTER_DELAY feature for OMAP5

Enable COUNTER_DELAY feature for OMAP5.

Signed-off-by: J Keerthy <j-keerthy@ti.com>
Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>

staging: ti-soc-thermal: Introduce HAS_COUNTER_DELAY feature for bandgap

Introduce HAS_COUNTER_DELAY feature for bandgap.

Signed-off-by: J Keerthy <j-keerthy@ti.com>
Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>

staging: ti-soc-thermal: Initialise counter_delay field for OMAP5 sensors

Initialize all 3 temperature sensors of OMAP5 bandgap with the counter delay
mask.

Signed-off-by: J Keerthy <j-keerthy@ti.com>
Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>

staging: ti-soc-thermal: Add counter_delay_mask field to temp_sensor_registers struct

Add counter_delay_mask field to temp_sensor_registers structure.

Signed-off-by: J Keerthy <j-keerthy@ti.com>
Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>

arm: omap2plus_defconfig: enable TI bandgap driver

Enable the bandgap driver for TI SoCs thermal support.

Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>

staging: ti-soc-thermal: defer probe if cpufreq is not ready

When builtin compiled, there is a chance for this driver
be probed before cpufreq driver is up and running. In this
case, the cpucooling device can be wrong initialized.

Thus, this patch makes sure this driver is probed only
when cpufreq driver is ready. Whenever there is no
cpufreq driver registered, the probe will return -EPROBE_DEFER.

Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
Tested-by: J Keerthy <j-keerthy@ti.com>

cpufreq: Add a get_current_driver helper

Add a helper function to return cpufreq_driver->name.

Signed-off-by: Borislav Petkov <bp@suse.de>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: J Keerthy <j-keerthy@ti.com>

arm: add bandgap DT entry for OMAP5

Add bandgap device DT entry for OMAP5 dtsi.

Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
Signed-off-by: J Keerthy <j-keerthy@ti.com>

ARM: OMAP3+: use cpu0-cpufreq driver in device tree supported boot(v4)

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.

[nm@ti.com: backport from V4: https://patchwork.kernel.org/patch/2438871/]
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>

cpufreq: OMAP: instantiate omap-cpufreq as a platform_driver(backport)

As multi-platform build is being adopted by more and more ARM platforms,
initcall function should be used very carefully.  For example, when
CONFIG_ARM_OMAP2PLUS_CPUFREQ is built in the kernel, omap_cpufreq_init()
will be called on all the platforms to initialize omap-cpufreq driver.

Further, on OMAP, we now use Soc generic cpufreq-cpu0 driver using device
tree entries.  To allow cpufreq-cpu0 and omap-cpufreq drivers to co-exist
for OMAP in a single image, we need to ensure the following:
 1. With device tree boot, we use cpufreq-cpu0
 2. With non device tree boot, we use omap-cpufreq

In the case of (1), we will have cpu OPPs and regulator registered
as part of the device tree nodes, to ensure that omap-cpufreq
and cpufreq-cpu0 don't conflict in managing the frequency of the
same CPU, we should not permit omap-cpufreq to be probed.

In the case of (2), we will not have the cpufreq-cpu0 device, hence
only omap-cpufreq will be active.

To eliminate this undesired these effects, we change omap-cpufreq
driver to have it instantiated as a platform_driver and register
"omap-cpufreq" device only when booted without device tree nodes on
OMAP platforms.

This allows the following:
 a) Will only run on platforms that create the platform_device
    "omap-cpufreq".
 b) Since the platform_device is registered only when device tree nodes
    are *not* populated, omap-cpufreq driver does not conflict with
    the usage of cpufreq-cpu0 driver which is used on OMAP platforms when
    device tree nodes are present.

Inspired by commit 5553f9e26f6f49a93ba732fd222eac6973a4cf35
(cpufreq: instantiate cpufreq-cpu0 as a platform_driver)

[nm@ti.com: in addition backport from Rafael's linux-next (for 3.10)
http://git.kernel.org/cgit/linux/kernel/git/rafael/linux-pm.git/commit/?id=49ded525d4486dc97fc965858bf3ddf245463670]

[robherring2@gmail.com: reported conflict of omap-cpufreq vs other
driver in an non-device tree supported boot]
Reported-by: Rob Herring <robherring2@gmail.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Kevin Hilman <khilman@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

cpufreq: instantiate cpufreq-cpu0 as a platform_driver(backport)

As multiplatform build is being adopted by more and more ARM platforms,
initcall function should be used very carefully.  For example, when
GENERIC_CPUFREQ_CPU0 is built in the kernel, cpu0_cpufreq_driver_init()
will be called on all the platforms to initialize cpufreq-cpu0 driver.

To eliminate this undesired the effect, the patch changes cpufreq-cpu0
driver to have it instantiated as a platform_driver.  Then it will only
run on platforms that create the platform_device "cpufreq-cpu0".

Along with the change, it also changes cpu_dev to be &pdev->dev,
so that managed functions can start working, and module build gets
supported too.

The highbank-cpufreq driver is also updated accordingly to adapt the
changes on cpufreq-cpu0.

[nm@ti.com: backport from upstream commit 5553f9e26f6f49a93ba732fd222eac6973a4cf35
dropped highbank changes as part of port (non-ti-platform)]
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Reviewed-by: Viresh Kumar <viresh.kumar@linaro.org>
Acked-by: Mark Langsdorf <mark.langsdorf@calxeda.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

ARM: OMAP3: board-generic: Add missing omap3_init_late(backport)

The .init_late callback for OMAP3 has been missing for DT
builds, which causes a lot of late PM initializations to
be missed in turn.

[nm@ti.com: backport with rebase from upstream commit 990fa4f537092551464a86928c1a056788183101]
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>

ARM: dts: OMAP443x: Add CPU OPP table(backport)

Add DT OPP table for OMAP443x family of devices. This data is
decoded by OF with of_init_opp_table() helper function.

OPP data here is based on existing opp4xxx_data.c

Since the omap4460 OPP tables would be different from OMAP443x,
introduce an new omap443x.dtsi for 443x specific entries and use
existing omap4.dtsi as the common dtsi file for all OMAP4 platforms.

This is in preparation to use generic cpufreq-cpu0 driver for device
tree enabled boot. Legacy non device tree enabled boot continues to
use omap-cpufreq.c and opp4xxx_data.c.

[nm@ti.com: backport from
http://git.kernel.org/cgit/linux/kernel/git/bcousson/linux-omap-dt.git/commit/?h=for_3.10/dts&id=e77049bbf84af59d3793fa5e1cc731013399591e]
Signed-off-by: Nishanth Menon <nm@ti.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Jon Hunter <jon-hunter@ti.com>
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Shawn Guo <shawn.guo@linaro.org>
Cc: Keerthy <j-keerthy@ti.com>
Signed-off-by: Benoit Cousson <benoit.cousson@linaro.org>

ARM: dts: OMAP3: use twl4030 vdd1 regulator for CPU(backport)

Define VDD1 regulator in twl4030 DT and mark it as the supply for the
various OMAP34xx/35xx/36xx/37xx platforms (all use TWL4030 variants with
VDD1 supplying the CPU).

NOTE: This currently will use I2C1 bus communication path to set the
voltage in device tree boot. In the legacy non device tree boot, we
continue to use twl-common.c which bypasses I2C1 bus communication path
and uses I2C4 bus path using OMAP voltage libraries. We should
eventually be able to use I2C4 path once we have voltage regulator for
OMAP which is capable of using the voltage controller/voltage processor
IP blocks.

[nm@ti.com: backport from for_3.10/dts:
http://git.kernel.org/cgit/linux/kernel/git/bcousson/linux-omap-dt.git/commit/?h=for_3.10/dts&id=a134be34065d52cde948f4ab13d0c1f3d4462c40]
Signed-off-by: Nishanth Menon <nm@ti.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Jon Hunter <jon-hunter@ti.com>
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Shawn Guo <shawn.guo@linaro.org>
Cc: Keerthy <j-keerthy@ti.com>
Signed-off-by: Benoit Cousson <benoit.cousson@linaro.org>

ARM: dts: OMAP36xx: Add CPU OPP table(backport)

Add DT OPP table for OMAP36xx/37xx family of devices. This data is
decoded by OF with of_init_opp_table() helper function.

OPP data here is based on existing opp3xxx_data.c

This is in preparation to use generic cpufreq-cpu0 driver for device
tree enabled boot. Legacy non device tree enabled boot continues to
use omap-cpufreq.c and opp3xxx_data.c.

[nm@ti.com: backport from for_3.10/dts
 http://git.kernel.org/cgit/linux/kernel/git/bcousson/linux-omap-dt.git/commit/?h=for_3.10/dts&id=3027e26737adc591fea2d88c2804ffeeb1acdd8c]
Signed-off-by: Nishanth Menon <nm@ti.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Jon Hunter <jon-hunter@ti.com>
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Shawn Guo <shawn.guo@linaro.org>
Cc: Keerthy <j-keerthy@ti.com>
Signed-off-by: Benoit Cousson <benoit.cousson@linaro.org>

ARM: dts: OMAP34xx/35xx: Add CPU OPP table(backport)

Add DT OPP table for OMAP34xx/35xx family of devices. This data is
decoded by OF with of_init_opp_table() helper function.

OPP data here is based on existing opp3xxx_data.c

Since the omap36xx OPP tables would be different from OMAP34xx/35xx,
introduce an new omap34xx.dtsi for 34xx/35xx specific entries and use
existing omap3.dtsi as the common dtsi file for all OMAP3 platforms.

This is in preparation to use generic cpufreq-cpu0 driver for device
tree enabled boot. Legacy non device tree enabled boot continues to
use omap-cpufreq.c and opp3xxx_data.c.

[nm@ti.com: dropped omap3-devkit8000 omap3-igep backport from for_3.10/dts:
http://git.kernel.org/cgit/linux/kernel/git/bcousson/linux-omap-dt.git/commit/?h=for_3.10/dts&id=1e633d713b64872fcdfd7a558480d34e0c8685bd]
Signed-off-by: Nishanth Menon <nm@ti.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Jon Hunter <jon-hunter@ti.com>
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Shawn Guo <shawn.guo@linaro.org>
Cc: Keerthy <j-keerthy@ti.com>
Signed-off-by: Benoit Cousson <benoit.cousson@linaro.org>

ARM: dts: OMAP5: remove regulator info from SoC code

regulator smps123 belongs to Palmas PMIC. the actual PMIC
used is entirely dependent on the board file. So remove
the regulator definitions from OMAP5 SoC generic file
into specific board file

Signed-off-by: Nishanth Menon <nm@ti.com>

ARM: dts: OMAP5: add clock nodes for CPU

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

[nm@ti.com: backport based on https://patchwork.kernel.org/patch/2438921/]
Signed-off-by: Nishanth Menon <nm@ti.com>

ARM: dts: AM33XX: add clock nodes for CPU(v4)

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.

[nm@ti.com: backport from https://patchwork.kernel.org/patch/2438921/]
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: dts: OMAP4: add clock nodes for CPU(v4)

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

[nm@ti.com: backport from https://patchwork.kernel.org/patch/2438971/]
Cc: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>

ARM: dts: OMAP3: add clock nodes for CPU(v4)

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

[nm@ti.com: backport from https://patchwork.kernel.org/patch/2438981/]
Cc: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>

clk: OMAP: introduce device tree binding to kernel clock data(v5.1)

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.

[nm@ti.com: backport from https://patchwork.kernel.org/patch/2442781/]
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>

Merge remote-tracking branch 'rnayak/platform-base-3.8.y' into pm-linux-3.8.y-test

Conflicts:
arch/arm/mach-omap2/omap-mpuss-lowpower.c
arch/arm/mach-omap2/omap_hwmod_33xx_data.c

Signed-off-by: Tero Kristo <t-kristo@ti.com>

Revert "ARM: OMAP5: Enable workaround for 798181"

This reverts commit 7f43c89b6d56b92c83fc290403de624350076fd4.

Enabling workaround for 798181 caused some side affects around
fork testcases (run using ./fork13 -i 1000000) causing a kernel
crash as seen below

[13141.411834] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000004
[13141.411834]
[13141.421630] CPU1: stopping
[13141.424499] [<c001b2e0>] (unwind_backtrace+0x0/0xf0) from [<c0019010>] (handle_IPI+0x130/0x15c)
[13141.433624] [<c0019010>] (handle_IPI+0x130/0x15c) from [<c0008538>] (gic_handle_irq+0x54/0x5c)
[13141.442687] [<c0008538>] (gic_handle_irq+0x54/0x5c) from [<c0557524>] (__irq_svc+0x44/0x5c)
[13141.451446] Exception stack(0xed17be60 to 0xed17bea8)
[13141.456726] be60: 00000001 00000001 00000000 edd02c00 ee800bc0 ee86e480 000000d0 000000d0
[13141.465301] be80: 60000013 c08a69f8 c0127bac c08a6980 00000001 ed17bea8 c0097054 c010a460
[13141.473876] bea0: 20000013 ffffffff
[13141.477539] [<c0557524>] (__irq_svc+0x44/0x5c) from [<c010a460>] (kmem_cache_alloc+0xe8/0x180)
[13141.486572] [<c010a460>] (kmem_cache_alloc+0xe8/0x180) from [<c0127bac>] (dup_fd+0x28/0x350)
[13141.495452] [<c0127bac>] (dup_fd+0x28/0x350) from [<c00452ec>] (copy_process+0x654/0xfd4)
[13141.504028] [<c00452ec>] (copy_process+0x654/0xfd4) from [<c0045ccc>] (do_fork+0x3c/0x2ec)
[13141.512695] [<c0045ccc>] (do_fork+0x3c/0x2ec) from [<c00133a0>] (ret_fast_syscall+0x0/0x3c)
[13141.521484] drm_kms_helper: panic occurred, switching back to text console

Hence revert the commit enabling the WA for now. It needs more testing and
analysis before it can be re-enabled.

Signed-off-by: Rajendra Nayak <rnayak@ti.com>

ARM: dts: omap4-panda: move generic sections to panda-common

PandaBoard, PandaBoard-A4 revisions use OMAP4430.
PandaBoard-ES version of the board uses OMAP4460.

Move the original panda dts file into a common dtsi used by all panda
variants. This allows us to introduce SoC variation for PandaBoard ES
without impacting other PandaBoard versions that are supported.
As part of this change, since OMAP4460 adds on to OMAP4430, add
omap4.dtsi to omap4460.dtsi.

Signed-off-by: Nishanth Menon <nm@ti.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Jon Hunter <jon-hunter@ti.com>
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Shawn Guo <shawn.guo@linaro.org>
Cc: Keerthy <j-keerthy@ti.com>
Signed-off-by: Benoit Cousson <benoit.cousson@linaro.org>
[rnayak: backported from for_3.10/dts headed for upstream]
Signed-off-by: Rajendra Nayak <rnayak@ti.com>

ARM: OMAP5: Source DPLL_ABE from sys_clk

DPLL_ABE gets into transient state when it's sourced from sys_32k,
this is a known (but not root caused) problem, so using sys_clk as
reference clock instead.

Signed-off-by: Misael Lopez Cruz <misael.lopez@ti.com>

ARM: OMAP5: Init DPLL_ABE CLKOUTX2_M2 to 196MHz

DPLL_ABE CLKOUTX2_M2 is expected to be set to 196.608 MHz as per TRM [1].
dpll_abe_ck was already initialized for the same purpose, but its
initialization doesn't guarantee that CLKOUTX2_M2 (dpll_abe_m2x2_ck) will
be at 196.608 MHz, hence m2x2_clk is explicitly initialized.

[1] OMAP543X ES2.0, section "CKGEN_ABE Clock Generator"

Signed-off-by: Misael Lopez Cruz <misael.lopez@ti.com>

ARM: OMAP5: Enable workaround for 798181

798181: On Cortex-A15 (r0p0..r3p2) the TLBI/DSB
        are not adequately shooting down all use
        of the old entries.

Enabling the WA for the same.

Signed-off-by: Sricharan R <r.sricharan@ti.com>

arm: errata: Workaround for Cortex-A15 erratum 798181 (TLBI/DSB operations)

On Cortex-A15 (r0p0..r3p2) the TLBI/DSB are not adequately shooting down
all use of the old entries. This patch implements the erratum workaround
which consists of:

1. Dummy TLBIMVAIS and DSB on the CPU doing the TLBI operation.
2. Send IPI to the CPUs that are running the same mm (and ASID) as the
   one being invalidated (or all the online CPUs for global pages).
3. CPU receiving the IPI executes a DMB and CLREX (part of the exception
   return code already).

The switch_mm() code includes at least one DMB (as required by the
workaround) and the IPI can be sent only to CPUs running the same ASID.

Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>

ARM: DTS: OMAP5-uevm: pull-up Palmas MSECURE line

Palmas MSECURE line must be pulled up, otherwise some of the PMIC
registers will be read-only. This fixes the problem with RTC
not updating properly.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
Cc: Nishanth Menon <nm@ti.com>
Cc: Tom Rini <trini@ti.com>

ARM/dts: omap5-sevm: Enable palmas on i2c1 bus

Patch adds palmas support for sEvm wakeup boards.
This is needed to enable cpufreq on sEvms.

Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Andrii.Tseglytskyi <andrii.tseglytskyi@ti.com>

Merge branch 'platform-base-3.8.y' of https://github.com/hvaibhav/am335x-linux into platform-base-3.8.y

ARM: OMAP2+: omap2plus_defconfig: Enable RTC support

AM33XX family of devices use RTC module, one has to manually enable
this support to use RTC features. So this patch enable RTC driver in
omap2plus_defconfig.

Signed-off-by: AnilKumar Ch <anilkumar@ti.com>
Reviewed-by: Russ Dill <russ.dill@ti.com>
Acked-by: Russ Dill <russ.dill@ti.com>

ARM: dts: AM33XX: Enable system power off control in am335x-bone

Enable system power off control for BeagleBone in am335x-bone.dts file
under rtc node. RTC is the incharge of controlling the system power.
This flag is used by the driver to hook up the pm_power_off system call.

Signed-off-by: AnilKumar Ch <anilkumar@ti.com>
Reviewed-by: Russ Dill <russ.dill@ti.com>
Acked-by: Russ Dill <russ.dill@ti.com>

ARM: dts: AM33XX: Set pmic-shutdown-controller for BeagleBone

Set ti,pmic-shutdown-controller for BeagleBone in am335x-bone.dts
file, this flag is used by the driver to set tps65217 PMIC status
to OFF when PWR_EN toggle.

Signed-off-by: AnilKumar Ch <anilkumar@ti.com>
Reviewed-by: Russ Dill <russ.dill@ti.com>
Acked-by: Russ Dill <russ.dill@ti.com>

rtc: OMAP: Add system pm_power_off to rtc driver

Add system power off control to rtc driver which is the in-charge
of controlling the BeagleBone system power. The power_off routine
can be hooked up to "pm_power_off" system call.

System power off sequence:-
* Set PMIC STATUS_OFF when PMIC_POWER_EN is pulled low
* Enable PMIC_POWER_EN in rtc module
* Set rtc ALARM2 time
* Enable ALARM2 interrupt

Signed-off-by: Colin Foe-Parker <colin.foeparker@logicpd.com>
[anilkumar@ti.com: move poweroff additions to rtc driver]
Signed-off-by: AnilKumar Ch <anilkumar@ti.com>
Reviewed-by: Russ Dill <russ.dill@ti.com>
Acked-by: Russ Dill <russ.dill@ti.com>

ARM: dts: OMAP2+: Identify GPIO banks that are always powered

Add the "ti,gpio-always-on" property to the appropriate GPIO banks to
indicate which banks are always powered and will never lose logic state.

Cc: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: Jon Hunter <jon-hunter@ti.com>

ARM: dts: OMAP4: Fix ethernet IRQ for OMAP4 boards

Commit ff5c9059 (ARM: dts: OMAP3+: Correct gpio #interrupts-cells
property) updated the number of interrupt cells required for configuring
gpios as interrupts for other devices (such as ethernet controllers).
This update allowed the interrupt type (edge, level, etc) to be
configured via device-tree (as described in the
Documentation/devicetree/bindings/gpio/gpio-omap.txt).

This broke ethernet support on the OMAP4 SDP board that defines a gpio
as the ethernet IRQ because the interrupt type (level, edge, etc) was
not getting configured correctly. This board use the ks8851 ethernet
chip which has an active low interrupt. Fix this by defining the gpio
interrupt as active-low in the device-tree binding.

Please note that the OMAP4-VAR-SOM also uses the same ethernet
controller and it is expected it will have the same problem. So the
same fix is also applied to this board.

Signed-off-by: Jon Hunter <jon-hunter@ti.com>

ARM: dts: Add OMAP3430 SDP NOR flash memory binding

Add device-tree node for the 128MB NOR on the OMAP3430-SDP board.

Signed-off-by: Jon Hunter <jon-hunter@ti.com>

ARM: dts: Add NOR flash bindings for OMAP2420 H4

Add device-tree node for the 64MB NOR on the OMAP2420-H4 board.

Signed-off-by: Jon Hunter <jon-hunter@ti.com>