tiler:tiler-omap5.git
5 years agoARM: omap5: clock: add dsp functional clock data
Subramaniam C.A [Wed, 7 Mar 2012 17:02:18 +0000 (11:02 -0600)]
ARM: omap5: clock: add dsp functional clock data

This patch adds the dsp functional clock data structure
to the omap5 clock data module.

Signed-off-by: Subramaniam C.A <subramaniam.ca@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
5 years agorpmsg: omx: use different device id for each rproc in id_table
Juan Gutierrez [Mon, 5 Sep 2011 16:47:30 +0000 (11:47 -0500)]
rpmsg: omx: use different device id for each rproc in id_table

Device id is the same for all remote processors currently, so
there is no way to know which remote proc is being registered
every time an rpmsg-omx channel is created. The devices being
created are simply created using an incremental minor number
in the boot/service registration order.

Userspace is assuming that the second cdev registered is always
for ipu_c1 (/dev/rpmsg-omx1 is used for omx video). This remains
true if ipu is the only remote processor present. ipu_c1 always
gets created second today due to the boot-up sequence of the
ipu cores and the images they are executing, but this may not
be valid always.

When dsp is being used, the dsp boot is quicker and usually
publishes the OMX service first (and creates the cdev as
rpmsg-omx0), then the ipu cores gets registered (as rpmsg-omx1
and rpmsg-omx2 respecitvely). This breaks the whole multimedia
use-cases, since the application is talking to an incorrect
remote processor.

The device id table is updated to match specific names to
specific processors, so that they always remain the same
irrespective of the boot sequence.
 "rpmsg-omx0"    ipu_c0
 "rpmsg-omx1"    ipu_c1
 "rpmsg-omx2"    dsp

Signed-off-by: Juan Gutierrez <jgutierrez@ti.com>
5 years agoMerge branch 'omap5_platform_base_v3.1_pm' of git://gitorious.org/~kristo/omap-pm...
Subramaniam C.A [Thu, 22 Mar 2012 20:21:10 +0000 (15:21 -0500)]
Merge branch 'omap5_platform_base_v3.1_pm' of git://gitorious.org/~kristo/omap-pm/omap-pm-work into omap5_platform_base_v3.1-pm-rpmsg

* 'omap5_platform_base_v3.1_pm' of git://gitorious.org/~kristo/omap-pm/omap-pm-work: (43 commits)
  mmc: set constraint to prevent mmc ip clock switch
  OMAP5 defconfig: Enable MUX framework
  Revert "TEMP: omap4+: fix iochain arming logic"
  Revert "TEMP: omap5: serial: enable wakeup for uart3_rx_irrx pad"
  omap3+: mux: uart3: rename uart3 pin name
  ARM: OMAP2+ mux-hack: Correct the _omap_mux_init_gpio API.
  ARM: OMAP5: board: Initialise the mux framework with omap5 evm board data.
  ARM: OMAP5: mux: Add the pin mux data for OMAP5 SOC.
  omap_hwmod: Allow io_ring wakeup configuration for all modules.
  omap-sar: usb_ehci: use hwmod api's for clock management
  clocks: usb: Remove host/tll clocks.
  OMAP5 Defconfig: Enable Palmas Power Button in PM Defconfig
  Palmas: Fix wrong error check
  OMAP5 Defconfig: Enable Palmas features in PM Defconfig
  OMAP5 Defconfig: Enable cpufreq and thermal in pmdefconfig
  Palmas: make sys_nirq wakeup capable
  OMAP2PLUS: DVFS: DVFS Control via CPUFREQ
  mfd: OMAP4plus: SCM : Fixed context restoration of OMAP temp sensor
  oma4plus: temperature sensor: Reduce the bgap counter to 250ms
  Change the time for Long press Key from 12S to 6S
  ...

Conflicts:
arch/arm/mach-omap2/opp5xxx_data.c

Change-Id: I88a026602a4461904719442c652d59a50ea83112
Signed-off-by: Subramaniam C.A <subramaniam.ca@ti.com>
5 years agommc: set constraint to prevent mmc ip clock switch
Balaji T K [Wed, 14 Mar 2012 15:19:04 +0000 (20:49 +0530)]
mmc: set constraint to prevent mmc ip clock switch

When MMC transaction is active, switching ip clock when OPP changes
results in increasing or decreasing clock frequency to the card
beyond the card supported frequency.
Set constraint to prevent IP clock switch between 96MHz and 192MHz

Signed-off-by: Balaji T K <balajitk@ti.com>
5 years agoOMAP5 defconfig: Enable MUX framework
Vishwanath BS [Fri, 16 Mar 2012 11:22:04 +0000 (16:52 +0530)]
OMAP5 defconfig: Enable MUX framework

Enable OMAP5 MUX framework in OMAP5 PM defconfig.

Signed-off-by: Vishwanath BS <vishwanath.bs@ti.com>
5 years agoRevert "TEMP: omap4+: fix iochain arming logic"
Vishwanath BS [Fri, 16 Mar 2012 11:20:18 +0000 (16:50 +0530)]
Revert "TEMP: omap4+: fix iochain arming logic"

This reverts commit 4beb404eaf205f1a886d1f002e74c2d216ae568f.

5 years agoRevert "TEMP: omap5: serial: enable wakeup for uart3_rx_irrx pad"
Vishwanath BS [Fri, 16 Mar 2012 11:20:09 +0000 (16:50 +0530)]
Revert "TEMP: omap5: serial: enable wakeup for uart3_rx_irrx pad"

This reverts commit 5b1109eb71aa2479f4061337abf3d3b219d936ad.

5 years agoomap3+: mux: uart3: rename uart3 pin name
Govindraj.R [Wed, 7 Mar 2012 09:53:35 +0000 (15:23 +0530)]
omap3+: mux: uart3: rename uart3 pin name

Correct the uart3 rx pin name.
On omap5 mux data generated uart3_rx pin which
can be used as irda_pin is named as uart3_rts_irsd
which seem to be the right rx pin name.

Correct the uart3 rx pin name in all other places for omap3/4
so that the default pad table available in serial.c can be
used across socs.

Reviewed-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Govindraj.R <govindraj.raja@ti.com>
5 years agoARM: OMAP2+ mux-hack: Correct the _omap_mux_init_gpio API.
R Sricharan [Mon, 27 Feb 2012 12:27:14 +0000 (17:57 +0530)]
ARM: OMAP2+ mux-hack: Correct the _omap_mux_init_gpio API.

The API always assumes that GPIO pins would be present only
in mode3 or mode4. But this is not true, they can be in any mux mode.
Just adding mode6 in to the API for OMAP5 now. But this has to
be corrected in a proper way to ensure that it is compatible for
all OMAP socs in general.

Signed-off-by: R Sricharan <r.sricharan@ti.com>
5 years agoARM: OMAP5: board: Initialise the mux framework with omap5 evm board data.
R Sricharan [Fri, 16 Mar 2012 10:25:00 +0000 (15:55 +0530)]
ARM: OMAP5: board: Initialise the mux framework with omap5 evm board data.

Signed-off-by: R Sricharan <r.sricharan@ti.com>
5 years agoARM: OMAP5: mux: Add the pin mux data for OMAP5 SOC.
R Sricharan [Mon, 27 Feb 2012 12:44:38 +0000 (18:14 +0530)]
ARM: OMAP5: mux: Add the pin mux data for OMAP5 SOC.

