Re: [PATCH 6/8] OMAP: PM CONSTRAINTS: implement the devices wake-up latency constraints
Kevin, On Fri, Sep 16, 2011 at 1:47 AM, Kevin Hilman khil...@ti.com wrote: Jean Pihet jean.pi...@newoldbits.com writes: Implement the devices wake-up latency constraints using the global device PM QoS notification handler which applies the constraints to the underlying layer by calling the corresponding function at hwmod level. Note: the bus throughput function is implemented but currently is a no-op. A new PM QoS class for the bus throughput needs to be added. Tested on OMAP3 Beagleboard and OMAP4 Pandaboard in RET/OFF using wake-up latency constraints on MPU, CORE and PER. Signed-off-by: Jean Pihet j-pi...@ti.com This patch does 2 things. 1) removes the MPU lat stuff from the OMAP PM layer (since it's now available in a generic form 2) implements device wake-up latency constraints This should be broken up into two parts. Also, this patch seems to remove a bunch of stuff that was just added in patch 2/8. Probably best to create the new OMAP PM layer after remving the unused stuff. It think the code using the new per-device PM QoS API should also live outside the OMAP PM layer, since it's not related, and we want to get rid of the OMAP PM layer eventually. Speaking of which..., the more I think about it, the more I think we should take this opportunity to clean and/or remove the OMAP PM layer completely. I agree completely, the OMAP PM 'plugin' layer is useless and anyway an empty implementation for now. With your work, other than the no-op bus throughput API, it's basically unused. I think that rather than creating a new OMAP PM layer just to have a a no-op bus throughput function here, I think it's time to remove OMAP PM completely. Ok. The only useful code is to register a PM QoS notifier in order to apply the constraints to the power domains. Are you suggesting to move this code to e.g. pmxxx.c? This might also give some incentive for a PM QoS bus throughput constraint as well. Sure the tput constraints should be implemented as well. Of course, Paul can make the final decision there whether to remove it now, but I think it's time. Just to prove it's usefulness (or lack thereof), Here's a hack that combined with your patch 1/8 shows that it is pretty easy to remove. Kevin Thanks! Jean -- 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 6/8] OMAP: PM CONSTRAINTS: implement the devices wake-up latency constraints
Jean Pihet jean.pi...@newoldbits.com writes: Kevin, On Fri, Sep 16, 2011 at 1:47 AM, Kevin Hilman khil...@ti.com wrote: Jean Pihet jean.pi...@newoldbits.com writes: Implement the devices wake-up latency constraints using the global device PM QoS notification handler which applies the constraints to the underlying layer by calling the corresponding function at hwmod level. Note: the bus throughput function is implemented but currently is a no-op. A new PM QoS class for the bus throughput needs to be added. Tested on OMAP3 Beagleboard and OMAP4 Pandaboard in RET/OFF using wake-up latency constraints on MPU, CORE and PER. Signed-off-by: Jean Pihet j-pi...@ti.com This patch does 2 things. 1) removes the MPU lat stuff from the OMAP PM layer (since it's now available in a generic form 2) implements device wake-up latency constraints This should be broken up into two parts. Also, this patch seems to remove a bunch of stuff that was just added in patch 2/8. Probably best to create the new OMAP PM layer after remving the unused stuff. It think the code using the new per-device PM QoS API should also live outside the OMAP PM layer, since it's not related, and we want to get rid of the OMAP PM layer eventually. Speaking of which..., the more I think about it, the more I think we should take this opportunity to clean and/or remove the OMAP PM layer completely. I agree completely, the OMAP PM 'plugin' layer is useless and anyway an empty implementation for now. Great, let's wait for Paul's view on this since he's the maintainer of the OMAP PM layer. With your work, other than the no-op bus throughput API, it's basically unused. I think that rather than creating a new OMAP PM layer just to have a a no-op bus throughput function here, I think it's time to remove OMAP PM completely. Ok. The only useful code is to register a PM QoS notifier in order to apply the constraints to the power domains. Are you suggesting to move this code to e.g. pmxxx.c? Yes, or simply pm-constraints.c since I guess it should be SoC-independent. 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
Re: [PATCH 6/8] OMAP: PM CONSTRAINTS: implement the devices wake-up latency constraints
Jean Pihet jean.pi...@newoldbits.com writes:
Implement the devices wake-up latency constraints using the global
device PM QoS notification handler which applies the constraints to the
underlying layer by calling the corresponding function at hwmod level.
Note: the bus throughput function is implemented but currently is
a no-op. A new PM QoS class for the bus throughput needs to be
added.
Tested on OMAP3 Beagleboard and OMAP4 Pandaboard in RET/OFF using wake-up
latency constraints on MPU, CORE and PER.
Signed-off-by: Jean Pihet j-pi...@ti.com
This patch does 2 things.
1) removes the MPU lat stuff from the OMAP PM layer (since it's now
available in a generic form
2) implements device wake-up latency constraints
This should be broken up into two parts.
Also, this patch seems to remove a bunch of stuff that was just added in
patch 2/8. Probably best to create the new OMAP PM layer after remving
the unused stuff.
It think the code using the new per-device PM QoS API should also live
outside the OMAP PM layer, since it's not related, and we want to get
rid of the OMAP PM layer eventually.
Speaking of which..., the more I think about it, the more I think we
should take this opportunity to clean and/or remove the OMAP PM layer
completely.
With your work, other than the no-op bus throughput API, it's basically
unused. I think that rather than creating a new OMAP PM layer just to
have a a no-op bus throughput function here, I think it's time
to remove OMAP PM completely. This might also give some incentive
for a PM QoS bus throughput constraint as well.
Of course, Paul can make the final decision there whether to remove it
now, but I think it's time.
Just to prove it's usefulness (or lack thereof), Here's a hack that
combined with your patch 1/8 shows that it is pretty easy to remove.
Kevin
diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c
index a5b7a23..e819d59 100644
--- a/arch/arm/mach-omap2/display.c
+++ b/arch/arm/mach-omap2/display.c
@@ -74,6 +74,13 @@ static const struct omap_dss_hwmod_data
omap4_dss_hwmod_data[] __initdata = {
{ dss_hdmi, omapdss_hdmi, -1 },
};
+static int omap_display_get_context_loss_count(struct device *dev)
+{
+ struct platform_device *pdev = to_platform_device(dev);
+
+ return omap_device_get_context_loss_count(pdev);
+}
+
int __init omap_display_init(struct omap_dss_board_info *board_data)
{
int r = 0;
@@ -98,7 +105,7 @@ int __init omap_display_init(struct omap_dss_board_info
*board_data)
pdata.board_data = board_data;
pdata.board_data-get_context_loss_count =
- omap_pm_get_dev_context_loss_count;
+ omap_display_get_context_loss_count;
for (i = 0; i oh_count; i++) {
oh = omap_hwmod_lookup(curr_dss_hwmod[i].oh_name);
diff --git a/arch/arm/mach-omap2/hsmmc.c b/arch/arm/mach-omap2/hsmmc.c
index a9b45c7..fc001f7 100644
--- a/arch/arm/mach-omap2/hsmmc.c
+++ b/arch/arm/mach-omap2/hsmmc.c
@@ -36,7 +36,9 @@ static u16 control_mmc1;
static int hsmmc_get_context_loss(struct device *dev)
{
- return omap_pm_get_dev_context_loss_count(dev);
+ struct platform_device *pdev = to_platform_device(dev);
+
+ return omap_device_get_context_loss_count(pdev);
}
#else
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 132724c..6e8794a 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -386,7 +386,7 @@ void __init omap2_init_common_infrastructure(void)
_set_hwmod_postsetup_state,
postsetup_state);
- omap_pm_if_early_init();
+ /* omap_pm_if_early_init(); */
if (cpu_is_omap2420())
omap2420_clk_init();
diff --git a/arch/arm/mach-omap2/pm-debug.c b/arch/arm/mach-omap2/pm-debug.c
index 4411163..ca978c0 100644
--- a/arch/arm/mach-omap2/pm-debug.c
+++ b/arch/arm/mach-omap2/pm-debug.c
@@ -243,10 +243,10 @@ static int option_set(void *data, u64 val)
*option = val;
if (option == enable_off_mode) {
- if (val)
- omap_pm_enable_off_mode();
- else
- omap_pm_disable_off_mode();
+ /* if (val) */
+ /* omap_pm_enable_off_mode(); */
+ /* else */
+ /* omap_pm_disable_off_mode(); */
if (cpu_is_omap34xx())
omap3_pm_off_mode_enable(val);
}
diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
index 472bf22..59e7533 100644
--- a/arch/arm/mach-omap2/pm.c
+++ b/arch/arm/mach-omap2/pm.c
@@ -243,7 +243,7 @@ static void __init omap4_init_voltages(void)
static int __init omap2_common_pm_init(void)
{
omap2_init_processor_devices();
- omap_pm_if_init();
+ /* omap_pm_if_init(); */
return 0;
}
diff --git a/arch/arm/plat-omap/Makefile
[PATCH 6/8] OMAP: PM CONSTRAINTS: implement the devices wake-up latency constraints
Implement the devices wake-up latency constraints using the global
device PM QoS notification handler which applies the constraints to the
underlying layer by calling the corresponding function at hwmod level.
Note: the bus throughput function is implemented but currently is
a no-op. A new PM QoS class for the bus throughput needs to be
added.
Tested on OMAP3 Beagleboard and OMAP4 Pandaboard in RET/OFF using wake-up
latency constraints on MPU, CORE and PER.
Signed-off-by: Jean Pihet j-pi...@ti.com
---
arch/arm/plat-omap/include/plat/omap-pm.h | 128 -
arch/arm/plat-omap/omap-pm-constraints.c | 173 +---
arch/arm/plat-omap/omap-pm-noop.c | 89 ---
3 files changed, 80 insertions(+), 310 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/omap-pm.h
b/arch/arm/plat-omap/include/plat/omap-pm.h
index 0840df8..d276082 100644
--- a/arch/arm/plat-omap/include/plat/omap-pm.h
+++ b/arch/arm/plat-omap/include/plat/omap-pm.h
@@ -62,136 +62,8 @@ void omap_pm_if_exit(void);
* Device-driver-originated constraints (via board-*.c files, platform_data)
*/
-
-/**
- * omap_pm_set_max_mpu_wakeup_lat - set the maximum MPU wakeup latency
- * @dev: struct device * requesting the constraint
- * @t: maximum MPU wakeup latency in microseconds
- *
- * Request that the maximum interrupt latency for the MPU to be no
- * greater than @t microseconds. Interrupt latency in this case is
- * defined as the elapsed time from the occurrence of a hardware or
- * timer interrupt to the time when the device driver's interrupt
- * service routine has been entered by the MPU.
- *
- * It is intended that underlying PM code will use this information to
- * determine what power state to put the MPU powerdomain into, and
- * possibly the CORE powerdomain as well, since interrupt handling
- * code currently runs from SDRAM. Advanced PM or board*.c code may
- * also configure interrupt controller priorities, OCP bus priorities,
- * CPU speed(s), etc.
- *
- * This function will not affect device wakeup latency, e.g., time
- * elapsed from when a device driver enables a hardware device with
- * clk_enable(), to when the device is ready for register access or
- * other use. To control this device wakeup latency, use
- * omap_pm_set_max_dev_wakeup_lat()
- *
- * Multiple calls to omap_pm_set_max_mpu_wakeup_lat() will replace the
- * previous t value. To remove the latency target for the MPU, call
- * with t = -1.
- *
- * XXX This constraint will be deprecated soon in favor of the more
- * general omap_pm_set_max_dev_wakeup_lat()
- *
- * Returns -EINVAL for an invalid argument, -ERANGE if the constraint
- * is not satisfiable, or 0 upon success.
- */
-int omap_pm_set_max_mpu_wakeup_lat(struct device *dev, long t);
-
-
-/**
- * omap_pm_set_min_bus_tput - set minimum bus throughput needed by device
- * @dev: struct device * requesting the constraint
- * @tbus_id: interconnect to operate on (OCP_{INITIATOR,TARGET}_AGENT)
- * @r: minimum throughput (in KiB/s)
- *
- * Request that the minimum data throughput on the OCP interconnect
- * attached to device @dev interconnect agent @tbus_id be no less
- * than @r KiB/s.
- *
- * It is expected that the OMAP PM or bus code will use this
- * information to set the interconnect clock to run at the lowest
- * possible speed that satisfies all current system users. The PM or
- * bus code will adjust the estimate based on its model of the bus, so
- * device driver authors should attempt to specify an accurate
- * quantity for their device use case, and let the PM or bus code
- * overestimate the numbers as necessary to handle request/response
- * latency, other competing users on the system, etc. On OMAP2/3, if
- * a driver requests a minimum L4 interconnect speed constraint, the
- * code will also need to add an minimum L3 interconnect speed
- * constraint,
- *
- * Multiple calls to omap_pm_set_min_bus_tput() will replace the
- * previous rate value for this device. To remove the interconnect
- * throughput restriction for this device, call with r = 0.
- *
- * Returns -EINVAL for an invalid argument, -ERANGE if the constraint
- * is not satisfiable, or 0 upon success.
- */
int omap_pm_set_min_bus_tput(struct device *dev, u8 agent_id, unsigned long r);
-
-/**
- * omap_pm_set_max_dev_wakeup_lat - set the maximum device enable latency
- * @req_dev: struct device * requesting the constraint, or NULL if none
- * @dev: struct device * to set the constraint one
- * @t: maximum device wakeup latency in microseconds
- *
- * Request that the maximum amount of time necessary for a device @dev
- * to become accessible after its clocks are enabled should be no
- * greater than @t microseconds. Specifically, this represents the
- * time from when a device driver enables device clocks with
- * clk_enable(), to when the register reads and writes on the device
- * will succeed. This function should be called before clk_disable()
- * is called,
