Re: [PATCH 7/7] 4460sdp/blaze/panda: hwmod: Prevent gpio1 reset during hwmod init
Hi Tony On Thu, 30 Jun 2011, Tony Lindgren wrote: > NAK for this patch. We don't want any of this in init_early. > > The problem is with hwmod core code that wrongly assumes it > can just reset all devices. I don't think the hwmod core code has any way of knowing which devices shouldn't be reset unless the board file specifically tells it. Even if the reset happens right before the hwmod enable (as called by the device driver), the 4460 boards would still crash when the GPIO driver starts. What you suggested below should allow those omap_hwmod_no_setup_reset() calls to live in init_machine, rather than init_early. Hopefully that is acceptable? So I did a test implementation of your idea, and learned some good news and bad news. The good news is that it seems to work for the PM runtime-converted drivers. omap_hwmod_no_setup_reset() calls can go into init_machine code. We should also be able to get rid of the postsetup code in mach-omap2/io.c. The bad news is that the unused IP block reset code will reset IP blocks used by drivers that haven't been converted to use runtime PM. The hwmod core code doesn't know that those IP blocks are in use, since omap_hwmod_enable() is never called for them. The unused IP block reset code will then reset those blocks after the drivers have already probed, and the drivers are not expecting this :-) GPTIMER and HSMMC drivers are the obvious problems in terms of getting a successful boot, but DSS is another one that may cause some problems here. There are HSMMC and DSS driver PM runtime conversion patches posted, hopefully they will go into mainline soon, but there are probably some other important drivers yet to be converted or yet to be pushed. Here are some options that come to mind: 1. Wait until the driver runtime PM conversion is finished before doing anything. In the meantime, boards with IP blocks that can't be reset - N810, TI 4460 boards - will have problems. 2. Merge the lazy/unused hwmod reset code, but prevent IP blocks controlled by non-runtime PM drivers from being reset. We'd have to maintain a list of these somewhere, perhaps in some common code called by board file init_machine code. Then we'd need to redact that list as new driver runtime PM conversions complete. 3. Merge the lazy/unused hwmod reset code, but disable the unused hwmod reset code until the driver runtime PM conversion is finished. This could cause problems with driverless devices that are left configured by bootloaders or ROM code, and that problem would reoccur for each new OMAP chip. Do you have a preference as to which approach to take? > We should fix the hwmod code to lazily only reset devices as they > are enabled, and only reset unused devices with late_initcall > when we have decent debug output. And the reset of unused devices > should be possible to turn off with some kernel cmdline option. - Paul -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] OMAP: hwmod: add kernel cmdline flag to avoid resetting IP blocks during init
On some boards, it's not possible to reset certain IP blocks during
kernel initialization. Some boards connect GPIO lines to external
voltage controllers, so resetting them may cause voltage to drop on a
critical supply[1]. Other boards connect GPIO lines to reset pins on
external devices without open documentation, so if the GPIO blocks are
reset, the external devices cannot currently be reconfigured[2].
The correct way to fix these issues on OMAP is to add a
hwmod_no_setup_reset(hwmod) call to the board file, that references
the IP block that must preserve its state. This allows the OMAP core
code to reset the remaining IP blocks.
However, during initial bring-up of a new board, it may be desirable
to not reset any IP block, for ease of debugging. This patch adds a
kernel command line parameter, 'hwmod_no_setup_reset', that prevents
the OMAP hwmod code from resetting any IP block during init.
1. Nayak, Rajendra. _[PATCH 7/7] 4460sdp/blaze/panda: hwmod: Prevent
gpio1 reset during hwmod init_. 1 July 2011. E-mail to the
linux-omap@vger.kernel.org mailing list. Retrieved from
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg51992.html
2. Buesch, Michael. _Nokia n810 LCD (MIPID/blizzard) on 2.6.38_. 28
Feb 2011. E-mail to the linux-omap@vger.kernel.org mailing list.
Retrieved from http://www.spinics.net/lists/linux-omap/msg47277.html
Signed-off-by: Paul Walmsley
Cc: Benoît Cousson
Cc: Rajendra Nayak
Cc: Michael Buesch
Cc: Tony Lindgren
---
Documentation/kernel-parameters.txt |9 +
arch/arm/mach-omap2/omap_hwmod.c| 19 +--
2 files changed, 26 insertions(+), 2 deletions(-)
diff --git a/Documentation/kernel-parameters.txt
b/Documentation/kernel-parameters.txt
index fd248a31..4b1c03f 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -75,6 +75,7 @@ parameter is applicable:
NET Appropriate network support is enabled.
NUMANUMA support is enabled.
NFS Appropriate NFS support is enabled.
+ OMAPOMAP sub-architecture is enabled.
OSS OSS sound support is enabled.
PV_OPS A paravirtualized kernel is enabled.
PARIDE The ParIDE (parallel port IDE) subsystem is enabled.
@@ -872,6 +873,14 @@ bytes respectively. Such letter suffixes can also be
entirely omitted.
If specified, z/VM IUCV HVC accepts connections
from listed z/VM user IDs only.
+ hwmod_no_setup_reset
+ [OMAP] During kernel initialization,
+ prevent the subarchitecture code from resetting
+ IP blocks before the driver loads. Useful for
+ initial bring-up of boards which require some
+ bootloader configuration to be retained on GPIO or
+ other IP blocks.
+
keep_bootcon[KNL]
Do not unregister boot console at start. This is only
useful for debugging when something happens in the
window
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 293fa6c..025bf2f 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -86,7 +86,9 @@
* completely self-reliant and independent from bootloaders. This is
* to ensure a repeatable configuration, both to ensure consistent
* runtime behavior, and to make it easier for others to reproduce
- * bugs.
+ * bugs. (This behavior can be disabled while bringing up a new board
+ * by passing the kernel command line parameter
+ * 'hwmod_no_setup_reset'.)
*
* OMAP module activity states
* ---
@@ -162,6 +164,12 @@ static LIST_HEAD(omap_hwmod_list);
/* mpu_oh: used to add/remove MPU initiator from sleepdep list */
static struct omap_hwmod *mpu_oh;
+/*
+ * no_setup_reset: if true, then don't reset any hwmods on boot. This
+ * can be changed by the 'hwmod_no_setup_reset' kernel command line
+ * parameter
+ */
+static bool no_setup_reset;
/* Private functions */
@@ -1453,7 +1461,7 @@ static int _setup(struct omap_hwmod *oh, void *data)
return 0;
}
- if (!(oh->flags & HWMOD_INIT_NO_RESET)) {
+ if (!no_setup_reset && !(oh->flags & HWMOD_INIT_NO_RESET)) {
_reset(oh);
/*
@@ -1542,6 +1550,13 @@ static int __init _register(struct omap_hwmod *oh)
return 0;
}
+static int __init _cmdline_no_setup_reset(char *s)
+{
+ no_setup_reset = true;
+ return 1;
+}
+
+__setup("hwmod_no_setup_reset", _cmdline_no_setup_reset);
/* Public functions */
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 03/11] PM QoS: support the dynamic devices insertion and removal
Hi,
On Thursday, June 30, 2011, jean.pi...@newoldbits.com wrote:
> From: Jean Pihet
>
> The devices wake-up latency constraints class of PM QoS is
> storing the constraints list using the device pm_info struct.
>
> This patch adds the init and de-init of the per-device constraints
> list in order to support the dynamic insertion and removal
> of the devices in the system.
>
> Signed-off-by: Jean Pihet
The number of times this patch special cases PM_QOS_DEV_WAKEUP_LATENCY with
respect to the other PM QoS classes indicates a design issue, which kind of
corresponds with my comments on [3/11].
Thanks,
Rafael
> ---
> drivers/base/power/main.c |8 +++--
> include/linux/pm.h|1 +
> include/linux/pm_qos_params.h |2 +
> kernel/pm_qos_params.c| 70
> 4 files changed, 64 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c
> index b1fd96b..51f5526 100644
> --- a/drivers/base/power/main.c
> +++ b/drivers/base/power/main.c
> @@ -27,6 +27,7 @@
> #include
> #include
> #include
> +#include
>
> #include "../base.h"
> #include "power.h"
> @@ -96,8 +97,8 @@ void device_pm_add(struct device *dev)
> dev_name(dev->parent));
> list_add_tail(&dev->power.entry, &dpm_list);
> mutex_unlock(&dpm_list_mtx);
> - /* ToDo: call PM QoS to init the per-device wakeup latency constraints
> */
> - plist_head_init(&dev->power.wakeup_lat_plist_head, &dev->power.lock);
> + /* Call PM QoS to init the per-device wakeup latency constraints */
> + pm_qos_dev_wakeup_lat_init(dev);
> }
>
> /**
> @@ -108,7 +109,8 @@ void device_pm_remove(struct device *dev)
> {
> pr_debug("PM: Removing info for %s:%s\n",
>dev->bus ? dev->bus->name : "No Bus", dev_name(dev));
> - /* ToDo: call PM QoS to de-init the per-device wakeup latency
> constraints */
> + /* Call PM QoS to de-init the per-device wakeup latency constraints */
> + pm_qos_dev_wakeup_lat_deinit(dev);
> complete_all(&dev->power.completion);
> mutex_lock(&dpm_list_mtx);
> list_del_init(&dev->power.entry);
> diff --git a/include/linux/pm.h b/include/linux/pm.h
> index 35fe682..d9b6092 100644
> --- a/include/linux/pm.h
> +++ b/include/linux/pm.h
> @@ -464,6 +464,7 @@ struct dev_pm_info {
> void*subsys_data; /* Owned by the subsystem. */
> #endif
> struct plist_head wakeup_lat_plist_head;
> + int wakeup_lat_init;
> };
>
> extern void update_pm_runtime_accounting(struct device *dev);
> diff --git a/include/linux/pm_qos_params.h b/include/linux/pm_qos_params.h
> index e6e16cb..5b6707a 100644
> --- a/include/linux/pm_qos_params.h
> +++ b/include/linux/pm_qos_params.h
> @@ -45,4 +45,6 @@ int pm_qos_add_notifier(int class, struct notifier_block
> *notifier);
> int pm_qos_remove_notifier(int class, struct notifier_block *notifier);
> int pm_qos_request_active(struct pm_qos_request_list *req);
>
> +void pm_qos_dev_wakeup_lat_init(struct device *dev);
> +void pm_qos_dev_wakeup_lat_deinit(struct device *dev);
> #endif
> diff --git a/kernel/pm_qos_params.c b/kernel/pm_qos_params.c
> index d61c8e5..6f25ccb 100644
> --- a/kernel/pm_qos_params.c
> +++ b/kernel/pm_qos_params.c
> @@ -275,11 +275,21 @@ void pm_qos_add_request(struct pm_qos_request_list
> *pm_qos_req,
> struct pm_qos_object *o = pm_qos_array[pm_qos_params->class];
> int new_value;
>
> - if ((pm_qos_params->class != PM_QOS_DEV_WAKEUP_LATENCY) &&
> - (pm_qos_request_active(pm_qos_req))) {
> - WARN(1, KERN_ERR "pm_qos_add_request() called for already "
> - "added request\n");
> - return;
> + if (pm_qos_params->class == PM_QOS_DEV_WAKEUP_LATENCY) {
> + if (!pm_qos_params->dev) {
> + WARN(1, KERN_ERR "pm_qos_add_request() called for "
> + "invalid device\n");
> + return;
> + }
> + /* Silently return if the device is being released */
> + if (!pm_qos_params->dev->power.wakeup_lat_init)
> + return;
> + } else {
> + if (pm_qos_request_active(pm_qos_req)) {
> + WARN(1, KERN_ERR "pm_qos_add_request() called for "
> + "already added request\n");
> + return;
> + }
> }
>
> if (pm_qos_params->value == PM_QOS_DEFAULT_VALUE)
> @@ -312,11 +322,16 @@ void pm_qos_update_request(struct pm_qos_request_list
> *pm_qos_req,
> if (!pm_qos_req) /*guard against callers passing in null */
> return;
>
> - if ((pm_qos_req->class != PM_QOS_DEV_WAKEUP_LATENCY) &&
> - (!pm_qos_request_active(pm_qos_req))) {
> - WARN(1, KERN_ERR "pm_qos_update_request() called for unknown "
> - "object
Re: [PATCH 02/11] PM: extend PM QoS with per-device wake-up constraints
Hi,
On Thursday, June 30, 2011, jean.pi...@newoldbits.com wrote:
> From: Jean Pihet
>
> - add a new PM QoS class PM_QOS_DEV_WAKEUP_LATENCY for device wake-up
> constraints. Due to the per-device nature of the new class the constraints
> list is stored inside the device dev_pm_info struct instead of the internal
> per-class constraints lists.
I think PM_QOS_DEV_LATENCY might be a better name.
> The new class is only available from kernel drivers and so is not exported
> to user space.
It should be available to user space, however, because in many cases drivers
simply have no idea what values to use (after all, the use decides if he
wants to trade worse video playback quality for better battery life, for
example).
> The new class is used to put constraints on given devices in the system
> while the existing PM_QOS_CPU_DMA_LATENCY class is used by cpuidle to
> determine the next MPU subsystem state.
>
> - make the pm_qos_add_request API more generic by using a struct
> pm_qos_parameters parameter
>
> - the notification mechanism now passes the constraint request struct ptr
> in order for the notifier callback to have access to the full set of
> constraint data, e.g. the struct device ptr
>
> - update the pm_qos_add_request callers to the generic API
>
> - minor clean-ups and rename of struct fields
>
> Signed-off-by: Jean Pihet
Well, I think this patch attempts to do too many things at a time, which
makes it somewhat hard to comprehend at first glance. I'd stronly suggest
splitting it into a series of patches that first modify the existing API
to make it suitable for the "real" changes and second introduce those
"real" chages in the most straightforward way possible.
> ---
> arch/arm/plat-omap/i2c.c | 20
> drivers/i2c/busses/i2c-omap.c | 35 ---
> drivers/media/video/via-camera.c |5 +-
> drivers/net/e1000e/netdev.c|9 +-
> drivers/net/wireless/ipw2x00/ipw2100.c |6 +-
> include/linux/pm_qos_params.h | 40 +---
> kernel/pm_qos_params.c | 185
> +++-
Hmm. If you're at it, what about moving pm_qos_params.c to kernel/power
and changing its name to pm_qos.c beforehand?
The header might be called pm_qos.h too, BTW.
> sound/core/pcm_native.c|8 +-
> 8 files changed, 177 insertions(+), 131 deletions(-)
>
...
> diff --git a/include/linux/pm_qos_params.h b/include/linux/pm_qos_params.h
> index a7d87f9..e6e16cb 100644
> --- a/include/linux/pm_qos_params.h
> +++ b/include/linux/pm_qos_params.h
> @@ -8,31 +8,41 @@
> #include
> #include
>
> -#define PM_QOS_RESERVED 0
> -#define PM_QOS_CPU_DMA_LATENCY 1
> -#define PM_QOS_NETWORK_LATENCY 2
> -#define PM_QOS_NETWORK_THROUGHPUT 3
> +#define PM_QOS_RESERVED 0
> +#define PM_QOS_CPU_DMA_LATENCY 1
> +#define PM_QOS_DEV_WAKEUP_LATENCY 2
> +#define PM_QOS_NETWORK_LATENCY 3
> +#define PM_QOS_NETWORK_THROUGHPUT 4
>
> -#define PM_QOS_NUM_CLASSES 4
> -#define PM_QOS_DEFAULT_VALUE -1
> +#define PM_QOS_NUM_CLASSES 5
> +#define PM_QOS_DEFAULT_VALUE -1
>
> -#define PM_QOS_CPU_DMA_LAT_DEFAULT_VALUE (2000 * USEC_PER_SEC)
> -#define PM_QOS_NETWORK_LAT_DEFAULT_VALUE (2000 * USEC_PER_SEC)
> -#define PM_QOS_NETWORK_THROUGHPUT_DEFAULT_VALUE 0
> +#define PM_QOS_CPU_DMA_LAT_DEFAULT_VALUE(2000 * USEC_PER_SEC)
> +#define PM_QOS_DEV_WAKEUP_LAT_DEFAULT_VALUE 0
> +#define PM_QOS_NETWORK_LAT_DEFAULT_VALUE(2000 * USEC_PER_SEC)
> +#define PM_QOS_NETWORK_THROUGHPUT_DEFAULT_VALUE 0
>
> struct pm_qos_request_list {
> struct plist_node list;
> - int pm_qos_class;
> + int class;
> + struct device *dev;
> };
>
> -void pm_qos_add_request(struct pm_qos_request_list *l, int pm_qos_class, s32
> value);
> +struct pm_qos_parameters {
> + int class;
> + struct device *dev;
> + s32 value;
> +};
> +
> +void pm_qos_add_request(struct pm_qos_request_list *l,
> + struct pm_qos_parameters *params);
> void pm_qos_update_request(struct pm_qos_request_list *pm_qos_req,
> - s32 new_value);
> +s32 new_value);
> void pm_qos_remove_request(struct pm_qos_request_list *pm_qos_req);
>
> -int pm_qos_request(int pm_qos_class);
> -int pm_qos_add_notifier(int pm_qos_class, struct notifier_block *notifier);
> -int pm_qos_remove_notifier(int pm_qos_class, struct notifier_block
> *notifier);
> +int pm_qos_request(int class);
> +int pm_qos_add_notifier(int class, struct notifier_block *notifier);
> +int pm_qos_remove_notifier(int class, struct notifier_block *notifier);
> int pm_qos_request_active(struct pm_qos_request_list *req);
>
> #endif
> diff --git a/kernel/pm_qos_params.c b/kernel/pm_qos_params.c
> index 6824ca7..d61c8e5 100644
> --- a/kernel/pm_qos_params.c
> +++ b/kernel/pm_qos_params.c
> @@ -60,7 +60,7 @@ enum pm_qos
Re: [PATCH 01/11] PM: add a per-device wake-up latency constraints plist
Hi,
On Thursday, June 30, 2011, jean.pi...@newoldbits.com wrote:
> From: Jean Pihet
>
> Add the field wakeup_lat_plist_head in the struct dev_pm_info
> and the initialization of the plist in device_pm_init.
>
> This enables the implementation of per-device constraints in
> PM QoS.
>
> Signed-off-by: Jean Pihet
> ---
> drivers/base/power/main.c |3 +++
> include/linux/pm.h|2 ++
> 2 files changed, 5 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c
> index aa632020..b1fd96b 100644
> --- a/drivers/base/power/main.c
> +++ b/drivers/base/power/main.c
> @@ -96,6 +96,8 @@ void device_pm_add(struct device *dev)
> dev_name(dev->parent));
> list_add_tail(&dev->power.entry, &dpm_list);
> mutex_unlock(&dpm_list_mtx);
> + /* ToDo: call PM QoS to init the per-device wakeup latency constraints
> */
> + plist_head_init(&dev->power.wakeup_lat_plist_head, &dev->power.lock);
> }
>
> /**
> @@ -106,6 +108,7 @@ void device_pm_remove(struct device *dev)
> {
> pr_debug("PM: Removing info for %s:%s\n",
>dev->bus ? dev->bus->name : "No Bus", dev_name(dev));
> + /* ToDo: call PM QoS to de-init the per-device wakeup latency
> constraints */
> complete_all(&dev->power.completion);
> mutex_lock(&dpm_list_mtx);
> list_del_init(&dev->power.entry);
> diff --git a/include/linux/pm.h b/include/linux/pm.h
> index 3160648..35fe682 100644
> --- a/include/linux/pm.h
> +++ b/include/linux/pm.h
> @@ -22,6 +22,7 @@
> #define _LINUX_PM_H
>
> #include
> +#include
> #include
> #include
> #include
> @@ -462,6 +463,7 @@ struct dev_pm_info {
> unsigned long accounting_timestamp;
> void*subsys_data; /* Owned by the subsystem. */
> #endif
> + struct plist_head wakeup_lat_plist_head;
> };
Please use a better name. I mean, relly, the type implies that this is a
plist head, so that doesn't need to appear in the field name too. Also,
the name is confusing, because "wakeup" may mean a couple of different things
and it's not entirely clear what "lat" stands for. So, I'd prefer something
like
+ struct plist_head latency_constraints;
or perhaps you can invent something even better.
>
> extern void update_pm_runtime_accounting(struct device *dev);
>
Thanks,
Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 00/11] PM QoS: add a per-device wake-up latency constraint class
Hi, On Thursday, June 30, 2011, jean.pi...@newoldbits.com wrote: > From: Jean Pihet > > This patch set is in an RFC state, for review and comments. First off, I'm sorry I couldn't review the patchset earlier. > In order to implement the new class in PM QoS the following changes have been > made: > > 1. Add a new PM QoS class for device wake-up constraints > (PM_QOS_DEV_WAKEUP_LATENCY). > Due to the per-device nature of the new class the constraints lists are stored > inside the device dev_pm_info struct instead of the internal per-class > constraints lists. > The new class is only available from kernel drivers and so is not exported to > user space. Have you considered a design in which multiple devices may use the same list of constraints? It seems plausible that the constraints will be the same, for example, for all Ethernet adapters in the system, in which case it will be wasteful to duplicate the list of constraints for each of them. > 2. Added a notification of device insertion/removal from the device PM > framework > to PM QoS. > This allows to init/de-init the per-device constraints list upon device > insertion > and removal. > RFC state for comments and review, barely tested I need to have a look at the details, but in principle this means that the per-device lists will be usable only after the devices have been registered. In particular, this means that it will only be possible to add new constraints after registering the device, which may be too late for some use cases. > 3. Make the pm_qos_add_request API more generic by using a > struct pm_qos_parameters parameter. This allows easy extension in the future. > > 4. Upon a change of the strongest constraint in the PM_QOS_DEV_WAKEUP_LATENCY > class a notification chain mechanism is used to take action on the system. > This is the proposed way to have PM QoS and the platform dependant code to > interact with each other, cf. 4 below. I guess you mean 5.? I think we will need something in addition to the notifier here. For example, I wouldn't like any core code, like runtime PM or cpuidle, to have to register a notifier with PM QoS. > The notification mechanism now passes the constraint request struct ptr in > order for the notifier callback to have access to the full set of constraint > data, e.g. the struct device ptr. > > 5. cpuidle interaction with the OMAP3 cpuidle handler > Since cpuidle is a CPU centric framework it decides the MPU next power state > based on the MPU exit_latency and target_residency figures. > > The rest of the power domains get their next power state programmed from > the PM_QOS_DEV_WAKEUP_LATENCY class of the PM QoS framework, via the device > wake-up latency constraints. > > Note: the exit_latency and target_residency figures of the MPU include the MPU > itself and the peripherals needed for the MPU to execute instructions (e.g. > main memory, caches, IRQ controller, MMU etc). > Some of those peripherals can belong to other power domains than the MPU > subsystem and so the corresponding latencies must be included in those > figures. > > 6. Update the pm_qos_add_request callers to the generic API > > 7. Minor clean-ups and rename of struct fields > > Questions: > 1. How to retrieve the device ptr from a given device driver in order to add > a constraint on it? > 2. The device struct has recently been extended with the power domain > information. Can this be used to apply the constraints on power domains? Yes, it can in principle, but that will require some work. > On-going developments, patches in preparation: > 1. write Documentation for the new PM QoS class I'd wait with that until the code has settled. > 2. validate the constraints framework on OMAP4 HW (done on OMAP3) > 3. refine the power domains wake-up latency and the cpuidle figures > > Based on the master branch of the linux-omap git tree (3.0.0-rc3). Compile > tested using OMAP and x86 generic defconfigs. > Tested on OMAP3 Beagleboard (ES2.x) with full RETention and OFF modes. More detailed comments will follow. Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP4: OPP: add OMAP4460 definitions
On Sat, Jul 2, 2011 at 07:20, Vishwanath BS wrote:
> Add OMAP4460 OPP definitions for voltage and frequencies based on
> OMAP4460 ES1.0 DM Operating Condition Addendum Version 0.1
>
> The following exceptions are present:
> * Smartreflex support is still on experimental mode: the gains and min
> limits are currently pending characterization data. Currently OMAP4430 values
> are used.
> * Efuse offset for core OPP100-OV setting is not clear in documentation.
> * IVA OPPs beyond OPP100 are disabled due to the delta between max OMAP4460
> current requirements and Phoenix Max supply on VCORE2 in the default
> configuration - boards which have supply which can support this should
> explicitly call opp_enable and enable the same.
> * MPU OPPs > OPPTURBO can easily be detected using a efuse burnt - currently
> disabled pending clock changes to support DCC feature.
>
> Pathch is generated against Patch series "[PATCH v2 0/6] OMAP4: Add 4460 base
> support" from Rajendra.
Spell check and this line does not belong to the commit message
Regards,
Nishanth Menon
>
> [n...@ti.com: cleanups and updates from Datamanual]
> Signed-off-by: Nishanth Menon
> Signed-off-by: Vishwanath BS
> ---
> arch/arm/mach-omap2/control.h | 1 +
> arch/arm/mach-omap2/omap_opp_data.h | 9 ++-
> arch/arm/mach-omap2/opp4xxx_data.c | 96
> ++---
> arch/arm/mach-omap2/voltagedomains44xx_data.c | 14 +++-
> 4 files changed, 105 insertions(+), 15 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/control.h b/arch/arm/mach-omap2/control.h
> index a016c8b..a41b9a7 100644
> --- a/arch/arm/mach-omap2/control.h
> +++ b/arch/arm/mach-omap2/control.h
> @@ -195,6 +195,7 @@
> #define OMAP44XX_CONTROL_FUSE_MPU_OPPNITRO 0x249
> #define OMAP44XX_CONTROL_FUSE_CORE_OPP50 0x254
> #define OMAP44XX_CONTROL_FUSE_CORE_OPP100 0x257
> +#define OMAP44XX_CONTROL_FUSE_CORE_OPP100OV 0x25A
>
> /* AM35XX only CONTROL_GENERAL register offsets */
> #define AM35XX_CONTROL_MSUSPENDMUX_6 (OMAP2_CONTROL_GENERAL + 0x0038)
> diff --git a/arch/arm/mach-omap2/omap_opp_data.h
> b/arch/arm/mach-omap2/omap_opp_data.h
> index c784c12..18a750e 100644
> --- a/arch/arm/mach-omap2/omap_opp_data.h
> +++ b/arch/arm/mach-omap2/omap_opp_data.h
> @@ -89,8 +89,11 @@ extern struct omap_volt_data omap34xx_vddcore_volt_data[];
> extern struct omap_volt_data omap36xx_vddmpu_volt_data[];
> extern struct omap_volt_data omap36xx_vddcore_volt_data[];
>
> -extern struct omap_volt_data omap44xx_vdd_mpu_volt_data[];
> -extern struct omap_volt_data omap44xx_vdd_iva_volt_data[];
> -extern struct omap_volt_data omap44xx_vdd_core_volt_data[];
> +extern struct omap_volt_data omap443x_vdd_mpu_volt_data[];
> +extern struct omap_volt_data omap443x_vdd_iva_volt_data[];
> +extern struct omap_volt_data omap443x_vdd_core_volt_data[];
> +extern struct omap_volt_data omap446x_vdd_mpu_volt_data[];
> +extern struct omap_volt_data omap446x_vdd_iva_volt_data[];
> +extern struct omap_volt_data omap446x_vdd_core_volt_data[];
>
> #endif /* __ARCH_ARM_MACH_OMAP2_OMAP_OPP_DATA_H */
> diff --git a/arch/arm/mach-omap2/opp4xxx_data.c
> b/arch/arm/mach-omap2/opp4xxx_data.c
> index 2293ba2..8c285e4 100644
> --- a/arch/arm/mach-omap2/opp4xxx_data.c
> +++ b/arch/arm/mach-omap2/opp4xxx_data.c
> @@ -1,7 +1,7 @@
> /*
> * OMAP4 OPP table definitions.
> *
> - * Copyright (C) 2010 Texas Instruments Incorporated - http://www.ti.com/
> + * Copyright (C) 2010-2011 Texas Instruments Incorporated -
> http://www.ti.com/
> * Nishanth Menon
> * Kevin Hilman
> * Thara Gopinath
> @@ -36,7 +36,7 @@
> #define OMAP4430_VDD_MPU_OPPTURBO_UV 1313000
> #define OMAP4430_VDD_MPU_OPPNITRO_UV 1375000
>
> -struct omap_volt_data omap44xx_vdd_mpu_volt_data[] = {
> +struct omap_volt_data omap443x_vdd_mpu_volt_data[] = {
> VOLT_DATA_DEFINE(OMAP4430_VDD_MPU_OPP50_UV,
> OMAP44XX_CONTROL_FUSE_MPU_OPP50, 0xf4, 0x0c),
> VOLT_DATA_DEFINE(OMAP4430_VDD_MPU_OPP100_UV,
> OMAP44XX_CONTROL_FUSE_MPU_OPP100, 0xf9, 0x16),
> VOLT_DATA_DEFINE(OMAP4430_VDD_MPU_OPPTURBO_UV,
> OMAP44XX_CONTROL_FUSE_MPU_OPPTURBO, 0xfa, 0x23),
> @@ -48,7 +48,7 @@ struct omap_volt_data omap44xx_vdd_mpu_volt_data[] = {
> #define OMAP4430_VDD_IVA_OPP100_UV 1188000
> #define OMAP4430_VDD_IVA_OPPTURBO_UV 130
>
> -struct omap_volt_data omap44xx_vdd_iva_volt_data[] = {
> +struct omap_volt_data omap443x_vdd_iva_volt_data[] = {
> VOLT_DATA_DEFINE(OMAP4430_VDD_IVA_OPP50_UV,
> OMAP44XX_CONTROL_FUSE_IVA_OPP50, 0xf4, 0x0c),
> VOLT_DATA_DEFINE(OMAP4430_VDD_IVA_OPP100_UV,
> OMAP44XX_CONTROL_FUSE_IVA_OPP100, 0xf9, 0x16),
> VOLT_DATA_DEFINE(OMAP4430_VDD_IVA_OPPTURBO_UV,
> OMAP44XX_CONTROL_FUSE_IVA_OPPTURBO, 0xfa, 0x23),
> @@ -58,14 +58,14 @@ struct omap_volt_data omap44xx_vdd_iva_volt_data[] = {
> #define OMAP4430_VDD_CORE_OPP50_UV 1025000
> #define OMAP4430_VDD_CORE_OPP100_UV
Re: [PATCH 2/2 v4] OMAP2+: hwmod: Add API to check IO PAD wakeup status
On Sat, 2 Jul 2011, Govindraj.R wrote: > +int omap_hmwod_pad_get_wakeup_status(struct omap_hwmod *oh) ^ should be "hwmod" - Paul -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] OMAP4: OPP: add OMAP4460 definitions
Add OMAP4460 OPP definitions for voltage and frequencies based on
OMAP4460 ES1.0 DM Operating Condition Addendum Version 0.1
The following exceptions are present:
* Smartreflex support is still on experimental mode: the gains and min
limits are currently pending characterization data. Currently OMAP4430 values
are used.
* Efuse offset for core OPP100-OV setting is not clear in documentation.
* IVA OPPs beyond OPP100 are disabled due to the delta between max OMAP4460
current requirements and Phoenix Max supply on VCORE2 in the default
configuration - boards which have supply which can support this should
explicitly call opp_enable and enable the same.
* MPU OPPs > OPPTURBO can easily be detected using a efuse burnt - currently
disabled pending clock changes to support DCC feature.
Pathch is generated against Patch series "[PATCH v2 0/6] OMAP4: Add 4460 base
support" from Rajendra.
[n...@ti.com: cleanups and updates from Datamanual]
Signed-off-by: Nishanth Menon
Signed-off-by: Vishwanath BS
---
arch/arm/mach-omap2/control.h |1 +
arch/arm/mach-omap2/omap_opp_data.h |9 ++-
arch/arm/mach-omap2/opp4xxx_data.c| 96 ++---
arch/arm/mach-omap2/voltagedomains44xx_data.c | 14 +++-
4 files changed, 105 insertions(+), 15 deletions(-)
diff --git a/arch/arm/mach-omap2/control.h b/arch/arm/mach-omap2/control.h
index a016c8b..a41b9a7 100644
--- a/arch/arm/mach-omap2/control.h
+++ b/arch/arm/mach-omap2/control.h
@@ -195,6 +195,7 @@
#define OMAP44XX_CONTROL_FUSE_MPU_OPPNITRO 0x249
#define OMAP44XX_CONTROL_FUSE_CORE_OPP50 0x254
#define OMAP44XX_CONTROL_FUSE_CORE_OPP100 0x257
+#define OMAP44XX_CONTROL_FUSE_CORE_OPP100OV0x25A
/* AM35XX only CONTROL_GENERAL register offsets */
#define AM35XX_CONTROL_MSUSPENDMUX_6(OMAP2_CONTROL_GENERAL + 0x0038)
diff --git a/arch/arm/mach-omap2/omap_opp_data.h
b/arch/arm/mach-omap2/omap_opp_data.h
index c784c12..18a750e 100644
--- a/arch/arm/mach-omap2/omap_opp_data.h
+++ b/arch/arm/mach-omap2/omap_opp_data.h
@@ -89,8 +89,11 @@ extern struct omap_volt_data omap34xx_vddcore_volt_data[];
extern struct omap_volt_data omap36xx_vddmpu_volt_data[];
extern struct omap_volt_data omap36xx_vddcore_volt_data[];
-extern struct omap_volt_data omap44xx_vdd_mpu_volt_data[];
-extern struct omap_volt_data omap44xx_vdd_iva_volt_data[];
-extern struct omap_volt_data omap44xx_vdd_core_volt_data[];
+extern struct omap_volt_data omap443x_vdd_mpu_volt_data[];
+extern struct omap_volt_data omap443x_vdd_iva_volt_data[];
+extern struct omap_volt_data omap443x_vdd_core_volt_data[];
+extern struct omap_volt_data omap446x_vdd_mpu_volt_data[];
+extern struct omap_volt_data omap446x_vdd_iva_volt_data[];
+extern struct omap_volt_data omap446x_vdd_core_volt_data[];
#endif /* __ARCH_ARM_MACH_OMAP2_OMAP_OPP_DATA_H */
diff --git a/arch/arm/mach-omap2/opp4xxx_data.c
b/arch/arm/mach-omap2/opp4xxx_data.c
index 2293ba2..8c285e4 100644
--- a/arch/arm/mach-omap2/opp4xxx_data.c
+++ b/arch/arm/mach-omap2/opp4xxx_data.c
@@ -1,7 +1,7 @@
/*
* OMAP4 OPP table definitions.
*
- * Copyright (C) 2010 Texas Instruments Incorporated - http://www.ti.com/
+ * Copyright (C) 2010-2011 Texas Instruments Incorporated - http://www.ti.com/
* Nishanth Menon
* Kevin Hilman
* Thara Gopinath
@@ -36,7 +36,7 @@
#define OMAP4430_VDD_MPU_OPPTURBO_UV 1313000
#define OMAP4430_VDD_MPU_OPPNITRO_UV 1375000
-struct omap_volt_data omap44xx_vdd_mpu_volt_data[] = {
+struct omap_volt_data omap443x_vdd_mpu_volt_data[] = {
VOLT_DATA_DEFINE(OMAP4430_VDD_MPU_OPP50_UV,
OMAP44XX_CONTROL_FUSE_MPU_OPP50, 0xf4, 0x0c),
VOLT_DATA_DEFINE(OMAP4430_VDD_MPU_OPP100_UV,
OMAP44XX_CONTROL_FUSE_MPU_OPP100, 0xf9, 0x16),
VOLT_DATA_DEFINE(OMAP4430_VDD_MPU_OPPTURBO_UV,
OMAP44XX_CONTROL_FUSE_MPU_OPPTURBO, 0xfa, 0x23),
@@ -48,7 +48,7 @@ struct omap_volt_data omap44xx_vdd_mpu_volt_data[] = {
#define OMAP4430_VDD_IVA_OPP100_UV 1188000
#define OMAP4430_VDD_IVA_OPPTURBO_UV 130
-struct omap_volt_data omap44xx_vdd_iva_volt_data[] = {
+struct omap_volt_data omap443x_vdd_iva_volt_data[] = {
VOLT_DATA_DEFINE(OMAP4430_VDD_IVA_OPP50_UV,
OMAP44XX_CONTROL_FUSE_IVA_OPP50, 0xf4, 0x0c),
VOLT_DATA_DEFINE(OMAP4430_VDD_IVA_OPP100_UV,
OMAP44XX_CONTROL_FUSE_IVA_OPP100, 0xf9, 0x16),
VOLT_DATA_DEFINE(OMAP4430_VDD_IVA_OPPTURBO_UV,
OMAP44XX_CONTROL_FUSE_IVA_OPPTURBO, 0xfa, 0x23),
@@ -58,14 +58,14 @@ struct omap_volt_data omap44xx_vdd_iva_volt_data[] = {
#define OMAP4430_VDD_CORE_OPP50_UV 1025000
#define OMAP4430_VDD_CORE_OPP100_UV120
-struct omap_volt_data omap44xx_vdd_core_volt_data[] = {
+struct omap_volt_data omap443x_vdd_core_volt_data[] = {
VOLT_DATA_DEFINE(OMAP4430_VDD_CORE_OPP50_UV,
OMAP44XX_CONTROL_FUSE_CORE_OPP50, 0xf4, 0x0c),
VOLT_DATA_DEFINE(OMAP4430_VDD_CORE_OPP100_UV,
OMAP44XX_CONTROL_FUSE_CORE_OPP
Re: [PATCHv4 7/9] OMAP: hwmod: enable / disable pad wakeups for a module dynamically
On Sat, Jul 2, 2011 at 3:48 AM, Kevin Hilman wrote: > Tero Kristo writes: > >> PRCM chain interrupt registration is done now as part of >> omap_hwmod_enable_wakeup() and omap_hwmod_disable_wakeup() calls. This >> allows module ISR:s to be called when the module is idle but an IO_PAD >> event is detected on the module input pads. > > These functions are the enable/disable for module-level wakeups, you > need to use the proposed enable/disable functions for IO ring wakeups as > proposed in the patch from Govindraj[1]. > Posted a new version rebased on 3.0-rc5 https://patchwork.kernel.org/patch/940332/ https://patchwork.kernel.org/patch/940322/ -- Thanks, Govindraj.R > I'm hoping that patch will be queued for v3.1, but will wait for Paul's > comments on that patch. > > Kevin > -- > To unsubscribe from this list: send the line "unsubscribe linux-omap" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2 v4] OMAP2+: hwmod: Add API to check IO PAD wakeup status
Add API to determine IO-PAD wakeup event status for a given
hwmod dynamic_mux pad.
Signed-off-by: Govindraj.R
---
arch/arm/mach-omap2/mux.c| 30 ++
arch/arm/mach-omap2/mux.h| 13 +++
arch/arm/mach-omap2/omap_hwmod.c |7 ++
arch/arm/plat-omap/include/plat/omap_hwmod.h |1 +
4 files changed, 51 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
index c7fb22a..50ee806 100644
--- a/arch/arm/mach-omap2/mux.c
+++ b/arch/arm/mach-omap2/mux.c
@@ -351,6 +351,36 @@ err1:
return NULL;
}
+/**
+ * omap_hwmod_mux_get_wake_status - omap hwmod check pad wakeup
+ * @hmux: Pads for a hwmod
+ *
+ * Gets the wakeup status of given pad from omap-hwmod.
+ * Returns true if wakeup event is set for pad else false
+ * if wakeup is not occured or pads are not avialable.
+ */
+bool omap_hwmod_mux_get_wake_status(struct omap_hwmod_mux_info *hmux)
+{
+ int i;
+ unsigned int val;
+ u8 ret = false;
+
+ for (i = 0; i < hmux->nr_pads; i++) {
+ struct omap_device_pad *pad = &hmux->pads[i];
+
+ if (pad->flags & OMAP_DEVICE_PAD_WAKEUP) {
+ val = omap_mux_read(pad->partition,
+ pad->mux->reg_offset);
+ if (val & OMAP_WAKEUP_EVENT) {
+ ret = true;
+ break;
+ }
+ }
+ }
+
+ return ret;
+}
+
/* Assumes the calling function takes care of locking */
void omap_hwmod_mux(struct omap_hwmod_mux_info *hmux, u8 state)
{
diff --git a/arch/arm/mach-omap2/mux.h b/arch/arm/mach-omap2/mux.h
index 2132308..8b2150a 100644
--- a/arch/arm/mach-omap2/mux.h
+++ b/arch/arm/mach-omap2/mux.h
@@ -225,8 +225,21 @@ omap_hwmod_mux_init(struct omap_device_pad *bpads, int
nr_pads);
*/
void omap_hwmod_mux(struct omap_hwmod_mux_info *hmux, u8 state);
+/**
+ * omap_hwmod_mux_get_wake_status - omap hwmod check pad wakeup
+ * @hmux: Pads for a hwmod
+ *
+ * Called only from omap_hwmod.c, do not use.
+ */
+bool omap_hwmod_mux_get_wake_status(struct omap_hwmod_mux_info *hmux);
#else
+static inline bool
+omap_hwmod_mux_get_wake_status(struct omap_hwmod_mux_info *hmux)
+{
+ return 0;
+}
+
static inline int omap_mux_init_gpio(int gpio, int val)
{
return 0;
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 3b28e0a..f9495fe 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -2428,3 +2428,10 @@ int omap_hwmod_no_setup_reset(struct omap_hwmod *oh)
return 0;
}
+
+int omap_hmwod_pad_get_wakeup_status(struct omap_hwmod *oh)
+{
+ if (oh && oh->mux)
+ return omap_hwmod_mux_get_wake_status(oh->mux);
+ return -EINVAL;
+}
diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h
b/arch/arm/plat-omap/include/plat/omap_hwmod.h
index 1adea9c..da6ab5c 100644
--- a/arch/arm/plat-omap/include/plat/omap_hwmod.h
+++ b/arch/arm/plat-omap/include/plat/omap_hwmod.h
@@ -602,6 +602,7 @@ u32 omap_hwmod_get_context_loss_count(struct omap_hwmod
*oh);
int omap_hwmod_no_setup_reset(struct omap_hwmod *oh);
+int omap_hmwod_pad_get_wakeup_status(struct omap_hwmod *oh);
/*
* Chip variant-specific hwmod init routines - XXX should be converted
* to use initcalls once the initial boot ordering is straightened out
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2 v4] OMAP2+: hwmod: Add API to enable IO ring wakeup.
Add API to enable IO pad wakeup capability based on mux dynamic pad and
wake_up enable flag available from hwmod_mux initialization.
Use the wakeup_enable flag and enable wakeup capability
for the given pads. Wakeup capability will be enabled/disabled
during hmwod idle transition based on whether wakeup_flag is
set or cleared.
Map the enable/disable pad wakeup API's to hwmod_wakeup_enable/disable.
Signed-off-by: Govindraj.R
---
arch/arm/mach-omap2/omap_hwmod.c | 59 ++
1 files changed, 59 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 293fa6c..3b28e0a 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -1770,6 +1770,34 @@ static int __init omap_hwmod_setup_all(void)
core_initcall(omap_hwmod_setup_all);
/**
+ * omap_hwmod_set_ioring_wakeup - enable io pad wakeup flag.
+ * @oh: struct omap_hwmod *
+ * @set: bool value indicating to set or clear wakeup status.
+ *
+ * Set or Clear wakeup flag for the io_pad.
+ */
+static int omap_hwmod_set_ioring_wakeup(struct omap_hwmod *oh, bool set_wake)
+{
+ struct omap_device_pad *pad;
+ int ret = -EINVAL, j;
+
+ if (oh->mux && oh->mux->enabled) {
+ for (j = 0; j < oh->mux->nr_pads_dynamic; j++) {
+ pad = oh->mux->pads_dynamic[j];
+ if (pad->flags & OMAP_DEVICE_PAD_WAKEUP) {
+ if (set_wake)
+ pad->idle |= OMAP_WAKEUP_EN;
+ else
+ pad->idle &= ~OMAP_WAKEUP_EN;
+ ret = 0;
+ }
+ }
+ }
+
+ return ret;
+}
+
+/**
* omap_hwmod_enable - enable an omap_hwmod
* @oh: struct omap_hwmod *
*
@@ -2097,6 +2125,35 @@ int omap_hwmod_del_initiator_dep(struct omap_hwmod *oh,
{
return _del_initiator_dep(oh, init_oh);
}
+/**
+ * omap_hwmod_enable_ioring_wakeup - Set wakeup flag for iopad.
+ * @oh: struct omap_hwmod *
+ *
+ * Traverse through dynamic pads, if pad is enabled then
+ * set wakeup enable bit flag for the mux pin. Wakeup pad bit
+ * will be set during hwmod idle transistion.
+ * Return error if pads are not enabled or not available.
+ */
+int omap_hwmod_enable_ioring_wakeup(struct omap_hwmod *oh)
+{
+ /* Enable pad wake-up capability */
+ return omap_hwmod_set_ioring_wakeup(oh, true);
+}
+
+/**
+ * omap_hwmod_disable_ioring_wakeup - Clear wakeup flag for iopad.
+ * @oh: struct omap_hwmod *
+ *
+ * Traverse through dynamic pads, if pad is enabled then
+ * clear wakeup enable bit flag for the mux pin. Wakeup pad bit
+ * will be set during hwmod idle transistion.
+ * Return error if pads are not enabled or not available.
+ */
+int omap_hwmod_disable_ioring_wakeup(struct omap_hwmod *oh)
+{
+ /* Disable pad wakeup capability */
+ return omap_hwmod_set_ioring_wakeup(oh, false);
+}
/**
* omap_hwmod_enable_wakeup - allow device to wake up the system
@@ -2123,6 +2180,7 @@ int omap_hwmod_enable_wakeup(struct omap_hwmod *oh)
v = oh->_sysc_cache;
_enable_wakeup(oh, &v);
_write_sysconfig(v, oh);
+ omap_hwmod_enable_ioring_wakeup(oh);
spin_unlock_irqrestore(&oh->_lock, flags);
return 0;
@@ -2153,6 +2211,7 @@ int omap_hwmod_disable_wakeup(struct omap_hwmod *oh)
v = oh->_sysc_cache;
_disable_wakeup(oh, &v);
_write_sysconfig(v, oh);
+ omap_hwmod_disable_ioring_wakeup(oh);
spin_unlock_irqrestore(&oh->_lock, flags);
return 0;
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2 v4] OMAP2+: hwmod: Add hwmod's API's for pad wakeup
Add two API's to set IO Pad wakeup capability based on hwmod mux pins available and also to check the status of IO Pad wakeup event. This two patches are separated from uart_runtime patches posted earlier and uart_runtime adaptation relies on these two API's. Rebased on 3.0-rc5 Changes from v3: --- Hooked up enable/disable io-ring to hwmod enable/disable Changes from v2: --- http://www.mail-archive.com/linux-omap@vger.kernel.org/msg49194.html Changes from v1: --- http://www.mail-archive.com/linux-omap@vger.kernel.org/msg49141.html Reference to Discussion: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg49000.html http://www.mail-archive.com/linux-omap@vger.kernel.org/msg49001.html Govindraj.R (2): OMAP2+: hwmod: Add API to enable IO ring wakeup. OMAP2+: hwmod: Add API to check IO PAD wakeup status arch/arm/mach-omap2/mux.c| 30 arch/arm/mach-omap2/mux.h| 13 + arch/arm/mach-omap2/omap_hwmod.c | 66 ++ arch/arm/plat-omap/include/plat/omap_hwmod.h |1 + 4 files changed, 110 insertions(+), 0 deletions(-) -- 1.7.4.1 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 17/18] OMAP4: hwmod data: Modify DSS opt clocks
On Sat, 2011-07-02 at 12:13 +0300, Tomi Valkeinen wrote: > Hi Benoit, > > On Fri, 2011-07-01 at 22:41 +0200, Benoit Cousson wrote: > > From: Tomi Valkeinen > > > > Add missing DSS optional clocks to HWMOD data for OMAP4xxx. > > > > Add HWMOD_CONTROL_OPT_CLKS_IN_RESET flag for dispc to fix dispc reset. > > > > Signed-off-by: Tomi Valkeinen > > [b-cous...@ti.com: Remove a comment and update the subject] > > Signed-off-by: Benoit Cousson > > This patch adds "fck" opt-clocks for DSS. After your patch set > for_3.1/5_auto_fck_clkdev, in which you create "fck" automatically, I > see: > > [0.218231] omap_device: omapdss_dss: fck already exist > [0.218261] omap_device: omapdss_dss: fck already exist > [0.218261] omap_device: omapdss_dss: sys_clk already exist > [0.218261] omap_device: omapdss_dss: tv_clk already exist > [0.218322] omap_device: omapdss_dss: video_clk already exist > [0.218627] omap_device: omapdss_dispc: fck already exist > [0.219329] omap_device: omapdss_venc: fck already exist > [0.219635] omap_device: omapdss_dsi1: fck already exist > [0.219970] omap_device: omapdss_dsi2: fck already exist > [0.220336] omap_device: omapdss_hdmi: fck already exist > > So I think the "fck" clocks in this patch should be removed. I only > added them for compatibility, as I didn't have the automatic "fck" > creation patch in my tree. Even after removing the "fck"s from the hwmod data, I see: [0.218200] omap_device: omapdss_dss: fck already exist [0.218231] omap_device: omapdss_dss: sys_clk already exist [0.218231] omap_device: omapdss_dss: tv_clk already exist [0.218292] omap_device: omapdss_dss: video_clk already exist I think those come from the clock44xxx_data.c. I believe those are more or less exact duplicates from the driver's point of view? If so, I guess the ones in clockdata could be removed after adding those to hwmod data? I also see that the main_clk for all dss hwmods is dss_dss_clk. Is that correct? In some earlier version the clocks were a bit different, and, at least according to TRM pictures, correct. For example, rfbi didn't have a main_clk at all, hdmi's main_clk was dss_48mhz_clk etc. Was that changed on purpose? I've tested all the branches from 1 to 7 on OMAP4 SDP, and I'm able to boot all of them (branch 7 needed merging the mmc branch), and I was able to start the dss driver. I also merged my latest dss pmruntime branch, which worked fine. I still need to test OMAP2/3, and the different outputs on OMAP4 (only DSI is tested so far). Tomi -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 17/18] OMAP4: hwmod data: Modify DSS opt clocks
Hi Benoit, On Fri, 2011-07-01 at 22:41 +0200, Benoit Cousson wrote: > From: Tomi Valkeinen > > Add missing DSS optional clocks to HWMOD data for OMAP4xxx. > > Add HWMOD_CONTROL_OPT_CLKS_IN_RESET flag for dispc to fix dispc reset. > > Signed-off-by: Tomi Valkeinen > [b-cous...@ti.com: Remove a comment and update the subject] > Signed-off-by: Benoit Cousson This patch adds "fck" opt-clocks for DSS. After your patch set for_3.1/5_auto_fck_clkdev, in which you create "fck" automatically, I see: [0.218231] omap_device: omapdss_dss: fck already exist [0.218261] omap_device: omapdss_dss: fck already exist [0.218261] omap_device: omapdss_dss: sys_clk already exist [0.218261] omap_device: omapdss_dss: tv_clk already exist [0.218322] omap_device: omapdss_dss: video_clk already exist [0.218627] omap_device: omapdss_dispc: fck already exist [0.219329] omap_device: omapdss_venc: fck already exist [0.219635] omap_device: omapdss_dsi1: fck already exist [0.219970] omap_device: omapdss_dsi2: fck already exist [0.220336] omap_device: omapdss_hdmi: fck already exist So I think the "fck" clocks in this patch should be removed. I only added them for compatibility, as I didn't have the automatic "fck" creation patch in my tree. Also, either you didn't email the patch set in for_3.1/5_auto_fck_clkdev, or I'm just blind... Tomi -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 7/7] omap_hwmod: share identical omap_hwmod_class, omap_hwmod_class_sysconfig arrays
To reduce kernel source file data duplication, share struct
omap_hwmod_class and omap_hwmod_class_sysconfig arrays across OMAP2xxx
and 3xxx hwmod data files.
Signed-off-by: Paul Walmsley
---
arch/arm/mach-omap2/omap_hwmod_2420_data.c | 267 ++--
arch/arm/mach-omap2/omap_hwmod_2430_data.c | 273 ++--
.../mach-omap2/omap_hwmod_2xxx_3xxx_ipblock_data.c | 228 -
arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c | 123 +
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 105 +---
arch/arm/mach-omap2/omap_hwmod_common_data.h | 11 +
6 files changed, 364 insertions(+), 643 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
index 6acc01f..f3901ab 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
@@ -274,24 +274,6 @@ static struct omap_hwmod omap2420_iva_hwmod = {
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2420)
};
-/* Timer Common */
-static struct omap_hwmod_class_sysconfig omap2420_timer_sysc = {
- .rev_offs = 0x,
- .sysc_offs = 0x0010,
- .syss_offs = 0x0014,
- .sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_CLOCKACTIVITY |
- SYSC_HAS_ENAWAKEUP | SYSC_HAS_SOFTRESET |
- SYSC_HAS_AUTOIDLE),
- .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
- .sysc_fields= &omap_hwmod_sysc_type1,
-};
-
-static struct omap_hwmod_class omap2420_timer_hwmod_class = {
- .name = "timer",
- .sysc = &omap2420_timer_sysc,
- .rev = OMAP_TIMER_IP_VERSION_1,
-};
-
/* timer1 */
static struct omap_hwmod omap2420_timer1_hwmod;
@@ -334,7 +316,7 @@ static struct omap_hwmod omap2420_timer1_hwmod = {
},
.slaves = omap2420_timer1_slaves,
.slaves_cnt = ARRAY_SIZE(omap2420_timer1_slaves),
- .class = &omap2420_timer_hwmod_class,
+ .class = &omap2xxx_timer_hwmod_class,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2420)
};
@@ -371,7 +353,7 @@ static struct omap_hwmod omap2420_timer2_hwmod = {
},
.slaves = omap2420_timer2_slaves,
.slaves_cnt = ARRAY_SIZE(omap2420_timer2_slaves),
- .class = &omap2420_timer_hwmod_class,
+ .class = &omap2xxx_timer_hwmod_class,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2420)
};
@@ -408,7 +390,7 @@ static struct omap_hwmod omap2420_timer3_hwmod = {
},
.slaves = omap2420_timer3_slaves,
.slaves_cnt = ARRAY_SIZE(omap2420_timer3_slaves),
- .class = &omap2420_timer_hwmod_class,
+ .class = &omap2xxx_timer_hwmod_class,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2420)
};
@@ -445,7 +427,7 @@ static struct omap_hwmod omap2420_timer4_hwmod = {
},
.slaves = omap2420_timer4_slaves,
.slaves_cnt = ARRAY_SIZE(omap2420_timer4_slaves),
- .class = &omap2420_timer_hwmod_class,
+ .class = &omap2xxx_timer_hwmod_class,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2420)
};
@@ -482,7 +464,7 @@ static struct omap_hwmod omap2420_timer5_hwmod = {
},
.slaves = omap2420_timer5_slaves,
.slaves_cnt = ARRAY_SIZE(omap2420_timer5_slaves),
- .class = &omap2420_timer_hwmod_class,
+ .class = &omap2xxx_timer_hwmod_class,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2420)
};
@@ -520,7 +502,7 @@ static struct omap_hwmod omap2420_timer6_hwmod = {
},
.slaves = omap2420_timer6_slaves,
.slaves_cnt = ARRAY_SIZE(omap2420_timer6_slaves),
- .class = &omap2420_timer_hwmod_class,
+ .class = &omap2xxx_timer_hwmod_class,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2420)
};
@@ -557,7 +539,7 @@ static struct omap_hwmod omap2420_timer7_hwmod = {
},
.slaves = omap2420_timer7_slaves,
.slaves_cnt = ARRAY_SIZE(omap2420_timer7_slaves),
- .class = &omap2420_timer_hwmod_class,
+ .class = &omap2xxx_timer_hwmod_class,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2420)
};
@@ -594,7 +576,7 @@ static struct omap_hwmod omap2420_timer8_hwmod = {
},
.slaves = omap2420_timer8_slaves,
.slaves_cnt = ARRAY_SIZE(omap2420_timer8_slaves),
- .class = &omap2420_timer_hwmod_class,
+ .class = &omap2xxx_timer_hwmod_class,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2420)
};
@@ -631,7 +613,7 @@ static struct omap_hwmod omap2420_timer9_hwmod = {
},
.slaves = omap2420_timer9_slaves,
.slaves_cnt = ARRAY_SIZE(omap2420_timer9_slaves),
- .class = &omap2420_timer_hwmod_class,
+ .class
[PATCH 6/7] omap_hwmod: share identical omap_hwmod_dma_info arrays
To reduce kernel source file data duplication, share struct
omap_hwmod_dma_info arrays across OMAP2xxx and 3xxx hwmod data files.
Signed-off-by: Paul Walmsley
---
arch/arm/mach-omap2/omap_hwmod_2420_data.c | 87 ++
arch/arm/mach-omap2/omap_hwmod_2430_data.c | 95 ++--
.../mach-omap2/omap_hwmod_2xxx_3xxx_ipblock_data.c | 92 +++
arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c |6 +
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 89 ++-
arch/arm/mach-omap2/omap_hwmod_common_data.c | 20
arch/arm/mach-omap2/omap_hwmod_common_data.h | 15 +++
7 files changed, 144 insertions(+), 260 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
index 60c817e..6acc01f 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
@@ -828,12 +828,6 @@ static struct omap_hwmod_class uart_class = {
/* UART1 */
-static struct omap_hwmod_dma_info uart1_sdma_reqs[] = {
- { .name = "rx", .dma_req = OMAP24XX_DMA_UART1_RX, },
- { .name = "tx", .dma_req = OMAP24XX_DMA_UART1_TX, },
- { .dma_req = -1 }
-};
-
static struct omap_hwmod_ocp_if *omap2420_uart1_slaves[] = {
&omap2_l4_core__uart1,
};
@@ -841,7 +835,7 @@ static struct omap_hwmod_ocp_if *omap2420_uart1_slaves[] = {
static struct omap_hwmod omap2420_uart1_hwmod = {
.name = "uart1",
.mpu_irqs = omap2_uart1_mpu_irqs,
- .sdma_reqs = uart1_sdma_reqs,
+ .sdma_reqs = omap2_uart1_sdma_reqs,
.main_clk = "uart1_fck",
.prcm = {
.omap2 = {
@@ -860,12 +854,6 @@ static struct omap_hwmod omap2420_uart1_hwmod = {
/* UART2 */
-static struct omap_hwmod_dma_info uart2_sdma_reqs[] = {
- { .name = "rx", .dma_req = OMAP24XX_DMA_UART2_RX, },
- { .name = "tx", .dma_req = OMAP24XX_DMA_UART2_TX, },
- { .dma_req = -1 }
-};
-
static struct omap_hwmod_ocp_if *omap2420_uart2_slaves[] = {
&omap2_l4_core__uart2,
};
@@ -873,7 +861,7 @@ static struct omap_hwmod_ocp_if *omap2420_uart2_slaves[] = {
static struct omap_hwmod omap2420_uart2_hwmod = {
.name = "uart2",
.mpu_irqs = omap2_uart2_mpu_irqs,
- .sdma_reqs = uart2_sdma_reqs,
+ .sdma_reqs = omap2_uart2_sdma_reqs,
.main_clk = "uart2_fck",
.prcm = {
.omap2 = {
@@ -892,12 +880,6 @@ static struct omap_hwmod omap2420_uart2_hwmod = {
/* UART3 */
-static struct omap_hwmod_dma_info uart3_sdma_reqs[] = {
- { .name = "rx", .dma_req = OMAP24XX_DMA_UART3_RX, },
- { .name = "tx", .dma_req = OMAP24XX_DMA_UART3_TX, },
- { .dma_req = -1 }
-};
-
static struct omap_hwmod_ocp_if *omap2420_uart3_slaves[] = {
&omap2_l4_core__uart3,
};
@@ -905,7 +887,7 @@ static struct omap_hwmod_ocp_if *omap2420_uart3_slaves[] = {
static struct omap_hwmod omap2420_uart3_hwmod = {
.name = "uart3",
.mpu_irqs = omap2_uart3_mpu_irqs,
- .sdma_reqs = uart3_sdma_reqs,
+ .sdma_reqs = omap2_uart3_sdma_reqs,
.main_clk = "uart3_fck",
.prcm = {
.omap2 = {
@@ -940,11 +922,6 @@ static struct omap_hwmod_class omap2420_dss_hwmod_class = {
.sysc = &omap2420_dss_sysc,
};
-static struct omap_hwmod_dma_info omap2420_dss_sdma_chs[] = {
- { .name = "dispc", .dma_req = 5 },
- { .dma_req = -1 }
-};
-
/* dss */
/* dss master ports */
static struct omap_hwmod_ocp_if *omap2420_dss_masters[] = {
@@ -980,7 +957,7 @@ static struct omap_hwmod omap2420_dss_core_hwmod = {
.name = "dss_core",
.class = &omap2420_dss_hwmod_class,
.main_clk = "dss1_fck", /* instead of dss_fck */
- .sdma_reqs = omap2420_dss_sdma_chs,
+ .sdma_reqs = omap2xxx_dss_sdma_chs,
.prcm = {
.omap2 = {
.prcm_reg_id = 1,
@@ -1183,12 +1160,6 @@ static struct omap_i2c_dev_attr i2c_dev_attr;
/* I2C1 */
-static struct omap_hwmod_dma_info i2c1_sdma_reqs[] = {
- { .name = "tx", .dma_req = OMAP24XX_DMA_I2C1_TX },
- { .name = "rx", .dma_req = OMAP24XX_DMA_I2C1_RX },
- { .dma_req = -1 }
-};
-
static struct omap_hwmod_ocp_if *omap2420_i2c1_slaves[] = {
&omap2420_l4_core__i2c1,
};
@@ -1196,7 +1167,7 @@ static struct omap_hwmod_ocp_if *omap2420_i2c1_slaves[] =
{
static struct omap_hwmod omap2420_i2c1_hwmod = {
.name = "i2c1",
.mpu_irqs = omap2_i2c1_mpu_irqs,
- .sdma_reqs = i2c1_sdma_reqs,
+ .sdma_reqs = omap2_i2c1_sdma_reqs,
.main_clk = "i2c1_fck",
.prcm = {
.omap2 = {
@@ -1217,12 +1188,6 @@ static struct omap_hwmod omap2420_i2c1_hwmod = {
/* I2C2 */
-stat
[PATCH 4/7] omap_hwmod: share identical omap_hwmod_mpu_irqs arrays
To reduce kernel source file data duplication, share struct
omap_hwmod_mpu_irqs arrays across OMAP2xxx and 3xxx hwmod data files.
Signed-off-by: Paul Walmsley
---
arch/arm/mach-omap2/Makefile | 11 +
arch/arm/mach-omap2/omap_hwmod_2420_data.c | 167 +++-
arch/arm/mach-omap2/omap_hwmod_2430_data.c | 166 +++-
.../mach-omap2/omap_hwmod_2xxx_3xxx_ipblock_data.c | 142 +
arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c | 21 +++
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 162 +++
arch/arm/mach-omap2/omap_hwmod_common_data.h | 29 +++
7 files changed, 275 insertions(+), 423 deletions(-)
create mode 100644 arch/arm/mach-omap2/omap_hwmod_2xxx_3xxx_ipblock_data.c
create mode 100644 arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index cafee7b..a2e7f12 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -145,13 +145,18 @@ obj-$(CONFIG_SOC_OMAP2420)+=
opp2420_data.o
obj-$(CONFIG_SOC_OMAP2430) += opp2430_data.o
# hwmod data
-obj-$(CONFIG_SOC_OMAP2420) += omap_hwmod_2xxx_interconnect_data.o \
+obj-$(CONFIG_SOC_OMAP2420) += omap_hwmod_2xxx_ipblock_data.o \
+ omap_hwmod_2xxx_3xxx_ipblock_data.o \
+ omap_hwmod_2xxx_interconnect_data.o \
omap_hwmod_2xxx_3xxx_interconnect_data.o \
omap_hwmod_2420_data.o
-obj-$(CONFIG_SOC_OMAP2430) += omap_hwmod_2xxx_interconnect_data.o \
+obj-$(CONFIG_SOC_OMAP2430) += omap_hwmod_2xxx_ipblock_data.o \
+ omap_hwmod_2xxx_3xxx_ipblock_data.o \
+ omap_hwmod_2xxx_interconnect_data.o \
omap_hwmod_2xxx_3xxx_interconnect_data.o \
omap_hwmod_2430_data.o
-obj-$(CONFIG_ARCH_OMAP3) +=
omap_hwmod_2xxx_3xxx_interconnect_data.o \
+obj-$(CONFIG_ARCH_OMAP3) += omap_hwmod_2xxx_3xxx_ipblock_data.o \
+
omap_hwmod_2xxx_3xxx_interconnect_data.o \
omap_hwmod_3xxx_data.o
obj-$(CONFIG_ARCH_OMAP4) += omap_hwmod_44xx_data.o
diff --git a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
index 04730d3..73157ee 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
@@ -294,10 +294,6 @@ static struct omap_hwmod_class omap2420_timer_hwmod_class
= {
/* timer1 */
static struct omap_hwmod omap2420_timer1_hwmod;
-static struct omap_hwmod_irq_info omap2420_timer1_mpu_irqs[] = {
- { .irq = 37, },
- { .irq = -1 }
-};
static struct omap_hwmod_addr_space omap2420_timer1_addrs[] = {
{
@@ -325,7 +321,7 @@ static struct omap_hwmod_ocp_if *omap2420_timer1_slaves[] =
{
/* timer1 hwmod */
static struct omap_hwmod omap2420_timer1_hwmod = {
.name = "timer1",
- .mpu_irqs = omap2420_timer1_mpu_irqs,
+ .mpu_irqs = omap2_timer1_mpu_irqs,
.main_clk = "gpt1_fck",
.prcm = {
.omap2 = {
@@ -344,11 +340,6 @@ static struct omap_hwmod omap2420_timer1_hwmod = {
/* timer2 */
static struct omap_hwmod omap2420_timer2_hwmod;
-static struct omap_hwmod_irq_info omap2420_timer2_mpu_irqs[] = {
- { .irq = 38, },
- { .irq = -1 }
-};
-
/* l4_core -> timer2 */
static struct omap_hwmod_ocp_if omap2420_l4_core__timer2 = {
@@ -367,7 +358,7 @@ static struct omap_hwmod_ocp_if *omap2420_timer2_slaves[] =
{
/* timer2 hwmod */
static struct omap_hwmod omap2420_timer2_hwmod = {
.name = "timer2",
- .mpu_irqs = omap2420_timer2_mpu_irqs,
+ .mpu_irqs = omap2_timer2_mpu_irqs,
.main_clk = "gpt2_fck",
.prcm = {
.omap2 = {
@@ -386,10 +377,6 @@ static struct omap_hwmod omap2420_timer2_hwmod = {
/* timer3 */
static struct omap_hwmod omap2420_timer3_hwmod;
-static struct omap_hwmod_irq_info omap2420_timer3_mpu_irqs[] = {
- { .irq = 39, },
- { .irq = -1 }
-};
/* l4_core -> timer3 */
static struct omap_hwmod_ocp_if omap2420_l4_core__timer3 = {
@@ -408,7 +395,7 @@ static struct omap_hwmod_ocp_if *omap2420_timer3_slaves[] =
{
/* timer3 hwmod */
static struct omap_hwmod omap2420_timer3_hwmod = {
.name = "timer3",
- .mpu_irqs = omap2420_timer3_mpu_irqs,
+ .mpu_irqs = omap2_timer3_mpu_irqs,
.main_clk = "gpt3_fck",
.prcm = {
.omap2 = {
@@ -427,10 +414,6 @@ static struct omap_hwmod omap242
[PATCH 5/7] omap_hwmod: use a terminator record with omap_hwmod_dma_info arrays
Previously, struct omap_hwmod_dma_info arrays were unterminated; and
users of these arrays used the ARRAY_SIZE() macro to determine the
length of the array. However, ARRAY_SIZE() only works when the array
is in the same scope as the macro user.
So far this hasn't been a problem. However, to reduce duplicated
data, a subsequent patch will move common data to a separate, shared
file. When this is done, ARRAY_SIZE() will no longer be usable.
This patch removes ARRAY_SIZE() usage for struct omap_hwmod_dma_info
arrays and uses a sentinel value (irq == -1) as the array terminator
instead.
Signed-off-by: Paul Walmsley
---
arch/arm/mach-omap2/omap_hwmod.c | 30 -
arch/arm/mach-omap2/omap_hwmod_2420_data.c | 20 -
arch/arm/mach-omap2/omap_hwmod_2430_data.c | 32 +++---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 43 +--
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 60 +-
arch/arm/plat-omap/include/plat/omap_hwmod.h |8 +--
6 files changed, 106 insertions(+), 87 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 21e3eb8..d1a8bde 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -702,6 +702,29 @@ static int _count_mpu_irqs(struct omap_hwmod *oh)
}
/**
+ * _count_sdma_reqs - count the number of SDMA request lines associated with
@oh
+ * @oh: struct omap_hwmod *oh
+ *
+ * Count and return the number of SDMA request lines associated with
+ * the hwmod @oh. Used to allocate struct resource data. Returns 0
+ * if @oh is NULL.
+ */
+static int _count_sdma_reqs(struct omap_hwmod *oh)
+{
+ struct omap_hwmod_dma_info *ohdi;
+ int i = 0;
+
+ if (!oh || !oh->sdma_reqs)
+ return 0;
+
+ do {
+ ohdi = &oh->sdma_reqs[i++];
+ } while (ohdi->dma_req != -1);
+
+ return i;
+}
+
+/**
* _count_ocp_if_addr_spaces - count the number of address space entries for
@oh
* @oh: struct omap_hwmod *oh
*
@@ -1987,7 +2010,7 @@ int omap_hwmod_count_resources(struct omap_hwmod *oh)
{
int ret, i;
- ret = _count_mpu_irqs(oh) + oh->sdma_reqs_cnt;
+ ret = _count_mpu_irqs(oh) + _count_sdma_reqs(oh);
for (i = 0; i < oh->slaves_cnt; i++)
ret += _count_ocp_if_addr_spaces(oh->slaves[i]);
@@ -2007,7 +2030,7 @@ int omap_hwmod_count_resources(struct omap_hwmod *oh)
*/
int omap_hwmod_fill_resources(struct omap_hwmod *oh, struct resource *res)
{
- int i, j, mpu_irqs_cnt;
+ int i, j, mpu_irqs_cnt, sdma_reqs_cnt;
int r = 0;
/* For each IRQ, DMA, memory area, fill in array.*/
@@ -2021,7 +2044,8 @@ int omap_hwmod_fill_resources(struct omap_hwmod *oh,
struct resource *res)
r++;
}
- for (i = 0; i < oh->sdma_reqs_cnt; i++) {
+ sdma_reqs_cnt = _count_sdma_reqs(oh);
+ for (i = 0; i < sdma_reqs_cnt; i++) {
(res + r)->name = (oh->sdma_reqs + i)->name;
(res + r)->start = (oh->sdma_reqs + i)->dma_req;
(res + r)->end = (oh->sdma_reqs + i)->dma_req;
diff --git a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
index 73157ee..60c817e 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
@@ -831,6 +831,7 @@ static struct omap_hwmod_class uart_class = {
static struct omap_hwmod_dma_info uart1_sdma_reqs[] = {
{ .name = "rx", .dma_req = OMAP24XX_DMA_UART1_RX, },
{ .name = "tx", .dma_req = OMAP24XX_DMA_UART1_TX, },
+ { .dma_req = -1 }
};
static struct omap_hwmod_ocp_if *omap2420_uart1_slaves[] = {
@@ -841,7 +842,6 @@ static struct omap_hwmod omap2420_uart1_hwmod = {
.name = "uart1",
.mpu_irqs = omap2_uart1_mpu_irqs,
.sdma_reqs = uart1_sdma_reqs,
- .sdma_reqs_cnt = ARRAY_SIZE(uart1_sdma_reqs),
.main_clk = "uart1_fck",
.prcm = {
.omap2 = {
@@ -863,6 +863,7 @@ static struct omap_hwmod omap2420_uart1_hwmod = {
static struct omap_hwmod_dma_info uart2_sdma_reqs[] = {
{ .name = "rx", .dma_req = OMAP24XX_DMA_UART2_RX, },
{ .name = "tx", .dma_req = OMAP24XX_DMA_UART2_TX, },
+ { .dma_req = -1 }
};
static struct omap_hwmod_ocp_if *omap2420_uart2_slaves[] = {
@@ -873,7 +874,6 @@ static struct omap_hwmod omap2420_uart2_hwmod = {
.name = "uart2",
.mpu_irqs = omap2_uart2_mpu_irqs,
.sdma_reqs = uart2_sdma_reqs,
- .sdma_reqs_cnt = ARRAY_SIZE(uart2_sdma_reqs),
.main_clk = "uart2_fck",
.prcm = {
.omap2 = {
@@ -895,6 +895,7 @@ static struct omap_hwmod omap2420_uart2_hwmod = {
static struct omap_hwmod_dma_info uart3_sdma_reqs[] = {
{ .name = "rx", .dma_req = OMAP24XX_DMA_UART3_RX, },
{ .name = "tx", .dma_re
[PATCH 2/7] omap_hwmod: share identical omap_hwmod_addr_space arrays
To reduce kernel source file data duplication, share struct
omap_hwmod_addr_space arrays across OMAP2xxx and 3xxx hwmod data
files.
Signed-off-by: Paul Walmsley
---
arch/arm/mach-omap2/Makefile | 11 +
arch/arm/mach-omap2/omap_hwmod_2420_data.c | 291 ++
arch/arm/mach-omap2/omap_hwmod_2430_data.c | 319 ++--
.../omap_hwmod_2xxx_3xxx_interconnect_data.c | 173 +++
.../mach-omap2/omap_hwmod_2xxx_interconnect_data.c | 130
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 151 +
arch/arm/mach-omap2/omap_hwmod_common_data.h | 38 ++
7 files changed, 414 insertions(+), 699 deletions(-)
create mode 100644 arch/arm/mach-omap2/omap_hwmod_2xxx_3xxx_interconnect_data.c
create mode 100644 arch/arm/mach-omap2/omap_hwmod_2xxx_interconnect_data.c
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index b148077..cafee7b 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -145,9 +145,14 @@ obj-$(CONFIG_SOC_OMAP2420) += opp2420_data.o
obj-$(CONFIG_SOC_OMAP2430) += opp2430_data.o
# hwmod data
-obj-$(CONFIG_SOC_OMAP2420) += omap_hwmod_2420_data.o
-obj-$(CONFIG_SOC_OMAP2430) += omap_hwmod_2430_data.o
-obj-$(CONFIG_ARCH_OMAP3) += omap_hwmod_3xxx_data.o
+obj-$(CONFIG_SOC_OMAP2420) += omap_hwmod_2xxx_interconnect_data.o \
+
omap_hwmod_2xxx_3xxx_interconnect_data.o \
+ omap_hwmod_2420_data.o
+obj-$(CONFIG_SOC_OMAP2430) += omap_hwmod_2xxx_interconnect_data.o \
+
omap_hwmod_2xxx_3xxx_interconnect_data.o \
+ omap_hwmod_2430_data.o
+obj-$(CONFIG_ARCH_OMAP3) +=
omap_hwmod_2xxx_3xxx_interconnect_data.o \
+ omap_hwmod_3xxx_data.o
obj-$(CONFIG_ARCH_OMAP4) += omap_hwmod_44xx_data.o
# EMU peripherals
diff --git a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
index 1a7ce3e..3ec625c 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
@@ -114,38 +114,20 @@ static struct omap_hwmod omap2420_mcbsp1_hwmod;
static struct omap_hwmod omap2420_mcbsp2_hwmod;
/* l4 core -> mcspi1 interface */
-static struct omap_hwmod_addr_space omap2420_mcspi1_addr_space[] = {
- {
- .pa_start = 0x48098000,
- .pa_end = 0x480980ff,
- .flags = ADDR_TYPE_RT,
- },
- { }
-};
-
static struct omap_hwmod_ocp_if omap2420_l4_core__mcspi1 = {
.master = &omap2420_l4_core_hwmod,
.slave = &omap2420_mcspi1_hwmod,
.clk= "mcspi1_ick",
- .addr = omap2420_mcspi1_addr_space,
+ .addr = omap2_mcspi1_addr_space,
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
/* l4 core -> mcspi2 interface */
-static struct omap_hwmod_addr_space omap2420_mcspi2_addr_space[] = {
- {
- .pa_start = 0x4809a000,
- .pa_end = 0x4809a0ff,
- .flags = ADDR_TYPE_RT,
- },
- { }
-};
-
static struct omap_hwmod_ocp_if omap2420_l4_core__mcspi2 = {
.master = &omap2420_l4_core_hwmod,
.slave = &omap2420_mcspi2_hwmod,
.clk= "mcspi2_ick",
- .addr = omap2420_mcspi2_addr_space,
+ .addr = omap2_mcspi2_addr_space,
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
@@ -157,95 +139,47 @@ static struct omap_hwmod_ocp_if omap2420_l4_core__l4_wkup
= {
};
/* L4 CORE -> UART1 interface */
-static struct omap_hwmod_addr_space omap2420_uart1_addr_space[] = {
- {
- .pa_start = OMAP2_UART1_BASE,
- .pa_end = OMAP2_UART1_BASE + SZ_8K - 1,
- .flags = ADDR_MAP_ON_INIT | ADDR_TYPE_RT,
- },
- { }
-};
-
static struct omap_hwmod_ocp_if omap2_l4_core__uart1 = {
.master = &omap2420_l4_core_hwmod,
.slave = &omap2420_uart1_hwmod,
.clk= "uart1_ick",
- .addr = omap2420_uart1_addr_space,
+ .addr = omap2xxx_uart1_addr_space,
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
/* L4 CORE -> UART2 interface */
-static struct omap_hwmod_addr_space omap2420_uart2_addr_space[] = {
- {
- .pa_start = OMAP2_UART2_BASE,
- .pa_end = OMAP2_UART2_BASE + SZ_1K - 1,
- .flags = ADDR_MAP_ON_INIT | ADDR_TYPE_RT,
- },
- { }
-};
-
static struct omap_hwmod_ocp_if omap2_l4_core__uart2 = {
.master = &omap2420_l4_core_hwmod,
.slave = &oma
[PATCH 0/7] OMAP: hwmod: consolidate duplicate data across OMAP2xxx/3xxx files
Hello, This series combines some duplicate omap_hwmod data across the OMAP2420, OMAP2430, and OMAP3 data files. The intention here is to reduce the amount of kernel source code in arch/arm/mach-omap2/, although there is also a small kernel size reduction. Further cleanup and reorganization is forthcoming in later series; this is simply the first round. Boot-tested on OMAP4430 ES2 PandaBoard and OMAP3530 BeagleBoard. - Paul --- Paul Walmsley (7): omap_hwmod: use a null structure record to terminate omap_hwmod_addr_space arrays omap_hwmod: share identical omap_hwmod_addr_space arrays omap_hwmod: use a terminator record with omap_hwmod_mpu_irqs arrays omap_hwmod: share identical omap_hwmod_mpu_irqs arrays omap_hwmod: use a terminator record with omap_hwmod_dma_info arrays omap_hwmod: share identical omap_hwmod_dma_info arrays omap_hwmod: share identical omap_hwmod_class, omap_hwmod_class_sysconfig arrays arch/arm/mach-omap2/Makefile | 16 arch/arm/mach-omap2/omap_hwmod.c | 101 ++ arch/arm/mach-omap2/omap_hwmod_2420_data.c | 832 ++ arch/arm/mach-omap2/omap_hwmod_2430_data.c | 910 +++- .../omap_hwmod_2xxx_3xxx_interconnect_data.c | 173 .../mach-omap2/omap_hwmod_2xxx_3xxx_ipblock_data.c | 322 +++ .../mach-omap2/omap_hwmod_2xxx_interconnect_data.c | 130 +++ arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c | 150 +++ arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 654 +++--- arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 357 arch/arm/mach-omap2/omap_hwmod_common_data.c | 20 arch/arm/mach-omap2/omap_hwmod_common_data.h | 93 ++ arch/arm/plat-omap/include/plat/omap_hwmod.h | 18 13 files changed, 1508 insertions(+), 2268 deletions(-) create mode 100644 arch/arm/mach-omap2/omap_hwmod_2xxx_3xxx_interconnect_data.c create mode 100644 arch/arm/mach-omap2/omap_hwmod_2xxx_3xxx_ipblock_data.c create mode 100644 arch/arm/mach-omap2/omap_hwmod_2xxx_interconnect_data.c create mode 100644 arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
