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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
Enable the static dependency between EMIF and MPU.
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
10 years agoARM: OMAP2+: Powerdomains: Remove the hard requirement to always have a voltdm assoca...
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>
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>
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>
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>
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>
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>
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>
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>
"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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
Add device-tree node for the 64MB NOR on the OMAP2420-H4 board.
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
ARM: dts: Update OMAP3430 SDP NAND and ONENAND properties
The GPMC timing properties for device-tree have been updated by adding
a "-ns" or "-ps" suffix to indicate the units of time the property
represents (as suggested by Rob Herring). Therefore, update the timing
property names for the OMAP3430 SDP NAND and ONENAND devices.
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
The GPMC timing properties for device-tree have been updated by adding
a "-ns" or "-ps" suffix to indicate the units of time the property
represents (as suggested by Rob Herring). Therefore, update the timing
property names for the OMAP3430 SDP NAND and ONENAND devices.
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
ARM: dts: OMAP3: Add support for OMAP3430 SDP board
Adds basic device-tree support for OMAP3430 SDP board which has 256MB
of RAM, 128MB ONENAND flash, 256MB NAND flash and uses the TWL4030
power management IC.
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
Signed-off-by: Benoit Cousson <benoit.cousson@linaro.org>
Adds basic device-tree support for OMAP3430 SDP board which has 256MB
of RAM, 128MB ONENAND flash, 256MB NAND flash and uses the TWL4030
power management IC.
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
Signed-off-by: Benoit Cousson <benoit.cousson@linaro.org>
ARM: dts: OMAP3: Add reg and interrupt properties for gpio
The OMAP3 gpio bindings are currently missing the reg and interrupt
properties and so add these properties.
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
Signed-off-by: Benoit Cousson <benoit.cousson@linaro.org>
The OMAP3 gpio bindings are currently missing the reg and interrupt
properties and so add these properties.
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
Signed-off-by: Benoit Cousson <benoit.cousson@linaro.org>
ARM: dts: OMAP3+: Correct gpio #interrupts-cells property
The OMAP gpio binding documention [1] states that the #interrupts-cells
property for gpio controllers should be 2. Currently, for OMAP3+ devices
the #interrupt-cells is set to 1. By setting this property to 2, it
allows clients to pass a 2nd parameter indicating the sensitivity (level
or edge) and polarity (high or low) of the interrupt. The OMAP gpio
controllers support these options and so update the #interrupt-cells
property for OMAP3+ devices to 2.
[1] Documentation/devicetree/bindings/gpio/gpio-omap.txt
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
Signed-off-by: Benoit Cousson <benoit.cousson@linaro.org>
The OMAP gpio binding documention [1] states that the #interrupts-cells
property for gpio controllers should be 2. Currently, for OMAP3+ devices
the #interrupt-cells is set to 1. By setting this property to 2, it
allows clients to pass a 2nd parameter indicating the sensitivity (level
or edge) and polarity (high or low) of the interrupt. The OMAP gpio
controllers support these options and so update the #interrupt-cells
property for OMAP3+ devices to 2.
[1] Documentation/devicetree/bindings/gpio/gpio-omap.txt
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
Signed-off-by: Benoit Cousson <benoit.cousson@linaro.org>
ARM: dts: Add OMAP2 gpio bindings
Add gpios bindings for OMAP2420 and OMAP2430 devices.
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
Signed-off-by: Benoit Cousson <benoit.cousson@linaro.org>
Add gpios bindings for OMAP2420 and OMAP2430 devices.
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
Signed-off-by: Benoit Cousson <benoit.cousson@linaro.org>
ARM: dts: Add GPMC node for OMAP2, OMAP4 and OMAP5
Add the device-tree node for GPMC on OMAP2, OMAP4 and OMAP5 devices.
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
Signed-off-by: Benoit Cousson <benoit.cousson@linaro.org>
Add the device-tree node for GPMC on OMAP2, OMAP4 and OMAP5 devices.
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
Signed-off-by: Benoit Cousson <benoit.cousson@linaro.org>
ARM: dts: OMAP2+: Add SDMA controller bindings and nodes
Add SDMA controller binding for OMAP2+ devices and populate DMA client
information for SPI and MMC peripheral on OMAP3+ devices. Please note
that OMAP24xx devices do not have SPI and MMC bindings available yet and
so DMA client information is not populated.
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
Reviewed-by: Felipe Balbi <balbi@ti.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Tested-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: Benoit Cousson <benoit.cousson@linaro.org>
Add SDMA controller binding for OMAP2+ devices and populate DMA client
information for SPI and MMC peripheral on OMAP3+ devices. Please note
that OMAP24xx devices do not have SPI and MMC bindings available yet and
so DMA client information is not populated.
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
Reviewed-by: Felipe Balbi <balbi@ti.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Tested-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: Benoit Cousson <benoit.cousson@linaro.org>
ARM: dts: OMAP2+: Add PMU nodes
Add PMU nodes for OMAP2, OMAP3 and OMAP4460 devices.
Please note that the node for OMAP4460 has been placed in a separate
header file for OMAP4460, because the node is not compatible with
OMAP4430. The node for OMAP4430 is not included because PMU is not
currently supported on OMAP4430 due to the absence of a cross-trigger
interface driver.
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
Signed-off-by: Benoit Cousson <benoit.cousson@linaro.org>
Add PMU nodes for OMAP2, OMAP3 and OMAP4460 devices.
Please note that the node for OMAP4460 has been placed in a separate
header file for OMAP4460, because the node is not compatible with
OMAP4430. The node for OMAP4430 is not included because PMU is not
currently supported on OMAP4430 due to the absence of a cross-trigger
interface driver.
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
Signed-off-by: Benoit Cousson <benoit.cousson@linaro.org>
ARM: OMAP2+: Prepare for device-tree PMU support
If device-tree is present, then do not create the PMU device from within
the OMAP specific PMU code. This is required to allow device-tree to
create the PMU device from the PMU device-tree node.
PMU is not currently supported for OMAP4430 (due to a dependency on
having a cross-trigger interface driver) and so ensure that this
indicated on boot with or without device-tree.
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Benoit Cousson <benoit.cousson@linaro.org>
If device-tree is present, then do not create the PMU device from within
the OMAP specific PMU code. This is required to allow device-tree to
create the PMU device from the PMU device-tree node.
PMU is not currently supported for OMAP4430 (due to a dependency on
having a cross-trigger interface driver) and so ensure that this
indicated on boot with or without device-tree.
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Benoit Cousson <benoit.cousson@linaro.org>
ARM: dts: OMAP3: reduce GPMC mapped registers address space
Currently the OMAP General-Purpose Memory Controller (GPMC) device
node maps 16 MB of address space for its hardware registers.
This is because the OMAP Technical Reference Manual says that the
GPMC module register address space size is 16 MB. But in practice
the maximum address offset used by a GPMC register is 0x02d0.
So, there is no need to map such a big address space for GPMC regs.
This change was suggested by Jon Hunter [1].
[1]: https://patchwork.kernel.org/patch/2057111/
Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Acked-by: Jon Hunter <jon-hunter@ti.com>
Signed-off-by: Benoit Cousson <benoit.cousson@linaro.org>
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
Currently the OMAP General-Purpose Memory Controller (GPMC) device
node maps 16 MB of address space for its hardware registers.
This is because the OMAP Technical Reference Manual says that the
GPMC module register address space size is 16 MB. But in practice
the maximum address offset used by a GPMC register is 0x02d0.
So, there is no need to map such a big address space for GPMC regs.
This change was suggested by Jon Hunter [1].
[1]: https://patchwork.kernel.org/patch/2057111/
Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Acked-by: Jon Hunter <jon-hunter@ti.com>
Signed-off-by: Benoit Cousson <benoit.cousson@linaro.org>
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
ARM: dts: OMAP3: Add GPMC controller
Add device-tree support for the GPMC controller on the OMAP3.
Signed-off-by: Florian Vaussard <florian.vaussard@epfl.ch>
Signed-off-by: Benoit Cousson <benoit.cousson@linaro.org>
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
Add device-tree support for the GPMC controller on the OMAP3.
Signed-off-by: Florian Vaussard <florian.vaussard@epfl.ch>
Signed-off-by: Benoit Cousson <benoit.cousson@linaro.org>
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
ARM: OMAP2+: Enable cpufreq-cpu0 Config options for cpufreq
Enable cpufreq-cpu0 Config options.
Signed-off-by: J Keerthy <j-keerthy@ti.com>
[t-kristo@ti.com: changed default governor to ondemand]
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Acked-by: Nishanth Menon <nm@ti.com>
Enable cpufreq-cpu0 Config options.
Signed-off-by: J Keerthy <j-keerthy@ti.com>
[t-kristo@ti.com: changed default governor to ondemand]
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Acked-by: Nishanth Menon <nm@ti.com>
Arm: OMAP5: Clock: Update the dependent clocks based on the MPU frequency
This patch does the changes needed to
scale the MPU DPLL dependent clocks namely: ABE Subsystem bridge and EMIF
DIV MODE.
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
Signed-off-by: Vishwanath BS <vishwanath.bs@ti.com>
Signed-off-by: J Keerthy <j-keerthy@ti.com>
[t-kristo@ti.com: added DM reference for EMIF/ABE DIV tweaks]
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Acked-by: Nishanth Menon <nm@ti.com>
This patch does the changes needed to
scale the MPU DPLL dependent clocks namely: ABE Subsystem bridge and EMIF
DIV MODE.
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
Signed-off-by: Vishwanath BS <vishwanath.bs@ti.com>
Signed-off-by: J Keerthy <j-keerthy@ti.com>
[t-kristo@ti.com: added DM reference for EMIF/ABE DIV tweaks]
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Acked-by: Nishanth Menon <nm@ti.com>
ARM: OMAP5: Cpufreq: Enable Duty Cycle Correction(DCC)
Duty cycle correction needs to be enabled if the MPU is to run
at frequencies beyond 1.4GHz for OMAP5. See the note on OMAP5 TRM
chapter 3.6.3.3.1 "DPLLs Output Clocks Parameters", and also
the "OMAP543x ES2.0 DM Operating Conditions Addendum v0.5"
chapter 2.1 "Micro Processor Unit (MPU)".
Signed-off-by: Andrii.Tseglytskyi <andrii.tseglytskyi@ti.com>
Signed-off-by: Taras Kondratiuk <taras@ti.com>
Signed-off-by: J Keerthy <j-keerthy@ti.com>
Acked-by: Nishanth Menon <nm@ti.com>
[t-kristo@ti.com: added TRM / DM references for DCC clock rate]
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Duty cycle correction needs to be enabled if the MPU is to run
at frequencies beyond 1.4GHz for OMAP5. See the note on OMAP5 TRM
chapter 3.6.3.3.1 "DPLLs Output Clocks Parameters", and also
the "OMAP543x ES2.0 DM Operating Conditions Addendum v0.5"
chapter 2.1 "Micro Processor Unit (MPU)".
Signed-off-by: Andrii.Tseglytskyi <andrii.tseglytskyi@ti.com>
Signed-off-by: Taras Kondratiuk <taras@ti.com>
Signed-off-by: J Keerthy <j-keerthy@ti.com>
Acked-by: Nishanth Menon <nm@ti.com>
[t-kristo@ti.com: added TRM / DM references for DCC clock rate]
Signed-off-by: Tero Kristo <t-kristo@ti.com>