Remove arch/arm/plat-omap/include/plat/clock.h by merging it into
arch/arm/mach-omap1/clock.h and arch/arm/mach-omap2/clock.h.
The goal here is to facilitate ARM single image kernels by removing
includes via the "plat/" symlink.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
[tony@atomide.com: fixed to remove duplicate clock.h includes]
Signed-off-by: NTony Lindgren <tony@atomide.com>

Let's make omap_hwmod local to mach-omap2 for
ARM common zImage support.
Signed-off-by: NTony Lindgren <tony@atomide.com>

Let's make omap_device local to mach-omap2 for
ARM common zImage support.
Signed-off-by: NTony Lindgren <tony@atomide.com>

In case of error, the function omap_device_alloc() returns ERR_PTR()
and never returns NULL pointer. The NULL test in the return value
check should be replaced with IS_ERR().

dpatch engine is used to auto generated this patch.
(https://github.com/weiyj/dpatch)
Signed-off-by: NWei Yongjun <yongjun_wei@trendmicro.com.cn>
Signed-off-by: NKevin Hilman <khilman@ti.com>

This API is meant to be an interface to hwmod assert/deassert
function, omap devices can call them through their platform data to
control their reset lines, they are expected to know the name of the
reset line they are trying to control.
Signed-off-by: NOmar Ramirez Luna <omar.luna@linaro.org>
[paul@pwsan.com: tweaked some documentation; fixed CodingStyle issue]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Moving to Common clk framework for OMAP would mean we no longer use
internal lookup mechanism like omap_clk_get_by_name().
get rid of all its usage mostly from hwmod and omap_device
code.

Moving to clk_get() also means the respective platforms
need the clkdev tables updated with an entry for all clocks
used by hwmod to have clock name same as the alias.

Based on original changes from Mike Turquette.
Signed-off-by: NRajendra Nayak <rnayak@ti.com>
Cc: Russell King - ARM Linux <linux@arm.linux.org.uk>
[paul@pwsan.com: removed IS_ERR_OR_NULL() conversion (rmk comment);
 restricted omap_96m_alwon_fck_3630 to OMAP36xx; added missing AM35xx
 clock aliases for emac_fck, emac_ick, vpfe_ick, vpfe_fck; added
 aliases rng_ick and several emulation clocks]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Under some circumstances, drivers may leave an omap_device enabled due
to driver programming errors, or due to a failure in the drivers
probe method.

Using the recently added omap_device driver_status field, we can
detect conditions where an omap_device is enabled but has no driver
bound and then ensure that the device is properly idled until it can
be probed again.

The goal of this feature is not only to detect and warn on these error
conditions, but also to ensure that devices are properly put in
low-power states so they do not prevent SoC-wide low-power states.
Reviewed-by: NPaul Walmsley <paul@pwsan.com>
Signed-off-by: NKevin Hilman <khilman@ti.com>

Currently, the omap_device PM domain layer uses the late suspend and
early resume callbacks to ensure devices are in their low power
states.

However, this is attempted even in cases where a driver probe has
failed.  If a driver's ->probe() method fails, the driver is likely in
a state where it is not expecting its runtime PM callbacks to be
called, yet currently the omap_device PM domain code attempts to call
the drivers callbacks.

To fix, use the omap_device driver_status field to check whether a
driver is bound to the omap_device before attempting to trigger driver
callbacks.
Reviewed-by: NPaul Walmsley <paul@pwsan.com>
Signed-off-by: NKevin Hilman <khilman@ti.com>

Use the bus notifier to keep track of driver bound status by adding a
new internal field to struct omap_device: _driver_status.

This will be useful for follow-up patches which need to know whether
or not a driver is bound in order to make intelligent omap_device
enable/idle decisions.
Reviewed-by: NPaul Walmsley <paul@pwsan.com>
Signed-off-by: NKevin Hilman <khilman@ti.com>

Find and unwrap wrapped strings in the style:

	pr_debug("clockdomain: hardware cannot set/clear wake up of "
		 "%s when %s wakes up\n", clkdm1->name, clkdm2->name);

Keeping these strings contiguous seems to be the current Linux kernel
policy.

The offending lines were found with the following command:

    pcregrep -rnM '"\s*$\s*"' arch/arm/*omap*

While here, some messages have been clarified, some pr_warning(
... calls have been converted to pr_warn( ..., and some printk(KERN_*
... have been converted to pr_*.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

With the new devices (like, AM33XX and OMAP5) we now only support
DT boot mode of operation and now it is the time to start killing
slowly the dependency on hwmod, so with this patch, we are starting
with device resources.
The idea here is implemented considering to both boot modes -
  - DT boot mode
    OF framework will construct the resource structure (currently
    does for MEM & IRQ resource) and we should respect/use these
    resources, killing hwmod dependency.
    If pdev->num_resources > 0, we assume that MEM & IRQ resources
    have been allocated by OF layer already (through DTB).

    Once DMA resource is available from OF layer, we should
    kill filling any resources from hwmod.

  - Non-DT boot mode
    Here, pdev->num_resources = 0, and we should get all the
    resources from hwmod (following existing steps)
Signed-off-by: NVaibhav Hiremath <hvaibhav@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@ti.com>
[b-cousson@ti.com: Fix some checkpatch CHECK issues]
Signed-off-by: NBenoit Cousson <b-cousson@ti.com>

When booted with some resource will have their name set to NULL. This can
cause later kernel crash since this is not expected by the platform code.

When we boot without DT the devices are created with platform_device_add()
which itself fixes up the missing resource names:
if (r->name == NULL)
	r->name = dev_name(&pdev->dev);

The of core also fixes up the resource names when taking the information
from DT data - in __of_address_to_resource():
r->name = name ? name : dev->full_name;

When we boot OMAP with devicetree: of will create the devices based on the
DT data so the resource names are guarantied to be not NULL. Since we have
the 'ti,hwmod' tag, we remove the of created resources from the device and
re-create them based on hwmod data. If the hwmod data does not specify a
name for a resource it will be NULL.
This can cause kernel crash if the driver uses
platform_get_resource_byname() to get any resource.
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
[b-cousson@ti.com: Change omap_hwmod to omap_device in subject]
Signed-off-by: NBenoit Cousson <b-cousson@ti.com>

Resolve some warnings identified by cppcheck in arch/arm/mach-omap2:

    [arch/arm/mach-omap2/usb-tusb6010.c:129]: (style) Checking if unsigned variable 'tmp' is less than zero.
    [arch/arm/mach-omap2/prm_common.c:241]: (error) Possible null pointer dereference: irq_setup - otherwise it is redundant to check if irq_setup is null at line 247
    [arch/arm/mach-omap2/pm34xx.c:790]: (style) Variable 'per_clkdm' is assigned a value that is never used
    [arch/arm/mach-omap2/pm34xx.c:790]: (style) Variable 'core_clkdm' is assigned a value that is never used
    [arch/arm/mach-omap2/pm24xx.c:185]: (style) Variable 'only_idle' is assigned a value that is never used
    [arch/arm/mach-omap2/mux.c:254]: (error) Possible null pointer dereference: mux
    [arch/arm/mach-omap2/mux.c:258]: (error) Possible null pointer dereference: mux
    [arch/arm/mach-omap2/gpmc-onenand.c:178]: (style) Variable 'tick_ns' is assigned a value that is never used
    [arch/arm/mach-omap2/gpio.c:56]: (error) Possible null pointer dereference: pdata - otherwise it is redundant to check if pdata is null at line 57
    [arch/arm/mach-omap2/devices.c:45]: (style) Variable 'l' is assigned a value that is never used
    [arch/arm/mach-omap2/board-omap3evm.c:641] -> [arch/arm/mach-omap2/board-omap3evm.c:639]: (style) Found duplicate branches for if and else.
    [arch/arm/mach-omap2/am35xx-emac.c:95]: (style) Variable 'regval' is assigned a value that is never used
    [arch/arm/mach-omap2/devices.c:74]: (style) Variable 'l' is assigned a value that is never used
    [arch/arm/mach-omap2/pm34xx.c:277]: (style) Variable 'per_prev_state' is assigned a value that is never used
    [arch/arm/plat-omap/dmtimer.c:352]: (error) Possible null pointer dereference: timer - otherwise it is redundant to check if timer is null at line 354
    [arch/arm/plat-omap/omap_device.c:478]: (style) Variable 'c' is assigned a value that is never used
    [arch/arm/plat-omap/usb.c:42]: (style) Variable 'status' is assigned a value that is never used
    [arch/arm/mach-omap1/clock.c:197]: (style) Variable 'dpll1_rate' is assigned a value that is never used
    [arch/arm/mach-omap1/lcd_dma.c:60]: (style) struct or union member 'lcd_dma_info::size' is never used
    [arch/arm/mach-omap1/pm.c:572]: (style) Variable 'entry' is assigned a value that is never used

Some of them are pretty good catches, such as gpio.c:56 and
usb-tusb6010.c:129.

Thanks to Jarkko Nikula for some comments on the sscanf() warnings.
It seems that the kernel sscanf() ignores the field width anyway for the
%d format, so those changes have been dropped from this second version.

Thanks to Daniel Marjamäki <daniel.marjamaki@gmail.com> for pointing
out that a variable was unnecessarily marked static in the
board-omap3evm.c change.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Felipe Balbi <balbi@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Kevin Hilman <khilman@ti.com>
Cc: Peter Ujfalusi <peter.ujfalusi@ti.com>
Cc: Jarkko Nikula <jarkko.nikula@bitmer.com>
Cc: Charulatha Varadarajan <charu@ti.com>
Cc: Daniel Marjamäki <daniel.marjamaki@gmail.com>
Cc: Tarun Kanti DebBarma <tarun.kanti@ti.com>
Reviewed-by: Charulatha Varadarajan <charu@ti.com> # for gpio.c

ARM: OMAP2+: omap_device: call all suspend, resume callbacks when OMAP_DEVICE_NO_IDLE_ON_SUSPEND is set

During system suspend, when OMAP_DEVICE_NO_IDLE_ON_SUSPEND is set on
an omap_device, call the corresponding driver's ->suspend() and
->suspend_noirq() callbacks (if present).  Similarly, during resume,
the driver's ->resume() and ->resume_noirq() callbacks must both be
called, if present.  (The previous code only called ->suspend_noirq()
and ->resume_noirq().)

If all of these callbacks aren't called, some important driver
suspend/resume code may not get executed.

In current mainline, the bug fixed by this patch is only a problem
under the following conditions:

- the kernel is running on an OMAP4

- an OMAP UART is used as a console

- the kernel command line parameter 'no_console_suspend' is specified

- and the system enters suspend ("echo mem > /sys/power/state").

Under this combined circumstance, the system cannot be awakened via
the serial port after commit be4b0281c
("tty: serial: OMAP: block idle while the UART is transferring data in
PIO mode").  This is because the OMAP UART driver's ->suspend()
callback is never called.  The ->suspend() callback would have called
uart_suspend_port() which in turn would call enable_irq_wake().  Since
enable_irq_wake() isn't called for the UART's IRQ, check_wakeup_irqs()
would mask off the UART IRQ in the GIC.

On v3.3 kernels prior to the above commit, serial resume from suspend
presumably occurred via the PRCM interrupt.  The UART was in
smart-idle mode, so it was able to send a PRCM wakeup which in turn
would be converted into a PRCM interrupt to the GIC, waking up the
kernel.  But after the above commit, when the system is suspended in
the middle of a UART transmit, the UART IP block would be in no-idle
mode.  In no-idle mode, the UART won't generate wakeups to the PRCM
when incoming characters are received; only GIC interrupts.  But since
the UART driver's ->suspend() callback is never called,
uart_suspend_port() and enable_irq_wake() is never called; so the UART
interrupt is masked by check_wakeup_irqs() and the UART can't wake up
the MPU.

The remaining mechanism that could have awakened the system would have
been I/O chain wakeups.  These wouldn't be active because the console
UART's clocks are never disabled when no_console_suspend is used,
preventing the full chip from idling.  Also, current mainline doesn't
yet support full chip idle states for OMAP4, so I/O chain wakeups are
not enabled.

This patch is the result of a collaboration.  John Stultz
<johnstul@us.ibm.com> and Andy Green <andy.green@linaro.org> reported
the serial wakeup problem that led to the discovery of this problem.
Kevin Hilman <khilman@ti.com> narrowed the problem down to the use of
no_console_suspend.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: John Stultz <johnstul@us.ibm.com>
Cc: Andy Green <andy.green@linaro.org>
Reviewed-by: NKevin Hilman <khilman@ti.com>
Signed-off-by: NKevin Hilman <khilman@ti.com>

Currently all omap_devices are forced to have the dummy device
'omap_device_parent' as a parent.  This was used to distinguish
omap_devices from "normal" platform_devices in the OMAP PM core code.

Now that we implement the PM core using PM domains, this is no longer
needed, and is removed.

This also frees up omap_devices to have a more complex parent/child
relationships that model actual device relationships.

The only in-tree user of omap_device_parent was the OMAP PM layer to
handle lost-context count for omap_devices.  That is now converted to
use the presence of the omap_device_pm_domain instead.
Signed-off-by: NKevin Hilman <khilman@ti.com>

Building omap_devices should only be done at init time, and since
omap_device_build() is using early_platform calls which are also
__init, this ensures that omap_device isn't trying to use functions
that disappear.
Signed-off-by: NKevin Hilman <khilman@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Expose omap_device_{alloc, delete, register} so we can use them outside
of omap_device.c.

This approach allows users, which need to manipulate an archdata member
of a device before it is registered, to do so. This is also useful
for users who have their devices created very early so they can be used
at ->reserve() time to reserve CMA memory.

The immediate use case for this is to set the private iommu archdata
member, which binds a device to its associated iommu controller.
This way, generic code will be able to attach omap devices to their
iommus, without calling any omap-specific API.

With this in hand, we can further clean the existing mainline OMAP iommu
driver and its mainline users, and focus on generic IOMMU approaches
for future users (rpmsg/remoteproc and the upcoming generic DMA API).

This patch is still considered an interim solution until DT fully materializes
for omap; at that point, this functionality will be removed as DT will
take care of creating the devices and configuring them correctly.

Tested on OMAP4 with a generic rpmsg/remoteproc that doesn't use any
omap-specific IOMMU API anymore.
Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com>
Signed-off-by: NKevin Hilman <khilman@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

This warning becomes a little bit too verbose with the increase of
device nodes in some DTS files.

Change it to debug only.
Signed-off-by: NBenoit Cousson <b-cousson@ti.com>
Acked-by: NKevin Hilman <khilman@ti.com>

Include linux/export.h to fix below build warning:

  CC      arch/arm/plat-omap/omap_device.o
arch/arm/plat-omap/omap_device.c:1055: warning: data definition has no type or storage class
arch/arm/plat-omap/omap_device.c:1055: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL'
arch/arm/plat-omap/omap_device.c:1055: warning: parameter names (without types) in function declaration
Signed-off-by: NAxel Lin <axel.lin@gmail.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

get_context_loss_count functions return context loss count as u32, and
zero means an error. However, zero is also returned when context has
never been lost and could also be returned when the context loss count
has wrapped and goes to zero.

Change the functions to return an int, with negative value meaning an
error.

OMAP HSMMC code uses omap_pm_get_dev_context_loss_count(), but as the
hsmmc code handles the returned value as an int, with negative value
meaning an error, this patch actually fixes hsmmc code also.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: NKevin Hilman <khilman@ti.com>
Acked-by: NPaul Walmsley <paul@pwsan.com>
[tony@atomide.com: updated to fix a warning with recent dmtimer changes]
Signed-off-by: NTony Lindgren <tony@atomide.com>

Add a notifier called during device_add phase. If an of_node is present,
retrieve the hwmod entry in order to populate properly the omap_device
structure.

For the moment the resource from the device-tree are overloaded.
DT does not support named resource yet, and thus, most driver will not
work without that information.

Add a documentation to capture the specifics OMAP bindings needed for
device-tree support.
Signed-off-by: NBenoit Cousson <b-cousson@ti.com>
Cc: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: NKevin Hilman <khilman@ti.com>

Split the omap_device_build_ss into two smaller functions
that will allow to populate a platform_device already allocated by
device-tree.

The functionality of the omap_device_build_ss is still the same, but
the omap_device_alloc will be usable with devices already built by
device-tree.
Signed-off-by: NBenoit Cousson <b-cousson@ti.com>
Signed-off-by: NKevin Hilman <khilman@ti.com>

Most devices are using the same default omap_device_pm_latency structure
during device built. In order to avoid the duplication of the same
structure everywhere, add a default structure that will be used if
the device does not have an explicit one.

Next patches will clean the duplicated structures.
Signed-off-by: NBenoit Cousson <b-cousson@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Signed-off-by: NKevin Hilman <khilman@ti.com>

An API which translates a standard hwmod name to corresponding
platform_device is useful for drivers when they need to look up the
device associated with a hwmod name to map back into the device
structure pointers. These ideally should be used by drivers in
mach directory. Using a generic hwmod name like "gpu" instead of
the actual device name which could change in the future, allows
us to:
a) Could in effect help replace apis such as omap2_get_mpuss_device,
omap2_get_iva_device, omap2_get_l3_device, omap4_get_dsp_device,
etc..
b) Scale to more devices rather than be restricted to named functions
c) Simplify driver's platform_data from passing additional fields
all doing the same thing with different function pointer names
just for accessing a different device name.
Signed-off-by: NNishanth Menon <nm@ti.com>
[b-cousson@ti.com: Adapt it to the new pdev pointer inside od,
remove the unneeded helpers, and fold the next patch here]
Signed-off-by: NBenoit Cousson <b-cousson@ti.com>
Signed-off-by: NKevin Hilman <khilman@ti.com>

Rather than embedding a struct platform_device inside a struct
omap_device, decouple them, leaving only a pointer to the
platform_device inside the omap_device.

Use the arch-specific data field of the platform_device (pdev_archdata)
to add an omap_device pointer after the platform_device has been created.
Signed-off-by: NKevin Hilman <khilman@ti.com>

The internal device register functions do not need or use any omap_device
internals, so pass in a platform_device pointer instead of an omap_device
pointer.
Signed-off-by: NKevin Hilman <khilman@ti.com>

All of the device init and device driver interaction with omap_device
is done using platform_device pointers.  To make this more explicit,
have omap_device return a platform_device pointer instead of an
omap_device pointer.

All current users of the omap_device pointer were only using it to get
at the platform_device pointer or struct device pointer, so fixing all
of the users was trivial.

This also makes it more difficult for device init code to directly
access members of struct omap_device, and allows for easier changing
of omap_device internals.

Cc: Paul Walmsley <paul@pwsan.com>
Signed-off-by: NKevin Hilman <khilman@ti.com>

The *_device_register() functions and the count/fill resources functions
are internal to omap_device and do not need to be in the header.
Signed-off-by: NKevin Hilman <khilman@ti.com>

During normal system operation warning messages similar to this
are appearing quite often:
omap_device: omap4-keypad.-1: new worst case activate latency 0: 61035

This doesn't seem to be reporting a problem, nor is it very useful for
non-developers, so reduce it to debug level.
Acked-by: NSteve Sakoman <steve@sakoman.com>
Signed-off-by: NGrazvydas Ignotas <notasas@gmail.com>
Signed-off-by: NKevin Hilman <khilman@ti.com>

For consistency in kernel printk output for devices, use dev_dbg(),
dev_warn(), dev_err() instead of pr_debug(), pr_warning() and
pr_err(), some of which currently use direct access of name from
platform_device and others of which use dev_name().  Using the dev_*
versions uses the standard device naming from the driver core.

Some pr_* prints were not converted with this patch since they are
used before the platform_device and struct device are created so
neither the dev_* prints or dev_name() is valid.
Reported-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Reviewed-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NKevin Hilman <khilman@ti.com>

The suspend/resume _noirq handlers were #ifdef'd out in the
!CONFIG_SUSPEND case, but were still assigned to the dev_pm_ops
struct.  Fix by defining them to NULL in the !CONFIG_SUSPEND case.
Reported-by: NArnd Bergmann <arnd@arndb.de>
Acked-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NKevin Hilman <khilman@ti.com>

Commit c03f007a (OMAP: PM:
omap_device: add system PM methods for PM domain handling) mistakenly
used SET_SYSTEM_SLEEP_PM_OPS() when trying to configure custom methods
for the PM domains noirq methods.  Fix that by setting only the
suspend_noirq and resume_noirq methods with custom versions.

Note that all other PM domain methods (including the "normal"
suspend/resume methods) are populated using USE_PLATFORM_PM_SLEEP_OPS,
which configures them all to the default subsystem (platform_bus)
methods.
Reported-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Tested-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: NKevin Hilman <khilman@ti.com>
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>

By default, omap_devices will be automatically idled on suspend
(and re-enabled on resume.)  Using this new API, device init code
can disable this feature if desired.

NOTE: any driver/device that has been runtime PM converted should
      not be using this API.
Signed-off-by: NKevin Hilman <khilman@ti.com>
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>

In the omap_device PM domain callbacks, use omap_device idle/enable to
automatically manage device idle states during system suspend/resume.

If an omap_device has not already been runtime suspended, the
->suspend_noirq() method of the PM domain will use omap_device_idle()
to idle the HW after calling the driver's ->runtime_suspend()
callback.  Similarily, upon resume, if the device was suspended during
->suspend_noirq(), the ->resume_noirq() method of the PM domain will
use omap_device_enable() to enable the HW and then call the driver's
->runtime_resume() callback.

If a device has already been runtime suspended, the noirq methods of
the PM domain leave the device runtime suspended by default.

However, if a driver needs to runtime resume a device during suspend
(for example, to change its wakeup settings), it may do so using
pm_runtime_get* in it's ->suspend() callback.
Signed-off-by: NKevin Hilman <khilman@ti.com>
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>

Only build and use the runtime PM helper functions only when runtime
PM is actually enabled.
Signed-off-by: NKevin Hilman <khilman@ti.com>
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>

Extend the existing function to create clkdev for every optional
clocks to add a well one "fck" alias for the main_clk of the
omap_hwmod.
It will allow to remove these static clkdev entries from the
clockXXX_data.c file.
Signed-off-by: NBenoit Cousson <b-cousson@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@ti.com>
Cc: Todd Poynor <toddpoynor@google.com>
[paul@pwsan.com: remove all of the "fck" role clkdev aliases from the
 clock data files; fixed error message]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

The omap_device layer currently has two ways of getting an omap_device
pointer from a platform_device pointer.

Replace current usage of _find_by_pdev() with to_omap_device() since
to_omap_device() is more familiar to the existing to_platform_device()
used when getting a platform_device pointer from a struct device pointer.

Cc: Felipe Balbi <balbi@ti.com>
Signed-off-by: NKevin Hilman <khilman@ti.com>
Reviewed-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

The naming convention used by commit 7538e3db6e015e890825fbd9f86599b
(PM: Add support for device power domains), which introduced the
struct dev_power_domain type for representing device power domains,
evidently confuses some developers who tend to think that objects
of this type must correspond to "power domains" as defined by
hardware, which is not the case.  Namely, at the kernel level, a
struct dev_power_domain object can represent arbitrary set of devices
that are mutually dependent power management-wise and need not belong
to one hardware power domain.  To avoid that confusion, rename struct
dev_power_domain to struct dev_pm_domain and rename the related
pointers in struct device and struct pm_clk_notifier_block from
pwr_domain to pm_domain.
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Acked-by: NKevin Hilman <khilman@ti.com>

After commit 4d27e9dc (PM: Make power
domain callbacks take precedence over subsystem ones), the power
domain callbacks need to call the driver callbacks instead of relying
on the default subsystem (in this case, platform_bus) to handle the
driver callbacks.

Validated on 3430/n900, 3530/Overo.
Signed-off-by: NKevin Hilman <khilman@ti.com>

In commit 7538e3db (PM: add support
for device power domains) a better way for handling platform-specific
power hooks was introduced.

Rather than using the platform_bus dev_pm_ops overrides
(platform_bus_set_pm_ops()), this patch moves the OMAP runtime PM
implementation over to using device power domains.

Since OMAP is the only user of platform_bus_set_pm_ops(), that
interface can be removed (and will be in a forthcoming patch.)

[rjw: Rebased on top of a previous change modifying the handling of
 power domains by the PM core so that power domain callbacks take
 precendence over subsystem-level PM callbacks.]
Signed-off-by: NKevin Hilman <khilman@ti.com>
Acked-by: NGrant Likely <grant.likely@secretlab.ca>
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>