Signed-off-by: R Sricharan <r.sricharan@ti.com>
5 years agoomap_hwmod: Allow io_ring wakeup configuration for all modules.
Govindraj.R [Wed, 7 Mar 2012 11:44:02 +0000 (17:14 +0530)]
omap_hwmod: Allow io_ring wakeup configuration for all modules.

Some modules doesn't have SYSC_HAS_ENAWAKEUP bit available
(ex: usb host uhh module) in absence of this flag
omap_hwmod_enable/disable_wakeup avoids configuring
pad mux wakeup capability.

Configure sysc if SYSC_HAS_ENAWAKEUP is available and for other cases
try enabling/disabling wakeup from mux_pad pins.

Cc: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@ti.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Signed-off-by: Govindraj.R <govindraj.raja@ti.com>
5 years agoomap-sar: usb_ehci: use hwmod api's for clock management
Govindraj.R [Thu, 23 Feb 2012 12:57:40 +0000 (18:27 +0530)]
omap-sar: usb_ehci: use hwmod api's for clock management

uhh and tll clocks are managed using hwmod framework
avoid using clock api's for enabling the uhh/tll module

clocks are enabled using module mode bits from hwmod data
and enabled using enable_module api.
Expand omap_hwmod_enable/disable_clocks to utilise these
api's

Signed-off-by: Govindraj.R <govindraj.raja@ti.com>
5 years agoclocks: usb: Remove host/tll clocks.
Govindraj.R [Wed, 22 Feb 2012 14:49:24 +0000 (20:19 +0530)]
clocks: usb: Remove host/tll clocks.

Host/tll clocks are managed from hwmod framework,
remove the host/tll clock management from clock
framework else, reset unsed clocks will gate it.
As hwmod manages these module bits without calling
clock api's.

Signed-off-by: Govindraj.R <govindraj.raja@ti.com>
5 years agoomap5: remoteproc: adjust rproc data for increased ducati heap
Suman Anna [Fri, 10 Feb 2012 18:44:22 +0000 (12:44 -0600)]
omap5: remoteproc: adjust rproc data for increased ducati heap

The Ducati Core1 heap has been increased by 60MB on OMAP5 to support
a 14MB Camera ZSL use-case. The suspend addresses for both Ducati and
Tesla has been adjusted accordingly for OMAP5.

Signed-off-by: Suman Anna <s-anna@ti.com>
5 years agoomap5: sevm: increase ducati carveout by 60MB
Suman Anna [Fri, 10 Feb 2012 21:33:59 +0000 (15:33 -0600)]
omap5: sevm: increase ducati carveout by 60MB

The ducati carveout has been increased by 60MB to enable
the ZSL usecase for a 14MP Camera. All the other carveout
addresses have to be readjusted accordingly.

Signed-off-by: Suman Anna <s-anna@ti.com>
5 years agoARM: omap4: hwmod: add clocks to dsp processor device
Suman Anna [Tue, 6 Mar 2012 18:20:18 +0000 (12:20 -0600)]
ARM: omap4: hwmod: add clocks to dsp processor device

The dsp processor hwmod device (dsp_c0) is defined primarily as
a pseudo-hwmod device with only reset control. This shares the
same functional clock along with the dsp hwmod device that is
mainly used for controlling the MMU. This clock name is added to
this pseudo-hwmod device, as it enables the power domain lookup.
This is required to be able to put any latency constraints on
the dsp using the dev_pm_qos_update_request api.

There is no major effect on the clock framework itself due to
this change, as the clock enable & disable will simply be
reference counted and the functionality would be identical as
before.

Signed-off-by: Suman Anna <s-anna@ti.com>
5 years agoOMAP5: OPP: correct hwmod name for dsp in opp_def_list
Suman Anna [Tue, 6 Mar 2012 23:23:17 +0000 (17:23 -0600)]
OMAP5: OPP: correct hwmod name for dsp in opp_def_list

Replace "dsp" with "dsp_c0" in the opp definition list.

The "dsp" name refers to the dsp's iommu hwmod, and not to the
dsp core itself (iommu is not opp-scalable).

"dsp_c0" is the correct hwmod name that should be used in
the OPP definitions list.

Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Juan Gutierrez <jgutierrez@ti.com>
Signed-off-by: Subramaniam C.A <subramaniam.ca@ti.com>
5 years agoOMAP4: OPP: enable dsp in opp_def_list
Suman Anna [Tue, 6 Mar 2012 23:09:54 +0000 (17:09 -0600)]
OMAP4: OPP: enable dsp in opp_def_list

DSP is enabled in the OPP definition list for OMAP4. The hwmod
name in the opp table has been changed from "dsp" to "dsp_c0".

The "dsp" name refers to the dsp's iommu hwmod, and not to the
dsp core itself (iommu is not opp-scalable).

"dsp_c0" is the correct hwmod name that should be used in
the OPP definitions list.

Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Juan Gutierrez <jgutierrez@ti.com>
Signed-off-by: Subramaniam C.A <subramaniam.ca@ti.com>
5 years agorpmsg: resmgr: support setting constraints on dsp
Juan Gutierrez [Sat, 25 Feb 2012 02:38:29 +0000 (20:38 -0600)]
rpmsg: resmgr: support setting constraints on dsp

Add support to set constraints on the DSP processor.

Signed-off-by: Juan Gutierrez <jgutierrez@ti.com>
5 years agoomap: remoteproc: add watchdog timer support for dsp
Juan Gutierrez [Thu, 1 Mar 2012 18:09:32 +0000 (12:09 -0600)]
omap: remoteproc: add watchdog timer support for dsp

Use GPTimer 6 as the watchdog timer for dsp. This is used
specifically instead of the WDT3, as the latter is not
capable of generating an interrupt to the DSP core. The
former is used to generate an interrupt and thereby
gather some watchdog context data.

Signed-off-by: Juan Gutierrez <jgutierrez@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
5 years agoomap: remoteproc: use device-specific dump-register ops
Juan Gutierrez [Thu, 1 Mar 2012 18:07:17 +0000 (12:07 -0600)]
omap: remoteproc: use device-specific dump-register ops

The current omap register dump function is catering only to
ARM cores. Introduce device-specific dump register functions
so that the omap remoteproc code can call into them based on
the processor type.

This patch also adds a minimal support for dumping dsp
registers in addition to moving the existing functionality
for ARM cores to the device-specific function.

Signed-off-by: Juan Gutierrez <jgutierrez@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
5 years agoremoteproc: enable core dump and halt-on-crash for dsp
Juan Gutierrez [Wed, 29 Feb 2012 23:17:29 +0000 (17:17 -0600)]
remoteproc: enable core dump and halt-on-crash for dsp

Support for halt-on-crash feature is enabled for dsp. The
generation of code dump file is also enabled for dsp. DSP
memory can be pulled from following file for offline
analysis:
/d/remoteproc/omap-rproc.0/core

Currently dsp registers are not saved. The DSP IO buffer
area is skipped as per core-dump design.

Signed-off-by: Juan Gutierrez <jgutierrez@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
5 years agoremoteproc: ignore static pool check for dsp IO buffers
Suman Anna [Thu, 1 Mar 2012 05:06:30 +0000 (23:06 -0600)]
remoteproc: ignore static pool check for dsp IO buffers

