* Re: [REGRESSION] 3.7-rc2 kernel BUG at kernel/power/snapshot.c:517!
From: Rafael J. Wysocki @ 2012-10-28 21:45 UTC (permalink / raw)
To: maciej.rutecki
Cc: Linux Kernel Mailing List, lenb, linux-acpi, pavel, linux-pm
In-Reply-To: <201210282212.50282.maciej.rutecki@gmail.com>
On Sunday, October 28, 2012 10:12:49 PM Maciej Rutecki wrote:
> On niedziela, 21 października 2012 o 17:12:28 Maciej Rutecki wrote:
> > Error: kernel BUG at kernel/power/snapshot.c:517!
> >
> > Last known good: 3.6.1
> > Bad: 3.7-rc2
> >
> > Steps to reproduce:
> > 1. Boot system with 3.7-rc2 kernel
> > 2. Try suspend to disk (s2ram works OK)
> >
> > System dies on message:
> > http://mrutecki.pl/download/kernel/3.7-rc2/swinka/DSCN0280.jpg
> >
> > lspci:
> > http://mrutecki.pl/download/kernel/3.7-rc2/swinka/lspci.txt
> >
> > dmesg:
> > http://mrutecki.pl/download/kernel/3.7-rc2/swinka/dmesg-3.7-rc2.txt
>
> Still present in -rc3
This appears to be a memory allocation error and I have no idea what
the reason of it is.
Any chance to bisect?
Does "echo disk > /sys/power/state" work?
Rafael
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" 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: [REGRESSION] 3.7-rc2 kernel BUG at kernel/power/snapshot.c:517!
From: Maciej Rutecki @ 2012-10-28 21:12 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: lenb, rjw, linux-acpi, pavel, linux-pm
In-Reply-To: <201210211712.28571.maciej.rutecki@gmail.com>
On niedziela, 21 października 2012 o 17:12:28 Maciej Rutecki wrote:
> Error: kernel BUG at kernel/power/snapshot.c:517!
>
> Last known good: 3.6.1
> Bad: 3.7-rc2
>
> Steps to reproduce:
> 1. Boot system with 3.7-rc2 kernel
> 2. Try suspend to disk (s2ram works OK)
>
> System dies on message:
> http://mrutecki.pl/download/kernel/3.7-rc2/swinka/DSCN0280.jpg
>
> lspci:
> http://mrutecki.pl/download/kernel/3.7-rc2/swinka/lspci.txt
>
> dmesg:
> http://mrutecki.pl/download/kernel/3.7-rc2/swinka/dmesg-3.7-rc2.txt
Still present in -rc3
Regards
--
Maciej Rutecki
http://www.mrutecki.pl
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" 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: [linux-pm] [RFC v2 0/3] ahci_platform: unbind/rmmod power down sequence
From: Rafael J. Wysocki @ 2012-10-28 0:11 UTC (permalink / raw)
To: Brian Norris; +Cc: Jeff Garzik, Tejun Heo, linux-ide, Linux PM list
In-Reply-To: <1351368576-5264-1-git-send-email-computersforpeace@gmail.com>
Hi,
Please don't CC the linux-pm@lists.linux-foundation.org list, which is dead.
Please use linux-pm@vger.kernel.org for future submissions, as documented in
multiple places.
Thanks,
Rafael
On Saturday, October 27, 2012 01:09:33 PM Brian Norris wrote:
> Hello,
>
> This is a follow up on a previous questions and RFC series I sent. See here for
> some context:
>
> http://article.gmane.org/gmane.linux.ide/53143
> http://article.gmane.org/gmane.linux.ide/52951
>
> This series:
>
> (1) Allows ahci_platform to unbind a device from the driver. This is useful for
> allowing total power-off of the device, for instance.
> (2) Adds ahci_platform ata_port_operations.host_stop() hook, so that
> platform-device exit() can power down the device at the appropriate point
> in the removal sequence.
>
> Thanks to Tejun for the comments, which suggested that ahci_platform (not
> libata-core) was broken.
>
> Brian
>
> Brian Norris (3):
> ahci_platform: enable hotplug unbinding
> ahci_platform: convert to module_platform_driver
> ahci_platform: perform platform exit in host_stop() hook
>
> drivers/ata/ahci_platform.c | 44 +++++++++++++++++++++++++-------------------
> 1 file changed, 25 insertions(+), 19 deletions(-)
>
>
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
^ permalink raw reply
* Re: [PATCH V2 5/6] Thermal: Add ST-Ericsson DB8500 thermal driver.
From: Francesco Lavra @ 2012-10-27 10:53 UTC (permalink / raw)
To: hongbo.zhang, linaro-dev@lists.linaro.org, linux-kernel, linux-pm
Cc: STEricsson_nomadik_linux, kernel, linaro-kernel, Patch Tracking
In-Reply-To: <1351163639-29304-1-git-send-email-hongbo.zhang@linaro.com>
On Thu Oct 25 11:13:59 2012, Hongbo Zhang wrote:
> From: "hongbo.zhang" <hongbo.zhang@linaro.com>
>
> This diver is based on the thermal management framework in thermal_sys.c. A
> thermal zone device is created with the trip points to which cooling devices
> can be bound, the current cooling device is cpufreq, e.g. CPU frequency is
> clipped down to cool the CPU, and other cooling devices can be added and bound
> to the trip points dynamically. The platform specific PRCMU interrupts are
> used to active thermal update when trip points are reached.
>
> Signed-off-by: hongbo.zhang <hongbo.zhang@linaro.com>
> ---
> .../devicetree/bindings/thermal/db8500-thermal.txt | 40 ++
> drivers/thermal/Kconfig | 20 +
> drivers/thermal/Makefile | 2 +
> drivers/thermal/db8500_cpufreq_cooling.c | 121 +++++
> drivers/thermal/db8500_thermal.c | 523 +++++++++++++++++++++
> include/linux/platform_data/db8500_thermal.h | 38 ++
> 6 files changed, 744 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/thermal/db8500-thermal.txt
> create mode 100644 drivers/thermal/db8500_cpufreq_cooling.c
> create mode 100644 drivers/thermal/db8500_thermal.c
> create mode 100644 include/linux/platform_data/db8500_thermal.h
>
> diff --git a/Documentation/devicetree/bindings/thermal/db8500-thermal.txt b/Documentation/devicetree/bindings/thermal/db8500-thermal.txt
> new file mode 100644
> index 0000000..abe08d7
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/thermal/db8500-thermal.txt
> @@ -0,0 +1,40 @@
> +* ST-Ericsson DB8500 Thermal
> +
> +** Thermal node properties:
> +
> +- compatible : "stericsson,db8500-thermal";
> +- reg : address range of the thermal sensor registers;
> +- interrupts : interrupts generated form PRCMU;
s/form/from
[...]
> diff --git a/drivers/thermal/db8500_cpufreq_cooling.c b/drivers/thermal/db8500_cpufreq_cooling.c
> new file mode 100644
> index 0000000..f6a8d24
> --- /dev/null
> +++ b/drivers/thermal/db8500_cpufreq_cooling.c
> @@ -0,0 +1,121 @@
> +/*
> + * db8500_cpufreq_cooling.c - db8500 cpufreq works as cooling device.
> + *
> + * Copyright (C) 2012 ST-Ericsson
> + * Copyright (C) 2012 Linaro Ltd.
> + *
> + * Author: Hongbo Zhang <hognbo.zhang@linaro.com>
Why do you keep writing an incorrect email address? :)
I'm referring to the spelling "hognbo" instead of "hongbo".
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +
> +#include <linux/cpu_cooling.h>
> +#include <linux/cpufreq.h>
> +#include <linux/err.h>
> +#include <linux/module.h>
> +#include <linux/platform_device.h>
> +#include <linux/slab.h>
> +
> +static LIST_HEAD(db8500_cpufreq_cdev_list);
> +
> +struct db8500_cpufreq_cdev {
> + struct thermal_cooling_device *cdev;
> + struct list_head node;
> +};
> +
> +static int db8500_cpufreq_cooling_probe(struct platform_device *pdev)
> +{
> + struct db8500_cpufreq_cdev *cooling_dev;
> + struct cpumask mask_val;
> +
> + cooling_dev = devm_kzalloc(&pdev->dev, sizeof(*cooling_dev),
> + GFP_KERNEL);
> + if (!cooling_dev)
> + return -ENOMEM;
> +
> + cpumask_set_cpu(0, &mask_val);
> + cooling_dev->cdev = cpufreq_cooling_register(&mask_val);
> +
> + if (IS_ERR_OR_NULL(cooling_dev->cdev)) {
> + dev_err(&pdev->dev, "Failed to register cooling device\n");
> + return PTR_ERR(cooling_dev->cdev);
> + }
> +
> + platform_set_drvdata(pdev, cooling_dev->cdev);
> + list_add_tail(&cooling_dev->node, &db8500_cpufreq_cdev_list);
> + dev_info(&pdev->dev, "Cooling device registered: %s\n",
> + cooling_dev->cdev->type);
> +
> + return 0;
> +}
> +
> +static int db8500_cpufreq_cooling_remove(struct platform_device *pdev)
> +{
> + struct db8500_cpufreq_cdev *cooling_dev;
> +
> + list_for_each_entry(cooling_dev, &db8500_cpufreq_cdev_list, node)
> + if (cooling_dev->cdev == platform_get_drvdata(pdev)) {
> + cpufreq_cooling_unregister(cooling_dev->cdev);
> + list_del(&cooling_dev->node);
> + }
> +
> + return 0;
> +}
There is no need to keep an internal list of cooling devices, and the
struct db8500_cpufreq_cdev definition is not needed either.
In probe() you can simply call platform_set_drvdata() with the pointer
returned by cpufreq_cooling_register(); conversely, in remove() you can
simply call cpufreq_cooling_unregister() with the pointer returned by
platform_get_drvdata().
> +
> +static int db8500_cpufreq_cooling_suspend(struct platform_device *pdev,
> + pm_message_t state)
> +{
> + return -ENOSYS;
> +}
> +
> +static int db8500_cpufreq_cooling_resume(struct platform_device *pdev)
> +{
> + return -ENOSYS;
> +}
> +
> +#ifdef CONFIG_OF
> +static const struct of_device_id db8500_cpufreq_cooling_match[] = {
> + { .compatible = "stericsson,db8500-cpufreq-cooling" },
> + {},
> +};
> +#else
> +#define db8500_cpufreq_cooling_match NULL
> +#endif
> +
> +static struct platform_driver db8500_cpufreq_cooling_driver = {
> + .driver = {
> + .owner = THIS_MODULE,
> + .name = "db8500-cpufreq-cooling",
> + .of_match_table = db8500_cpufreq_cooling_match,
> + },
> + .probe = db8500_cpufreq_cooling_probe,
> + .suspend = db8500_cpufreq_cooling_suspend,
> + .resume = db8500_cpufreq_cooling_resume,
> + .remove = __devexit_p(db8500_cpufreq_cooling_remove),
Since db8500_cpufreq_cooling_remove is not __devexit anymore,
__devexit_p() should be removed.
> +};
> +
> +static int __init db8500_cpufreq_cooling_init(void)
> +{
> + return platform_driver_register(&db8500_cpufreq_cooling_driver);
> +}
> +
> +static void __exit db8500_cpufreq_cooling_exit(void)
> +{
> + platform_driver_unregister(&db8500_cpufreq_cooling_driver);
> +}
> +
> +/* Should be later than db8500_cpufreq_register */
> +late_initcall(db8500_cpufreq_cooling_init);
> +module_exit(db8500_cpufreq_cooling_exit);
> +
> +MODULE_AUTHOR("Hongbo Zhang <hongbo.zhang@stericsson.com>");
> +MODULE_DESCRIPTION("DB8500 cpufreq cooling driver");
> +MODULE_LICENSE("GPL");
> diff --git a/drivers/thermal/db8500_thermal.c b/drivers/thermal/db8500_thermal.c
> new file mode 100644
> index 0000000..d12bf9b
> --- /dev/null
> +++ b/drivers/thermal/db8500_thermal.c
> @@ -0,0 +1,523 @@
> +/*
> + * db8500_thermal.c - db8500 Thermal Management Implementation
> + *
> + * Copyright (C) 2012 ST-Ericsson
> + * Copyright (C) 2012 Linaro Ltd.
> + *
> + * Author: Hongbo Zhang <hognbo.zhang@linaro.com>
s/hognbo/hongbo
[...]
> +static irqreturn_t prcmu_high_irq_handler(int irq, void *irq_data)
> +{
> + struct db8500_thermal_zone *pzone = irq_data;
> + struct db8500_thsens_platform_data *ptrips = pzone->trip_tab;
> + unsigned int idx = pzone->cur_index;
> + unsigned long next_low, next_high;
> +
> + if (idx < ptrips->num_trips - 1) {
> + next_high = ptrips->trip_points[idx+1].temp;
> + next_low = ptrips->trip_points[idx].temp;
> + idx += 1;
> +
> + db8500_thermal_update_config(pzone, idx, THERMAL_TREND_RAISING,
> + next_low, next_high);
> +
> + dev_dbg(&pzone->therm_dev->device,
> + "PRCMU set max %ld, min %ld\n", next_high, next_low);
> + }
> +
> + else if (idx == ptrips->num_trips - 1)
As per kernel coding style, the else clause should be in the same line
as the closing brace of the if block:
} else if ()
> + pzone->cur_temp_pseudo = ptrips->trip_points[idx].temp + 1;
> +
> + schedule_work(&pzone->therm_work);
> +
> + return IRQ_HANDLED;
> +}
> +
> +static void db8500_thermal_work(struct work_struct *work)
> +{
> + enum thermal_device_mode cur_mode;
> + struct db8500_thermal_zone *pzone;
> +
> + pzone = container_of(work, struct db8500_thermal_zone, therm_work);
> +
> + mutex_lock(&pzone->th_lock);
> + cur_mode = pzone->mode;
> + mutex_unlock(&pzone->th_lock);
> +
> + if (cur_mode == THERMAL_DEVICE_DISABLED)
> + return;
> +
> + thermal_zone_device_update(pzone->therm_dev);
> + dev_dbg(&pzone->therm_dev->device, "thermal work finished.\n");
> +}
> +
> +#ifdef CONFIG_OF
> +static struct db8500_thsens_platform_data*
> + db8500_thermal_parse_dt(struct platform_device *pdev)
> +{
> + struct db8500_thsens_platform_data *ptrips;
> + struct device_node *np = pdev->dev.of_node;
> + char prop_name[32];
> + const char *tmp_str;
> + u32 tmp_data;
> + int i, j;
> +
> + ptrips = devm_kzalloc(&pdev->dev, sizeof(*ptrips), GFP_KERNEL);
> + if (!ptrips)
> + return NULL;
> +
> + if (of_property_read_u32(np, "num-trips", &tmp_data))
> + goto err_parse_dt;
> +
> + ptrips->num_trips = tmp_data;
There should be a check against tmp_data exceeding the size of the
trip_points array.
> +
> + for (i = 0; i < ptrips->num_trips; i++) {
> + sprintf(prop_name, "trip%d-temp", i);
> + if (of_property_read_u32(np, prop_name, &tmp_data))
> + goto err_parse_dt;
> +
> + ptrips->trip_points[i].temp = tmp_data;
> +
> + sprintf(prop_name, "trip%d-type", i);
> + if (of_property_read_string(np, prop_name, &tmp_str))
> + goto err_parse_dt;
> +
> + if (!strcmp(tmp_str, "active"))
> + ptrips->trip_points[i].type = THERMAL_TRIP_ACTIVE;
> + else if (!strcmp(tmp_str, "passive"))
> + ptrips->trip_points[i].type = THERMAL_TRIP_PASSIVE;
> + else if (!strcmp(tmp_str, "hot"))
> + ptrips->trip_points[i].type = THERMAL_TRIP_HOT;
> + else if (!strcmp(tmp_str, "critical"))
> + ptrips->trip_points[i].type = THERMAL_TRIP_CRITICAL;
> + else
> + goto err_parse_dt;
> +
> + sprintf(prop_name, "trip%d-cdev-num", i);
> + if (of_property_read_u32(np, prop_name, &tmp_data))
> + goto err_parse_dt;
> +
> + for (j = 0; j < tmp_data; j++) {
> + sprintf(prop_name, "trip%d-cdev-name%d", i, j);
> + if (of_property_read_string(np, prop_name, &tmp_str))
> + goto err_parse_dt;
> + strcpy(ptrips->trip_points[i].cdev_name[j], tmp_str);
You should check that tmp_data doesn't exceed the size of the cdev_name
array, and that the length of the tmp_str string doesn't exceed the size
of each element of the cdev_name array.
[...]
> +static struct platform_driver db8500_thermal_driver = {
> + .driver = {
> + .owner = THIS_MODULE,
> + .name = "db8500-thermal",
> + .of_match_table = db8500_thermal_match,
> + },
> + .probe = db8500_thermal_probe,
> + .suspend = db8500_thermal_suspend,
> + .resume = db8500_thermal_resume,
> + .remove = __devexit_p(db8500_thermal_remove),
__devexit_p() should be removed.
> +};
> +
> +module_platform_driver(db8500_thermal_driver);
> +
> +MODULE_AUTHOR("Hongbo Zhang <hongbo.zhang@stericsson.com>");
> +MODULE_DESCRIPTION("DB8500 thermal driver");
> +MODULE_LICENSE("GPL");
> diff --git a/include/linux/platform_data/db8500_thermal.h b/include/linux/platform_data/db8500_thermal.h
> new file mode 100644
> index 0000000..aad98f8
> --- /dev/null
> +++ b/include/linux/platform_data/db8500_thermal.h
> @@ -0,0 +1,38 @@
> +/*
> + * db8500_thermal.h - db8500 Thermal Management Implementation
> + *
> + * Copyright (C) 2012 ST-Ericsson
> + * Copyright (C) 2012 Linaro Ltd.
> + *
> + * Author: Hongbo Zhang <hognbo.zhang@linaro.com>
s/hognbo/hongbo
PS: When re-sending the patch, I'd suggest you re-send the entire patch
series as V3.
Thanks,
Francesco
^ permalink raw reply
* Re: [PATCH V2 4/6] Thermal: Remove the cooling_cpufreq_list.
From: Francesco Lavra @ 2012-10-27 6:39 UTC (permalink / raw)
To: hongbo.zhang, linaro-dev@lists.linaro.org, linux-kernel, linux-pm
Cc: STEricsson_nomadik_linux, kernel, linaro-kernel, Patch Tracking
In-Reply-To: <1351235345-13050-1-git-send-email-hongbo.zhang@linaro.com>
On Fri, 26 Oct 2012 15:09:05 +0800, Hongbo Zhang wrote:
> From: "hongbo.zhang" <hongbo.zhang at linaro.com>
>
> Problem of using this list is that the cpufreq_get_max_state callback will be
> called when register cooling device by thermal_cooling_device_register, but
> this list isn't ready at this moment. What's more, there is no need to maintain
> such a list, we can get cpufreq_cooling_device instance by the private
> thermal_cooling_device.devdata.
>
> Signed-off-by: hongbo.zhang <hongbo.zhang at linaro.com>
FWIW,
Reviewed-by: Francesco Lavra <francescolavra.fl@gmail.com>
^ permalink raw reply
* Re: [PATCH -next] PM / OPP: using kfree_rcu() to simplify the code
From: Nishanth Menon @ 2012-10-27 0:14 UTC (permalink / raw)
To: Wei Yongjun, Vincent Guittot
Cc: len.brown, pavel, rjw, gregkh, yongjun_wei, linux-pm
In-Reply-To: <CAPgLHd_HvceXF4pNhnrKH3px8h59S7zTwToAjAZzjCBm3AEmRw@mail.gmail.com>
On 22:57-20121026, Wei Yongjun wrote:
> From: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
>
> The callback function of call_rcu() just calls a kfree(), so we
> can use kfree_rcu() instead of call_rcu() + callback function.
>
> dpatch engine is used to auto generate this patch.
> (https://github.com/weiyj/dpatch)
>
> Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
> ---
> drivers/base/power/opp.c | 13 +------------
> 1 file changed, 1 insertion(+), 12 deletions(-)
>
> diff --git a/drivers/base/power/opp.c b/drivers/base/power/opp.c
> index c8a908b..50b2831 100644
> --- a/drivers/base/power/opp.c
> +++ b/drivers/base/power/opp.c
> @@ -461,17 +461,6 @@ int opp_add(struct device *dev, unsigned long freq, unsigned long u_volt)
> }
>
> /**
> - * opp_free_rcu() - helper to clear the struct opp when grace period has
> - * elapsed without blocking the the caller of opp_set_availability
> - */
> -static void opp_free_rcu(struct rcu_head *head)
> -{
> - struct opp *opp = container_of(head, struct opp, head);
> -
> - kfree(opp);
> -}
> -
> -/**
> * opp_set_availability() - helper to set the availability of an opp
> * @dev: device for which we do this operation
> * @freq: OPP frequency to modify availability
> @@ -542,7 +531,7 @@ static int opp_set_availability(struct device *dev, unsigned long freq,
>
> list_replace_rcu(&opp->node, &new_opp->node);
> mutex_unlock(&dev_opp_list_lock);
> - call_rcu(&opp->head, opp_free_rcu);
> + kfree_rcu(opp, head);
>
> /* Notify the change of the OPP availability */
> if (availability_req)
A good idea. thanks.
I wonder if we might squash this with
https://patchwork.kernel.org/patch/1504361/
on a side note:
struct opp {
struct list_head node;
bool available;
unsigned long rate;
unsigned long u_volt;
struct device_opp *dev_opp;
struct rcu_head;
};
we could move rcu_head to the top of the struct .. just to avoid
revisiting this at a later point in time *if* struct opp expands..
If we are squashing it, we might consider fixing the kern-doc for
"head"..
--
Regards,
Nishanth Menon
^ permalink raw reply
* Re: [PATCH 0/8] clk: ux500: Fixup smp_twd clk for clk notifiers
From: Linus Walleij @ 2012-10-26 23:34 UTC (permalink / raw)
To: Mike Turquette
Cc: Ulf Hansson, Samuel Ortiz, Ulf Hansson, linux-arm-kernel,
Rafael J. Wysocki, cpufreq, linux-pm, Philippe Begnic,
Rickard Andersson, Jonas Aberg, Vincent Guittot
In-Reply-To: <20121026180349.3141.76336@nucleus>
On Fri, Oct 26, 2012 at 8:03 PM, Mike Turquette <mturquette@ti.com> wrote:
> Would be better to get ACKs but enough time has passed. I'll take these
> into clk-next (which will get built while I fly to Copenhagen for LCE).
OK FWIW: Acked-by: Linus Walleij <linus.walleij@linaro.org>
for all.
Yours,
Linus Walleij
^ permalink raw reply
* [GIT PULL] Power management and ACPI fixes for 3.7-rc3
From: Rafael J. Wysocki @ 2012-10-26 21:20 UTC (permalink / raw)
To: Linus Torvalds; +Cc: ACPI Devel Maling List, LKML, Linux PM list, Len Brown
Hi Linus,
Please pull from the git repository at
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git pm+acpi-for-3.7-rc3
to receive power management and ACPI fixes for v3.7-rc3 with top-most commit
879dca019dc43a1622edca3e7dde644b14b5acc5
ACPI: missing break
on top of commit 6f0c0580b70c89094b3422ba81118c7b959c7556
Linux 3.7-rc2
Included are:
* Fix for a recently introduced memory leak in acpi_bind_one() from Jesper Juhl.
* PM domains fix for an error code path memory leak in pm_genpd_attach_cpuidle()
from Jonghwan Choi.
* Fix for smp_processor_id() usage in preemptible code in powernow-k8 from
Andreas Herrmann (stable material).
* Fix for a suspend-related memory leak in cpufreq stats from Xiaobing Tu.
* Freezer fix for failure to clear PF_NOFREEZE along with PF_KTHREAD
in flush_old_exec() from Oleg Nesterov.
* One-liner acpi_processor_notify() fix from Alan Cox.
Thanks!
drivers/acpi/glue.c | 1 +
drivers/acpi/processor_driver.c | 1 +
drivers/base/power/domain.c | 5 ++++-
drivers/cpufreq/cpufreq_stats.c | 1 +
drivers/cpufreq/powernow-k8.c | 9 +--------
fs/exec.c | 3 ++-
6 files changed, 10 insertions(+), 10 deletions(-)
---------------
Alan Cox (1):
ACPI: missing break
Andreas Herrmann (1):
cpufreq / powernow-k8: Remove usage of smp_processor_id() in preemptible code
Jesper Juhl (1):
ACPI: Fix memory leak in acpi_bind_one()
Oleg Nesterov (1):
freezer: exec should clear PF_NOFREEZE along with PF_KTHREAD
Tu, Xiaobing (1):
Fix memory leak in cpufreq stats.
jhbird.choi@samsung.com (1):
PM / Domains: Fix memory leak on error path in pm_genpd_attach_cpuidle
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
^ permalink raw reply
* Re: [PATCH] cpufreq: fix jiffies/cputime mixup in conservative/ondemand governors
From: Rafael J. Wysocki @ 2012-10-26 21:10 UTC (permalink / raw)
To: Andreas Schwab; +Cc: cpufreq, linux-pm
In-Reply-To: <m2625x5shx.fsf@igel.home>
On Friday, October 26, 2012 02:26:34 PM Andreas Schwab wrote:
> "Rafael J. Wysocki" <rjw@sisk.pl> writes:
>
> > http://git.kernel.org/?p=linux/kernel/git/rafael/linux-pm.git;a=shortlog;h=refs/heads/linux-next
>
> 91f347c looks good, unfortunately d7d6f64 undoes the change.
I didn't notice that, sorry. Thanks for the heads up.
Rafael
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
^ permalink raw reply
* Re: [PATCH 0/4][V2] cpuidle : multiple drivers support
From: Rafael J. Wysocki @ 2012-10-26 21:10 UTC (permalink / raw)
To: Daniel Lezcano
Cc: Peter De Schrijver, linaro-dev@lists.linaro.org,
patches@linaro.org, linux-pm@vger.kernel.org
In-Reply-To: <508AE341.6050102@linaro.org>
On Friday, October 26, 2012 09:23:45 PM Daniel Lezcano wrote:
>
> Rafael,
>
> this patchset does not apply anymore on linux-pm-next.
>
> Let me refresh it and resend a V3.
OK, thanks!
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
^ permalink raw reply
* Re: [PATCH 0/4][V2] cpuidle : multiple drivers support
From: Daniel Lezcano @ 2012-10-26 19:23 UTC (permalink / raw)
To: Peter De Schrijver
Cc: Rafael J. Wysocki, linaro-dev@lists.linaro.org,
patches@linaro.org, linux-pm@vger.kernel.org
In-Reply-To: <20121026082358.GD1962@tbergstrom-lnx.Nvidia.com>
Rafael,
this patchset does not apply anymore on linux-pm-next.
Let me refresh it and resend a V3.
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
^ permalink raw reply
* Re: [PATCH 0/8] clk: ux500: Fixup smp_twd clk for clk notifiers
From: Mike Turquette @ 2012-10-26 18:03 UTC (permalink / raw)
To: Linus Walleij, Ulf Hansson
Cc: Samuel Ortiz, Ulf Hansson, linux-arm-kernel, Rafael J. Wysocki,
cpufreq, linux-pm, Philippe Begnic, Rickard Andersson,
Jonas Aberg, Vincent Guittot
In-Reply-To: <CACRpkdYdzvdJc=+gnRDEue1uZApGTc-P2pQfLAJXc_uBZLSPkQ@mail.gmail.com>
Quoting Linus Walleij (2012-10-26 01:57:49)
> On Fri, Oct 26, 2012 at 10:19 AM, Ulf Hansson <ulf.hansson@linaro.org> wrote:
>
> > Samuel, a kind reminder on this, trying to collect acks to be able to
> > advise Mike to take this series through his clk tree. There are two
> > mfd patches.
> > [PATCH 2/8] mfd: db8500: Provide cpufreq table as platform data
> > [PATCH 5/8] mfd: db8500: Connect ARMSS clk to ARM OPP
>
> Two weeks of slack for review is good enough, involved
> subsystem maintainers have been Cc:ed.
>
> Mike T, can you just apply the patches please.
>
Would be better to get ACKs but enough time has passed. I'll take these
into clk-next (which will get built while I fly to Copenhagen for LCE).
Expect to see a new clk-next on Monday.
Regards,
Mike
> Yours,
> Linus Walleij
^ permalink raw reply
* [PATCH -next] PM / OPP: using kfree_rcu() to simplify the code
From: Wei Yongjun @ 2012-10-26 14:57 UTC (permalink / raw)
To: len.brown, pavel, rjw, gregkh; +Cc: yongjun_wei, linux-pm
From: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
The callback function of call_rcu() just calls a kfree(), so we
can use kfree_rcu() instead of call_rcu() + callback function.
dpatch engine is used to auto generate this patch.
(https://github.com/weiyj/dpatch)
Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
---
drivers/base/power/opp.c | 13 +------------
1 file changed, 1 insertion(+), 12 deletions(-)
diff --git a/drivers/base/power/opp.c b/drivers/base/power/opp.c
index c8a908b..50b2831 100644
--- a/drivers/base/power/opp.c
+++ b/drivers/base/power/opp.c
@@ -461,17 +461,6 @@ int opp_add(struct device *dev, unsigned long freq, unsigned long u_volt)
}
/**
- * opp_free_rcu() - helper to clear the struct opp when grace period has
- * elapsed without blocking the the caller of opp_set_availability
- */
-static void opp_free_rcu(struct rcu_head *head)
-{
- struct opp *opp = container_of(head, struct opp, head);
-
- kfree(opp);
-}
-
-/**
* opp_set_availability() - helper to set the availability of an opp
* @dev: device for which we do this operation
* @freq: OPP frequency to modify availability
@@ -542,7 +531,7 @@ static int opp_set_availability(struct device *dev, unsigned long freq,
list_replace_rcu(&opp->node, &new_opp->node);
mutex_unlock(&dev_opp_list_lock);
- call_rcu(&opp->head, opp_free_rcu);
+ kfree_rcu(opp, head);
/* Notify the change of the OPP availability */
if (availability_req)
^ permalink raw reply related
* Re: [PATCH] cpuidle: add missing header include
From: Daniel Lezcano @ 2012-10-26 12:45 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Jingoo Han, 'Rafael J. Wysocki', linux-pm, linux-kernel
In-Reply-To: <6329232.eg8Mc603Uh@vostro.rjw.lan>
On 10/26/2012 01:14 PM, Rafael J. Wysocki wrote:
> On Friday, October 26, 2012 01:30:07 PM Jingoo Han wrote:
>> This patch adds missing device.h header to fix build warnings as below:
>>
>> drivers/cpuidle/cpuidle.h:26:41: warning: 'struct device' declared inside parameter list [enabled by default]
>> drivers/cpuidle/cpuidle.h:26:41: warning: its scope is only this definition or declaration, which is probably not what you want
>> [enabled by default]
>> drivers/cpuidle/cpuidle.h:27:45: warning: 'struct device' declared inside parameter list [enabled by default]
>> In file included from drivers/cpuidle/driver.c:15:0:
>> drivers/cpuidle/cpuidle.h:26:41: warning: 'struct device' declared inside parameter list [enabled by default]
>> drivers/cpuidle/cpuidle.h:26:41: warning: its scope is only this definition or declaration, which is probably not what you want
>> [enabled by default]
>> drivers/cpuidle/cpuidle.h:27:45: warning: 'struct device' declared inside parameter list [enabled by default]
>>
>> This build warning is introduced by commit efeca1b
>> "cpuidle / sysfs: change function parameter".
>>
>> Signed-off-by: Jingoo Han <jg1.han@samsung.com>
>> Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
>
> I fixed up the original patch.
>
> Daniel, I must say I'm less and less impressed by the quality of code
> I'm getting from you. Please improve it.
Rafael,
I am sorry there are some compilation problems with the code.
I am trying to improve and cleanup step by step the code. I would
understand you remark if I send you untested patches but I always take
care of making the patches git-bisect safe, compile and boot for every
patch.
I double checked the patch and I was able to compile without problem
with my config file.
Jingoo, would you mind to pastebin your config file please ?
If I can compile without problem and Jingoo can't compile, that means
there is something wrong with the headers and including device.h in the
cpuidle.h does not solve the root problem. Furthermore, driver.c does
not use the struct device.
At the first glance, adding a forward declaration in cpuidle.h
struct device;
and including device.h for sysfs.c should fix the problem.
There are so many combinations for the configuration that it makes
possible I miss one config option and when the code defines implicit
rules difficult to track like the _COMPONENT macro in acpi, that makes
it harder.
For example, include/linux/pm_qos.h includes device.h, but it is not
needed because a forward declaration should suffice and it is up to the
.c files to include device.h if they manipulate the struct device.
If I fix that, it is possible, with my best effort, to miss a .c to add
the device.h file if the option is not set for it.
I promise to try improving the code but please accept some parts of the
current code look like a jackstraws, don't blame me too much if
sometimes I introduce some errors.
Thanks
-- Daniel
>> ---
>> drivers/cpuidle/cpuidle.h | 2 ++
>> 1 files changed, 2 insertions(+), 0 deletions(-)
>>
>> diff --git a/drivers/cpuidle/cpuidle.h b/drivers/cpuidle/cpuidle.h
>> index a5bbd1c..2120d9e 100644
>> --- a/drivers/cpuidle/cpuidle.h
>> +++ b/drivers/cpuidle/cpuidle.h
>> @@ -5,6 +5,8 @@
>> #ifndef __DRIVER_CPUIDLE_H
>> #define __DRIVER_CPUIDLE_H
>>
>> +#include <linux/device.h>
>> +
>> /* For internal use only */
>> extern struct cpuidle_governor *cpuidle_curr_governor;
>> extern struct list_head cpuidle_governors;
>>
--
<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
^ permalink raw reply
* [PATCH RESEND] cpufreq: Make sure target freq is within limits
From: Viresh Kumar @ 2012-10-26 12:35 UTC (permalink / raw)
To: rjw
Cc: cpufreq, linux-pm, linux-kernel, linux-arm-kernel, linaro-dev,
patches, pdsw-power-team, Viresh Kumar
__cpufreq_driver_target() must not pass target frequency beyond the limits of
current policy.
Today most of cpufreq platform drivers are doing this check in their target
routines. Why not move it to __cpufreq_driver_target().
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
---
Hi Rafael,
Resend doesn't contain any change, but fixed commit log
drivers/cpufreq/cpufreq.c | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 28dc134..2f5ac2d 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -1470,12 +1470,19 @@ int __cpufreq_driver_target(struct cpufreq_policy *policy,
unsigned int relation)
{
int retval = -EINVAL;
+ unsigned int old_target_freq = target_freq;
if (cpufreq_disabled())
return -ENODEV;
- pr_debug("target for CPU %u: %u kHz, relation %u\n", policy->cpu,
- target_freq, relation);
+ /* Make sure that target_freq is within supported range */
+ if (target_freq > policy->max)
+ target_freq = policy->max;
+ if (target_freq < policy->min)
+ target_freq = policy->min;
+
+ pr_debug("target for CPU %u: %u kHz, relation %u, requested %u kHz\n",
+ policy->cpu, target_freq, relation, old_target_freq);
if (target_freq == policy->cur)
return 0;
--
1.7.12.rc2.18.g61b472e
^ permalink raw reply related
* Re: [PATCH] cpufreq: fix jiffies/cputime mixup in conservative/ondemand governors
From: Andreas Schwab @ 2012-10-26 12:26 UTC (permalink / raw)
To: Rafael J. Wysocki; +Cc: cpufreq, linux-pm
In-Reply-To: <1448859.RJLWEdIAIe@vostro.rjw.lan>
"Rafael J. Wysocki" <rjw@sisk.pl> writes:
> http://git.kernel.org/?p=linux/kernel/git/rafael/linux-pm.git;a=shortlog;h=refs/heads/linux-next
91f347c looks good, unfortunately d7d6f64 undoes the change.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: [RFC] cpufreq: Make sure target freq is within limits
From: Rafael J. Wysocki @ 2012-10-26 11:23 UTC (permalink / raw)
To: Viresh Kumar
Cc: cpufreq, linux-pm, linux-kernel, linux-arm-kernel, linaro-dev,
patches, pdsw-power-team, arvind.chauhan
In-Reply-To: <f0099171c1c4f3048d0f29b7deb42144f26ac5d5.1351146515.git.viresh.kumar@linaro.org>
On Thursday, October 25, 2012 12:03:34 PM Viresh Kumar wrote:
> Hi Rafael,
>
> __cpufreq_driver_target() must not pass target frequency beyond the limits of
> current policy.
>
> Today most of cpufreq platform drivers are doing this check in their target
> routines. Why not move it to __cpufreq_driver_target().
>
> I wanted to get your opinion on this before making changes in all driver files.
> That's why this is an RFC.
I'd prefer to apply the patch below before changing the drviers.
Thanks,
Rafael
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
> ---
> drivers/cpufreq/cpufreq.c | 11 +++++++++--
> 1 file changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> index f552d5f..59264f1 100644
> --- a/drivers/cpufreq/cpufreq.c
> +++ b/drivers/cpufreq/cpufreq.c
> @@ -1470,12 +1470,19 @@ int __cpufreq_driver_target(struct cpufreq_policy *policy,
> unsigned int relation)
> {
> int retval = -EINVAL;
> + unsigned int old_target_freq = target_freq;
>
> if (cpufreq_disabled())
> return -ENODEV;
>
> - pr_debug("target for CPU %u: %u kHz, relation %u\n", policy->cpu,
> - target_freq, relation);
> + /* Make sure that target_freq is within supported range */
> + if (target_freq > policy->max)
> + target_freq = policy->max;
> + if (target_freq < policy->min)
> + target_freq = policy->min;
> +
> + pr_debug("target for CPU %u: %u kHz, relation %u, requested %u kHz\n",
> + policy->cpu, target_freq, relation, old_target_freq);
> if (cpu_online(policy->cpu) && cpufreq_driver->target)
> retval = cpufreq_driver->target(policy, target_freq, relation);
>
>
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
^ permalink raw reply
* Re: PCI/PM: Add comments for PME poll support for PCIe
From: Rafael J. Wysocki @ 2012-10-26 11:18 UTC (permalink / raw)
To: Huang Ying
Cc: Bjorn Helgaas, linux-kernel, linux-pci, linux-pm,
Rafael J. Wysocki
In-Reply-To: <1351228071-15161-1-git-send-email-ying.huang@intel.com>
On Friday, October 26, 2012 01:07:51 PM Huang Ying wrote:
> There are comments on why PME poll support is necessary for PCI
> devices, but not for PCIe devices. That may lead to misunderstanding
> that PME poll is only necessary for PCI devices. So add comments
> related to PCIe PME poll to make it more clear.
>
> The content of comments comes from the changelog of commit:
>
> 379021d5c0899fcf9410cae4ca7a59a5a94ca769
>
> Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> Signed-off-by: Huang Ying <ying.huang@intel.com>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> ---
> drivers/pci/pci.c | 28 +++++++++++++++++++---------
> 1 file changed, 19 insertions(+), 9 deletions(-)
>
> --- a/drivers/pci/pci.c
> +++ b/drivers/pci/pci.c
> @@ -1578,15 +1578,25 @@ void pci_pme_active(struct pci_dev *dev,
>
> pci_write_config_word(dev, dev->pm_cap + PCI_PM_CTRL, pmcsr);
>
> - /* PCI (as opposed to PCIe) PME requires that the device have
> - its PME# line hooked up correctly. Not all hardware vendors
> - do this, so the PME never gets delivered and the device
> - remains asleep. The easiest way around this is to
> - periodically walk the list of suspended devices and check
> - whether any have their PME flag set. The assumption is that
> - we'll wake up often enough anyway that this won't be a huge
> - hit, and the power savings from the devices will still be a
> - win. */
> + /*
> + * PCI (as opposed to PCIe) PME requires that the device have
> + * its PME# line hooked up correctly. Not all hardware vendors
> + * do this, so the PME never gets delivered and the device
> + * remains asleep. The easiest way around this is to
> + * periodically walk the list of suspended devices and check
> + * whether any have their PME flag set. The assumption is that
> + * we'll wake up often enough anyway that this won't be a huge
> + * hit, and the power savings from the devices will still be a
> + * win.
> + *
> + * Although PCIe uses in-band PME message instead of PME# line
> + * to report PME, PME does not work for some PCIe devices in
> + * reality. For example, there are devices that set their PME
> + * status bits, but don't really bother to send a PME message;
> + * there are PCI Express Root Ports that don't bother to
> + * trigger interrupts when they receive PME messages from the
> + * devices below. So PME poll is used for PCIe devices too.
> + */
>
> if (dev->pme_poll) {
> struct pci_pme_device *pme_dev;
>
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
^ permalink raw reply
* Re: [PATCH 8/8] cpufreq: db8500: Use armss clk to update frequency
From: Rafael J. Wysocki @ 2012-10-26 11:20 UTC (permalink / raw)
To: Ulf Hansson
Cc: linux-arm-kernel, Mike Turquette, Mike Turquette, Samuel Ortiz,
cpufreq, linux-pm, Linus Walleij, Lee Jones, Philippe Begnic,
Rickard Andersson, Jonas Aberg, Vincent Guittot
In-Reply-To: <CAPDyKFp8OVn1kXzQB_PVxb4PBYCdvE7QGzCiqN+Zmm9LsX3HDg@mail.gmail.com>
On Friday, October 26, 2012 10:10:40 AM Ulf Hansson wrote:
> On 10 October 2012 13:42, Ulf Hansson <ulf.hansson@stericsson.com> wrote:
> > From: Ulf Hansson <ulf.hansson@linaro.org>
> >
> > Using the armss clk to update the frequency makes the driver no more
> > directly dependant on the prmcu API.
> >
> > Cc: Rafael J. Wysocki <rjw@sisk.pl>
> > Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
> > ---
> > drivers/cpufreq/db8500-cpufreq.c | 24 ++++++++++++++++--------
> > 1 file changed, 16 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/cpufreq/db8500-cpufreq.c b/drivers/cpufreq/db8500-cpufreq.c
> > index dea9a49..4f154bc 100644
> > --- a/drivers/cpufreq/db8500-cpufreq.c
> > +++ b/drivers/cpufreq/db8500-cpufreq.c
> > @@ -14,10 +14,11 @@
> > #include <linux/delay.h>
> > #include <linux/slab.h>
> > #include <linux/platform_device.h>
> > -#include <linux/mfd/dbx500-prcmu.h>
> > +#include <linux/clk.h>
> > #include <mach/id.h>
> >
> > static struct cpufreq_frequency_table *freq_table;
> > +static struct clk *armss_clk;
> >
> > static struct freq_attr *db8500_cpufreq_attr[] = {
> > &cpufreq_freq_attr_scaling_available_freqs,
> > @@ -58,9 +59,9 @@ static int db8500_cpufreq_target(struct cpufreq_policy *policy,
> > for_each_cpu(freqs.cpu, policy->cpus)
> > cpufreq_notify_transition(&freqs, CPUFREQ_PRECHANGE);
> >
> > - /* request the PRCM unit for opp change */
> > - if (prcmu_set_arm_opp(freq_table[idx].index)) {
> > - pr_err("db8500-cpufreq: Failed to set OPP level\n");
> > + /* update armss clk frequency */
> > + if (clk_set_rate(armss_clk, freq_table[idx].frequency * 1000)) {
> > + pr_err("db8500-cpufreq: Failed to update armss clk\n");
> > return -EINVAL;
> > }
> >
> > @@ -74,16 +75,16 @@ static int db8500_cpufreq_target(struct cpufreq_policy *policy,
> > static unsigned int db8500_cpufreq_getspeed(unsigned int cpu)
> > {
> > int i = 0;
> > - /* request the prcm to get the current ARM opp */
> > - int opp = prcmu_get_arm_opp();
> > + unsigned long freq = clk_get_rate(armss_clk) / 1000;
> >
> > while (freq_table[i].frequency != CPUFREQ_TABLE_END) {
> > - if (opp == freq_table[i].index)
> > + if (freq <= freq_table[i].frequency)
> > return freq_table[i].frequency;
> > i++;
> > }
> >
> > - /* We could not find a corresponding opp frequency. */
> > + /* We could not find a corresponding frequency. */
> > + pr_err("db8500-cpufreq: Failed to find cpufreq speed\n");
> > return 0;
> > }
> >
> > @@ -92,6 +93,12 @@ static int __cpuinit db8500_cpufreq_init(struct cpufreq_policy *policy)
> > int i = 0;
> > int res;
> >
> > + armss_clk = clk_get(NULL, "armss");
> > + if (IS_ERR(armss_clk)) {
> > + pr_err("db8500-cpufreq : Failed to get armss clk\n");
> > + return PTR_ERR(armss_clk);
> > + }
> > +
> > pr_info("db8500-cpufreq : Available frequencies:\n");
> > while (freq_table[i].frequency != CPUFREQ_TABLE_END) {
> > pr_info(" %d Mhz\n", freq_table[i].frequency/1000);
> > @@ -104,6 +111,7 @@ static int __cpuinit db8500_cpufreq_init(struct cpufreq_policy *policy)
> > cpufreq_frequency_table_get_attr(freq_table, policy->cpu);
> > else {
> > pr_err("db8500-cpufreq : Failed to read policy table\n");
> > + clk_put(armss_clk);
> > return res;
> > }
> >
> > --
> > 1.7.10
> >
>
> Just a kind reminder on this Rafael; trying to collect acks, do you
> think we can advise Mike to merge this though his clk tree?
Yes, please.
Thanks,
Rafael
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
^ permalink raw reply
* Re: [PATCH] cpufreq: Avoid calling cpufreq driver's target() routine if target_freq == policy->cur
From: Rafael J. Wysocki @ 2012-10-26 11:17 UTC (permalink / raw)
To: Viresh Kumar
Cc: cpufreq, linux-pm, linux-kernel, linux-arm-kernel, linaro-dev,
patches, pdsw-power-team
In-Reply-To: <1d7b6e421a335255da956804b43ce3517538409c.1351244153.git.viresh.kumar@linaro.org>
On Friday, October 26, 2012 03:06:26 PM Viresh Kumar wrote:
> Avoid calling cpufreq driver's target() routine if new frequency is same as
> policies current frequency.
>
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Looks reasonable.
Any objection from anyone?
Rafael
> ---
> drivers/cpufreq/cpufreq.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> index 261ef65..28dc134 100644
> --- a/drivers/cpufreq/cpufreq.c
> +++ b/drivers/cpufreq/cpufreq.c
> @@ -1476,6 +1476,10 @@ int __cpufreq_driver_target(struct cpufreq_policy *policy,
>
> pr_debug("target for CPU %u: %u kHz, relation %u\n", policy->cpu,
> target_freq, relation);
> +
> + if (target_freq == policy->cur)
> + return 0;
> +
> if (cpu_online(policy->cpu) && cpufreq_driver->target)
> retval = cpufreq_driver->target(policy, target_freq, relation);
>
>
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
^ permalink raw reply
* Re: [PATCH] cpuidle: add missing header include
From: Rafael J. Wysocki @ 2012-10-26 11:14 UTC (permalink / raw)
To: Jingoo Han, 'Daniel Lezcano'
Cc: 'Rafael J. Wysocki', linux-pm, linux-kernel
In-Reply-To: <001401cdb332$93ffe450$bbffacf0$%han@samsung.com>
On Friday, October 26, 2012 01:30:07 PM Jingoo Han wrote:
> This patch adds missing device.h header to fix build warnings as below:
>
> drivers/cpuidle/cpuidle.h:26:41: warning: 'struct device' declared inside parameter list [enabled by default]
> drivers/cpuidle/cpuidle.h:26:41: warning: its scope is only this definition or declaration, which is probably not what you want
> [enabled by default]
> drivers/cpuidle/cpuidle.h:27:45: warning: 'struct device' declared inside parameter list [enabled by default]
> In file included from drivers/cpuidle/driver.c:15:0:
> drivers/cpuidle/cpuidle.h:26:41: warning: 'struct device' declared inside parameter list [enabled by default]
> drivers/cpuidle/cpuidle.h:26:41: warning: its scope is only this definition or declaration, which is probably not what you want
> [enabled by default]
> drivers/cpuidle/cpuidle.h:27:45: warning: 'struct device' declared inside parameter list [enabled by default]
>
> This build warning is introduced by commit efeca1b
> "cpuidle / sysfs: change function parameter".
>
> Signed-off-by: Jingoo Han <jg1.han@samsung.com>
> Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
I fixed up the original patch.
Daniel, I must say I'm less and less impressed by the quality of code
I'm getting from you. Please improve it.
Thanks,
Rafael
> ---
> drivers/cpuidle/cpuidle.h | 2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/cpuidle/cpuidle.h b/drivers/cpuidle/cpuidle.h
> index a5bbd1c..2120d9e 100644
> --- a/drivers/cpuidle/cpuidle.h
> +++ b/drivers/cpuidle/cpuidle.h
> @@ -5,6 +5,8 @@
> #ifndef __DRIVER_CPUIDLE_H
> #define __DRIVER_CPUIDLE_H
>
> +#include <linux/device.h>
> +
> /* For internal use only */
> extern struct cpuidle_governor *cpuidle_curr_governor;
> extern struct list_head cpuidle_governors;
>
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
^ permalink raw reply
* [PATCH] cpufreq: Avoid calling cpufreq driver's target() routine if target_freq == policy->cur
From: Viresh Kumar @ 2012-10-26 9:36 UTC (permalink / raw)
To: rjw
Cc: cpufreq, linux-pm, linux-kernel, linux-arm-kernel, linaro-dev,
patches, pdsw-power-team, Viresh Kumar
Avoid calling cpufreq driver's target() routine if new frequency is same as
policies current frequency.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
---
drivers/cpufreq/cpufreq.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 261ef65..28dc134 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -1476,6 +1476,10 @@ int __cpufreq_driver_target(struct cpufreq_policy *policy,
pr_debug("target for CPU %u: %u kHz, relation %u\n", policy->cpu,
target_freq, relation);
+
+ if (target_freq == policy->cur)
+ return 0;
+
if (cpu_online(policy->cpu) && cpufreq_driver->target)
retval = cpufreq_driver->target(policy, target_freq, relation);
--
1.7.12.rc2.18.g61b472e
^ permalink raw reply related
* Re: [PATCH 0/8] clk: ux500: Fixup smp_twd clk for clk notifiers
From: Linus Walleij @ 2012-10-26 8:57 UTC (permalink / raw)
To: Ulf Hansson
Cc: Samuel Ortiz, Ulf Hansson, linux-arm-kernel, Mike Turquette,
Mike Turquette, Rafael J. Wysocki, cpufreq, linux-pm,
Philippe Begnic, Rickard Andersson, Jonas Aberg, Vincent Guittot
In-Reply-To: <CAPDyKFof65xAVyOo3FrdS2uYQwB1Wq3553PKj04FR6JXaJsH6Q@mail.gmail.com>
On Fri, Oct 26, 2012 at 10:19 AM, Ulf Hansson <ulf.hansson@linaro.org> wrote:
> Samuel, a kind reminder on this, trying to collect acks to be able to
> advise Mike to take this series through his clk tree. There are two
> mfd patches.
> [PATCH 2/8] mfd: db8500: Provide cpufreq table as platform data
> [PATCH 5/8] mfd: db8500: Connect ARMSS clk to ARM OPP
Two weeks of slack for review is good enough, involved
subsystem maintainers have been Cc:ed.
Mike T, can you just apply the patches please.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH 0/4][V2] cpuidle : multiple drivers support
From: Peter De Schrijver @ 2012-10-26 8:23 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: linaro-dev-cunTk1MwBs8s++Sfvej+rw@public.gmane.org,
patches-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org,
linux-pm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <4190590.cE8oL2xMlM-sKB8Sp2ER+y1GS7QM15AGw@public.gmane.org>
On Thu, Oct 25, 2012 at 10:29:43PM +0200, Rafael J. Wysocki wrote:
> On Thursday, October 25, 2012 04:49:33 PM Peter De Schrijver wrote:
> > On Fri, Oct 19, 2012 at 12:10:45PM +0200, Daniel Lezcano wrote:
> > > The discussion about having different cpus on the system with
> > > different latencies bring us to a first attemp by adding a
> > > pointer in the cpuidle_device to the states array.
> > >
> > > But as Rafael suggested, it would make more sense to create a
> > > driver per cpu [1].
> > >
> > > This patch adds support for multiple cpuidle drivers.
> > >
> > > It creates a per cpu cpuidle driver pointer.
> > >
> > > In order to not break the different drivers, the function cpuidle_register_driver
> > > assign for each cpu, the driver.
> > >
> > > The multiple driver support is optional and if it is not set, the cpuide driver
> > > core code remains the same (except some code reorganisation).
> > >
> > > I did the following tests compiled, booted, tested without/with CONFIG_CPU_IDLE,
> > > with/without CONFIG_CPU_IDLE_MULTIPLE_DRIVERS.
> > >
> > > Tested on Core2 Duo T9500 with acpi_idle [and intel_idle]
> > > Tested on ARM Dual Cortex-A9 U8500 (aka Snowball)
> > >
> > > V1 tested on Tegra3 and Vexpress TC2
> > >
> >
> > V2 tested on Tegra3.
>
> Do I assume correctly that Tested-by applies?
>
Yes.
Cheers,
Peter.
^ permalink raw reply
* Re: [PATCH 0/8] clk: ux500: Fixup smp_twd clk for clk notifiers
From: Ulf Hansson @ 2012-10-26 8:19 UTC (permalink / raw)
To: Samuel Ortiz
Cc: Linus Walleij, Ulf Hansson, linux-arm-kernel, Mike Turquette,
Mike Turquette, Rafael J. Wysocki, cpufreq, linux-pm,
Philippe Begnic, Rickard Andersson, Jonas Aberg, Vincent Guittot
In-Reply-To: <20121011151947.GD15428@gmail.com>
On 11 October 2012 17:19, Lee Jones <lee.jones@linaro.org> wrote:
> On Thu, 11 Oct 2012, Linus Walleij wrote:
>
>> On Thu, Oct 11, 2012 at 3:44 PM, Lee Jones <lee.jones@linaro.org> wrote:
>>
>> >> Patches are based on Linus Torvalds tree with latest commit as of okt 10.
>> >
>> > Hmm... I get:
>> >
>> > Applying: clk: ux500: Support for prcmu_scalable_rate clock
>> > error: drivers/clk/ux500/clk-prcmu.c: does not exist in index
>> > error: drivers/clk/ux500/clk.h: does not exist in index
>> > Patch failed at 0001 clk: ux500: Support for prcmu_scalable_rate clock
>> >
>> > So when did drivers/clk/ux500/* arrive?
>>
>> Exactly here, 10 days ago on Torvalds' master branch:
>
> Ah I see. Basing patches on commits half way through the merge
> window. Good move! ;)
>
> --
> Lee Jones
> Linaro ST-Ericsson Landing Team Lead
> Linaro.org │ Open source software for ARM SoCs
> Follow Linaro: Facebook | Twitter | Blog
Samuel, a kind reminder on this, trying to collect acks to be able to
advise Mike to take this series through his clk tree. There are two
mfd patches.
[PATCH 2/8] mfd: db8500: Provide cpufreq table as platform data
[PATCH 5/8] mfd: db8500: Connect ARMSS clk to ARM OPP
Kind regards
Ulf Hansson
^ 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