iv/linux
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
c541c15fb5
linux/arch/arm/plat-omap/include/plat/omap_device.h

163 lines
5.1 KiB
C
Raw Normal View History

OMAP2/3/4 core: create omap_device layer The omap_device code provides a mapping of omap_hwmod structures into the platform_device system, and includes some details on external (board-level) integration. This allows drivers to enable, idle, and shutdown on-chip device resources, including clocks, regulators, etc. The resources enabled and idled are dependent on the device's maximum wakeup latency constraint (if present). At the moment, omap_device functions are intended to be called from platform_data function pointers. Ideally in the future these functions will be called from either subarchitecture-specific platform_data activate, deactivate functions, or via an custom bus/device type for OMAP. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-03 21:14:05 +04:00
/*
* omap_device headers
*
* Copyright (C) 2009 Nokia Corporation
* Paul Walmsley
*
* Developed in collaboration with (alphabetical order): Benoit
* Cousson, Kevin Hilman, Tony Lindgren, Rajendra Nayak, Vikram
* Pandita, Sakari Poussa, Anand Sawant, Santosh Shilimkar, Richard
* Woodruff
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation.
*
* Eventually this type of functionality should either be
* a) implemented via arch-specific pointers in platform_device
* or
* b) implemented as a proper omap_bus/omap_device in Linux, no more
* platform_device
*
* omap_device differs from omap_hwmod in that it includes external
* (e.g., board- and system-level) integration details. omap_hwmod
* stores hardware data that is invariant for a given OMAP chip.
*
* To do:
* - GPIO integration
* - regulator integration
*
*/
#ifndef __ARCH_ARM_PLAT_OMAP_INCLUDE_MACH_OMAP_DEVICE_H
#define __ARCH_ARM_PLAT_OMAP_INCLUDE_MACH_OMAP_DEVICE_H
#include <linux/kernel.h>
#include <linux/platform_device.h>
omap: headers: Move remaining headers from include/mach to include/plat Move the remaining headers under plat-omap/include/mach to plat-omap/include/plat. Also search and replace the files using these headers to include using the right path. This was done with: #!/bin/bash mach_dir_old="arch/arm/plat-omap/include/mach" plat_dir_new="arch/arm/plat-omap/include/plat" headers=$(cd $mach_dir_old && ls *.h) omap_dirs="arch/arm/*omap*/ \ drivers/video/omap \ sound/soc/omap" other_files="drivers/leds/leds-ams-delta.c \ drivers/mfd/menelaus.c \ drivers/mfd/twl4030-core.c \ drivers/mtd/nand/ams-delta.c" for header in $headers; do old="#include <mach\/$header" new="#include <plat\/$header" for dir in $omap_dirs; do find $dir -type f -name \*.[chS] | \ xargs sed -i "s/$old/$new/" done find drivers/ -type f -name \*omap*.[chS] | \ xargs sed -i "s/$old/$new/" for file in $other_files; do sed -i "s/$old/$new/" $file done done for header in $(ls $mach_dir_old/*.h); do git mv $header $plat_dir_new/ done Signed-off-by: Tony Lindgren <tony@atomide.com>
2009-10-20 20:40:47 +04:00
#include <plat/omap_hwmod.h>
OMAP2/3/4 core: create omap_device layer The omap_device code provides a mapping of omap_hwmod structures into the platform_device system, and includes some details on external (board-level) integration. This allows drivers to enable, idle, and shutdown on-chip device resources, including clocks, regulators, etc. The resources enabled and idled are dependent on the device's maximum wakeup latency constraint (if present). At the moment, omap_device functions are intended to be called from platform_data function pointers. Ideally in the future these functions will be called from either subarchitecture-specific platform_data activate, deactivate functions, or via an custom bus/device type for OMAP. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-03 21:14:05 +04:00
OMAP: omap_device: make all devices a child of a new parent device In order to help differentiate omap_devices from normal platform_devices, make them all a parent of a new common parent device. Then, in order to determine if a platform_device is also an omap_device, checking the parent is all that is needed. Users of this feature are the runtime PM core for OMAP, where we need to know if a device being passed in is an omap_device or not in order to know whether to call the omap_device API with it. In addition, all omap_devices will now show up under /sys/devices/omap instead of /sys/devices/platform Acked-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2010-08-23 19:10:55 +04:00
extern struct device omap_device_parent;
OMAP2/3/4 core: create omap_device layer The omap_device code provides a mapping of omap_hwmod structures into the platform_device system, and includes some details on external (board-level) integration. This allows drivers to enable, idle, and shutdown on-chip device resources, including clocks, regulators, etc. The resources enabled and idled are dependent on the device's maximum wakeup latency constraint (if present). At the moment, omap_device functions are intended to be called from platform_data function pointers. Ideally in the future these functions will be called from either subarchitecture-specific platform_data activate, deactivate functions, or via an custom bus/device type for OMAP. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-03 21:14:05 +04:00
/* omap_device._state values */
#define OMAP_DEVICE_STATE_UNKNOWN 0
#define OMAP_DEVICE_STATE_ENABLED 1
#define OMAP_DEVICE_STATE_IDLE 2
#define OMAP_DEVICE_STATE_SHUTDOWN 3
OMAP: PM: omap_device: add system PM methods for PM domain handling 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: Kevin Hilman <khilman@ti.com> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-07-13 00:48:19 +04:00
/* omap_device.flags values */
#define OMAP_DEVICE_SUSPENDED BIT(0)
OMAP: PM: omap_device: add API to disable idle on suspend 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: Kevin Hilman <khilman@ti.com> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-07-13 00:48:29 +04:00
#define OMAP_DEVICE_NO_IDLE_ON_SUSPEND BIT(1)
OMAP: PM: omap_device: add system PM methods for PM domain handling 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: Kevin Hilman <khilman@ti.com> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-07-13 00:48:19 +04:00
OMAP2/3/4 core: create omap_device layer The omap_device code provides a mapping of omap_hwmod structures into the platform_device system, and includes some details on external (board-level) integration. This allows drivers to enable, idle, and shutdown on-chip device resources, including clocks, regulators, etc. The resources enabled and idled are dependent on the device's maximum wakeup latency constraint (if present). At the moment, omap_device functions are intended to be called from platform_data function pointers. Ideally in the future these functions will be called from either subarchitecture-specific platform_data activate, deactivate functions, or via an custom bus/device type for OMAP. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-03 21:14:05 +04:00
/**
* struct omap_device - omap_device wrapper for platform_devices
* @pdev: platform_device
* @hwmods: (one .. many per omap_device)
* @hwmods_cnt: ARRAY_SIZE() of @hwmods
* @pm_lats: ptr to an omap_device_pm_latency table
* @pm_lats_cnt: ARRAY_SIZE() of what is passed to @pm_lats
* @pm_lat_level: array index of the last odpl entry executed - -1 if never
OMAP: omap_device: track latency in nanoseconds Rather than having to do a usecs = nsecs / NSECS_PER_USEC to track latency in usecs, just track it in nanoseconds. Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
2009-12-09 02:34:26 +03:00
* @dev_wakeup_lat: dev wakeup latency in nanoseconds
* @_dev_wakeup_lat_limit: dev wakeup latency limit in nsec - set by OMAP PM
OMAP2/3/4 core: create omap_device layer The omap_device code provides a mapping of omap_hwmod structures into the platform_device system, and includes some details on external (board-level) integration. This allows drivers to enable, idle, and shutdown on-chip device resources, including clocks, regulators, etc. The resources enabled and idled are dependent on the device's maximum wakeup latency constraint (if present). At the moment, omap_device functions are intended to be called from platform_data function pointers. Ideally in the future these functions will be called from either subarchitecture-specific platform_data activate, deactivate functions, or via an custom bus/device type for OMAP. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-03 21:14:05 +04:00
* @_state: one of OMAP_DEVICE_STATE_* (see above)
* @flags: device flags
*
* Integrates omap_hwmod data into Linux platform_device.
*
* Field names beginning with underscores are for the internal use of
* the omap_device code.
*
*/
struct omap_device {
OMAP: omap_device: decouple platform_device from omap_device 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: Kevin Hilman <khilman@ti.com>
2011-07-22 00:58:51 +04:00
struct platform_device *pdev;
OMAP2/3/4 core: create omap_device layer The omap_device code provides a mapping of omap_hwmod structures into the platform_device system, and includes some details on external (board-level) integration. This allows drivers to enable, idle, and shutdown on-chip device resources, including clocks, regulators, etc. The resources enabled and idled are dependent on the device's maximum wakeup latency constraint (if present). At the moment, omap_device functions are intended to be called from platform_data function pointers. Ideally in the future these functions will be called from either subarchitecture-specific platform_data activate, deactivate functions, or via an custom bus/device type for OMAP. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-03 21:14:05 +04:00
struct omap_hwmod **hwmods;
struct omap_device_pm_latency *pm_lats;
u32 dev_wakeup_lat;
u32 _dev_wakeup_lat_limit;
u8 pm_lats_cnt;
s8 pm_lat_level;
u8 hwmods_cnt;
u8 _state;
OMAP: PM: omap_device: add system PM methods for PM domain handling 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: Kevin Hilman <khilman@ti.com> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-07-13 00:48:19 +04:00
u8 flags;
OMAP2/3/4 core: create omap_device layer The omap_device code provides a mapping of omap_hwmod structures into the platform_device system, and includes some details on external (board-level) integration. This allows drivers to enable, idle, and shutdown on-chip device resources, including clocks, regulators, etc. The resources enabled and idled are dependent on the device's maximum wakeup latency constraint (if present). At the moment, omap_device functions are intended to be called from platform_data function pointers. Ideally in the future these functions will be called from either subarchitecture-specific platform_data activate, deactivate functions, or via an custom bus/device type for OMAP. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-03 21:14:05 +04:00
};
/* Device driver interface (call via platform_data fn ptrs) */
int omap_device_enable(struct platform_device *pdev);
int omap_device_idle(struct platform_device *pdev);
int omap_device_shutdown(struct platform_device *pdev);
/* Core code interface */
OMAP: omap_device: when building return platform_device instead of omap_device 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: Kevin Hilman <khilman@ti.com>
2011-07-22 00:48:45 +04:00
struct platform_device *omap_device_build(const char *pdev_name, int pdev_id,
OMAP2/3/4 core: create omap_device layer The omap_device code provides a mapping of omap_hwmod structures into the platform_device system, and includes some details on external (board-level) integration. This allows drivers to enable, idle, and shutdown on-chip device resources, including clocks, regulators, etc. The resources enabled and idled are dependent on the device's maximum wakeup latency constraint (if present). At the moment, omap_device functions are intended to be called from platform_data function pointers. Ideally in the future these functions will be called from either subarchitecture-specific platform_data activate, deactivate functions, or via an custom bus/device type for OMAP. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-03 21:14:05 +04:00
struct omap_hwmod *oh, void *pdata,
int pdata_len,
struct omap_device_pm_latency *pm_lats,
OMAP: HWMOD: Add support for early device register into omap device layer This patch adds support in omap device layer to register devices as early platform devices. Certain devices needed during system boot up like timers, gpio etc can be registered as early devices. This will allow for them to be probed very early on during system boot up. This patch adds a parameter is_early_device in omap_device_build. Depending on this parameter a call to early_platform_add_devices or platform_register_device is made. Signed-off-by: Thara Gopinath <thara@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
2010-02-24 22:05:58 +03:00
int pm_lats_cnt, int is_early_device);
OMAP2/3/4 core: create omap_device layer The omap_device code provides a mapping of omap_hwmod structures into the platform_device system, and includes some details on external (board-level) integration. This allows drivers to enable, idle, and shutdown on-chip device resources, including clocks, regulators, etc. The resources enabled and idled are dependent on the device's maximum wakeup latency constraint (if present). At the moment, omap_device functions are intended to be called from platform_data function pointers. Ideally in the future these functions will be called from either subarchitecture-specific platform_data activate, deactivate functions, or via an custom bus/device type for OMAP. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-03 21:14:05 +04:00
OMAP: omap_device: when building return platform_device instead of omap_device 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: Kevin Hilman <khilman@ti.com>
2011-07-22 00:48:45 +04:00
struct platform_device *omap_device_build_ss(const char *pdev_name, int pdev_id,
OMAP2/3/4 core: create omap_device layer The omap_device code provides a mapping of omap_hwmod structures into the platform_device system, and includes some details on external (board-level) integration. This allows drivers to enable, idle, and shutdown on-chip device resources, including clocks, regulators, etc. The resources enabled and idled are dependent on the device's maximum wakeup latency constraint (if present). At the moment, omap_device functions are intended to be called from platform_data function pointers. Ideally in the future these functions will be called from either subarchitecture-specific platform_data activate, deactivate functions, or via an custom bus/device type for OMAP. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-03 21:14:05 +04:00
struct omap_hwmod **oh, int oh_cnt,
void *pdata, int pdata_len,
struct omap_device_pm_latency *pm_lats,
OMAP: HWMOD: Add support for early device register into omap device layer This patch adds support in omap device layer to register devices as early platform devices. Certain devices needed during system boot up like timers, gpio etc can be registered as early devices. This will allow for them to be probed very early on during system boot up. This patch adds a parameter is_early_device in omap_device_build. Depending on this parameter a call to early_platform_add_devices or platform_register_device is made. Signed-off-by: Thara Gopinath <thara@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
2010-02-24 22:05:58 +03:00
int pm_lats_cnt, int is_early_device);
OMAP2/3/4 core: create omap_device layer The omap_device code provides a mapping of omap_hwmod structures into the platform_device system, and includes some details on external (board-level) integration. This allows drivers to enable, idle, and shutdown on-chip device resources, including clocks, regulators, etc. The resources enabled and idled are dependent on the device's maximum wakeup latency constraint (if present). At the moment, omap_device functions are intended to be called from platform_data function pointers. Ideally in the future these functions will be called from either subarchitecture-specific platform_data activate, deactivate functions, or via an custom bus/device type for OMAP. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-03 21:14:05 +04:00
OMAP: hwmod/device: add omap_{device,hwmod}_get_mpu_rt_va Add omap_device_get_mpu_rt_va(). This is intended to be used by device drivers (currently, via a struct platform_data function pointer) to retrieve their corresponding device's virtual base address that the MPU should use to access the device. This is needed because the omap_hwmod code does its own ioremap(), in order to gain access to the module's OCP_SYSCONFIG register. Add omap_hwmod_get_mpu_rt_va(). omap_device_get_mpu_rt_va() calls this function to do the real work. While here, rename struct omap_hwmod._rt_va to struct omap_hwmod._mpu_rt_va, to reinforce that it refers to the MPU's register target virtual address base (as opposed to, for example, the L3's). In the future, this belongs as a function in an omap_bus, so it is not necessary to call this through a platform_data function pointer. The use-case for this function was originally presented by Santosh Shilimkar <santosh.shilimkar@ti.com>. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
2010-07-27 02:34:33 +04:00
void __iomem *omap_device_get_rt_va(struct omap_device *od);
OMAP2/3/4 core: create omap_device layer The omap_device code provides a mapping of omap_hwmod structures into the platform_device system, and includes some details on external (board-level) integration. This allows drivers to enable, idle, and shutdown on-chip device resources, including clocks, regulators, etc. The resources enabled and idled are dependent on the device's maximum wakeup latency constraint (if present). At the moment, omap_device functions are intended to be called from platform_data function pointers. Ideally in the future these functions will be called from either subarchitecture-specific platform_data activate, deactivate functions, or via an custom bus/device type for OMAP. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-03 21:14:05 +04:00
/* OMAP PM interface */
int omap_device_align_pm_lat(struct platform_device *pdev,
u32 new_wakeup_lat_limit);
struct powerdomain *omap_device_get_pwrdm(struct omap_device *od);
OMAP: PM: implement context loss count APIs Implement OMAP PM layer omap_pm_get_dev_context_loss_count() API by creating similar APIs at the omap_device and omap_hwmod levels. The omap_hwmod level call is the layer with access to the powerdomain core, so it is the place where the powerdomain is queried to get the context loss count. The new APIs return an unsigned value that can wrap as the context-loss count grows. However, the wrapping is not important as the role of this function is to determine context loss by checking for any difference in subsequent calls to this function. Note that these APIs at each level can return zero when no context loss is detected, or on errors. This is to avoid returning error codes which could potentially be mistaken for large context loss counters. NOTE: only works for devices which have been converted to use omap_device/omap_hwmod. Longer term, we could possibly remove this API from the OMAP PM layer, and instead directly use the omap_device level API. Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
2010-12-22 07:31:55 +03:00
u32 omap_device_get_context_loss_count(struct platform_device *pdev);
OMAP2/3/4 core: create omap_device layer The omap_device code provides a mapping of omap_hwmod structures into the platform_device system, and includes some details on external (board-level) integration. This allows drivers to enable, idle, and shutdown on-chip device resources, including clocks, regulators, etc. The resources enabled and idled are dependent on the device's maximum wakeup latency constraint (if present). At the moment, omap_device functions are intended to be called from platform_data function pointers. Ideally in the future these functions will be called from either subarchitecture-specific platform_data activate, deactivate functions, or via an custom bus/device type for OMAP. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-03 21:14:05 +04:00
/* Other */
int omap_device_idle_hwmods(struct omap_device *od);
int omap_device_enable_hwmods(struct omap_device *od);
int omap_device_disable_clocks(struct omap_device *od);
int omap_device_enable_clocks(struct omap_device *od);
/*
* Entries should be kept in latency order ascending
*
* deact_lat is the maximum number of microseconds required to complete
* deactivate_func() at the device's slowest OPP.
*
* act_lat is the maximum number of microseconds required to complete
* activate_func() at the device's slowest OPP.
*
* This will result in some suboptimal power management decisions at fast
* OPPs, but avoids having to recompute all device power management decisions
* if the system shifts from a fast OPP to a slow OPP (in order to meet
* latency requirements).
*
* XXX should deactivate_func/activate_func() take platform_device pointers
* rather than omap_device pointers?
*/
struct omap_device_pm_latency {
u32 deactivate_lat;
OMAP: omap_device: optionally auto-adjust device activate/deactivate latencies First, this patch adds new worst-case latency values to the omap_device_pm_latency struct. Here the worst-case measured latencies for the activate and deactivate hooks are stored. In addition, add an option to auto-adjust the latency values used for device activate/deactivate. By setting a new 'OMAP_DEVICE_LATENCY_AUTO_ADJUST' flag in the omap_device_pm_latency struct, the omap_device layer automatically adjusts the activate/deactivate latencies to the worst-case measured values. Anytime a new worst-case value is found, it is printed to the console. Here is an example log during boot using UART2 s an example. After boot, the OPP is manually changed to the 125MHz OPP: [...] Freeing init memory: 128K omap_device: serial8250.2: new worst case deactivate latency 0: 30517 omap_device: serial8250.2: new worst case activate latency 0: 30517 omap_device: serial8250.2: new worst case activate latency 0: 218139648 omap_device: serial8250.2: new worst case deactivate latency 0: 61035 omap_device: serial8250.2: new worst case activate latency 0: 278076171 omap_device: serial8250.2: new worst case activate latency 0: 298614501 omap_device: serial8250.2: new worst case activate latency 0: 327331542 / # echo 125000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed omap_device: serial8250.2: new worst case deactivate latency 0: 91552 Motivation: this can be used as a technique to automatically determine the worst case latency values. The current method of printing a warning on every violation is too noisy to actually interact the console in order to set low OPP to discover latencies. Another motivation for this patch is that the activate/deactivate latenices can vary depending on the idlemode of the device. While working on the UARTs, I noticed that when using no-idle, the activate latencies were as high as several hundred msecs as shown above. When the UARTs are in smart-idle, the max latency is well under 100 usecs. Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
2010-01-27 06:13:02 +03:00
u32 deactivate_lat_worst;
OMAP2/3/4 core: create omap_device layer The omap_device code provides a mapping of omap_hwmod structures into the platform_device system, and includes some details on external (board-level) integration. This allows drivers to enable, idle, and shutdown on-chip device resources, including clocks, regulators, etc. The resources enabled and idled are dependent on the device's maximum wakeup latency constraint (if present). At the moment, omap_device functions are intended to be called from platform_data function pointers. Ideally in the future these functions will be called from either subarchitecture-specific platform_data activate, deactivate functions, or via an custom bus/device type for OMAP. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-03 21:14:05 +04:00
int (*deactivate_func)(struct omap_device *od);
u32 activate_lat;
OMAP: omap_device: optionally auto-adjust device activate/deactivate latencies First, this patch adds new worst-case latency values to the omap_device_pm_latency struct. Here the worst-case measured latencies for the activate and deactivate hooks are stored. In addition, add an option to auto-adjust the latency values used for device activate/deactivate. By setting a new 'OMAP_DEVICE_LATENCY_AUTO_ADJUST' flag in the omap_device_pm_latency struct, the omap_device layer automatically adjusts the activate/deactivate latencies to the worst-case measured values. Anytime a new worst-case value is found, it is printed to the console. Here is an example log during boot using UART2 s an example. After boot, the OPP is manually changed to the 125MHz OPP: [...] Freeing init memory: 128K omap_device: serial8250.2: new worst case deactivate latency 0: 30517 omap_device: serial8250.2: new worst case activate latency 0: 30517 omap_device: serial8250.2: new worst case activate latency 0: 218139648 omap_device: serial8250.2: new worst case deactivate latency 0: 61035 omap_device: serial8250.2: new worst case activate latency 0: 278076171 omap_device: serial8250.2: new worst case activate latency 0: 298614501 omap_device: serial8250.2: new worst case activate latency 0: 327331542 / # echo 125000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed omap_device: serial8250.2: new worst case deactivate latency 0: 91552 Motivation: this can be used as a technique to automatically determine the worst case latency values. The current method of printing a warning on every violation is too noisy to actually interact the console in order to set low OPP to discover latencies. Another motivation for this patch is that the activate/deactivate latenices can vary depending on the idlemode of the device. While working on the UARTs, I noticed that when using no-idle, the activate latencies were as high as several hundred msecs as shown above. When the UARTs are in smart-idle, the max latency is well under 100 usecs. Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
2010-01-27 06:13:02 +03:00
u32 activate_lat_worst;
OMAP2/3/4 core: create omap_device layer The omap_device code provides a mapping of omap_hwmod structures into the platform_device system, and includes some details on external (board-level) integration. This allows drivers to enable, idle, and shutdown on-chip device resources, including clocks, regulators, etc. The resources enabled and idled are dependent on the device's maximum wakeup latency constraint (if present). At the moment, omap_device functions are intended to be called from platform_data function pointers. Ideally in the future these functions will be called from either subarchitecture-specific platform_data activate, deactivate functions, or via an custom bus/device type for OMAP. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-03 21:14:05 +04:00
int (*activate_func)(struct omap_device *od);
OMAP: omap_device: optionally auto-adjust device activate/deactivate latencies First, this patch adds new worst-case latency values to the omap_device_pm_latency struct. Here the worst-case measured latencies for the activate and deactivate hooks are stored. In addition, add an option to auto-adjust the latency values used for device activate/deactivate. By setting a new 'OMAP_DEVICE_LATENCY_AUTO_ADJUST' flag in the omap_device_pm_latency struct, the omap_device layer automatically adjusts the activate/deactivate latencies to the worst-case measured values. Anytime a new worst-case value is found, it is printed to the console. Here is an example log during boot using UART2 s an example. After boot, the OPP is manually changed to the 125MHz OPP: [...] Freeing init memory: 128K omap_device: serial8250.2: new worst case deactivate latency 0: 30517 omap_device: serial8250.2: new worst case activate latency 0: 30517 omap_device: serial8250.2: new worst case activate latency 0: 218139648 omap_device: serial8250.2: new worst case deactivate latency 0: 61035 omap_device: serial8250.2: new worst case activate latency 0: 278076171 omap_device: serial8250.2: new worst case activate latency 0: 298614501 omap_device: serial8250.2: new worst case activate latency 0: 327331542 / # echo 125000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed omap_device: serial8250.2: new worst case deactivate latency 0: 91552 Motivation: this can be used as a technique to automatically determine the worst case latency values. The current method of printing a warning on every violation is too noisy to actually interact the console in order to set low OPP to discover latencies. Another motivation for this patch is that the activate/deactivate latenices can vary depending on the idlemode of the device. While working on the UARTs, I noticed that when using no-idle, the activate latencies were as high as several hundred msecs as shown above. When the UARTs are in smart-idle, the max latency is well under 100 usecs. Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
2010-01-27 06:13:02 +03:00
u32 flags;
OMAP2/3/4 core: create omap_device layer The omap_device code provides a mapping of omap_hwmod structures into the platform_device system, and includes some details on external (board-level) integration. This allows drivers to enable, idle, and shutdown on-chip device resources, including clocks, regulators, etc. The resources enabled and idled are dependent on the device's maximum wakeup latency constraint (if present). At the moment, omap_device functions are intended to be called from platform_data function pointers. Ideally in the future these functions will be called from either subarchitecture-specific platform_data activate, deactivate functions, or via an custom bus/device type for OMAP. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-03 21:14:05 +04:00
};
OMAP: omap_device: optionally auto-adjust device activate/deactivate latencies First, this patch adds new worst-case latency values to the omap_device_pm_latency struct. Here the worst-case measured latencies for the activate and deactivate hooks are stored. In addition, add an option to auto-adjust the latency values used for device activate/deactivate. By setting a new 'OMAP_DEVICE_LATENCY_AUTO_ADJUST' flag in the omap_device_pm_latency struct, the omap_device layer automatically adjusts the activate/deactivate latencies to the worst-case measured values. Anytime a new worst-case value is found, it is printed to the console. Here is an example log during boot using UART2 s an example. After boot, the OPP is manually changed to the 125MHz OPP: [...] Freeing init memory: 128K omap_device: serial8250.2: new worst case deactivate latency 0: 30517 omap_device: serial8250.2: new worst case activate latency 0: 30517 omap_device: serial8250.2: new worst case activate latency 0: 218139648 omap_device: serial8250.2: new worst case deactivate latency 0: 61035 omap_device: serial8250.2: new worst case activate latency 0: 278076171 omap_device: serial8250.2: new worst case activate latency 0: 298614501 omap_device: serial8250.2: new worst case activate latency 0: 327331542 / # echo 125000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed omap_device: serial8250.2: new worst case deactivate latency 0: 91552 Motivation: this can be used as a technique to automatically determine the worst case latency values. The current method of printing a warning on every violation is too noisy to actually interact the console in order to set low OPP to discover latencies. Another motivation for this patch is that the activate/deactivate latenices can vary depending on the idlemode of the device. While working on the UARTs, I noticed that when using no-idle, the activate latencies were as high as several hundred msecs as shown above. When the UARTs are in smart-idle, the max latency is well under 100 usecs. Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
2010-01-27 06:13:02 +03:00
#define OMAP_DEVICE_LATENCY_AUTO_ADJUST BIT(1)
OMAP2/3/4 core: create omap_device layer The omap_device code provides a mapping of omap_hwmod structures into the platform_device system, and includes some details on external (board-level) integration. This allows drivers to enable, idle, and shutdown on-chip device resources, including clocks, regulators, etc. The resources enabled and idled are dependent on the device's maximum wakeup latency constraint (if present). At the moment, omap_device functions are intended to be called from platform_data function pointers. Ideally in the future these functions will be called from either subarchitecture-specific platform_data activate, deactivate functions, or via an custom bus/device type for OMAP. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-03 21:14:05 +04:00
OMAP: omap_device: add to_omap_device() macro Following the model of to_platform_device(), add to_omap_device() macro so a platform_device pointer can be converted into an omap_device pointer. Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
2009-12-09 02:34:17 +03:00
/* Get omap_device pointer from platform_device pointer */
OMAP: omap_device: decouple platform_device from omap_device 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: Kevin Hilman <khilman@ti.com>
2011-07-22 00:58:51 +04:00
static inline struct omap_device *to_omap_device(struct platform_device *pdev)
{
return pdev ? pdev->archdata.od : NULL;
}
OMAP2/3/4 core: create omap_device layer The omap_device code provides a mapping of omap_hwmod structures into the platform_device system, and includes some details on external (board-level) integration. This allows drivers to enable, idle, and shutdown on-chip device resources, including clocks, regulators, etc. The resources enabled and idled are dependent on the device's maximum wakeup latency constraint (if present). At the moment, omap_device functions are intended to be called from platform_data function pointers. Ideally in the future these functions will be called from either subarchitecture-specific platform_data activate, deactivate functions, or via an custom bus/device type for OMAP. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
2009-09-03 21:14:05 +04:00
OMAP: omap_device: _disable_idle_on_suspend() takes platform_device pointer Public omap_device functions need to take platform_device pointers, conversion to omap_device pointers is done internal to the omap_device layer. Signed-off-by: Kevin Hilman <khilman@ti.com>
2011-08-01 20:33:13 +04:00
static inline
void omap_device_disable_idle_on_suspend(struct platform_device *pdev)
{
struct omap_device *od = to_omap_device(pdev);
od->flags |= OMAP_DEVICE_NO_IDLE_ON_SUSPEND;
}
OMAP: omap_device: add to_omap_device() macro Following the model of to_platform_device(), add to_omap_device() macro so a platform_device pointer can be converted into an omap_device pointer. Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
2009-12-09 02:34:17 +03:00
#endif
Reference in New Issue Copy Permalink