The dsp remoteproc is using the same pool of 1D buffer
region as the ducati. This cannot be configured in the
static pool of dsp as this memory region is co-located
only with ducati memory, but not dsp. So, ignore the
valid memory check to proceed with the loading & booting
for dsp.

Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Jesse Villarreal <jesse.villarreal@ti.com>
Signed-off-by: Juan Gutierrez <jgutierrez@ti.com>
5 years agoomap: rpmsg: add dsp as a virtio rproc device
Juan Gutierrez [Thu, 23 Feb 2012 23:37:31 +0000 (17:37 -0600)]
omap: rpmsg: add dsp as a virtio rproc device

Add a dsp virtio rproc device to the omap_rpmsg_vproc
array, so that the corresponding virtio device can be
created and registered with the virtio bus.

The device is included only if the dsp remote rproc
is enabled.

Signed-off-by: Juan Gutierrez <jgutierrez@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
5 years agoomap: remoteproc: add support for dsp
Juan Gutierrez [Thu, 23 Feb 2012 22:47:58 +0000 (16:47 -0600)]
omap: remoteproc: add support for dsp

Add the necessary rproc data for dsp for proper functionality
including power management.

The logic for getting the memory pool information has also
been updated to work for dsp.

Signed-off-by: Juan Gutierrez <jgutierrez@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
5 years agoomap5: configs: zero out remoteproc dynamic carveout (dsp)
Suman Anna [Wed, 7 Mar 2012 02:36:11 +0000 (20:36 -0600)]
omap5: configs: zero out remoteproc dynamic carveout (dsp)

The dsp text & ipc sections have been programmed to use static
carveout currently, so there is no need to set-aside the dynamic
carveout memory for the same.

Signed-off-by: Juan Gutierrez <jgutierrez@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Subramaniam C.A <subramaniam.ca@ti.com>
5 years agoomap5: evm: reserve memory for dsp
Subramaniam C.A [Wed, 7 Mar 2012 02:23:57 +0000 (20:23 -0600)]
omap5: evm: reserve memory for dsp

DSP is configured to use 4 MB of memory. Memory for DSP is
reserved during board initialization. The memory is just
below the reserved memory for all ION heaps. This memory is
reserved at boot-time using the memblock API and it is
reserved only if CONFIG_REMOTE_PROC_DSP is enabled.

Signed-off-by: Juan Gutierrez <jgutierrez@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Subramaniam C.A <subramaniam.ca@ti.com>
5 years agoomap4: sdp/panda: reserve memory for dsp
Juan Gutierrez [Fri, 19 Aug 2011 17:04:55 +0000 (12:04 -0500)]
omap4: sdp/panda: reserve memory for dsp

DSP is configured to use 4 MB of memory. Memory for DSP is
reserved during board initialization. The memory is just
below the reserved memory for all ION heaps. This memory is
reserved at boot-time using the memblock API and it is
reserved only if CONFIG_REMOTE_PROC_DSP is enabled.

Signed-off-by: Juan Gutierrez <jgutierrez@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Subramaniam C.A <subramaniam.ca@ti.com>
5 years agoomap: add dsp carveout for remoteproc functionality
Juan Gutierrez [Fri, 24 Feb 2012 17:33:58 +0000 (11:33 -0600)]
omap: add dsp carveout for remoteproc functionality

remoteproc uses DDR carveout memories for the functionality
of different rproc instances. New interfaces have been added
to perform this carveout memory during board initialization
for DSP. This patch reserves two types of carveout memory -
one whose address is dynamic, and another that leverages a
fixed static range. The dynamic pool will be used for
allocating memory for firmware sections that have no physical
memory allocated. The static pool will be used to validate the
firmware sections with fixed physical addresses.

This patch also assigns addresses for the Virtio vring buffers
for DSP. This is previously not handled, and the buffers are
currently assigned from the static pool associated with the
dsp. The rpmsg bus initialization sequence is enhanced to
process all the vprocs even if an earlier one in the list
fails due to memory requirements.

Signed-off-by: Juan Gutierrez <jgutierrez@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
5 years agoomap: add ipu and dsp as configurable remoteproc instances
Juan Gutierrez [Fri, 24 Feb 2012 17:20:19 +0000 (11:20 -0600)]
omap: add ipu and dsp as configurable remoteproc instances

OMAP4 and OMAP5 both support two remoteproc instances - ipu &
dsp. The CONFIG_OMAP_REMOTE_PROC menuconfig option enabled
support for all OMAP remoteproc instances, but there was no
choice to enable/disable a specific remoteproc instance.

This patch adds two additional dependent config options for
finer control over these remoteproc instances. The option
CONFIG_OMAP_REMOTE_PROC will continue to be the generic
option for enabling remoteproc driver support for OMAP.

Signed-off-by: Juan Gutierrez <jgutierrez@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Subramaniam C.A <subramaniam.ca@ti.com>
5 years agoomap: remoteproc: add support for a boot register
Juan Gutierrez [Fri, 19 Aug 2011 17:33:21 +0000 (12:33 -0500)]
omap: remoteproc: add support for a boot register

Some remote processors (like DSP) need to explicitly configure
a boot address in a special register or memory location, and
this is the address from which they start executing code when
taken out of reset.

Support for this infrastructure has been added to remoteproc
code. The memory or register address where the boot address
is to be stored is supplied through the boot_reg field of the
platform data in the remoteproc. The omap_rproc_start function
will fetch the boot address from the image, and write this
address into the boot register, if provided, before taking the
processor out of reset.

Signed-off-by: Juan Gutierrez <jgutierrez@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
5 years agoomap: remoteproc: fix return value for latency constraints function
Suman Anna [Fri, 2 Mar 2012 03:20:21 +0000 (21:20 -0600)]
omap: remoteproc: fix return value for latency constraints function

The omap_rproc_set_lat function is not returning the actual status
of the dev_pm_qos_update_request() function call. This patch fixes
the same.

Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Subramaniam C.A <subramaniam.ca@ti.com>
5 years agoomap: mailbox: enable mailbox irq per instance
Juan Gutierrez [Fri, 19 Aug 2011 20:38:23 +0000 (15:38 -0500)]
omap: mailbox: enable mailbox irq per instance

The machine-specific omap2_mbox_startup is called only once
to initialize the whole mbox module. Enabling mbox irq at
startup is only enabling the irq of the very first mailbox
instance created.

The enable_irq function should be called every time a
new mbox instance is created, in the generic platform
mailbox layer.

Signed-off-by: Juan Gutierrez <jgutierrez@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
5 years agoremoteproc: remove pa hardcoding of IPU_MEM_IOBUFS
Subramaniam C.A [Fri, 24 Feb 2012 23:52:00 +0000 (17:52 -0600)]
remoteproc: remove pa hardcoding of IPU_MEM_IOBUFS

While adding a mem entry, we currently check the pa of
IPU_MEM_IOBUFS and mark the entry not to be considered
during core dump. The pa hardcoding is removed in this
patch and we use the resource name instead, to make it
independent of the address location of this section.

Change-Id: I05f2d157f5eedac5ec540c1d4b03de0a60084fc3
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Subramaniam C.A <subramaniam.ca@ti.com>
5 years agorpmsg: omx: use rproc api for pa to da conversion
Subramaniam C.A [Fri, 10 Feb 2012 00:11:15 +0000 (18:11 -0600)]
rpmsg: omx: use rproc api for pa to da conversion

