aboutsummaryrefslogtreecommitdiffstats
path: root/arch/arm/plat-omap/omap_device.c
Commit message (Collapse)AuthorAgeFilesLines
* OMAP: PM: omap_device: fix device power domain callbacksKevin Hilman2011-06-061-2/+17
| | | | | | | | | | | | After commit 4d27e9dcff00a6425d779b065ec8892e4f391661 (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: Kevin Hilman <khilman@ti.com>
* OMAP2+ / PM: move runtime PM implementation to use device power domainsKevin Hilman2011-04-291-0/+23
| | | | | | | | | | | | | | | | | | | | | In commit 7538e3db6e015e890825fbd9f8659952896ddd5b (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: Kevin Hilman <khilman@ti.com> Acked-by: Grant Likely <grant.likely@secretlab.ca> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
* OMAP2+: omap_device/clock: Do not expect an entry in clkdev for opt_clksRajendra Nayak2011-03-011-10/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | The _add_optional_clock_alias function expects an entry already existing in the clkdev table in the form of <dev-id=NULL, con-id=role> which might not be the case always. Instead, just check if an entry already exists in clkdev in the <dev-id=dev_name, con-id=role> form, else go ahead and add one. Remove any assumption of an entry already existing in clkdev table in any form. Since this means, adding a new entry in clkdev if it does not already exist, and not really adding an 'alias', also rename the function name (s/_add_optional_clock_alias/_add_optional_clock_clkdev) to reflect this. Signed-off-by: Rajendra Nayak <rnayak@ti.com> Reported-by: Sumit Semwal <sumit.semwal@ti.com> Cc: Sumit Semwal <sumit.semwal@ti.com> Cc: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@ti.com> Cc: Partha Basak <p-basak2@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
* OMAP: PM: implement context loss count APIsKevin Hilman2010-12-211-0/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Merge branch 'misc_2.6.37' of git://git.pwsan.com/linux-2.6 into omap-for-linusTony Lindgren2010-09-271-21/+14
|\
| * OMAP: omap_device: Fix to support multiple hwmods for a single deviceKishon Vijay Abraham I2010-09-241-21/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently there is a bug in the existing omap_device core code when extracting the hwmod structures passed to omap_device_build_ss(). This bug gets exposed only when passing multiple hwmod structures to omap_device_build_ss() resulting in incorrect extraction from second hwmod structure. This fix uses the pointer to pointer to omap_hwmod structure (array of pointers to omap_hwmod structure) passed to omap_device_build_ss() to correctly extract the appropriate omap_hwmod structure. This patch has been created and tested on lo/master and mainline. Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com> Acked-by: Benoit Cousson <b-cousson@ti.com> Acked-by: Kevin Hilman <khilman@deeprootsystems.com> Cc: Charulatha V <charu@ti.com> Cc: Shubhrajyoti D <shubhrajyoti@ti.com>
* | Merge branch 'pm-next' of ↵Tony Lindgren2010-09-231-20/+12
|\ \ | |/ |/| | | ssh://master.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm into omap-for-linus
| * OMAP: omap_device: make all devices a child of a new parent deviceKevin Hilman2010-09-231-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * Revert "OMAP: omap_device: add omap_device_is_valid()"Kevin Hilman2010-09-231-20/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit 0007122ad85cc36b1c18c0b59344093ca210d206. The dereference method of checking for a valid omap_device when wrapping a platform_device is rather unsafe and dangerous. Instead, a better way of checking for a valid omap-device is to use a common parent device for all omap_devices, then a check can simply be made using the device parent. The only user of this API was the initial version of the runtime PM core for OMAP. This has now been switched to check device parent, so there are no more users of this API. Acked-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
* | OMAP: hwmod: Handle opt clocks node using clk_add_aliasPartha Basak2010-09-221-1/+42
|/ | | | | | | | | | | | | | | | | | | | | | | | For every optional clock present per hwmod per omap-device, this function adds an entry in the clocks list of the form <dev-id=dev_name, con-id=role>, if an entry is already present in the list of the form <dev-id=NULL, con-id=role>. The function is called from within the framework inside omap_device_build_ss(), after omap_device_register. This allows drivers to get a pointer to its optional clocks based on its role by calling clk_get(<dev*>, <role>). Link to discussions related to this patch: http://www.spinics.net/lists/linux-omap/msg34809.html Signed-off-by: Charulatha V <charu@ti.com> Signed-off-by: Partha Basak <p-basak2@ti.com> Signed-off-by: Benoit Cousson <b-cousson@ti.com> Signed-off-by: Rajendra Nayak <rnayak@ti.com> [paul@pwsan.com: simplified loop iterator; removed the superfluous clk_get(), using the clk_get() in clk_add_alias() instead] Signed-off-by: Paul Walmsley <paul@pwsan.com> Acked-by: Kevin Hilman <khilman@deeprootsystems.com>
* omap: device: improve errors handlingArtem Bityutskiy2010-08-041-1/+3
| | | | | | | | | | Do not forget to check the 'platform_device_add_data()' error code in 'omap_device_build_ss()'. Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com> Acked-by: Nishanth Menon <nm@ti.com> Acked-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
* OMAP2+: hwmod/device: update documentation and copyrightPaul Walmsley2010-07-261-3/+6
| | | | | | | | | Update some minor documentation issues and update copyright for omap_device/omap_hwmod code. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Benoît Cousson <b-cousson@ti.com>
* OMAP: hwmod/device: add omap_{device,hwmod}_get_mpu_rt_vaPaul Walmsley2010-07-261-0/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* OMAP: omap_device: ensure hwmod tracks attached omap_device pointerKevin Hilman2010-07-261-1/+4
| | | | | | | | | | The omap_hwmod struct has a field to track the omap_device that is attached to it, but it was not being assigned. Fix by assigning omap_device pointer when omap_device is built. Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com> [paul@pwsan.com: use an array index rather than pointer arithmetic] Signed-off-by: Paul Walmsley <paul@pwsan.com>
* OMAP powerdomain, hwmod, omap_device: add some creditsPaul Walmsley2010-05-201-2/+2
| | | | | | | | | | | Add some missing credits for people who have contributed significant features or fixes. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com> Cc: Tero Kristo <tero.kristo@nokia.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Thara Gopinath <thara@ti.com>
* include cleanup: Update gfp.h and slab.h includes to prepare for breaking ↵Tejun Heo2010-03-301-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | implicit slab.h inclusion from percpu.h percpu.h is included by sched.h and module.h and thus ends up being included when building most .c files. percpu.h includes slab.h which in turn includes gfp.h making everything defined by the two files universally available and complicating inclusion dependencies. percpu.h -> slab.h dependency is about to be removed. Prepare for this change by updating users of gfp and slab facilities include those headers directly instead of assuming availability. As this conversion needs to touch large number of source files, the following script is used as the basis of conversion. http://userweb.kernel.org/~tj/misc/slabh-sweep.py The script does the followings. * Scan files for gfp and slab usages and update includes such that only the necessary includes are there. ie. if only gfp is used, gfp.h, if slab is used, slab.h. * When the script inserts a new include, it looks at the include blocks and try to put the new include such that its order conforms to its surrounding. It's put in the include block which contains core kernel includes, in the same order that the rest are ordered - alphabetical, Christmas tree, rev-Xmas-tree or at the end if there doesn't seem to be any matching order. * If the script can't find a place to put a new include (mostly because the file doesn't have fitting include block), it prints out an error message indicating which .h file needs to be added to the file. The conversion was done in the following steps. 1. The initial automatic conversion of all .c files updated slightly over 4000 files, deleting around 700 includes and adding ~480 gfp.h and ~3000 slab.h inclusions. The script emitted errors for ~400 files. 2. Each error was manually checked. Some didn't need the inclusion, some needed manual addition while adding it to implementation .h or embedding .c file was more appropriate for others. This step added inclusions to around 150 files. 3. The script was run again and the output was compared to the edits from #2 to make sure no file was left behind. 4. Several build tests were done and a couple of problems were fixed. e.g. lib/decompress_*.c used malloc/free() wrappers around slab APIs requiring slab.h to be added manually. 5. The script was run on all .h files but without automatically editing them as sprinkling gfp.h and slab.h inclusions around .h files could easily lead to inclusion dependency hell. Most gfp.h inclusion directives were ignored as stuff from gfp.h was usually wildly available and often used in preprocessor macros. Each slab.h inclusion directive was examined and added manually as necessary. 6. percpu.h was updated not to include slab.h. 7. Build test were done on the following configurations and failures were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my distributed build env didn't work with gcov compiles) and a few more options had to be turned off depending on archs to make things build (like ipr on powerpc/64 which failed due to missing writeq). * x86 and x86_64 UP and SMP allmodconfig and a custom test config. * powerpc and powerpc64 SMP allmodconfig * sparc and sparc64 SMP allmodconfig * ia64 SMP allmodconfig * s390 SMP allmodconfig * alpha SMP allmodconfig * um on x86_64 SMP allmodconfig 8. percpu.h modifications were reverted so that it could be applied as a separate patch and serve as bisection point. Given the fact that I had only a couple of failures from tests on step 6, I'm fairly confident about the coverage of this conversion patch. If there is a breakage, it's likely to be something in one of the arch headers which should be easily discoverable easily on most builds of the specific arch. Signed-off-by: Tejun Heo <tj@kernel.org> Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org> Cc: Ingo Molnar <mingo@redhat.com> Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
* OMAP: HWMOD: Add support for early device register into omap device layerThara Gopinath2010-02-241-4/+29
| | | | | | | | | | | | | 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>
* OMAP: omap_device: when 'called from invalid state', print stateKevin Hilman2010-02-241-6/+6
| | | | | | | | | | | | | | The omap_device_[enable|idle|shutdown] functions print a warning when called from an invalid state. Print the invalid state in the warning messages. This also uses __func__ to get the function name. Also, move the entire print string onto a single line to facilitate grepping or error messages. Recent discussions on LKML show strong preference for grep-able code vs. strict 80 column limit. Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
* OMAP: omap_device: add omap_device_is_valid()Kevin Hilman2010-02-241-0/+16
| | | | | | | | | | | | | | | | | | 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>
* Merge branch 'omap-fixes-for-linus' into omap-for-linusTony Lindgren2010-02-101-10/+0
|\
| * omap: Remove old unused defines for OMAP_32KSYNCT_BASETony Lindgren2010-02-031-10/+0
| | | | | | | | | | | | Remove old unused defines for OMAP_32KSYNCT_BASE Signed-off-by: Tony Lindgren <tony@atomide.com>
* | OMAP: omap_device: optionally auto-adjust device activate/deactivate latenciesKevin Hilman2010-01-261-8/+33
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* OMAP: omap_device: track latency in nanosecondsKevin Hilman2009-12-111-4/+4
| | | | | | | | 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>
* OMAP: omap_device: fix nsec/usec conversion in latency calculationsKevin Hilman2009-12-111-2/+2
| | | | | | | | | | | | | Use usecs = nsecs / NSEC_PER_USEC; instead of usecs = nsecs * NSEC_PER_USEC; Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
* OMAP: omap_device: use read_persistent_clock() instead of getnstimeofday()Kevin Hilman2009-12-111-4/+4
| | | | | | | | | | | During suspend and resume, when omap_device deactivation and activation is happening, the timekeeping subsystem has likely already been suspended. Thus getnstimeofday() will fail and trigger a WARN(). Use read_persistent_clock() instead of getnstimeofday() to avoid this. Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
* OMAP: omap_device: use UINT_MAX for default wakeup latency limitKevin Hilman2009-12-111-1/+1
| | | | | | | | The _dev_wakeup_lat_limit field of struct omap_device is u32, so use UINT_MAX instead of INT_MAX for the default maximum. Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
* omap: headers: Move remaining headers from include/mach to include/platTony Lindgren2009-10-201-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* omap: Use getnstimeofday for omap_deviceTony Lindgren2009-10-191-31/+19
| | | | | | | Use getnstimeofday for omap_device Acked-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
* OMAP2/3/4 core: create omap_device layerPaul Walmsley2009-09-031-0/+687
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>