Minki/linux
1
0
Fork 1
mirror of https://github.com/torvalds/linux.git synced 2024-12-30 14:52:05 +00:00
Code Issues Packages Projects Releases Wiki Activity
358f0e630d
linux/arch/arm/plat-omap/include/plat/omap_device.h

150 lines
4.7 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 17:14:05 +00: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 16:40:47 +00: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 17:14:05 +00: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
/**
* 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-08 23:34:26 +00: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 17:14:05 +00: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: add omap_device_is_valid() The omap_device struct contains a 'struct platform_device'. Normally, converting a platform_device pointer to an omap_device pointer consists of simply doing a container_of(), as is done currently by the to_omap_device() macro. However, if this is attempted when using platform_device that has not been created as part of the omap_device creation, the container_of() will point to a memory location before the platform_device pointer which will contain random data. Therefore, we need a way to detect valid omap_device pointers. This patch solves this by using the simple magic number approach. Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
2010-02-24 19:05:45 +00:00
u32 magic;
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 17:14:05 +00:00
struct platform_device pdev;
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;
};
/* 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: add omap_device_is_valid() The omap_device struct contains a 'struct platform_device'. Normally, converting a platform_device pointer to an omap_device pointer consists of simply doing a container_of(), as is done currently by the to_omap_device() macro. However, if this is attempted when using platform_device that has not been created as part of the omap_device creation, the container_of() will point to a memory location before the platform_device pointer which will contain random data. Therefore, we need a way to detect valid omap_device pointers. This patch solves this by using the simple magic number approach. Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
2010-02-24 19:05:45 +00:00
bool omap_device_is_valid(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 17:14:05 +00:00
int omap_device_count_resources(struct omap_device *od);
int omap_device_fill_resources(struct omap_device *od, struct resource *res);
struct omap_device *omap_device_build(const char *pdev_name, int pdev_id,
struct omap_hwmod *oh, void *pdata,
int pdata_len,
struct omap_device_pm_latency *pm_lats,
int pm_lats_cnt);
struct omap_device *omap_device_build_ss(const char *pdev_name, int pdev_id,
struct omap_hwmod **oh, int oh_cnt,
void *pdata, int pdata_len,
struct omap_device_pm_latency *pm_lats,
int pm_lats_cnt);
int omap_device_register(struct omap_device *od);
/* 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);
/* 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 03:13:02 +00: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 17:14:05 +00: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 03:13:02 +00: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 17:14:05 +00: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 03:13:02 +00: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 17:14:05 +00: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 03:13:02 +00: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 17:14:05 +00: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-08 23:34:17 +00:00
/* Get omap_device pointer from platform_device pointer */
#define to_omap_device(x) container_of((x), struct omap_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 17:14:05 +00: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-08 23:34:17 +00:00
#endif
Reference in New Issue Copy Permalink