This patch adds the capability to query the remote proc memory
map to perform pa to da conversions in the rpmsg omx driver.
This removes the hard-coded table lookup for translating buffer
addresses.

Change-Id: I116e0983db493f7184796bce416cb45f99c86dd5
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Subramaniam C.A <subramaniam.ca@ti.com>
Signed-off-by: Fernando Guzman Lugo <fernando.lugo@ti.com>
5 years agorpmsg: store rproc reference during virtio device creation
Subramaniam C.A [Fri, 24 Feb 2012 23:46:11 +0000 (17:46 -0600)]
rpmsg: store rproc reference during virtio device creation

Get and store a reference to the rproc associated with the
virtio device. This can later be used by rpmsg drivers to
exercise rproc API (for eg: rproc_da_to_pa).

An API is provided to get this reference from a given rpmsg
channel device.

Change-Id: Ieb397a8cbdd9897a09d631f902c37364fa612210
Signed-off-by: Subramaniam C.A <subramaniam.ca@ti.com>
Signed-off-by: Fernando Guzman Lugo <fernando.lugo@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
5 years agoremoteproc: add an api to do pa to da conversion
Subramaniam C.A [Thu, 9 Feb 2012 23:40:13 +0000 (17:40 -0600)]
remoteproc: add an api to do pa to da conversion

Added an api to provide memory translation from a
physical address to a device virtual address.

Change-Id: I476ce1ba8dc53562c500ad069be42b62e69c5ee3
Signed-off-by: Subramaniam C.A <subramaniam.ca@ti.com>
Signed-off-by: Fernando Guzman Lugo <fernando.lugo@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
5 years agoremoteproc: create version debugfs after image is loaded
Subramaniam C.A [Mon, 30 Jan 2012 16:18:26 +0000 (10:18 -0600)]
remoteproc: create version debugfs after image is loaded

This patch ensures that the image version debugfs entry is
created only after the image is loaded. Version info is
not available before the image is loaded.

If the debugfs entry is created before, then it results in
a kernel panic.

Change-Id: I69f6ad33acbc5908a8ffdad96389c5602ada6336
Signed-off-by: Subramaniam C.A <subramaniam.ca@ti.com>
5 years agoremoteproc: fix checkpatch warnings
Subramaniam C.A [Mon, 30 Jan 2012 16:18:26 +0000 (10:18 -0600)]
remoteproc: fix checkpatch warnings

A few checkpatch warnings have crept into remoteproc over time,
and these have been fixed.

Change-Id: Idcbfab5f8b044f4e8b0550eac910e465d1576312
Signed-off-by: Subramaniam C.A <subramaniam.ca@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
5 years agoremoteproc: simplify system suspend flow to use runtime suspend
Miguel Vadillo [Thu, 1 Mar 2012 02:19:48 +0000 (20:19 -0600)]
remoteproc: simplify system suspend flow to use runtime suspend

When a system suspend is invoked, rproc_suspend is calling the
machine specific to send the remoteproc to the desired state.

Then as part of the system suspend flow, the runtime_suspend is
called later and rproc_runtime_suspend is simply returning since
the remoteproc is already in the desired (SUSPENDED) state.

Instead of doing this, just set the force_suspend flag in
rproc_suspend and allow the rproc_runtime_suspend to call the
machine specific api to put the remoteproc in proper state.

This is to honor the existing behaviour of suspend/runtime_suspend,
and simplify the logic between system suspend and runtime_suspend.

Change-Id: I6f5776dc18a84daf7eca40240b7622ae1c9c468c
Signed-off-by: Miguel Vadillo <vadillo@ti.com>
5 years agorpmsg: adapt to mailbox enable/disable functions
Omar Ramirez Luna [Wed, 29 Feb 2012 19:24:05 +0000 (13:24 -0600)]
rpmsg: adapt to mailbox enable/disable functions

Instead of releasing & requesting the mailbox handle on every
power transition, use enable/disable functions to signal the
driver that it is ok to transition and in the process, perform
save & restore the context as well.

Change-Id: I731c5af7f4c10a28fbb052c67e34c9ae4d1b147d
Signed-off-by: Omar Ramirez Luna <omar.ramirez@ti.com>
5 years agoOMAP: mailbox: provide enable/disable functions
Omar Ramirez Luna [Wed, 29 Feb 2012 18:57:37 +0000 (12:57 -0600)]
OMAP: mailbox: provide enable/disable functions

...for devices that will no longer use the mailbox (while
they are sleep) but still maintain a registered device.

Rather than providing a specific mach ops to [get|put]_sync,
it might be better to move the whole pm_runtime to the common
framework, but this should be addressed in subsequent patches.

Change-Id: I8fcce7d7da2de33409179c01cb2e026ca7eda472
Signed-off-by: Omar Ramirez Luna <omar.ramirez@ti.com>
5 years agoOMAP: mailbox: support save/restore context using runtime PM
Omar Ramirez Luna [Wed, 29 Feb 2012 07:32:57 +0000 (01:32 -0600)]
OMAP: mailbox: support save/restore context using runtime PM

Add new runtime_pm functions and use these to save and restore
the context of the mailbox users.

Change-Id: I0ae1908f2793d75bf8ad042242d68c043c68a552
Signed-off-by: Omar Ramirez Luna <omar.ramirez@ti.com>
5 years agoOMAP5 Defconfig: Enable Palmas Power Button in PM Defconfig
Vishwanath BS [Thu, 1 Mar 2012 12:52:02 +0000 (18:22 +0530)]
OMAP5 Defconfig: Enable Palmas Power Button in PM Defconfig

Enable Palmas Power Button feature in PM Defconfig.

Signed-off-by: Vishwanath BS <vishwanath.bs@ti.com>
5 years agoPalmas: Fix wrong error check
Girish S G [Thu, 1 Mar 2012 09:18:45 +0000 (14:48 +0530)]
Palmas: Fix wrong error check

Fix wrong error check. Enable wakeup on irq if the request_irq succeeds.

Signed-off-by: Girish S G <girishsg@ti.com>
5 years agoOMAP5 Defconfig: Enable Palmas features in PM Defconfig
Vishwanath BS [Wed, 29 Feb 2012 13:48:54 +0000 (19:18 +0530)]
OMAP5 Defconfig: Enable Palmas features in PM Defconfig

Enable Palmas features in PM Defconfig.

Signed-off-by: Vishwanath BS <vishwanath.bs@ti.com>
5 years agoOMAP5 Defconfig: Enable cpufreq and thermal in pmdefconfig
Vishwanath BS [Wed, 29 Feb 2012 11:49:55 +0000 (17:19 +0530)]
OMAP5 Defconfig: Enable cpufreq and thermal in pmdefconfig

Enable cpufreq and thermal in pm defconfig so that system is thermal safe
when pm defconfig is used.

Signed-off-by: Vishwanath BS <vishwanath.bs@ti.com>
5 years agoPalmas: make sys_nirq wakeup capable
Girish S G [Mon, 27 Feb 2012 11:59:33 +0000 (17:29 +0530)]
Palmas: make sys_nirq wakeup capable

This patch makes sys_nirq1 wakeup capable which is required for waking up
omap via Palmas events.

Signed-off-by: Vishwanath Sripathy <vishwanath.bs@ti.com>
Signed-off-by: Girish S G <girishsg@ti.com>
5 years agoOMAP2PLUS: DVFS: DVFS Control via CPUFREQ
Vishwanath BS [Wed, 29 Feb 2012 11:19:42 +0000 (16:49 +0530)]
OMAP2PLUS: DVFS: DVFS Control via CPUFREQ

