* RE: [RFC PATCH 2/7] Thermal: Create zone level APIs
From: R, Durgadoss @ 2012-12-14 5:10 UTC (permalink / raw)
To: Hongbo Zhang
Cc: Zhang, Rui, linux-pm@vger.kernel.org, wni@nvidia.com,
eduardo.valentin@ti.com, amit.kachhap@linaro.org,
sachin.kamat@linaro.org
In-Reply-To: <CAJLyvQxp9A_PT4HDhV9NUizDS9Ax+ibAb8q-j48pUOt8221zOQ@mail.gmail.com>
Hi,
> -----Original Message-----
> From: Hongbo Zhang [mailto:hongbo.zhang@linaro.org]
> Sent: Friday, December 14, 2012 9:41 AM
> To: R, Durgadoss
> Cc: Zhang, Rui; linux-pm@vger.kernel.org; wni@nvidia.com;
> eduardo.valentin@ti.com; amit.kachhap@linaro.org;
> sachin.kamat@linaro.org
> Subject: Re: [RFC PATCH 2/7] Thermal: Create zone level APIs
>
> On 13 December 2012 23:00, R, Durgadoss <durgadoss.r@intel.com> wrote:
> > Hi,
> >
> >
> >> -----Original Message-----
> >> From: linux-pm-owner@vger.kernel.org [mailto:linux-pm-
> >> owner@vger.kernel.org] On Behalf Of Hongbo Zhang
> >> Sent: Thursday, December 13, 2012 11:53 AM
> >> To: R, Durgadoss
> >> Cc: Zhang, Rui; linux-pm@vger.kernel.org; wni@nvidia.com;
> >> eduardo.valentin@ti.com; amit.kachhap@linaro.org;
> >> sachin.kamat@linaro.org
> >> Subject: Re: [RFC PATCH 2/7] Thermal: Create zone level APIs
> >>
> >> On 17 November 2012 18:45, Durgadoss R <durgadoss.r@intel.com>
> wrote:
> >> > This patch adds a new thermal_zone structure to
> >> > thermal.h. Also, adds zone level APIs to the thermal
> >> > framework.
> >> >
> >> > Signed-off-by: Durgadoss R <durgadoss.r@intel.com>
> >
> > [A big cut.]
> >
> >> > #define to_cooling_device(_dev) \
> >> > container_of(_dev, struct thermal_cooling_device, device)
> >> > @@ -1557,6 +1615,146 @@ static void remove_trip_attrs(struct
> >> thermal_zone_device *tz)
> >> > kfree(tz->trip_hyst_attrs);
> >> > }
> >> >
> >> > +struct thermal_zone *create_thermal_zone(const char *name, void
> >> *devdata)
> >> Durgaross,
> >> Since more sensors can be added into one thermal zone, think about
> >> this situation that every sensor is in itself file separately:
> >
> > Yes, we thought about this scenario.
> > The way the new framework is designed is like below:
> >
> > The thermal sensor source file can be generic (can be any sensor driver, in
> any
> > subsystem). This driver will use the sensor APIs and register with thermal
> > framework to participate in platform Thermal management. This does not
> > (and should not) know about which zone it belongs to, or any other
> information
> > about platform thermals. A sensor driver is a standalone piece of code,
> which
> > can optionally register with thermal framework.
> >
> > However, for any platform, there should be a platformX_thermal.c file,
> > which will know about the platform thermal characteristics (like how many
> sensors,
> > zones, cooling devices, etc.. And how they are related to each other i.e the
> > mapping information). Only in this file, the zone level APIs should be used,
> in
> > which case the file will have all information required to attach various
> sensors
> > to a particular zone.
> I guess you will remove the bind callback, I suggest to remove it if
> you don't have this plan.
Yes, We will remove this.
> A match callback or/and mapping data can be used to identify the
> binding relationship, the current binding process is abundant and
> strange a bit.
Yes, the mapping data can be used.
> >
> > This way, we can have one platform level thermal file, which can support
> > multiple platforms (may be)using the same set of sensors (but)binded in a
> different way.
> > This file can get the platform thermal information through Firmware,
> > ACPI tables, device tree etc.
> >
> > Unfortunately, today we don't have many drivers that can be clearly
> differentiated
> > as 'sensor_file.c' and 'platform_thermal_file.c'. But very soon we will
> need/have.
> > The reason I am saying this is because we are seeing a lot of chip drivers,
> > starting to use thermal framework, and we should keep it really light-
> weight
> > for them to do so.
> >
> > An Example: drivers/hwmon/emc1403.c - a generic thermal chip driver
> > In one platform this sensor can belong to 'ZoneA' and in another the
> > same can belong to 'ZoneB'. But, emc1403.c does not really care about
> > where does it belong. It just reports temperature.
> > [Okay, I just picked an example, it doesn't register with framework,
> > as of today :-)]
> Clear about the above information.
Thank you :-)
> This is a good design, I believe more and more drivers will use this.
> But much efforts are needed.
Yes, we need quite some code modifications.
> >
> >>
> >> sensorA_file.c:
> >> if common_zone_for_AB not there;
> >> create common_zone_for_AB;
> >
> > This create_zone should not even be in sensorA_file.c.
> > It should be moved to platform level file.
> >
> >> add sensorA into common_zone_for_AB;
> >>
> >> sensorB_file.c:
> >> if common_zone_for_AB not there;
> >> create common_zone_for_AB;
> >> add sensorB into common_zone_for_AB;
> >>
> >
> > Same here..
> >
> >> But how to check dedicate thermal zone is created or not? we are
> >> lacking of this interface.
> >> Here are two ways to achieve this from my point of view:
> >> a)
> >> add interface get_thermal_zone_byname(const char *name) which will
> >> walk through the thermal_zone_list.
> >
> > However, (despite this problem we are talking about)
> > we can introduce this API, if needed.
> >
> >> b)
> >> add one more parameter for current interface, like this
> >> create_thermal_zone(const char *name, void *devdata, bool reuse)
> >> if reuse==ture {
> >> if thermal zone already created, return it;
> >> else create thermal zone;
> >> } else {
> >> if thermal zone already created, return error;
> >> else create thermal zone;
> >> }
> >>
> >> I prefer a), how do you think about it?
> >
> > I know I wrote a lengthy explanation. Let me know if it makes sense.
> > If it does, then probably I will add it to our Documentation file.
> Yes, It really makes sense.
> Thanks.
Okay, Then I am adding this to our Documentation file.
Thanks,
Durga
^ permalink raw reply
* [PATCH] cpufreq_stats: fix race between stats allocation and first usage
From: Konstantin Khlebnikov @ 2012-12-14 10:59 UTC (permalink / raw)
To: linux-kernel; +Cc: Rafael J. Wysocki, cpufreq, linux-pm
This patch forces complete struct cpufreq_stats allocation for all cpus before
registering CPUFREQ_TRANSITION_NOTIFIER notifier, otherwise in some conditions
cpufreq_stat_notifier_trans() can be called in the middle of stats allocation,
in this case cpufreq_stats_table already exists, but stat->freq_table is NULL.
Signed-off-by: Konstantin Khlebnikov <khlebnikov@openvz.org>
Cc: Rafael J. Wysocki <rjw@sisk.pl>
Cc: cpufreq <cpufreq@vger.kernel.org>
Cc: linux-pm <linux-pm@vger.kernel.org>
---
<1>[ 363.116198] BUG: unable to handle kernel NULL pointer dereference at (null)
<1>[ 363.116668] IP: [<ffffffffa11a70e4>] cpufreq_stat_notifier_trans+0x64/0xf0 [cpufreq_stats]
<4>[ 363.116977] PGD 23177e067 PUD 2349c1067 PMD 0
<4>[ 363.117151] Oops: 0000 [#1] SMP
<4>[ 363.117151] last sysfs file: /sys/module/freq_table/initstate
<4>[ 363.117151] CPU 5
<4>[ 363.117151] Modules linked in: cpufreq_stats(+)(U) [a lot] [last unloaded: umc]
<4>[ 363.117151]
<4>[ 363.117151] Pid: 1690, comm: kondemand/5 veid: 0 Tainted: P WC --------------- T 2.6.32-279.5.1.el6-042stab061.7-vz #112 042stab061_7 System manufacturer System Product Name/Crosshair IV Formula
<4>[ 363.117151] RIP: 0010:[<ffffffffa11a70e4>] [<ffffffffa11a70e4>] cpufreq_stat_notifier_trans+0x64/0xf0 [cpufreq_stats]
<4>[ 363.117151] RSP: 0018:ffff880234281920 EFLAGS: 00010246
<4>[ 363.117151] RAX: 00000000001e12e8 RBX: 0000000000000000 RCX: 00000000002ab980
<4>[ 363.117151] RDX: 0000000000000004 RSI: 0000000000000000 RDI: 0000000000000005
<4>[ 363.117151] RBP: ffff880234281940 R08: 0000000000000000 R09: 0000000000000000
<4>[ 363.117151] R10: 0000000000000000 R11: 2222222222222222 R12: ffff880218ce7400
<4>[ 363.117151] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
<4>[ 363.117151] FS: 00007f499ffe0700(0000) GS:ffff880031000000(0000) knlGS:0000000000000000
<4>[ 363.117151] CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
<4>[ 363.117151] CR2: 0000000000000000 CR3: 0000000230af7000 CR4: 00000000000006e0
<4>[ 363.117151] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
<4>[ 363.117151] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
<4>[ 363.117151] Process kondemand/5 (pid: 1690, veid: 0, threadinfo ffff880234280000, task ffff8802330c48c0)
<4>[ 363.117151] Stack:
<4>[ 363.117151] ffffffff810cf4f3 0000000000000001 00000000ffffffff ffffffffa11a7ac0
<4>[ 363.117151] <d> ffff880234281990 ffffffff815454a8 ffff880234281c80 0000000000000000
<4>[ 363.117151] <d> ffff880234281a10 ffffffff833be978 ffffffff833be8e0 0000000000000001
<4>[ 363.117151] Call Trace:
<4>[ 363.117151] [<ffffffff810cf4f3>] ? is_module_text_address+0x23/0x30
<4>[ 363.117151] [<ffffffff815454a8>] notifier_call_chain+0x58/0xb0
<4>[ 363.117151] [<ffffffff810a5a8d>] __srcu_notifier_call_chain+0x5d/0x90
<4>[ 363.117151] [<ffffffff810a5ad6>] srcu_notifier_call_chain+0x16/0x20
<4>[ 363.117151] [<ffffffff81442a0a>] cpufreq_notify_transition+0x12a/0x190
<4>[ 363.117151] [<ffffffffa026df08>] powernowk8_target+0x628/0xb30 [powernow_k8]
<4>[ 363.117151] [<ffffffff8144289b>] __cpufreq_driver_target+0x8b/0x90
<4>[ 363.117151] [<ffffffffa0279388>] do_dbs_timer+0x3b8/0x3bc [cpufreq_ondemand]
<4>[ 363.117151] [<ffffffffa0278fd0>] ? do_dbs_timer+0x0/0x3bc [cpufreq_ondemand]
<4>[ 363.117151] [<ffffffff81097df4>] worker_thread+0x264/0x440
<4>[ 363.117151] [<ffffffff81097da3>] ? worker_thread+0x213/0x440
<4>[ 363.117151] [<ffffffff81097b90>] ? worker_thread+0x0/0x440
<4>[ 363.117151] [<ffffffff8109f050>] ? autoremove_wake_function+0x0/0x40
<4>[ 363.117151] [<ffffffff81097b90>] ? worker_thread+0x0/0x440
<4>[ 363.117151] [<ffffffff8109e986>] kthread+0x96/0xa0
<4>[ 363.117151] [<ffffffff8100c34a>] child_rip+0xa/0x20
<4>[ 363.117151] [<ffffffff8100bc90>] ? restore_args+0x0/0x30
<4>[ 363.117151] [<ffffffff8109e8f0>] ? kthread+0x0/0xa0
<4>[ 363.117151] [<ffffffff8100c340>] ? child_rip+0x0/0x20
<4>[ 363.117151] Code: 89 f9 48 8b 0c cd 20 53 9c 81 4c 8b 24 08 4d 85 e4 74 d3 8b 4a 08 41 8b 54 24 10 45 8b 6c 24 18 85 d2 74 22 49 8b 74 24 28 31 db <3b> 0e 75 10 eb 1a 66 0f 1f 44 00 00 48 63 c3 3b 0c 86 74 0c 83
<1>[ 363.117151] RIP [<ffffffffa11a70e4>] cpufreq_stat_notifier_trans+0x64/0xf0 [cpufreq_stats]
<4>[ 363.117151] RSP <ffff880234281920>
<4>[ 363.117151] CR2: 0000000000000000
---
drivers/cpufreq/cpufreq_stats.c | 11 +++++++----
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/cpufreq/cpufreq_stats.c b/drivers/cpufreq/cpufreq_stats.c
index e40e508..9d7732b 100644
--- a/drivers/cpufreq/cpufreq_stats.c
+++ b/drivers/cpufreq/cpufreq_stats.c
@@ -364,18 +364,21 @@ static int __init cpufreq_stats_init(void)
if (ret)
return ret;
+ register_hotcpu_notifier(&cpufreq_stat_cpu_notifier);
+ for_each_online_cpu(cpu)
+ cpufreq_update_policy(cpu);
+
ret = cpufreq_register_notifier(¬ifier_trans_block,
CPUFREQ_TRANSITION_NOTIFIER);
if (ret) {
cpufreq_unregister_notifier(¬ifier_policy_block,
CPUFREQ_POLICY_NOTIFIER);
+ unregister_hotcpu_notifier(&cpufreq_stat_cpu_notifier);
+ for_each_online_cpu(cpu)
+ cpufreq_stats_free_table(cpu);
return ret;
}
- register_hotcpu_notifier(&cpufreq_stat_cpu_notifier);
- for_each_online_cpu(cpu) {
- cpufreq_update_policy(cpu);
- }
return 0;
}
static void __exit cpufreq_stats_exit(void)
^ permalink raw reply related
* [PATCH 0/2] Thermal sensor for Orion/Kirkwood
From: Andrew Lunn @ 2012-12-14 11:03 UTC (permalink / raw)
To: linux ARM, iwamatsu, linux-pm
Cc: Jason Cooper, Sebastian Hesselbarth, Thomas Petazzoni, jgunthorpe,
Andrew Lunn
This patchset adds thermal support for Orion Kirkwood devices, based
on code from Nobuhiro Iwamatsu. This provides a framework to later add
support for the thermal sensor on Dove.
The comments raised when the code was first posted have now been
addressed:
* Temperature Reading in milligrad
* marvel -> marvell
* generalized to Orion
* Compatibility string marvell,kirkwood-thermal
* Arithmetic using unsigned long
Nobuhiro Iwamatsu (2):
thermal: Add support for thermal sensor for Orion SoC
ARM: Kirkwood: Add support thermal sensor for 88F6282 and 88F6283
.../devicetree/bindings/thermal/orion-thermal.txt | 16 +++
arch/arm/boot/dts/kirkwood-6282.dtsi | 7 ++
arch/arm/configs/kirkwood_defconfig | 2 +
drivers/thermal/Kconfig | 7 ++
drivers/thermal/Makefile | 1 +
drivers/thermal/orion_thermal.c | 133 ++++++++++++++++++++
6 files changed, 166 insertions(+)
create mode 100644 Documentation/devicetree/bindings/thermal/orion-thermal.txt
create mode 100644 drivers/thermal/orion_thermal.c
--
1.7.10.4
^ permalink raw reply
* [PATCH 2/2] ARM: Kirkwood: Add support thermal sensor for 88F6282 and 88F6283
From: Andrew Lunn @ 2012-12-14 11:03 UTC (permalink / raw)
To: linux ARM, iwamatsu, linux-pm
Cc: Jason Cooper, Sebastian Hesselbarth, Thomas Petazzoni, jgunthorpe,
Andrew Lunn
In-Reply-To: <1355482986-885-1-git-send-email-andrew@lunn.ch>
From: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
88F6282 and 88F6283 has thermal sensor.
This patch enables DT and kernel config.
Signed-off-by: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
---
arch/arm/boot/dts/kirkwood-6282.dtsi | 7 +++++++
arch/arm/configs/kirkwood_defconfig | 2 ++
2 files changed, 9 insertions(+)
diff --git a/arch/arm/boot/dts/kirkwood-6282.dtsi b/arch/arm/boot/dts/kirkwood-6282.dtsi
index 9ae2004..28fe90b 100644
--- a/arch/arm/boot/dts/kirkwood-6282.dtsi
+++ b/arch/arm/boot/dts/kirkwood-6282.dtsi
@@ -32,6 +32,12 @@
};
};
+ thermal@10078 {
+ compatible = "marvell,kirkwood-thermal";
+ reg = <0x10078 0x4>;
+ status = "okay";
+ };
+
i2c@11100 {
compatible = "marvell,mv64xxx-i2c";
reg = <0x11100 0x20>;
@@ -41,5 +47,6 @@
clock-frequency = <100000>;
status = "disabled";
};
+
};
};
diff --git a/arch/arm/configs/kirkwood_defconfig b/arch/arm/configs/kirkwood_defconfig
index 93f3794..f9ce566 100644
--- a/arch/arm/configs/kirkwood_defconfig
+++ b/arch/arm/configs/kirkwood_defconfig
@@ -118,6 +118,8 @@ CONFIG_SPI=y
CONFIG_SPI_ORION=y
CONFIG_GPIO_SYSFS=y
# CONFIG_HWMON is not set
+CONFIG_THERMAL=y
+CONFIG_ORION_THERMAL=y
CONFIG_WATCHDOG=y
CONFIG_ORION_WATCHDOG=y
CONFIG_HID_DRAGONRISE=y
--
1.7.10.4
^ permalink raw reply related
* [PATCH 1/2] thermal: Add support for thermal sensor for Orion SoC
From: Andrew Lunn @ 2012-12-14 11:03 UTC (permalink / raw)
To: linux ARM, iwamatsu, linux-pm
Cc: Jason Cooper, Sebastian Hesselbarth, Thomas Petazzoni, jgunthorpe,
Andrew Lunn
In-Reply-To: <1355482986-885-1-git-send-email-andrew@lunn.ch>
From: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
Some Orion SoC has thermal sensor.
This patch adds support for 88F6282 and 88F6283.
Signed-off-by: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
---
.../devicetree/bindings/thermal/orion-thermal.txt | 16 +++
drivers/thermal/Kconfig | 7 ++
drivers/thermal/Makefile | 1 +
drivers/thermal/orion_thermal.c | 133 ++++++++++++++++++++
4 files changed, 157 insertions(+)
create mode 100644 Documentation/devicetree/bindings/thermal/orion-thermal.txt
create mode 100644 drivers/thermal/orion_thermal.c
diff --git a/Documentation/devicetree/bindings/thermal/orion-thermal.txt b/Documentation/devicetree/bindings/thermal/orion-thermal.txt
new file mode 100644
index 0000000..5ce925d
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/orion-thermal.txt
@@ -0,0 +1,16 @@
+* Orion Thermal
+
+This initial version is for Kirkwood 88F8262 & 88F6283 SoCs, however
+it is expected the driver will sometime in the future be expanded to
+also support Dove, using a different compatibility string.
+
+Required properties:
+- compatible : "marvell,kirkwood-thermal"
+- reg : Address range of the thermal registers
+
+Example:
+
+ thermal@10078 {
+ compatible = "marvell,kirkwood";
+ reg = <0x10078 0x4>;
+ };
diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index e1cb6bd..3bba13f 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -55,3 +55,10 @@ config EXYNOS_THERMAL
help
If you say yes here you get support for TMU (Thermal Managment
Unit) on SAMSUNG EXYNOS series of SoC.
+
+config ORION_THERMAL
+ tristate "Temperature sensor on Marvel Orion SoCs"
+ depends on PLAT_ORION && THERMAL
+ help
+ Support for the Orion thermal sensor driver into the Linux thermal
+ framework. This currently supports only 88F6282 and 88F6283.
diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
index 885550d..2fc64aa 100644
--- a/drivers/thermal/Makefile
+++ b/drivers/thermal/Makefile
@@ -6,4 +6,5 @@ obj-$(CONFIG_THERMAL) += thermal_sys.o
obj-$(CONFIG_CPU_THERMAL) += cpu_cooling.o
obj-$(CONFIG_SPEAR_THERMAL) += spear_thermal.o
obj-$(CONFIG_RCAR_THERMAL) += rcar_thermal.o
+obj-$(CONFIG_ORION_THERMAL) += orion_thermal.o
obj-$(CONFIG_EXYNOS_THERMAL) += exynos_thermal.o
diff --git a/drivers/thermal/orion_thermal.c b/drivers/thermal/orion_thermal.c
new file mode 100644
index 0000000..e8a2a68
--- /dev/null
+++ b/drivers/thermal/orion_thermal.c
@@ -0,0 +1,133 @@
+/*
+ * Orion thermal sensor driver
+ *
+ * Copyright (C) 2012 Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * 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/device.h>
+#include <linux/err.h>
+#include <linux/io.h>
+#include <linux/kernel.h>
+#include <linux/of.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/thermal.h>
+
+#define THERMAL_VALID_OFFSET 9
+#define THERMAL_VALID_MASK 0x1
+#define THERMAL_TEMP_OFFSET 10
+#define THERMAL_TEMP_MASK 0x1FF
+
+/* Orion Thermal Sensor Dev Structure */
+struct orion_thermal_dev {
+ void __iomem *base_addr;
+};
+
+static int orion_get_temp(struct thermal_zone_device *thermal,
+ unsigned long *temp)
+{
+ unsigned long reg;
+ struct orion_thermal_dev *thermal_dev = thermal->devdata;
+
+ reg = readl_relaxed(thermal_dev->base_addr);
+
+ /* Valid check */
+ if (!(reg >> THERMAL_VALID_OFFSET) & THERMAL_VALID_MASK) {
+ dev_info(&thermal->device,
+ "Temperature sensor reading not valid\n");
+ return -EIO;
+ }
+
+ reg = (reg >> THERMAL_TEMP_OFFSET) & THERMAL_TEMP_MASK;
+ /* Calculate temperature. See Table 814 in 8262 hardware manual. */
+ *temp = ((322UL - reg) * 10000UL * 1000UL) / 13625UL;
+
+ return 0;
+}
+
+static struct thermal_zone_device_ops ops = {
+ .get_temp = orion_get_temp,
+};
+
+static int orion_thermal_probe(struct platform_device *pdev)
+{
+ struct thermal_zone_device *thermal = NULL;
+ struct orion_thermal_dev *thermal_dev;
+ struct resource *res;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!res) {
+ dev_err(&pdev->dev, "Failed to get platform resource\n");
+ return -ENODEV;
+ }
+
+ thermal_dev = devm_kzalloc(&pdev->dev, sizeof(*thermal_dev),
+ GFP_KERNEL);
+ if (!thermal_dev) {
+ dev_err(&pdev->dev, "kzalloc fail\n");
+ return -ENOMEM;
+ }
+
+ thermal_dev->base_addr = devm_ioremap(&pdev->dev, res->start,
+ resource_size(res));
+ if (!thermal_dev->base_addr) {
+ dev_err(&pdev->dev, "Failed to ioremap memory\n");
+ return -ENOMEM;
+ }
+
+ thermal = thermal_zone_device_register("orion_thermal", 0, 0,
+ thermal_dev, &ops, 0, 0);
+ if (IS_ERR(thermal)) {
+ dev_err(&pdev->dev,
+ "Failed to register thermal zone device\n");
+ return PTR_ERR(thermal);
+ }
+
+ platform_set_drvdata(pdev, thermal);
+
+ dev_info(&thermal->device,
+ KBUILD_MODNAME ": Thermal sensor registered\n");
+
+ return 0;
+}
+
+static int orion_thermal_exit(struct platform_device *pdev)
+{
+ struct thermal_zone_device *orion_thermal = platform_get_drvdata(pdev);
+
+ thermal_zone_device_unregister(orion_thermal);
+ platform_set_drvdata(pdev, NULL);
+
+ return 0;
+}
+
+static const struct of_device_id orion_thermal_id_table[] = {
+ { .compatible = "marvell,kirkwood-thermal" },
+ {}
+};
+MODULE_DEVICE_TABLE(of, orion_thermal_id_table);
+
+static struct platform_driver orion_thermal_driver = {
+ .probe = orion_thermal_probe,
+ .remove = orion_thermal_exit,
+ .driver = {
+ .name = "orion_thermal",
+ .owner = THIS_MODULE,
+ .of_match_table = of_match_ptr(orion_thermal_id_table),
+ },
+};
+
+module_platform_driver(orion_thermal_driver);
+
+MODULE_AUTHOR("Nobuhiro Iwamatsu <iwamatsu@nigauri.org>");
+MODULE_DESCRIPTION("orion thermal driver");
+MODULE_LICENSE("GPL");
--
1.7.10.4
^ permalink raw reply related
* RE: [PATCH 1/2] thermal: Add support for thermal sensor for Orion SoC
From: R, Durgadoss @ 2012-12-14 11:30 UTC (permalink / raw)
To: Andrew Lunn, linux ARM, iwamatsu@nigauri.org,
linux-pm@vger.kernel.org
Cc: Jason Cooper, Sebastian Hesselbarth, Thomas Petazzoni,
jgunthorpe@obsidianresearch.com
In-Reply-To: <1355482986-885-2-git-send-email-andrew@lunn.ch>
> -----Original Message-----
> From: linux-pm-owner@vger.kernel.org [mailto:linux-pm-
> owner@vger.kernel.org] On Behalf Of Andrew Lunn
> Sent: Friday, December 14, 2012 4:33 PM
> To: linux ARM; iwamatsu@nigauri.org; linux-pm@vger.kernel.org
> Cc: Jason Cooper; Sebastian Hesselbarth; Thomas Petazzoni;
> jgunthorpe@obsidianresearch.com; Andrew Lunn
> Subject: [PATCH 1/2] thermal: Add support for thermal sensor for Orion SoC
>
> From: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
>
> Some Orion SoC has thermal sensor.
> This patch adds support for 88F6282 and 88F6283.
>
> Signed-off-by: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
> Signed-off-by: Andrew Lunn <andrew@lunn.ch>
> ---
> .../devicetree/bindings/thermal/orion-thermal.txt | 16 +++
> drivers/thermal/Kconfig | 7 ++
> drivers/thermal/Makefile | 1 +
> drivers/thermal/orion_thermal.c | 133 ++++++++++++++++++++
> 4 files changed, 157 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/thermal/orion-
> thermal.txt
> create mode 100644 drivers/thermal/orion_thermal.c
>
> diff --git a/Documentation/devicetree/bindings/thermal/orion-thermal.txt
> b/Documentation/devicetree/bindings/thermal/orion-thermal.txt
> new file mode 100644
> index 0000000..5ce925d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/thermal/orion-thermal.txt
> @@ -0,0 +1,16 @@
> +* Orion Thermal
> +
> +This initial version is for Kirkwood 88F8262 & 88F6283 SoCs, however
> +it is expected the driver will sometime in the future be expanded to
> +also support Dove, using a different compatibility string.
> +
> +Required properties:
> +- compatible : "marvell,kirkwood-thermal"
> +- reg : Address range of the thermal registers
> +
> +Example:
> +
> + thermal@10078 {
> + compatible = "marvell,kirkwood";
> + reg = <0x10078 0x4>;
> + };
> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
> index e1cb6bd..3bba13f 100644
> --- a/drivers/thermal/Kconfig
> +++ b/drivers/thermal/Kconfig
> @@ -55,3 +55,10 @@ config EXYNOS_THERMAL
> help
> If you say yes here you get support for TMU (Thermal Managment
> Unit) on SAMSUNG EXYNOS series of SoC.
> +
> +config ORION_THERMAL
> + tristate "Temperature sensor on Marvel Orion SoCs"
> + depends on PLAT_ORION && THERMAL
On what tree is this patch set based on ?
Rui's -next tree ?
If not, it would better if you could rebase it on top of that.
If it is, then you don't need '&& THERMAL' in Kconfig.
> + help
> + Support for the Orion thermal sensor driver into the Linux thermal
> + framework. This currently supports only 88F6282 and 88F6283.
> diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
> index 885550d..2fc64aa 100644
> --- a/drivers/thermal/Makefile
> +++ b/drivers/thermal/Makefile
> @@ -6,4 +6,5 @@ obj-$(CONFIG_THERMAL) += thermal_sys.o
> obj-$(CONFIG_CPU_THERMAL) += cpu_cooling.o
> obj-$(CONFIG_SPEAR_THERMAL) += spear_thermal.o
> obj-$(CONFIG_RCAR_THERMAL) += rcar_thermal.o
> +obj-$(CONFIG_ORION_THERMAL) += orion_thermal.o
> obj-$(CONFIG_EXYNOS_THERMAL) += exynos_thermal.o
> diff --git a/drivers/thermal/orion_thermal.c
> b/drivers/thermal/orion_thermal.c
> new file mode 100644
> index 0000000..e8a2a68
> --- /dev/null
> +++ b/drivers/thermal/orion_thermal.c
> @@ -0,0 +1,133 @@
> +/*
> + * Orion thermal sensor driver
> + *
> + * Copyright (C) 2012 Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
> + *
> + * This software is licensed under the terms of the GNU General Public
> + * License version 2, as published by the Free Software Foundation, and
> + * may be copied, distributed, and modified under those terms.
> + *
> + * 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/device.h>
> +#include <linux/err.h>
> +#include <linux/io.h>
> +#include <linux/kernel.h>
> +#include <linux/of.h>
> +#include <linux/module.h>
> +#include <linux/platform_device.h>
> +#include <linux/thermal.h>
> +
> +#define THERMAL_VALID_OFFSET 9
> +#define THERMAL_VALID_MASK 0x1
> +#define THERMAL_TEMP_OFFSET 10
> +#define THERMAL_TEMP_MASK 0x1FF
> +
> +/* Orion Thermal Sensor Dev Structure */
> +struct orion_thermal_dev {
> + void __iomem *base_addr;
> +};
> +
> +static int orion_get_temp(struct thermal_zone_device *thermal,
> + unsigned long *temp)
> +{
> + unsigned long reg;
> + struct orion_thermal_dev *thermal_dev = thermal->devdata;
> +
> + reg = readl_relaxed(thermal_dev->base_addr);
> +
> + /* Valid check */
> + if (!(reg >> THERMAL_VALID_OFFSET) & THERMAL_VALID_MASK) {
> + dev_info(&thermal->device,
> + "Temperature sensor reading not valid\n");
> + return -EIO;
> + }
> +
> + reg = (reg >> THERMAL_TEMP_OFFSET) & THERMAL_TEMP_MASK;
> + /* Calculate temperature. See Table 814 in 8262 hardware manual. */
Thanks for the comment.
Can we move this comment one line above ? like below:
/* comment */
reg =
*temp =
increases readability.
BTW, is this datasheet public ?
If so, could you please add the link to the datasheet at the top ?
> + *temp = ((322UL - reg) * 10000UL * 1000UL) / 13625UL;
> +
> + return 0;
> +}
> +
> +static struct thermal_zone_device_ops ops = {
> + .get_temp = orion_get_temp,
> +};
> +
> +static int orion_thermal_probe(struct platform_device *pdev)
> +{
> + struct thermal_zone_device *thermal = NULL;
> + struct orion_thermal_dev *thermal_dev;
> + struct resource *res;
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + if (!res) {
> + dev_err(&pdev->dev, "Failed to get platform resource\n");
> + return -ENODEV;
> + }
> +
> + thermal_dev = devm_kzalloc(&pdev->dev, sizeof(*thermal_dev),
> + GFP_KERNEL);
> + if (!thermal_dev) {
> + dev_err(&pdev->dev, "kzalloc fail\n");
> + return -ENOMEM;
> + }
> +
> + thermal_dev->base_addr = devm_ioremap(&pdev->dev, res->start,
> + resource_size(res));
> + if (!thermal_dev->base_addr) {
> + dev_err(&pdev->dev, "Failed to ioremap memory\n");
> + return -ENOMEM;
> + }
> +
> + thermal = thermal_zone_device_register("orion_thermal", 0, 0,
> + thermal_dev, &ops, 0, 0);
> + if (IS_ERR(thermal)) {
> + dev_err(&pdev->dev,
> + "Failed to register thermal zone device\n");
Don't we have to free ioremap resource ? Or devm_ takes care of that ?
please educate me :-)
> + return PTR_ERR(thermal);
> + }
> +
> + platform_set_drvdata(pdev, thermal);
> +
> + dev_info(&thermal->device,
> + KBUILD_MODNAME ": Thermal sensor registered\n");
> +
> + return 0;
> +}
> +
> +static int orion_thermal_exit(struct platform_device *pdev)
> +{
> + struct thermal_zone_device *orion_thermal =
> platform_get_drvdata(pdev);
> +
> + thermal_zone_device_unregister(orion_thermal);
> + platform_set_drvdata(pdev, NULL);
> +
> + return 0;
> +}
> +
> +static const struct of_device_id orion_thermal_id_table[] = {
> + { .compatible = "marvell,kirkwood-thermal" },
> + {}
> +};
> +MODULE_DEVICE_TABLE(of, orion_thermal_id_table);
> +
> +static struct platform_driver orion_thermal_driver = {
> + .probe = orion_thermal_probe,
> + .remove = orion_thermal_exit,
> + .driver = {
> + .name = "orion_thermal",
> + .owner = THIS_MODULE,
> + .of_match_table = of_match_ptr(orion_thermal_id_table),
> + },
> +};
> +
> +module_platform_driver(orion_thermal_driver);
> +
> +MODULE_AUTHOR("Nobuhiro Iwamatsu <iwamatsu@nigauri.org>");
> +MODULE_DESCRIPTION("orion thermal driver");
> +MODULE_LICENSE("GPL");
> --
> 1.7.10.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pm" 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: [PATCH 1/2] thermal: Add support for thermal sensor for Orion SoC
From: Andrew Lunn @ 2012-12-14 11:50 UTC (permalink / raw)
To: R, Durgadoss
Cc: Andrew Lunn, linux ARM, iwamatsu@nigauri.org,
linux-pm@vger.kernel.org, Jason Cooper, Sebastian Hesselbarth,
Thomas Petazzoni, jgunthorpe@obsidianresearch.com
In-Reply-To: <4D68720C2E767A4AA6A8796D42C8EB59249564@BGSMSX101.gar.corp.intel.com>
On Fri, Dec 14, 2012 at 11:30:41AM +0000, R, Durgadoss wrote:
> > -----Original Message-----
> > From: linux-pm-owner@vger.kernel.org [mailto:linux-pm-
> > owner@vger.kernel.org] On Behalf Of Andrew Lunn
> > Sent: Friday, December 14, 2012 4:33 PM
> > To: linux ARM; iwamatsu@nigauri.org; linux-pm@vger.kernel.org
> > Cc: Jason Cooper; Sebastian Hesselbarth; Thomas Petazzoni;
> > jgunthorpe@obsidianresearch.com; Andrew Lunn
> > Subject: [PATCH 1/2] thermal: Add support for thermal sensor for Orion SoC
> >
> > From: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
> >
> > Some Orion SoC has thermal sensor.
> > This patch adds support for 88F6282 and 88F6283.
> >
> > Signed-off-by: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
> > Signed-off-by: Andrew Lunn <andrew@lunn.ch>
> > ---
> > .../devicetree/bindings/thermal/orion-thermal.txt | 16 +++
> > drivers/thermal/Kconfig | 7 ++
> > drivers/thermal/Makefile | 1 +
> > drivers/thermal/orion_thermal.c | 133 ++++++++++++++++++++
> > 4 files changed, 157 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/thermal/orion-
> > thermal.txt
> > create mode 100644 drivers/thermal/orion_thermal.c
> >
> > diff --git a/Documentation/devicetree/bindings/thermal/orion-thermal.txt
> > b/Documentation/devicetree/bindings/thermal/orion-thermal.txt
> > new file mode 100644
> > index 0000000..5ce925d
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/thermal/orion-thermal.txt
> > @@ -0,0 +1,16 @@
> > +* Orion Thermal
> > +
> > +This initial version is for Kirkwood 88F8262 & 88F6283 SoCs, however
> > +it is expected the driver will sometime in the future be expanded to
> > +also support Dove, using a different compatibility string.
> > +
> > +Required properties:
> > +- compatible : "marvell,kirkwood-thermal"
> > +- reg : Address range of the thermal registers
> > +
> > +Example:
> > +
> > + thermal@10078 {
> > + compatible = "marvell,kirkwood";
> > + reg = <0x10078 0x4>;
> > + };
> > diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
> > index e1cb6bd..3bba13f 100644
> > --- a/drivers/thermal/Kconfig
> > +++ b/drivers/thermal/Kconfig
> > @@ -55,3 +55,10 @@ config EXYNOS_THERMAL
> > help
> > If you say yes here you get support for TMU (Thermal Managment
> > Unit) on SAMSUNG EXYNOS series of SoC.
> > +
> > +config ORION_THERMAL
> > + tristate "Temperature sensor on Marvel Orion SoCs"
> > + depends on PLAT_ORION && THERMAL
>
> On what tree is this patch set based on ?
Not a good one. arm-soc/for-next
I posted these patches to let other know i'm working in the driver and
to get further feedback. I've also started on adding support for Dove,
which is similar, but different.
It will get rebased onto -rc1 in a couple of weeks time and by then i
hope i will have Dove support.
> If it is, then you don't need '&& THERMAL' in Kconfig.
> > + reg = (reg >> THERMAL_TEMP_OFFSET) & THERMAL_TEMP_MASK;
> > + /* Calculate temperature. See Table 814 in 8262 hardware manual. */
>
> Thanks for the comment.
> Can we move this comment one line above ? like below:
>
> /* comment */
> reg =
> *temp =
Sure.
> BTW, is this datasheet public ?
Humm, think so. Take a look at Documentation/arm/Marvell/REAMDE. I
will check and add a reference to this README file and the specific
datasheet.
> If so, could you please add the link to the datasheet at the top ?
>
> > + *temp = ((322UL - reg) * 10000UL * 1000UL) / 13625UL;
> > +
> > + return 0;
> > +}
> > +
> > +static struct thermal_zone_device_ops ops = {
> > + .get_temp = orion_get_temp,
> > +};
> > +
> > +static int orion_thermal_probe(struct platform_device *pdev)
> > +{
> > + struct thermal_zone_device *thermal = NULL;
> > + struct orion_thermal_dev *thermal_dev;
> > + struct resource *res;
> > +
> > + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > + if (!res) {
> > + dev_err(&pdev->dev, "Failed to get platform resource\n");
> > + return -ENODEV;
> > + }
> > +
> > + thermal_dev = devm_kzalloc(&pdev->dev, sizeof(*thermal_dev),
> > + GFP_KERNEL);
> > + if (!thermal_dev) {
> > + dev_err(&pdev->dev, "kzalloc fail\n");
> > + return -ENOMEM;
> > + }
> > +
> > + thermal_dev->base_addr = devm_ioremap(&pdev->dev, res->start,
> > + resource_size(res));
> > + if (!thermal_dev->base_addr) {
> > + dev_err(&pdev->dev, "Failed to ioremap memory\n");
> > + return -ENOMEM;
> > + }
> > +
> > + thermal = thermal_zone_device_register("orion_thermal", 0, 0,
> > + thermal_dev, &ops, 0, 0);
> > + if (IS_ERR(thermal)) {
> > + dev_err(&pdev->dev,
> > + "Failed to register thermal zone device\n");
>
> Don't we have to free ioremap resource ? Or devm_ takes care of that ?
> please educate me :-)
devm_ should take care of that. If the probe function returns an
error, or the driver is unloaded, all resources allocated with devm_
get automagically freed.
Andrew
^ permalink raw reply
* [PATCH 1/2] cpuidle: fix finding state with min power_usage
From: Sivaram Nair @ 2012-12-14 13:17 UTC (permalink / raw)
To: rafael.j.wysocki, len.brown, daniel.lezcano, khilman, ccross,
riel, youquan.song, akpm, shuox.liu
Cc: linux-pm, Sivaram Nair, linux-kernel
Since cpuidle_state.power_usage is a signed value, use INT_MAX (instead
of -1) to init the local copies so that functions that tries to find
cpuidle states with minimum power usage works correctly even if they use
non-negative values.
Signed-off-by: Sivaram Nair <sivaramn@nvidia.com>
---
drivers/cpuidle/cpuidle.c | 2 +-
| 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/cpuidle/cpuidle.c b/drivers/cpuidle/cpuidle.c
index 8df53dd..fb4a7dd 100644
--- a/drivers/cpuidle/cpuidle.c
+++ b/drivers/cpuidle/cpuidle.c
@@ -70,7 +70,7 @@ int cpuidle_play_dead(void)
struct cpuidle_device *dev = __this_cpu_read(cpuidle_devices);
struct cpuidle_driver *drv = cpuidle_get_cpu_driver(dev);
int i, dead_state = -1;
- int power_usage = -1;
+ int power_usage = INT_MAX;
if (!drv)
return -ENODEV;
--git a/drivers/cpuidle/governors/menu.c b/drivers/cpuidle/governors/menu.c
index bd40b94..20ea33a 100644
--- a/drivers/cpuidle/governors/menu.c
+++ b/drivers/cpuidle/governors/menu.c
@@ -312,7 +312,7 @@ static int menu_select(struct cpuidle_driver *drv, struct cpuidle_device *dev)
{
struct menu_device *data = &__get_cpu_var(menu_devices);
int latency_req = pm_qos_request(PM_QOS_CPU_DMA_LATENCY);
- int power_usage = -1;
+ int power_usage = INT_MAX;
int i;
int multiplier;
struct timespec t;
--
1.7.9.5
^ permalink raw reply related
* [PATCH 2/2] cpuidle: fix sysfs output for power_usage
From: Sivaram Nair @ 2012-12-14 13:17 UTC (permalink / raw)
To: rafael.j.wysocki, daniel.lezcano, shuox.liu, akpm, yanmin_zhang
Cc: linux-pm, Sivaram Nair, linux-kernel
In-Reply-To: <1355491060-970-1-git-send-email-sivaramn@nvidia.com>
cpuidle_state->power_usage is signed; so change the corresponding sysfs
ops to output signed value instead of unsigned.
Signed-off-by: Sivaram Nair <sivaramn@nvidia.com>
---
drivers/cpuidle/sysfs.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/cpuidle/sysfs.c b/drivers/cpuidle/sysfs.c
index 3409429..2fc79cd 100644
--- a/drivers/cpuidle/sysfs.c
+++ b/drivers/cpuidle/sysfs.c
@@ -232,6 +232,13 @@ static struct cpuidle_state_attr attr_##_name = __ATTR(_name, 0644, show, store)
static ssize_t show_state_##_name(struct cpuidle_state *state, \
struct cpuidle_state_usage *state_usage, char *buf) \
{ \
+ return sprintf(buf, "%d\n", state->_name);\
+}
+
+#define define_show_state_u_function(_name) \
+static ssize_t show_state_##_name(struct cpuidle_state *state, \
+ struct cpuidle_state_usage *state_usage, char *buf) \
+{ \
return sprintf(buf, "%u\n", state->_name);\
}
@@ -270,7 +277,7 @@ static ssize_t show_state_##_name(struct cpuidle_state *state, \
return sprintf(buf, "%s\n", state->_name);\
}
-define_show_state_function(exit_latency)
+define_show_state_u_function(exit_latency)
define_show_state_function(power_usage)
define_show_state_ull_function(usage)
define_show_state_ull_function(time)
--
1.7.9.5
^ permalink raw reply related
* [PATCH 0/2][V2] cpuidle - remove power from the select equation
From: Daniel Lezcano @ 2012-12-14 13:57 UTC (permalink / raw)
To: rjw-KKrjLPT3xs0
Cc: deepthi-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8,
g.trinabh-Re5JQEeQqe8AvxtiuMwx3w,
linaro-dev-cunTk1MwBs8s++Sfvej+rw,
len.brown-ral2JQCrhuEAvxtiuMwx3w, linux-pm-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
jwerner-F7+t8E8rja9g9hUCZPvPmw,
akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
snanda-F7+t8E8rja9g9hUCZPvPmw
The states could be sorted in the power backward order, we get rid of
some lines of code and by this way that fixes also a bug in the dynamic
c-states.
Changelog:
V2:
* added the optimization in the select menu governor
Daniel Lezcano (2):
cpuidle - remove the power_specified field in the driver
cpuidle - optimize the select function for the 'menu' governor
drivers/cpuidle/cpuidle.c | 17 ++++-------------
drivers/cpuidle/driver.c | 25 -------------------------
drivers/cpuidle/governors/menu.c | 20 ++++++++------------
include/linux/cpuidle.h | 2 +-
4 files changed, 13 insertions(+), 51 deletions(-)
--
1.7.5.4
^ permalink raw reply
* [PATCH 1/2][V2] cpuidle - remove the power_specified field in the driver
From: Daniel Lezcano @ 2012-12-14 13:57 UTC (permalink / raw)
To: rjw-KKrjLPT3xs0
Cc: deepthi-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8,
g.trinabh-Re5JQEeQqe8AvxtiuMwx3w,
linaro-dev-cunTk1MwBs8s++Sfvej+rw,
len.brown-ral2JQCrhuEAvxtiuMwx3w, linux-pm-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
jwerner-F7+t8E8rja9g9hUCZPvPmw,
akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
snanda-F7+t8E8rja9g9hUCZPvPmw
In-Reply-To: <1355493455-30665-1-git-send-email-daniel.lezcano-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
This patch follows the discussion about reinitializing the power usage
when a C-state is added/removed.
https://lkml.org/lkml/2012/10/16/518
We realized the power usage field is never filled and when it is
filled for tegra, the power_specified flag is not set making all these
values to be resetted when the driver is initialized with the set_power_state
function.
Julius and I feel this is over-engineered and the power_specified
flag could be simply removed and continue assuming the states are
backward sorted.
The menu governor select function is simplified as the power is ordered.
Actually the condition is always true with the current code.
The cpuidle_play_dead function is also simplified by doing a reverse lookup
on the array.
The set_power_states function is removed as it does no make sense anymore.
As a consequence, this patch fix also the bug where on the dynamic C-state
system, the power fields is not initialized.
Signed-off-by: Daniel Lezcano <daniel.lezcano-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Cc: Julius Werner <jwerner-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
---
drivers/cpuidle/cpuidle.c | 17 ++++-------------
drivers/cpuidle/driver.c | 25 -------------------------
| 8 ++------
include/linux/cpuidle.h | 2 +-
4 files changed, 7 insertions(+), 45 deletions(-)
diff --git a/drivers/cpuidle/cpuidle.c b/drivers/cpuidle/cpuidle.c
index 8df53dd..e1f6860 100644
--- a/drivers/cpuidle/cpuidle.c
+++ b/drivers/cpuidle/cpuidle.c
@@ -69,24 +69,15 @@ int cpuidle_play_dead(void)
{
struct cpuidle_device *dev = __this_cpu_read(cpuidle_devices);
struct cpuidle_driver *drv = cpuidle_get_cpu_driver(dev);
- int i, dead_state = -1;
- int power_usage = -1;
+ int i;
if (!drv)
return -ENODEV;
/* Find lowest-power state that supports long-term idle */
- for (i = CPUIDLE_DRIVER_STATE_START; i < drv->state_count; i++) {
- struct cpuidle_state *s = &drv->states[i];
-
- if (s->power_usage < power_usage && s->enter_dead) {
- power_usage = s->power_usage;
- dead_state = i;
- }
- }
-
- if (dead_state != -1)
- return drv->states[dead_state].enter_dead(dev, dead_state);
+ for (i = drv->state_count - 1; i >= CPUIDLE_DRIVER_STATE_START; i--)
+ if (drv->states[i].enter_dead)
+ return drv->states[i].enter_dead(dev, i);
return -ENODEV;
}
diff --git a/drivers/cpuidle/driver.c b/drivers/cpuidle/driver.c
index 3af841f..bb045f1 100644
--- a/drivers/cpuidle/driver.c
+++ b/drivers/cpuidle/driver.c
@@ -19,34 +19,9 @@ DEFINE_SPINLOCK(cpuidle_driver_lock);
static void __cpuidle_set_cpu_driver(struct cpuidle_driver *drv, int cpu);
static struct cpuidle_driver * __cpuidle_get_cpu_driver(int cpu);
-static void set_power_states(struct cpuidle_driver *drv)
-{
- int i;
-
- /*
- * cpuidle driver should set the drv->power_specified bit
- * before registering if the driver provides
- * power_usage numbers.
- *
- * If power_specified is not set,
- * we fill in power_usage with decreasing values as the
- * cpuidle code has an implicit assumption that state Cn
- * uses less power than C(n-1).
- *
- * With CONFIG_ARCH_HAS_CPU_RELAX, C0 is already assigned
- * an power value of -1. So we use -2, -3, etc, for other
- * c-states.
- */
- for (i = CPUIDLE_DRIVER_STATE_START; i < drv->state_count; i++)
- drv->states[i].power_usage = -1 - i;
-}
-
static void __cpuidle_driver_init(struct cpuidle_driver *drv)
{
drv->refcnt = 0;
-
- if (!drv->power_specified)
- set_power_states(drv);
}
static int __cpuidle_register_driver(struct cpuidle_driver *drv, int cpu)
--git a/drivers/cpuidle/governors/menu.c b/drivers/cpuidle/governors/menu.c
index bd40b94..fe343a0 100644
--- a/drivers/cpuidle/governors/menu.c
+++ b/drivers/cpuidle/governors/menu.c
@@ -312,7 +312,6 @@ static int menu_select(struct cpuidle_driver *drv, struct cpuidle_device *dev)
{
struct menu_device *data = &__get_cpu_var(menu_devices);
int latency_req = pm_qos_request(PM_QOS_CPU_DMA_LATENCY);
- int power_usage = -1;
int i;
int multiplier;
struct timespec t;
@@ -383,11 +382,8 @@ static int menu_select(struct cpuidle_driver *drv, struct cpuidle_device *dev)
if (s->exit_latency * multiplier > data->predicted_us)
continue;
- if (s->power_usage < power_usage) {
- power_usage = s->power_usage;
- data->last_state_idx = i;
- data->exit_us = s->exit_latency;
- }
+ data->last_state_idx = i;
+ data->exit_us = s->exit_latency;
}
/* not deepest C-state chosen for low predicted residency */
diff --git a/include/linux/cpuidle.h b/include/linux/cpuidle.h
index 3711b34..24cd103 100644
--- a/include/linux/cpuidle.h
+++ b/include/linux/cpuidle.h
@@ -126,9 +126,9 @@ struct cpuidle_driver {
struct module *owner;
int refcnt;
- unsigned int power_specified:1;
/* set to 1 to use the core cpuidle time keeping (for all states). */
unsigned int en_core_tk_irqen:1;
+ /* states array must be ordered in decreasing power consumption */
struct cpuidle_state states[CPUIDLE_STATE_MAX];
int state_count;
int safe_state_index;
--
1.7.5.4
^ permalink raw reply related
* [PATCH 2/2][V2] cpuidle - optimize the select function for the 'menu' governor
From: Daniel Lezcano @ 2012-12-14 13:57 UTC (permalink / raw)
To: rjw-KKrjLPT3xs0
Cc: deepthi-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8,
g.trinabh-Re5JQEeQqe8AvxtiuMwx3w,
linaro-dev-cunTk1MwBs8s++Sfvej+rw,
len.brown-ral2JQCrhuEAvxtiuMwx3w, linux-pm-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
jwerner-F7+t8E8rja9g9hUCZPvPmw,
akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
snanda-F7+t8E8rja9g9hUCZPvPmw
In-Reply-To: <1355493455-30665-1-git-send-email-daniel.lezcano-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
As the power is backward sorted in the states array and we are looking for
the state consuming the little power as possible, instead of looking from
the beginning of the array, we look from the end. That should save us some
iterations in the loop each time we select a state at idle time.
Signed-off-by: Daniel Lezcano <daniel.lezcano-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
---
| 12 ++++++------
1 files changed, 6 insertions(+), 6 deletions(-)
--git a/drivers/cpuidle/governors/menu.c b/drivers/cpuidle/governors/menu.c
index fe343a0..05b8998 100644
--- a/drivers/cpuidle/governors/menu.c
+++ b/drivers/cpuidle/governors/menu.c
@@ -367,24 +367,24 @@ static int menu_select(struct cpuidle_driver *drv, struct cpuidle_device *dev)
* Find the idle state with the lowest power while satisfying
* our constraints.
*/
- for (i = CPUIDLE_DRIVER_STATE_START; i < drv->state_count; i++) {
+ for (i = drv->state_count - 1; i >= CPUIDLE_DRIVER_STATE_START; i--) {
struct cpuidle_state *s = &drv->states[i];
struct cpuidle_state_usage *su = &dev->states_usage[i];
if (s->disabled || su->disable)
continue;
- if (s->target_residency > data->predicted_us) {
- low_predicted = 1;
- continue;
- }
if (s->exit_latency > latency_req)
continue;
+ if (s->target_residency > data->predicted_us)
+ continue;
if (s->exit_latency * multiplier > data->predicted_us)
continue;
+ low_predicted = i - CPUIDLE_DRIVER_STATE_START;
data->last_state_idx = i;
data->exit_us = s->exit_latency;
- }
+ break;
+ }
/* not deepest C-state chosen for low predicted residency */
if (low_predicted) {
--
1.7.5.4
^ permalink raw reply related
* Re: [PATCH 1/2] cpuidle: fix finding state with min power_usage
From: Rik van Riel @ 2012-12-14 17:43 UTC (permalink / raw)
To: Sivaram Nair
Cc: rafael.j.wysocki, len.brown, daniel.lezcano, khilman, ccross,
youquan.song, akpm, shuox.liu, linux-pm, linux-kernel
In-Reply-To: <1355491060-970-1-git-send-email-sivaramn@nvidia.com>
On 12/14/2012 08:17 AM, Sivaram Nair wrote:
> Since cpuidle_state.power_usage is a signed value, use INT_MAX (instead
> of -1) to init the local copies so that functions that tries to find
> cpuidle states with minimum power usage works correctly even if they use
> non-negative values.
>
> Signed-off-by: Sivaram Nair <sivaramn@nvidia.com>
Reviewed-by: Rik van Riel <riel@redhat.com>
--
All rights reversed
^ permalink raw reply
* Re: [RFC PATCH v4 1/9] CPU hotplug: Provide APIs to prevent CPU offline from atomic context
From: Oleg Nesterov @ 2012-12-14 18:03 UTC (permalink / raw)
To: Srivatsa S. Bhat
Cc: tglx, peterz, paulmck, rusty, mingo, akpm, namhyung,
vincent.guittot, tj, sbw, amit.kucheria, rostedt, rjw, wangyun,
xiaoguangrong, nikunj, linux-pm, linux-kernel
In-Reply-To: <50CA0317.90501@linux.vnet.ibm.com>
On 12/13, Srivatsa S. Bhat wrote:
>
> On 12/13/2012 09:47 PM, Oleg Nesterov wrote:
> > On 12/13, Srivatsa S. Bhat wrote:
> >>
> >> On 12/13/2012 12:42 AM, Srivatsa S. Bhat wrote:
> >>>
> >>> Even I don't spot anything wrong with it. But I'll give it some more
> >>> thought..
> >>
> >> Since an interrupt handler can also run get_online_cpus_atomic(), we
> >> cannot use the __this_cpu_* versions for modifying reader_percpu_refcnt,
> >> right?
> >
> > Hmm. I thought that __this_cpu_* must be safe under preempt_disable().
> > IOW, I thought that, say, this_cpu_inc() is "equal" to preempt_disable +
> > __this_cpu_inc() correctness-wise.
> >
> > And. I thought that this_cpu_inc() is safe wrt interrupt, like local_t.
> >
> > But when I try to read the comments percpu.h, I am starting to think that
> > even this_cpu_inc() is not safe if irq handler can do the same?
> >
>
> The comment seems to say that its not safe wrt interrupts. But looking at
> the code in include/linux/percpu.h, IIUC, that is true only about
> this_cpu_read() because it only disables preemption.
>
> However, this_cpu_inc() looks safe wrt interrupts because it wraps the
> increment within raw_local_irqsave()/restore().
You mean _this_cpu_generic_to_op() I guess. So yes, I think you are right,
this_cpu_* should be irq-safe, but __this_cpu_* is not.
Thanks.
At least on x86 there is no difference between this_ and __this_, both do
percpu_add_op() without local_irq_disable/enable. But it seems that most
of architectures use generic code.
Oleg.
^ permalink raw reply
* Re: [PATCH 1/2] thermal: Add support for thermal sensor for Orion SoC
From: Jason Gunthorpe @ 2012-12-14 18:13 UTC (permalink / raw)
To: Andrew Lunn
Cc: linux ARM, iwamatsu, linux-pm, Jason Cooper,
Sebastian Hesselbarth, Thomas Petazzoni
In-Reply-To: <1355482986-885-2-git-send-email-andrew@lunn.ch>
On Fri, Dec 14, 2012 at 12:03:05PM +0100, Andrew Lunn wrote:
> From: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
>
> Some Orion SoC has thermal sensor.
> This patch adds support for 88F6282 and 88F6283.
>
> Signed-off-by: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
> Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Tested-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
^ permalink raw reply
* "Unknown header type 7f" after wakeup
From: tim @ 2012-12-14 20:01 UTC (permalink / raw)
To: linux-pm
hi all,
i'm having some troubles with my RME hdsp audio interface after waking
up my machine:
lspci tells me:
04:01.0 Multimedia audio controller: Xilinx Corporation RME Hammerfall
DSP (rev ff) (prog-if ff)
!!! Unknown header type 7f
Kernel modules: snd-hdsp
all other devices work fine ... rmmod/modprobe of the specific module
doesn't help, either ... iac, it somehow seems that the PCI device state
is not properly restored, maybe because the fpga on the device is too
slow ... how can i help in fixing this issue?
tia,
tim
^ permalink raw reply
* Re: [PATCH 1/2] thermal: Add support for thermal sensor for Kirkwood SoC
From: Nobuhiro Iwamatsu @ 2012-12-14 21:22 UTC (permalink / raw)
To: Jason Gunthorpe; +Cc: linux-pm, rui.zhang, jason, linux-arm-kernel
In-Reply-To: <20121207235904.GA15078@obsidianresearch.com>
On Sat, Dec 8, 2012 at 8:59 AM, Jason Gunthorpe
<jgunthorpe@obsidianresearch.com> wrote:
> On Fri, Dec 07, 2012 at 04:24:59PM -0700, Jason Gunthorpe wrote:
>> On Sat, Dec 08, 2012 at 08:15:50AM +0900, Nobuhiro Iwamatsu wrote:
>> > Some kirkwood SoC has thermal sensor.
>> > This patch adds support for 88F6282 and 88F6283.
>>
>> Thanks! I was just about to write this.. Looks good here.
>
> Ah, looking closer:
>
> $ cat /sys/class/thermal/thermal_zone0/temp
> 37
>
> That should be 37000, the value out of the driver should be in
> milli-Celsius.
>
> I'd use this equation instead:
>
> *temp = ((322 - reg) * 10000 * 1000) / 13625;
>
OK, I will fix this.
Thanks for your review.
Best regards,
Nobuhiro
--
Nobuhiro Iwamatsu
iwamatsu at {nigauri.org / debian.org}
GPG ID: 40AD1FA6
^ permalink raw reply
* Re: [PATCH 1/2] thermal: Add support for thermal sensor for Kirkwood SoC
From: Nobuhiro Iwamatsu @ 2012-12-14 21:24 UTC (permalink / raw)
To: Thomas Petazzoni; +Cc: linux-pm, rui.zhang, jason, linux-arm-kernel
In-Reply-To: <20121208010708.260209f5@skate>
Hi,
On Sat, Dec 8, 2012 at 9:07 AM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Hello,
>
> On Sat, 8 Dec 2012 08:15:50 +0900, Nobuhiro Iwamatsu wrote:
>
>> +config KIRKWOOD_THERMAL
>> + tristate "Temperature sensor on Marvel Kirkwood"
>
> Marvell
Thanks, I will fix.
>
>> + /* Valid check */
>> + if (!(reg >> THERMAL_VALID_OFFSET) & THERMAL_VALID_MASK) {
>> + dev_info(&thermal->device, "Reading temperature is not valid\n");
>
> "Temperature read is not valid" maybe? An native english speaker could
> say.
I will fix.
>
>> + thermal_dev
>> + = devm_kzalloc(&pdev->dev, sizeof(*thermal_dev), GFP_KERNEL);
>
> I think the usual coding style is to have the = on the first line.
>
>> +static int kirkwood_thermal_exit(struct platform_device *pdev)
>> +{
>> + struct thermal_zone_device *kirkwood_thermal
>> + = platform_get_drvdata(pdev);
>
> Ditto.
>
I will fix.
>> +static const struct of_device_id kirkwood_thermal_id_table[] = {
>> + { .compatible = "marvel,thermal-kirkwood" },
>
> marvel -> marvell
Thanks, I will fix.
>
> Also, I think it should be marvell,kirkwood-thermal, since most other
> DT compatible strings that we have for Marvell SoCs are
> marvell,<soc>-<function>.
>
> Also, the Device Tree binding documentation is missing (even though it
> is admittedly going to be a very short documentation).
>
OK, I forgot this.
I will write documentation.
> Thanks!
>
> Thomas
> --
> Thomas Petazzoni, Free Electrons
> Kernel, drivers, real-time and embedded Linux
> development, consulting, training and support.
> http://free-electrons.com
Best regards,
Nobuhiro
--
Nobuhiro Iwamatsu
iwamatsu at {nigauri.org / debian.org}
GPG ID: 40AD1FA6
^ permalink raw reply
* Re: [PATCH 1/2] thermal: Add support for thermal sensor for Kirkwood SoC
From: Nobuhiro Iwamatsu @ 2012-12-14 21:25 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Jason Gunthorpe, rui.zhang, jason, linux-arm-kernel, linux-pm
In-Reply-To: <20121208000850.GZ14363@n2100.arm.linux.org.uk>
Hi,
On Sat, Dec 8, 2012 at 9:08 AM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Fri, Dec 07, 2012 at 04:59:04PM -0700, Jason Gunthorpe wrote:
>> On Fri, Dec 07, 2012 at 04:24:59PM -0700, Jason Gunthorpe wrote:
>> > On Sat, Dec 08, 2012 at 08:15:50AM +0900, Nobuhiro Iwamatsu wrote:
>> > > Some kirkwood SoC has thermal sensor.
>> > > This patch adds support for 88F6282 and 88F6283.
>> >
>> > Thanks! I was just about to write this.. Looks good here.
>>
>> Ah, looking closer:
>>
>> $ cat /sys/class/thermal/thermal_zone0/temp
>> 37
>>
>> That should be 37000, the value out of the driver should be in
>> milli-Celsius.
>>
>> I'd use this equation instead:
>>
>> *temp = ((322 - reg) * 10000 * 1000) / 13625;
>
> Be careful of math overflows... make sure you do this calculation using
> unsigned arithmetic as temperatures above 157 degress will cause this
> to look like a negative number using signed math... However, that
> probably won't ever be noticed because at 157 degrees, you'll definitely
> be outside the operating limits of the device.
Oh, OK. I would like to thank you pointed out.
I will fix.
Best regards,
Nobuhiro
--
Nobuhiro Iwamatsu
iwamatsu at {nigauri.org / debian.org}
GPG ID: 40AD1FA6
^ permalink raw reply
* Re: [PATCH 1/2] thermal: Add support for thermal sensor for Kirkwood SoC
From: Nobuhiro Iwamatsu @ 2012-12-14 21:31 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Thomas Petazzoni, rui.zhang, jason, linux-arm-kernel, linux-pm
In-Reply-To: <20121208001152.GA14363@n2100.arm.linux.org.uk>
Hi,
On Sat, Dec 8, 2012 at 9:11 AM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Sat, Dec 08, 2012 at 01:07:08AM +0100, Thomas Petazzoni wrote:
>> Hello,
>>
>> On Sat, 8 Dec 2012 08:15:50 +0900, Nobuhiro Iwamatsu wrote:
>> > +static const struct of_device_id kirkwood_thermal_id_table[] = {
>> > + { .compatible = "marvel,thermal-kirkwood" },
>>
>> marvel -> marvell
>>
>> Also, I think it should be marvell,kirkwood-thermal, since most other
>> DT compatible strings that we have for Marvell SoCs are
>> marvell,<soc>-<function>.
>>
>> Also, the Device Tree binding documentation is missing (even though it
>> is admittedly going to be a very short documentation).
>
> Is this in any way compatible with the thermal monitoring found on
> Dove (510) stuff? If so, should it have the SoC prefix in there,
> or should it be "armada-thermal" for the SoC family?
I have document of armada and kirkwood only.
I dont know about Dove. if Dove has same device, we had better change
it is a good idea.
Best regards,
Nobuhiro
--
Nobuhiro Iwamatsu
iwamatsu at {nigauri.org / debian.org}
GPG ID: 40AD1FA6
^ permalink raw reply
* Re: [PATCH 1/2] thermal: Add support for thermal sensor for Orion SoC
From: Nobuhiro Iwamatsu @ 2012-12-14 21:54 UTC (permalink / raw)
To: Andrew Lunn
Cc: linux ARM, linux-pm, Jason Cooper, Sebastian Hesselbarth,
Thomas Petazzoni, jgunthorpe
In-Reply-To: <1355482986-885-2-git-send-email-andrew@lunn.ch>
Hi,
Thanks you for your work.
Sorry, I dont hava a time at this week about this.
On Fri, Dec 14, 2012 at 8:03 PM, Andrew Lunn <andrew@lunn.ch> wrote:
> From: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
>
> Some Orion SoC has thermal sensor.
> This patch adds support for 88F6282 and 88F6283.
>
> Signed-off-by: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
> Signed-off-by: Andrew Lunn <andrew@lunn.ch>
> ---
> .../devicetree/bindings/thermal/orion-thermal.txt | 16 +++
> drivers/thermal/Kconfig | 7 ++
> drivers/thermal/Makefile | 1 +
> drivers/thermal/orion_thermal.c | 133 ++++++++++++++++++++
> 4 files changed, 157 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/thermal/orion-thermal.txt
> create mode 100644 drivers/thermal/orion_thermal.c
>
> diff --git a/Documentation/devicetree/bindings/thermal/orion-thermal.txt b/Documentation/devicetree/bindings/thermal/orion-thermal.txt
> new file mode 100644
> index 0000000..5ce925d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/thermal/orion-thermal.txt
> @@ -0,0 +1,16 @@
> +* Orion Thermal
> +
> +This initial version is for Kirkwood 88F8262 & 88F6283 SoCs, however
> +it is expected the driver will sometime in the future be expanded to
> +also support Dove, using a different compatibility string.
> +
> +Required properties:
> +- compatible : "marvell,kirkwood-thermal"
> +- reg : Address range of the thermal registers
> +
> +Example:
> +
> + thermal@10078 {
> + compatible = "marvell,kirkwood";
compatible = "marvell,kirkwood-thermal"; ?
> + reg = <0x10078 0x4>;
> + };
> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
> index e1cb6bd..3bba13f 100644
> --- a/drivers/thermal/Kconfig
> +++ b/drivers/thermal/Kconfig
> @@ -55,3 +55,10 @@ config EXYNOS_THERMAL
> help
> If you say yes here you get support for TMU (Thermal Managment
> Unit) on SAMSUNG EXYNOS series of SoC.
> +
> +config ORION_THERMAL
> + tristate "Temperature sensor on Marvel Orion SoCs"
Marvel -> Marvell
> + depends on PLAT_ORION && THERMAL
> + help
> + Support for the Orion thermal sensor driver into the Linux thermal
> + framework. This currently supports only 88F6282 and 88F6283.
> diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
> index 885550d..2fc64aa 100644
> --- a/drivers/thermal/Makefile
> +++ b/drivers/thermal/Makefile
> @@ -6,4 +6,5 @@ obj-$(CONFIG_THERMAL) += thermal_sys.o
> obj-$(CONFIG_CPU_THERMAL) += cpu_cooling.o
> obj-$(CONFIG_SPEAR_THERMAL) += spear_thermal.o
> obj-$(CONFIG_RCAR_THERMAL) += rcar_thermal.o
> +obj-$(CONFIG_ORION_THERMAL) += orion_thermal.o
> obj-$(CONFIG_EXYNOS_THERMAL) += exynos_thermal.o
> diff --git a/drivers/thermal/orion_thermal.c b/drivers/thermal/orion_thermal.c
> new file mode 100644
> index 0000000..e8a2a68
> --- /dev/null
> +++ b/drivers/thermal/orion_thermal.c
> @@ -0,0 +1,133 @@
> +/*
> + * Orion thermal sensor driver
> + *
> + * Copyright (C) 2012 Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
> + *
> + * This software is licensed under the terms of the GNU General Public
> + * License version 2, as published by the Free Software Foundation, and
> + * may be copied, distributed, and modified under those terms.
> + *
> + * 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/device.h>
> +#include <linux/err.h>
> +#include <linux/io.h>
> +#include <linux/kernel.h>
> +#include <linux/of.h>
> +#include <linux/module.h>
> +#include <linux/platform_device.h>
> +#include <linux/thermal.h>
> +
> +#define THERMAL_VALID_OFFSET 9
> +#define THERMAL_VALID_MASK 0x1
> +#define THERMAL_TEMP_OFFSET 10
> +#define THERMAL_TEMP_MASK 0x1FF
> +
> +/* Orion Thermal Sensor Dev Structure */
> +struct orion_thermal_dev {
> + void __iomem *base_addr;
> +};
> +
> +static int orion_get_temp(struct thermal_zone_device *thermal,
> + unsigned long *temp)
> +{
> + unsigned long reg;
> + struct orion_thermal_dev *thermal_dev = thermal->devdata;
> +
> + reg = readl_relaxed(thermal_dev->base_addr);
> +
> + /* Valid check */
> + if (!(reg >> THERMAL_VALID_OFFSET) & THERMAL_VALID_MASK) {
> + dev_info(&thermal->device,
> + "Temperature sensor reading not valid\n");
> + return -EIO;
> + }
> +
> + reg = (reg >> THERMAL_TEMP_OFFSET) & THERMAL_TEMP_MASK;
> + /* Calculate temperature. See Table 814 in 8262 hardware manual. */
> + *temp = ((322UL - reg) * 10000UL * 1000UL) / 13625UL;
> +
> + return 0;
> +}
> +
> +static struct thermal_zone_device_ops ops = {
> + .get_temp = orion_get_temp,
> +};
> +
> +static int orion_thermal_probe(struct platform_device *pdev)
> +{
> + struct thermal_zone_device *thermal = NULL;
> + struct orion_thermal_dev *thermal_dev;
> + struct resource *res;
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + if (!res) {
> + dev_err(&pdev->dev, "Failed to get platform resource\n");
> + return -ENODEV;
> + }
> +
> + thermal_dev = devm_kzalloc(&pdev->dev, sizeof(*thermal_dev),
> + GFP_KERNEL);
> + if (!thermal_dev) {
> + dev_err(&pdev->dev, "kzalloc fail\n");
> + return -ENOMEM;
> + }
> +
> + thermal_dev->base_addr = devm_ioremap(&pdev->dev, res->start,
> + resource_size(res));
> + if (!thermal_dev->base_addr) {
> + dev_err(&pdev->dev, "Failed to ioremap memory\n");
> + return -ENOMEM;
> + }
> +
> + thermal = thermal_zone_device_register("orion_thermal", 0, 0,
> + thermal_dev, &ops, 0, 0);
> + if (IS_ERR(thermal)) {
> + dev_err(&pdev->dev,
> + "Failed to register thermal zone device\n");
> + return PTR_ERR(thermal);
> + }
> +
> + platform_set_drvdata(pdev, thermal);
> +
> + dev_info(&thermal->device,
> + KBUILD_MODNAME ": Thermal sensor registered\n");
> +
> + return 0;
> +}
> +
> +static int orion_thermal_exit(struct platform_device *pdev)
> +{
> + struct thermal_zone_device *orion_thermal = platform_get_drvdata(pdev);
> +
> + thermal_zone_device_unregister(orion_thermal);
> + platform_set_drvdata(pdev, NULL);
> +
> + return 0;
> +}
> +
> +static const struct of_device_id orion_thermal_id_table[] = {
> + { .compatible = "marvell,kirkwood-thermal" },
> + {}
> +};
> +MODULE_DEVICE_TABLE(of, orion_thermal_id_table);
> +
> +static struct platform_driver orion_thermal_driver = {
> + .probe = orion_thermal_probe,
> + .remove = orion_thermal_exit,
> + .driver = {
> + .name = "orion_thermal",
> + .owner = THIS_MODULE,
> + .of_match_table = of_match_ptr(orion_thermal_id_table),
> + },
> +};
> +
> +module_platform_driver(orion_thermal_driver);
> +
> +MODULE_AUTHOR("Nobuhiro Iwamatsu <iwamatsu@nigauri.org>");
> +MODULE_DESCRIPTION("orion thermal driver");
> +MODULE_LICENSE("GPL");
> --
> 1.7.10.4
>
Tested-by: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
Best regard,
Nobuhiro
--
Nobuhiro Iwamatsu
iwamatsu at {nigauri.org / debian.org}
GPG ID: 40AD1FA6
^ permalink raw reply
* Re: [PATCH 1/2] thermal: Add support for thermal sensor for Orion SoC
From: Nobuhiro Iwamatsu @ 2012-12-14 22:03 UTC (permalink / raw)
To: Andrew Lunn
Cc: R, Durgadoss, linux ARM, linux-pm@vger.kernel.org, Jason Cooper,
Sebastian Hesselbarth, Thomas Petazzoni,
jgunthorpe@obsidianresearch.com
In-Reply-To: <20121214115040.GB7717@lunn.ch>
Hi,
On Fri, Dec 14, 2012 at 8:50 PM, Andrew Lunn <andrew@lunn.ch> wrote:
> On Fri, Dec 14, 2012 at 11:30:41AM +0000, R, Durgadoss wrote:
>> > -----Original Message-----
>> > From: linux-pm-owner@vger.kernel.org [mailto:linux-pm-
>> > owner@vger.kernel.org] On Behalf Of Andrew Lunn
>> > Sent: Friday, December 14, 2012 4:33 PM
>> > To: linux ARM; iwamatsu@nigauri.org; linux-pm@vger.kernel.org
>> > Cc: Jason Cooper; Sebastian Hesselbarth; Thomas Petazzoni;
>> > jgunthorpe@obsidianresearch.com; Andrew Lunn
>> > Subject: [PATCH 1/2] thermal: Add support for thermal sensor for Orion SoC
>> >
>> > From: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
>> >
>> > Some Orion SoC has thermal sensor.
>> > This patch adds support for 88F6282 and 88F6283.
>> >
>> > Signed-off-by: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
>> > Signed-off-by: Andrew Lunn <andrew@lunn.ch>
>> > ---
>> > .../devicetree/bindings/thermal/orion-thermal.txt | 16 +++
>> > drivers/thermal/Kconfig | 7 ++
>> > drivers/thermal/Makefile | 1 +
>> > drivers/thermal/orion_thermal.c | 133 ++++++++++++++++++++
>> > 4 files changed, 157 insertions(+)
>> > create mode 100644 Documentation/devicetree/bindings/thermal/orion-
>> > thermal.txt
>> > create mode 100644 drivers/thermal/orion_thermal.c
>> >
>> > diff --git a/Documentation/devicetree/bindings/thermal/orion-thermal.txt
>> > b/Documentation/devicetree/bindings/thermal/orion-thermal.txt
>> > new file mode 100644
>> > index 0000000..5ce925d
>> > --- /dev/null
>> > +++ b/Documentation/devicetree/bindings/thermal/orion-thermal.txt
>> > @@ -0,0 +1,16 @@
>> > +* Orion Thermal
>> > +
>> > +This initial version is for Kirkwood 88F8262 & 88F6283 SoCs, however
>> > +it is expected the driver will sometime in the future be expanded to
>> > +also support Dove, using a different compatibility string.
>> > +
>> > +Required properties:
>> > +- compatible : "marvell,kirkwood-thermal"
>> > +- reg : Address range of the thermal registers
>> > +
>> > +Example:
>> > +
>> > + thermal@10078 {
>> > + compatible = "marvell,kirkwood";
>> > + reg = <0x10078 0x4>;
>> > + };
>> > diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
>> > index e1cb6bd..3bba13f 100644
>> > --- a/drivers/thermal/Kconfig
>> > +++ b/drivers/thermal/Kconfig
>> > @@ -55,3 +55,10 @@ config EXYNOS_THERMAL
>> > help
>> > If you say yes here you get support for TMU (Thermal Managment
>> > Unit) on SAMSUNG EXYNOS series of SoC.
>> > +
>> > +config ORION_THERMAL
>> > + tristate "Temperature sensor on Marvel Orion SoCs"
>> > + depends on PLAT_ORION && THERMAL
>>
>> On what tree is this patch set based on ?
>
> Not a good one. arm-soc/for-next
>
> I posted these patches to let other know i'm working in the driver and
> to get further feedback. I've also started on adding support for Dove,
> which is similar, but different.
>
> It will get rebased onto -rc1 in a couple of weeks time and by then i
> hope i will have Dove support.
>
>> If it is, then you don't need '&& THERMAL' in Kconfig.
>> > + reg = (reg >> THERMAL_TEMP_OFFSET) & THERMAL_TEMP_MASK;
>> > + /* Calculate temperature. See Table 814 in 8262 hardware manual. */
>>
>> Thanks for the comment.
>> Can we move this comment one line above ? like below:
>>
>> /* comment */
>> reg =
>> *temp =
>
> Sure.
>
>> BTW, is this datasheet public ?
>
> Humm, think so. Take a look at Documentation/arm/Marvell/REAMDE. I
> will check and add a reference to this README file and the specific
> datasheet.
Datasheet of 88F6282 and 88F6283 is not public.
# I dont know about other SoC (about Dove).
Best regards,
Nobuhiro
--
Nobuhiro Iwamatsu
iwamatsu at {nigauri.org / debian.org}
GPG ID: 40AD1FA6
^ permalink raw reply
* Re: [PATCH 1/2] thermal: Add support for thermal sensor for Orion SoC
From: Andrew Lunn @ 2012-12-14 22:11 UTC (permalink / raw)
To: Nobuhiro Iwamatsu
Cc: Andrew Lunn, linux ARM, linux-pm, Jason Cooper,
Sebastian Hesselbarth, Thomas Petazzoni, jgunthorpe
In-Reply-To: <CABMQnV+zNWz4UJ_127Xe+MkTt9eQVPA8StJzyEXt58Z4OqZBYw@mail.gmail.com>
On Sat, Dec 15, 2012 at 06:54:17AM +0900, Nobuhiro Iwamatsu wrote:
> Hi,
>
> Thanks you for your work.
> Sorry, I dont hava a time at this week about this.
Its not a problem. We have plenty of time before the next merge
window. I was just interested in seeing it work on my QNAP device, so
did some of the cleanup work.
> On Fri, Dec 14, 2012 at 8:03 PM, Andrew Lunn <andrew@lunn.ch> wrote:
> > From: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
> >
> > Some Orion SoC has thermal sensor.
> > This patch adds support for 88F6282 and 88F6283.
> >
> > Signed-off-by: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
> > Signed-off-by: Andrew Lunn <andrew@lunn.ch>
> > ---
> > .../devicetree/bindings/thermal/orion-thermal.txt | 16 +++
> > drivers/thermal/Kconfig | 7 ++
> > drivers/thermal/Makefile | 1 +
> > drivers/thermal/orion_thermal.c | 133 ++++++++++++++++++++
> > 4 files changed, 157 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/thermal/orion-thermal.txt
> > create mode 100644 drivers/thermal/orion_thermal.c
> >
> > diff --git a/Documentation/devicetree/bindings/thermal/orion-thermal.txt b/Documentation/devicetree/bindings/thermal/orion-thermal.txt
> > new file mode 100644
> > index 0000000..5ce925d
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/thermal/orion-thermal.txt
> > @@ -0,0 +1,16 @@
> > +* Orion Thermal
> > +
> > +This initial version is for Kirkwood 88F8262 & 88F6283 SoCs, however
> > +it is expected the driver will sometime in the future be expanded to
> > +also support Dove, using a different compatibility string.
> > +
> > +Required properties:
> > +- compatible : "marvell,kirkwood-thermal"
> > +- reg : Address range of the thermal registers
> > +
> > +Example:
> > +
> > + thermal@10078 {
> > + compatible = "marvell,kirkwood";
>
> compatible = "marvell,kirkwood-thermal"; ?
Yep, my error.
> > + reg = <0x10078 0x4>;
> > + };
> > diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
> > index e1cb6bd..3bba13f 100644
> > --- a/drivers/thermal/Kconfig
> > +++ b/drivers/thermal/Kconfig
> > @@ -55,3 +55,10 @@ config EXYNOS_THERMAL
> > help
> > If you say yes here you get support for TMU (Thermal Managment
> > Unit) on SAMSUNG EXYNOS series of SoC.
> > +
> > +config ORION_THERMAL
> > + tristate "Temperature sensor on Marvel Orion SoCs"
>
> Marvel -> Marvell
Missed that one, thanks.
Thanks for the Tested-by. I will add it to the next version. I
started work on Dove support, so i will probably repost when i have
that ready for testing.
Andrew
^ permalink raw reply
* Re: [PATCH] PCIe/PM: Do not suspend port if any subordinate device need PME polling
From: Rafael J. Wysocki @ 2012-12-14 23:03 UTC (permalink / raw)
To: Richard Yang; +Cc: Huang Ying, Bjorn Helgaas, linux-kernel, linux-pci, linux-pm
In-Reply-To: <20121214051131.GA31440@richard.>
On Friday, December 14, 2012 01:11:31 PM Richard Yang wrote:
> On Fri, Dec 14, 2012 at 10:52:11AM +0800, Huang Ying wrote:
> >In
> >
> > http://www.mail-archive.com/linux-usb@vger.kernel.org/msg07976.html
> >
> >Ulrich reported that his USB3 cardreader does not work reliably when
> >connected to the USB3 port. It turns out that USB3 controller failed
> >to be waken up when plugging in the USB3 cardreader. Further
> >experiment found that the USB3 host controller can only be waken up
> >via polling, while not via PME interrupt. But if the PCIe port that
> >the USB3 host controller is connected is suspended, we can not poll
> >the USB3 host controller because its config space is not accessible if
> >the PCIe port is put into low power state.
> >
> >To solve the issue, the PCIe port will not be suspended if any
> >subordinate device need PME polling.
> >
> >Reported-by: Ulrich Eckhardt <usb@uli-eckhardt.de>
> >Signed-off-by: Huang Ying <ying.huang@intel.com>
> >Tested-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
> >Cc: stable@vger.kernel.org # 3.6+
> >---
> > drivers/pci/pcie/portdrv_pci.c | 18 +++++++++++++++++-
> > 1 file changed, 17 insertions(+), 1 deletion(-)
> >
> >--- a/drivers/pci/pcie/portdrv_pci.c
> >+++ b/drivers/pci/pcie/portdrv_pci.c
> >@@ -134,10 +134,26 @@ static int pcie_port_runtime_resume(stru
> > return 0;
> > }
> >
> >+static int pci_dev_pme_poll(struct pci_dev *pdev, void *data)
> >+{
> >+ int *pme_poll = data;
> >+ *pme_poll = *pme_poll || pdev->pme_poll;
> >+ return 0;
> >+}
> >+
> > static int pcie_port_runtime_idle(struct device *dev)
> > {
> >+ struct pci_dev *pdev = to_pci_dev(dev);
> >+ int pme_poll = false;
>
> You want to use int or bool?
>
> I think bool is better?
Well, bool would be nicer, but it's not a big deal.
Thanks,
Rafael
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
^ permalink raw reply
* Re: [PATCH] cpufreq_stats: fix race between stats allocation and first usage
From: Rafael J. Wysocki @ 2012-12-14 23:33 UTC (permalink / raw)
To: Konstantin Khlebnikov; +Cc: linux-kernel, cpufreq, linux-pm
In-Reply-To: <20121214105921.5139.502.stgit@zurg>
On Friday, December 14, 2012 02:59:21 PM Konstantin Khlebnikov wrote:
> This patch forces complete struct cpufreq_stats allocation for all cpus before
> registering CPUFREQ_TRANSITION_NOTIFIER notifier, otherwise in some conditions
> cpufreq_stat_notifier_trans() can be called in the middle of stats allocation,
> in this case cpufreq_stats_table already exists, but stat->freq_table is NULL.
I'll queue it up for submission as v3.8 material.
Does it need to be marked as -stable material too?
Rafael
> Signed-off-by: Konstantin Khlebnikov <khlebnikov@openvz.org>
> Cc: Rafael J. Wysocki <rjw@sisk.pl>
> Cc: cpufreq <cpufreq@vger.kernel.org>
> Cc: linux-pm <linux-pm@vger.kernel.org>
>
> ---
>
> <1>[ 363.116198] BUG: unable to handle kernel NULL pointer dereference at (null)
> <1>[ 363.116668] IP: [<ffffffffa11a70e4>] cpufreq_stat_notifier_trans+0x64/0xf0 [cpufreq_stats]
> <4>[ 363.116977] PGD 23177e067 PUD 2349c1067 PMD 0
> <4>[ 363.117151] Oops: 0000 [#1] SMP
> <4>[ 363.117151] last sysfs file: /sys/module/freq_table/initstate
> <4>[ 363.117151] CPU 5
> <4>[ 363.117151] Modules linked in: cpufreq_stats(+)(U) [a lot] [last unloaded: umc]
> <4>[ 363.117151]
> <4>[ 363.117151] Pid: 1690, comm: kondemand/5 veid: 0 Tainted: P WC --------------- T 2.6.32-279.5.1.el6-042stab061.7-vz #112 042stab061_7 System manufacturer System Product Name/Crosshair IV Formula
> <4>[ 363.117151] RIP: 0010:[<ffffffffa11a70e4>] [<ffffffffa11a70e4>] cpufreq_stat_notifier_trans+0x64/0xf0 [cpufreq_stats]
> <4>[ 363.117151] RSP: 0018:ffff880234281920 EFLAGS: 00010246
> <4>[ 363.117151] RAX: 00000000001e12e8 RBX: 0000000000000000 RCX: 00000000002ab980
> <4>[ 363.117151] RDX: 0000000000000004 RSI: 0000000000000000 RDI: 0000000000000005
> <4>[ 363.117151] RBP: ffff880234281940 R08: 0000000000000000 R09: 0000000000000000
> <4>[ 363.117151] R10: 0000000000000000 R11: 2222222222222222 R12: ffff880218ce7400
> <4>[ 363.117151] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
> <4>[ 363.117151] FS: 00007f499ffe0700(0000) GS:ffff880031000000(0000) knlGS:0000000000000000
> <4>[ 363.117151] CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
> <4>[ 363.117151] CR2: 0000000000000000 CR3: 0000000230af7000 CR4: 00000000000006e0
> <4>[ 363.117151] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> <4>[ 363.117151] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> <4>[ 363.117151] Process kondemand/5 (pid: 1690, veid: 0, threadinfo ffff880234280000, task ffff8802330c48c0)
> <4>[ 363.117151] Stack:
> <4>[ 363.117151] ffffffff810cf4f3 0000000000000001 00000000ffffffff ffffffffa11a7ac0
> <4>[ 363.117151] <d> ffff880234281990 ffffffff815454a8 ffff880234281c80 0000000000000000
> <4>[ 363.117151] <d> ffff880234281a10 ffffffff833be978 ffffffff833be8e0 0000000000000001
> <4>[ 363.117151] Call Trace:
> <4>[ 363.117151] [<ffffffff810cf4f3>] ? is_module_text_address+0x23/0x30
> <4>[ 363.117151] [<ffffffff815454a8>] notifier_call_chain+0x58/0xb0
> <4>[ 363.117151] [<ffffffff810a5a8d>] __srcu_notifier_call_chain+0x5d/0x90
> <4>[ 363.117151] [<ffffffff810a5ad6>] srcu_notifier_call_chain+0x16/0x20
> <4>[ 363.117151] [<ffffffff81442a0a>] cpufreq_notify_transition+0x12a/0x190
> <4>[ 363.117151] [<ffffffffa026df08>] powernowk8_target+0x628/0xb30 [powernow_k8]
> <4>[ 363.117151] [<ffffffff8144289b>] __cpufreq_driver_target+0x8b/0x90
> <4>[ 363.117151] [<ffffffffa0279388>] do_dbs_timer+0x3b8/0x3bc [cpufreq_ondemand]
> <4>[ 363.117151] [<ffffffffa0278fd0>] ? do_dbs_timer+0x0/0x3bc [cpufreq_ondemand]
> <4>[ 363.117151] [<ffffffff81097df4>] worker_thread+0x264/0x440
> <4>[ 363.117151] [<ffffffff81097da3>] ? worker_thread+0x213/0x440
> <4>[ 363.117151] [<ffffffff81097b90>] ? worker_thread+0x0/0x440
> <4>[ 363.117151] [<ffffffff8109f050>] ? autoremove_wake_function+0x0/0x40
> <4>[ 363.117151] [<ffffffff81097b90>] ? worker_thread+0x0/0x440
> <4>[ 363.117151] [<ffffffff8109e986>] kthread+0x96/0xa0
> <4>[ 363.117151] [<ffffffff8100c34a>] child_rip+0xa/0x20
> <4>[ 363.117151] [<ffffffff8100bc90>] ? restore_args+0x0/0x30
> <4>[ 363.117151] [<ffffffff8109e8f0>] ? kthread+0x0/0xa0
> <4>[ 363.117151] [<ffffffff8100c340>] ? child_rip+0x0/0x20
> <4>[ 363.117151] Code: 89 f9 48 8b 0c cd 20 53 9c 81 4c 8b 24 08 4d 85 e4 74 d3 8b 4a 08 41 8b 54 24 10 45 8b 6c 24 18 85 d2 74 22 49 8b 74 24 28 31 db <3b> 0e 75 10 eb 1a 66 0f 1f 44 00 00 48 63 c3 3b 0c 86 74 0c 83
> <1>[ 363.117151] RIP [<ffffffffa11a70e4>] cpufreq_stat_notifier_trans+0x64/0xf0 [cpufreq_stats]
> <4>[ 363.117151] RSP <ffff880234281920>
> <4>[ 363.117151] CR2: 0000000000000000
> ---
> drivers/cpufreq/cpufreq_stats.c | 11 +++++++----
> 1 file changed, 7 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/cpufreq/cpufreq_stats.c b/drivers/cpufreq/cpufreq_stats.c
> index e40e508..9d7732b 100644
> --- a/drivers/cpufreq/cpufreq_stats.c
> +++ b/drivers/cpufreq/cpufreq_stats.c
> @@ -364,18 +364,21 @@ static int __init cpufreq_stats_init(void)
> if (ret)
> return ret;
>
> + register_hotcpu_notifier(&cpufreq_stat_cpu_notifier);
> + for_each_online_cpu(cpu)
> + cpufreq_update_policy(cpu);
> +
> ret = cpufreq_register_notifier(¬ifier_trans_block,
> CPUFREQ_TRANSITION_NOTIFIER);
> if (ret) {
> cpufreq_unregister_notifier(¬ifier_policy_block,
> CPUFREQ_POLICY_NOTIFIER);
> + unregister_hotcpu_notifier(&cpufreq_stat_cpu_notifier);
> + for_each_online_cpu(cpu)
> + cpufreq_stats_free_table(cpu);
> return ret;
> }
>
> - register_hotcpu_notifier(&cpufreq_stat_cpu_notifier);
> - for_each_online_cpu(cpu) {
> - cpufreq_update_policy(cpu);
> - }
> return 0;
> }
> static void __exit cpufreq_stats_exit(void)
>
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
^ 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