summaryrefslogtreecommitdiffstats
path: root/arch/arm/plat-omap/omap_device.c
Commit message (Collapse)AuthorAgeFilesLines
* Merge branch 'fixes-modulesplit' into fixesTony Lindgren2011-11-071-0/+1
|\
| * ARM: OMAP: omap_device: Include linux/export.hAxel Lin2011-11-071-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | Include linux/export.h to fix below build warning: CC arch/arm/plat-omap/omap_device.o arch/arm/plat-omap/omap_device.c:1055: warning: data definition has no type or storage class arch/arm/plat-omap/omap_device.c:1055: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL' arch/arm/plat-omap/omap_device.c:1055: warning: parameter names (without types) in function declaration Signed-off-by: Axel Lin <axel.lin@gmail.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
* | ARM: OMAP: change get_context_loss_count ret value to intTomi Valkeinen2011-11-041-1/+1
|/ | | | | | | | | | | | | | | | | | | | get_context_loss_count functions return context loss count as u32, and zero means an error. However, zero is also returned when context has never been lost and could also be returned when the context loss count has wrapped and goes to zero. Change the functions to return an int, with negative value meaning an error. OMAP HSMMC code uses omap_pm_get_dev_context_loss_count(), but as the hsmmc code handles the returned value as an int, with negative value meaning an error, this patch actually fixes hsmmc code also. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Acked-by: Kevin Hilman <khilman@ti.com> Acked-by: Paul Walmsley <paul@pwsan.com> [tony@atomide.com: updated to fix a warning with recent dmtimer changes] Signed-off-by: Tony Lindgren <tony@atomide.com>
* ARM: OMAP: omap_device: Add a method to build an omap_device from a DT nodeBenoit Cousson2011-10-041-0/+101
| | | | | | | | | | | | | | | | | Add a notifier called during device_add phase. If an of_node is present, retrieve the hwmod entry in order to populate properly the omap_device structure. For the moment the resource from the device-tree are overloaded. DT does not support named resource yet, and thus, most driver will not work without that information. Add a documentation to capture the specifics OMAP bindings needed for device-tree support. Signed-off-by: Benoit Cousson <b-cousson@ti.com> Cc: Grant Likely <grant.likely@secretlab.ca> Signed-off-by: Kevin Hilman <khilman@ti.com>
* ARM: OMAP: omap_device: Add omap_device_[alloc|delete] for DT integrationBenoit Cousson2011-10-041-58/+119
| | | | | | | | | | | | | Split the omap_device_build_ss into two smaller functions that will allow to populate a platform_device already allocated by device-tree. The functionality of the omap_device_build_ss is still the same, but the omap_device_alloc will be usable with devices already built by device-tree. Signed-off-by: Benoit Cousson <b-cousson@ti.com> Signed-off-by: Kevin Hilman <khilman@ti.com>
* ARM: OMAP: omap_device: Create a default omap_device_pm_latencyBenoit Cousson2011-10-041-1/+18
| | | | | | | | | | | | | Most devices are using the same default omap_device_pm_latency structure during device built. In order to avoid the duplication of the same structure everywhere, add a default structure that will be used if the device does not have an explicit one. Next patches will clean the duplicated structures. Signed-off-by: Benoit Cousson <b-cousson@ti.com> Cc: Paul Walmsley <paul@pwsan.com> Signed-off-by: Kevin Hilman <khilman@ti.com>
* ARM: OMAP: omap_device: Add omap_device_get_by_hwmod_nameNishanth Menon2011-10-041-0/+36
| | | | | | | | | | | | | | | | | | | | | | | An API which translates a standard hwmod name to corresponding platform_device is useful for drivers when they need to look up the device associated with a hwmod name to map back into the device structure pointers. These ideally should be used by drivers in mach directory. Using a generic hwmod name like "gpu" instead of the actual device name which could change in the future, allows us to: a) Could in effect help replace apis such as omap2_get_mpuss_device, omap2_get_iva_device, omap2_get_l3_device, omap4_get_dsp_device, etc.. b) Scale to more devices rather than be restricted to named functions c) Simplify driver's platform_data from passing additional fields all doing the same thing with different function pointer names just for accessing a different device name. Signed-off-by: Nishanth Menon <nm@ti.com> [b-cousson@ti.com: Adapt it to the new pdev pointer inside od, remove the unneeded helpers, and fold the next patch here] Signed-off-by: Benoit Cousson <b-cousson@ti.com> Signed-off-by: Kevin Hilman <khilman@ti.com>
* OMAP: omap_device: decouple platform_device from omap_deviceKevin Hilman2011-09-151-48/+52
| | | | | | | | | | | 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>
* OMAP: omap_device: device register functions now take platform_device pointerKevin Hilman2011-09-151-11/+11
| | | | | | | | The internal device register functions do not need or use any omap_device internals, so pass in a platform_device pointer instead of an omap_device pointer. Signed-off-by: Kevin Hilman <khilman@ti.com>
* OMAP: omap_device: when building return platform_device instead of omap_deviceKevin Hilman2011-09-151-3/+3
| | | | | | | | | | | | | | | | | | 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>
* OMAP: omap_device: remove internal functions from omap_device.hKevin Hilman2011-09-151-4/+8
| | | | | | | The *_device_register() functions and the count/fill resources functions are internal to omap_device and do not need to be in the header. Signed-off-by: Kevin Hilman <khilman@ti.com>
* OMAP: omap_device: make latency autoadjust messages debugGrazvydas Ignotas2011-09-151-8/+8
| | | | | | | | | | | | | During normal system operation warning messages similar to this are appearing quite often: omap_device: omap4-keypad.-1: new worst case activate latency 0: 61035 This doesn't seem to be reporting a problem, nor is it very useful for non-developers, so reduce it to debug level. Acked-by: Steve Sakoman <steve@sakoman.com> Signed-off-by: Grazvydas Ignotas <notasas@gmail.com> Signed-off-by: Kevin Hilman <khilman@ti.com>
* OMAP: omap_device: replace debug/warning/error prints with dev_* macrosKevin Hilman2011-09-151-43/+42
| | | | | | | | | | | | | | | | For consistency in kernel printk output for devices, use dev_dbg(), dev_warn(), dev_err() instead of pr_debug(), pr_warning() and pr_err(), some of which currently use direct access of name from platform_device and others of which use dev_name(). Using the dev_* versions uses the standard device naming from the driver core. Some pr_* prints were not converted with this patch since they are used before the platform_device and struct device are created so neither the dev_* prints or dev_name() is valid. Reported-by: Russell King <rmk+kernel@arm.linux.org.uk> Reviewed-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Kevin Hilman <khilman@ti.com>
* OMAP: omap_device: fix !CONFIG_SUSPEND case in _noirq handlersKevin Hilman2011-09-061-0/+3
| | | | | | | | | | The suspend/resume _noirq handlers were #ifdef'd out in the !CONFIG_SUSPEND case, but were still assigned to the dev_pm_ops struct. Fix by defining them to NULL in the !CONFIG_SUSPEND case. Reported-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Kevin Hilman <khilman@ti.com>
* OMAP: omap_device: only override _noirq methods, not normal suspend/resumeKevin Hilman2011-08-251-1/+2
| | | | | | | | | | | | | | | | | | Commit c03f007a8bf0e092caeb6856a5c8a850df10b974 (OMAP: PM: omap_device: add system PM methods for PM domain handling) mistakenly used SET_SYSTEM_SLEEP_PM_OPS() when trying to configure custom methods for the PM domains noirq methods. Fix that by setting only the suspend_noirq and resume_noirq methods with custom versions. Note that all other PM domain methods (including the "normal" suspend/resume methods) are populated using USE_PLATFORM_PM_SLEEP_OPS, which configures them all to the default subsystem (platform_bus) methods. Reported-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Tested-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Signed-off-by: Kevin Hilman <khilman@ti.com> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
* Merge branch 'next/devel2' of ↵Linus Torvalds2011-07-261-35/+50
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/arm/linux-arm-soc * 'next/devel2' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/linux-arm-soc: (47 commits) OMAP: Add debugfs node to show the summary of all clocks OMAP2+: hwmod: Follow the recommended PRCM module enable sequence OMAP2+: clock: allow per-SoC clock init code to prevent clockdomain calls from clock code OMAP2+: clockdomain: Add per clkdm lock to prevent concurrent state programming OMAP2+: PM: idle clkdms only if already in idle OMAP2+: clockdomain: add clkdm_in_hwsup() OMAP2+: clockdomain: Add 2 APIs to control clockdomain from hwmod framework OMAP: clockdomain: Remove redundant call to pwrdm_wait_transition() OMAP4: hwmod: Introduce the module control in hwmod control OMAP4: cm: Add two new APIs for modulemode control OMAP4: hwmod data: Add modulemode entry in omap_hwmod structure OMAP4: hwmod data: Add PRM context register offset OMAP4: prm: Remove deprecated functions OMAP4: prm: Replace warm reset API with the offset based version OMAP4: hwmod: Replace RSTCTRL absolute address with offset macros OMAP: hwmod: Wait the idle status to be disabled OMAP4: hwmod: Replace CLKCTRL absolute address with offset macros OMAP2+: hwmod: Init clkdm field at boot time OMAP4: hwmod data: Add clock domain attribute OMAP4: clock data: Add missing divider selection for auxclks ...
| * OMAP: omap_device: Create clkdev entry for hwmod main_clkBenoit Cousson2011-07-101-35/+50
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Extend the existing function to create clkdev for every optional clocks to add a well one "fck" alias for the main_clk of the omap_hwmod. It will allow to remove these static clkdev entries from the clockXXX_data.c file. Signed-off-by: Benoit Cousson <b-cousson@ti.com> Cc: Paul Walmsley <paul@pwsan.com> Cc: Kevin Hilman <khilman@ti.com> Cc: Todd Poynor <toddpoynor@google.com> [paul@pwsan.com: remove all of the "fck" role clkdev aliases from the clock data files; fixed error message] Signed-off-by: Paul Walmsley <paul@pwsan.com>
* | Merge branch 'next/cleanup' of ↵Linus Torvalds2011-07-251-10/+5
|\ \ | |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/arm/linux-arm-soc * 'next/cleanup' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/linux-arm-soc: (133 commits) ARM: EXYNOS4: Change devname for FIMD clkdev ARM: S3C64XX: Cleanup mach/regs-fb.h from mach-s3c64xx ARM: S5PV210: Cleanup mach/regs-fb.h from mach-s5pv210 ARM: S5PC100: Cleanup mach/regs-fb.h from mach-s5pc100 ARM: S3C24XX: Use generic s3c_set_platdata for devices ARM: S3C64XX: Use generic s3c_set_platdata for OneNAND ARM: SAMSUNG: Use generic s3c_set_platdata for NAND ARM: SAMSUNG: Use generic s3c_set_platdata for USB OHCI ARM: SAMSUNG: Use generic s3c_set_platdata for HWMON ARM: SAMSUNG: Use generic s3c_set_platdata for FB ARM: SAMSUNG: Use generic s3c_set_platdata for TS ARM: S3C64XX: Add PWM backlight support on SMDK6410 ARM: S5P64X0: Add PWM backlight support on SMDK6450 ARM: S5P64X0: Add PWM backlight support on SMDK6440 ARM: S5PC100: Add PWM backlight support on SMDKC100 ARM: S5PV210: Add PWM backlight support on SMDKV210 ARM: EXYNOS4: Add PWM backlight support on SMDKC210 ARM: EXYNOS4: Add PWM backlight support on SMDKV310 ARM: SAMSUNG: Create a common infrastructure for PWM backlight support clocksource: convert 32-bit down counting clocksource on S5PV210/S5P64X0 ... Fix up trivial conflict in arch/arm/mach-imx/mach-scb9328.c
| * OMAP: omap_device: replace _find_by_pdev() with to_omap_device()Kevin Hilman2011-07-091-10/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The omap_device layer currently has two ways of getting an omap_device pointer from a platform_device pointer. Replace current usage of _find_by_pdev() with to_omap_device() since to_omap_device() is more familiar to the existing to_platform_device() used when getting a platform_device pointer from a struct device pointer. Cc: Felipe Balbi <balbi@ti.com> Signed-off-by: Kevin Hilman <khilman@ti.com> Reviewed-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
* | OMAP: PM: omap_device: add API to disable idle on suspendKevin Hilman2011-07-121-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | 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>
* | OMAP: PM: omap_device: add system PM methods for PM domain handlingKevin Hilman2011-07-121-0/+36
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | OMAP: PM: omap_device: conditionally use PM domain runtime helpersKevin Hilman2011-07-121-3/+4
| | | | | | | | | | | | | | | | Only build and use the runtime PM helper functions only when runtime PM is actually enabled. Signed-off-by: Kevin Hilman <khilman@ti.com> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
* | PM / Domains: Rename struct dev_power_domain to struct dev_pm_domainRafael J. Wysocki2011-07-021-2/+2
|/ | | | | | | | | | | | | | | | | | The naming convention used by commit 7538e3db6e015e890825fbd9f86599b (PM: Add support for device power domains), which introduced the struct dev_power_domain type for representing device power domains, evidently confuses some developers who tend to think that objects of this type must correspond to "power domains" as defined by hardware, which is not the case. Namely, at the kernel level, a struct dev_power_domain object can represent arbitrary set of devices that are mutually dependent power management-wise and need not belong to one hardware power domain. To avoid that confusion, rename struct dev_power_domain to struct dev_pm_domain and rename the related pointers in struct device and struct pm_clk_notifier_block from pwr_domain to pm_domain. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Acked-by: Kevin Hilman <khilman@ti.com>
* 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>
OpenPOWER on IntegriCloud