Instead of using seperate config entry for DVFS, use CPUFREQ to enable/disable
DVFS. There is no pointing in having DVFS w/o CPUFREQ and visa versa.

Signed-off-by: Vishwanath BS <vishwanath.bs@ti.com>
5 years agoremoteproc: replace pm_runtime_suspend in rproc suspend
Miguel Vadillo [Thu, 23 Feb 2012 22:05:16 +0000 (16:05 -0600)]
remoteproc: replace pm_runtime_suspend in rproc suspend

Due to changes introduced by 1e2ef05bb8cf851a694d38e9170c89e7ff052741
"PM: Limit race conditions between runtime PM and system sleep (v2)",
it is not possible to call pm_runtime_suspend inside a system suspend
callback.

Due to this, the rproc_suspend is returning an error during system
suspend if ducati is actively being used.

When the suspend is called after rproc hibernation, there is no issue
as the pm_runtime_suspend call is never executed.

Call the machine specific operation to suspend the rproc instead.

Signed-off-by: Miguel Vadillo <vadillo@ti.com>
Signed-off-by: Fernando Guzman Lugo <fernando.lugo@ti.com>
5 years agomfd: OMAP4plus: SCM : Fixed context restoration of OMAP temp sensor
Keerthy [Fri, 24 Feb 2012 04:20:39 +0000 (09:50 +0530)]
mfd: OMAP4plus: SCM : Fixed context restoration of OMAP temp sensor

Spurious thermal alert interrupt is generated when restoring the context
of OMAP temperature sensor driver upon a wake-up from CORE OSWRet/OFF modes.
This spurious interrupt is due to the fact that current SW implementation
restores all HW registers without any specific sequence.
Finally, the thermal alert interrupt handler prints error message because
the temperature reported by the sensor is invalid.

This patch applies a SW sequence taking into the HW constraints to avoid
the generation of cold thermal alert.
HW constraints:
- The HW logic decrements the counter and then starts the temperature
measurement.
- An immediate temperature measurement is possible only if counter is set to
low value.
- The HW logic compares the BGAP_TEMP_SENSOR_DTEMP bitfield with threshold as
soon as the clock is enabled.
- To avoid spurious interrupt, it is mandatory to unmask interrupts (cold
and/or hot) when BGAP_TEMP_SENSOR_DTEMP bitfield is different than 0.

New SW implementation:
1/ If all registers have been reset:
- Force immediate temperature measurement and wait until
BGAP_TEMP_SENSOR_DTEMP bitfield is updated before completing the full context
restoration.
- Ensure that the BGAP_TEMPSOFF bit is not set to 1 during context restoration.
- Complete the context restoration (mask bits and counter).
2/ If registers have not been reset:
- Force immediate temperature measurement and wait until
BGAP_TEMP_SENSOR_DTEMP bitfield is different than 0.

Signed-off-by:Sebastien Sabatier <s-sabatier1@ti.com>
Signed-off-by: Keerthy <j-keerthy@ti.com>
5 years agooma4plus: temperature sensor: Reduce the bgap counter to 250ms
Keerthy [Fri, 24 Feb 2012 04:19:05 +0000 (09:49 +0530)]
oma4plus: temperature sensor: Reduce the bgap counter to 250ms

Reduce the bgap counter to 250ms since updating
the hw counter on the fly might result in unexpected
behavior. Hence keeping the counter constant at 250ms.

Signed-off-by: Keerthy <j-keerthy@ti.com>
5 years agoChange the time for Long press Key from 12S to 6S
J Keerthy [Thu, 23 Feb 2012 04:26:36 +0000 (09:56 +0530)]
Change the time for Long press Key from 12S to 6S

Change the time for Long press Key from 12S to 6S

Signed-off-by: J Keerthy <j-keerthy@ti.com>
5 years agoOMAP5 Defconfig: Enable DVFS by default in PM Defconfig
Vishwanath BS [Thu, 23 Feb 2012 04:32:45 +0000 (10:02 +0530)]
OMAP5 Defconfig: Enable DVFS by default in PM Defconfig

Signed-off-by: Vishwanath BS <vishwanath.bs@ti.com>
5 years agoOMAP2PLUS DVFS: Enable config option to disable DVFS
Vishwanath BS [Wed, 22 Feb 2012 09:40:05 +0000 (15:10 +0530)]
OMAP2PLUS DVFS: Enable config option to disable DVFS

Provide a config option to disable/enable DVFS via menuconfig.
DVFS is disabled by default now till all drivers are DVFS adapted.

Signed-off-by: Vishwanath BS <vishwanath.bs@ti.com>
5 years agoARM: omap5: hwmod: add address space for DSP MMU
Suman Anna [Fri, 17 Feb 2012 07:32:54 +0000 (01:32 -0600)]
ARM: omap5: hwmod: add address space for DSP MMU

This patch adds the hwmod address space for DSP MMU configuration
space for OMAP5.

Signed-off-by: Suman Anna <s-anna@ti.com>
5 years agoomap5: opp: fix fdif clk name in opp tables
Miguel Vadillo [Wed, 15 Feb 2012 22:32:50 +0000 (16:32 -0600)]
omap5: opp: fix fdif clk name in opp tables

OPP table has a wrong name for fdif clock, fixed the same.

Signed-off-by: Miguel Vadillo <vadillo@ti.com>
Acked-by: Vishwanath BS <vishwanath.bs@ti.com>
5 years agoOMAP4: PM: program warm_reset latency
Nishanth Menon [Mon, 13 Feb 2012 13:04:40 +0000 (18:34 +0530)]
OMAP4: PM: program warm_reset latency

    Warm reset could be triggered by normal reboot sequence or with
    various OMAP watchdog timers. Watchdog timers introduce unplanned
    reset sequence which could, in theory occur at any point of time.

    OMAP provides two registers to control the length that reset is
    held low allowing for the voltages and oscillator to reach stable
    state. PRM_RSTTIME::RSTTIME1 which is a default duration which is
    added and PRM_VOLTSETUP_WARMRESET depending on which voltage domains
    are in LP state. Considering watchdog, it is really not practical
    to optimally program PRM_VOLTSETUP_WARMRESET, hence we use the
    worst case latency in the worst case scenario in RSTTIME1.

    From a latency consideration, system restarting from an OFF mode
    would be the worst case for watchdog. Here, we need to consider
    ramping of each voltage domains + Oscillator which could have been
    caught at the worst possible time - at the start of oscillator
    shutdown sequence.

    Since all these information is already available in the
    datastructures maintained by PM framework, it is not necessary for
    board files to provide any further information.

Reported-by: Baek.Kyung-Han <wildtaz.baek@samsung.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
5 years agoOMAP5: PM: VP: recover device with a cold reset
Vishwanath BS [Mon, 13 Feb 2012 10:12:44 +0000 (15:42 +0530)]
OMAP5: PM: VP: recover device with a cold reset

OMAP5 Voltage processor and PRM is reset only with a cold reset.
So we hook the VP's recovery api to cold reset.

Signed-off-by: Vishwanath BS <vishwanath.bs@ti.com>
5 years agoOMAP4: PM: VP: recover device with a cold reset
Nishanth Menon [Mon, 13 Feb 2012 10:06:26 +0000 (15:36 +0530)]
OMAP4: PM: VP: recover device with a cold reset

