* Re: [PATCH][v2] ARM: davinci: cpuidle - remove ops
From: Sekhar Nori @ 2012-05-22 17:58 UTC (permalink / raw)
To: Daniel Lezcano
Cc: khilman-l0cyMroinI0,
davinci-linux-open-source-VycZQUHpC/PFrsHnngEfi1aTQe2KTcn/,
linaro-dev-cunTk1MwBs8s++Sfvej+rw, patches-QSEj5FYQhm4dnm+yROfE0A,
linux-pm-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
lenb-DgEjT+Ai2ygdnm+yROfE0A
In-Reply-To: <1337551640-5973-1-git-send-email-daniel.lezcano-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Hi Daniel,
On 5/21/2012 3:37 AM, Daniel Lezcano wrote:
> This patch removes the ops usage because we have the index
> passed as parameter to the idle function and we can determine
> if we do WFI or memory retention.
>
> The benefit of this cleanup is the removal of:
> * the ops
> * the statedata usage because we want to get rid of it in all the drivers
> * extra structure definition
> * extra functions definition
> * remove macro definition using BIT(0)
>
> It also benefits the readability.
>
> Signed-off-by: Daniel Lezcano <daniel.lezcano-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Looks good to me. If there is no other plan, I will queue these two
cpuidle patches for v3.6 through DaVinci tree.
Thanks,
Sekhar
^ permalink raw reply
* uswsusp and plymouth don't play nice together
From: Mikko Vinni @ 2012-05-21 6:52 UTC (permalink / raw)
To: plymouth-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org,
linux-pm-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Cc: Rafael J. Wysocki, Rabin Vincent
Hi,
has any uswsusp[1] (aka suspend-utils) or plymouth[2] developer tested the
two together? It seems there is a hang during resume from s2disk, and the
resume can be continued by pressing ALT-SysRq-K or ALT-SysRq-E.
This is not hardware specific neither new. For example, there is a bug report
for Debian[3] opened in 2010 (don't get confused by the reference to the
blinking fb cursor bug). Personally, I have tested on Ubuntu 12.04 and
Arch Linux (stable and some rc kernel versions for some months now).
Easily reproduced also in a virtual machine, without graphical splash.
The hang does not occur if using the in-kernel hibernation, nor when
not starting plymouth before resume.
ALT-SysRq-T shows this backtrace for the 'plymouthd' and 'resume' processes:
[ 51.853427] plymouthd D 0000000000000000 0 55 1 0x00000004
[ 51.853427] ffff88000da6fd18 0000000000000086 ffff88000da58000 ffff88000da6ffd8
[ 51.853427] ffff88000da6ffd8 ffff88000da6ffd8 ffff88000da59000 ffff88000da58000
[ 51.853427] 0000000000000000 ffff88000da58490 ffff88000da6fc78 ffff88000d9bd500
[ 51.853427] Call Trace:
[ 51.853427] [<ffffffff8107d879>] ? finish_task_switch+0x49/0xd0
[ 51.853427] [<ffffffff8145daa1>] ? __schedule+0x431/0x900
[ 51.853427] [<ffffffff8145e0af>] schedule+0x3f/0x60
[ 51.853427] [<ffffffff8109b9b3>] __refrigerator+0x43/0xe0
[ 51.853427] [<ffffffff810bdb72>] ? cgroup_freezing+0x32/0x40
[ 51.853427] [<ffffffff8106499d>] get_signal_to_deliver+0x56d/0x600
[ 51.853427] [<ffffffff8118687c>] ? destroy_inode+0x3c/0x70
[ 51.853427] [<ffffffff81014278>] do_signal+0x68/0x750
[ 51.853427] [<ffffffff811b04f1>] ? ep_poll+0x2a1/0x360
[ 51.853427] [<ffffffff811b09ed>] ? sys_epoll_ctl+0xad/0x850
[ 51.853427] [<ffffffff8116dfeb>] ? fput+0x16b/0x210
[ 51.853427] [<ffffffff810149e5>] do_notify_resume+0x65/0x80
[ 51.853427] [<ffffffff81460122>] int_signal+0x12/0x17
[ 51.853427] resume S ffff88000da593c8 0 57 1 0x00000000
[ 51.853427] ffff88000da5fd48 0000000000000082 ffff88000da59000 ffff88000da5ffd8
[ 51.853427] ffff88000da5ffd8 ffff88000da5ffd8 ffffffff8180d020 ffff88000da59000
[ 51.853427] ffff88000da59000 ffff88000da5ffd8 ffff88000da5ffd8 ffff88000da5ffd8
[ 51.853427] Call Trace:
[ 51.853427] [<ffffffff8108014c>] ? ttwu_do_wakeup+0x2c/0x120
[ 51.853427] [<ffffffff8145eed8>] ? _raw_spin_unlock_irqrestore+0x38/0x50
[ 51.853427] [<ffffffff8145e0af>] schedule+0x3f/0x60
[ 51.853427] [<ffffffff812e20f7>] vt_event_wait+0xa7/0x130
[ 51.853427] [<ffffffff81072570>] ? abort_exclusive_wait+0xb0/0xb0
[ 51.853427] [<ffffffff812e225d>] vt_waitactive+0x2d/0x60
[ 51.853427] [<ffffffff8145cc26>] ? mutex_lock+0x16/0x30
[ 51.853427] [<ffffffff812e4886>] vt_move_to_console+0x56/0xc0
[ 51.853427] [<ffffffff81094388>] pm_prepare_console+0x18/0x40
[ 51.853427] [<ffffffff81095974>] hibernation_restore+0x14/0x130
[ 51.853427] [<ffffffff8109afe8>] snapshot_ioctl+0x218/0x4a0
[ 51.853427] [<ffffffff8117e787>] do_vfs_ioctl+0x97/0x530
[ 51.853427] [<ffffffff8118ae14>] ? mntput+0x24/0x40
[ 51.853427] [<ffffffff8116dfeb>] ? fput+0x16b/0x210
[ 51.853427] [<ffffffff8117ecb9>] sys_ioctl+0x99/0xa0
[ 51.853427] [<ffffffff8145fe69>] system_call_fastpath+0x16/0x1b
Does plymouthd register to listen for console change, or something else
that it can't do while refrigerated?
There was on May 18th a patch proposed for the vt_event_wait() function[4],
but that patch has no effect for this particular hang.
Apparently Mandriva has a patch[5] to add plymouth support to uswsusp, but one
would assume that s2disk/resume should not hang in its default state.
Any ideas?
Mikko
--
[1] http://suspend.sourceforge.net/
[2] http://cgit.freedesktop.org/plymouth/
[3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=593795
[4] "Race in vt_event_wait() during suspend/resume": http://article.gmane.org/gmane.linux.kernel/1299487
[5] changelog e.g.: http://rpmfind.net//linux/RPM/mandriva/2011/x86_64/media/main/release/suspend-0.8-12.20080612.x86_64.html
^ permalink raw reply
* Re: [PATCH 0/2] bug fixes for coupled cpuidle
From: Santosh Shilimkar @ 2012-05-21 6:44 UTC (permalink / raw)
To: Colin Cross
Cc: Kevin Hilman, Len Brown, linux-kernel, Amit Kucheria, linux-pm,
Arjan van de Ven, linux-arm-kernel
In-Reply-To: <1337364324-12171-1-git-send-email-ccross@android.com>
On Friday 18 May 2012 11:35 PM, Colin Cross wrote:
> The last modifications made to the coupled cpuidle patches introduced
> two bugs that I missed during testing. The online count was never
> initialized, causing coupled idle to always wait and never enter the
> ready loop. That hid the second bug, the ready count could never be
> decremented after exiting idle.
>
> Len, these two patches could be squashed into patch 3 of the original
> set. If you do squash them, you could also add Rafael's tags to the
> set (Reviewed-by on 1 and 2, acked-by on 3). Or I can reupload the
> whole stack as v5 if you prefer.
I confirm that these two fixes are needed to get couple idle
v4 series working.
Regards
Santosh
^ permalink raw reply
* [PATCH][v2] ARM: davinci: cpuidle - remove ops
From: Daniel Lezcano @ 2012-05-20 22:07 UTC (permalink / raw)
To: nsekhar, khilman; +Cc: davinci-linux-open-source, patches, linaro-dev, linux-pm
This patch removes the ops usage because we have the index
passed as parameter to the idle function and we can determine
if we do WFI or memory retention.
The benefit of this cleanup is the removal of:
* the ops
* the statedata usage because we want to get rid of it in all the drivers
* extra structure definition
* extra functions definition
* remove macro definition using BIT(0)
It also benefits the readability.
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
---
arch/arm/mach-davinci/cpuidle.c | 81 +++++++++++++--------------------------
1 files changed, 27 insertions(+), 54 deletions(-)
diff --git a/arch/arm/mach-davinci/cpuidle.c b/arch/arm/mach-davinci/cpuidle.c
index f0f179c..1b0782a 100644
--- a/arch/arm/mach-davinci/cpuidle.c
+++ b/arch/arm/mach-davinci/cpuidle.c
@@ -25,35 +25,46 @@
#define DAVINCI_CPUIDLE_MAX_STATES 2
-struct davinci_ops {
- void (*enter) (u32 flags);
- void (*exit) (u32 flags);
- u32 flags;
-};
+static bool ddr2_pwdn;
+
+static void __iomem *ddr2_reg_base;
+
+static void davinci_save_ddr_power(int enter, bool pdown)
+{
+ u32 val;
+
+ val = readl(ddr2_reg_base + DDR2_SDRCR_OFFSET);
+
+ if (enter) {
+ if (pdown)
+ val |= DDR2_SRPD_BIT;
+ else
+ val &= ~DDR2_SRPD_BIT;
+ val |= DDR2_LPMODEN_BIT;
+ } else {
+ val &= ~(DDR2_SRPD_BIT | DDR2_LPMODEN_BIT);
+ }
+
+ writel(val, ddr2_reg_base + DDR2_SDRCR_OFFSET);
+}
/* Actual code that puts the SoC in different idle states */
static int davinci_enter_idle(struct cpuidle_device *dev,
struct cpuidle_driver *drv,
int index)
{
- struct cpuidle_state_usage *state_usage = &dev->states_usage[index];
- struct davinci_ops *ops = cpuidle_get_statedata(state_usage);
-
- if (ops && ops->enter)
- ops->enter(ops->flags);
+ if (index)
+ davinci_save_ddr_power(1, ddr2_pwdn);
index = cpuidle_wrap_enter(dev, drv, index,
arm_cpuidle_simple_enter);
- if (ops && ops->exit)
- ops->exit(ops->flags);
+ if (index)
+ davinci_save_ddr_power(0, ddr2_pwdn);
return index;
}
-/* fields in davinci_ops.flags */
-#define DAVINCI_CPUIDLE_FLAGS_DDR2_PWDN BIT(0)
-
static struct cpuidle_driver davinci_idle_driver = {
.name = "cpuidle-davinci",
.owner = THIS_MODULE,
@@ -71,43 +82,6 @@ static struct cpuidle_driver davinci_idle_driver = {
};
static DEFINE_PER_CPU(struct cpuidle_device, davinci_cpuidle_device);
-static void __iomem *ddr2_reg_base;
-
-static void davinci_save_ddr_power(int enter, bool pdown)
-{
- u32 val;
-
- val = __raw_readl(ddr2_reg_base + DDR2_SDRCR_OFFSET);
-
- if (enter) {
- if (pdown)
- val |= DDR2_SRPD_BIT;
- else
- val &= ~DDR2_SRPD_BIT;
- val |= DDR2_LPMODEN_BIT;
- } else {
- val &= ~(DDR2_SRPD_BIT | DDR2_LPMODEN_BIT);
- }
-
- __raw_writel(val, ddr2_reg_base + DDR2_SDRCR_OFFSET);
-}
-
-static void davinci_c2state_enter(u32 flags)
-{
- davinci_save_ddr_power(1, !!(flags & DAVINCI_CPUIDLE_FLAGS_DDR2_PWDN));
-}
-
-static void davinci_c2state_exit(u32 flags)
-{
- davinci_save_ddr_power(0, !!(flags & DAVINCI_CPUIDLE_FLAGS_DDR2_PWDN));
-}
-
-static struct davinci_ops davinci_states[DAVINCI_CPUIDLE_MAX_STATES] = {
- [1] = {
- .enter = davinci_c2state_enter,
- .exit = davinci_c2state_exit,
- },
-};
static int __init davinci_cpuidle_probe(struct platform_device *pdev)
{
@@ -125,8 +99,7 @@ static int __init davinci_cpuidle_probe(struct platform_device *pdev)
ddr2_reg_base = pdata->ddr2_ctlr_base;
if (pdata->ddr2_pdown)
- davinci_states[1].flags |= DAVINCI_CPUIDLE_FLAGS_DDR2_PWDN;
- cpuidle_set_statedata(&device->states_usage[1], &davinci_states[1]);
+ ddr2_pwdn = true;
ret = cpuidle_register_driver(&davinci_idle_driver);
if (ret) {
--
1.7.5.4
^ permalink raw reply related
* Re: [PATCH 2/2] ARM: DAVINCI: cpuidle - remove ops
From: Daniel Lezcano @ 2012-05-20 10:37 UTC (permalink / raw)
To: Sekhar Nori
Cc: khilman, davinci-linux-open-source, linaro-dev, patches, linux-pm
In-Reply-To: <4FB8C53C.1020301@ti.com>
On 05/20/2012 12:19 PM, Sekhar Nori wrote:
> Hi Daniel,
>
> On 5/10/2012 2:14 PM, Daniel Lezcano wrote:
>> This patch removes the ops usage because we have the index
>> passed as parameter to the idle function and we can determine
>> if we do WFI or memory retention.
>>
>> The benefit of this cleanup is the removal of:
>> * the ops
>> * the statedata usage because we want to get rid of it in all the drivers
>> * extra structure definition
>> * extra functions definition
>> * pointless macro definition BIT(0)
>
> This macro was not pointless in the original code. This comment seems to
> suggest so.
>
>>
>> It also benefits the readability.
>>
>> Signed-off-by: Daniel Lezcano<daniel.lezcano@linaro.org>
>> ---
>> arch/arm/mach-davinci/cpuidle.c | 81 +++++++++++++--------------------------
>> 1 files changed, 27 insertions(+), 54 deletions(-)
>>
>> diff --git a/arch/arm/mach-davinci/cpuidle.c b/arch/arm/mach-davinci/cpuidle.c
>> index f0f179c..61f4e52 100644
>> --- a/arch/arm/mach-davinci/cpuidle.c
>> +++ b/arch/arm/mach-davinci/cpuidle.c
>> @@ -25,35 +25,46 @@
>>
>> #define DAVINCI_CPUIDLE_MAX_STATES 2
>>
>> -struct davinci_ops {
>> - void (*enter) (u32 flags);
>> - void (*exit) (u32 flags);
>> - u32 flags;
>> -};
>> +static bool ddr2_pwdn = false;
>
> This zero initialization is not required. In fact this throws a
> checkpatch error.
>
>> +
>> +static void __iomem *ddr2_reg_base;
>> +
>> +static void davinci_save_ddr_power(int enter, bool pdown)
>> +{
>> + u32 val;
>> +
>> + val = __raw_readl(ddr2_reg_base + DDR2_SDRCR_OFFSET);
>> +
>> + if (enter) {
>> + if (pdown)
>> + val |= DDR2_SRPD_BIT;
>> + else
>> + val&= ~DDR2_SRPD_BIT;
>> + val |= DDR2_LPMODEN_BIT;
>> + } else {
>> + val&= ~(DDR2_SRPD_BIT | DDR2_LPMODEN_BIT);
>> + }
>> +
>> + __raw_writel(val, ddr2_reg_base + DDR2_SDRCR_OFFSET);
>
> Can you please use readl/writel instead of the __raw variants. I know
> this is carried from original code, but we need to git rid of it with
> cleanups like this.
Sure, I will resend a version without the initialization and the
_raw_write variant.
Thanks
-- Daniel
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
_______________________________________________
linux-pm mailing list
linux-pm@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/linux-pm
^ permalink raw reply
* Re: [PATCH 2/2] ARM: DAVINCI: cpuidle - remove ops
From: Sekhar Nori @ 2012-05-20 10:19 UTC (permalink / raw)
To: Daniel Lezcano
Cc: khilman-l0cyMroinI0,
davinci-linux-open-source-VycZQUHpC/PFrsHnngEfi1aTQe2KTcn/,
linaro-dev-cunTk1MwBs8s++Sfvej+rw, patches-QSEj5FYQhm4dnm+yROfE0A,
linux-pm-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
lenb-DgEjT+Ai2ygdnm+yROfE0A
In-Reply-To: <1336639485-26955-3-git-send-email-daniel.lezcano-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Hi Daniel,
On 5/10/2012 2:14 PM, Daniel Lezcano wrote:
> This patch removes the ops usage because we have the index
> passed as parameter to the idle function and we can determine
> if we do WFI or memory retention.
>
> The benefit of this cleanup is the removal of:
> * the ops
> * the statedata usage because we want to get rid of it in all the drivers
> * extra structure definition
> * extra functions definition
> * pointless macro definition BIT(0)
This macro was not pointless in the original code. This comment seems to
suggest so.
>
> It also benefits the readability.
>
> Signed-off-by: Daniel Lezcano <daniel.lezcano-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> ---
> arch/arm/mach-davinci/cpuidle.c | 81 +++++++++++++--------------------------
> 1 files changed, 27 insertions(+), 54 deletions(-)
>
> diff --git a/arch/arm/mach-davinci/cpuidle.c b/arch/arm/mach-davinci/cpuidle.c
> index f0f179c..61f4e52 100644
> --- a/arch/arm/mach-davinci/cpuidle.c
> +++ b/arch/arm/mach-davinci/cpuidle.c
> @@ -25,35 +25,46 @@
>
> #define DAVINCI_CPUIDLE_MAX_STATES 2
>
> -struct davinci_ops {
> - void (*enter) (u32 flags);
> - void (*exit) (u32 flags);
> - u32 flags;
> -};
> +static bool ddr2_pwdn = false;
This zero initialization is not required. In fact this throws a
checkpatch error.
> +
> +static void __iomem *ddr2_reg_base;
> +
> +static void davinci_save_ddr_power(int enter, bool pdown)
> +{
> + u32 val;
> +
> + val = __raw_readl(ddr2_reg_base + DDR2_SDRCR_OFFSET);
> +
> + if (enter) {
> + if (pdown)
> + val |= DDR2_SRPD_BIT;
> + else
> + val &= ~DDR2_SRPD_BIT;
> + val |= DDR2_LPMODEN_BIT;
> + } else {
> + val &= ~(DDR2_SRPD_BIT | DDR2_LPMODEN_BIT);
> + }
> +
> + __raw_writel(val, ddr2_reg_base + DDR2_SDRCR_OFFSET);
Can you please use readl/writel instead of the __raw variants. I know
this is carried from original code, but we need to git rid of it with
cleanups like this.
Thanks,
Sekhar
^ permalink raw reply
* Re: [PATCH 1/2] ARM: DAVINCI: cpuidle - remove useless state count initialization
From: Sekhar Nori @ 2012-05-20 9:24 UTC (permalink / raw)
To: Daniel Lezcano
Cc: khilman-l0cyMroinI0,
davinci-linux-open-source-VycZQUHpC/PFrsHnngEfi1aTQe2KTcn/,
linaro-dev-cunTk1MwBs8s++Sfvej+rw, patches-QSEj5FYQhm4dnm+yROfE0A,
linux-pm-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
lenb-DgEjT+Ai2ygdnm+yROfE0A
In-Reply-To: <1336639485-26955-2-git-send-email-daniel.lezcano-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Hi Daniel,
On 5/10/2012 2:14 PM, Daniel Lezcano wrote:
> The state count is initialized in the driver structure, the cpuidle
> core uses it to initialize the device state count.
>
> Signed-off-by: Daniel Lezcano <daniel.lezcano-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Looks good to me. Will queue for v3.6
Nit: In future, please use davinci in small case in subject line to keep
it consistent with other DaVinci patches.
Thanks,
Sekhar
^ permalink raw reply
* Re: [PATCH 0/2] ARM: DAVINCI: cpuidle - cleanups
From: Daniel Lezcano @ 2012-05-19 9:26 UTC (permalink / raw)
To: nsekhar, khilman; +Cc: davinci-linux-open-source, patches, linaro-dev, linux-pm
In-Reply-To: <1336639485-26955-1-git-send-email-daniel.lezcano@linaro.org>
On 05/10/2012 10:44 AM, Daniel Lezcano wrote:
> These couple of patches use the new cpuidle core api to refactor
> some part of the code. The first one removes the state count initialization
> as it is done from the cpuidle core and the second one use the new
> API and removes the ops.
>
> The patchset is based on Lenb's tree on top of Robert Lee cpuidle consolidation
> work.
>
> I don't have this board, I was not able to test these patches.
>
> Daniel Lezcano (2):
> ARM: DAVINCI: cpuidle - remove useless state count initialization
> ARM: DAVINCI: cpuidle - remove ops
>
> arch/arm/mach-davinci/cpuidle.c | 83 +++++++++++++--------------------------
> 1 files changed, 27 insertions(+), 56 deletions(-)
>
Hi,
maybe these patches did not raise attention.
Do you think they sound good ?
Thanks
-- Daniel
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro:<http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
_______________________________________________
linux-pm mailing list
linux-pm@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/linux-pm
^ permalink raw reply
* Re: [PATCHv3 0/4] coupled cpuidle state support
From: Shilimkar, Santosh @ 2012-05-19 7:04 UTC (permalink / raw)
To: Colin Cross
Cc: Kevin Hilman, Len Brown, Russell King, Greg Kroah-Hartman,
Kay Sievers, linux-kernel, Amit Kucheria, linux-pm,
Arjan van de Ven, Arnd Bergmann, linux-arm-kernel
In-Reply-To: <CAMbhsRTvhP5+ow8koUsS8zbvJwyE_JMGHGasYvP58HudG8wJMA@mail.gmail.com>
On Sat, May 19, 2012 at 1:48 AM, Colin Cross <ccross@android.com> wrote:
> On Fri, May 18, 2012 at 12:03 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
>> On Friday, May 18, 2012, Santosh Shilimkar wrote:
>>> On Tuesday 08 May 2012 06:27 AM, Colin Cross wrote:
>>> > On some ARM SMP SoCs (OMAP4460, Tegra 2, and probably more), the
>>> > cpus cannot be independently powered down, either due to
>>> > sequencing restrictions (on Tegra 2, cpu 0 must be the last to
>>> > power down), or due to HW bugs (on OMAP4460, a cpu powering up
>>> > will corrupt the gic state unless the other cpu runs a work
>>> > around). Each cpu has a power state that it can enter without
>>> > coordinating with the other cpu (usually Wait For Interrupt, or
>>> > WFI), and one or more "coupled" power states that affect blocks
>>> > shared between the cpus (L2 cache, interrupt controller, and
>>> > sometimes the whole SoC). Entering a coupled power state must
>>> > be tightly controlled on both cpus.
>>> >
>>>
>>> [...]
>>>
>>> > This series has been tested and reviewed by Santosh and Kevin
>>> > for OMAP4, which has a cpuidle series ready for 3.5, and Tegra
>>> > and Exynos5 patches are in progress. I think this is ready to
>>> > go in. Lean, are you maintaining a cpuidle tree for linux-next?
>>> > If not, I can publish a tree for linux-next, or this could go in
>>> > through Arnd's tree.
>>>
>>> I haven't seen any response so far on who is lining up this
>>> series for 3.5 ? Not sure if it made it to linux-next either.
>>
>> That should be Len, but he's been silent recently.
>>
>> How urgent is it?
>
> Len silently picked up the last version. I just posted two fixes to
> it, hopefully he'll pick up those too.
Great !!
I will pull Len's tree and rebase OMAP patches against it.
Regards
Santosh
^ permalink raw reply
* Re: [PATCHv3 0/4] coupled cpuidle state support
From: Colin Cross @ 2012-05-18 20:18 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Kevin Hilman, Len Brown, Russell King, Greg Kroah-Hartman,
Kay Sievers, linux-kernel, Amit Kucheria, linux-pm,
Arjan van de Ven, Arnd Bergmann, linux-arm-kernel
In-Reply-To: <201205182103.56301.rjw@sisk.pl>
On Fri, May 18, 2012 at 12:03 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> On Friday, May 18, 2012, Santosh Shilimkar wrote:
>> On Tuesday 08 May 2012 06:27 AM, Colin Cross wrote:
>> > On some ARM SMP SoCs (OMAP4460, Tegra 2, and probably more), the
>> > cpus cannot be independently powered down, either due to
>> > sequencing restrictions (on Tegra 2, cpu 0 must be the last to
>> > power down), or due to HW bugs (on OMAP4460, a cpu powering up
>> > will corrupt the gic state unless the other cpu runs a work
>> > around). Each cpu has a power state that it can enter without
>> > coordinating with the other cpu (usually Wait For Interrupt, or
>> > WFI), and one or more "coupled" power states that affect blocks
>> > shared between the cpus (L2 cache, interrupt controller, and
>> > sometimes the whole SoC). Entering a coupled power state must
>> > be tightly controlled on both cpus.
>> >
>>
>> [...]
>>
>> > This series has been tested and reviewed by Santosh and Kevin
>> > for OMAP4, which has a cpuidle series ready for 3.5, and Tegra
>> > and Exynos5 patches are in progress. I think this is ready to
>> > go in. Lean, are you maintaining a cpuidle tree for linux-next?
>> > If not, I can publish a tree for linux-next, or this could go in
>> > through Arnd's tree.
>>
>> I haven't seen any response so far on who is lining up this
>> series for 3.5 ? Not sure if it made it to linux-next either.
>
> That should be Len, but he's been silent recently.
>
> How urgent is it?
Len silently picked up the last version. I just posted two fixes to
it, hopefully he'll pick up those too.
^ permalink raw reply
* Re: [PATCHv3 0/4] coupled cpuidle state support
From: Rafael J. Wysocki @ 2012-05-18 19:03 UTC (permalink / raw)
To: Santosh Shilimkar
Cc: Kevin Hilman, Len Brown, Russell King, Greg Kroah-Hartman,
Kay Sievers, linux-kernel, Amit Kucheria, Colin Cross, linux-pm,
Arjan van de Ven, Arnd Bergmann, linux-arm-kernel
In-Reply-To: <4FB62611.7080908@ti.com>
On Friday, May 18, 2012, Santosh Shilimkar wrote:
> On Tuesday 08 May 2012 06:27 AM, Colin Cross wrote:
> > On some ARM SMP SoCs (OMAP4460, Tegra 2, and probably more), the
> > cpus cannot be independently powered down, either due to
> > sequencing restrictions (on Tegra 2, cpu 0 must be the last to
> > power down), or due to HW bugs (on OMAP4460, a cpu powering up
> > will corrupt the gic state unless the other cpu runs a work
> > around). Each cpu has a power state that it can enter without
> > coordinating with the other cpu (usually Wait For Interrupt, or
> > WFI), and one or more "coupled" power states that affect blocks
> > shared between the cpus (L2 cache, interrupt controller, and
> > sometimes the whole SoC). Entering a coupled power state must
> > be tightly controlled on both cpus.
> >
>
> [...]
>
> > This series has been tested and reviewed by Santosh and Kevin
> > for OMAP4, which has a cpuidle series ready for 3.5, and Tegra
> > and Exynos5 patches are in progress. I think this is ready to
> > go in. Lean, are you maintaining a cpuidle tree for linux-next?
> > If not, I can publish a tree for linux-next, or this could go in
> > through Arnd's tree.
>
> I haven't seen any response so far on who is lining up this
> series for 3.5 ? Not sure if it made it to linux-next either.
That should be Len, but he's been silent recently.
How urgent is it?
Rafael
^ permalink raw reply
* [PATCH 2/2] cpuidle: coupled: fix decrementing ready count
From: Colin Cross @ 2012-05-18 18:05 UTC (permalink / raw)
To: Len Brown
Cc: Kevin Hilman, linux-kernel, Amit Kucheria, Colin Cross, linux-pm,
Arjan van de Ven, linux-arm-kernel
In-Reply-To: <1337364324-12171-1-git-send-email-ccross@android.com>
cpuidle_coupled_set_not_ready sometimes refuses to decrement the
ready count in order to prevent a race condition. This makes it
unsuitable for use when finished with idle. Add a new function
cpuidle_coupled_set_done that decrements both the ready count and
waiting count, and call it after idle is complete.
Signed-off-by: Colin Cross <ccross@android.com>
---
drivers/cpuidle/coupled.c | 18 ++++++++++++++++--
1 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/drivers/cpuidle/coupled.c b/drivers/cpuidle/coupled.c
index b02810a..fc427fa 100644
--- a/drivers/cpuidle/coupled.c
+++ b/drivers/cpuidle/coupled.c
@@ -388,6 +388,21 @@ static void cpuidle_coupled_set_not_waiting(int cpu,
}
/**
+ * cpuidle_coupled_set_done - mark this cpu as leaving the ready loop
+ * @cpu: the current cpu
+ * @coupled: the struct coupled that contains the current cpu
+ *
+ * Marks this cpu as no longer in the ready and waiting loops. Decrements
+ * the waiting count first to prevent another cpu looping back in and seeing
+ * this cpu as waiting just before it exits idle.
+ */
+static void cpuidle_coupled_set_done(int cpu, struct cpuidle_coupled *coupled)
+{
+ cpuidle_coupled_set_not_waiting(cpu, coupled);
+ atomic_sub(MAX_WAITING_CPUS, &coupled->ready_waiting_counts);
+}
+
+/**
* cpuidle_coupled_clear_pokes - spin until the poke interrupt is processed
* @cpu - this cpu
*
@@ -501,8 +516,7 @@ int cpuidle_enter_state_coupled(struct cpuidle_device *dev,
entered_state = cpuidle_enter_state(dev, drv, next_state);
- cpuidle_coupled_set_not_waiting(dev->cpu, coupled);
- cpuidle_coupled_set_not_ready(coupled);
+ cpuidle_coupled_set_done(dev->cpu, coupled);
out:
/*
--
1.7.7.3
^ permalink raw reply related
* [PATCH 1/2] cpuidle: coupled: fix count of online cpus
From: Colin Cross @ 2012-05-18 18:05 UTC (permalink / raw)
To: Len Brown
Cc: Kevin Hilman, linux-kernel, Amit Kucheria, Colin Cross, linux-pm,
Arjan van de Ven, linux-arm-kernel
In-Reply-To: <1337364324-12171-1-git-send-email-ccross@android.com>
online_count was never incremented on boot, and was also counting
cpus that were not part of the coupled set. Fix both issues by
introducting a new function that counts online coupled cpus, and
call it from register as well as the hotplug notifier.
Signed-off-by: Colin Cross <ccross@android.com>
---
drivers/cpuidle/coupled.c | 11 ++++++++++-
1 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/drivers/cpuidle/coupled.c b/drivers/cpuidle/coupled.c
index 3e65de1..b02810a 100644
--- a/drivers/cpuidle/coupled.c
+++ b/drivers/cpuidle/coupled.c
@@ -532,6 +532,13 @@ int cpuidle_enter_state_coupled(struct cpuidle_device *dev,
return entered_state;
}
+static void cpuidle_coupled_update_online_cpus(struct cpuidle_coupled *coupled)
+{
+ cpumask_t cpus;
+ cpumask_and(&cpus, cpu_online_mask, &coupled->coupled_cpus);
+ coupled->online_count = cpumask_weight(&cpus);
+}
+
/**
* cpuidle_coupled_register_device - register a coupled cpuidle device
* @dev: struct cpuidle_device for the current cpu
@@ -570,6 +577,8 @@ int cpuidle_coupled_register_device(struct cpuidle_device *dev)
if (WARN_ON(!cpumask_equal(&dev->coupled_cpus, &coupled->coupled_cpus)))
coupled->prevent++;
+ cpuidle_coupled_update_online_cpus(coupled);
+
coupled->refcnt++;
csd = &per_cpu(cpuidle_coupled_poke_cb, dev->cpu);
@@ -668,7 +677,7 @@ static int cpuidle_coupled_cpu_notify(struct notifier_block *nb,
break;
case CPU_ONLINE:
case CPU_DEAD:
- dev->coupled->online_count = num_online_cpus();
+ cpuidle_coupled_update_online_cpus(dev->coupled);
/* Fall through */
case CPU_UP_CANCELED:
case CPU_DOWN_FAILED:
--
1.7.7.3
^ permalink raw reply related
* [PATCH 0/2] bug fixes for coupled cpuidle
From: Colin Cross @ 2012-05-18 18:05 UTC (permalink / raw)
To: Len Brown
Cc: Kevin Hilman, linux-kernel, Amit Kucheria, Colin Cross, linux-pm,
Arjan van de Ven, linux-arm-kernel
The last modifications made to the coupled cpuidle patches introduced
two bugs that I missed during testing. The online count was never
initialized, causing coupled idle to always wait and never enter the
ready loop. That hid the second bug, the ready count could never be
decremented after exiting idle.
Len, these two patches could be squashed into patch 3 of the original
set. If you do squash them, you could also add Rafael's tags to the
set (Reviewed-by on 1 and 2, acked-by on 3). Or I can reupload the
whole stack as v5 if you prefer.
^ permalink raw reply
* Re: [PATCHv3 0/4] coupled cpuidle state support
From: Santosh Shilimkar @ 2012-05-18 10:36 UTC (permalink / raw)
To: Colin Cross
Cc: Kevin Hilman, Len Brown, Russell King, Greg Kroah-Hartman,
Kay Sievers, linux-kernel, Amit Kucheria, linux-pm,
Arjan van de Ven, Arnd Bergmann, linux-arm-kernel
In-Reply-To: <1336438662-10484-1-git-send-email-ccross@android.com>
On Tuesday 08 May 2012 06:27 AM, Colin Cross wrote:
> On some ARM SMP SoCs (OMAP4460, Tegra 2, and probably more), the
> cpus cannot be independently powered down, either due to
> sequencing restrictions (on Tegra 2, cpu 0 must be the last to
> power down), or due to HW bugs (on OMAP4460, a cpu powering up
> will corrupt the gic state unless the other cpu runs a work
> around). Each cpu has a power state that it can enter without
> coordinating with the other cpu (usually Wait For Interrupt, or
> WFI), and one or more "coupled" power states that affect blocks
> shared between the cpus (L2 cache, interrupt controller, and
> sometimes the whole SoC). Entering a coupled power state must
> be tightly controlled on both cpus.
>
[...]
> This series has been tested and reviewed by Santosh and Kevin
> for OMAP4, which has a cpuidle series ready for 3.5, and Tegra
> and Exynos5 patches are in progress. I think this is ready to
> go in. Lean, are you maintaining a cpuidle tree for linux-next?
> If not, I can publish a tree for linux-next, or this could go in
> through Arnd's tree.
I haven't seen any response so far on who is lining up this
series for 3.5 ? Not sure if it made it to linux-next either.
Regards
santosh
^ permalink raw reply
* Re: Plumbers: PM constraints micro-conf RFP
From: Sundar @ 2012-05-17 11:30 UTC (permalink / raw)
To: markgross
Cc: Kevin Hilman, Agarwal, Ramesh, paulmck, pdeschrijver,
Praveen Chidambaram, Amit Kucheria, John Stultz, linux-pm,
amiettinen
In-Reply-To: <CAMHCuPX_=Vi6mQ0XdyNvca-dq+r8bFok=SQoZkK17GvOrERR+w@mail.gmail.com>
:(
I received this:
Your message (attached below) was not delivered to:
paulmck@vnet.ibm.com
because:
Bad destination mailbox address
Final-recipient: rfc822;paulmck@vnet.ibm.com
Action: failed
Status: 5.1.1
Diagnostic-code: X-Xagent; Bad destination mailbox address
On Thu, May 17, 2012 at 4:47 PM, Sundar <sunder.svit@gmail.com> wrote:
> I put in a rough draft @
> https://blueprints.launchpad.net/lpc/+spec/lpc2012-power-management-constraints
>
> Cheers!
--
---------
The views expressed in this email are personal and do not necessarily
echo my employers.
^ permalink raw reply
* Re: Plumbers: PM constraints micro-conf RFP
From: Sundar @ 2012-05-17 11:17 UTC (permalink / raw)
To: markgross
Cc: Kevin Hilman, Agarwal, Ramesh, paulmck, pdeschrijver,
Praveen Chidambaram, Amit Kucheria, John Stultz, linux-pm,
amiettinen
In-Reply-To: <20120516001335.GB4260@G62>
I put in a rough draft @
https://blueprints.launchpad.net/lpc/+spec/lpc2012-power-management-constraints
Cheers!
On Wed, May 16, 2012 at 5:43 AM, mark gross <markgross@thegnar.org> wrote:
> On Tue, May 15, 2012 at 03:58:59PM +0300, Amit Kucheria wrote:
>> On Tue, May 15, 2012 at 12:40 PM, Jean Pihet <jean.pihet@newoldbits.com> wrote:
>> > Hi!
>> >
>> > Here is my proposal for the PM constraints micro-conf RFP, as e-mailed today:
>> >
>> > Session title: A New Model for the System and Devices Latency
>> >
>> > Name of microconference (if applicable): PM constraints micro-conf,
>> > led by Mark Gross
>> >
>> > Abstract:
>> > Due to the nature of the new SoC architectures the Power Management
>> > needs a new model for the various system latencies. The talk presents:
>> > . the concepts of system, devices, wake-up and resume latencies,
>> > . the recent changes in the devices framework for the latency, why
>> > and how to make it generic,
>> > . the link with the other PM QoS frameworks: thermal, cpuidle,
>>
>> Jean,
>>
>> Do you already consider GPU drivers, backlight drivers and battery
>> charging for setting constraints (performance and thermal) ?
>>
>> Between your, Eduardo's and Antti's proposals, a lot of ground is
>> being covered and I don't want to make a new proposal just for these
>> three. But we're keen on helping consolidate on generic interfaces to
>> deal with these three kinds of devices.
>
> It will be great to have you there in any case.
>
> It feels like we have enough content to come up with portable
> requirements and maybe an ok design that can work for multiple SoC's.
>
> --mark
>
>> > . the recent changes in the ARM/OMAP platform code for the system latency,
>> > . the problems encountered while modelling and measuring the
>> > various latencies,
>> >
>> > . a proposal on the model and on the way to implement it,
>> > . the planned changes in the device framework, the platform code
>> > and the APIs.
>> >
>> > This talk is oriented towards Linux power management developers. The
>> > goal is to agree on a framework implementation and the interfaces
>> > within the kernel and with the user space.
>> >
>> > Experience:
>> > Jean Pihet, NewOldBits.com
>> >
>> > Jean Pihet is working with embedded Linux since many years now, for
>> > companies like Texas Instruments, MontaVista, Motorola and Philips.
>> > Recently NewOldBits.com has been founded to provide high quality
>> > consulting services. The area of work is mainly OMAP Power Management,
>> > tracing and profiling tools (perf, ftrace, oprofile...) for recent ARM
>> > cores.
>> >
>> > Kind regards,
>> > Jean
>> >
>> > On Tue, May 15, 2012 at 7:34 AM, Valentin, Eduardo
>> > <eduardo.valentin@ti.com> wrote:
>> >> FYI,
>> >>
>> >> I will submit later today, something like this:
>> >> "
>> >> Abstract
>> >>
>> >> The thermal challenge is to design an end-product with high
>> >> performance while keeping the junction temperature of the IC
>> >> components used on this product within their limitations and which
>> >> does not present a thermal discomfort for the user. OMAP4/OMAP5 System
>> >> on Chips, operating at highest Operating Performance Points (OPP), is
>> >> a powerful mobile applications processor. However operating at higher
>> >> voltage and higher frequency in a sustained manner may cause thermal
>> >> limits to be exceeded, both for silicon and user comfort. We propose a
>> >> new framework to model per device power constraints, for containment
>> >> of thermal limitations across major heat sources of a end-product
>> >> device, e.g. LCD, CPU, charging, etc. The framework shall facilitate
>> >> the power and thermal management performed by governor and policies,
>> >> depending on device context and use case knowledge.
>> >>
>> >> Authors
>> >>
>> >> Eduardo Valentin, System Software Engineer at Texas Instruments,
>> >> working on OMAP Linux kernel, previously a working on power management
>> >> in maemo for Nokia.
>> >>
>> >>
>> >> On Tue, May 15, 2012 at 8:06 AM, Valentin, Eduardo
>> >> <eduardo.valentin@ti.com> wrote:
>> >>> Benoit,
>> >>>
>> >>> On Mon, May 14, 2012 at 8:11 PM, Cousson, Benoit <b-cousson@ti.com> wrote:
>> >>>> Hi Jean,
>> >>>>
>> >>>>
>> >>>> On 5/14/2012 2:45 PM, Jean Pihet wrote:
>> >>>>>
>> >>>>> Hi Benoit,
>> >>>>>
>> >>>>> On Fri, May 11, 2012 at 9:17 AM, Valentin, Eduardo
>> >>>>> <eduardo.valentin@ti.com> wrote:
>> >>>>>>
>> >>>>>> Hello Mark,
>> >>>>>>
>> >>>>>> On Wed, May 2, 2012 at 5:36 PM, mark gross<markgross@thegnar.org> wrote:
>> >>>>>>>
>> >>>>>>> This is a Request For Participation in a micro-conference at this years
>> >>>>>>> Linux plumbers event. For this micro conference to happen we need to
>> >>>>>>> reach a certain critical mass WRT participants as measured by submitted
>> >>>>>>> talks associated to Power Management Constraints.
>> >>>>>>
>> >>>>>>
>> >>>>>> Nice! Thanks for proposing this.
>> >>>>>>
>> >>>>>>>
>> >>>>>>> The To: list is populated with folks that I've had interactions with
>> >>>>>>> over extending pm-qos or constraint based PM over the past year.
>> >>>>>>>
>> >>>>>>> If you are working on problems related to constraining the power /
>> >>>>>>> performance of devices I am inviting your participation and request you
>> >>>>>>> submit a proposal for presenting your problem space (preferred) and or
>> >>>>>>> solution to a group of developers looking for a good solution to push
>> >>>>>>> upstream. The talks will be about 20 min long as I want to get into
>> >>>>>>> some design and implementation discussions after the requirements
>> >>>>>>> definition is mostly finished.
>> >>>>>
>> >>>>> Is it OK to submit a talk for the next LPC? The deadline is tomorrow IIRC.
>> >>>>
>> >>>>
>> >>>> Yes, it is. Go ahead. It is related to Mark's proposal? Because it seems we
>> >>>> have to do some homework in order to participate to the micro-conf :-(.
>> >>>
>> >>> Yes, the homework is required in order to drive the discussion based
>> >>> on existing usable solutions..
>> >>>
>> >>> Jean, I'll write down a proposal today, from thermal requirements
>> >>> perspective. But we can discuss also a way to converge either in a
>> >>> common presentation or in even with two presentations but with strong
>> >>> linking together.
>> >>>
>> >>> Just trying to avoid two conflicting proposals from two peers @ti.com
>> >>>
>> >>>>
>> >>>> Regards,
>> >>>> Benoit
>> >>>>
>> >>>>
>> >>>>>
>> >>>>> Regards,
>> >>>>> Jean
>> >>>>>
>> >>>>>>>
>> >>>>>>> I am interested in gathering user mode interface needs as well as kernel
>> >>>>>>> mode.
>> >>>>>>>
>> >>>>>>> From a high level pm-constraints is a generalization of pm-qos to
>> >>>>>>> include
>> >>>>>>> limiting performance as well as its current limiting of device
>> >>>>>>> throttling.
>> >>>>>>>
>> >>>>>>> As performance limiting is typically used for any of the following:
>> >>>>>>> 1) staying within thermal operational envelopes
>> >>>>>>> 2) avoiding peak current
>> >>>>>>> 3) extending battery life in active use cases
>> >>>>>>>
>> >>>>>>> I invite anyone working in any of these areas or pm-qos applications to
>> >>>>>>> participate in this micro-conference.
>> >>>>>>>
>> >>>>>>> I will organize the micro-conference into 2 parts:
>> >>>>>>> 1) problem statements with specific participant examples where
>> >>>>>>> constraining the performance or throttling is needed.
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>> I could bring something on the use cases where this type of
>> >>>>>> constraining could be used. Essentially major focus gets partitioned
>> >>>>>> in two areas: For device skin/case temperature management, and IC's
>> >>>>>> junction temperature management.
>> >>>>>>
>> >>>>>> I am currently checking the traveling arrangements as well. And
>> >>>>>> confirming soon.
>> >>>>>>
>> >>>>>>
>> >>>>>>>
>> >>>>>>> 2) high level design brain storming.
>> >>>>>>>
>> >>>>>>> If the micro-conference happens (i.e. critical mass is reached) any
>> >>>>>>> interested linux-plumbers attendees is very welcome to participate.
>> >>>>>>>
>> >>>>>>> Please send me an off list email if you want me to add you to my mutt
>> >>>>>>> alias of interested parties I'll use to cc people on emails. Note: must
>> >>>>>>> of the correspondence will cc linux-pm too.
>> >>>>>>>
>> >>>>>>> Please submit a proposal if you are interested in participating in this
>> >>>>>>> with me. I know a number of people are working in this space for the
>> >>>>>>> past few years now. I think its a good time to compare notes and at
>> >>>>>>> least consolidate requirements and use cases. Perhaps we'll even come
>> >>>>>>> up
>> >>>>>>> with a good design to implement in the process.
>> >>>>>>>
>> >>>>>>> thanks,
>> >>>>>>> --mark
>> >>>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>> All best,
>> >>>>>> --
>> >>>>>>
>> >>>>>> Eduardo Valentin
>> >>>>>> _______________________________________________
>> >>>>>> linux-pm mailing list
>> >>>>>> linux-pm@lists.linux-foundation.org
>> >>>>>> https://lists.linuxfoundation.org/mailman/listinfo/linux-pm
>> >>>>
>> >>>>
>> >>>
>> >>>
>> >>>
>> >>> --
>> >>>
>> >>> Eduardo Valentin
>> >>
>> >>
>> >>
>> >> --
>> >>
>> >> Eduardo Valentin
> _______________________________________________
> linux-pm mailing list
> linux-pm@lists.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/linux-pm
--
---------
The views expressed in this email are personal and do not necessarily
echo my employers.
^ permalink raw reply
* Re: Plumbers: PM constraints micro-conf RFP
From: Mansoor, Illyas @ 2012-05-16 9:45 UTC (permalink / raw)
To: markgross@thegnar.org, John Stultz,
jeen.pihet@G62.linuxfoundation.org, MyungJoo Ham, Amit Kucheria,
Agarwal, Ramesh, Praveen Chidambaram, Antti P Miettinen,
Valentin, Eduardo, Rafael J. Wysocki, Kevin Hilman
Cc: paulmck@vnet.ibm.com, linux-pm@lists.linux-foundation.org
In-Reply-To: <20120502143607.GA21640@G62>
[-- Attachment #1.1: Type: text/plain, Size: 3236 bytes --]
> -----Original Message-----
> From: linux-pm-bounces@lists.linux-foundation.org [mailto:linux-pm-
> bounces@lists.linux-foundation.org] On Behalf Of mark gross
> Sent: Wednesday, May 02, 2012 8:06 PM
> To: mark gross; John Stultz; jeen.pihet@G62.linuxfoundation.org; MyungJoo Ham;
> Amit Kucheria; Agarwal, Ramesh; Praveen Chidambaram; Antti P Miettinen;
Valentin,
> Eduardo; Rafael J. Wysocki; Kevin Hilman
> Cc: paulmck@vnet.ibm.com; linux-pm@lists.linux-foundation.org
> Subject: [linux-pm] Plumbers: PM constraints micro-conf RFP
>
> This is a Request For Participation in a micro-conference at this years Linux
plumbers
> event. For this micro conference to happen we need to reach a certain
critical mass
> WRT participants as measured by submitted talks associated to Power Management
> Constraints.
>
> The To: list is populated with folks that I've had interactions with over
extending pm-
> qos or constraint based PM over the past year.
>
> If you are working on problems related to constraining the power / performance
of
> devices I am inviting your participation and request you submit a proposal for
> presenting your problem space (preferred) and or solution to a group of
developers
> looking for a good solution to push upstream. The talks will be about 20 min
long as
> I want to get into some design and implementation discussions after the
> requirements definition is mostly finished.
>
> I am interested in gathering user mode interface needs as well as kernel mode.
>
> From a high level pm-constraints is a generalization of pm-qos to include
limiting
> performance as well as its current limiting of device throttling.
>
> As performance limiting is typically used for any of the following:
> 1) staying within thermal operational envelopes
> 2) avoiding peak current
> 3) extending battery life in active use cases
>
> I invite anyone working in any of these areas or pm-qos applications to
participate in
> this micro-conference.
>
> I will organize the micro-conference into 2 parts:
> 1) problem statements with specific participant examples where constraining
the
> performance or throttling is needed.
>
> 2) high level design brain storming.
>
> If the micro-conference happens (i.e. critical mass is reached) any interested
linux-
> plumbers attendees is very welcome to participate.
>
> Please send me an off list email if you want me to add you to my mutt alias of
> interested parties I'll use to cc people on emails. Note: must of the
correspondence
> will cc linux-pm too.
>
> Please submit a proposal if you are interested in participating in this with
me. I know
> a number of people are working in this space for the past few years now. I
think its a
> good time to compare notes and at least consolidate requirements and use
cases.
> Perhaps we'll even come up with a good design to implement in the process.
Mark,
Please find a draft proposal on priority based PM-QoS Parameters,
https://blueprints.launchpad.net/lpc/+spec/lpc-2012-priority-based-pmqos-paramet
ers
Thanks,
>
> thanks,
> --mark
>
> _______________________________________________
> linux-pm mailing list
> linux-pm@lists.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/linux-pm
[-- Attachment #1.2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 7212 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: Plumbers: PM constraints micro-conf RFP
From: mark gross @ 2012-05-16 0:13 UTC (permalink / raw)
To: Amit Kucheria
Cc: Kevin Hilman, Agarwal, Ramesh, markgross, paulmck, pdeschrijver,
Praveen Chidambaram, John Stultz, linux-pm, amiettinen
In-Reply-To: <CAP245DUhJ+Y9tKV=JNqdPHEvAe9fZ013ee9NKMkKQQcOs3M15A@mail.gmail.com>
On Tue, May 15, 2012 at 03:58:59PM +0300, Amit Kucheria wrote:
> On Tue, May 15, 2012 at 12:40 PM, Jean Pihet <jean.pihet@newoldbits.com> wrote:
> > Hi!
> >
> > Here is my proposal for the PM constraints micro-conf RFP, as e-mailed today:
> >
> > Session title: A New Model for the System and Devices Latency
> >
> > Name of microconference (if applicable): PM constraints micro-conf,
> > led by Mark Gross
> >
> > Abstract:
> > Due to the nature of the new SoC architectures the Power Management
> > needs a new model for the various system latencies. The talk presents:
> > . the concepts of system, devices, wake-up and resume latencies,
> > . the recent changes in the devices framework for the latency, why
> > and how to make it generic,
> > . the link with the other PM QoS frameworks: thermal, cpuidle,
>
> Jean,
>
> Do you already consider GPU drivers, backlight drivers and battery
> charging for setting constraints (performance and thermal) ?
>
> Between your, Eduardo's and Antti's proposals, a lot of ground is
> being covered and I don't want to make a new proposal just for these
> three. But we're keen on helping consolidate on generic interfaces to
> deal with these three kinds of devices.
It will be great to have you there in any case.
It feels like we have enough content to come up with portable
requirements and maybe an ok design that can work for multiple SoC's.
--mark
> > . the recent changes in the ARM/OMAP platform code for the system latency,
> > . the problems encountered while modelling and measuring the
> > various latencies,
> >
> > . a proposal on the model and on the way to implement it,
> > . the planned changes in the device framework, the platform code
> > and the APIs.
> >
> > This talk is oriented towards Linux power management developers. The
> > goal is to agree on a framework implementation and the interfaces
> > within the kernel and with the user space.
> >
> > Experience:
> > Jean Pihet, NewOldBits.com
> >
> > Jean Pihet is working with embedded Linux since many years now, for
> > companies like Texas Instruments, MontaVista, Motorola and Philips.
> > Recently NewOldBits.com has been founded to provide high quality
> > consulting services. The area of work is mainly OMAP Power Management,
> > tracing and profiling tools (perf, ftrace, oprofile...) for recent ARM
> > cores.
> >
> > Kind regards,
> > Jean
> >
> > On Tue, May 15, 2012 at 7:34 AM, Valentin, Eduardo
> > <eduardo.valentin@ti.com> wrote:
> >> FYI,
> >>
> >> I will submit later today, something like this:
> >> "
> >> Abstract
> >>
> >> The thermal challenge is to design an end-product with high
> >> performance while keeping the junction temperature of the IC
> >> components used on this product within their limitations and which
> >> does not present a thermal discomfort for the user. OMAP4/OMAP5 System
> >> on Chips, operating at highest Operating Performance Points (OPP), is
> >> a powerful mobile applications processor. However operating at higher
> >> voltage and higher frequency in a sustained manner may cause thermal
> >> limits to be exceeded, both for silicon and user comfort. We propose a
> >> new framework to model per device power constraints, for containment
> >> of thermal limitations across major heat sources of a end-product
> >> device, e.g. LCD, CPU, charging, etc. The framework shall facilitate
> >> the power and thermal management performed by governor and policies,
> >> depending on device context and use case knowledge.
> >>
> >> Authors
> >>
> >> Eduardo Valentin, System Software Engineer at Texas Instruments,
> >> working on OMAP Linux kernel, previously a working on power management
> >> in maemo for Nokia.
> >>
> >>
> >> On Tue, May 15, 2012 at 8:06 AM, Valentin, Eduardo
> >> <eduardo.valentin@ti.com> wrote:
> >>> Benoit,
> >>>
> >>> On Mon, May 14, 2012 at 8:11 PM, Cousson, Benoit <b-cousson@ti.com> wrote:
> >>>> Hi Jean,
> >>>>
> >>>>
> >>>> On 5/14/2012 2:45 PM, Jean Pihet wrote:
> >>>>>
> >>>>> Hi Benoit,
> >>>>>
> >>>>> On Fri, May 11, 2012 at 9:17 AM, Valentin, Eduardo
> >>>>> <eduardo.valentin@ti.com> wrote:
> >>>>>>
> >>>>>> Hello Mark,
> >>>>>>
> >>>>>> On Wed, May 2, 2012 at 5:36 PM, mark gross<markgross@thegnar.org> wrote:
> >>>>>>>
> >>>>>>> This is a Request For Participation in a micro-conference at this years
> >>>>>>> Linux plumbers event. For this micro conference to happen we need to
> >>>>>>> reach a certain critical mass WRT participants as measured by submitted
> >>>>>>> talks associated to Power Management Constraints.
> >>>>>>
> >>>>>>
> >>>>>> Nice! Thanks for proposing this.
> >>>>>>
> >>>>>>>
> >>>>>>> The To: list is populated with folks that I've had interactions with
> >>>>>>> over extending pm-qos or constraint based PM over the past year.
> >>>>>>>
> >>>>>>> If you are working on problems related to constraining the power /
> >>>>>>> performance of devices I am inviting your participation and request you
> >>>>>>> submit a proposal for presenting your problem space (preferred) and or
> >>>>>>> solution to a group of developers looking for a good solution to push
> >>>>>>> upstream. The talks will be about 20 min long as I want to get into
> >>>>>>> some design and implementation discussions after the requirements
> >>>>>>> definition is mostly finished.
> >>>>>
> >>>>> Is it OK to submit a talk for the next LPC? The deadline is tomorrow IIRC.
> >>>>
> >>>>
> >>>> Yes, it is. Go ahead. It is related to Mark's proposal? Because it seems we
> >>>> have to do some homework in order to participate to the micro-conf :-(.
> >>>
> >>> Yes, the homework is required in order to drive the discussion based
> >>> on existing usable solutions..
> >>>
> >>> Jean, I'll write down a proposal today, from thermal requirements
> >>> perspective. But we can discuss also a way to converge either in a
> >>> common presentation or in even with two presentations but with strong
> >>> linking together.
> >>>
> >>> Just trying to avoid two conflicting proposals from two peers @ti.com
> >>>
> >>>>
> >>>> Regards,
> >>>> Benoit
> >>>>
> >>>>
> >>>>>
> >>>>> Regards,
> >>>>> Jean
> >>>>>
> >>>>>>>
> >>>>>>> I am interested in gathering user mode interface needs as well as kernel
> >>>>>>> mode.
> >>>>>>>
> >>>>>>> From a high level pm-constraints is a generalization of pm-qos to
> >>>>>>> include
> >>>>>>> limiting performance as well as its current limiting of device
> >>>>>>> throttling.
> >>>>>>>
> >>>>>>> As performance limiting is typically used for any of the following:
> >>>>>>> 1) staying within thermal operational envelopes
> >>>>>>> 2) avoiding peak current
> >>>>>>> 3) extending battery life in active use cases
> >>>>>>>
> >>>>>>> I invite anyone working in any of these areas or pm-qos applications to
> >>>>>>> participate in this micro-conference.
> >>>>>>>
> >>>>>>> I will organize the micro-conference into 2 parts:
> >>>>>>> 1) problem statements with specific participant examples where
> >>>>>>> constraining the performance or throttling is needed.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> I could bring something on the use cases where this type of
> >>>>>> constraining could be used. Essentially major focus gets partitioned
> >>>>>> in two areas: For device skin/case temperature management, and IC's
> >>>>>> junction temperature management.
> >>>>>>
> >>>>>> I am currently checking the traveling arrangements as well. And
> >>>>>> confirming soon.
> >>>>>>
> >>>>>>
> >>>>>>>
> >>>>>>> 2) high level design brain storming.
> >>>>>>>
> >>>>>>> If the micro-conference happens (i.e. critical mass is reached) any
> >>>>>>> interested linux-plumbers attendees is very welcome to participate.
> >>>>>>>
> >>>>>>> Please send me an off list email if you want me to add you to my mutt
> >>>>>>> alias of interested parties I'll use to cc people on emails. Note: must
> >>>>>>> of the correspondence will cc linux-pm too.
> >>>>>>>
> >>>>>>> Please submit a proposal if you are interested in participating in this
> >>>>>>> with me. I know a number of people are working in this space for the
> >>>>>>> past few years now. I think its a good time to compare notes and at
> >>>>>>> least consolidate requirements and use cases. Perhaps we'll even come
> >>>>>>> up
> >>>>>>> with a good design to implement in the process.
> >>>>>>>
> >>>>>>> thanks,
> >>>>>>> --mark
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>> All best,
> >>>>>> --
> >>>>>>
> >>>>>> Eduardo Valentin
> >>>>>> _______________________________________________
> >>>>>> linux-pm mailing list
> >>>>>> linux-pm@lists.linux-foundation.org
> >>>>>> https://lists.linuxfoundation.org/mailman/listinfo/linux-pm
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >>> --
> >>>
> >>> Eduardo Valentin
> >>
> >>
> >>
> >> --
> >>
> >> Eduardo Valentin
^ permalink raw reply
* Re: Plumbers: PM constraints micro-conf RFP
From: mark gross @ 2012-05-16 0:09 UTC (permalink / raw)
To: Jean Pihet
Cc: Kevin Hilman, Agarwal, Ramesh, markgross, paulmck, pdeschrijver,
Praveen Chidambaram, Amit Kucheria, John Stultz, linux-pm
In-Reply-To: <CAORVsuV7PrJb4v-7G_JJJMy-fAAFdU-R-JWfwQoRzgtSg-m_KQ@mail.gmail.com>
On Tue, May 15, 2012 at 11:40:44AM +0200, Jean Pihet wrote:
> Hi!
>
> Here is my proposal for the PM constraints micro-conf RFP, as e-mailed today:
>
> Session title: A New Model for the System and Devices Latency
>
> Name of microconference (if applicable): PM constraints micro-conf,
> led by Mark Gross
>
> Abstract:
> Due to the nature of the new SoC architectures the Power Management
> needs a new model for the various system latencies. The talk presents:
> . the concepts of system, devices, wake-up and resume latencies,
> . the recent changes in the devices framework for the latency, why
> and how to make it generic,
> . the link with the other PM QoS frameworks: thermal, cpuidle,
> . the recent changes in the ARM/OMAP platform code for the system latency,
> . the problems encountered while modelling and measuring the
> various latencies,
> . a proposal on the model and on the way to implement it,
> . the planned changes in the device framework, the platform code
> and the APIs.
>
> This talk is oriented towards Linux power management developers. The
> goal is to agree on a framework implementation and the interfaces
> within the kernel and with the user space.
looks great to me! you should toss it up on the plumbers site.
--mark
> Experience:
> Jean Pihet, NewOldBits.com
>
> Jean Pihet is working with embedded Linux since many years now, for
> companies like Texas Instruments, MontaVista, Motorola and Philips.
> Recently NewOldBits.com has been founded to provide high quality
> consulting services. The area of work is mainly OMAP Power Management,
> tracing and profiling tools (perf, ftrace, oprofile...) for recent ARM
> cores.
>
> Kind regards,
> Jean
>
> On Tue, May 15, 2012 at 7:34 AM, Valentin, Eduardo
> <eduardo.valentin@ti.com> wrote:
> > FYI,
> >
> > I will submit later today, something like this:
> > "
> > Abstract
> >
> > The thermal challenge is to design an end-product with high
> > performance while keeping the junction temperature of the IC
> > components used on this product within their limitations and which
> > does not present a thermal discomfort for the user. OMAP4/OMAP5 System
> > on Chips, operating at highest Operating Performance Points (OPP), is
> > a powerful mobile applications processor. However operating at higher
> > voltage and higher frequency in a sustained manner may cause thermal
> > limits to be exceeded, both for silicon and user comfort. We propose a
> > new framework to model per device power constraints, for containment
> > of thermal limitations across major heat sources of a end-product
> > device, e.g. LCD, CPU, charging, etc. The framework shall facilitate
> > the power and thermal management performed by governor and policies,
> > depending on device context and use case knowledge.
> >
> > Authors
> >
> > Eduardo Valentin, System Software Engineer at Texas Instruments,
> > working on OMAP Linux kernel, previously a working on power management
> > in maemo for Nokia.
> >
> >
> > On Tue, May 15, 2012 at 8:06 AM, Valentin, Eduardo
> > <eduardo.valentin@ti.com> wrote:
> >> Benoit,
> >>
> >> On Mon, May 14, 2012 at 8:11 PM, Cousson, Benoit <b-cousson@ti.com> wrote:
> >>> Hi Jean,
> >>>
> >>>
> >>> On 5/14/2012 2:45 PM, Jean Pihet wrote:
> >>>>
> >>>> Hi Benoit,
> >>>>
> >>>> On Fri, May 11, 2012 at 9:17 AM, Valentin, Eduardo
> >>>> <eduardo.valentin@ti.com> wrote:
> >>>>>
> >>>>> Hello Mark,
> >>>>>
> >>>>> On Wed, May 2, 2012 at 5:36 PM, mark gross<markgross@thegnar.org> wrote:
> >>>>>>
> >>>>>> This is a Request For Participation in a micro-conference at this years
> >>>>>> Linux plumbers event. For this micro conference to happen we need to
> >>>>>> reach a certain critical mass WRT participants as measured by submitted
> >>>>>> talks associated to Power Management Constraints.
> >>>>>
> >>>>>
> >>>>> Nice! Thanks for proposing this.
> >>>>>
> >>>>>>
> >>>>>> The To: list is populated with folks that I've had interactions with
> >>>>>> over extending pm-qos or constraint based PM over the past year.
> >>>>>>
> >>>>>> If you are working on problems related to constraining the power /
> >>>>>> performance of devices I am inviting your participation and request you
> >>>>>> submit a proposal for presenting your problem space (preferred) and or
> >>>>>> solution to a group of developers looking for a good solution to push
> >>>>>> upstream. The talks will be about 20 min long as I want to get into
> >>>>>> some design and implementation discussions after the requirements
> >>>>>> definition is mostly finished.
> >>>>
> >>>> Is it OK to submit a talk for the next LPC? The deadline is tomorrow IIRC.
> >>>
> >>>
> >>> Yes, it is. Go ahead. It is related to Mark's proposal? Because it seems we
> >>> have to do some homework in order to participate to the micro-conf :-(.
> >>
> >> Yes, the homework is required in order to drive the discussion based
> >> on existing usable solutions..
> >>
> >> Jean, I'll write down a proposal today, from thermal requirements
> >> perspective. But we can discuss also a way to converge either in a
> >> common presentation or in even with two presentations but with strong
> >> linking together.
> >>
> >> Just trying to avoid two conflicting proposals from two peers @ti.com
> >>
> >>>
> >>> Regards,
> >>> Benoit
> >>>
> >>>
> >>>>
> >>>> Regards,
> >>>> Jean
> >>>>
> >>>>>>
> >>>>>> I am interested in gathering user mode interface needs as well as kernel
> >>>>>> mode.
> >>>>>>
> >>>>>> From a high level pm-constraints is a generalization of pm-qos to
> >>>>>> include
> >>>>>> limiting performance as well as its current limiting of device
> >>>>>> throttling.
> >>>>>>
> >>>>>> As performance limiting is typically used for any of the following:
> >>>>>> 1) staying within thermal operational envelopes
> >>>>>> 2) avoiding peak current
> >>>>>> 3) extending battery life in active use cases
> >>>>>>
> >>>>>> I invite anyone working in any of these areas or pm-qos applications to
> >>>>>> participate in this micro-conference.
> >>>>>>
> >>>>>> I will organize the micro-conference into 2 parts:
> >>>>>> 1) problem statements with specific participant examples where
> >>>>>> constraining the performance or throttling is needed.
> >>>>>
> >>>>>
> >>>>>
> >>>>> I could bring something on the use cases where this type of
> >>>>> constraining could be used. Essentially major focus gets partitioned
> >>>>> in two areas: For device skin/case temperature management, and IC's
> >>>>> junction temperature management.
> >>>>>
> >>>>> I am currently checking the traveling arrangements as well. And
> >>>>> confirming soon.
> >>>>>
> >>>>>
> >>>>>>
> >>>>>> 2) high level design brain storming.
> >>>>>>
> >>>>>> If the micro-conference happens (i.e. critical mass is reached) any
> >>>>>> interested linux-plumbers attendees is very welcome to participate.
> >>>>>>
> >>>>>> Please send me an off list email if you want me to add you to my mutt
> >>>>>> alias of interested parties I'll use to cc people on emails. Note: must
> >>>>>> of the correspondence will cc linux-pm too.
> >>>>>>
> >>>>>> Please submit a proposal if you are interested in participating in this
> >>>>>> with me. I know a number of people are working in this space for the
> >>>>>> past few years now. I think its a good time to compare notes and at
> >>>>>> least consolidate requirements and use cases. Perhaps we'll even come
> >>>>>> up
> >>>>>> with a good design to implement in the process.
> >>>>>>
> >>>>>> thanks,
> >>>>>> --mark
> >>>>>>
> >>>>>
> >>>>>
> >>>>> All best,
> >>>>> --
> >>>>>
> >>>>> Eduardo Valentin
> >>>>> _______________________________________________
> >>>>> linux-pm mailing list
> >>>>> linux-pm@lists.linux-foundation.org
> >>>>> https://lists.linuxfoundation.org/mailman/listinfo/linux-pm
> >>>
> >>>
> >>
> >>
> >>
> >> --
> >>
> >> Eduardo Valentin
> >
> >
> >
> > --
> >
> > Eduardo Valentin
^ permalink raw reply
* Re: Plumbers: PM constraints micro-conf RFP
From: Amit Kucheria @ 2012-05-15 12:58 UTC (permalink / raw)
To: Jean Pihet, markgross
Cc: Kevin Hilman, Agarwal, Ramesh, paulmck, pdeschrijver,
Praveen Chidambaram, John Stultz, linux-pm, amiettinen
In-Reply-To: <CAORVsuV7PrJb4v-7G_JJJMy-fAAFdU-R-JWfwQoRzgtSg-m_KQ@mail.gmail.com>
On Tue, May 15, 2012 at 12:40 PM, Jean Pihet <jean.pihet@newoldbits.com> wrote:
> Hi!
>
> Here is my proposal for the PM constraints micro-conf RFP, as e-mailed today:
>
> Session title: A New Model for the System and Devices Latency
>
> Name of microconference (if applicable): PM constraints micro-conf,
> led by Mark Gross
>
> Abstract:
> Due to the nature of the new SoC architectures the Power Management
> needs a new model for the various system latencies. The talk presents:
> . the concepts of system, devices, wake-up and resume latencies,
> . the recent changes in the devices framework for the latency, why
> and how to make it generic,
> . the link with the other PM QoS frameworks: thermal, cpuidle,
Jean,
Do you already consider GPU drivers, backlight drivers and battery
charging for setting constraints (performance and thermal) ?
Between your, Eduardo's and Antti's proposals, a lot of ground is
being covered and I don't want to make a new proposal just for these
three. But we're keen on helping consolidate on generic interfaces to
deal with these three kinds of devices.
> . the recent changes in the ARM/OMAP platform code for the system latency,
> . the problems encountered while modelling and measuring the
> various latencies,
>
> . a proposal on the model and on the way to implement it,
> . the planned changes in the device framework, the platform code
> and the APIs.
>
> This talk is oriented towards Linux power management developers. The
> goal is to agree on a framework implementation and the interfaces
> within the kernel and with the user space.
>
> Experience:
> Jean Pihet, NewOldBits.com
>
> Jean Pihet is working with embedded Linux since many years now, for
> companies like Texas Instruments, MontaVista, Motorola and Philips.
> Recently NewOldBits.com has been founded to provide high quality
> consulting services. The area of work is mainly OMAP Power Management,
> tracing and profiling tools (perf, ftrace, oprofile...) for recent ARM
> cores.
>
> Kind regards,
> Jean
>
> On Tue, May 15, 2012 at 7:34 AM, Valentin, Eduardo
> <eduardo.valentin@ti.com> wrote:
>> FYI,
>>
>> I will submit later today, something like this:
>> "
>> Abstract
>>
>> The thermal challenge is to design an end-product with high
>> performance while keeping the junction temperature of the IC
>> components used on this product within their limitations and which
>> does not present a thermal discomfort for the user. OMAP4/OMAP5 System
>> on Chips, operating at highest Operating Performance Points (OPP), is
>> a powerful mobile applications processor. However operating at higher
>> voltage and higher frequency in a sustained manner may cause thermal
>> limits to be exceeded, both for silicon and user comfort. We propose a
>> new framework to model per device power constraints, for containment
>> of thermal limitations across major heat sources of a end-product
>> device, e.g. LCD, CPU, charging, etc. The framework shall facilitate
>> the power and thermal management performed by governor and policies,
>> depending on device context and use case knowledge.
>>
>> Authors
>>
>> Eduardo Valentin, System Software Engineer at Texas Instruments,
>> working on OMAP Linux kernel, previously a working on power management
>> in maemo for Nokia.
>>
>>
>> On Tue, May 15, 2012 at 8:06 AM, Valentin, Eduardo
>> <eduardo.valentin@ti.com> wrote:
>>> Benoit,
>>>
>>> On Mon, May 14, 2012 at 8:11 PM, Cousson, Benoit <b-cousson@ti.com> wrote:
>>>> Hi Jean,
>>>>
>>>>
>>>> On 5/14/2012 2:45 PM, Jean Pihet wrote:
>>>>>
>>>>> Hi Benoit,
>>>>>
>>>>> On Fri, May 11, 2012 at 9:17 AM, Valentin, Eduardo
>>>>> <eduardo.valentin@ti.com> wrote:
>>>>>>
>>>>>> Hello Mark,
>>>>>>
>>>>>> On Wed, May 2, 2012 at 5:36 PM, mark gross<markgross@thegnar.org> wrote:
>>>>>>>
>>>>>>> This is a Request For Participation in a micro-conference at this years
>>>>>>> Linux plumbers event. For this micro conference to happen we need to
>>>>>>> reach a certain critical mass WRT participants as measured by submitted
>>>>>>> talks associated to Power Management Constraints.
>>>>>>
>>>>>>
>>>>>> Nice! Thanks for proposing this.
>>>>>>
>>>>>>>
>>>>>>> The To: list is populated with folks that I've had interactions with
>>>>>>> over extending pm-qos or constraint based PM over the past year.
>>>>>>>
>>>>>>> If you are working on problems related to constraining the power /
>>>>>>> performance of devices I am inviting your participation and request you
>>>>>>> submit a proposal for presenting your problem space (preferred) and or
>>>>>>> solution to a group of developers looking for a good solution to push
>>>>>>> upstream. The talks will be about 20 min long as I want to get into
>>>>>>> some design and implementation discussions after the requirements
>>>>>>> definition is mostly finished.
>>>>>
>>>>> Is it OK to submit a talk for the next LPC? The deadline is tomorrow IIRC.
>>>>
>>>>
>>>> Yes, it is. Go ahead. It is related to Mark's proposal? Because it seems we
>>>> have to do some homework in order to participate to the micro-conf :-(.
>>>
>>> Yes, the homework is required in order to drive the discussion based
>>> on existing usable solutions..
>>>
>>> Jean, I'll write down a proposal today, from thermal requirements
>>> perspective. But we can discuss also a way to converge either in a
>>> common presentation or in even with two presentations but with strong
>>> linking together.
>>>
>>> Just trying to avoid two conflicting proposals from two peers @ti.com
>>>
>>>>
>>>> Regards,
>>>> Benoit
>>>>
>>>>
>>>>>
>>>>> Regards,
>>>>> Jean
>>>>>
>>>>>>>
>>>>>>> I am interested in gathering user mode interface needs as well as kernel
>>>>>>> mode.
>>>>>>>
>>>>>>> From a high level pm-constraints is a generalization of pm-qos to
>>>>>>> include
>>>>>>> limiting performance as well as its current limiting of device
>>>>>>> throttling.
>>>>>>>
>>>>>>> As performance limiting is typically used for any of the following:
>>>>>>> 1) staying within thermal operational envelopes
>>>>>>> 2) avoiding peak current
>>>>>>> 3) extending battery life in active use cases
>>>>>>>
>>>>>>> I invite anyone working in any of these areas or pm-qos applications to
>>>>>>> participate in this micro-conference.
>>>>>>>
>>>>>>> I will organize the micro-conference into 2 parts:
>>>>>>> 1) problem statements with specific participant examples where
>>>>>>> constraining the performance or throttling is needed.
>>>>>>
>>>>>>
>>>>>>
>>>>>> I could bring something on the use cases where this type of
>>>>>> constraining could be used. Essentially major focus gets partitioned
>>>>>> in two areas: For device skin/case temperature management, and IC's
>>>>>> junction temperature management.
>>>>>>
>>>>>> I am currently checking the traveling arrangements as well. And
>>>>>> confirming soon.
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> 2) high level design brain storming.
>>>>>>>
>>>>>>> If the micro-conference happens (i.e. critical mass is reached) any
>>>>>>> interested linux-plumbers attendees is very welcome to participate.
>>>>>>>
>>>>>>> Please send me an off list email if you want me to add you to my mutt
>>>>>>> alias of interested parties I'll use to cc people on emails. Note: must
>>>>>>> of the correspondence will cc linux-pm too.
>>>>>>>
>>>>>>> Please submit a proposal if you are interested in participating in this
>>>>>>> with me. I know a number of people are working in this space for the
>>>>>>> past few years now. I think its a good time to compare notes and at
>>>>>>> least consolidate requirements and use cases. Perhaps we'll even come
>>>>>>> up
>>>>>>> with a good design to implement in the process.
>>>>>>>
>>>>>>> thanks,
>>>>>>> --mark
>>>>>>>
>>>>>>
>>>>>>
>>>>>> All best,
>>>>>> --
>>>>>>
>>>>>> Eduardo Valentin
>>>>>> _______________________________________________
>>>>>> linux-pm mailing list
>>>>>> linux-pm@lists.linux-foundation.org
>>>>>> https://lists.linuxfoundation.org/mailman/listinfo/linux-pm
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>>
>>> Eduardo Valentin
>>
>>
>>
>> --
>>
>> Eduardo Valentin
^ permalink raw reply
* Re: Plumbers: PM constraints micro-conf RFP
From: Valentin, Eduardo @ 2012-05-15 11:00 UTC (permalink / raw)
To: Jean Pihet
Cc: Kevin Hilman, Agarwal, Ramesh, markgross, paulmck, pdeschrijver,
Praveen Chidambaram, Amit Kucheria, John Stultz, linux-pm
In-Reply-To: <CAORVsuV7PrJb4v-7G_JJJMy-fAAFdU-R-JWfwQoRzgtSg-m_KQ@mail.gmail.com>
Hello,
I submitted a blueprint on launchpad as well, available here:
https://blueprints.launchpad.net/linux/+spec/lpc2012-cf-thermal-pm-constraint
On Tue, May 15, 2012 at 12:40 PM, Jean Pihet <jean.pihet@newoldbits.com> wrote:
> Hi!
>
> Here is my proposal for the PM constraints micro-conf RFP, as e-mailed today:
>
> Session title: A New Model for the System and Devices Latency
>
> Name of microconference (if applicable): PM constraints micro-conf,
> led by Mark Gross
>
> Abstract:
> Due to the nature of the new SoC architectures the Power Management
> needs a new model for the various system latencies. The talk presents:
> . the concepts of system, devices, wake-up and resume latencies,
> . the recent changes in the devices framework for the latency, why
> and how to make it generic,
> . the link with the other PM QoS frameworks: thermal, cpuidle,
> . the recent changes in the ARM/OMAP platform code for the system latency,
> . the problems encountered while modelling and measuring the
> various latencies,
> . a proposal on the model and on the way to implement it,
> . the planned changes in the device framework, the platform code
> and the APIs.
>
> This talk is oriented towards Linux power management developers. The
> goal is to agree on a framework implementation and the interfaces
> within the kernel and with the user space.
>
> Experience:
> Jean Pihet, NewOldBits.com
>
> Jean Pihet is working with embedded Linux since many years now, for
> companies like Texas Instruments, MontaVista, Motorola and Philips.
> Recently NewOldBits.com has been founded to provide high quality
> consulting services. The area of work is mainly OMAP Power Management,
> tracing and profiling tools (perf, ftrace, oprofile...) for recent ARM
> cores.
>
> Kind regards,
> Jean
>
> On Tue, May 15, 2012 at 7:34 AM, Valentin, Eduardo
> <eduardo.valentin@ti.com> wrote:
>> FYI,
>>
>> I will submit later today, something like this:
>> "
>> Abstract
>>
>> The thermal challenge is to design an end-product with high
>> performance while keeping the junction temperature of the IC
>> components used on this product within their limitations and which
>> does not present a thermal discomfort for the user. OMAP4/OMAP5 System
>> on Chips, operating at highest Operating Performance Points (OPP), is
>> a powerful mobile applications processor. However operating at higher
>> voltage and higher frequency in a sustained manner may cause thermal
>> limits to be exceeded, both for silicon and user comfort. We propose a
>> new framework to model per device power constraints, for containment
>> of thermal limitations across major heat sources of a end-product
>> device, e.g. LCD, CPU, charging, etc. The framework shall facilitate
>> the power and thermal management performed by governor and policies,
>> depending on device context and use case knowledge.
>>
>> Authors
>>
>> Eduardo Valentin, System Software Engineer at Texas Instruments,
>> working on OMAP Linux kernel, previously a working on power management
>> in maemo for Nokia.
>>
>>
>> On Tue, May 15, 2012 at 8:06 AM, Valentin, Eduardo
>> <eduardo.valentin@ti.com> wrote:
>>> Benoit,
>>>
>>> On Mon, May 14, 2012 at 8:11 PM, Cousson, Benoit <b-cousson@ti.com> wrote:
>>>> Hi Jean,
>>>>
>>>>
>>>> On 5/14/2012 2:45 PM, Jean Pihet wrote:
>>>>>
>>>>> Hi Benoit,
>>>>>
>>>>> On Fri, May 11, 2012 at 9:17 AM, Valentin, Eduardo
>>>>> <eduardo.valentin@ti.com> wrote:
>>>>>>
>>>>>> Hello Mark,
>>>>>>
>>>>>> On Wed, May 2, 2012 at 5:36 PM, mark gross<markgross@thegnar.org> wrote:
>>>>>>>
>>>>>>> This is a Request For Participation in a micro-conference at this years
>>>>>>> Linux plumbers event. For this micro conference to happen we need to
>>>>>>> reach a certain critical mass WRT participants as measured by submitted
>>>>>>> talks associated to Power Management Constraints.
>>>>>>
>>>>>>
>>>>>> Nice! Thanks for proposing this.
>>>>>>
>>>>>>>
>>>>>>> The To: list is populated with folks that I've had interactions with
>>>>>>> over extending pm-qos or constraint based PM over the past year.
>>>>>>>
>>>>>>> If you are working on problems related to constraining the power /
>>>>>>> performance of devices I am inviting your participation and request you
>>>>>>> submit a proposal for presenting your problem space (preferred) and or
>>>>>>> solution to a group of developers looking for a good solution to push
>>>>>>> upstream. The talks will be about 20 min long as I want to get into
>>>>>>> some design and implementation discussions after the requirements
>>>>>>> definition is mostly finished.
>>>>>
>>>>> Is it OK to submit a talk for the next LPC? The deadline is tomorrow IIRC.
>>>>
>>>>
>>>> Yes, it is. Go ahead. It is related to Mark's proposal? Because it seems we
>>>> have to do some homework in order to participate to the micro-conf :-(.
>>>
>>> Yes, the homework is required in order to drive the discussion based
>>> on existing usable solutions..
>>>
>>> Jean, I'll write down a proposal today, from thermal requirements
>>> perspective. But we can discuss also a way to converge either in a
>>> common presentation or in even with two presentations but with strong
>>> linking together.
>>>
>>> Just trying to avoid two conflicting proposals from two peers @ti.com
>>>
>>>>
>>>> Regards,
>>>> Benoit
>>>>
>>>>
>>>>>
>>>>> Regards,
>>>>> Jean
>>>>>
>>>>>>>
>>>>>>> I am interested in gathering user mode interface needs as well as kernel
>>>>>>> mode.
>>>>>>>
>>>>>>> From a high level pm-constraints is a generalization of pm-qos to
>>>>>>> include
>>>>>>> limiting performance as well as its current limiting of device
>>>>>>> throttling.
>>>>>>>
>>>>>>> As performance limiting is typically used for any of the following:
>>>>>>> 1) staying within thermal operational envelopes
>>>>>>> 2) avoiding peak current
>>>>>>> 3) extending battery life in active use cases
>>>>>>>
>>>>>>> I invite anyone working in any of these areas or pm-qos applications to
>>>>>>> participate in this micro-conference.
>>>>>>>
>>>>>>> I will organize the micro-conference into 2 parts:
>>>>>>> 1) problem statements with specific participant examples where
>>>>>>> constraining the performance or throttling is needed.
>>>>>>
>>>>>>
>>>>>>
>>>>>> I could bring something on the use cases where this type of
>>>>>> constraining could be used. Essentially major focus gets partitioned
>>>>>> in two areas: For device skin/case temperature management, and IC's
>>>>>> junction temperature management.
>>>>>>
>>>>>> I am currently checking the traveling arrangements as well. And
>>>>>> confirming soon.
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> 2) high level design brain storming.
>>>>>>>
>>>>>>> If the micro-conference happens (i.e. critical mass is reached) any
>>>>>>> interested linux-plumbers attendees is very welcome to participate.
>>>>>>>
>>>>>>> Please send me an off list email if you want me to add you to my mutt
>>>>>>> alias of interested parties I'll use to cc people on emails. Note: must
>>>>>>> of the correspondence will cc linux-pm too.
>>>>>>>
>>>>>>> Please submit a proposal if you are interested in participating in this
>>>>>>> with me. I know a number of people are working in this space for the
>>>>>>> past few years now. I think its a good time to compare notes and at
>>>>>>> least consolidate requirements and use cases. Perhaps we'll even come
>>>>>>> up
>>>>>>> with a good design to implement in the process.
>>>>>>>
>>>>>>> thanks,
>>>>>>> --mark
>>>>>>>
>>>>>>
>>>>>>
>>>>>> All best,
>>>>>> --
>>>>>>
>>>>>> Eduardo Valentin
>>>>>> _______________________________________________
>>>>>> linux-pm mailing list
>>>>>> linux-pm@lists.linux-foundation.org
>>>>>> https://lists.linuxfoundation.org/mailman/listinfo/linux-pm
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>>
>>> Eduardo Valentin
>>
>>
>>
>> --
>>
>> Eduardo Valentin
--
Eduardo Valentin
^ permalink raw reply
* Re: Plumbers: PM constraints micro-conf RFP
From: Jean Pihet @ 2012-05-15 9:40 UTC (permalink / raw)
To: Valentin, Eduardo, markgross, Kevin Hilman, Agarwal, Ramesh,
paulmck, Praveen Chidambaram, Amit Kucheria, John Stultz,
linux-pm, pdeschrijver
In-Reply-To: <CAGF5oy9kKPW5BF9FPXXm8-=9O5AM+NhKxjOysJbDiwDF=RvpKw@mail.gmail.com>
Hi!
Here is my proposal for the PM constraints micro-conf RFP, as e-mailed today:
Session title: A New Model for the System and Devices Latency
Name of microconference (if applicable): PM constraints micro-conf,
led by Mark Gross
Abstract:
Due to the nature of the new SoC architectures the Power Management
needs a new model for the various system latencies. The talk presents:
. the concepts of system, devices, wake-up and resume latencies,
. the recent changes in the devices framework for the latency, why
and how to make it generic,
. the link with the other PM QoS frameworks: thermal, cpuidle,
. the recent changes in the ARM/OMAP platform code for the system latency,
. the problems encountered while modelling and measuring the
various latencies,
. a proposal on the model and on the way to implement it,
. the planned changes in the device framework, the platform code
and the APIs.
This talk is oriented towards Linux power management developers. The
goal is to agree on a framework implementation and the interfaces
within the kernel and with the user space.
Experience:
Jean Pihet, NewOldBits.com
Jean Pihet is working with embedded Linux since many years now, for
companies like Texas Instruments, MontaVista, Motorola and Philips.
Recently NewOldBits.com has been founded to provide high quality
consulting services. The area of work is mainly OMAP Power Management,
tracing and profiling tools (perf, ftrace, oprofile...) for recent ARM
cores.
Kind regards,
Jean
On Tue, May 15, 2012 at 7:34 AM, Valentin, Eduardo
<eduardo.valentin@ti.com> wrote:
> FYI,
>
> I will submit later today, something like this:
> "
> Abstract
>
> The thermal challenge is to design an end-product with high
> performance while keeping the junction temperature of the IC
> components used on this product within their limitations and which
> does not present a thermal discomfort for the user. OMAP4/OMAP5 System
> on Chips, operating at highest Operating Performance Points (OPP), is
> a powerful mobile applications processor. However operating at higher
> voltage and higher frequency in a sustained manner may cause thermal
> limits to be exceeded, both for silicon and user comfort. We propose a
> new framework to model per device power constraints, for containment
> of thermal limitations across major heat sources of a end-product
> device, e.g. LCD, CPU, charging, etc. The framework shall facilitate
> the power and thermal management performed by governor and policies,
> depending on device context and use case knowledge.
>
> Authors
>
> Eduardo Valentin, System Software Engineer at Texas Instruments,
> working on OMAP Linux kernel, previously a working on power management
> in maemo for Nokia.
>
>
> On Tue, May 15, 2012 at 8:06 AM, Valentin, Eduardo
> <eduardo.valentin@ti.com> wrote:
>> Benoit,
>>
>> On Mon, May 14, 2012 at 8:11 PM, Cousson, Benoit <b-cousson@ti.com> wrote:
>>> Hi Jean,
>>>
>>>
>>> On 5/14/2012 2:45 PM, Jean Pihet wrote:
>>>>
>>>> Hi Benoit,
>>>>
>>>> On Fri, May 11, 2012 at 9:17 AM, Valentin, Eduardo
>>>> <eduardo.valentin@ti.com> wrote:
>>>>>
>>>>> Hello Mark,
>>>>>
>>>>> On Wed, May 2, 2012 at 5:36 PM, mark gross<markgross@thegnar.org> wrote:
>>>>>>
>>>>>> This is a Request For Participation in a micro-conference at this years
>>>>>> Linux plumbers event. For this micro conference to happen we need to
>>>>>> reach a certain critical mass WRT participants as measured by submitted
>>>>>> talks associated to Power Management Constraints.
>>>>>
>>>>>
>>>>> Nice! Thanks for proposing this.
>>>>>
>>>>>>
>>>>>> The To: list is populated with folks that I've had interactions with
>>>>>> over extending pm-qos or constraint based PM over the past year.
>>>>>>
>>>>>> If you are working on problems related to constraining the power /
>>>>>> performance of devices I am inviting your participation and request you
>>>>>> submit a proposal for presenting your problem space (preferred) and or
>>>>>> solution to a group of developers looking for a good solution to push
>>>>>> upstream. The talks will be about 20 min long as I want to get into
>>>>>> some design and implementation discussions after the requirements
>>>>>> definition is mostly finished.
>>>>
>>>> Is it OK to submit a talk for the next LPC? The deadline is tomorrow IIRC.
>>>
>>>
>>> Yes, it is. Go ahead. It is related to Mark's proposal? Because it seems we
>>> have to do some homework in order to participate to the micro-conf :-(.
>>
>> Yes, the homework is required in order to drive the discussion based
>> on existing usable solutions..
>>
>> Jean, I'll write down a proposal today, from thermal requirements
>> perspective. But we can discuss also a way to converge either in a
>> common presentation or in even with two presentations but with strong
>> linking together.
>>
>> Just trying to avoid two conflicting proposals from two peers @ti.com
>>
>>>
>>> Regards,
>>> Benoit
>>>
>>>
>>>>
>>>> Regards,
>>>> Jean
>>>>
>>>>>>
>>>>>> I am interested in gathering user mode interface needs as well as kernel
>>>>>> mode.
>>>>>>
>>>>>> From a high level pm-constraints is a generalization of pm-qos to
>>>>>> include
>>>>>> limiting performance as well as its current limiting of device
>>>>>> throttling.
>>>>>>
>>>>>> As performance limiting is typically used for any of the following:
>>>>>> 1) staying within thermal operational envelopes
>>>>>> 2) avoiding peak current
>>>>>> 3) extending battery life in active use cases
>>>>>>
>>>>>> I invite anyone working in any of these areas or pm-qos applications to
>>>>>> participate in this micro-conference.
>>>>>>
>>>>>> I will organize the micro-conference into 2 parts:
>>>>>> 1) problem statements with specific participant examples where
>>>>>> constraining the performance or throttling is needed.
>>>>>
>>>>>
>>>>>
>>>>> I could bring something on the use cases where this type of
>>>>> constraining could be used. Essentially major focus gets partitioned
>>>>> in two areas: For device skin/case temperature management, and IC's
>>>>> junction temperature management.
>>>>>
>>>>> I am currently checking the traveling arrangements as well. And
>>>>> confirming soon.
>>>>>
>>>>>
>>>>>>
>>>>>> 2) high level design brain storming.
>>>>>>
>>>>>> If the micro-conference happens (i.e. critical mass is reached) any
>>>>>> interested linux-plumbers attendees is very welcome to participate.
>>>>>>
>>>>>> Please send me an off list email if you want me to add you to my mutt
>>>>>> alias of interested parties I'll use to cc people on emails. Note: must
>>>>>> of the correspondence will cc linux-pm too.
>>>>>>
>>>>>> Please submit a proposal if you are interested in participating in this
>>>>>> with me. I know a number of people are working in this space for the
>>>>>> past few years now. I think its a good time to compare notes and at
>>>>>> least consolidate requirements and use cases. Perhaps we'll even come
>>>>>> up
>>>>>> with a good design to implement in the process.
>>>>>>
>>>>>> thanks,
>>>>>> --mark
>>>>>>
>>>>>
>>>>>
>>>>> All best,
>>>>> --
>>>>>
>>>>> Eduardo Valentin
>>>>> _______________________________________________
>>>>> linux-pm mailing list
>>>>> linux-pm@lists.linux-foundation.org
>>>>> https://lists.linuxfoundation.org/mailman/listinfo/linux-pm
>>>
>>>
>>
>>
>>
>> --
>>
>> Eduardo Valentin
>
>
>
> --
>
> Eduardo Valentin
^ permalink raw reply
* Re: [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling)
From: J, KEERTHY @ 2012-05-15 5:46 UTC (permalink / raw)
To: Rafael J. Wysocki, Kevin Hilman
Cc: linux-omap, linux-arm-kernel, linux-kernel, linux-pm, j-pihet
In-Reply-To: <87397by2h9.fsf@ti.com>
On Tue, May 8, 2012 at 5:21 AM, Kevin Hilman <khilman@ti.com> wrote:
> Rafael,
>
> Keerthy <j-keerthy@ti.com> writes:
>
>> From: J Keerthy <j-keerthy@ti.com>
>>
>> AVS(Adaptive Voltage Scaling) is a power management technique which
>> controls the operating voltage of a device in order to optimize (i.e. reduce)
>> its power consumption. The voltage is adapted depending on static factors
>> (chip manufacturing process) and dynamic factors (temperature
>> depending performance).
>> The TI AVS solution is named Smartreflex.
>>
>> To that end, create the AVS driver in drivers/power/avs and
>> move the OMAP SmartReflex code to the new directory. The
>> class driver is still retained in the mach-omap2 directory.
>
> How should we handle this for upstream?
>
> It does a bunch of cleanup under arch/arm then does the move to
> drivers/power the end. To avoid conflicts with other OMAP core changes,
> I would suggest we take this through the OMAP tree.
>
> With your ack, I'd be glad to take it.
Hello Rafael,
A gentle ping on this series.
>
> Thanks,
>
> Kevin
>
--
Regards and Thanks,
Keerthy
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Plumbers: PM constraints micro-conf RFP
From: mark gross @ 2012-05-14 13:35 UTC (permalink / raw)
To: Antti P Miettinen
Cc: Kevin Hilman, Agarwal, Ramesh, markgross, paulmck, pdeschrijver,
Praveen Chidambaram, Amit Kucheria, John Stultz, linux-pm,
jeen.pihet
In-Reply-To: <87vcjz6tli.fsf@amiettinen-lnx.nvidia.com>
On Mon, May 14, 2012 at 11:43:21AM +0300, Antti P Miettinen wrote:
> mark gross <markgross@thegnar.org> writes:
> > I forgot to make clear a few things specific to the Plumbers conference.
> > 1) they need proposals by mid may
> > 2) if you want financial assistance to be part of this micro-conf you
> > need to ask the conference committee and I think I need to recommend you
> > as an important participant. --- Paul, can you clarify this?
> >
> > If we don't get a critical mass as determined by the conference
> > committee we can try again / do more stuff over email. BTW we should be
> > doing more of anyway.
> >
> > --mark
>
> Not being familiar with LPC format - does LPC expect just a presentation
> or should there be also a "paper"? I just registered a blueprint at
>
> https://blueprints.launchpad.net/lpc/+spec/lpc2012-cf-tegra
>
> Is the format OK for a proposal?
That looks good to me. But, Paul would be right person to confirm.
Please be sure to give equal time to the problem statement as well as
your implementation in the presentation. Depending on time constraints,
TBD, you may need to trim back on the talk or not.
The time per talk depends on how much participation we get.
--mark
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox