AuxXxilium/linux_dsm_epyc7002
1
0
Fork 0
mirror of https://github.com/AuxXxilium/linux_dsm_epyc7002.git synced 2024-12-21 08:27:01 +07:00
Code Issues Actions Packages Projects Releases Wiki Activity
fea79e0b0e
linux_dsm_epyc7002/arch/arm/mach-omap2/omap_device.h

101 lines
3.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-04 00:14:05 +07: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.
*
ARM: OMAP2+: omap_device: remove obsolete pm_lats and early_device code Remove now-obsolete code from arch/arm/mach-omap2/omap_device.c. This mostly consists of removing the first attempt at device PM latency handling. This was never really used, has been replaced by the common dev_pm_qos code, and needs to go away as part of the DT conversion. Also, the early platform_device creation code has been removed, as it appears to be unused. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Kevin Hilman <khilman@deeprootsystems.com>
2013-01-26 14:48:53 +07:00
* This type of functionality should be implemented as a proper
* omap_bus/omap_device in Linux.
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-04 00:14:05 +07:00
*
* 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.
*/
#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>
ARM: OMAP: Make plat/omap_hwmod.h local to mach-omap2 Let's make omap_hwmod local to mach-omap2 for ARM common zImage support. Signed-off-by: Tony Lindgren <tony@atomide.com>
2012-10-03 07:41:35 +07:00
#include "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-04 00:14:05 +07:00
ARM: OMAP: omap_device: remove omap_device_parent Currently all omap_devices are forced to have the dummy device 'omap_device_parent' as a parent. This was used to distinguish omap_devices from "normal" platform_devices in the OMAP PM core code. Now that we implement the PM core using PM domains, this is no longer needed, and is removed. This also frees up omap_devices to have a more complex parent/child relationships that model actual device relationships. The only in-tree user of omap_device_parent was the OMAP PM layer to handle lost-context count for omap_devices. That is now converted to use the presence of the omap_device_pm_domain instead. Signed-off-by: Kevin Hilman <khilman@ti.com>
2012-02-16 02:47:45 +07:00
extern struct dev_pm_domain omap_device_pm_domain;
ARM: OMAP2+: omap_device: add fail hook for runtime_pm when bad data is detected Due to the cross dependencies between hwmod for automanaged device information for OMAP and dts node definitions, we can run into scenarios where the dts node is defined, however it's hwmod entry is yet to be added. In these cases: a) omap_device does not register a pm_domain (since it cannot find hwmod entry). b) driver does not know about (a), does a pm_runtime_get_sync which never fails c) It then tries to do some operation on the device (such as read the revision register (as part of probe) without clock or adequate OMAP generic PM operation performed for enabling the module. This causes a crash such as that reported in: https://bugzilla.kernel.org/show_bug.cgi?id=66441 When 'ti,hwmod' is provided in dt node, it is expected that the device will not function without the OMAP's power automanagement. Hence, when we hit a fail condition (due to hwmod entries not present or other similar scenario), fail at pm_domain level due to lack of data, provide enough information for it to be fixed, however, it allows for the driver to take appropriate measures to prevent crash. Reported-by: Tobias Jakobi <tjakobi@math.uni-bielefeld.de> Signed-off-by: Nishanth Menon <nm@ti.com> Acked-by: Kevin Hilman <khilman@linaro.org> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Kevin Hilman <khilman@linaro.org>
2013-12-04 08:39:13 +07:00
extern struct dev_pm_domain omap_device_fail_pm_domain;
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 22:10:55 +07: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-04 00:14:05 +07: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 03:48:19 +07:00
/* omap_device.flags values */
ARM: OMAP2+: omap_device: remove obsolete pm_lats and early_device code Remove now-obsolete code from arch/arm/mach-omap2/omap_device.c. This mostly consists of removing the first attempt at device PM latency handling. This was never really used, has been replaced by the common dev_pm_qos code, and needs to go away as part of the DT conversion. Also, the early platform_device creation code has been removed, as it appears to be unused. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Kevin Hilman <khilman@deeprootsystems.com>
2013-01-26 14:48:53 +07:00
#define OMAP_DEVICE_SUSPENDED BIT(0)
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 03:48:19 +07: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-04 00:14:05 +07: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
* @_state: one of OMAP_DEVICE_STATE_* (see above)
* @flags: device flags
ARM: OMAP: omap_device: keep track of driver bound status Use the bus notifier to keep track of driver bound status by adding a new internal field to struct omap_device: _driver_status. This will be useful for follow-up patches which need to know whether or not a driver is bound in order to make intelligent omap_device enable/idle decisions. Reviewed-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Kevin Hilman <khilman@ti.com>
2012-07-11 01:13:16 +07:00
* @_driver_status: one of BUS_NOTIFY_*_DRIVER from <linux/device.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-04 00:14:05 +07:00
*
* 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 03:58:51 +07: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-04 00:14:05 +07:00
struct omap_hwmod **hwmods;
ARM: OMAP: omap_device: keep track of driver bound status Use the bus notifier to keep track of driver bound status by adding a new internal field to struct omap_device: _driver_status. This will be useful for follow-up patches which need to know whether or not a driver is bound in order to make intelligent omap_device enable/idle decisions. Reviewed-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Kevin Hilman <khilman@ti.com>
2012-07-11 01:13:16 +07:00
unsigned long _driver_status;
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-04 00:14:05 +07:00
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 03:48:19 +07: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-04 00:14:05 +07: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);
/* 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 03:48:45 +07:00
struct platform_device *omap_device_build(const char *pdev_name, int pdev_id,
ARM: OMAP2+: omap_device: remove obsolete pm_lats and early_device code Remove now-obsolete code from arch/arm/mach-omap2/omap_device.c. This mostly consists of removing the first attempt at device PM latency handling. This was never really used, has been replaced by the common dev_pm_qos code, and needs to go away as part of the DT conversion. Also, the early platform_device creation code has been removed, as it appears to be unused. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Kevin Hilman <khilman@deeprootsystems.com>
2013-01-26 14:48:53 +07:00
struct omap_hwmod *oh, void *pdata,
int pdata_len);
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-04 00:14:05 +07:00
ARM: OMAP: omap_device: Expose omap_device_{alloc, delete, register} Expose omap_device_{alloc, delete, register} so we can use them outside of omap_device.c. This approach allows users, which need to manipulate an archdata member of a device before it is registered, to do so. This is also useful for users who have their devices created very early so they can be used at ->reserve() time to reserve CMA memory. The immediate use case for this is to set the private iommu archdata member, which binds a device to its associated iommu controller. This way, generic code will be able to attach omap devices to their iommus, without calling any omap-specific API. With this in hand, we can further clean the existing mainline OMAP iommu driver and its mainline users, and focus on generic IOMMU approaches for future users (rpmsg/remoteproc and the upcoming generic DMA API). This patch is still considered an interim solution until DT fully materializes for omap; at that point, this functionality will be removed as DT will take care of creating the devices and configuring them correctly. Tested on OMAP4 with a generic rpmsg/remoteproc that doesn't use any omap-specific IOMMU API anymore. Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com> Signed-off-by: Kevin Hilman <khilman@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2012-02-21 00:43:29 +07:00
struct omap_device *omap_device_alloc(struct platform_device *pdev,
ARM: OMAP2+: omap_device: remove obsolete pm_lats and early_device code Remove now-obsolete code from arch/arm/mach-omap2/omap_device.c. This mostly consists of removing the first attempt at device PM latency handling. This was never really used, has been replaced by the common dev_pm_qos code, and needs to go away as part of the DT conversion. Also, the early platform_device creation code has been removed, as it appears to be unused. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Kevin Hilman <khilman@deeprootsystems.com>
2013-01-26 14:48:53 +07:00
struct omap_hwmod **ohs, int oh_cnt);
ARM: OMAP: omap_device: Expose omap_device_{alloc, delete, register} Expose omap_device_{alloc, delete, register} so we can use them outside of omap_device.c. This approach allows users, which need to manipulate an archdata member of a device before it is registered, to do so. This is also useful for users who have their devices created very early so they can be used at ->reserve() time to reserve CMA memory. The immediate use case for this is to set the private iommu archdata member, which binds a device to its associated iommu controller. This way, generic code will be able to attach omap devices to their iommus, without calling any omap-specific API. With this in hand, we can further clean the existing mainline OMAP iommu driver and its mainline users, and focus on generic IOMMU approaches for future users (rpmsg/remoteproc and the upcoming generic DMA API). This patch is still considered an interim solution until DT fully materializes for omap; at that point, this functionality will be removed as DT will take care of creating the devices and configuring them correctly. Tested on OMAP4 with a generic rpmsg/remoteproc that doesn't use any omap-specific IOMMU API anymore. Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com> Signed-off-by: Kevin Hilman <khilman@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2012-02-21 00:43:29 +07:00
void omap_device_delete(struct omap_device *od);
int omap_device_register(struct platform_device *pdev);
ARM: OMAP: omap_device: Add omap_device_get_by_hwmod_name 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>
2011-07-28 03:02:32 +07:00
struct device *omap_device_get_by_hwmod_name(const char *oh_name);
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 05:34:33 +07: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-04 00:14:05 +07:00
/* OMAP PM interface */
ARM: OMAP: change get_context_loss_count ret value to int 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>
2011-06-09 20:56:23 +07:00
int 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-04 00:14:05 +07:00
/* Other */
ARM: OMAP2+: omap_device: expose hwmod assert/deassert to omap devices This API is meant to be an interface to hwmod assert/deassert function, omap devices can call them through their platform data to control their reset lines, they are expected to know the name of the reset line they are trying to control. Signed-off-by: Omar Ramirez Luna <omar.luna@linaro.org> [paul@pwsan.com: tweaked some documentation; fixed CodingStyle issue] Signed-off-by: Paul Walmsley <paul@pwsan.com>
2012-09-24 06:28:18 +07:00
int omap_device_assert_hardreset(struct platform_device *pdev,
const char *name);
int omap_device_deassert_hardreset(struct platform_device *pdev,
const char *name);
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-04 00:14:05 +07: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 06:34:17 +07: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 03:58:51 +07:00
static inline struct omap_device *to_omap_device(struct platform_device *pdev)
{
return pdev ? pdev->archdata.od : NULL;
}
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 06:34:17 +07:00
#endif
Reference in New Issue Copy Permalink