OMAP4 Voltage processor and PRM is reset only with a cold reset.
So we hook the VP's recovery api to cold reset.

Signed-off-by: Nishanth Menon <nm@ti.com>
5 years agoOMAP3+: PM: VP: provide api for arch specific recovery
Nishanth Menon [Mon, 13 Feb 2012 10:04:42 +0000 (15:34 +0530)]
OMAP3+: PM: VP: provide api for arch specific recovery

Provide hook so that we can attempt to populate a arch specific
recovery mechanism

Signed-off-by: Nishanth Menon <nm@ti.com>
5 years agoOMAP4: PM: provide support for cold reset of device
Nishanth Menon [Mon, 13 Feb 2012 09:58:39 +0000 (15:28 +0530)]
OMAP4: PM: provide support for cold reset of device

OMAP4 has support for cold resetting the device. It is not
recommended to use this as the default behavior, however
certain modules in OMAP have no other mechanism to reset
themselves once certain bad states have been hit.

Signed-off-by: Nishanth Menon <nm@ti.com>
5 years agoOMAP5 OPP: Enable MMC OPP
Vishwanath BS [Fri, 17 Feb 2012 13:33:42 +0000 (19:03 +0530)]
OMAP5 OPP: Enable MMC OPP

MMC OPPs have to be enabled for non pm standalone build.

Signed-off-by: Vishwanath BS <vishwanath.bs@ti.com>
5 years agoOMAP5 Powerdomain: Enable only ON State
Vishwanath BS [Fri, 17 Feb 2012 05:21:20 +0000 (10:51 +0530)]
OMAP5 Powerdomain: Enable only ON State

As Device latency constraints are not yet supported, let's disable low power
states being activated via constrainst framework.
Once latency for each of the low powerstates are profiled, lower power states
will be enabled.

Signed-off-by: Vishwanath BS <vishwanath.bs@ti.com>
5 years agoOMAP5: PALMAS: Defconfig: Enable Palmas power button driver in omap_5430evm_defconfig
Keerthy [Thu, 16 Feb 2012 09:31:21 +0000 (15:01 +0530)]
OMAP5: PALMAS: Defconfig: Enable Palmas power button driver in omap_5430evm_defconfig

Enable Palmas power button driver in omap_5430evm_defconfig

Signed-off-by: Keerthy <j-keerthy@ti.com>
5 years agoINPUT: KEY: Add palmas pwron button
Girish S G [Tue, 7 Feb 2012 12:36:01 +0000 (18:06 +0530)]
INPUT: KEY: Add palmas pwron button

Add Palmas Power button config option in Kconfig.

Change-Id: I10f9d90128a5322432fd5cd54a9e82184a51b681
Signed-off-by: Girish S G <girishsg@ti.com>
Signed-off-by: Keerthy <j-keerthy@ti.com>
5 years agoINPUT: KEY: Add Power button input key event driver
Girish S G [Fri, 3 Feb 2012 14:50:25 +0000 (20:20 +0530)]
INPUT: KEY: Add Power button input key event driver

This patch adds palmas power button as a input event driver. This
will be mapped as power button key in the userland.

Change-Id: Ifedb13322cf1fc8658247fe47eeca423657497b3
Signed-off-by: Girish S G <girishsg@ti.com>
Signed-off-by: Keerthy <j-keerthy@ti.com>
5 years agoMFD: PALMAS: Add pwron resource to palmas
Girish S G [Fri, 3 Feb 2012 14:57:43 +0000 (20:27 +0530)]
MFD: PALMAS: Add pwron resource to palmas

This patch adds power button as a resource to palmas.

Change-Id: I1385fae7fd2c0a7903d8b7c0be72e7d406c50cdf
Signed-off-by: Girish S G <girishsg@ti.com>
Signed-off-by: Keerthy <j-keerthy@ti.com>
5 years agoARM: omap5: hwmod_data: split DSP hwmod into two hwmod devices
Miguel Vadillo [Wed, 15 Feb 2012 16:31:33 +0000 (10:31 -0600)]
ARM: omap5: hwmod_data: split DSP hwmod into two hwmod devices

DSP has two reset lines, one for MMU and another for the core
itself. The MMU reset line needs to be deasserted first so that
it can be programmed before deasserting the core reset. There is
a single hwmod device for DSP currently, and this would not allow
the remoteproc code to program and manage the DSP properly. This
device has therefore been split into two different hwmod devices
to allow independent control of the MMU and the processor core.

Signed-off-by: Miguel Vadillo <vadillo@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
5 years agoARM: omap5: hwmod_data: fix iva flags for proper sl2if setup
Miguel Vadillo [Thu, 16 Feb 2012 01:53:34 +0000 (19:53 -0600)]
ARM: omap5: hwmod_data: fix iva flags for proper sl2if setup

SL2IF is a module within the IVAHD domain, and has no reset
lines of its own. The hwmod setup initialization for SL2IF
requires that the IVA domain be enabled. The HWMOD_INIT_NO_RESET
flag on the iva hwmod keeps the IVA in reset and disabled,
causing the SL2IF to be stuck in transition.

The HWMOD_INIT_NO_IDLE flags are removed from all the IVA
hwmod structures, as when combined with the INIT_NO_RESET
would leave them in an improper hwmod state machine.

The above problems and fixed with the changes made, and also
help in achieving low power states for the device.

Signed-off-by: Miguel Vadillo <vadillo@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
5 years agoARM: omap5: hwmod: remove INIT_NO_IDLE flag for iss
Miguel Vadillo [Wed, 15 Feb 2012 06:06:22 +0000 (00:06 -0600)]
ARM: omap5: hwmod: remove INIT_NO_IDLE flag for iss

The HWMOD_INIT_NO_IDLE flag has been removed from the ISS
hwmod data. With this flag set, the ISS device is being
enabled and is never idled after the _setup step during
hwmod initialization.

This is not idled until the time ISS has been used and go
through a enable/disable sequence. This causes the chip not
to achieve a low power state after bootup.

Signed-off-by: Miguel Vadillo <vadillo@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
5 years agoomap4: hwmod_data: add clock names to iva sequencers
Chandra Sekhar.Anagani [Fri, 17 Feb 2012 05:07:37 +0000 (23:07 -0600)]
omap4: hwmod_data: add clock names to iva sequencers

The IVA sequencer hwmod data for OMAP4 is missing clock names.
This may cause an improper hwmod setup, and would miss out on
the proper reference counting of the modules using the IVA
clock. This has been corrected.

Signed-off-by: Chandra Sekhar.Anagani <chandu@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
5 years agoomap4: hwmod_data: add missing fields for sl2if
Chandra Sekhar.Anagani [Fri, 17 Feb 2012 05:05:39 +0000 (23:05 -0600)]
omap4: hwmod_data: add missing fields for sl2if

The SL2IF hwmod data for OMAP4 is missing the chip version and
the clock domain name fields. The absence of chip name caused
the hwmod to be ignored altogether during registration, and
the lack of the clock domain caused the hwmod setup to fail,
rendering ipu pretty-much non-functional, and may lead to a
boot failure.

This has been corrected.

Signed-off-by: Chandra Sekhar.Anagani <chandu@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
5 years agoomap4: hwmod_data: add missing fields for fdif
Chandra Sekhar.Anagani [Fri, 17 Feb 2012 04:56:44 +0000 (22:56 -0600)]
omap4: hwmod_data: add missing fields for fdif

