RE: [RFC: PATCH 0/4] Introducing TI's New SoC/board AM335XEVM
> -Original Message- > From: Hiremath, Vaibhav > Sent: Thursday, August 11, 2011 4:00 PM > To: linux-omap@vger.kernel.org > Cc: t...@atomide.com; Hilman, Kevin; p...@pwsan.com; linux-arm- > ker...@lists.infradead.org; Hiremath, Vaibhav > Subject: [RFC: PATCH 0/4] Introducing TI's New SoC/board AM335XEVM > > From: Vaibhav Hiremath > > This patch set adds support for AM335x device having > Cortex-A8 MPU. > > AM335X is treated as another OMAP3 variant where the > cpu class is considered as OMAP34XX and the type is AM335X. > Also, AM335X devices shares similar architecture as TI81XX devices; > this means, cpu_is_omap34xx(), cpu_is_ti81xx() and > cpu_is_am335x() checks return success for AM335X. > > Currently submitting this patch series as a RFC, to initiate the > discussion on the approach we have chosen for AM335x device support. > Based on the feedback, will submit the final version of patch series > immediately. [Hiremath, Vaibhav] Tony/Kevin/Paul and others, Any comments/inputs/suggestions on this patch series? Thanks, Vaibhav > > This patch series is created on top of linux-omap/master and > Hemant's TI814X patches submitted recently. > > http://www.mail-archive.com/linux-omap@vger.kernel.org/msg53457.html > > Also, I have validated OMAP3 boot test with this patch-series on OMAP3EVM. > > Afzal Mohammed (4): > AM335X: Update common omap platform files > AM335X: Update common OMAP machine specific sources > AM335X: Create board support and enable build for AM335XEVM > AM335X: Add low level debugging support > > arch/arm/mach-omap2/Kconfig|7 +++- > arch/arm/mach-omap2/Makefile |2 + > arch/arm/mach-omap2/board-am335xevm.c | 57 > > arch/arm/mach-omap2/clock3xxx_data.c |3 + > arch/arm/mach-omap2/common.c | 16 +++ > arch/arm/mach-omap2/id.c |6 +++ > arch/arm/mach-omap2/include/mach/debug-macro.S | 21 + > arch/arm/plat-omap/include/plat/clkdev_omap.h |1 + > arch/arm/plat-omap/include/plat/clock.h|1 + > arch/arm/plat-omap/include/plat/cpu.h | 14 ++ > arch/arm/plat-omap/include/plat/io.h | 12 + > arch/arm/plat-omap/include/plat/omap34xx.h |2 + > arch/arm/plat-omap/include/plat/serial.h |4 ++ > arch/arm/plat-omap/include/plat/ti81xx.h |4 ++ > arch/arm/plat-omap/include/plat/uncompress.h |6 +++ > 15 files changed, 155 insertions(+), 1 deletions(-) > create mode 100644 arch/arm/mach-omap2/board-am335xevm.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
Re: [PATCH] OMAP: clockdomain: Wait for powerdomain to be ON when using clockdomain force wakeup
On Wednesday 17 August 2011 07:17 AM, Paul Walmsley wrote: Hi everyone I've updated this patch per my earlier comments and also to apply. Please let me know if you have any issues with it ASAP. - Paul From: Santosh Shilimkar Date: Sat, 13 Aug 2011 08:56:28 +0530 Subject: [PATCH] [PATCH] OMAP: clockdomain: Wait for powerdomain to be ON when using clockdomain force wakeup While using clockdomain force wakeup method, not waiting for powerdomain to be effectively ON may end up locking the clockdomain FSM until a next wakeup event occurs. One such issue was seen on OMAP4430, where L4_PER was periodically getting stuck in in-transition state when transitioning from from OSWR to ON. This issue was reported and investigated by Patrick Titiano Signed-off-by: Santosh Shilimkar Signed-off-by: Rajendra Nayak Reported-by: Patrick Titiano Cc: Kevin Hilman Cc: Benoit Cousson Cc: Paul Walmsley [p...@pwsan.com: updated to apply; added transition wait on clkdm_deny_idle(); remove two superfluous pwrdm_wait_transition() calls] Signed-off-by: Paul Walmsley --- Thanks Paul. Patch looks good to me. Regards Santosh -- 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] OMAP: powerdomains: Make all powerdomain target states as ON at init
Hi, On Fri, 15 Jul 2011, Felipe Balbi wrote: > How about something like: > > /* > * Program target state of all power domains to ON. This is to prevent > * power domains from hitting low power states during boot up and > * potentially causing accesses to the address space of an IP while it > * is disabled. > * > * PM late init code will make sure of disabling all unused IPs later. > */ > > not sure if it's a lot better though. It's not directly related to accesses to the IP block's address space. The problem happens when the driver (or the hwmod code) for a particular device causes the last clock in a clockdomain to be disabled. This allows the clockdomain to go INACTIVE. At that point, if all of the clockdomains in the powerdomain are INACTIVE, the powerdomain itself will switch to its "next power state". If the bootloader had programmed the next power state to be OFF, for example, then all devices in that powerdomain will lose context. If this happens before the PM code initializes, or if the PM code is not compiled in, then this will cause some strange behavior or crashes, since the kernel won't be expecting devices to lose their context at that point. - 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
Re: [PATCH] OMAP: powerdomains: Make all powerdomain target states as ON at init
Hi everyone
I've tweaked this patch a little bit. Please let me know if you have any
issues with it ASAP,
thanks,
- Paul
From: Rajendra Nayak
Date: Tue, 16 Aug 2011 15:22:58 -0600
Subject: [PATCH] OMAP: powerdomains: Make all powerdomain target states as ON
at init
Program all powerdomain target state as ON; this is to prevent domains
from hitting low power states (if bootloader has target states set to
something other than ON) and potentially even losing context while PM
is not fully initialized, which can cause the system to crash. The PM
late init code can then program the desired target state for all the
power domains.
Signed-off-by: Rajendra Nayak
Signed-off-by: Santosh Shilimkar
[p...@pwsan.com: dropped comment typo hunk; fixed comment indent and moved
to kerneldoc; moved code to pwrdm_init(); changed pwrdm_init() argument name
to prevent clash; cleaned up patch description]
Signed-off-by: Paul Walmsley
---
arch/arm/mach-omap2/powerdomain.c | 25 -
1 files changed, 16 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-omap2/powerdomain.c
b/arch/arm/mach-omap2/powerdomain.c
index 9af0847..ef71fdd 100644
--- a/arch/arm/mach-omap2/powerdomain.c
+++ b/arch/arm/mach-omap2/powerdomain.c
@@ -195,28 +195,35 @@ static int _pwrdm_post_transition_cb(struct powerdomain
*pwrdm, void *unused)
/**
* pwrdm_init - set up the powerdomain layer
- * @pwrdm_list: array of struct powerdomain pointers to register
+ * @pwrdms: array of struct powerdomain pointers to register
* @custom_funcs: func pointers for arch specific implementations
*
- * Loop through the array of powerdomains @pwrdm_list, registering all
- * that are available on the current CPU. If pwrdm_list is supplied
- * and not null, all of the referenced powerdomains will be
- * registered. No return value. XXX pwrdm_list is not really a
- * "list"; it is an array. Rename appropriately.
+ * Loop through the array of powerdomains @pwrdms, registering all
+ * that are available on the current CPU. Also, program all
+ * powerdomain target state as ON; this is to prevent domains from
+ * hitting low power states (if bootloader has target states set to
+ * something other than ON) and potentially even losing context while
+ * PM is not fully initialized. The PM late init code can then program
+ * the desired target state for all the power domains. No return
+ * value.
*/
-void pwrdm_init(struct powerdomain **pwrdm_list, struct pwrdm_ops
*custom_funcs)
+void pwrdm_init(struct powerdomain **pwrdms, struct pwrdm_ops *custom_funcs)
{
struct powerdomain **p = NULL;
+ struct powerdomain *temp_p;
if (!custom_funcs)
WARN(1, "powerdomain: No custom pwrdm functions registered\n");
else
arch_pwrdm = custom_funcs;
- if (pwrdm_list) {
- for (p = pwrdm_list; *p; p++)
+ if (pwrdms) {
+ for (p = pwrdms; *p; p++)
_pwrdm_register(*p);
}
+
+ list_for_each_entry(temp_p, &pwrdm_list, node)
+ pwrdm_set_next_pwrst(temp_p, PWRDM_POWER_ON);
}
/**
--
1.7.5.4
--
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] OMAP: clockdomain: Wait for powerdomain to be ON when using clockdomain force wakeup
Hi everyone
I've updated this patch per my earlier comments and also to apply.
Please let me know if you have any issues with it ASAP.
- Paul
From: Santosh Shilimkar
Date: Sat, 13 Aug 2011 08:56:28 +0530
Subject: [PATCH] [PATCH] OMAP: clockdomain: Wait for powerdomain to be ON
when using clockdomain force wakeup
While using clockdomain force wakeup method, not waiting for powerdomain
to be effectively ON may end up locking the clockdomain FSM until a
next wakeup event occurs.
One such issue was seen on OMAP4430, where L4_PER was periodically
getting stuck in in-transition state when transitioning from from OSWR to ON.
This issue was reported and investigated by Patrick Titiano
Signed-off-by: Santosh Shilimkar
Signed-off-by: Rajendra Nayak
Reported-by: Patrick Titiano
Cc: Kevin Hilman
Cc: Benoit Cousson
Cc: Paul Walmsley
[p...@pwsan.com: updated to apply; added transition wait on clkdm_deny_idle();
remove two superfluous pwrdm_wait_transition() calls]
Signed-off-by: Paul Walmsley
---
arch/arm/mach-omap2/clockdomain.c |2 ++
arch/arm/mach-omap2/pm.c |2 --
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/clockdomain.c
b/arch/arm/mach-omap2/clockdomain.c
index ab7db08..8f08906 100644
--- a/arch/arm/mach-omap2/clockdomain.c
+++ b/arch/arm/mach-omap2/clockdomain.c
@@ -747,6 +747,7 @@ int clkdm_wakeup(struct clockdomain *clkdm)
spin_lock_irqsave(&clkdm->lock, flags);
clkdm->_flags &= ~_CLKDM_FLAG_HWSUP_ENABLED;
ret = arch_clkdm->clkdm_wakeup(clkdm);
+ ret |= pwrdm_state_switch(clkdm->pwrdm.ptr);
spin_unlock_irqrestore(&clkdm->lock, flags);
return ret;
}
@@ -818,6 +819,7 @@ void clkdm_deny_idle(struct clockdomain *clkdm)
spin_lock_irqsave(&clkdm->lock, flags);
clkdm->_flags &= ~_CLKDM_FLAG_HWSUP_ENABLED;
arch_clkdm->clkdm_deny_idle(clkdm);
+ pwrdm_state_switch(clkdm->pwrdm.ptr);
spin_unlock_irqrestore(&clkdm->lock, flags);
}
diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
index 3feb359..472bf22 100644
--- a/arch/arm/mach-omap2/pm.c
+++ b/arch/arm/mach-omap2/pm.c
@@ -130,7 +130,6 @@ int omap_set_pwrdm_state(struct powerdomain *pwrdm, u32
state)
} else {
hwsup = clkdm_in_hwsup(pwrdm->pwrdm_clkdms[0]);
clkdm_wakeup(pwrdm->pwrdm_clkdms[0]);
- pwrdm_wait_transition(pwrdm);
sleep_switch = FORCEWAKEUP_SWITCH;
}
}
@@ -156,7 +155,6 @@ int omap_set_pwrdm_state(struct powerdomain *pwrdm, u32
state)
return ret;
}
- pwrdm_wait_transition(pwrdm);
pwrdm_state_switch(pwrdm);
err:
return ret;
--
1.7.5.4
--
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 07/15] PM QoS: add a global notification mechanism for the device constraints
Hi, On Tuesday, August 16, 2011, jean.pi...@newoldbits.com wrote: > From: Jean Pihet > > Add a global notification chain that gets called upon changes to the > aggregated constraint value for any device. > The notification callbacks are passing the full constraint request data > in order for the callees to have access to it. The current use is for the > platform low-level code to access the target device of the constraint. > > Signed-off-by: Jean Pihet > --- > drivers/base/power/qos.c | 84 > -- > include/linux/pm_qos.h | 11 ++ > kernel/power/qos.c |2 +- > 3 files changed, 78 insertions(+), 19 deletions(-) > > diff --git a/drivers/base/power/qos.c b/drivers/base/power/qos.c > index 304d68d..b52b3e8 100644 > --- a/drivers/base/power/qos.c > +++ b/drivers/base/power/qos.c > @@ -8,6 +8,12 @@ > * > * This QoS design is best effort based. Dependents register their QoS needs. > * Watchers register to keep track of the current QoS needs of the system. > + * Watchers can register different types of notification callbacks: > + * . a per-device notification callback using the dev_pm_qos_*_notifier API. > + *The notification chain data is stored in the per-device constraint > + *data struct. > + * . a system-wide notification callback using the > dev_pm_qos_*_global_notifier > + *API. The notification chain data is stored in a static variable. > * > * Note about the per-device constraint data struct allocation: > * . The per-device constraints data struct ptr is tored into the device > @@ -36,8 +42,32 @@ > > > static DEFINE_MUTEX(dev_pm_qos_mtx); > +static BLOCKING_NOTIFIER_HEAD(dev_pm_notifiers); > static void dev_pm_qos_constraints_allocate(struct device *dev); > > +/* > + * Update the constraints list using the PM QoS core code and > + * if needed call the per-device and the global notification callbacks > + */ Well, if you add kerneldoc comments, please make them follow the standard, even if that's a static function. > +static int _apply_constraint(struct dev_pm_qos_request *req, The initial underscore looks odd and is not really necessary. Please drop it. The rest of the patch looks fine. 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 06/15] PM QoS: implement the per-device PM QoS constraints
Hi,
On Tuesday, August 16, 2011, jean.pi...@newoldbits.com wrote:
> From: Jean Pihet
>
> Implement the per-device PM QoS constraints by creating a device
> PM QoS API, which calls the PM QoS constraints management core code.
>
> The per-device latency constraints data strctures are stored
> in the device dev_pm_info struct.
>
> The device PM code calls the init and destroy of the per-device constraints
> data struct in order to support the dynamic insertion and removal of the
> devices in the system.
>
> To minimize the data usage by the per-device constraints, the data struct
> is only allocated at the first call to dev_pm_qos_add_request.
> The data is later free'd when the device is removed from the system.
> A global mutex protects the constraints users from the data being
> allocated and free'd.
>
> Signed-off-by: Jean Pihet
> ---
> drivers/base/power/Makefile |4 +-
> drivers/base/power/main.c |3 +
> drivers/base/power/qos.c| 291
> +++
> include/linux/pm.h |9 ++
> include/linux/pm_qos.h | 42 ++
> 5 files changed, 347 insertions(+), 2 deletions(-)
> create mode 100644 drivers/base/power/qos.c
>
> diff --git a/drivers/base/power/Makefile b/drivers/base/power/Makefile
> index 2639ae7..b707447 100644
> --- a/drivers/base/power/Makefile
> +++ b/drivers/base/power/Makefile
> @@ -1,4 +1,4 @@
> -obj-$(CONFIG_PM) += sysfs.o generic_ops.o
> +obj-$(CONFIG_PM) += sysfs.o generic_ops.o qos.o
> obj-$(CONFIG_PM_SLEEP) += main.o wakeup.o
> obj-$(CONFIG_PM_RUNTIME) += runtime.o
> obj-$(CONFIG_PM_TRACE_RTC) += trace.o
> @@ -6,4 +6,4 @@ obj-$(CONFIG_PM_OPP) += opp.o
> obj-$(CONFIG_PM_GENERIC_DOMAINS) += domain.o
> obj-$(CONFIG_HAVE_CLK) += clock_ops.o
>
> -ccflags-$(CONFIG_DEBUG_DRIVER) := -DDEBUG
> \ No newline at end of file
> +ccflags-$(CONFIG_DEBUG_DRIVER) := -DDEBUG
> diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c
> index a854591..956443f 100644
> --- a/drivers/base/power/main.c
> +++ b/drivers/base/power/main.c
> @@ -22,6 +22,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -97,6 +98,7 @@ void device_pm_add(struct device *dev)
> dev_name(dev->parent));
> list_add_tail(&dev->power.entry, &dpm_list);
> mutex_unlock(&dpm_list_mtx);
> + dev_pm_qos_constraints_init(dev);
> }
>
> /**
> @@ -107,6 +109,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));
> + dev_pm_qos_constraints_destroy(dev);
> complete_all(&dev->power.completion);
> mutex_lock(&dpm_list_mtx);
> list_del_init(&dev->power.entry);
> diff --git a/drivers/base/power/qos.c b/drivers/base/power/qos.c
> new file mode 100644
> index 000..304d68d
> --- /dev/null
> +++ b/drivers/base/power/qos.c
> @@ -0,0 +1,291 @@
> +/*
Please add a copyright notice.
> + * This module exposes the interface to kernel space for specifying
> + * per-device PM QoS dependencies. It provides infrastructure for
> registration
> + * of:
> + *
> + * Dependents on a QoS value : register requests
> + * Watchers of QoS value : get notified when target QoS value changes
> + *
> + * This QoS design is best effort based. Dependents register their QoS needs.
> + * Watchers register to keep track of the current QoS needs of the system.
> + *
> + * Note about the per-device constraint data struct allocation:
> + * . The per-device constraints data struct ptr is tored into the device
> + *dev_pm_info.
> + * . To minimize the data usage by the per-device constraints, the data
> struct
> + * is only allocated at the first call to dev_pm_qos_add_request.
> + * . The data is later free'd when the device is removed from the system.
> + * . The constraints_state variable from dev_pm_info tracks the data struct
> + *allocation state:
> + *DEV_PM_QOS_NO_DEVICE: No device present or device removed, no data
> + * allocated,
> + *DEV_PM_QOS_DEVICE_PRESENT: Device present, data not allocated and will
> be
> + * allocated at the first call to dev_pm_qos_add_request,
> + *DEV_PM_QOS_ALLOCATED: Device present, data allocated. The per-device
> + * PM QoS constraints framework is operational and constraints can be
> + * added, updated or removed using the dev_pm_qos_* API.
> + * . A global mutex protects the constraints users from the data being
> + * allocated and free'd.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +
> +static DEFINE_MUTEX(dev_pm_qos_mtx);
> +static void dev_pm_qos_constraints_allocate(struct device *dev);
This header wouldn't be necessary if you put the definition of
dev_pm_qos_constraints_allocate() before dev_pm_qos_add_request().
> +
> +/**
> + * dev_pm_qos_add_request - inserts new qos request into the list
> + * @dev
Re: [RFC/PATCH 14/14] dt: omap3: enable dt support for i2c1 controller
On Wed, Aug 10, 2011 at 02:57:21PM +0200, Cousson, Benoit wrote:
> On 8/9/2011 4:10 PM, G, Manjunath Kondaiah wrote:
> >
> >Adapt dt for omap i2c1 controller and remove legacy i2c
> >initilization in omap3 generic board file.
> >
> >Tested on omap3 beagle board for dt and non-dt builds.
> >
> >Signed-off-by: G, Manjunath Kondaiah
> >---
> > arch/arm/boot/dts/omap3-soc.dtsi |6 ++--
> > arch/arm/mach-omap2/board-omap3-dt.c | 14 +-
> > drivers/i2c/busses/i2c-omap.c| 23 --
> > drivers/of/platform.c| 41
> > +-
>
> It looks like this patch is doing a lot of things. You should
> probably hack the DT core first and then update the driver and the
> DTS.
>
> > 4 files changed, 70 insertions(+), 14 deletions(-)
> >
> >diff --git a/arch/arm/boot/dts/omap3-soc.dtsi
> >b/arch/arm/boot/dts/omap3-soc.dtsi
> >index 85de92f..bcff63b 100644
> >--- a/arch/arm/boot/dts/omap3-soc.dtsi
> >+++ b/arch/arm/boot/dts/omap3-soc.dtsi
> >@@ -31,7 +31,7 @@
> > i2c1: i2c@7 {
> > #address-cells =<1>;
> > #size-cells =<0>;
> >-compatible = "ti,omap3-i2c";
> >+compatible = "ti,omap3-i2c", "ti,omap3-device";
>
> In that case the compatible is just a tagto identify an OMAP type of
> devices. You should use a more generic "ti,omap-device" entry.
> This is similar to the "arm,primecell" used to tag the primecell IPs.
>
> > reg =<0x7 0x100>;
> > interrupts =< 88>;
> > };
> >@@ -39,7 +39,7 @@
> > i2c2: i2c@72000 {
> > #address-cells =<1>;
> > #size-cells =<0>;
> >-compatible = "ti,omap3-i2c";
> >+compatible = "ti,omap3-i2c", "ti,omap3-device";
> > reg =<0x72000 0x100>;
> > interrupts =< 89>;
> > };
> >@@ -47,7 +47,7 @@
> > i2c3: i2c@6 {
> > #address-cells =<1>;
> > #size-cells =<0>;
> >-compatible = "ti,omap3-i2c";
> >+compatible = "ti,omap3-i2c", "ti,omap3-device";
> > reg =<0x6 0x100>;
> > interrupts =< 93>;
> > };
> >diff --git a/arch/arm/mach-omap2/board-omap3-dt.c
> >b/arch/arm/mach-omap2/board-omap3-dt.c
> >index 4b76e19..16cf283 100644
> >--- a/arch/arm/mach-omap2/board-omap3-dt.c
> >+++ b/arch/arm/mach-omap2/board-omap3-dt.c
> >@@ -36,11 +36,11 @@ static struct twl4030_platform_data beagle_twldata = {
> > /* platform_data for children goes here */
> > };
> >
> >-static int __init omap3_beagle_i2c_init(void)
> >-{
> >-omap3_pmic_init("twl4030",&beagle_twldata);
> >-return 0;
> >-}
> >+struct of_dev_auxdata omap3_auxdata_lookup[] __initdata = {
> >+OF_DEV_AUXDATA_ID_PDSIZE("ti,omap3-i2c", 0x4807, "i2c1", 1,\
> >+&beagle_twldata, sizeof(beagle_twldata)),
> >+{}
> >+};
> >
> > static void __init omap3_init_early(void)
> > {
> >@@ -70,11 +70,11 @@ static struct of_device_id omap_dt_match_table[]
> >__initdata = {
> >
> > static void __init omap3_init(void)
> > {
> >-omap3_beagle_i2c_init();
> > omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
> > omap_serial_init();
> >
> >-of_platform_populate(NULL, omap_dt_match_table, NULL, NULL);
> >+of_platform_populate(NULL, omap_dt_match_table, omap3_auxdata_lookup,
> >+ NULL);
> > }
> >
> > static const char *omap3_dt_match[] __initdata = {
> >diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
> >index ae1545b..5167737 100644
> >--- a/drivers/i2c/busses/i2c-omap.c
> >+++ b/drivers/i2c/busses/i2c-omap.c
> >@@ -38,6 +38,7 @@
> > #include
> > #include
> > #include
> >+#include
> > #include
> > #include
> > #include
> >@@ -972,6 +973,16 @@ static const struct i2c_algorithm omap_i2c_algo = {
> > .functionality = omap_i2c_func,
> > };
> >
> >+#if defined(CONFIG_OF)
> >+static const struct of_device_id omap_i2c_of_match[] = {
> >+{.compatible = "ti,omap3-i2c", },.
>
> This is a generic OMAP driver, so a "ti,omap-i2c" is probably much
> more appropriate. We should always avoid adding OMAP version
> information into a generic driver. Only the IP version should matter
> for a driver.
>
> >+{},
> >+}
> >+MODULE_DEVICE_TABLE(of, omap_i2c_of_match);
> >+#else
> >+#define omap_i2c_of_match NULL
> >+#endif
> >+
> > static int __devinit
> > omap_i2c_probe(struct platform_device *pdev)
> > {
> >@@ -1008,12 +1019,17 @@ omap_i2c_probe(struct platform_device *pdev)
> > goto err_release_region;
> > }
> >
> >+speed = 100;/* Default speed */
> > if (pdata != NULL) {
> > speed = pdata->clkrate;
> > dev->set_mpu_wkup_lat = pdata->set_mpu_wku
Re: [PATCH 05/15] PM QoS: generalize and export the constraints management code
On Tuesday, August 16, 2011, mark gross wrote:
> On Tue, Aug 16, 2011 at 08:44:19AM +0200, Jean Pihet wrote:
> > On Tue, Aug 16, 2011 at 6:08 AM, mark gross wrote:
> > > On Sun, Aug 14, 2011 at 03:37:43PM +0200, Rafael J. Wysocki wrote:
> > >> On Sunday, August 14, 2011, Jean Pihet wrote:
> > >> > Hi Rafael, Mark,
> > >> >
> > >> > On Sat, Aug 13, 2011 at 10:34 PM, Rafael J. Wysocki
> > >> > wrote:
> > >> > > On Saturday, August 13, 2011, mark gross wrote:
> > >> > >> On Thu, Aug 11, 2011 at 05:06:42PM +0200, jean.pi...@newoldbits.com
> > >> > >> wrote:
> > >> > >> > From: Jean Pihet
> > >> > >> >
> > >> > >> > In preparation for the per-device constratins support:
> > >> > >> > - rename update_target to pm_qos_update_target
> > >> > >> > - generalize and export pm_qos_update_target for usage by the
> > >> > >> > upcoming
> > >> > >> > per-device latency constraints framework:
> > >> > >> >. operate on struct pm_qos_constraints for constraints
> > >> > >> > management,
> > >> > >> >. introduce an 'action' parameter for constraints
> > >> > >> > add/update/remove,
> > >> > >> >. the return value indicates if the aggregated constraint
> > >> > >> > value has
> > >> > >> > changed,
> > >> > >> > - update the internal code to operate on struct pm_qos_constraints
> > >> > >> > - add a NULL pointer check in the API functions
> > >> > >> >
> > >> > >> > Signed-off-by: Jean Pihet
> > >> > ...
> > >> > >> > +/* Action requested to pm_qos_update_target */
> > >> > >> > +enum pm_qos_req_action {
> > >> > >> > + PM_QOS_ADD_REQ, /* Add a new request */
> > >> > >> > + PM_QOS_UPDATE_REQ, /* Update an existing request */
> > >> > >> > + PM_QOS_REMOVE_REQ /* Remove an existing request */
> > >> > >> > +};
> > >> > >> > +
> > >> > >>
> > >> > >> What do you need this enum for? The function names *_update_*,
> > >> > >> *_add_*,
> > >> > >> and *_remove_* seem to be pretty redundant if you have to pass an
> > >> > >> enum
> > >> > >> that could possibly conflict with the function name.
> > >> > >>
> > >> > >> > #ifdef CONFIG_PM
> > >> > >> > +int pm_qos_update_target(struct pm_qos_constraints *c, struct
> > >> > >> > plist_node *node,
> > >> > >> > +enum pm_qos_req_action action, int value);
> > >> > >> The action for update_target better damn well be
> > >> > >> "PM_QOS_UPDATE_REQ" or
> > >> > >> there is something strange going on BTW what shold this
> > >> > >> function do
> > >> > >> if the pm_qos_req_action was *not* the UPDATE one?
> > >> >
> > >> > The meaning of pm_qos_update_target is 'update the PM QoS target
> > >> > constraints lists'. As described in the changelog the intention of
> > >> > this patch is to implement the constraints lists management logic in
> > >> > update_target and simplify the API functions (add/update/remove). It
> > >> > is also exported for the upcoming (patch 06/15]) to use it as well.
> > >>
> > >> The enums are fine by me and they allow us to simplify the code
> > >> quite a bit.
> > >>
> > > Ok, but they look a bit sloppy to me as we now have an API that says
> > > "add" we can actually pass in an enum that says "remove".
> > We have an API that says 'update target' that we pass in a parameter
> > that says 'add request', 'update request' or 'remove request'.
> > If it is required I could just rename the internal function
> > update_target, in a later patch.
>
> You are right. I thought I saw the enum added to the other API's for
> some reason. Still, with this update we have an API overloaded through
> that enum parameter providing 2 add, 2 delete and 2 update API's Each
> pair doing about the same thing.
>
> To me it feels like a baby step toward an ioctl type of API that I don't
> like. I'm not going to fight about it any more but I don't like such
> API's as they tend to get hard to read and get out of control.
>
> please rethink this a little.
For real _users_, the API is still "add", "update" and "remove",
but _internally_ those functions use the same "worker" routine with an
argument specifying the operation to carry out. This reduces code
duplication quite a bit and it quite common in the kernel.
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 05/15] PM QoS: generalize and export the constraints management code
On Tue, Aug 16, 2011 at 08:44:19AM +0200, Jean Pihet wrote:
> On Tue, Aug 16, 2011 at 6:08 AM, mark gross wrote:
> > On Sun, Aug 14, 2011 at 03:37:43PM +0200, Rafael J. Wysocki wrote:
> >> On Sunday, August 14, 2011, Jean Pihet wrote:
> >> > Hi Rafael, Mark,
> >> >
> >> > On Sat, Aug 13, 2011 at 10:34 PM, Rafael J. Wysocki wrote:
> >> > > On Saturday, August 13, 2011, mark gross wrote:
> >> > >> On Thu, Aug 11, 2011 at 05:06:42PM +0200, jean.pi...@newoldbits.com
> >> > >> wrote:
> >> > >> > From: Jean Pihet
> >> > >> >
> >> > >> > In preparation for the per-device constratins support:
> >> > >> > - rename update_target to pm_qos_update_target
> >> > >> > - generalize and export pm_qos_update_target for usage by the
> >> > >> > upcoming
> >> > >> > per-device latency constraints framework:
> >> > >> > . operate on struct pm_qos_constraints for constraints
> >> > >> > management,
> >> > >> > . introduce an 'action' parameter for constraints
> >> > >> > add/update/remove,
> >> > >> > . the return value indicates if the aggregated constraint value
> >> > >> > has
> >> > >> > changed,
> >> > >> > - update the internal code to operate on struct pm_qos_constraints
> >> > >> > - add a NULL pointer check in the API functions
> >> > >> >
> >> > >> > Signed-off-by: Jean Pihet
> >> > ...
> >> > >> > +/* Action requested to pm_qos_update_target */
> >> > >> > +enum pm_qos_req_action {
> >> > >> > + PM_QOS_ADD_REQ, /* Add a new request */
> >> > >> > + PM_QOS_UPDATE_REQ, /* Update an existing request */
> >> > >> > + PM_QOS_REMOVE_REQ /* Remove an existing request */
> >> > >> > +};
> >> > >> > +
> >> > >>
> >> > >> What do you need this enum for? The function names *_update_*,
> >> > >> *_add_*,
> >> > >> and *_remove_* seem to be pretty redundant if you have to pass an
> >> > >> enum
> >> > >> that could possibly conflict with the function name.
> >> > >>
> >> > >> > #ifdef CONFIG_PM
> >> > >> > +int pm_qos_update_target(struct pm_qos_constraints *c, struct
> >> > >> > plist_node *node,
> >> > >> > + enum pm_qos_req_action action, int value);
> >> > >> The action for update_target better damn well be "PM_QOS_UPDATE_REQ"
> >> > >> or
> >> > >> there is something strange going on BTW what shold this function
> >> > >> do
> >> > >> if the pm_qos_req_action was *not* the UPDATE one?
> >> >
> >> > The meaning of pm_qos_update_target is 'update the PM QoS target
> >> > constraints lists'. As described in the changelog the intention of
> >> > this patch is to implement the constraints lists management logic in
> >> > update_target and simplify the API functions (add/update/remove). It
> >> > is also exported for the upcoming (patch 06/15]) to use it as well.
> >>
> >> The enums are fine by me and they allow us to simplify the code
> >> quite a bit.
> >>
> > Ok, but they look a bit sloppy to me as we now have an API that says
> > "add" we can actually pass in an enum that says "remove".
> We have an API that says 'update target' that we pass in a parameter
> that says 'add request', 'update request' or 'remove request'.
> If it is required I could just rename the internal function
> update_target, in a later patch.
You are right. I thought I saw the enum added to the other API's for
some reason. Still, with this update we have an API overloaded through
that enum parameter providing 2 add, 2 delete and 2 update API's Each
pair doing about the same thing.
To me it feels like a baby step toward an ioctl type of API that I don't
like. I'm not going to fight about it any more but I don't like such
API's as they tend to get hard to read and get out of control.
please rethink this a little.
--mark
--
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: [stable] [PATCH 1/1] OMAP: wlan: Set the WLAN Regulator to be always on
On Tue, Aug 16, 2011 at 10:03:57AM -0500, panduranga_mallire...@ti.com wrote: > From: Panduranga Mallireddy > > For regulator omap4_clk32k used by wlan, set .constraints.always_on to 1. > This regulator should never be disabled. > > Signed-off-by: Panduranga Mallireddy > --- > arch/arm/mach-omap2/twl-common.c |1 + > 1 files changed, 1 insertions(+), 0 deletions(-) This is not the correct way to submit patches for inclusion in the stable kernel tree. Please read Documentation/stable_kernel_rules.txt for how to do this properly. -- 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: [RFC/PATCH 09/14] dt: omap: prepare hwmod to support dt
On Wed, Aug 10, 2011 at 09:58:46PM +0530, G, Manjunath Kondaiah wrote:
> On Wed, Aug 10, 2011 at 01:51:47PM +0200, Cousson, Benoit wrote:
> > Hi Manju,
> >
> > On 8/9/2011 4:10 PM, G, Manjunath Kondaiah wrote:
> > >
> > >The omap dt requires new omap hwmod api to be added for in order
> > >to support omap dt.
> >
> > Both the subject and the changelog are misleading. You are not doing
> > any hwmod stuff in it.
> > You are just passing an "of_node" pointer during omap_device_build_ss.
> >
> > The subject should start with OMAP: omap_device: because it does not
> > belong to the DT subsystem.
> > The same comment apply to most patches in that series.
>
> The goal of this patch is to make omap-hwmod ready for dt adaptation hence
> I used the title "dt: omap: prepare hwmod to support dt" and "of_node" pointer
> is passed from dt and it is required for dt build.
>
> And as you mentioned, patch does not do anything related to omap_device.
>
> >
> > >The new api is added and new parameter "np" is added for existing
> > >api.
> >
> > I don't think np is not a super meaningful name. Some more
> > explanation are needed as well.
>
> ok. I can expand it.
>
> >
> > >The users of hwmod api is changed accrodingly.
> >
> > omap_device API + typo.
> >
> > >Build and boot tested on omap3 beagle for both dt and not dt build.
> > >
> > >Signed-off-by: G, Manjunath Kondaiah
> > >---
> > > arch/arm/mach-omap2/devices.c |2 +-
> > > arch/arm/mach-omap2/mcbsp.c |2 +-
> > > arch/arm/plat-omap/include/plat/omap_device.h | 11 +-
> > > arch/arm/plat-omap/omap_device.c | 53
> > > ++---
> > > 4 files changed, 59 insertions(+), 9 deletions(-)
> > >
> > >diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
> > >index 458f7be..d7ff1ae 100644
> > >--- a/arch/arm/mach-omap2/devices.c
> > >+++ b/arch/arm/mach-omap2/devices.c
> > >@@ -92,7 +92,7 @@ static int __init omap4_l3_init(void)
> > > pr_err("could not look up %s\n", oh_name);
> > > }
> > >
> > >- pdev = omap_device_build_ss("omap_l3_noc", 0, oh, 3, NULL,
> > >+ pdev = omap_device_build_ss(NULL, "omap_l3_noc", 0, oh, 3, NULL,
> > >0, NULL, 0, 0);
> >
> > OK, maybe that is just me, but in order to extend an API, I'd rather
> > add the new parameter at the end.
>
> I feel it's fine since node pointer is first parameter is all dt api's.
>
> >
> > > WARN(IS_ERR(pdev), "could not build omap_device for %s\n", oh_name);
> > >diff --git a/arch/arm/mach-omap2/mcbsp.c b/arch/arm/mach-omap2/mcbsp.c
> > >index 7a42f32..98eb95d 100644
> > >--- a/arch/arm/mach-omap2/mcbsp.c
> > >+++ b/arch/arm/mach-omap2/mcbsp.c
> > >@@ -144,7 +144,7 @@ static int omap_init_mcbsp(struct omap_hwmod *oh, void
> > >*unused)
> > > (struct omap_mcbsp_dev_attr *)(oh->dev_attr))->sidetone);
> > > count++;
> > > }
> > >- pdev = omap_device_build_ss(name, id, oh_device, count, pdata,
> > >+ pdev = omap_device_build_ss(NULL, name, id, oh_device, count, pdata,
> > > sizeof(*pdata), omap2_mcbsp_latency,
> > > ARRAY_SIZE(omap2_mcbsp_latency), false);
> > > kfree(pdata);
> > >diff --git a/arch/arm/plat-omap/include/plat/omap_device.h
> > >b/arch/arm/plat-omap/include/plat/omap_device.h
> > >index 7a3ec4f..5e2424b 100644
> > >--- a/arch/arm/plat-omap/include/plat/omap_device.h
> > >+++ b/arch/arm/plat-omap/include/plat/omap_device.h
> > >@@ -33,6 +33,7 @@
> > >
> > > #include
> > > #include
> > >+#include
> > >
> > > #include
> > >
> > >@@ -89,12 +90,20 @@ struct platform_device *omap_device_build(const char
> > >*pdev_name, int pdev_id,
> > > struct omap_device_pm_latency *pm_lats,
> > > int pm_lats_cnt, int is_early_device);
> > >
> > >-struct platform_device *omap_device_build_ss(const char *pdev_name, int
> > >pdev_id,
> > >+struct platform_device *omap_device_build_ss(struct device_node *np,
> > >+ const char *pdev_name, int pdev_id,
> > >struct omap_hwmod **oh, int oh_cnt,
> > >void *pdata, int pdata_len,
> > >struct omap_device_pm_latency *pm_lats,
> > >int pm_lats_cnt, int is_early_device);
> > >
> > >+struct platform_device *omap_device_build_dt(struct device_node *np,
> > >+const char *pdev_name, int pdev_id,
> > >+struct omap_hwmod *oh, void *pdata,
> > >+int pdata_len,
> > >+struct omap_device_pm_latency *pm_lats,
> > >+int pm_lats_cnt, int is_early_device);
> > >+
> > > void __iomem *omap_device_get_rt_va(struct omap_device *od);
> > >
> > >
Re: [PATCH 12/15] OMAP4: powerdomain data: add wake-up latency figures
On Tuesday 16 August 2011 08:08 PM, Jean Pihet wrote: On Tue, Aug 16, 2011 at 4:26 PM, Santosh wrote: On Tuesday 16 August 2011 07:13 PM, jean.pi...@newoldbits.com wrote: From: Vishwanath BS This patch adds wake up latency numbers for OMAP4. Note that these are preliminary numbers and need to be relooked. Signed-off-by: Vishwanath BS The INACTIVE state is added as unsupported. In that case, don't add that support in first place. When INA support is getting added, you can update these as well. No. A value is needed for all states, even if unsupported at the moment. Omitting a value causes it to be set to '0', which means 'no latency'. What I am saying is don't add "PWRDM_FUNC_PWRST_INACTIVE" which is not supported. Then you won't even have that state and no need of latency number for that in the current series. Regards Santosh -- 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 12/15] OMAP4: powerdomain data: add wake-up latency figures
On Tue, Aug 16, 2011 at 4:26 PM, Santosh wrote: > On Tuesday 16 August 2011 07:13 PM, jean.pi...@newoldbits.com wrote: >> >> From: Vishwanath BS >> >> This patch adds wake up latency numbers for OMAP4. Note that these are >> preliminary numbers and need to be relooked. >> >> Signed-off-by: Vishwanath BS >> >> The INACTIVE state is added as unsupported. >> > In that case, don't add that support in first place. When INA support is > getting added, you can update these as well. No. A value is needed for all states, even if unsupported at the moment. Omitting a value causes it to be set to '0', which means 'no latency'. 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 11/15] OMAP3: powerdomain data: add wake-up latency figures
On Tuesday 16 August 2011 08:04 PM, Jean Pihet wrote:
On Tue, Aug 16, 2011 at 4:25 PM, Santosh wrote:
On Tuesday 16 August 2011 07:13 PM, jean.pi...@newoldbits.com wrote:
From: Jean Pihet
Figures are added to the power domains structs.
Note: the figures are preliminary figures. More accurate measurements
are needed. Also the conditions of measurements shall be investigated
and described.
Tested on OMAP3 Beagleboard in RET/OFF using wake-up latency constraints
on MPU, CORE and PER.
Signed-off-by: Jean Pihet
---
arch/arm/mach-omap2/powerdomains3xxx_data.c | 77
+++
1 files changed, 77 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/powerdomains3xxx_data.c
b/arch/arm/mach-omap2/powerdomains3xxx_data.c
index 469a920..64446e7 100644
--- a/arch/arm/mach-omap2/powerdomains3xxx_data.c
+++ b/arch/arm/mach-omap2/powerdomains3xxx_data.c
@@ -31,6 +31,13 @@
/*
* Powerdomains
+ *
+ * The wakeup_lat values are derived from measurements on
+ * the actual target.
+ *
+ * Note: the latency figures are preliminary and only used
+ * for the constraints framework validation.
+ * Actual figures and measurements conditions shall be added.
*/
static struct powerdomain iva2_pwrdm = {
@@ -52,6 +59,13 @@ static struct powerdomain iva2_pwrdm = {
[2] = PWRSTS_OFF_ON,
[3] = PWRSTS_ON,
},
+ .wakeup_lat = {
+ [PWRDM_FUNC_PWRST_OFF] = 1100,
+ [PWRDM_FUNC_PWRST_OSWR] = UNSUP_STATE,
+ [PWRDM_FUNC_PWRST_CSWR] = 350,
+ [PWRDM_FUNC_PWRST_INACTIVE] = UNSUP_STATE,
This can easily derived from the PWRST flag instead of hardcoding
it this way. Also note that INACTIVE PD isn't supported in mainline
yet because of voltage-domain dependency planned changes.
+ [PWRDM_FUNC_PWRST_ON] = 0,
All of the PD structures are manually coded. This whole file is
auto-generated and even these field generation needs to follow
that path.
Ok I need to check that. Any pointer on how to generate those?
The scripts needs to be updated to generate this additional information.
Will send you some pointer off the list.
Regards
Santosh
--
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 11/15] OMAP3: powerdomain data: add wake-up latency figures
On Tue, Aug 16, 2011 at 4:25 PM, Santosh wrote:
> On Tuesday 16 August 2011 07:13 PM, jean.pi...@newoldbits.com wrote:
>>
>> From: Jean Pihet
>>
>> Figures are added to the power domains structs.
>>
>> Note: the figures are preliminary figures. More accurate measurements
>> are needed. Also the conditions of measurements shall be investigated
>> and described.
>>
>> Tested on OMAP3 Beagleboard in RET/OFF using wake-up latency constraints
>> on MPU, CORE and PER.
>>
>> Signed-off-by: Jean Pihet
>> ---
>> arch/arm/mach-omap2/powerdomains3xxx_data.c | 77
>> +++
>> 1 files changed, 77 insertions(+), 0 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/powerdomains3xxx_data.c
>> b/arch/arm/mach-omap2/powerdomains3xxx_data.c
>> index 469a920..64446e7 100644
>> --- a/arch/arm/mach-omap2/powerdomains3xxx_data.c
>> +++ b/arch/arm/mach-omap2/powerdomains3xxx_data.c
>> @@ -31,6 +31,13 @@
>>
>> /*
>> * Powerdomains
>> + *
>> + * The wakeup_lat values are derived from measurements on
>> + * the actual target.
>> + *
>> + * Note: the latency figures are preliminary and only used
>> + * for the constraints framework validation.
>> + * Actual figures and measurements conditions shall be added.
>> */
>>
>> static struct powerdomain iva2_pwrdm = {
>> @@ -52,6 +59,13 @@ static struct powerdomain iva2_pwrdm = {
>> [2] = PWRSTS_OFF_ON,
>> [3] = PWRSTS_ON,
>> },
>> + .wakeup_lat = {
>> + [PWRDM_FUNC_PWRST_OFF] = 1100,
>> + [PWRDM_FUNC_PWRST_OSWR] = UNSUP_STATE,
>> + [PWRDM_FUNC_PWRST_CSWR] = 350,
>> + [PWRDM_FUNC_PWRST_INACTIVE] = UNSUP_STATE,
>
> This can easily derived from the PWRST flag instead of hardcoding
> it this way. Also note that INACTIVE PD isn't supported in mainline
> yet because of voltage-domain dependency planned changes.
>
>> + [PWRDM_FUNC_PWRST_ON] = 0,
>
> All of the PD structures are manually coded. This whole file is
> auto-generated and even these field generation needs to follow
> that path.
Ok I need to check that. Any pointer on how to generate those?
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
[PATCH] ARM: OMAP: Pointers to __devexit should be __devexit_p
Pointers to functions that are annotated as __devexit should be
protected by the __devexit_p() macro.
This fixes a build failure for OMAP when defined(CONFIG_SMP_ON_UP) &&
!defined(CONFIG_DEBUG_SPINLOCK)
Signed-off-by: Bjarne Steinsbo
---
arch/arm/mach-omap2/smartreflex.c |2 +-
arch/arm/plat-omap/dma.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/smartreflex.c
b/arch/arm/mach-omap2/smartreflex.c
index 34c01a7..67bc6ce 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -1002,7 +1002,7 @@ static int __devexit omap_sr_remove(struct
platform_device *pdev)
}
static struct platform_driver smartreflex_driver = {
- .remove = omap_sr_remove,
+ .remove = __devexit_p(omap_sr_remove),
.driver = {
.name = "smartreflex",
},
diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c
index c22217c..f7150ba 100644
--- a/arch/arm/plat-omap/dma.c
+++ b/arch/arm/plat-omap/dma.c
@@ -2105,7 +2105,7 @@ static int __devexit
omap_system_dma_remove(struct platform_device *pdev)
static struct platform_driver omap_system_dma_driver = {
.probe = omap_system_dma_probe,
- .remove = omap_system_dma_remove,
+ .remove = __devexit_p(omap_system_dma_remove),
.driver = {
.name = "omap_dma_system"
},
--
1.7.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] DMAEngine: Define generic transfer request api
On 16 August 2011 18:26, Koul, Vinod wrote:
> On Fri, 2011-08-12 at 16:44 +0530, Jassi Brar wrote:
>> Define a new api that could be used for doing fancy data transfers
>> like interleaved to contiguous copy and vice-versa.
>> Traditional SG_list based transfers tend to be very inefficient in
>> such cases as where the interleave and chunk are only a few bytes,
>> which call for a very condensed api to convey pattern of the transfer.
>>
>> This api supports all 4 variants of scatter-gather and contiguous transfer.
>> Besides, it could also represent common operations like
>> device_prep_dma_{cyclic, memset, memcpy}
>> and maybe some more that I am not sure of.
>>
>> Of course, neither can this api help transfers that don't lend to DMA by
>> nature, i.e, scattered tiny read/writes with no periodic pattern.
>>
>> Signed-off-by: Jassi Brar
>> ---
>> include/linux/dmaengine.h | 73
>> +
>> 1 files changed, 73 insertions(+), 0 deletions(-)
>>
>> diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
>> index 8fbf40e..74f3ae0 100644
>> --- a/include/linux/dmaengine.h
>> +++ b/include/linux/dmaengine.h
>> @@ -76,6 +76,76 @@ enum dma_transaction_type {
>> /* last transaction type for creation of the capabilities mask */
>> #define DMA_TX_TYPE_END (DMA_CYCLIC + 1)
>>
>> +/**
>> + * Generic Transfer Request
>> + *
>> + * A chunk is collection of contiguous bytes to be transfered.
>> + * The gap(in bytes) between two chunks is called inter-chunk-gap(ICG).
>> + * ICGs may or maynot change between chunks.
>> + * A FRAME is the smallest series of contiguous {chunk,icg} pairs,
>> + * that when repeated an integral number of times, specifies the transfer.
>> + * A transfer template is specification of a Frame, the number of times
>> + * it is to be repeated and other per-transfer attributes.
>> + *
>> + * Practically, a client driver would have ready a template for each
>> + * type of transfer it is going to need during its lifetime and
>> + * set only 'src_start' and 'dst_start' before submitting the requests.
>> + *
>> + *
>> + * | Frame-1 | Frame-2 | ~ | Frame-'numf' |
>> + * |==.===...=...|==.===...=...| ~ |==.===...=...|
>> + *
>> + * == Chunk size
>> + * ... ICG
>> + */
>> +
>> +/**
>> + * struct data_chunk - Element of scatter-gather list that makes a frame.
>> + * @size: Number of bytes to read from source.
>> + * size_dst := fn(op, size_src), so doesn't mean much for destination.
>> + * @icg: Number of bytes to jump after last src/dst address of this
>> + * chunk and before first src/dst address for next chunk.
>> + * Ignored for dst(assumed 0), if dst_inc is true and dst_sgl is false.
>> + * Ignored for src(assumed 0), if src_inc is true and src_sgl is false.
>> + */
>> +struct data_chunk {
>> + size_t size;
>> + size_t icg;
>> +};
>> +
>> +/**
>> + * struct xfer_template - Template to convey DMAC the transfer pattern
>> + * and attributes.
>> + * @op: The operation to perform on source data before writing it on
>> + * to destination address.
>> + * @src_start: Bus address of source for the first chunk.
>> + * @dst_start: Bus address of destination for the first chunk.
>> + * @src_inc: If the source address increments after reading from it.
>> + * @dst_inc: If the destination address increments after writing to it.
>> + * @src_sgl: If the 'icg' of sgl[] applies to Source (scattered read).
>> + * Otherwise, source is read contiguously (icg ignored).
>> + * Ignored if src_inc is false.
>> + * @dst_sgl: If the 'icg' of sgl[] applies to Destination (scattered write).
>> + * Otherwise, destination is filled contiguously (icg ignored).
>> + * Ignored if dst_inc is false.
>> + * @frm_irq: If the client expects DMAC driver to do callback after each
>> frame.
>> + * @numf: Number of frames in this template.
>> + * @frame_size: Number of chunks in a frame i.e, size of sgl[].
>> + * @sgl: Array of {chunk,icg} pairs that make up a frame.
>> + */
>> +struct xfer_template {
>> + enum dma_transaction_type op;
>> + dma_addr_t src_start;
>> + dma_addr_t dst_start;
>> + bool src_inc;
>> + bool dst_inc;
>> + bool src_sgl;
>> + bool dst_sgl;
>> + bool frm_irq;
>> + size_t numf;
>> + size_t frame_size;
>> + struct data_chunk sgl[0];
>> +};
>>
>> /**
>> * enum dma_ctrl_flags - DMA flags to augment operation preparation,
>> @@ -432,6 +502,7 @@ struct dma_tx_state {
>> * @device_prep_dma_cyclic: prepare a cyclic dma operation suitable for
>> audio.
>> * The function takes a buffer of size buf_len. The callback function will
>> * be called after period_len bytes have been transferred.
>> + * @device_prep_dma_genxfer: Transfer expression in a generic way.
>> * @device_control: manipulate all pending operations on a channel, returns
>> * zero or e
Re: [PATCH 12/15] OMAP4: powerdomain data: add wake-up latency figures
On Tuesday 16 August 2011 07:13 PM, jean.pi...@newoldbits.com wrote: From: Vishwanath BS This patch adds wake up latency numbers for OMAP4. Note that these are preliminary numbers and need to be relooked. Signed-off-by: Vishwanath BS The INACTIVE state is added as unsupported. In that case, don't add that support in first place. When INA support is getting added, you can update these as well. -- 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 11/15] OMAP3: powerdomain data: add wake-up latency figures
On Tuesday 16 August 2011 07:13 PM, jean.pi...@newoldbits.com wrote:
From: Jean Pihet
Figures are added to the power domains structs.
Note: the figures are preliminary figures. More accurate measurements
are needed. Also the conditions of measurements shall be investigated
and described.
Tested on OMAP3 Beagleboard in RET/OFF using wake-up latency constraints
on MPU, CORE and PER.
Signed-off-by: Jean Pihet
---
arch/arm/mach-omap2/powerdomains3xxx_data.c | 77 +++
1 files changed, 77 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/powerdomains3xxx_data.c
b/arch/arm/mach-omap2/powerdomains3xxx_data.c
index 469a920..64446e7 100644
--- a/arch/arm/mach-omap2/powerdomains3xxx_data.c
+++ b/arch/arm/mach-omap2/powerdomains3xxx_data.c
@@ -31,6 +31,13 @@
/*
* Powerdomains
+ *
+ * The wakeup_lat values are derived from measurements on
+ * the actual target.
+ *
+ * Note: the latency figures are preliminary and only used
+ * for the constraints framework validation.
+ * Actual figures and measurements conditions shall be added.
*/
static struct powerdomain iva2_pwrdm = {
@@ -52,6 +59,13 @@ static struct powerdomain iva2_pwrdm = {
[2] = PWRSTS_OFF_ON,
[3] = PWRSTS_ON,
},
+ .wakeup_lat = {
+ [PWRDM_FUNC_PWRST_OFF] = 1100,
+ [PWRDM_FUNC_PWRST_OSWR] = UNSUP_STATE,
+ [PWRDM_FUNC_PWRST_CSWR] = 350,
+ [PWRDM_FUNC_PWRST_INACTIVE] = UNSUP_STATE,
This can easily derived from the PWRST flag instead of hardcoding
it this way. Also note that INACTIVE PD isn't supported in mainline
yet because of voltage-domain dependency planned changes.
+ [PWRDM_FUNC_PWRST_ON] = 0,
All of the PD structures are manually coded. This whole file is
auto-generated and even these field generation needs to follow
that path.
--
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 15/15] OMAP2+: cpuidle only influences the MPU state
Jean,
On Tuesday 16 August 2011 07:13 PM, jean.pi...@newoldbits.com wrote:
From: Jean Pihet
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 devices PM QoS framework, via the devices 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 this figure.
Tested on OMAP3 Beagleboard in RET/OFF using wake-up latency constraints
on MPU, CORE and PER.
Signed-off-by: Jean Pihet
---
arch/arm/mach-omap2/cpuidle34xx.c | 42 +++-
arch/arm/mach-omap2/pm.h | 17 +-
2 files changed, 28 insertions(+), 31 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c
b/arch/arm/mach-omap2/cpuidle34xx.c
index 4bf6e6e..b43d1d2 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -37,26 +37,26 @@
#ifdef CONFIG_CPU_IDLE
[]
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index 4e166ad..aca3b6c 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -43,9 +43,22 @@ static inline int omap4_opp_init(void)
* omap3_pm_init_cpuidle
*/
struct cpuidle_params {
- u32 exit_latency; /* exit_latency = sleep + wake-up latencies */
+ /*
+* exit_latency = sleep + wake-up latencies of the MPU,
+* which 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 this figure.
+*/
This is exactly was my point in the last comment on this patch.
If you are adding up those numbers then it's no long MPU PD
latency but the system C-state latency.
And I say again, the latency numbers above are not for MPU alone
as you have done in this hunk. So be clear here. Either you provide
way to dynamically add the latency numbers to MPU latency which
is fixed for a OPP or call this as system latency etc.
> /*
> - * The latencies/thresholds for various C states have
> + * The MPU latencies/thresholds for various C states have
>* to be configured from the respective board files.
>* These are some default values (which might not provide
>* the best power savings) used on boards which do not
>* pass these details from the board file.
>*/
> static struct cpuidle_params cpuidle_params_table[] = {
> - /* C1 */
> + /* C1 . MPU WFI + Core active */
>{2 + 2, 5, 1},
> - /* C2 */
> + /* C2 . MPU WFI + Core inactive */
>{10 + 10, 30, 1},
Regards
Santosh
--
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: ALSA SoC TWL4030 driver
On Tuesday 16 August 2011 15:33:09 Maximilian Schwerin wrote:
> Hi,
>
> I'm currently working on a beagle board clone.
>
> I've got some problems getting the micbias1 output on the TPS65950 to work.
> I can record audio coming from a line out or if I connect micbias1 to an
> extern 1.8V supply.
>
> /sys/devices/platform/soc-audio/TWL4030/dapm_widget shows Mic Bias 1 to be
> off at all times. Is there something I have to do to enable this other than
> to start recording? Or could this be a bug in the driver? Does anyone have
> experience with the mic input of the TPS65950?
In your machine driver you need to connect the corresponding mic bias, like it
is done in for example for zoom2:
/* Headset Mic: HSMIC with bias */
{"HSMIC", NULL, "Headset Mic Bias"},
{"Headset Mic Bias", NULL, "Headset Mic"},
Note: Beagle only have support for line-in, does your board have additional
inputs jack (Headset?)
--
Péter
--
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: Remaining omap pull requests
On Wednesday 10 August 2011, Tony Lindgren wrote: > * Kevin Hilman [110802 17:00]: > > On 08/02/2011 04:14 PM, Kevin Hilman wrote: > > [...] > > >> > > >>Looks like I forgot the i2c driver changes that also should be > > >>merged by us. Those are acked by Ben Dooks, Kevin's pull request > > >>for that is at: > > >> > > >>http://marc.info/?l=linux-omap&m=131014213007667&w=2 > > >> > > > > > >I thought this was already pulled, but looking now I see that this was > > >never pulled into the arm-soc tree. > > > > > >Can you pull this for v3.1 please? > > I'll send a pull request for Ben Dooks for this as now the conflicting > parts have been merged. Sorry for missing this one during the merge window. I'm now starting to collect branches for 3.2, so please tell me if you want me to pull it now, if there is anything left that is not yet in Ben's tree. Arnd -- 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
ALSA SoC TWL4030 driver
Hi, I'm currently working on a beagle board clone. I've got some problems getting the micbias1 output on the TPS65950 to work. I can record audio coming from a line out or if I connect micbias1 to an extern 1.8V supply. /sys/devices/platform/soc-audio/TWL4030/dapm_widget shows Mic Bias 1 to be off at all times. Is there something I have to do to enable this other than to start recording? Or could this be a bug in the driver? Does anyone have experience with the mic input of the TPS65950? Thanks, Maximilian Maximilian Schwerin mailto:m...@tigris.de Tigris Elektronik GmbH http://www.tigris.de Wikingerufer 7 Tel: +49-30-301048-30 10555 Berlin, Germany Fax: +49-30-301048-59 Geschäftsführer: Henry Westphal, Guido Kuhlmann Sitz der Gesellschaft:Berlin Amtsgericht:Berlin-Charlottenburg, HRB 71737 pgprAkqEGBpLy.pgp Description: PGP signature
[PATCH 06/15] PM QoS: implement the per-device PM QoS constraints
From: Jean Pihet
Implement the per-device PM QoS constraints by creating a device
PM QoS API, which calls the PM QoS constraints management core code.
The per-device latency constraints data strctures are stored
in the device dev_pm_info struct.
The device PM code calls the init and destroy of the per-device constraints
data struct in order to support the dynamic insertion and removal of the
devices in the system.
To minimize the data usage by the per-device constraints, the data struct
is only allocated at the first call to dev_pm_qos_add_request.
The data is later free'd when the device is removed from the system.
A global mutex protects the constraints users from the data being
allocated and free'd.
Signed-off-by: Jean Pihet
---
drivers/base/power/Makefile |4 +-
drivers/base/power/main.c |3 +
drivers/base/power/qos.c| 291 +++
include/linux/pm.h |9 ++
include/linux/pm_qos.h | 42 ++
5 files changed, 347 insertions(+), 2 deletions(-)
create mode 100644 drivers/base/power/qos.c
diff --git a/drivers/base/power/Makefile b/drivers/base/power/Makefile
index 2639ae7..b707447 100644
--- a/drivers/base/power/Makefile
+++ b/drivers/base/power/Makefile
@@ -1,4 +1,4 @@
-obj-$(CONFIG_PM) += sysfs.o generic_ops.o
+obj-$(CONFIG_PM) += sysfs.o generic_ops.o qos.o
obj-$(CONFIG_PM_SLEEP) += main.o wakeup.o
obj-$(CONFIG_PM_RUNTIME) += runtime.o
obj-$(CONFIG_PM_TRACE_RTC) += trace.o
@@ -6,4 +6,4 @@ obj-$(CONFIG_PM_OPP)+= opp.o
obj-$(CONFIG_PM_GENERIC_DOMAINS) += domain.o
obj-$(CONFIG_HAVE_CLK) += clock_ops.o
-ccflags-$(CONFIG_DEBUG_DRIVER) := -DDEBUG
\ No newline at end of file
+ccflags-$(CONFIG_DEBUG_DRIVER) := -DDEBUG
diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c
index a854591..956443f 100644
--- a/drivers/base/power/main.c
+++ b/drivers/base/power/main.c
@@ -22,6 +22,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -97,6 +98,7 @@ void device_pm_add(struct device *dev)
dev_name(dev->parent));
list_add_tail(&dev->power.entry, &dpm_list);
mutex_unlock(&dpm_list_mtx);
+ dev_pm_qos_constraints_init(dev);
}
/**
@@ -107,6 +109,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));
+ dev_pm_qos_constraints_destroy(dev);
complete_all(&dev->power.completion);
mutex_lock(&dpm_list_mtx);
list_del_init(&dev->power.entry);
diff --git a/drivers/base/power/qos.c b/drivers/base/power/qos.c
new file mode 100644
index 000..304d68d
--- /dev/null
+++ b/drivers/base/power/qos.c
@@ -0,0 +1,291 @@
+/*
+ * This module exposes the interface to kernel space for specifying
+ * per-device PM QoS dependencies. It provides infrastructure for registration
+ * of:
+ *
+ * Dependents on a QoS value : register requests
+ * Watchers of QoS value : get notified when target QoS value changes
+ *
+ * This QoS design is best effort based. Dependents register their QoS needs.
+ * Watchers register to keep track of the current QoS needs of the system.
+ *
+ * Note about the per-device constraint data struct allocation:
+ * . The per-device constraints data struct ptr is tored into the device
+ *dev_pm_info.
+ * . To minimize the data usage by the per-device constraints, the data struct
+ * is only allocated at the first call to dev_pm_qos_add_request.
+ * . The data is later free'd when the device is removed from the system.
+ * . The constraints_state variable from dev_pm_info tracks the data struct
+ *allocation state:
+ *DEV_PM_QOS_NO_DEVICE: No device present or device removed, no data
+ * allocated,
+ *DEV_PM_QOS_DEVICE_PRESENT: Device present, data not allocated and will be
+ * allocated at the first call to dev_pm_qos_add_request,
+ *DEV_PM_QOS_ALLOCATED: Device present, data allocated. The per-device
+ * PM QoS constraints framework is operational and constraints can be
+ * added, updated or removed using the dev_pm_qos_* API.
+ * . A global mutex protects the constraints users from the data being
+ * allocated and free'd.
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+
+static DEFINE_MUTEX(dev_pm_qos_mtx);
+static void dev_pm_qos_constraints_allocate(struct device *dev);
+
+/**
+ * dev_pm_qos_add_request - inserts new qos request into the list
+ * @dev: target device for the constraint
+ * @req: pointer to a preallocated handle
+ * @value: defines the qos request
+ *
+ * This function inserts a new entry in the device constraints list of
+ * requested qos performance characteristics. It recomputes the aggregate
+ * QoS expectations of parameters and initializes the dev_pm_qos_request
+ * handle. Caller needs to save this handle for later use in updates and
+ * removal.
+ */
+void dev_pm_qos_add_request(struct
[PATCH 15/15] OMAP2+: cpuidle only influences the MPU state
From: Jean Pihet
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 devices PM QoS framework, via the devices 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 this figure.
Tested on OMAP3 Beagleboard in RET/OFF using wake-up latency constraints
on MPU, CORE and PER.
Signed-off-by: Jean Pihet
---
arch/arm/mach-omap2/cpuidle34xx.c | 42 +++-
arch/arm/mach-omap2/pm.h | 17 +-
2 files changed, 28 insertions(+), 31 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c
b/arch/arm/mach-omap2/cpuidle34xx.c
index 4bf6e6e..b43d1d2 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -37,26 +37,26 @@
#ifdef CONFIG_CPU_IDLE
/*
- * The latencies/thresholds for various C states have
+ * The MPU latencies/thresholds for various C states have
* to be configured from the respective board files.
* These are some default values (which might not provide
* the best power savings) used on boards which do not
* pass these details from the board file.
*/
static struct cpuidle_params cpuidle_params_table[] = {
- /* C1 */
+ /* C1 . MPU WFI + Core active */
{2 + 2, 5, 1},
- /* C2 */
+ /* C2 . MPU WFI + Core inactive */
{10 + 10, 30, 1},
- /* C3 */
+ /* C3 . MPU CSWR + Core inactive */
{50 + 50, 300, 1},
- /* C4 */
+ /* C4 . MPU OFF + Core inactive */
{1500 + 1800, 4000, 1},
- /* C5 */
+ /* C5 . MPU RET + Core RET */
{2500 + 7500, 12000, 1},
- /* C6 */
+ /* C6 . MPU OFF + Core RET */
{3000 + 8500, 15000, 1},
- /* C7 */
+ /* C7 . MPU OFF + Core OFF */
{1 + 3, 30, 1},
};
#define OMAP3_NUM_STATES ARRAY_SIZE(cpuidle_params_table)
@@ -64,7 +64,6 @@ static struct cpuidle_params cpuidle_params_table[] = {
/* Mach specific information to be recorded in the C-state driver_data */
struct omap3_idle_statedata {
u32 mpu_state;
- u32 core_state;
u8 valid;
};
struct omap3_idle_statedata omap3_idle_data[OMAP3_NUM_STATES];
@@ -98,7 +97,7 @@ static int omap3_enter_idle(struct cpuidle_device *dev,
{
struct omap3_idle_statedata *cx = cpuidle_get_statedata(state);
struct timespec ts_preidle, ts_postidle, ts_idle;
- u32 mpu_state = cx->mpu_state, core_state = cx->core_state;
+ u32 mpu_state = cx->mpu_state;
/* Used to keep track of the total time in idle */
getnstimeofday(&ts_preidle);
@@ -107,7 +106,6 @@ static int omap3_enter_idle(struct cpuidle_device *dev,
local_fiq_disable();
pwrdm_set_next_pwrst(mpu_pd, mpu_state);
- pwrdm_set_next_pwrst(core_pd, core_state);
if (omap_irq_pending() || need_resched())
goto return_sleep_time;
@@ -156,6 +154,7 @@ static struct cpuidle_state *next_valid_state(struct
cpuidle_device *dev,
struct omap3_idle_statedata *cx = cpuidle_get_statedata(curr);
u32 mpu_deepest_state = PWRDM_POWER_RET;
u32 core_deepest_state = PWRDM_POWER_RET;
+ u32 core_next_state = pwrdm_read_next_pwrst(core_pd);
if (enable_off_mode) {
mpu_deepest_state = PWRDM_POWER_OFF;
@@ -171,7 +170,7 @@ static struct cpuidle_state *next_valid_state(struct
cpuidle_device *dev,
/* Check if current state is valid */
if ((cx->valid) &&
(cx->mpu_state >= mpu_deepest_state) &&
- (cx->core_state >= core_deepest_state)) {
+ (core_next_state >= core_deepest_state)) {
return curr;
} else {
int idx = OMAP3_NUM_STATES - 1;
@@ -196,7 +195,7 @@ static struct cpuidle_state *next_valid_state(struct
cpuidle_device *dev,
cx = cpuidle_get_statedata(&dev->states[idx]);
if ((cx->valid) &&
(cx->mpu_state >= mpu_deepest_state) &&
- (cx->core_state >= core_deepest_state)) {
+ (core_next_state >= core_deepest_state)) {
next = &dev->states[idx];
break;
}
@@ -242,19 +241,11 @@ static int omap3_enter_idle_bm(struct cpuidle_device *dev,
}
/*
-* FIXME: we currently manage device-specific idle states
-*for PER and CORE in combination with CPU-specific
-*idle states. This is wrong, and device-specific
-
[PATCH 14/15] OMAP: PM CONSTRAINTS: implement the devices wake-up latency constraints
From: Jean Pihet
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
---
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 ca
[PATCH 13/15] OMAP2+: omap_hwmod: manage the wake-up latency constraints
From: Jean Pihet
Hwmod is queried from the OMAP_PM layer to manage the power domains
wake-up latency constraints. Hwmod retrieves the correct power domain
and if it exists it calls the corresponding power domain function.
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
---
arch/arm/mach-omap2/omap_hwmod.c | 26 +-
arch/arm/plat-omap/include/plat/omap_hwmod.h |2 ++
2 files changed, 27 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 84cc0bd..c6b1cc9 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -143,6 +143,7 @@
#include "powerdomain.h"
#include
#include
+#include
#include
#include "cm2xxx_3xxx.h"
@@ -2618,11 +2619,34 @@ ohsps_unlock:
return ret;
}
+/*
+ * omap_hwmod_set_wkup_constraint- set/release a wake-up latency constraint
+ *
+ * @oh: struct omap_hwmod* to which the target device belongs to.
+ * @cookie: identifier of the constraints list for @oh.
+ * @min_latency: the minimum allowed wake-up latency for @oh.
+ *
+ * Returns 0 upon success.
+ */
+int omap_hwmod_set_wkup_lat_constraint(struct omap_hwmod *oh,
+ void *cookie, long min_latency)
+{
+ struct powerdomain *pwrdm = omap_hwmod_get_pwrdm(oh);
+
+ if (!pwrdm) {
+ pr_err("%s: Error: could not find powerdomain "
+ "for %s\n", __func__, oh->name);
+ return -EINVAL;
+ }
+
+ return pwrdm_set_wkup_lat_constraint(pwrdm, cookie, min_latency);
+}
+
/**
* omap_hwmod_get_context_loss_count - get lost context count
* @oh: struct omap_hwmod *
*
- * Query the powerdomain of of @oh to get the context loss
+ * Query the powerdomain of @oh to get the context loss
* count for this device.
*
* Returns the context loss count of the powerdomain assocated with @oh
diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h
b/arch/arm/plat-omap/include/plat/omap_hwmod.h
index 0e329ca..75e0e7a 100644
--- a/arch/arm/plat-omap/include/plat/omap_hwmod.h
+++ b/arch/arm/plat-omap/include/plat/omap_hwmod.h
@@ -603,6 +603,8 @@ int omap_hwmod_for_each_by_class(const char *classname,
void *user);
int omap_hwmod_set_postsetup_state(struct omap_hwmod *oh, u8 state);
+int omap_hwmod_set_wkup_lat_constraint(struct omap_hwmod *oh, void *cookie,
+ long min_latency);
u32 omap_hwmod_get_context_loss_count(struct omap_hwmod *oh);
int omap_hwmod_no_setup_reset(struct omap_hwmod *oh);
--
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 12/15] OMAP4: powerdomain data: add wake-up latency figures
From: Vishwanath BS
This patch adds wake up latency numbers for OMAP4. Note that these are
preliminary numbers and need to be relooked.
Signed-off-by: Vishwanath BS
The INACTIVE state is added as unsupported.
Tested on OMAP4 Pandaboard in RET/OFF using wake-up latency constraints on
MPU, CORE and PER.
Signed-off-by: Jean Pihet
---
arch/arm/mach-omap2/powerdomains44xx_data.c | 84 +++
1 files changed, 84 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/powerdomains44xx_data.c
b/arch/arm/mach-omap2/powerdomains44xx_data.c
index 247e794..c3f8dd4 100644
--- a/arch/arm/mach-omap2/powerdomains44xx_data.c
+++ b/arch/arm/mach-omap2/powerdomains44xx_data.c
@@ -54,6 +54,13 @@ static struct powerdomain core_44xx_pwrdm = {
[4] = PWRSTS_ON,/* ducati_unicache */
},
.flags= PWRDM_HAS_LOWPOWERSTATECHANGE,
+ .wakeup_lat = {
+ [PWRDM_FUNC_PWRST_OFF] = UNSUP_STATE,
+ [PWRDM_FUNC_PWRST_OSWR] = 600,
+ [PWRDM_FUNC_PWRST_CSWR] = 300,
+ [PWRDM_FUNC_PWRST_INACTIVE] = UNSUP_STATE,
+ [PWRDM_FUNC_PWRST_ON] = 0,
+ },
};
/* gfx_44xx_pwrdm: 3D accelerator power domain */
@@ -71,6 +78,13 @@ static struct powerdomain gfx_44xx_pwrdm = {
[0] = PWRSTS_ON,/* gfx_mem */
},
.flags= PWRDM_HAS_LOWPOWERSTATECHANGE,
+ .wakeup_lat = {
+ [PWRDM_FUNC_PWRST_OFF] = 1000,
+ [PWRDM_FUNC_PWRST_OSWR] = UNSUP_STATE,
+ [PWRDM_FUNC_PWRST_CSWR] = UNSUP_STATE,
+ [PWRDM_FUNC_PWRST_INACTIVE] = UNSUP_STATE,
+ [PWRDM_FUNC_PWRST_ON] = 0,
+ },
};
/* abe_44xx_pwrdm: Audio back end power domain */
@@ -91,6 +105,13 @@ static struct powerdomain abe_44xx_pwrdm = {
[1] = PWRSTS_ON,/* periphmem */
},
.flags= PWRDM_HAS_LOWPOWERSTATECHANGE,
+ .wakeup_lat = {
+ [PWRDM_FUNC_PWRST_OFF] = 1000,
+ [PWRDM_FUNC_PWRST_OSWR] = 600,
+ [PWRDM_FUNC_PWRST_CSWR] = 300,
+ [PWRDM_FUNC_PWRST_INACTIVE] = UNSUP_STATE,
+ [PWRDM_FUNC_PWRST_ON] = 0,
+ },
};
/* dss_44xx_pwrdm: Display subsystem power domain */
@@ -109,6 +130,13 @@ static struct powerdomain dss_44xx_pwrdm = {
[0] = PWRSTS_ON,/* dss_mem */
},
.flags= PWRDM_HAS_LOWPOWERSTATECHANGE,
+ .wakeup_lat = {
+ [PWRDM_FUNC_PWRST_OFF] = 1000,
+ [PWRDM_FUNC_PWRST_OSWR] = UNSUP_STATE,
+ [PWRDM_FUNC_PWRST_CSWR] = 300,
+ [PWRDM_FUNC_PWRST_INACTIVE] = UNSUP_STATE,
+ [PWRDM_FUNC_PWRST_ON] = 0,
+ },
};
/* tesla_44xx_pwrdm: Tesla processor power domain */
@@ -131,6 +159,13 @@ static struct powerdomain tesla_44xx_pwrdm = {
[2] = PWRSTS_ON,/* tesla_l2 */
},
.flags= PWRDM_HAS_LOWPOWERSTATECHANGE,
+ .wakeup_lat = {
+ [PWRDM_FUNC_PWRST_OFF] = 1000,
+ [PWRDM_FUNC_PWRST_OSWR] = 600,
+ [PWRDM_FUNC_PWRST_CSWR] = 300,
+ [PWRDM_FUNC_PWRST_INACTIVE] = UNSUP_STATE,
+ [PWRDM_FUNC_PWRST_ON] = 0,
+ },
};
/* wkup_44xx_pwrdm: Wake-up power domain */
@@ -164,6 +199,13 @@ static struct powerdomain cpu0_44xx_pwrdm = {
.pwrsts_mem_on = {
[0] = PWRSTS_ON,/* cpu0_l1 */
},
+ .wakeup_lat = {
+ [PWRDM_FUNC_PWRST_OFF] = 1000,
+ [PWRDM_FUNC_PWRST_OSWR] = 600,
+ [PWRDM_FUNC_PWRST_CSWR] = 300,
+ [PWRDM_FUNC_PWRST_INACTIVE] = UNSUP_STATE,
+ [PWRDM_FUNC_PWRST_ON] = 0,
+ },
};
/* cpu1_44xx_pwrdm: MPU1 processor and Neon coprocessor power domain */
@@ -181,6 +223,13 @@ static struct powerdomain cpu1_44xx_pwrdm = {
.pwrsts_mem_on = {
[0] = PWRSTS_ON,/* cpu1_l1 */
},
+ .wakeup_lat = {
+ [PWRDM_FUNC_PWRST_OFF] = 1000,
+ [PWRDM_FUNC_PWRST_OSWR] = 600,
+ [PWRDM_FUNC_PWRST_CSWR] = 300,
+ [PWRDM_FUNC_PWRST_INACTIVE] = UNSUP_STATE,
+ [PWRDM_FUNC_PWRST_ON] = 0,
+ },
};
/* emu_44xx_pwrdm: Emulation power domain */
@@ -218,6 +267,13 @@ static struct powerdomain mpu_44xx_pwrdm = {
[1] = PWRSTS_ON,/* mpu_l2 */
[2] = PWRSTS_ON,/* mpu_ram */
},
+ .wakeup_lat = {
+ [PWRDM_FUNC_PWRST_OFF] = 1000,
+ [PWRDM_FUNC_PWRST_OSWR] = 600,
+ [PWRDM_FUNC_PWRST_CSWR] = 300,
+ [PWRDM_FUNC_PWRST_INACTIVE] = UNSUP_STATE,
+ [PWRDM_FUNC_PWRST_ON] = 0,
+ },
};
/* ivahd_44xx_pwrdm: IVA-HD power domain */
@@ -242,6 +298,13 @@ static struct powerdomain ivahd_44xx_pwrdm = {
[3] = PWRSTS_ON,
[PATCH 11/15] OMAP3: powerdomain data: add wake-up latency figures
From: Jean Pihet
Figures are added to the power domains structs.
Note: the figures are preliminary figures. More accurate measurements
are needed. Also the conditions of measurements shall be investigated
and described.
Tested on OMAP3 Beagleboard in RET/OFF using wake-up latency constraints
on MPU, CORE and PER.
Signed-off-by: Jean Pihet
---
arch/arm/mach-omap2/powerdomains3xxx_data.c | 77 +++
1 files changed, 77 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/powerdomains3xxx_data.c
b/arch/arm/mach-omap2/powerdomains3xxx_data.c
index 469a920..64446e7 100644
--- a/arch/arm/mach-omap2/powerdomains3xxx_data.c
+++ b/arch/arm/mach-omap2/powerdomains3xxx_data.c
@@ -31,6 +31,13 @@
/*
* Powerdomains
+ *
+ * The wakeup_lat values are derived from measurements on
+ * the actual target.
+ *
+ * Note: the latency figures are preliminary and only used
+ * for the constraints framework validation.
+ * Actual figures and measurements conditions shall be added.
*/
static struct powerdomain iva2_pwrdm = {
@@ -52,6 +59,13 @@ static struct powerdomain iva2_pwrdm = {
[2] = PWRSTS_OFF_ON,
[3] = PWRSTS_ON,
},
+ .wakeup_lat = {
+ [PWRDM_FUNC_PWRST_OFF] = 1100,
+ [PWRDM_FUNC_PWRST_OSWR] = UNSUP_STATE,
+ [PWRDM_FUNC_PWRST_CSWR] = 350,
+ [PWRDM_FUNC_PWRST_INACTIVE] = UNSUP_STATE,
+ [PWRDM_FUNC_PWRST_ON] = 0,
+ },
};
static struct powerdomain mpu_3xxx_pwrdm = {
@@ -68,6 +82,13 @@ static struct powerdomain mpu_3xxx_pwrdm = {
.pwrsts_mem_on= {
[0] = PWRSTS_OFF_ON,
},
+ .wakeup_lat = {
+ [PWRDM_FUNC_PWRST_OFF] = 95,
+ [PWRDM_FUNC_PWRST_OSWR] = UNSUP_STATE,
+ [PWRDM_FUNC_PWRST_CSWR] = 45,
+ [PWRDM_FUNC_PWRST_INACTIVE] = UNSUP_STATE,
+ [PWRDM_FUNC_PWRST_ON] = 0,
+ },
};
/*
@@ -98,6 +119,13 @@ static struct powerdomain core_3xxx_pre_es3_1_pwrdm = {
[0] = PWRSTS_OFF_RET_ON, /* MEM1ONSTATE */
[1] = PWRSTS_OFF_RET_ON, /* MEM2ONSTATE */
},
+ .wakeup_lat = {
+ [PWRDM_FUNC_PWRST_OFF] = 100,
+ [PWRDM_FUNC_PWRST_OSWR] = UNSUP_STATE,
+ [PWRDM_FUNC_PWRST_CSWR] = 60,
+ [PWRDM_FUNC_PWRST_INACTIVE] = UNSUP_STATE,
+ [PWRDM_FUNC_PWRST_ON] = 0,
+ },
};
static struct powerdomain core_3xxx_es3_1_pwrdm = {
@@ -121,6 +149,13 @@ static struct powerdomain core_3xxx_es3_1_pwrdm = {
[0] = PWRSTS_OFF_RET_ON, /* MEM1ONSTATE */
[1] = PWRSTS_OFF_RET_ON, /* MEM2ONSTATE */
},
+ .wakeup_lat = {
+ [PWRDM_FUNC_PWRST_OFF] = 100,
+ [PWRDM_FUNC_PWRST_OSWR] = UNSUP_STATE,
+ [PWRDM_FUNC_PWRST_CSWR] = 60,
+ [PWRDM_FUNC_PWRST_INACTIVE] = UNSUP_STATE,
+ [PWRDM_FUNC_PWRST_ON] = 0,
+ },
};
static struct powerdomain dss_pwrdm = {
@@ -136,6 +171,13 @@ static struct powerdomain dss_pwrdm = {
.pwrsts_mem_on= {
[0] = PWRSTS_ON, /* MEMONSTATE */
},
+ .wakeup_lat = {
+ [PWRDM_FUNC_PWRST_OFF] = 70,
+ [PWRDM_FUNC_PWRST_OSWR] = UNSUP_STATE,
+ [PWRDM_FUNC_PWRST_CSWR] = 20,
+ [PWRDM_FUNC_PWRST_INACTIVE] = UNSUP_STATE,
+ [PWRDM_FUNC_PWRST_ON] = 0,
+ },
};
/*
@@ -157,6 +199,13 @@ static struct powerdomain sgx_pwrdm = {
.pwrsts_mem_on= {
[0] = PWRSTS_ON, /* MEMONSTATE */
},
+ .wakeup_lat = {
+ [PWRDM_FUNC_PWRST_OFF] = 1000,
+ [PWRDM_FUNC_PWRST_OSWR] = UNSUP_STATE,
+ [PWRDM_FUNC_PWRST_CSWR] = UNSUP_STATE,
+ [PWRDM_FUNC_PWRST_INACTIVE] = UNSUP_STATE,
+ [PWRDM_FUNC_PWRST_ON] = 0,
+ },
};
static struct powerdomain cam_pwrdm = {
@@ -172,6 +221,13 @@ static struct powerdomain cam_pwrdm = {
.pwrsts_mem_on= {
[0] = PWRSTS_ON, /* MEMONSTATE */
},
+ .wakeup_lat = {
+ [PWRDM_FUNC_PWRST_OFF] = 850,
+ [PWRDM_FUNC_PWRST_OSWR] = UNSUP_STATE,
+ [PWRDM_FUNC_PWRST_CSWR] = 35,
+ [PWRDM_FUNC_PWRST_INACTIVE] = UNSUP_STATE,
+ [PWRDM_FUNC_PWRST_ON] = 0,
+ },
};
static struct powerdomain per_pwrdm = {
@@ -187,6 +243,13 @@ static struct powerdomain per_pwrdm = {
.pwrsts_mem_on= {
[0] = PWRSTS_ON, /* MEMONSTATE */
},
+ .wakeup_lat = {
+ [PWRDM_FUNC_PWRST_OFF] = 200,
+ [PWRDM_FUNC_PWRST_OSWR] = UNSUP_STATE,
+ [PWRDM_FUNC_PWRST_CSWR] = 110,
+ [PWRDM_FUNC_PWRST_INACTIVE] = UNSUP_STATE,
+ [PWRDM_FUNC_PWRST_ON] = 0,
+ },
};
static struct powerdomain emu_pwrdm = {
@@ -201,6 +264,13 @@ static
[PATCH 10/15] OMAP2+: powerdomain: control power domains next state
From: Jean Pihet
When a PM QoS device latency constraint is requested or removed the
PM QoS layer notifies the underlying layer with the updated aggregated
constraint value. The constraint is stored in the powerdomain constraints
list and then applied to the corresponding power domain.
The power domains get the next power state programmed directly in the
registers via pwrdm_wakeuplat_update_pwrst.
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
---
arch/arm/mach-omap2/powerdomain.c | 190 +
arch/arm/mach-omap2/powerdomain.h | 33 ++-
2 files changed, 221 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/powerdomain.c
b/arch/arm/mach-omap2/powerdomain.c
index 9af0847..afa8153 100644
--- a/arch/arm/mach-omap2/powerdomain.c
+++ b/arch/arm/mach-omap2/powerdomain.c
@@ -17,8 +17,10 @@
#include
#include
#include
+#include
#include
#include
+#include
#include
#include "cm2xxx_3xxx.h"
@@ -104,6 +106,11 @@ static int _pwrdm_register(struct powerdomain *pwrdm)
for (i = 0; i < pwrdm->banks; i++)
pwrdm->ret_mem_off_counter[i] = 0;
+ /* Initialize the per-od wake-up constraints list and spinlock */
+ spin_lock_init(&pwrdm->wkup_lat_plist_lock);
+ plist_head_init(&pwrdm->wkup_lat_plist_head);
+
+ /* Initialize the pwrdm state */
pwrdm_wait_transition(pwrdm);
pwrdm->state = pwrdm_read_pwrst(pwrdm);
pwrdm->state_counter[pwrdm->state] = 1;
@@ -191,6 +198,77 @@ static int _pwrdm_post_transition_cb(struct powerdomain
*pwrdm, void *unused)
return 0;
}
+/**
+ * pwrdm_wakeuplat_update_pwrst - Update power domain power state if needed
+ * @pwrdm: struct powerdomain * to which requesting device belongs to.
+ * @min_latency: the allowed wake-up latency for the given power domain. A
+ * value of PM_QOS_DEV_LAT_DEFAULT_VALUE means 'no constraint' on the pwrdm.
+ *
+ * Finds the power domain next power state that fulfills the constraint.
+ * Programs a new target state if it is different from current power state.
+ * The power domains get the next power state programmed directly in the
+ * registers.
+ *
+ * Returns 0 upon success.
+ */
+static int pwrdm_wakeuplat_update_pwrst(struct powerdomain *pwrdm,
+ long min_latency)
+{
+ int ret = 0, new_state = 0;
+
+ if (!pwrdm) {
+ WARN(1, "powerdomain: %s: invalid parameter(s)", __func__);
+ return -EINVAL;
+ }
+
+ /*
+* Apply constraints to power domains by programming
+* the pwrdm next power state.
+*/
+
+ /* Find power state with wakeup latency < minimum constraint */
+ for (new_state = 0x0; new_state < PWRDM_MAX_PWRSTS; new_state++) {
+ if (min_latency == PM_QOS_DEV_LAT_DEFAULT_VALUE ||
+ pwrdm->wakeup_lat[new_state] <= min_latency)
+ break;
+ }
+
+ switch (new_state) {
+ case PWRDM_FUNC_PWRST_OFF:
+ new_state = PWRDM_POWER_OFF;
+ break;
+ case PWRDM_FUNC_PWRST_OSWR:
+ pwrdm_set_logic_retst(pwrdm, PWRDM_POWER_OFF);
+ new_state = PWRDM_POWER_RET;
+ break;
+ case PWRDM_FUNC_PWRST_CSWR:
+ pwrdm_set_logic_retst(pwrdm, PWRDM_POWER_RET);
+ new_state = PWRDM_POWER_RET;
+ break;
+ case PWRDM_FUNC_PWRST_INACTIVE:
+ new_state = PWRDM_POWER_INACTIVE;
+ break;
+ case PWRDM_FUNC_PWRST_ON:
+ new_state = PWRDM_POWER_ON;
+ break;
+ default:
+ pr_warn("powerdomain: requested latency constraint not "
+ "supported %s set to ON state\n", pwrdm->name);
+ new_state = PWRDM_POWER_ON;
+ break;
+ }
+
+ if (pwrdm_read_next_pwrst(pwrdm) != new_state)
+ ret = omap_set_pwrdm_state(pwrdm, new_state);
+
+ pr_debug("powerdomain: %s pwrst: curr=%d, prev=%d next=%d "
+"min_latency=%ld, set_state=%d\n", pwrdm->name,
+pwrdm_read_pwrst(pwrdm), pwrdm_read_prev_pwrst(pwrdm),
+pwrdm_read_next_pwrst(pwrdm), min_latency, new_state);
+
+ return ret;
+}
+
/* Public functions */
/**
@@ -930,6 +1008,118 @@ int pwrdm_post_transition(void)
return 0;
}
+/*
+ * pwrdm_set_wkup_lat_constraint - Set/update/remove a powerdomain wakeup
+ * latency constraint and apply it
+ * @pwrdm: struct powerdomain * which the constraint applies to
+ * @cookie: constraint identifier, used for tracking.
+ * @min_latency: minimum wakeup latency constraint (in microseconds) for
+ * the given pwrdm. The value of PM_QOS_DEV_LAT_DEFAULT_VALUE removes
+ * the constraint.
+ *
+ * Tracks the constraints by @cookie.
+ * Constraint set/update: Adds a new
[PATCH 09/15] OMAP: PM: create a PM layer plugin for per-device constraints
From: Jean Pihet
Created arch/arm/plat-omap/omap-pm-constraints.c file from
arch/arm/plat-omap/omap-pm-noop.c and the associated Kconfig option
OMAP_PM_CONSTRAINTS.
Signed-off-by: Jean Pihet
---
arch/arm/plat-omap/Kconfig |7 +
arch/arm/plat-omap/Makefile |1 +
arch/arm/plat-omap/omap-pm-constraints.c | 363 ++
3 files changed, 371 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/plat-omap/omap-pm-constraints.c
diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig
index bb8f4a6..3ee47a1 100644
--- a/arch/arm/plat-omap/Kconfig
+++ b/arch/arm/plat-omap/Kconfig
@@ -215,6 +215,13 @@ choice
config OMAP_PM_NOOP
bool "No-op/debug PM layer"
+config OMAP_PM_CONSTRAINTS
+ depends on PM
+ bool "Per device constraints"
+ help
+ Select this option to enable the PM layer plugin for
+ the per-device constraints support
+
endchoice
endmenu
diff --git a/arch/arm/plat-omap/Makefile b/arch/arm/plat-omap/Makefile
index f0233e6..f2e09f1 100644
--- a/arch/arm/plat-omap/Makefile
+++ b/arch/arm/plat-omap/Makefile
@@ -32,3 +32,4 @@ obj-y += $(i2c-omap-m) $(i2c-omap-y)
obj-$(CONFIG_OMAP_MBOX_FWK) += mailbox.o
obj-$(CONFIG_OMAP_PM_NOOP) += omap-pm-noop.o
+obj-$(CONFIG_OMAP_PM_CONSTRAINTS) += omap-pm-constraints.o
diff --git a/arch/arm/plat-omap/omap-pm-constraints.c
b/arch/arm/plat-omap/omap-pm-constraints.c
new file mode 100644
index 000..c8b4e4c
--- /dev/null
+++ b/arch/arm/plat-omap/omap-pm-constraints.c
@@ -0,0 +1,363 @@
+/*
+ * omap-pm.c - OMAP power management interface
+ *
+ * This code implements the OMAP power management interface to
+ * drivers, CPUIdle, CPUFreq, and DSP Bridge.
+ *
+ * Copyright (C) 2008-2009 Texas Instruments, Inc.
+ * Copyright (C) 2008-2009 Nokia Corporation
+ * Paul Walmsley
+ *
+ * Interface developed by (in alphabetical order):
+ * Karthik Dasu, Tony Lindgren, Jean Pihet, Rajendra Nayak, Sakari Poussa,
+ * Veeramanikandan Raju, Anand Sawant, Igor Stoppa, Paul Walmsley,
+ * Richard Woodruff
+ */
+
+#undef DEBUG
+
+#include
+#include
+#include
+#include
+
+/* Interface documentation is in mach/omap-pm.h */
+#include
+#include
+
+static bool off_mode_enabled;
+static u32 dummy_context_loss_counter;
+
+/*
+ * Device-driver-originated constraints (via board-*.c files)
+ */
+
+int omap_pm_set_max_mpu_wakeup_lat(struct device *dev, long t)
+{
+ if (!dev || t < -1) {
+ WARN(1, "OMAP PM: %s: invalid parameter(s)", __func__);
+ return -EINVAL;
+ };
+
+ if (t == -1)
+ pr_debug("OMAP PM: remove max MPU wakeup latency constraint: "
+"dev %s\n", dev_name(dev));
+ else
+ pr_debug("OMAP PM: add max MPU wakeup latency constraint: "
+"dev %s, t = %ld usec\n", dev_name(dev), t);
+
+ /*
+* For current Linux, this needs to map the MPU to a
+* powerdomain, then go through the list of current max lat
+* constraints on the MPU and find the smallest. If
+* the latency constraint has changed, the code should
+* recompute the state to enter for the next powerdomain
+* state.
+*
+* TI CDP code can call constraint_set here.
+*/
+
+ return 0;
+}
+
+int omap_pm_set_min_bus_tput(struct device *dev, u8 agent_id, unsigned long r)
+{
+ if (!dev || (agent_id != OCP_INITIATOR_AGENT &&
+ agent_id != OCP_TARGET_AGENT)) {
+ WARN(1, "OMAP PM: %s: invalid parameter(s)", __func__);
+ return -EINVAL;
+ };
+
+ if (r == 0)
+ pr_debug("OMAP PM: remove min bus tput constraint: "
+"dev %s for agent_id %d\n", dev_name(dev), agent_id);
+ else
+ pr_debug("OMAP PM: add min bus tput constraint: "
+"dev %s for agent_id %d: rate %ld KiB\n",
+dev_name(dev), agent_id, r);
+
+ /*
+* This code should model the interconnect and compute the
+* required clock frequency, convert that to a VDD2 OPP ID, then
+* set the VDD2 OPP appropriately.
+*
+* TI CDP code can call constraint_set here on the VDD2 OPP.
+*/
+
+ return 0;
+}
+
+int omap_pm_set_max_dev_wakeup_lat(struct device *req_dev, struct device *dev,
+ long t)
+{
+ if (!req_dev || !dev || t < -1) {
+ WARN(1, "OMAP PM: %s: invalid parameter(s)", __func__);
+ return -EINVAL;
+ };
+
+ if (t == -1)
+ pr_debug("OMAP PM: remove max device latency constraint: "
+"dev %s\n", dev_name(dev));
+ else
+ pr_debug("OMAP PM: add max device latency constraint: "
+"dev %s, t = %ld usec\n", dev_name(dev), t);
+
+ /*
+* For current Linux, this needs to map the device to a
[PATCH 08/15] OMAP: convert I2C driver to PM QoS for latency constraints
From: Jean Pihet
Convert the driver from the outdated omap_pm_set_max_mpu_wakeup_lat
API to the new PM QoS API.
Since the constraint is on the MPU subsystem, use the PM_QOS_CPU_DMA_LATENCY
class of PM QoS. The resulting MPU constraints are used by cpuidle to
decide the next power state of the MPU subsystem.
Currently only OMAP3 is placing constraints on the MPU.
Signed-off-by: Jean Pihet
---
arch/arm/plat-omap/i2c.c | 20
drivers/i2c/busses/i2c-omap.c | 31 ++-
2 files changed, 18 insertions(+), 33 deletions(-)
diff --git a/arch/arm/plat-omap/i2c.c b/arch/arm/plat-omap/i2c.c
index 3341ca4..e1e2502 100644
--- a/arch/arm/plat-omap/i2c.c
+++ b/arch/arm/plat-omap/i2c.c
@@ -34,7 +34,6 @@
#include
#include
#include
-#include
#include
#define OMAP_I2C_SIZE 0x3f
@@ -113,16 +112,6 @@ static inline int omap1_i2c_add_bus(int bus_id)
#ifdef CONFIG_ARCH_OMAP2PLUS
-/*
- * XXX This function is a temporary compatibility wrapper - only
- * needed until the I2C driver can be converted to call
- * omap_pm_set_max_dev_wakeup_lat() and handle a return code.
- */
-static void omap_pm_set_max_mpu_wakeup_lat_compat(struct device *dev, long t)
-{
- omap_pm_set_max_mpu_wakeup_lat(dev, t);
-}
-
static struct omap_device_pm_latency omap_i2c_latency[] = {
[0] = {
.deactivate_func= omap_device_idle_hwmods,
@@ -151,15 +140,6 @@ static inline int omap2_i2c_add_bus(int bus_id)
}
pdata = &i2c_pdata[bus_id - 1];
- /*
-* When waiting for completion of a i2c transfer, we need to
-* set a wake up latency constraint for the MPU. This is to
-* ensure quick enough wakeup from idle, when transfer
-* completes.
-* Only omap3 has support for constraints
-*/
- if (cpu_is_omap34xx())
- pdata->set_mpu_wkup_lat = omap_pm_set_max_mpu_wakeup_lat_compat;
od = omap_device_build(name, bus_id, oh, pdata,
sizeof(struct omap_i2c_bus_platform_data),
omap_i2c_latency, ARRAY_SIZE(omap_i2c_latency), 0);
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 8ae8081..d80ae91 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -40,6 +40,7 @@
#include
#include
#include
+#include
/* I2C controller revisions */
#define OMAP_I2C_REV_2 0x20
@@ -179,8 +180,7 @@ struct omap_i2c_dev {
struct completion cmd_complete;
struct resource *ioarea;
u32 latency;/* maximum mpu wkup latency */
- void(*set_mpu_wkup_lat)(struct device *dev,
- long latency);
+ struct pm_qos_request pm_qos_request;
u32 speed; /* Speed of bus in Khz */
u16 cmd_err;
u8 *buf;
@@ -648,8 +648,16 @@ omap_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg
msgs[], int num)
if (r < 0)
goto out;
- if (dev->set_mpu_wkup_lat != NULL)
- dev->set_mpu_wkup_lat(dev->dev, dev->latency);
+ /*
+* When waiting for completion of a i2c transfer, we need to
+* set a wake up latency constraint for the MPU. This is to
+* ensure quick enough wakeup from idle, when transfer
+* completes.
+* Used on OMAP3 Only
+*/
+ if (cpu_is_omap34xx())
+ pm_qos_add_request(&dev->pm_qos_request, PM_QOS_CPU_DMA_LATENCY,
+ dev->latency);
for (i = 0; i < num; i++) {
r = omap_i2c_xfer_msg(adap, &msgs[i], (i == (num - 1)));
@@ -657,8 +665,8 @@ omap_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg
msgs[], int num)
break;
}
- if (dev->set_mpu_wkup_lat != NULL)
- dev->set_mpu_wkup_lat(dev->dev, -1);
+ if (cpu_is_omap34xx())
+ pm_qos_remove_request(&dev->pm_qos_request);
if (r == 0)
r = num;
@@ -1005,13 +1013,10 @@ omap_i2c_probe(struct platform_device *pdev)
goto err_release_region;
}
- if (pdata != NULL) {
+ if (pdata != NULL)
speed = pdata->clkrate;
- dev->set_mpu_wkup_lat = pdata->set_mpu_wkup_lat;
- } else {
+ else
speed = 100;/* Default speed */
- dev->set_mpu_wkup_lat = NULL;
- }
dev->speed = speed;
dev->idle = 1;
@@ -1064,8 +1069,8 @@ omap_i2c_probe(struct platform_device *pdev)
dev->fifo_size = (dev->fifo_size / 2);
dev->b_hw = 1; /* Enable hardware fixes */
}
- /* calculate wakeup latency constraint for MPU */
- if (dev->set_mpu_wkup_lat != NULL)
+
[PATCH 07/15] PM QoS: add a global notification mechanism for the device constraints
From: Jean Pihet
Add a global notification chain that gets called upon changes to the
aggregated constraint value for any device.
The notification callbacks are passing the full constraint request data
in order for the callees to have access to it. The current use is for the
platform low-level code to access the target device of the constraint.
Signed-off-by: Jean Pihet
---
drivers/base/power/qos.c | 84 --
include/linux/pm_qos.h | 11 ++
kernel/power/qos.c |2 +-
3 files changed, 78 insertions(+), 19 deletions(-)
diff --git a/drivers/base/power/qos.c b/drivers/base/power/qos.c
index 304d68d..b52b3e8 100644
--- a/drivers/base/power/qos.c
+++ b/drivers/base/power/qos.c
@@ -8,6 +8,12 @@
*
* This QoS design is best effort based. Dependents register their QoS needs.
* Watchers register to keep track of the current QoS needs of the system.
+ * Watchers can register different types of notification callbacks:
+ * . a per-device notification callback using the dev_pm_qos_*_notifier API.
+ *The notification chain data is stored in the per-device constraint
+ *data struct.
+ * . a system-wide notification callback using the
dev_pm_qos_*_global_notifier
+ *API. The notification chain data is stored in a static variable.
*
* Note about the per-device constraint data struct allocation:
* . The per-device constraints data struct ptr is tored into the device
@@ -36,8 +42,32 @@
static DEFINE_MUTEX(dev_pm_qos_mtx);
+static BLOCKING_NOTIFIER_HEAD(dev_pm_notifiers);
static void dev_pm_qos_constraints_allocate(struct device *dev);
+/*
+ * Update the constraints list using the PM QoS core code and
+ * if needed call the per-device and the global notification callbacks
+ */
+static int _apply_constraint(struct dev_pm_qos_request *req,
+enum pm_qos_req_action action, int value)
+{
+ int ret, curr_value;
+
+ ret = pm_qos_update_target(req->dev->power.constraints,
+ &req->node, action, value);
+
+ if (ret) {
+ /* Call the global callbacks if needed */
+ curr_value = pm_qos_read_value(req->dev->power.constraints);
+ blocking_notifier_call_chain(&dev_pm_notifiers,
+(unsigned long)curr_value,
+req);
+ }
+
+ return ret;
+}
+
/**
* dev_pm_qos_add_request - inserts new qos request into the list
* @dev: target device for the constraint
@@ -66,16 +96,13 @@ void dev_pm_qos_add_request(struct device *dev, struct
dev_pm_qos_request *req,
dev_pm_qos_constraints_allocate(dev);
mutex_lock(&dev_pm_qos_mtx);
-
req->dev = dev;
/* Silently return if the device has been removed */
if (req->dev->power.constraints_state != DEV_PM_QOS_ALLOCATED)
goto out;
- pm_qos_update_target(dev->power.constraints,
-&req->node, PM_QOS_ADD_REQ, value);
-
+ _apply_constraint(req, PM_QOS_ADD_REQ, value);
out:
mutex_unlock(&dev_pm_qos_mtx);
}
@@ -92,7 +119,7 @@ EXPORT_SYMBOL_GPL(dev_pm_qos_add_request);
* Attempts are made to make this code callable on hot code paths.
*/
void dev_pm_qos_update_request(struct dev_pm_qos_request *req,
- s32 new_value)
+ s32 new_value)
{
if (!req) /*guard against callers passing in null */
return;
@@ -110,9 +137,7 @@ void dev_pm_qos_update_request(struct dev_pm_qos_request
*req,
goto out;
if (new_value != req->node.prio)
- pm_qos_update_target(
- req->dev->power.constraints,
- &req->node, PM_QOS_UPDATE_REQ, new_value);
+ _apply_constraint(req, PM_QOS_UPDATE_REQ, new_value);
out:
mutex_unlock(&dev_pm_qos_mtx);
@@ -143,9 +168,7 @@ void dev_pm_qos_remove_request(struct dev_pm_qos_request
*req)
if (req->dev->power.constraints_state != DEV_PM_QOS_ALLOCATED)
goto out;
- pm_qos_update_target(req->dev->power.constraints,
-&req->node, PM_QOS_REMOVE_REQ,
-PM_QOS_DEFAULT_VALUE);
+ _apply_constraint(req, PM_QOS_REMOVE_REQ, PM_QOS_DEFAULT_VALUE);
memset(req, 0, sizeof(*req));
out:
@@ -214,6 +237,36 @@ out:
}
EXPORT_SYMBOL_GPL(dev_pm_qos_remove_notifier);
+/**
+ * dev_pm_qos_add_global_notifier - sets notification entry for changes to
+ * target value of the PM QoS constraints for any device
+ *
+ * @notifier: notifier block managed by caller.
+ *
+ * Will register the notifier into a notification chain that gets called
+ * upon changes to the target value for any device.
+ */
+int dev_pm_qos_add_global_notifier(struct notifier_block *notifier)
+{
+ return blocking_notifier_chain_register(&dev_pm_notifiers, notifi
[PATCH 05/15] PM QoS: generalize and export the constraints management code
From: Jean Pihet
In preparation for the per-device constratins support:
- rename update_target to pm_qos_update_target
- generalize and export pm_qos_update_target for usage by the upcoming
per-device latency constraints framework:
. operate on struct pm_qos_constraints for constraints management,
. introduce an 'action' parameter for constraints add/update/remove,
. the return value indicates if the aggregated constraint value has
changed,
- update the internal code to operate on struct pm_qos_constraints
- add a NULL pointer check in the API functions
Signed-off-by: Jean Pihet
---
include/linux/pm_qos.h | 14 ++
kernel/power/qos.c | 123 ++--
2 files changed, 81 insertions(+), 56 deletions(-)
diff --git a/include/linux/pm_qos.h b/include/linux/pm_qos.h
index 9772311..84aa150 100644
--- a/include/linux/pm_qos.h
+++ b/include/linux/pm_qos.h
@@ -44,7 +44,16 @@ struct pm_qos_constraints {
struct blocking_notifier_head *notifiers;
};
+/* Action requested to pm_qos_update_target */
+enum pm_qos_req_action {
+ PM_QOS_ADD_REQ, /* Add a new request */
+ PM_QOS_UPDATE_REQ, /* Update an existing request */
+ PM_QOS_REMOVE_REQ /* Remove an existing request */
+};
+
#ifdef CONFIG_PM
+int pm_qos_update_target(struct pm_qos_constraints *c, struct plist_node *node,
+enum pm_qos_req_action action, int value);
void pm_qos_add_request(struct pm_qos_request *req, int pm_qos_class,
s32 value);
void pm_qos_update_request(struct pm_qos_request *req,
@@ -56,6 +65,11 @@ 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_active(struct pm_qos_request *req);
#else
+static inline int pm_qos_update_target(struct pm_qos_constraints *c,
+ struct plist_node *node,
+ enum pm_qos_req_action action,
+ int value)
+ { return 0; }
static inline void pm_qos_add_request(struct pm_qos_request *req,
int pm_qos_class, s32 value)
{ return; }
diff --git a/kernel/power/qos.c b/kernel/power/qos.c
index 4a35fe5..7c7cd18 100644
--- a/kernel/power/qos.c
+++ b/kernel/power/qos.c
@@ -122,17 +122,17 @@ static const struct file_operations pm_qos_power_fops = {
};
/* unlocked internal variant */
-static inline int pm_qos_get_value(struct pm_qos_object *o)
+static inline int pm_qos_get_value(struct pm_qos_constraints *c)
{
- if (plist_head_empty(&o->constraints->list))
- return o->constraints->default_value;
+ if (plist_head_empty(&c->list))
+ return c->default_value;
- switch (o->constraints->type) {
+ switch (c->type) {
case PM_QOS_MIN:
- return plist_first(&o->constraints->list)->prio;
+ return plist_first(&c->list)->prio;
case PM_QOS_MAX:
- return plist_last(&o->constraints->list)->prio;
+ return plist_last(&c->list)->prio;
default:
/* runtime check for not using enum */
@@ -140,47 +140,73 @@ static inline int pm_qos_get_value(struct pm_qos_object
*o)
}
}
-static inline s32 pm_qos_read_value(struct pm_qos_object *o)
+static inline s32 pm_qos_read_value(struct pm_qos_constraints *c)
{
- return o->constraints->target_value;
+ return c->target_value;
}
-static inline void pm_qos_set_value(struct pm_qos_object *o, s32 value)
+static inline void pm_qos_set_value(struct pm_qos_constraints *c, s32 value)
{
- o->constraints->target_value = value;
+ c->target_value = value;
}
-static void update_target(struct pm_qos_object *o, struct plist_node *node,
- int del, int value)
+/**
+ * pm_qos_update_target - manages the constraints list and calls the notifiers
+ * if needed
+ * @c: constraints data struct
+ * @node: request to add to the list, to update or to remove
+ * @action: action to take on the constraints list
+ * @value: value of the request to add or update
+ *
+ * This function returns 1 if the aggregated constraint value has changed, 0
+ * otherwise.
+ */
+int pm_qos_update_target(struct pm_qos_constraints *c, struct plist_node *node,
+enum pm_qos_req_action action, int value)
{
unsigned long flags;
- int prev_value, curr_value;
+ int prev_value, curr_value, new_value;
spin_lock_irqsave(&pm_qos_lock, flags);
- prev_value = pm_qos_get_value(o);
- /* PM_QOS_DEFAULT_VALUE is a signal that the value is unchanged */
- if (value != PM_QOS_DEFAULT_VALUE) {
+ prev_value = pm_qos_get_value(c);
+ if (value == PM_QOS_DEFAULT_VALUE)
+ new_value = c->default_val
[PATCH 04/15] PM QoS: re-organize data structs
From: Jean Pihet
In preparation for the per-device constratins support, re-organize
the data strctures:
- add a struct pm_qos_constraints which contains the constraints
related data
- update struct pm_qos_object contents to the PM QoS internal object
data. Add a pointer to struct pm_qos_constraints
- update the internal code to use the new data structs.
Signed-off-by: Jean Pihet
---
include/linux/pm_qos.h | 19 +++
kernel/power/qos.c | 85 +++-
2 files changed, 60 insertions(+), 44 deletions(-)
diff --git a/include/linux/pm_qos.h b/include/linux/pm_qos.h
index 6b0968f..9772311 100644
--- a/include/linux/pm_qos.h
+++ b/include/linux/pm_qos.h
@@ -25,6 +25,25 @@ struct pm_qos_request {
int pm_qos_class;
};
+enum pm_qos_type {
+ PM_QOS_UNITIALIZED,
+ PM_QOS_MAX, /* return the largest value */
+ PM_QOS_MIN /* return the smallest value */
+};
+
+/*
+ * Note: The lockless read path depends on the CPU accessing
+ * target_value atomically. Atomic access is only guaranteed on all CPU
+ * types linux supports for 32 bit quantites
+ */
+struct pm_qos_constraints {
+ struct plist_head list;
+ s32 target_value; /* Do not change to 64 bit */
+ s32 default_value;
+ enum pm_qos_type type;
+ struct blocking_notifier_head *notifiers;
+};
+
#ifdef CONFIG_PM
void pm_qos_add_request(struct pm_qos_request *req, int pm_qos_class,
s32 value);
diff --git a/kernel/power/qos.c b/kernel/power/qos.c
index 788c4cf..4a35fe5 100644
--- a/kernel/power/qos.c
+++ b/kernel/power/qos.c
@@ -49,58 +49,53 @@
* or pm_qos_object list and pm_qos_objects need to happen with pm_qos_lock
* held, taken with _irqsave. One lock to rule them all
*/
-enum pm_qos_type {
- PM_QOS_MAX, /* return the largest value */
- PM_QOS_MIN /* return the smallest value */
-};
-
-/*
- * Note: The lockless read path depends on the CPU accessing
- * target_value atomically. Atomic access is only guaranteed on all CPU
- * types linux supports for 32 bit quantites
- */
struct pm_qos_object {
- struct plist_head constraints;
- struct blocking_notifier_head *notifiers;
+ struct pm_qos_constraints *constraints;
struct miscdevice pm_qos_power_miscdev;
char *name;
- s32 target_value; /* Do not change to 64 bit */
- s32 default_value;
- enum pm_qos_type type;
};
static DEFINE_SPINLOCK(pm_qos_lock);
static struct pm_qos_object null_pm_qos;
+
static BLOCKING_NOTIFIER_HEAD(cpu_dma_lat_notifier);
-static struct pm_qos_object cpu_dma_pm_qos = {
- .constraints = PLIST_HEAD_INIT(cpu_dma_pm_qos.constraints),
- .notifiers = &cpu_dma_lat_notifier,
- .name = "cpu_dma_latency",
+static struct pm_qos_constraints cpu_dma_constraints = {
+ .list = PLIST_HEAD_INIT(cpu_dma_constraints.list),
.target_value = PM_QOS_CPU_DMA_LAT_DEFAULT_VALUE,
.default_value = PM_QOS_CPU_DMA_LAT_DEFAULT_VALUE,
.type = PM_QOS_MIN,
+ .notifiers = &cpu_dma_lat_notifier,
+};
+static struct pm_qos_object cpu_dma_pm_qos = {
+ .constraints = &cpu_dma_constraints,
};
static BLOCKING_NOTIFIER_HEAD(network_lat_notifier);
-static struct pm_qos_object network_lat_pm_qos = {
- .constraints = PLIST_HEAD_INIT(network_lat_pm_qos.constraints),
- .notifiers = &network_lat_notifier,
- .name = "network_latency",
+static struct pm_qos_constraints network_lat_constraints = {
+ .list = PLIST_HEAD_INIT(network_lat_constraints.list),
.target_value = PM_QOS_NETWORK_LAT_DEFAULT_VALUE,
.default_value = PM_QOS_NETWORK_LAT_DEFAULT_VALUE,
- .type = PM_QOS_MIN
+ .type = PM_QOS_MIN,
+ .notifiers = &network_lat_notifier,
+};
+static struct pm_qos_object network_lat_pm_qos = {
+ .constraints = &network_lat_constraints,
+ .name = "network_latency",
};
static BLOCKING_NOTIFIER_HEAD(network_throughput_notifier);
-static struct pm_qos_object network_throughput_pm_qos = {
- .constraints = PLIST_HEAD_INIT(network_throughput_pm_qos.constraints),
- .notifiers = &network_throughput_notifier,
- .name = "network_throughput",
+static struct pm_qos_constraints network_tput_constraints = {
+ .list = PLIST_HEAD_INIT(network_tput_constraints.list),
.target_value = PM_QOS_NETWORK_THROUGHPUT_DEFAULT_VALUE,
.default_value = PM_QOS_NETWORK_THROUGHPUT_DEFAULT_VALUE,
.type = PM_QOS_MAX,
+ .notifiers = &network_throughput_notifier,
+};
+static struct pm_qos_object network_throughput_pm_qos = {
+ .constraints = &network_tput_constraints,
+ .name = "network_throughput",
};
@@ -129,15 +124,15 @@ static const struct file_operations pm_qos_power_fops = {
/* unlocked internal variant */
static inline int pm_qos_get_value(struct pm_qos_object *o)
{
- if (plist_head_empty(&o->c
[PATCH 03/15] PM QoS: code re-organization
From: Jean Pihet
Move around the PM QoS misc devices management code
for better readability.
Signed-off-by: Jean Pihet
---
kernel/power/qos.c | 45 +++--
1 files changed, 23 insertions(+), 22 deletions(-)
diff --git a/kernel/power/qos.c b/kernel/power/qos.c
index aa52c44..788c4cf 100644
--- a/kernel/power/qos.c
+++ b/kernel/power/qos.c
@@ -188,28 +188,6 @@ static void update_target(struct pm_qos_object *o, struct
plist_node *node,
NULL);
}
-static int register_pm_qos_misc(struct pm_qos_object *qos)
-{
- qos->pm_qos_power_miscdev.minor = MISC_DYNAMIC_MINOR;
- qos->pm_qos_power_miscdev.name = qos->name;
- qos->pm_qos_power_miscdev.fops = &pm_qos_power_fops;
-
- return misc_register(&qos->pm_qos_power_miscdev);
-}
-
-static int find_pm_qos_object_by_minor(int minor)
-{
- int pm_qos_class;
-
- for (pm_qos_class = 0;
- pm_qos_class < PM_QOS_NUM_CLASSES; pm_qos_class++) {
- if (minor ==
- pm_qos_array[pm_qos_class]->pm_qos_power_miscdev.minor)
- return pm_qos_class;
- }
- return -1;
-}
-
/**
* pm_qos_request - returns current system wide qos expectation
* @pm_qos_class: identification of which qos value is requested
@@ -362,6 +340,29 @@ int pm_qos_remove_notifier(int pm_qos_class, struct
notifier_block *notifier)
}
EXPORT_SYMBOL_GPL(pm_qos_remove_notifier);
+/* User space interface to PM QoS classes via misc devices */
+static int register_pm_qos_misc(struct pm_qos_object *qos)
+{
+ qos->pm_qos_power_miscdev.minor = MISC_DYNAMIC_MINOR;
+ qos->pm_qos_power_miscdev.name = qos->name;
+ qos->pm_qos_power_miscdev.fops = &pm_qos_power_fops;
+
+ return misc_register(&qos->pm_qos_power_miscdev);
+}
+
+static int find_pm_qos_object_by_minor(int minor)
+{
+ int pm_qos_class;
+
+ for (pm_qos_class = 0;
+ pm_qos_class < PM_QOS_NUM_CLASSES; pm_qos_class++) {
+ if (minor ==
+ pm_qos_array[pm_qos_class]->pm_qos_power_miscdev.minor)
+ return pm_qos_class;
+ }
+ return -1;
+}
+
static int pm_qos_power_open(struct inode *inode, struct file *filp)
{
long pm_qos_class;
--
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 02/15] PM QoS: minor clean-ups
From: Jean Pihet
- Misc fixes to improve code readability:
. rename struct pm_qos_request_list to struct pm_qos_request,
. rename pm_qos_req parameter to req in internal code,
consistenly use req in the API parameters,
. update the in-kernel API callers to the new parameters names,
. rename of fields names (requests, list, node, constraints)
Signed-off-by: Jean Pihet
---
drivers/media/video/via-camera.c |2 +-
drivers/net/wireless/ipw2x00/ipw2100.c |2 +-
include/linux/netdevice.h |2 +-
include/linux/pm_qos.h | 22
include/sound/pcm.h|2 +-
kernel/power/qos.c | 88
6 files changed, 59 insertions(+), 59 deletions(-)
diff --git a/drivers/media/video/via-camera.c b/drivers/media/video/via-camera.c
index b3ca389..fba6c64 100644
--- a/drivers/media/video/via-camera.c
+++ b/drivers/media/video/via-camera.c
@@ -69,7 +69,7 @@ struct via_camera {
struct mutex lock;
enum viacam_opstate opstate;
unsigned long flags;
- struct pm_qos_request_list qos_request;
+ struct pm_qos_request qos_request;
/*
* GPIO info for power/reset management
*/
diff --git a/drivers/net/wireless/ipw2x00/ipw2100.c
b/drivers/net/wireless/ipw2x00/ipw2100.c
index aaab76c..db35f99 100644
--- a/drivers/net/wireless/ipw2x00/ipw2100.c
+++ b/drivers/net/wireless/ipw2x00/ipw2100.c
@@ -174,7 +174,7 @@ that only one external action is invoked at a time.
#define DRV_DESCRIPTION"Intel(R) PRO/Wireless 2100 Network Driver"
#define DRV_COPYRIGHT "Copyright(c) 2003-2006 Intel Corporation"
-static struct pm_qos_request_list ipw2100_pm_qos_req;
+static struct pm_qos_request ipw2100_pm_qos_req;
/* Debugging stuff */
#ifdef CONFIG_IPW2100_DEBUG
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index f72ac6b..f38ab5b 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -964,7 +964,7 @@ struct net_device {
*/
charname[IFNAMSIZ];
- struct pm_qos_request_list pm_qos_req;
+ struct pm_qos_request pm_qos_req;
/* device name hash chain */
struct hlist_node name_hlist;
diff --git a/include/linux/pm_qos.h b/include/linux/pm_qos.h
index 7ba67541..6b0968f 100644
--- a/include/linux/pm_qos.h
+++ b/include/linux/pm_qos.h
@@ -20,30 +20,30 @@
#define PM_QOS_NETWORK_LAT_DEFAULT_VALUE (2000 * USEC_PER_SEC)
#define PM_QOS_NETWORK_THROUGHPUT_DEFAULT_VALUE0
-struct pm_qos_request_list {
- struct plist_node list;
+struct pm_qos_request {
+ struct plist_node node;
int pm_qos_class;
};
#ifdef CONFIG_PM
-void pm_qos_add_request(struct pm_qos_request_list *l,
- int pm_qos_class, s32 value);
-void pm_qos_update_request(struct pm_qos_request_list *pm_qos_req,
+void pm_qos_add_request(struct pm_qos_request *req, int pm_qos_class,
+ s32 value);
+void pm_qos_update_request(struct pm_qos_request *req,
s32 new_value);
-void pm_qos_remove_request(struct pm_qos_request_list *pm_qos_req);
+void pm_qos_remove_request(struct pm_qos_request *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_active(struct pm_qos_request_list *req);
+int pm_qos_request_active(struct pm_qos_request *req);
#else
-static inline void pm_qos_add_request(struct pm_qos_request_list *l,
+static inline void pm_qos_add_request(struct pm_qos_request *req,
int pm_qos_class, s32 value)
{ return; }
-static inline void pm_qos_update_request(struct pm_qos_request_list
*pm_qos_req,
+static inline void pm_qos_update_request(struct pm_qos_request *req,
s32 new_value)
{ return; }
-static inline void pm_qos_remove_request(struct pm_qos_request_list
*pm_qos_req)
+static inline void pm_qos_remove_request(struct pm_qos_request *req)
{ return; }
static inline int pm_qos_request(int pm_qos_class)
@@ -54,7 +54,7 @@ static inline int pm_qos_add_notifier(int pm_qos_class,
static inline int pm_qos_remove_notifier(int pm_qos_class,
struct notifier_block *notifier)
{ return 0; }
-static inline int pm_qos_request_active(struct pm_qos_request_list *req)
+static inline int pm_qos_request_active(struct pm_qos_request *req)
{ return 0; }
#endif
diff --git a/include/sound/pcm.h b/include/sound/pcm.h
index 666ee91..54cb079 100644
--- a/include/sound/pcm.h
+++ b/include/sound/pcm.h
@@ -373,7 +373,7 @@ struct snd_pcm_substream {
int number;
char name[32]; /* sub
[PATCH 01/15] PM QoS: move and rename the implementation files
From: Jean Pihet
The PM QoS implementation files are better named
kernel/power/qos.c and include/linux/pm_qos.h.
The PM QoS support is compiled under the CONFIG_PM option.
Signed-off-by: Jean Pihet
---
arch/arm/mach-msm/clock.c |2 +-
drivers/acpi/processor_idle.c |2 +-
drivers/cpuidle/cpuidle.c |2 +-
drivers/cpuidle/governors/ladder.c |2 +-
drivers/cpuidle/governors/menu.c |2 +-
drivers/media/video/via-camera.c |2 +-
drivers/net/e1000e/netdev.c|2 +-
drivers/net/wireless/ipw2x00/ipw2100.c |2 +-
include/linux/netdevice.h |2 +-
include/linux/pm_qos.h | 61
include/linux/pm_qos_params.h | 38 ---
include/sound/pcm.h|2 +-
kernel/Makefile|2 +-
kernel/pm_qos_params.c | 481
kernel/power/Makefile |2 +-
kernel/power/qos.c | 481
net/mac80211/main.c|2 +-
net/mac80211/mlme.c|2 +-
net/mac80211/scan.c|2 +-
sound/core/pcm_native.c|2 +-
20 files changed, 558 insertions(+), 535 deletions(-)
create mode 100644 include/linux/pm_qos.h
delete mode 100644 include/linux/pm_qos_params.h
delete mode 100644 kernel/pm_qos_params.c
create mode 100644 kernel/power/qos.c
diff --git a/arch/arm/mach-msm/clock.c b/arch/arm/mach-msm/clock.c
index 22a5376..d9145df 100644
--- a/arch/arm/mach-msm/clock.c
+++ b/arch/arm/mach-msm/clock.c
@@ -18,7 +18,7 @@
#include
#include
#include
-#include
+#include
#include
#include
#include
diff --git a/drivers/acpi/processor_idle.c b/drivers/acpi/processor_idle.c
index 431ab11..2e69e09 100644
--- a/drivers/acpi/processor_idle.c
+++ b/drivers/acpi/processor_idle.c
@@ -37,7 +37,7 @@
#include
#include
#include/* need_resched() */
-#include
+#include
#include
#include
#include
diff --git a/drivers/cpuidle/cpuidle.c b/drivers/cpuidle/cpuidle.c
index d4c5423..0df0141 100644
--- a/drivers/cpuidle/cpuidle.c
+++ b/drivers/cpuidle/cpuidle.c
@@ -12,7 +12,7 @@
#include
#include
#include
-#include
+#include
#include
#include
#include
diff --git a/drivers/cpuidle/governors/ladder.c
b/drivers/cpuidle/governors/ladder.c
index 12c9890..f62fde2 100644
--- a/drivers/cpuidle/governors/ladder.c
+++ b/drivers/cpuidle/governors/ladder.c
@@ -14,7 +14,7 @@
#include
#include
-#include
+#include
#include
#include
diff --git a/drivers/cpuidle/governors/menu.c b/drivers/cpuidle/governors/menu.c
index c47f3d0..3600f19 100644
--- a/drivers/cpuidle/governors/menu.c
+++ b/drivers/cpuidle/governors/menu.c
@@ -12,7 +12,7 @@
#include
#include
-#include
+#include
#include
#include
#include
diff --git a/drivers/media/video/via-camera.c b/drivers/media/video/via-camera.c
index 85d3048..b3ca389 100644
--- a/drivers/media/video/via-camera.c
+++ b/drivers/media/video/via-camera.c
@@ -21,7 +21,7 @@
#include
#include
#include
-#include
+#include
#include
#include
#include
diff --git a/drivers/net/e1000e/netdev.c b/drivers/net/e1000e/netdev.c
index ab4be80..40deb44 100644
--- a/drivers/net/e1000e/netdev.c
+++ b/drivers/net/e1000e/netdev.c
@@ -47,7 +47,7 @@
#include
#include
#include
-#include
+#include
#include
#include
#include
diff --git a/drivers/net/wireless/ipw2x00/ipw2100.c
b/drivers/net/wireless/ipw2x00/ipw2100.c
index 3774dd0..aaab76c 100644
--- a/drivers/net/wireless/ipw2x00/ipw2100.c
+++ b/drivers/net/wireless/ipw2x00/ipw2100.c
@@ -161,7 +161,7 @@ that only one external action is invoked at a time.
#include
#include
#include
-#include
+#include
#include
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index ddee79b..f72ac6b 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -31,7 +31,7 @@
#include
#ifdef __KERNEL__
-#include
+#include
#include
#include
#include
diff --git a/include/linux/pm_qos.h b/include/linux/pm_qos.h
new file mode 100644
index 000..7ba67541
--- /dev/null
+++ b/include/linux/pm_qos.h
@@ -0,0 +1,61 @@
+#ifndef _LINUX_PM_QOS_H
+#define _LINUX_PM_QOS_H
+/* interface for the pm_qos_power infrastructure of the linux kernel.
+ *
+ * Mark Gross
+ */
+#include
+#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_NUM_CLASSES 4
+#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_VALUE0
+
+struct pm_qos_request_list {
+ struct plist_node list;
+ int pm_qos_class;
+};
+
+#ifdef CONFIG_PM
+void pm_qos_add_request(struct
[PATCH v5 00/15] PM QoS: add a per-device latency constraints framework
From: Jean Pihet High level implementation: 1. Preparation of the PM QoS for the addition of a device PM QoS constraints framework: . rename and move of the PM QoS implementation files to kernel/power/qos.c and include/linux/pm_qos.h . rename of API parameters and internal fields names . Move around the PM QoS misc devices management code for better readability . re-organize the internal data structs . generalize and export the constraints management core code 2. Implementation of the per-device PM QoS constraints: . create drivers/base/power/qos.c for the implementation . create a device PM QoS API, which calls the PM QoS constraints management core code . the per-device latency constraints data strctures are stored in the device dev_pm_info struct . the device PM code calls the init and destroy of the per-device constraints data struct in order to support the dynamic insertion and removal of the devices in the system. . to minimize the data usage by the per-device constraints, the data struct is only allocated at the first call to dev_pm_qos_add_request. The data is later free'd when the device is removed from the system . per-device notification callbacks can be registered and called upon a change to the aggregated constraint value . a global mutex protects the constraints users from the data being allocated and free'd. 3. add a global notification mechanism for the device constraints . add a global notification chain that gets called upon changes to the aggregated constraint value for any device. . the notification callbacks are passing the full constraint request data in order for the callees to have access to it. The current use is for the platform low-level code to access the target device of the constraint 4. Implement the OMAP low level constraints management code . create a PM layer plugin for per-device constraints, compiled under CONFIG_OMAP_PM_CONSTRAINTS=y . implement the devices wake-up latency constraints using the global device PM QoS notification handler which applies the constraints to the underlying layer . implement the low level code which controls the power domains next power states, through the hwmod and pwrdm layers . add (preliminary) power domains wake-up latency figures for OMAP3&4 . cpuidle is a CPU centric framework so 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 devices PM QoS framework, via the devices wake-up latency constraints. . convert the OMAP I2C driver to the PM QoS API for MPU latency constraints Questions: 1. the user space API is still under discussions on linux-omap and linux-pm MLs, cf. [1]. The idea is to add a user-space API for the devices constratins PM QoS, using a sysfs entry per device [1] http://marc.info/?l=linux-omap&m=131232344503327&w=2 ToDo: 1. write Documentation for the new PM QoS class, once the code is agreed on 2. validate the constraints framework on OMAP4 HW (done on OMAP3) 3. Need testing on platforms other than OMAP 4. refine the power domains wake-up latency and the cpuidle figures 5. re-visit the OMAP power domains states initialization procedure. Currently the power states that have been changed from the constraints API which were applied before the initialization of the power domains are lost Based on the master branch of the linux-omap git tree (3.1.0-rc1). Compile tested using OMAP and x86 generic defconfigs. Tested on OMAP3 Beagleboard (ES2.x). Need testing on platforms other than OMAP, because of the impact on the device insertion/removal in device_pm_add/remove Changelog: v5: . Added a global mutex to protect the per-device data allocation/free from the users . More robust error checking in the device PM QoS code . Clean-up of the device PM QoS code: refactor some duplicated code, removal of unneeded includes v4: . Complete devices PM QoS re-design: . Separation from the existing PM QoS classes by adding a device PM QoS API. The device code is re-using the PM QoS core code for constraints lists management and notification mechanism . Addition of a devices PM QoS global notification mechanism, for interaction with the low level platform code v3: . Complete PM QoS re-design after the comments on MLs . Patch set split up for improved readability and easier maintenance v2: . Rework after comments on the mailing lists . Added a notification of device insertion/removal from the device PM framework . Validated on OMAP3 HW v1: . Initial implementation Jean Pihet (14): PM QoS: move and rename the implementation files PM QoS: minor clean-ups PM QoS: code re-organization PM QoS: re-organize data structs PM QoS: generalize and export the constraints management code PM QoS: implement the per-device PM QoS constraints PM QoS: add a g
Re: [PATCH] DMAEngine: Define generic transfer request api
On Tue, Aug 16, 2011 at 2:56 PM, Koul, Vinod wrote: > Currently we have two approaches to solve this problem first being the > DMA_STRIDE_CONFIG proposed by Linus W, I feel this one is better > approach as this can give client ability to configure each transfer > rather than set for the channel. Linus W, do you agree? I think Sundaram is in the position of doing some heavy work on using one or the other of the API:s, and I think he is better suited than anyone else of us to select what scheme to use, in the end he's going to write the first code using the API. Yours, Linus Walleij -- 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] DMAEngine: Define generic transfer request api
On Fri, 2011-08-12 at 16:44 +0530, Jassi Brar wrote:
> Define a new api that could be used for doing fancy data transfers
> like interleaved to contiguous copy and vice-versa.
> Traditional SG_list based transfers tend to be very inefficient in
> such cases as where the interleave and chunk are only a few bytes,
> which call for a very condensed api to convey pattern of the transfer.
>
> This api supports all 4 variants of scatter-gather and contiguous transfer.
> Besides, it could also represent common operations like
> device_prep_dma_{cyclic, memset, memcpy}
> and maybe some more that I am not sure of.
>
> Of course, neither can this api help transfers that don't lend to DMA by
> nature, i.e, scattered tiny read/writes with no periodic pattern.
>
> Signed-off-by: Jassi Brar
> ---
> include/linux/dmaengine.h | 73
> +
> 1 files changed, 73 insertions(+), 0 deletions(-)
>
> diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
> index 8fbf40e..74f3ae0 100644
> --- a/include/linux/dmaengine.h
> +++ b/include/linux/dmaengine.h
> @@ -76,6 +76,76 @@ enum dma_transaction_type {
> /* last transaction type for creation of the capabilities mask */
> #define DMA_TX_TYPE_END (DMA_CYCLIC + 1)
>
> +/**
> + * Generic Transfer Request
> + *
> + * A chunk is collection of contiguous bytes to be transfered.
> + * The gap(in bytes) between two chunks is called inter-chunk-gap(ICG).
> + * ICGs may or maynot change between chunks.
> + * A FRAME is the smallest series of contiguous {chunk,icg} pairs,
> + * that when repeated an integral number of times, specifies the transfer.
> + * A transfer template is specification of a Frame, the number of times
> + * it is to be repeated and other per-transfer attributes.
> + *
> + * Practically, a client driver would have ready a template for each
> + * type of transfer it is going to need during its lifetime and
> + * set only 'src_start' and 'dst_start' before submitting the requests.
> + *
> + *
> + * | Frame-1| Frame-2 | ~ | Frame-'numf' |
> + * |==.===...=...|==.===...=...| ~ |==.===...=...|
> + *
> + *== Chunk size
> + *... ICG
> + */
> +
> +/**
> + * struct data_chunk - Element of scatter-gather list that makes a frame.
> + * @size: Number of bytes to read from source.
> + * size_dst := fn(op, size_src), so doesn't mean much for destination.
> + * @icg: Number of bytes to jump after last src/dst address of this
> + *chunk and before first src/dst address for next chunk.
> + *Ignored for dst(assumed 0), if dst_inc is true and dst_sgl is false.
> + *Ignored for src(assumed 0), if src_inc is true and src_sgl is false.
> + */
> +struct data_chunk {
> + size_t size;
> + size_t icg;
> +};
> +
> +/**
> + * struct xfer_template - Template to convey DMAC the transfer pattern
> + *and attributes.
> + * @op: The operation to perform on source data before writing it on
> + *to destination address.
> + * @src_start: Bus address of source for the first chunk.
> + * @dst_start: Bus address of destination for the first chunk.
> + * @src_inc: If the source address increments after reading from it.
> + * @dst_inc: If the destination address increments after writing to it.
> + * @src_sgl: If the 'icg' of sgl[] applies to Source (scattered read).
> + * Otherwise, source is read contiguously (icg ignored).
> + * Ignored if src_inc is false.
> + * @dst_sgl: If the 'icg' of sgl[] applies to Destination (scattered write).
> + * Otherwise, destination is filled contiguously (icg ignored).
> + * Ignored if dst_inc is false.
> + * @frm_irq: If the client expects DMAC driver to do callback after each
> frame.
> + * @numf: Number of frames in this template.
> + * @frame_size: Number of chunks in a frame i.e, size of sgl[].
> + * @sgl: Array of {chunk,icg} pairs that make up a frame.
> + */
> +struct xfer_template {
> + enum dma_transaction_type op;
> + dma_addr_t src_start;
> + dma_addr_t dst_start;
> + bool src_inc;
> + bool dst_inc;
> + bool src_sgl;
> + bool dst_sgl;
> + bool frm_irq;
> + size_t numf;
> + size_t frame_size;
> + struct data_chunk sgl[0];
> +};
>
> /**
> * enum dma_ctrl_flags - DMA flags to augment operation preparation,
> @@ -432,6 +502,7 @@ struct dma_tx_state {
> * @device_prep_dma_cyclic: prepare a cyclic dma operation suitable for
> audio.
> * The function takes a buffer of size buf_len. The callback function will
> * be called after period_len bytes have been transferred.
> + * @device_prep_dma_genxfer: Transfer expression in a generic way.
> * @device_control: manipulate all pending operations on a channel, returns
> * zero or error code
> * @device_tx_status: poll for transaction completion, the optional
> @@ -496,6 +567,8 @@ struct dma_device {
> struct dma_async_t
Re: [PATCH 07/15] PM QoS: add a global notification mechanism for the device constraints
Hi Rafael,
2011/8/14 Rafael J. Wysocki :
> Hi,
>
> There is some code duplication in this patch that should better be
> avoided (details below).
>
> On Thursday, August 11, 2011, jean.pi...@newoldbits.com wrote:
>> From: Jean Pihet
>>
>> Add a global notification chain that gets called upon changes to the
>> aggregated constraint value for any device.
>> The notification callbacks are passing the full constraint request data
>> in order for the callees to have access to it. The current use is for the
>> platform low-level code to access the target device of the constraint.
>>
...
>
> The following code:
>
>> + /*
>> + * Update constraints list and call the per-device callbacks if needed
>> + */
>> + ret = pm_qos_update_target(dev->power.constraints,
>> + &req->node, PM_QOS_ADD_REQ, value);
>> +
>> + if (ret) {
>> + /* Call the global callbacks if needed */
>> + curr_value = pm_qos_read_value(req->dev->power.constraints);
>> + blocking_notifier_call_chain(&dev_pm_notifiers,
>> + (unsigned long)curr_value,
>> + req);
>> + }
>
> is used in dev_pm_qos_update_request() and dev_pm_qos_remove_request()
> with the only difference being the command given to pm_qos_update_target().
> This asks for a common function, eg. dev_pm_qos_update_target(), containing
> that code that will be called by all of them (and, apparently, by
> dev_pm_qos_constraints_destroy()).
Ok that makes the code cleaner.
>
> ...
>> @@ -250,9 +329,18 @@ void dev_pm_qos_constraints_destroy(struct device *dev)
>> * Update constraints list and call the per-device
>> * callbacks if needed
>> */
>> - pm_qos_update_target(req->dev->power.constraints,
>> - &req->node, PM_QOS_REMOVE_REQ,
>> - PM_QOS_DEFAULT_VALUE);
>> + ret |=
>> pm_qos_update_target(req->dev->power.constraints,
>> + &req->node,
>> + PM_QOS_REMOVE_REQ,
>> + PM_QOS_DEFAULT_VALUE);
>
> I'm not sure why you're using the binary or operator here. Shouldn't that be
> a simple assignment?
>
>> +
>> + if (ret) {
>> + /* Call the global callbacks if needed */
>> + curr_value = dev->power.constraints->default_value;
>> + blocking_notifier_call_chain(&dev_pm_notifiers,
>> + (unsigned long)curr_value,
>> + req);
>> + }
In the sake of optimization I had a single return value that
aggregates the return values of the calls target_value and calls the
global notifier callbacks _only once_.
As you suggested it is better to use the common update code, which
makes the code cleaner but also removes this optimization.
>>
>> kfree(dev->power.constraints->notifiers);
>> kfree(dev->power.constraints);
>
> Thanks,
> Rafael
>
Regards,
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