The FDIF hwmod data for OMAP4 is missing the chip version and
the clock domain name fields. The absence of chip name caused
the hwmod to be ignored altogether during registration, and
the lack of the clock domain caused the hwmod setup to fail,
rendering fdif use-cases non-functional.

This missing data has been added.

Signed-off-by: Chandra Sekhar.Anagani <chandu@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
5 years agoomap4: hwmod_data: add missing clock fields for ipu
Chandra Sekhar.Anagani [Fri, 17 Feb 2012 04:18:26 +0000 (22:18 -0600)]
omap4: hwmod_data: add missing clock fields for ipu

IPU is missing the clock names on the individual processor
pseudo-hwmod data and clock domain on the main ipu hwmod.
Adding the clock names help keep the reference count. The
lack of the clock domain causes the hwmod setup to be
incomplete and may lead to a boot failure.

This data has been added.

Signed-off-by: Chandra Sekhar Anagani <chandu@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
5 years agoOMAP4: PM: correct next state logic for unsuported states.
Nishanth Menon [Wed, 31 Aug 2011 23:50:47 +0000 (16:50 -0700)]
OMAP4: PM: correct next state logic for unsuported states.

Update next state logic to accomodate the following scenarios
where the power domain does not support the requested power state:

a) if this power domain is a parent power domain, we do not intend
for it to go to a lower power state(because we are not targetting it),
select the next higher power state which is supported is returned.

b) However, for all children power domains, we first try to match
with a lower power domain state before attempting a higher state.
This is because a combination of system power states where the
parent PD's state is not in line with expectation can result in
system instabilities.

Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Axel Haslam <axelhaslam@ti.com>
5 years agoOMAP4: PM: dont program to greater LP state on suspend
Nishanth Menon [Mon, 3 Oct 2011 21:42:35 +0000 (16:42 -0500)]
OMAP4: PM: dont program to greater LP state on suspend

OMAP4 TRM chapter "Power domain transitions" clearly indicate
the approved states that each power domain can transition to.
As part of this programming, stepping down is possible to
lower power state, however, step up is required to ON mode.
Enumerating this:
   PWRDM_POWER_ON ->PWRDM_POWER_INACTIVE, PWRDM_POWER_RET, PWRDM_POWER_OFF
   PWRDM_POWER_INACTIVE -> PWRDM_POWER_RET, PWRDM_POWER_OFF
   PWRDM_POWER_RET -> PWRDM_POWER_OFF

   PWRDM_POWER_INACTIVE, PWRDM_POWER_RET, PWRDM_POWER_OFF -> PWRDM_POWER_ON

We currently ignore this transition limitation while programming to
suspend path. This can cause issues if we attempt OSWR/CSWR after
achieving a module level OFF previously (saved_state would be OFF
but achievable state might indicate point to a retention transition)
in such cases, it is better than we dont program the state.

Reported-by: Todd Poynor <toddpoynor@google.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
5 years agoOMAP4: PM: dont restore to greater LP state on resume
Devaraj Rangasamy [Fri, 30 Sep 2011 21:47:56 +0000 (16:47 -0500)]
OMAP4: PM: dont restore to greater LP state on resume

OMAP4 TRM chapter "Power domain transitions" clearly indicate
the approved states that each power domain can transition to.
As part of this programming, stepping down is possible to
lower power state, however, step up is required to ON mode.
Enumerating this:
   PWRDM_POWER_ON ->PWRDM_POWER_INACTIVE, PWRDM_POWER_RET, PWRDM_POWER_OFF
   PWRDM_POWER_INACTIVE -> PWRDM_POWER_RET, PWRDM_POWER_OFF
   PWRDM_POWER_RET -> PWRDM_POWER_OFF

   PWRDM_POWER_INACTIVE, PWRDM_POWER_RET, PWRDM_POWER_OFF -> PWRDM_POWER_ON

Exit condition from suspend does not currently obey the requirement, and allows
transition to last saved state which could have been an intermediate
saved low power state. This is not allowed per PRCM state machine.

This caused issue with DSS power domain attempting to wakeup from Suspend
mode.

Reported by: Baek.Kyung-Han <wildtaz.baek@samsung.com>
[nm@ti.com: improvement of the patch]
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Vinay Amancha <vinaykumar@ti.com>
Signed-off-by: Devaraj Rangasamy <dev@ti.com>
5 years agoOMAP4: PM: Dont write to readonly/reserved powerdomain register on suspend
Nishanth Menon [Sat, 1 Oct 2011 07:23:52 +0000 (02:23 -0500)]
OMAP4: PM: Dont write to readonly/reserved powerdomain register on suspend

Some of the powerst control/logic_st_ctrl registers such as
CAM, EMU, ABE, etc. are reserved registers, we shouldn't be
writing to them in the first place. The ALWAYS_ON power domains
(wakeup, those of core, DSP, MPU), STD_EFUSE are not under
software control, hence for the purposes of this patch, considered as
not modifiable by software.

Signed-off-by: Nishanth Menon <nm@ti.com>
5 years agoOMAP4: PM: Skip resume powerdomain programing if state already achieved
Nishanth Menon [Sat, 1 Oct 2011 07:20:48 +0000 (02:20 -0500)]
OMAP4: PM: Skip resume powerdomain programing if state already achieved

If the state we plan on restoring is precisely the state that the
domain is already at on resume, don't bother to reprogram the domain.

Signed-off-by: Nishanth Menon <nm@ti.com>
5 years agoOMAP4: PM: Honor powerdomain wakeup ON state in resume reprogramming
Nishanth Menon [Sat, 1 Oct 2011 07:16:35 +0000 (02:16 -0500)]
OMAP4: PM: Honor powerdomain wakeup ON state in resume reprogramming

If the power domain state is ON - e.g. wakeup dependency,
don't reprogram the domain back to LP state it entered suspend into.
If the domain wokeup, it should finish it's work
before going back down, let the relevant subsystem deal with it.

Signed-off-by: Nishanth Menon <nm@ti.com>
5 years agoOMAP4: PM: Refactor resume pd programing
Nishanth Menon [Sat, 1 Oct 2011 00:29:21 +0000 (19:29 -0500)]
OMAP4: PM: Refactor resume pd programing

Move the resume power domain programming into it's own
function as a staging for additional logic.

Signed-off-by: Nishanth Menon <nm@ti.com>
5 years agoomap4: pm: remove gic save context for gp chips
Tero Kristo [Fri, 10 Feb 2012 10:43:44 +0000 (12:43 +0200)]
omap4: pm: remove gic save context for gp chips

This is taken care of by the common gic code and is not needed within
wakeupgen.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
5 years agoRevert "omap5: support for gic save context"
Tero Kristo [Fri, 10 Feb 2012 08:57:23 +0000 (10:57 +0200)]
Revert "omap5: support for gic save context"

This reverts commit ee893b5625f4d7210c4a365d552d5e6326f33e21.

Not needed as common gic code takes care of this.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
5 years agoemif: add voltage notification handling
Aneesh V [Tue, 27 Dec 2011 15:19:56 +0000 (20:49 +0530)]
emif: add voltage notification handling

Some of the EMIF settings need to have a safer value when
voltage is ramping. So, add a notifier in EMIF for core
voltage change notifications and take appropriate actions

Signed-off-by: Aneesh V <aneesh@ti.com>
5 years agorpmsg: omx: build rpmsg_omx even if TILER is not selected
Cris Jansson [Fri, 23 Sep 2011 21:41:41 +0000 (16:41 -0500)]
rpmsg: omx: build rpmsg_omx even if TILER is not selected

The OMX driver does not need TILER for basic messaging. The
call to tiler_virt2phys() is moved behind a check for
CONFIG_TI_TILER to break the dependency.  If TILER is not
included in the kernel then only mappings of
RPC_OMX_MAP_INFO_NONE are allowed. Others would return an
error back to userspace.

Signed-off-by: Cris Jansson <cjansson@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
5 years agorpmsg: omx: re-work buffer lookup to support contiguous NV12
Subramaniam C.A [Thu, 19 Jan 2012 02:24:35 +0000 (20:24 -0600)]
rpmsg: omx: re-work buffer lookup to support contiguous NV12

SGX544 requires Y and UV to be contiguous in SGX virtual address space. This
is done by using single FD for two ion handles.

Change-Id: I33ced876905d74e6293a2c32df0612f01a23d13f
Signed-off-by: Hemant Hariyani <hemanthariyani@ti.com>
Signed-off-by: Subramaniam C.A <subramaniam.ca@ti.com>
5 years agorpmsg: omx: add return values to the pa to da convert function
Subramaniam C.A [Wed, 18 Jan 2012 23:45:48 +0000 (17:45 -0600)]
rpmsg: omx: add return values to the pa to da convert function

This patch adds return values to the pa to da conversion function.
This will help in propagation of proper error codes to the calling
functions.

Change-Id: Ie547f7b7e7c51eff4b7998cbd336a61663995708
Signed-off-by: Subramaniam C.A <subramaniam.ca@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
5 years agorpmsg: resmgr: add support for OMAP5 auxclk requests
Suman Anna [Wed, 25 Jan 2012 12:24:01 +0000 (13:24 +0100)]
rpmsg: resmgr: add support for OMAP5 auxclk requests

All aux clocks are derived from CORE or PER dpll post divider(m3x2).
However on OMAP5, there are additional OPT clock controls between the
DPLL post divider and the leaf aux clock. This OPT clock control nodes
merely support enabling or disabling the corresponding clock output.
The aux clock requests in rpmsg resmgr have been adapted to request a
desired rate for a aux clock by accounting for this additional OPT
clock control node.

Signed-off-by: Suman Anna <s-anna@ti.com>
5 years agorpmsg: resmgr: enable camera regulators for omap5
Suman Anna [Tue, 17 Jan 2012 18:55:53 +0000 (19:55 +0100)]
rpmsg: resmgr: enable camera regulators for omap5

Camera requires an additional regulator on OMAP5. Added
the support for requesting this new regulator through rpmsg
resource manager.

The bound check for the regulator id has also been made
robust.

Signed-off-by: Suman Anna <s-anna@ti.com>
5 years agoomap5: evm: add support for camera regulators
Suman Anna [Tue, 17 Jan 2012 13:42:56 +0000 (14:42 +0100)]
omap5: evm: add support for camera regulators

Add support for cam2pwr and cam2csi regulators to enable
camera functionality on the OMAP5 SEVM board.

Signed-off-by: Suman Anna <s-anna@ti.com>
5 years agoARM: omap5: clockdomain: set iss clk domain to SWSUP
Subramaniam C.A [Wed, 4 Jan 2012 21:54:25 +0000 (15:54 -0600)]
ARM: omap5: clockdomain: set iss clk domain to SWSUP

This patch sets the cam/iss clock domain from HW_AUTO to just
SW_SUP. This patch is based on a similar patch done for OMAP4,

"ARM: OMAP: clockdomain: set iss clk domain to just SWSUP"

This is done because CAM domain has no module wake-up dependency
with any other clock domain of the device and the dynamic
dependency from L3_main_2 is always disabled, the domain needs
to be in force wakeup in order to be able to be used or accessed
for configuration.

Also since there is no clock in the domain managed automatically
by the hardware, so there is no need to configure automatic
clock domain transition. SW should keep the SW_WKUP domain
transition as long as a module in the domain is required to
be functional.

Signed-off-by: Subramaniam C.A <subramaniam.ca@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
5 years agoomap5: hwmod: add softreset delay field
Cris Jansson [Tue, 27 Sep 2011 22:03:52 +0000 (17:03 -0500)]
omap5: hwmod: add softreset delay field

This patch accompanies the omap4 softreset delay patch to include omap5.

See "omap: hwmod: add softreset delay field".

Signed-off-by: Cris Jansson <cjansson@ti.com>
5 years agoARM: omap5: hwmod: correct iva hwmod data
Subramaniam C.A [Thu, 2 Feb 2012 02:44:40 +0000 (03:44 +0100)]
ARM: omap5: hwmod: correct iva hwmod data

Corrected the iva hwmod data to have separate hwmod devices
to deal with multiple processors with associated reset
lines.

The iva sequencers do not need a dedicated sysconfig. Hence,
a separate hwmod class is defined for them.

Signed-off-by: Cris Jansson <cjansson@ti.com>
Signed-off-by: Subramaniam C.A <subramaniam.ca@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
5 years agoARM: omap5: hwmod: correct and enable iss
Subramaniam C.A [Thu, 2 Feb 2012 02:41:39 +0000 (03:41 +0100)]
ARM: omap5: hwmod: correct and enable iss

Corrected the iss hwmod data, and enabled it.

Signed-off-by: Cris Jansson <cjansson@ti.com>
Signed-off-by: Subramaniam C.A <subramaniam.ca@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
5 years agoARM: omap5: hwmod: correct ipu hwmod data
Subramaniam C.A [Thu, 2 Feb 2012 02:33:25 +0000 (03:33 +0100)]
ARM: omap5: hwmod: correct ipu hwmod data

Corrected the ipu hwmod data to have the correct
ipu address space, and separate hwmod devices
to deal with multiple processors with associated
reset lines.

Signed-off-by: Cris Jansson <cjansson@ti.com>
Signed-off-by: Subramaniam C.A <subramaniam.ca@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
5 years agoARM: omap5: hwmod: add sl2if hwmod data
Subramaniam C.A [Thu, 2 Feb 2012 02:16:52 +0000 (03:16 +0100)]
ARM: omap5: hwmod: add sl2if hwmod data

Added hwmod data for sl2if.

Signed-off-by: Cris Jansson <cjansson@ti.com>
Signed-off-by: Subramaniam C.A <subramaniam.ca@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
5 years agoARM: omap5: hwmod: add fdif hwmod data
Subramaniam C.A [Thu, 2 Feb 2012 02:00:45 +0000 (03:00 +0100)]
ARM: omap5: hwmod: add fdif hwmod data

Added hwmod data for fdif.

Signed-off-by: Cris Jansson <cjansson@ti.com>
Signed-off-by: Subramaniam C.A <subramaniam.ca@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
5 years agoomap5: clkdata: added clock data for ipu, iva, iss and sl2if
Subramaniam C.A [Wed, 4 Jan 2012 22:04:59 +0000 (16:04 -0600)]
omap5: clkdata: added clock data for ipu, iva, iss and sl2if

This patch adds clock data for ipu, iva, iss and sl2if
Also corrected fdif clock data.

Signed-off-by: Subramaniam C.A <subramaniam.ca@ti.com>