* [PATCH 0/6 v5] cpufreq: add support for Calxeda ECX-1000 (highbank)
From: Mark Langsdorf @ 2012-11-27 15:04 UTC (permalink / raw)
To: linux-kernel, cpufreq, linux-pm, linux-arm-kernel
In-Reply-To: <1351631056-25938-1-git-send-email-mark.langsdorf@calxeda.com>
This patch series adds cpufreq support for the Calxeda
ECX-1000 (highbank) SoCs. The driver is based on the
cpufreq-cpu0 driver. Because of the unique way that
highbank uses the EnergyCore Management Engine to manage
voltages, it was not possible to use the cpufreq-cpu0 driver.
--Mark Langsdorf
^ permalink raw reply
* [PATCH 6/6 v5] cpufreq, highbank: add support for highbank cpufreq
From: Mark Langsdorf @ 2012-11-27 15:04 UTC (permalink / raw)
To: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
cpufreq-u79uwXL29TY76Z2rM5mHXA, linux-pm-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ, Mark Langsdorf
In-Reply-To: <1354028674-23685-1-git-send-email-mark.langsdorf-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org>
Highbank processors depend on the external ECME to perform voltage
management based on a requested frequency. Communication between the
A9 cores and the ECME happens over the pl320 IPC channel.
Signed-off-by: Mark Langsdorf <mark.langsdorf-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org>
Cc: devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
---
Changes from v4
Removed erroneous changes to arch/arm/Kconfig.
Removed unnecessary changes to drivers/cpufreq/Kconfig.arm
Alphabetized additions to arch/arm/mach-highbank/Kconfig
Changed ipc call and header to match new ipc location in
drivers/mailbox.
Changes from v3
None.
Changes from v2
Changed transition latency binding in code to match documentation.
Changes from v1
Added highbank specific Kconfig changes.
.../bindings/cpufreq/highbank-cpufreq.txt | 53 +++++
arch/arm/boot/dts/highbank.dts | 10 +
arch/arm/mach-highbank/Kconfig | 2 +
drivers/cpufreq/Kconfig.arm | 13 ++
drivers/cpufreq/Makefile | 1 +
drivers/cpufreq/highbank-cpufreq.c | 229 +++++++++++++++++++++
6 files changed, 308 insertions(+)
create mode 100644 Documentation/devicetree/bindings/cpufreq/highbank-cpufreq.txt
create mode 100644 drivers/cpufreq/highbank-cpufreq.c
diff --git a/Documentation/devicetree/bindings/cpufreq/highbank-cpufreq.txt b/Documentation/devicetree/bindings/cpufreq/highbank-cpufreq.txt
new file mode 100644
index 0000000..1d5a836
--- /dev/null
+++ b/Documentation/devicetree/bindings/cpufreq/highbank-cpufreq.txt
@@ -0,0 +1,53 @@
+Highbank cpufreq driver
+
+This is cpufreq driver for Calxeda ECX-1000 (highbank) processor. It is based
+on the generic cpu0 driver and uses a similar format for bindings. Since
+the EnergyCore Management Engine maintains the voltage based on the
+frequency, the voltage component of the operating points can be set to any
+arbitrary values.
+
+Both required properties listed below must be defined under node /cpus/cpu@0.
+
+Required properties:
+- operating-points: Refer to Documentation/devicetree/bindings/power/opp.txt
+ for details
+- transition-latency: Specify the possible maximum transition latency for clock,
+ in unit of nanoseconds.
+
+Examples:
+
+cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu@0 {
+ compatible = "arm,cortex-a9";
+ reg = <0>;
+ next-level-cache = <&L2>;
+ operating-points = <
+ /* kHz ignored */
+ 790000 1000000
+ 396000 1000000
+ 198000 1000000
+ >;
+ transition-latency = <200000>;
+ };
+
+ cpu@1 {
+ compatible = "arm,cortex-a9";
+ reg = <1>;
+ next-level-cache = <&L2>;
+ };
+
+ cpu@2 {
+ compatible = "arm,cortex-a9";
+ reg = <2>;
+ next-level-cache = <&L2>;
+ };
+
+ cpu@3 {
+ compatible = "arm,cortex-a9";
+ reg = <3>;
+ next-level-cache = <&L2>;
+ };
+};
diff --git a/arch/arm/boot/dts/highbank.dts b/arch/arm/boot/dts/highbank.dts
index 0c6fc34..8624c94 100644
--- a/arch/arm/boot/dts/highbank.dts
+++ b/arch/arm/boot/dts/highbank.dts
@@ -36,6 +36,16 @@
next-level-cache = <&L2>;
clocks = <&a9pll>;
clock-names = "cpu";
+ operating-points = <
+ /* kHz ignored */
+ 1300000 1000000
+ 1200000 1000000
+ 1100000 1000000
+ 800000 1000000
+ 400000 1000000
+ 200000 1000000
+ >;
+ transition-latency = <100000>;
};
cpu@1 {
diff --git a/arch/arm/mach-highbank/Kconfig b/arch/arm/mach-highbank/Kconfig
index 2896881..b7862da 100644
--- a/arch/arm/mach-highbank/Kconfig
+++ b/arch/arm/mach-highbank/Kconfig
@@ -1,5 +1,7 @@
config ARCH_HIGHBANK
bool "Calxeda ECX-1000 (Highbank)" if ARCH_MULTI_V7
+ select ARCH_HAS_CPUFREQ
+ select ARCH_HAS_OPP
select ARCH_WANT_OPTIONAL_GPIOLIB
select ARM_AMBA
select ARM_GIC
diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
index 5961e64..7a8bcdc 100644
--- a/drivers/cpufreq/Kconfig.arm
+++ b/drivers/cpufreq/Kconfig.arm
@@ -76,3 +76,16 @@ config ARM_EXYNOS5250_CPUFREQ
help
This adds the CPUFreq driver for Samsung EXYNOS5250
SoC.
+
+config ARM_HIGHBANK_CPUFREQ
+ tristate "Calxeda Highbank-based"
+ depends on ARCH_HIGHBANK
+ select CPU_FREQ_TABLE
+ select PM_OPP
+ default m
+ help
+ This adds the CPUFreq driver for Calxeda Highbank SoC
+ based boards.
+
+ If in doubt, say N.
+
diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
index 1bc90e1..9e8f12a 100644
--- a/drivers/cpufreq/Makefile
+++ b/drivers/cpufreq/Makefile
@@ -50,6 +50,7 @@ obj-$(CONFIG_ARM_EXYNOS4210_CPUFREQ) += exynos4210-cpufreq.o
obj-$(CONFIG_ARM_EXYNOS4X12_CPUFREQ) += exynos4x12-cpufreq.o
obj-$(CONFIG_ARM_EXYNOS5250_CPUFREQ) += exynos5250-cpufreq.o
obj-$(CONFIG_ARM_OMAP2PLUS_CPUFREQ) += omap-cpufreq.o
+obj-$(CONFIG_ARM_HIGHBANK_CPUFREQ) += highbank-cpufreq.o
##################################################################################
# PowerPC platform drivers
diff --git a/drivers/cpufreq/highbank-cpufreq.c b/drivers/cpufreq/highbank-cpufreq.c
new file mode 100644
index 0000000..f2ac342
--- /dev/null
+++ b/drivers/cpufreq/highbank-cpufreq.c
@@ -0,0 +1,229 @@
+/*
+ * Copyright (C) 2012 Calxeda, Inc.
+ *
+ * derived from cpufreq-cpu0 by Freescale Semiconductor
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
+#include <linux/clk.h>
+#include <linux/cpu.h>
+#include <linux/cpufreq.h>
+#include <linux/err.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/opp.h>
+#include <linux/slab.h>
+#include <linux/mailbox.h>
+
+#define HB_CPUFREQ_CHANGE_NOTE 0x80000001
+
+static unsigned int transition_latency;
+
+static struct device *cpu_dev;
+static struct clk *cpu_clk;
+static struct cpufreq_frequency_table *freq_table;
+
+static int hb_verify_speed(struct cpufreq_policy *policy)
+{
+ return cpufreq_frequency_table_verify(policy, freq_table);
+}
+
+static unsigned int hb_get_speed(unsigned int cpu)
+{
+ return clk_get_rate(cpu_clk) / 1000;
+}
+
+static int hb_voltage_change(unsigned int freq)
+{
+ int i;
+ u32 msg[7];
+
+ msg[0] = HB_CPUFREQ_CHANGE_NOTE;
+ msg[1] = freq / 1000;
+ for (i = 2; i < 7; i++)
+ msg[i] = 0;
+
+ return ipc_transmit(msg);
+}
+
+static int hb_set_target(struct cpufreq_policy *policy,
+ unsigned int target_freq, unsigned int relation)
+{
+ struct cpufreq_freqs freqs;
+ unsigned long freq_Hz;
+ unsigned int index, cpu;
+ int ret;
+
+ ret = cpufreq_frequency_table_target(policy, freq_table, target_freq,
+ relation, &index);
+ if (ret) {
+ pr_err("failed to match target freqency %d: %d\n",
+ target_freq, ret);
+ return ret;
+ }
+
+ freq_Hz = clk_round_rate(cpu_clk, freq_table[index].frequency * 1000);
+ if (freq_Hz < 0)
+ freq_Hz = freq_table[index].frequency * 1000;
+ freqs.new = freq_Hz / 1000;
+ freqs.old = clk_get_rate(cpu_clk) / 1000;
+
+ if (freqs.old == freqs.new)
+ return 0;
+
+ for_each_online_cpu(cpu) {
+ freqs.cpu = cpu;
+ cpufreq_notify_transition(&freqs, CPUFREQ_PRECHANGE);
+ }
+
+ pr_debug("%u MHz --> %u MHz\n", freqs.old / 1000, freqs.new / 1000);
+
+ /* scaling up? scale voltage before frequency */
+ if (freqs.new > freqs.old) {
+ ret = hb_voltage_change(freqs.new);
+ if (ret) {
+ freqs.new = freqs.old;
+ return -EAGAIN;
+ }
+ }
+
+ ret = clk_set_rate(cpu_clk, freqs.new * 1000);
+ if (ret) {
+ pr_err("failed to set clock rate: %d\n", ret);
+ hb_voltage_change(freqs.old);
+ return ret;
+ }
+
+ /* scaling down? scale voltage after frequency */
+ if (freqs.new < freqs.old) {
+ ret = hb_voltage_change(freqs.new);
+ if (ret) {
+ if (clk_set_rate(cpu_clk, freqs.old * 1000))
+ pr_err("also failed to reset freq\n");
+ freqs.new = freqs.old;
+ return -EAGAIN;
+ }
+ }
+
+ for_each_online_cpu(cpu) {
+ freqs.cpu = cpu;
+ cpufreq_notify_transition(&freqs, CPUFREQ_POSTCHANGE);
+ }
+
+ return 0;
+}
+
+static int hb_cpufreq_init(struct cpufreq_policy *policy)
+{
+ int ret;
+
+ if (policy->cpu != 0)
+ return -EINVAL;
+
+ ret = cpufreq_frequency_table_cpuinfo(policy, freq_table);
+ if (ret) {
+ pr_err("invalid frequency table: %d\n", ret);
+ return ret;
+ }
+
+ policy->cpuinfo.transition_latency = transition_latency;
+ policy->cur = clk_get_rate(cpu_clk) / 1000;
+
+ policy->shared_type = CPUFREQ_SHARED_TYPE_ANY;
+ cpumask_setall(policy->cpus);
+
+ cpufreq_frequency_table_get_attr(freq_table, policy->cpu);
+
+ return 0;
+}
+
+static int hb_cpufreq_exit(struct cpufreq_policy *policy)
+{
+ cpufreq_frequency_table_put_attr(policy->cpu);
+
+ return 0;
+}
+
+static struct freq_attr *hb_cpufreq_attr[] = {
+ &cpufreq_freq_attr_scaling_available_freqs,
+ NULL,
+};
+
+static struct cpufreq_driver hb_cpufreq_driver = {
+ .flags = CPUFREQ_STICKY,
+ .verify = hb_verify_speed,
+ .target = hb_set_target,
+ .get = hb_get_speed,
+ .init = hb_cpufreq_init,
+ .exit = hb_cpufreq_exit,
+ .name = "highbank-cpufreq",
+ .attr = hb_cpufreq_attr,
+};
+
+static int __devinit hb_cpufreq_driver_init(void)
+{
+ struct device_node *np;
+ int ret;
+
+ np = of_find_node_by_path("/cpus/cpu@0");
+ if (!np) {
+ pr_err("failed to find highbank cpufreq node\n");
+ return -ENOENT;
+ }
+
+ cpu_dev = get_cpu_device(0);
+ if (!cpu_dev) {
+ pr_err("failed to get highbank cpufreq device\n");
+ ret = -ENODEV;
+ goto out_put_node;
+ }
+
+ cpu_dev->of_node = np;
+
+ cpu_clk = clk_get(cpu_dev, NULL);
+ if (IS_ERR(cpu_clk)) {
+ ret = PTR_ERR(cpu_clk);
+ pr_err("failed to get cpu0 clock: %d\n", ret);
+ goto out_put_node;
+ }
+
+ ret = of_init_opp_table(cpu_dev);
+ if (ret) {
+ pr_err("failed to init OPP table: %d\n", ret);
+ goto out_put_node;
+ }
+
+ ret = opp_init_cpufreq_table(cpu_dev, &freq_table);
+ if (ret) {
+ pr_err("failed to init cpufreq table: %d\n", ret);
+ goto out_put_node;
+ }
+
+ if (of_property_read_u32(np, "transition-latency", &transition_latency))
+ transition_latency = CPUFREQ_ETERNAL;
+
+ ret = cpufreq_register_driver(&hb_cpufreq_driver);
+ if (ret) {
+ pr_err("failed register driver: %d\n", ret);
+ goto out_free_table;
+ }
+
+ of_node_put(np);
+ return 0;
+
+out_free_table:
+ opp_free_cpufreq_table(cpu_dev, &freq_table);
+out_put_node:
+ of_node_put(np);
+ return ret;
+}
+late_initcall(hb_cpufreq_driver_init);
+
+MODULE_AUTHOR("Mark Langsdorf <mark.langsdorf-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org>");
+MODULE_DESCRIPTION("Calxeda Highbank cpufreq driver");
+MODULE_LICENSE("GPL");
--
1.7.11.7
^ permalink raw reply related
* [PATCH 5/6 v5] power: export opp cpufreq functions
From: Mark Langsdorf @ 2012-11-27 15:04 UTC (permalink / raw)
To: linux-kernel, cpufreq, linux-pm, linux-arm-kernel; +Cc: Mark Langsdorf
In-Reply-To: <1354028674-23685-1-git-send-email-mark.langsdorf@calxeda.com>
These functions are needed to make the cpufreq-core0 and highbank-cpufreq
drivers loadable as modules.
Signed-off-by: Mark Langsdorf <mark.langsdorf@calxeda.com>
Acked-by: Nishanth Menon <nm@ti.com>
---
Changes from v4
None.
Changes from v3
includes linux/export.h instead of module.h.
Changes from v2
None.
Changes from v1
Added Nishanth Menon's ack.
Clarified the purpose of the change in the commit message.
drivers/base/power/opp.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/base/power/opp.c b/drivers/base/power/opp.c
index d946864..4062ec3 100644
--- a/drivers/base/power/opp.c
+++ b/drivers/base/power/opp.c
@@ -23,6 +23,7 @@
#include <linux/rcupdate.h>
#include <linux/opp.h>
#include <linux/of.h>
+#include <linux/export.h>
/*
* Internal data structure organization with the OPP layer library is as
@@ -643,6 +644,7 @@ int opp_init_cpufreq_table(struct device *dev,
return 0;
}
+EXPORT_SYMBOL(opp_init_cpufreq_table);
/**
* opp_free_cpufreq_table() - free the cpufreq table
@@ -660,6 +662,7 @@ void opp_free_cpufreq_table(struct device *dev,
kfree(*table);
*table = NULL;
}
+EXPORT_SYMBOL(opp_free_cpufreq_table);
#endif /* CONFIG_CPU_FREQ */
/**
@@ -720,4 +723,5 @@ int of_init_opp_table(struct device *dev)
return 0;
}
+EXPORT_SYMBOL(of_init_opp_table);
#endif
--
1.7.11.7
^ permalink raw reply related
* [PATCH 4/6 v5] arm highbank: add support for pl320 IPC
From: Mark Langsdorf @ 2012-11-27 15:04 UTC (permalink / raw)
To: linux-kernel, cpufreq, linux-pm, linux-arm-kernel
Cc: Mark Langsdorf, Rob Herring, Omar Ramirez Luna, Arnd Bergmann
In-Reply-To: <1354028674-23685-1-git-send-email-mark.langsdorf@calxeda.com>
From: Rob Herring <rob.herring@calxeda.com>
The pl320 IPC allows for interprocessor communication between the highbank A9
and the EnergyCore Management Engine. The pl320 implements a straightforward
mailbox protocol.
This patch depends on Omar Ramirez Luna's <omar.luna@linaro.org>
mailbox driver patch series.
Signed-off-by: Mark Langsdorf <mark.langsdorf@calxeda.com>
Signed-off-by: Rob Herring <rob.herring@calxeda.com>
Cc: Omar Ramirez Luna <omar.luna@linaro.org>
Cc: Arnd Bergmann <arnd@arndb.de>
---
Changes from v4
Moved pl320-ipc.c from arch/arm/mach-highbank to drivers/mailbox.
Moved header information to include/linux/mailbox.h.
Added Kconfig options to reflect the new code location.
Change drivers/mailbox/Makefile to build the omap mailboxes only
when they are configured.
Removed ipc_call_fast and renamed ipc_call_slow ipc_transmit
Changes from v3, v2
None.
Changes from v1
Removed erroneous changes for cpufreq Kconfig.
arch/arm/mach-highbank/Kconfig | 2 +
drivers/mailbox/Kconfig | 9 ++
drivers/mailbox/Makefile | 4 +
drivers/mailbox/pl320-ipc.c | 197 +++++++++++++++++++++++++++++++++++++++++
include/linux/mailbox.h | 19 +++-
5 files changed, 230 insertions(+), 1 deletion(-)
create mode 100644 drivers/mailbox/Makefile
create mode 100644 drivers/mailbox/pl320-ipc.c
diff --git a/arch/arm/mach-highbank/Kconfig b/arch/arm/mach-highbank/Kconfig
index 0e1d0a4..2896881 100644
--- a/arch/arm/mach-highbank/Kconfig
+++ b/arch/arm/mach-highbank/Kconfig
@@ -11,5 +11,7 @@ config ARCH_HIGHBANK
select GENERIC_CLOCKEVENTS
select HAVE_ARM_SCU
select HAVE_SMP
+ select MAILBOX
+ select PL320_MBOX
select SPARSE_IRQ
select USE_OF
diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
index be8cac0..e89fdb4 100644
--- a/drivers/mailbox/Kconfig
+++ b/drivers/mailbox/Kconfig
@@ -34,4 +34,13 @@ config OMAP_MBOX_KFIFO_SIZE
This can also be changed at runtime (via the mbox_kfifo_size
module parameter).
+config PL320_MBOX
+ bool "ARM PL320 Mailbox"
+ help
+ An implementation of the ARM PL320 Interprocessor Communication
+ Mailbox (IPCM), tailored for the Calxeda Highbank. It is used to
+ send short messages between Highbank's A9 cores and the EnergyCore
+ Management Engine, primarily for cpufreq. Say Y here if you want
+ to use the PL320 IPCM support.
+
endif
diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile
new file mode 100644
index 0000000..c9f14c3
--- /dev/null
+++ b/drivers/mailbox/Makefile
@@ -0,0 +1,4 @@
+obj-$(CONFIG_OMAP1_MBOX) += mailbox.o mailbox-omap1.o
+obj-$(CONFIG_OMAP2PLUS_MBOX) += mailbox.o mailbox-omap2.o
+obj-$(CONFIG_PL320_MBOX) += pl320-ipc.o
+
diff --git a/drivers/mailbox/pl320-ipc.c b/drivers/mailbox/pl320-ipc.c
new file mode 100644
index 0000000..33eb97f
--- /dev/null
+++ b/drivers/mailbox/pl320-ipc.c
@@ -0,0 +1,197 @@
+/*
+ * Copyright 2012 Calxeda, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope 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.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program. If not, see <http://www.gnu.org/licenses/>.
+ */
+#include <linux/types.h>
+#include <linux/err.h>
+#include <linux/delay.h>
+#include <linux/export.h>
+#include <linux/io.h>
+#include <linux/interrupt.h>
+#include <linux/completion.h>
+#include <linux/mutex.h>
+#include <linux/notifier.h>
+#include <linux/spinlock.h>
+#include <linux/device.h>
+#include <linux/amba/bus.h>
+
+#include <linux/mailbox.h>
+
+#define IPCMxSOURCE(m) ((m) * 0x40)
+#define IPCMxDSET(m) (((m) * 0x40) + 0x004)
+#define IPCMxDCLEAR(m) (((m) * 0x40) + 0x008)
+#define IPCMxDSTATUS(m) (((m) * 0x40) + 0x00C)
+#define IPCMxMODE(m) (((m) * 0x40) + 0x010)
+#define IPCMxMSET(m) (((m) * 0x40) + 0x014)
+#define IPCMxMCLEAR(m) (((m) * 0x40) + 0x018)
+#define IPCMxMSTATUS(m) (((m) * 0x40) + 0x01C)
+#define IPCMxSEND(m) (((m) * 0x40) + 0x020)
+#define IPCMxDR(m, dr) (((m) * 0x40) + ((dr) * 4) + 0x024)
+
+#define IPCMMIS(irq) (((irq) * 8) + 0x800)
+#define IPCMRIS(irq) (((irq) * 8) + 0x804)
+
+#define MBOX_MASK(n) (1 << (n))
+#define IPC_TX_MBOX 1
+#define IPC_RX_MBOX 2
+
+#define CHAN_MASK(n) (1 << (n))
+#define A9_SOURCE 1
+#define M3_SOURCE 0
+
+static void __iomem *ipc_base;
+static int ipc_irq;
+static DEFINE_MUTEX(ipc_m1_lock);
+static DECLARE_COMPLETION(ipc_completion);
+static ATOMIC_NOTIFIER_HEAD(ipc_notifier);
+
+static inline void set_destination(int source, int mbox)
+{
+ __raw_writel(CHAN_MASK(source), ipc_base + IPCMxDSET(mbox));
+ __raw_writel(CHAN_MASK(source), ipc_base + IPCMxMSET(mbox));
+}
+
+static inline void clear_destination(int source, int mbox)
+{
+ __raw_writel(CHAN_MASK(source), ipc_base + IPCMxDCLEAR(mbox));
+ __raw_writel(CHAN_MASK(source), ipc_base + IPCMxMCLEAR(mbox));
+}
+
+static void __ipc_send(int mbox, u32 *data)
+{
+ int i;
+ for (i = 0; i < 7; i++)
+ __raw_writel(data[i], ipc_base + IPCMxDR(mbox, i));
+ __raw_writel(0x1, ipc_base + IPCMxSEND(mbox));
+}
+
+static u32 __ipc_rcv(int mbox, u32 *data)
+{
+ int i;
+ for (i = 0; i < 7; i++)
+ data[i] = __raw_readl(ipc_base + IPCMxDR(mbox, i));
+ return data[1];
+}
+
+/* blocking implmentation from the A9 side, not usuable in interrupts! */
+int ipc_transmit(u32 *data)
+{
+ int ret;
+
+ mutex_lock(&ipc_m1_lock);
+
+ init_completion(&ipc_completion);
+ __ipc_send(IPC_TX_MBOX, data);
+ ret = wait_for_completion_timeout(&ipc_completion,
+ msecs_to_jiffies(1000));
+ if (ret == 0) {
+ ret = -ETIMEDOUT;
+ goto out;
+ }
+
+ ret = __ipc_rcv(IPC_TX_MBOX, data);
+out:
+ mutex_unlock(&ipc_m1_lock);
+ return ret;
+}
+EXPORT_SYMBOL(ipc_transmit);
+
+irqreturn_t ipc_handler(int irq, void *dev)
+{
+ u32 irq_stat;
+ u32 data[7];
+
+ irq_stat = __raw_readl(ipc_base + IPCMMIS(1));
+ if (irq_stat & MBOX_MASK(IPC_TX_MBOX)) {
+ __raw_writel(0, ipc_base + IPCMxSEND(IPC_TX_MBOX));
+ complete(&ipc_completion);
+ }
+ if (irq_stat & MBOX_MASK(IPC_RX_MBOX)) {
+ __ipc_rcv(IPC_RX_MBOX, data);
+ atomic_notifier_call_chain(&ipc_notifier, data[0], data + 1);
+ __raw_writel(2, ipc_base + IPCMxSEND(IPC_RX_MBOX));
+ }
+
+ return IRQ_HANDLED;
+}
+
+int pl320_ipc_register_notifier(struct notifier_block *nb)
+{
+ return atomic_notifier_chain_register(&ipc_notifier, nb);
+}
+
+int pl320_ipc_unregister_notifier(struct notifier_block *nb)
+{
+ return atomic_notifier_chain_unregister(&ipc_notifier, nb);
+}
+
+static int __devinit pl320_probe(struct amba_device *adev,
+ const struct amba_id *id)
+{
+ int ret;
+
+ ipc_base = ioremap(adev->res.start, resource_size(&adev->res));
+ if (ipc_base == NULL)
+ return -ENOMEM;
+
+ __raw_writel(0, ipc_base + IPCMxSEND(IPC_TX_MBOX));
+
+ ipc_irq = adev->irq[0];
+ ret = request_irq(ipc_irq, ipc_handler, 0, dev_name(&adev->dev), NULL);
+ if (ret < 0)
+ goto err;
+
+ /* Init slow mailbox */
+ __raw_writel(CHAN_MASK(A9_SOURCE),
+ ipc_base + IPCMxSOURCE(IPC_TX_MBOX));
+ __raw_writel(CHAN_MASK(M3_SOURCE),
+ ipc_base + IPCMxDSET(IPC_TX_MBOX));
+ __raw_writel(CHAN_MASK(M3_SOURCE) | CHAN_MASK(A9_SOURCE),
+ ipc_base + IPCMxMSET(IPC_TX_MBOX));
+
+ /* Init receive mailbox */
+ __raw_writel(CHAN_MASK(M3_SOURCE),
+ ipc_base + IPCMxSOURCE(IPC_RX_MBOX));
+ __raw_writel(CHAN_MASK(A9_SOURCE),
+ ipc_base + IPCMxDSET(IPC_RX_MBOX));
+ __raw_writel(CHAN_MASK(M3_SOURCE) | CHAN_MASK(A9_SOURCE),
+ ipc_base + IPCMxMSET(IPC_RX_MBOX));
+
+ return 0;
+err:
+ iounmap(ipc_base);
+ return ret;
+}
+
+static struct amba_id pl320_ids[] = {
+ {
+ .id = 0x00041320,
+ .mask = 0x000fffff,
+ },
+ { 0, 0 },
+};
+
+static struct amba_driver pl320_driver = {
+ .drv = {
+ .name = "pl320",
+ },
+ .id_table = pl320_ids,
+ .probe = pl320_probe,
+};
+
+static int __init ipc_init(void)
+{
+ return amba_driver_register(&pl320_driver);
+}
+module_init(ipc_init);
diff --git a/include/linux/mailbox.h b/include/linux/mailbox.h
index e8e4131..ac50a03 100644
--- a/include/linux/mailbox.h
+++ b/include/linux/mailbox.h
@@ -1,4 +1,16 @@
-/* mailbox.h */
+/*
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope 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.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program. If not, see <http://www.gnu.org/licenses/>.
+ */
typedef u32 mbox_msg_t;
struct omap_mbox;
@@ -20,3 +32,8 @@ void omap_mbox_save_ctx(struct omap_mbox *mbox);
void omap_mbox_restore_ctx(struct omap_mbox *mbox);
void omap_mbox_enable_irq(struct omap_mbox *mbox, omap_mbox_irq_t irq);
void omap_mbox_disable_irq(struct omap_mbox *mbox, omap_mbox_irq_t irq);
+
+int ipc_transmit(u32 *data);
+
+extern int pl320_ipc_register_notifier(struct notifier_block *nb);
+extern int pl320_ipc_unregister_notifier(struct notifier_block *nb);
--
1.7.11.7
^ permalink raw reply related
* [PATCH 2/6 v5] clk, highbank: Prevent glitches in non-bypass reset mode
From: Mark Langsdorf @ 2012-11-27 15:04 UTC (permalink / raw)
To: linux-kernel, cpufreq, linux-pm, linux-arm-kernel
Cc: Mark Langsdorf, Rob Herring, mturquette
In-Reply-To: <1354028674-23685-1-git-send-email-mark.langsdorf@calxeda.com>
The highbank clock will glitch with the current code if the
clock rate is reset without relocking the PLL. Program the PLL
correctly to prevent glitches.
Signed-off-by: Mark Langsdorf <mark.langsdorf@calxeda.com>
Signed-off-by: Rob Herring <rob.herring@calxeda.com>
Cc: mturquette@linaro.org
---
Changes from v4
None.
Changes from v3
Changelog text and patch name now correspond to the actual patch.
was clk, highbank: remove non-bypass reset mode.
Changes from v2
None.
Changes from v1:
Removed erroneous reformating.
drivers/clk/clk-highbank.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/clk/clk-highbank.c b/drivers/clk/clk-highbank.c
index 52fecad..3a0b723 100644
--- a/drivers/clk/clk-highbank.c
+++ b/drivers/clk/clk-highbank.c
@@ -182,8 +182,10 @@ static int clk_pll_set_rate(struct clk_hw *hwclk, unsigned long rate,
reg |= HB_PLL_EXT_ENA;
reg &= ~HB_PLL_EXT_BYPASS;
} else {
+ writel(reg | HB_PLL_EXT_BYPASS, hbclk->reg);
reg &= ~HB_PLL_DIVQ_MASK;
reg |= divq << HB_PLL_DIVQ_SHIFT;
+ writel(reg | HB_PLL_EXT_BYPASS, hbclk->reg);
}
writel(reg, hbclk->reg);
--
1.7.11.7
^ permalink raw reply related
* [PATCH 1/6 v5] arm: use devicetree to get smp_twd clock
From: Mark Langsdorf @ 2012-11-27 15:04 UTC (permalink / raw)
To: linux-kernel, cpufreq, linux-pm, linux-arm-kernel
Cc: Mark Langsdorf, Rob Herring
In-Reply-To: <1354028674-23685-1-git-send-email-mark.langsdorf@calxeda.com>
From: Rob Herring <rob.herring@calxeda.com>
Signed-off-by: Rob Herring <rob.herring@calxeda.com>
Signed-off-by: Mark Langsdorf <mark.langsdorf@calxeda.com>
---
Changes from v4
None.
Changes from v3
No longer setting *clk to NULL in twd_get_clock().
Changes from v2
Turned the check for the node pointer into an if-then-else statement.
Removed the second, redundant clk_get_rate.
Changes from v1
None.
arch/arm/kernel/smp_twd.c | 19 +++++++++++--------
1 file changed, 11 insertions(+), 8 deletions(-)
diff --git a/arch/arm/kernel/smp_twd.c b/arch/arm/kernel/smp_twd.c
index b22d700..af46b80 100644
--- a/arch/arm/kernel/smp_twd.c
+++ b/arch/arm/kernel/smp_twd.c
@@ -237,12 +237,15 @@ static irqreturn_t twd_handler(int irq, void *dev_id)
return IRQ_NONE;
}
-static struct clk *twd_get_clock(void)
+static struct clk *twd_get_clock(struct device_node *np)
{
struct clk *clk;
int err;
- clk = clk_get_sys("smp_twd", NULL);
+ if (np)
+ clk = of_clk_get(np, 0);
+ else
+ clk = clk_get_sys("smp_twd", NULL);
if (IS_ERR(clk)) {
pr_err("smp_twd: clock not found: %d\n", (int)PTR_ERR(clk));
return clk;
@@ -263,6 +266,7 @@ static struct clk *twd_get_clock(void)
return ERR_PTR(err);
}
+ twd_timer_rate = clk_get_rate(clk);
return clk;
}
@@ -273,12 +277,7 @@ static int __cpuinit twd_timer_setup(struct clock_event_device *clk)
{
struct clock_event_device **this_cpu_clk;
- if (!twd_clk)
- twd_clk = twd_get_clock();
-
- if (!IS_ERR_OR_NULL(twd_clk))
- twd_timer_rate = clk_get_rate(twd_clk);
- else
+ if (IS_ERR_OR_NULL(twd_clk))
twd_calibrate_rate();
__raw_writel(0, twd_base + TWD_TIMER_CONTROL);
@@ -349,6 +348,8 @@ int __init twd_local_timer_register(struct twd_local_timer *tlt)
if (!twd_base)
return -ENOMEM;
+ twd_clk = twd_get_clock(NULL);
+
return twd_local_timer_common_register();
}
@@ -383,6 +384,8 @@ void __init twd_local_timer_of_register(void)
goto out;
}
+ twd_clk = twd_get_clock(np);
+
err = twd_local_timer_common_register();
out:
--
1.7.11.7
^ permalink raw reply related
* Re: [PATCHv9 1/3] Runtime Interpreted Power Sequences
From: Laurent Pinchart @ 2012-11-27 14:47 UTC (permalink / raw)
To: Thierry Reding
Cc: Alexandre Courbot,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Stephen Warren, linux-pm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org,
Mark Brown, Mark Zhang, Rob Herring,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Tomi Valkeinen, Anton Vorontsov,
linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
David Woodhouse,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
In-Reply-To: <20121121114018.GA31576-RM9K5IK7kjIyiCvfTdI0JKcOhU4Rzj621B7CTYaBSLdn68oJJulU0Q@public.gmane.org>
[-- Attachment #1.1: Type: text/plain, Size: 10167 bytes --]
Hi Thierry,
Sorry for the late reply.
On Wednesday 21 November 2012 12:40:18 Thierry Reding wrote:
> On Wed, Nov 21, 2012 at 01:06:03PM +0200, Tomi Valkeinen wrote:
> > On 2012-11-21 06:23, Alex Courbot wrote:
> > > On Wednesday 21 November 2012 05:54:29 Grant Likely wrote:
> > >>> With the advent of the device tree and of ARM kernels that are not
> > >>> board-tied, we cannot rely on these board-specific hooks anymore but
> > >>
> > >> This isn't strictly true. It is still perfectly fine to have board
> > >> specific code when necessary. However, there is strong encouragement to
> > >> enable that code in device drivers as much as possible and new board
> > >> files need to have very strong justification.
> > >
> > > But doesn't introducing board-specific code into the kernel just defeats
> > > the purpose of the DT? If we extend this logic, we are heading straight
> > > back to board-definition files. To a lesser extent than before I agree,
> > > but the problem is fundamentally the same.
> >
> > I don't think so. I'll reiterate my opinion on this subject, as a
> > summary and for those who haven't read the discussions of the earlier
> > versions of the series. And perhaps I'll even manage to say something
> > new =).
> >
> >
> > First about the board specific code. I think we may need some board
> > specific code, even if this series was merged. Let's call them board
> > drivers. These board drivers would only exist for boards with some weird
> > setups that cannot be expressed or managed with DT and normal drivers.
> >
> > I think these cases would be quite rare, as I can't even come up with a
> > very good example. I guess most likely these cases would involve some
> > small trivial chips for muxing or such, for which it doesn't really make
> > sense to have a real driver.
> >
> > Say, perhaps a board with two LCDs connected to one video output, and
> > only one LCD can be enabled at a time, and you need to set some mux chip
> > to route the signals to the correct LCD. In this case I'd see we should
> > have hotplug support in the display framework, and the board driver
> > would act on user input (sysfs file, perhaps), plugging in/out the LCD
> > device depending on the user input.
> >
> >
> > As for expressing device internal details in the DT data, as done in
> > this series, I don't like it very much. I think the DT data or the board
> > file should just describe which device is the one in question, and how
> > it's connected to other components on the board. The driver for the
> > device should handle everything else.
> >
> > As Alex pointed out, there may be lots of devices that work the same way
> > when enabled, but require slightly different power-on/off sequences. We
> > could have these sequences in the driver itself, either as plain code,
> > or in a table of some sort, possibly using the power sequence framework
> > presented in this series. The correct code or sequence would be ran
> > depending on the particular model of the device.
> >
> > I think this approach is correct in the sense that this is what drivers
> > are supposed to do: handle all the device internal matters. But this
> > raises the problem of bloating the kernel with possibly lots of
> > different power sequences, of which only a few would be used by a board,
> > and all the rest would just be waste of memory.
> >
> > Regarding this problem I have the following questions, to which I don't
> > have clear answers:
> >
> > - How much of this device specific data is too much? If a driver
> > supports 10 different models, and the sequences for each model take 100
> > bytes, this 1000 bytes doesn't sound too much. But where's the limit?
> > And even if one driver only has 1kB of this data, what if we have lots
> > of similar drivers?
> >
> > - How many bytes does a power sequence presented in this series take, if
> > the sequence contains, say, 5 steps, with gpio, delay, pwm, delay and
> > regulator?
> >
> > - How likely is it that we'll get lots of different models? A hundred
> > different models for a backlight PWM with different power-on/off
> > sequences already sounds a really big number. If we're only going to
> > have each driver supporting, say, no more than 10 models, perhaps the
> > problem is not even an issue in practice.
> >
> > - Are there ways to limit this bloat in the driver? One obvious way
> > would be to discard the unused sequences after driver probe, but that
> > only works for platform devices. Although, I guess these sequences would
> > mostly be used by platform drivers? If so, then the problem could be
> > solved by discarding the data after probe. Another would be to load the
> > sequences from a file as firmware, but that feels quite an awful
> > solution. Anybody have other ideas?
> >
> > One clear positive side with in-driver approach is that it's totally
> > inside the kernel, and can be easily reworked in the future, or even
> > changed to a DT-based approach as presented in this series if that seems
> > like a better solution. The DT based approach, on the other hand, will
> > be more or less written to stone after it's merged.
> >
> >
> > So, I like the framework of expressing the sequences presented in this
> > series (except there's a problem with error cases, as I pointed out in
> > another post), as it can be used inside the drivers. But I'm not so
> > enthusiastic about presenting the sequences in DT.
> >
> > My suggestion would be to go forward with an in-driver solution, and
> > look at the DT based solution later if we are seeing an increasing bloat
> > in the drivers.
>
> Assuming we go with your approach, what's the plan? We're actually
> facing this problem right now for Tegra. Basically we have a DRM driver
> that can drive the panel, but we're still missing a way to hook up the
> backlight and panel enabling code. So we effectively can't support any
> of the LVDS devices out there without this series.
>
> As I understand it, what you propose is similar to what ASoC does. For a
> specific board, you'd have to write a driver, presumably for the new
> panel/display framework, that provides code to power the panel on and
> off. That means we'll have to have a driver for each panel out there
> basically, or we'd need to write generic drivers that can be configured
> to some degree (via platform data or DT). This is similar to how ASoC
> works, where we have a driver that provides support for a specific codec
> connected to the Tegra SoC. For the display framework things could be
> done in a similar way I suppose, so that Tegra could have one display
> driver to handle all aspects of powering on and off the various panels
> for the various boards out there.
The common display framework (CDF) includes a driver for dumb parallel panels
called panel-dpi. It doesn't handle complex power on/off sequences yet as I
haven't run into any need for them, but that's definitely something we could
add, possibly using Alexandre's code to express the sequences. Similarly to
Tomi, my preferences go for including the sequences in drivers.
> Obviously, a lot of the code will be similar for other SoCs, but maybe
> that's just the way things are if we choose that approach. There's also
> the potential for factoring out large chunks of common code later on
> once we start to see common patterns.
I don't mind duplicating some code in different drivers as a first step.
Factoring out common code in a second step is easier (at least for me) than
trying to figure out what the common code would look like before the first
driver is even written.
> One thing that's not very clear is how the backlight subsystem should be
> wired up with the display framework. I have a patch on top of the Tegra
> DRM driver which adds some ad-hoc display support using this power
> sequences series and the pwm-backlight.
I've touched the backlight API a bit, from both the provider and consumer
points of view, and my feeling is that the API will need to be reworked to
neatly integrate with the CDF. The backlight API currently depends on fbdev,
that's something we should aim to remove. Proposals are welcome :-) Should we
create a separate mail thread for this ?
> From reading the proposal for the panel/display framework, it sounds
> like a lot more is planned than just enabling or disabling panels,
That's correct. CDF implements several other panel control operations (to
retrieve the list of modes supported by the panel for instance), and more
operations will be needed in the future. I've decided to only implement in the
RFC operations that I need for the platforms I work on, and let other
developers propose additional operations depending on their use cases.
> but it also seems like a lot of code needs to be written to support things
> like DSI, DBI or other control busses.
I don't think we need that much code there. The most common control busses for
display hardware are DSI, DBI, I2C, SPI and plain GPIOs. The last three
control busses are well supported in the Linux kernel, I've implemented DBI
support as part of the CDF RFC, and DSI support is missing. If you look at the
DBI bus implementation the amount of code isn't overly large.
> At least for Tegra, and I think the same holds for a wide variety of other
> SoCs, dumb panels would be enough for a start. In the interest of getting a
> working solution for those setups, maybe we can start small and add just
> enough framework to register dumb panel drivers to along with code to wire
> up a backlight to light up the display. Then we could possibly still make it
> to have a proper solution to support the various LVDS panels for Tegra with
> 3.9.
>
> I'm adding Laurent on Cc since he's probably busy working on a new
> proposal for the panel/display framework. Maybe he can share his thought
> on this.
>
> All of the above said, I'm willing to help out with the coding if that's
> what is required to reach a solution that everybody can be happy with.
That's much appreciated. If that means a couple additional hours of sleep per
week for me I'll be extremely thankful :-)
--
Regards,
Laurent Pinchart
[-- Attachment #1.2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
[-- Attachment #2: Type: text/plain, Size: 192 bytes --]
_______________________________________________
devicetree-discuss mailing list
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
^ permalink raw reply
* Re: [PATCH] cpufreq: SPEAr: Add CPUFreq driver
From: Rafael J. Wysocki @ 2012-11-27 12:06 UTC (permalink / raw)
To: Viresh Kumar
Cc: linux-pm, Shawn Guo, Shiraz HASHIM, Deepak SIKRI,
devicetree-discuss, spear-devel, cpufreq, Mike Turquette,
linux-arm-kernel
In-Reply-To: <CAKohpo=XirzP5Dj5kZq8Ou7D-W8CjfT8m=_vpjim4oH9jXfdQQ@mail.gmail.com>
On Tuesday, November 27, 2012 05:05:47 PM Viresh Kumar wrote:
> On 27 November 2012 17:08, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> > On Tuesday, November 27, 2012 09:28:01 AM Viresh Kumar wrote:
> >> On 27 November 2012 09:31, Shawn Guo <shawn.guo@linaro.org> wrote:
> >> > On Sun, Nov 25, 2012 at 01:09:28AM +0530, Viresh Kumar wrote:
> >> >> +cpufreq {
> >> >> + compatible = "st,cpufreq-spear";
> >> >
> >> > I do not think we need a "cpufreq" node, as we already have node for
> >> > cpu to contain these.
> >>
> >> Hmm.. Yes, can be done.
> >
> > OK, so changes are going to be made to the driver, right?
> >
> > I'll drop it then and please resubmit when ready (and tested) after the changes.
>
> Yes, for now this would be the only change i have. I can resend it right now,
> if you can still pick it for 3.8.
Yes, I think I can take it for v3.8 if you resubmit shortly.
Thanks,
Rafael
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
^ permalink raw reply
* Re: [PATCH] cpufreq: SPEAr: Add CPUFreq driver
From: Rafael J. Wysocki @ 2012-11-27 11:38 UTC (permalink / raw)
To: linux-pm
Cc: Viresh Kumar, Shawn Guo, Shiraz HASHIM, Deepak SIKRI,
devicetree-discuss, spear-devel, cpufreq, Mike Turquette,
linux-arm-kernel
In-Reply-To: <CAKohpomSAogQVeBQ8HaWwwoTVCsMha5d_1Wid6N3t5SnVZTc=w@mail.gmail.com>
On Tuesday, November 27, 2012 09:28:01 AM Viresh Kumar wrote:
> Hi Shawn,
>
> Thanks for feedback.
>
> On 27 November 2012 09:31, Shawn Guo <shawn.guo@linaro.org> wrote:
> > On Sun, Nov 25, 2012 at 01:09:28AM +0530, Viresh Kumar wrote:
> >> +cpufreq {
> >> + compatible = "st,cpufreq-spear";
> >
> > I do not think we need a "cpufreq" node, as we already have node for
> > cpu to contain these.
>
> Hmm.. Yes, can be done.
OK, so changes are going to be made to the driver, right?
I'll drop it then and please resubmit when ready (and tested) after the changes.
Thanks,
Rafael
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
^ permalink raw reply
* Re: [PATCH] cpufreq: SPEAr: Add CPUFreq driver
From: Viresh Kumar @ 2012-11-27 11:35 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: linux-pm, Shawn Guo, Shiraz HASHIM, Deepak SIKRI,
devicetree-discuss, spear-devel, cpufreq, Mike Turquette,
linux-arm-kernel
In-Reply-To: <1728458.5AqJNfNVgK@vostro.rjw.lan>
On 27 November 2012 17:08, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> On Tuesday, November 27, 2012 09:28:01 AM Viresh Kumar wrote:
>> On 27 November 2012 09:31, Shawn Guo <shawn.guo@linaro.org> wrote:
>> > On Sun, Nov 25, 2012 at 01:09:28AM +0530, Viresh Kumar wrote:
>> >> +cpufreq {
>> >> + compatible = "st,cpufreq-spear";
>> >
>> > I do not think we need a "cpufreq" node, as we already have node for
>> > cpu to contain these.
>>
>> Hmm.. Yes, can be done.
>
> OK, so changes are going to be made to the driver, right?
>
> I'll drop it then and please resubmit when ready (and tested) after the changes.
Yes, for now this would be the only change i have. I can resend it right now,
if you can still pick it for 3.8.
--
viresh
^ permalink raw reply
* Re: PROBLEM: resuming from suspend-to-ram hangs
From: Adrian Byszuk @ 2012-11-27 10:42 UTC (permalink / raw)
To: MyungJoo Ham; +Cc: linux-pm
In-Reply-To: <CAJ0PZbSwbU-Lkbc66n7KCLXobR1si=M0NsaK1qo96f7dV4CsXg@mail.gmail.com>
On 27/11/12 03:10, MyungJoo Ham wrote:
> On Tue, Nov 27, 2012 at 2:14 AM, Adrian Byszuk <adrian.byszuk@gmail.com> wrote:
>> Hello all-mighty linux kernel developers.
>>
>> My laptop (Asus F3F-AP075) can't wake up from suspend to RAM, it seems
>> to hang completely while resuming. What seems to be a bit odd, is that
>> LED for HDD lights on all the time while the system is hanged.
>> To be more precise: s2ram used to work on this notebook, but it stopped
>> to. Some time ago I changed the HDD from typical 2.5' hard drive to an
>> OCZ Vertex4 SSD drive (and installed a new distribution on it) - I think
>> that's the moment it stopped working (however I'm not suspending often,
>> so it could also be a pure coincidence).
>> This problem is 100% reproducible on both Debian 3.2 kernel and vanilla
>> 3.6.x kernels.
>>
>> Following the Documentation/power/s2ram.txt I've got something like this
>> from dmesg:
>> [ 0.253496] Magic number: 0:56:890
>> [ 0.253501] hash matches drivers/base/power/main.c:571
>> [ 0.253542] pci 0000:00:1f.3: hash matches
>>
>> and PCI 00:1f.3 device is:
>> 00:1f.3 SMBus: Intel Corporation N10/ICH 7 Family SMBus Controller (rev 02)
>>
>> I'm willing to debug this by myself, but I need your help. Could someone
>> tell where to start looking?
>>
>> Regards,
>> Adrian
>>
>
> Have you tested with console_suspend (or was it suspend_console?)
> disabled without X ?
I've tried suspending without X, no change.
I've just tested it with console_suspend disabled and got this:
[ 136.708075] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6
frozen
[ 136.708156] ata1.00: failed command: READ VERIFY SECTOR(S)
[ 136.708221] ata1.00: cmd 40/00:01:00:00:00/00:00:00:00:00/e0 tag 0
[ 136.708221] res 40/00:00:00:00:00/00:00:00:00:00/40 Emask 0x4
(timeout)
[ 136.708352] ata1.00: status: [DRDY]
[ 156.800057] ata1: SRST failed (errno=-16)
[ 166.845059] ata1: SRST failed (errno=-16)
^ permalink raw reply
* Re: [PATCH] cpuidle: Measure idle state durations with monotonic clock
From: Len Brown @ 2012-11-27 6:15 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Julius Werner, linux-kernel, Kevin Hilman, Andrew Morton,
Srivatsa S. Bhat, linux-acpi, linux-pm, linuxppc-dev,
Deepthi Dharwar, Trinabh Gupta, Sameer Nanda, Lists Linaro-dev,
Daniel Lezcano
In-Reply-To: <3364211.o5ZCq4Y6Je@vostro.rjw.lan>
>> drivers/idle/intel_idle.c | 14 +-----
Acked-by: Len Brown <len.brown@intel.com>
thanks!
-Len
^ permalink raw reply
* Re: [PATCH] cpuidle: Measure idle state durations with monotonic clock
From: Len Brown @ 2012-11-27 6:14 UTC (permalink / raw)
To: Preeti Murthy
Cc: Julius Werner, linux-kernel, Rafael J. Wysocki, Kevin Hilman,
Andrew Morton, Srivatsa S. Bhat, linux-acpi, linux-pm,
linuxppc-dev, Deepthi Dharwar, Trinabh Gupta, Sameer Nanda,
Lists Linaro-dev, Daniel Lezcano, Peter Zijlstra
In-Reply-To: <CAM4v1pPhaP=pVnFMXUU_nmrOxhY5yPNtbBdQsT5MH37MndK6LQ@mail.gmail.com>
On 11/15/2012 04:04 AM, Preeti Murthy wrote:
> Hi all,
>
> The code looks correct and inviting to me as it has led to good cleanups.
> I dont think passing 0 as the argument to the function
> sched_clock_idle_wakeup_event()
> should lead to problems,as it does not do anything useful with the
> passed arguments.
>
> My only curiosity is what was the purpose of passing idle residency time to
> sched_clock_idle_wakeup_event() when this data could always be retrieved from
> dev->last_residency for each cpu,which gets almost immediately updated.
sched_clock_idle_wakeup_event() is part of the scheduler.
The scheduler doesn't know what a cpuidle_device is, and
probably should not grow such a dependency.
cheers,
-Len Brown, Intel Open Source Technology Center
> But this does not seem to come in way of this patch for now.Anyway I
> have added Peter to
> the list so that he can opine about this issue if possible and needed.
>
> Reviewed-by: Preeti U Murthy <preeti@linux.vnet.ibm.com>
>
>
> Regards
> Preeti U Murthy
>
^ permalink raw reply
* RE: [PATCH 2/2] platform / ACPI: Attach/detach ACPI PM during probe/remove/shutdown
From: Zheng, Lv @ 2012-11-27 5:24 UTC (permalink / raw)
To: Rafael J. Wysocki, LKML
Cc: Greg Kroah-Hartman, Linux PM list, ACPI Devel Maling List,
Zhang, Rui, Svahn, Kai, Mika Westerberg, Huang, Ying, Lan, Tianyu,
Lu, Aaron, Grant Likely
In-Reply-To: <6227446.8xPtqi6yHi@vostro.rjw.lan>
It looks cleanest unless more abstractions are introduced for other power management providers.
Best regards/Lv Zheng
> -----Original Message-----
> From: Rafael J. Wysocki [mailto:rjw@sisk.pl]
> Sent: Sunday, November 25, 2012 10:58 PM
> To: LKML
> Cc: Greg Kroah-Hartman; Linux PM list; ACPI Devel Maling List; Zhang, Rui;
> Svahn, Kai; Mika Westerberg; Huang, Ying; Lan, Tianyu; Zheng, Lv; Lu, Aaron;
> Grant Likely
> Subject: [PATCH 2/2] platform / ACPI: Attach/detach ACPI PM during
> probe/remove/shutdown
>
> From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
>
> Drivers usually expect that the devices they are supposed to handle will be
> operational when their .probe() routines are called, but that need not be the
> case on some ACPI-based systems with ACPI-based device enumeration where
> the BIOSes don't put devices into D0 by default. To work around this problem
> it is sufficient to change bus type .probe() routines to ensure that devices will
> be powered on before the drivers' .probe() routines run (and their .remove()
> and .shutdown() routines accordingly).
>
> Modify platform_drv_probe() to run acpi_dev_pm_attach() for devices whose
> ACPI handles are present, so that ACPI power management is used to change
> their power states and change their power states to D0 before driver probing.
> Analogously, modify platform_drv_remove() and
> platform_drv_shutdown() to call acpi_dev_pm_detach() for those devices, so
> that they are not subject to ACPI PM any more.
>
> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> ---
> drivers/base/platform.c | 19 +++++++++++++++++--
> 1 file changed, 17 insertions(+), 2 deletions(-)
>
> Index: linux/drivers/base/platform.c
> ================================================================
> ===
> --- linux.orig/drivers/base/platform.c
> +++ linux/drivers/base/platform.c
> @@ -484,8 +484,16 @@ static int platform_drv_probe(struct dev {
> struct platform_driver *drv = to_platform_driver(_dev->driver);
> struct platform_device *dev = to_platform_device(_dev);
> + int ret;
>
> - return drv->probe(dev);
> + if (ACPI_HANDLE(_dev))
> + acpi_dev_pm_attach(_dev, true);
> +
> + ret = drv->probe(dev);
> + if (ret && ACPI_HANDLE(_dev))
> + acpi_dev_pm_detach(_dev, true);
> +
> + return ret;
> }
>
> static int platform_drv_probe_fail(struct device *_dev) @@ -497,8 +505,13
> @@ static int platform_drv_remove(struct de {
> struct platform_driver *drv = to_platform_driver(_dev->driver);
> struct platform_device *dev = to_platform_device(_dev);
> + int ret;
> +
> + ret = drv->remove(dev);
> + if (ACPI_HANDLE(_dev))
> + acpi_dev_pm_detach(_dev, true);
>
> - return drv->remove(dev);
> + return ret;
> }
>
> static void platform_drv_shutdown(struct device *_dev) @@ -507,6 +520,8
> @@ static void platform_drv_shutdown(struct
> struct platform_device *dev = to_platform_device(_dev);
>
> drv->shutdown(dev);
> + if (ACPI_HANDLE(_dev))
> + acpi_dev_pm_detach(_dev, true);
> }
>
> /**
^ permalink raw reply
* Re: [k.org requests #104] Please add 2 categories
From: Len Brown via RT @ 2012-11-27 2:43 UTC (permalink / raw)
Cc: linux-pm
In-Reply-To: <50B428D9.6080906@kernel.org>
Konstantin,
Please sent the default assignees as below.
They may not be perfect, but they are better than totally broken:-)
thanks!
-Len
On 10/30/2012 11:24 AM, Konstantin Ryabitsev via RT wrote:
> On Tue Oct 30 15:10:36 2012, lenb@kernel.org wrote:
>> Dear Bugzilla Admins,
>>
>> Please add 2 additional Categories under Product "Power Management":
>>
>> Run-Time-PM - Issues related to Linux Device Run Time Power
>> Management.
"Rafael J. Wysocki" <rjw@sisk.pl>
>>
>> Thermal - Issues related to OS-visible Thermal Management, such as
>> throttling.
Zhang Rui <rui.zhang@intel.com>
> Sure, but I'll need "default assignee" for both of these.
>
> Speaking of default assignees, kernel-bugs.osdl.org doesn't appear to
> exist any more either, so the following will need to be adjusted as well:
>
> cpuidle power-management_cpuidle@kernel-bugs.osdl.org
lenb@kernel.org
> Hibernation/Suspend power-management_other@kernel-bugs.osdl.org
"Rafael J. Wysocki" <rjw@sisk.pl>
> intel_idle power-management_intel_idle@kernel-bugs.osdl.org
lenb@kernel.org
> Other power-management_other@kernel-bugs.osdl.org
"Rafael J. Wysocki" <rjw@sisk.pl>
^ permalink raw reply
* Re: [k.org requests #104] Please add 2 categories
From: Len Brown @ 2012-11-27 2:43 UTC (permalink / raw)
To: rt; +Cc: linux-pm, Zhang Rui, Rafael J. Wysocki
In-Reply-To: <rt-3.8.13-793-1351610640-1281.104-7-0@kernel.org>
Konstantin,
Please sent the default assignees as below.
They may not be perfect, but they are better than totally broken:-)
thanks!
-Len
On 10/30/2012 11:24 AM, Konstantin Ryabitsev via RT wrote:
> On Tue Oct 30 15:10:36 2012, lenb@kernel.org wrote:
>> Dear Bugzilla Admins,
>>
>> Please add 2 additional Categories under Product "Power Management":
>>
>> Run-Time-PM - Issues related to Linux Device Run Time Power
>> Management.
"Rafael J. Wysocki" <rjw@sisk.pl>
>>
>> Thermal - Issues related to OS-visible Thermal Management, such as
>> throttling.
Zhang Rui <rui.zhang@intel.com>
> Sure, but I'll need "default assignee" for both of these.
>
> Speaking of default assignees, kernel-bugs.osdl.org doesn't appear to
> exist any more either, so the following will need to be adjusted as well:
>
> cpuidle power-management_cpuidle@kernel-bugs.osdl.org
lenb@kernel.org
> Hibernation/Suspend power-management_other@kernel-bugs.osdl.org
"Rafael J. Wysocki" <rjw@sisk.pl>
> intel_idle power-management_intel_idle@kernel-bugs.osdl.org
lenb@kernel.org
> Other power-management_other@kernel-bugs.osdl.org
"Rafael J. Wysocki" <rjw@sisk.pl>
^ permalink raw reply
* Re: PROBLEM: resuming from suspend-to-ram hangs
From: MyungJoo Ham @ 2012-11-27 2:10 UTC (permalink / raw)
To: Adrian Byszuk; +Cc: linux-pm
In-Reply-To: <50B3A371.10101@gmail.com>
On Tue, Nov 27, 2012 at 2:14 AM, Adrian Byszuk <adrian.byszuk@gmail.com> wrote:
> Hello all-mighty linux kernel developers.
>
> My laptop (Asus F3F-AP075) can't wake up from suspend to RAM, it seems
> to hang completely while resuming. What seems to be a bit odd, is that
> LED for HDD lights on all the time while the system is hanged.
> To be more precise: s2ram used to work on this notebook, but it stopped
> to. Some time ago I changed the HDD from typical 2.5' hard drive to an
> OCZ Vertex4 SSD drive (and installed a new distribution on it) - I think
> that's the moment it stopped working (however I'm not suspending often,
> so it could also be a pure coincidence).
> This problem is 100% reproducible on both Debian 3.2 kernel and vanilla
> 3.6.x kernels.
>
> Following the Documentation/power/s2ram.txt I've got something like this
> from dmesg:
> [ 0.253496] Magic number: 0:56:890
> [ 0.253501] hash matches drivers/base/power/main.c:571
> [ 0.253542] pci 0000:00:1f.3: hash matches
>
> and PCI 00:1f.3 device is:
> 00:1f.3 SMBus: Intel Corporation N10/ICH 7 Family SMBus Controller (rev 02)
>
> I'm willing to debug this by myself, but I need your help. Could someone
> tell where to start looking?
>
> Regards,
> Adrian
>
Have you tested with console_suspend (or was it suspend_console?)
disabled without X ?
--
MyungJoo Ham, Ph.D.
System S/W Lab, S/W Center, Samsung Electronics
^ permalink raw reply
* Re: [PATCH v9 06/10] ata: zpodd: check zero power ready status
From: Aaron Lu @ 2012-11-27 1:41 UTC (permalink / raw)
To: James Bottomley
Cc: Rafael J. Wysocki, Tejun Heo, Jeff Garzik, Alan Stern, Jeff Wu,
Aaron Lu, linux-ide, linux-pm, linux-scsi, linux-acpi
In-Reply-To: <1353935850.2523.52.camel@dabdike>
On 11/26/2012 09:17 PM, James Bottomley wrote:
> On Mon, 2012-11-26 at 16:27 +0800, Aaron Lu wrote:
>> Well, ZPREADY is not a power state that we can program the ODD to
>> enter(figure 234 and table 323 of the SPEC), it servers more like an
>> information provided by ODD to host so that host does not need to do TUR
>> and then examine the sense code to decide if zero power ready status is
>> satisfied but simply query ODD if its current power state is ZPREADY.
>> So it's not that we program the device to go into ZPREADY power state
>> and the ODD's power will be omitted.
>>
>> The benefit of a ZPREADY capable ODD is that, when we need to decide if
>> the ODD is in a zero power ready status, we can simply query the ODD by
>> issuing a GET_EVENT_STATUS_NOTIFICATION and check the returned power
>> class events, if it is in ZPREADY power state, then we can omit the
>> power. To support ZPREADY, we just need some change to the zpready
>> funtion, which currently uses sense code to check ZP ready status.
>>
>> So this is my understanding of ZPREADY, and I don't see it as a total
>> different thing with ZPODD, it just changes the way how host senses the
>> zero power ready status. But if I was wrong, please kindly let me know,
>> thanks.
>
> My understanding is that a ZPREADY device may be capable of internal
> power down, meaning it doesn't necessarily need the host to omit the
> power. It depends what the difference is between Sleep and Off is
> (they're deliberately left as implementation defined in the standard, Ch
> 16, but the conditions of sleep are pretty onerous, so it sounds like
> most of the mechanics are powered down).
I Agree that when the ODD is put to Sleep state, it may power down most
of the mechanics, good for power saving. The problem is, we have the 2
seconds poll, and since Sleep state can not process any command, we will
need to bring the ODD out of Sleep state every 2 seconds, is this
feasible? Please note that leaving Sleep state needs full initialization
of the ODD.
ZPODD system(ODD+platform) solves this problem with ACPI, when the ODD
is powered off and any event that may induce a media change event will
generate an ACPI interrupt, so we can stop the poll(though in whatever
way is still in discussion).
So I suppose we need to find a proper way to implement Sleep.
>
> However, if you want to work it similarly to ZPODD, then the timeouts
> automatically transitions to ZPREADY, the device issues an event, we
> trap the event at the low level and omit power.
Yeah, I can do this. Except that I don't quite understand how the device
issues the event to host, by interrupt? My understanding is that, it
will issue this event to itself...and host still needs to use command
GET_EVENT_STATUS_NOTIFICATION to fetch the event, much the same way like
the media related events it emits.
>
> I'm also curious about driving sleep from autopm, since mode page timers
> don't control the sleep transition.
I see. But we will need to work out a sensible way to put the ODD into
that power state, if at all possible.
Thanks,
Aaron
^ permalink raw reply
* Re: [PATCH v2 3/3] PM: Introduce Intel PowerClamp Driver
From: Joe Perches @ 2012-11-26 23:27 UTC (permalink / raw)
To: Jacob Pan
Cc: Linux PM, LKML, Peter Zijlstra, Rafael Wysocki, Len Brown,
Thomas Gleixner, H. Peter Anvin, Ingo Molnar, Zhang Rui,
Rob Landley, Arjan van de Ven, Paul McKenney
In-Reply-To: <1353940633-20084-4-git-send-email-jacob.jun.pan@linux.intel.com>
On Mon, 2012-11-26 at 06:37 -0800, Jacob Pan wrote:
> Intel PowerClamp driver performs synchronized idle injection across
> all online CPUs. The goal is to maintain a given package level C-state
> ratio.
trivial notes:
> diff --git a/drivers/thermal/intel_powerclamp.c b/drivers/thermal/intel_powerclamp.c
You should still add #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
before any include so that all messages are prefixed with powerclamp:
> +
> +/* #define DEBUG */
> +
> +#include <linux/module.h>
> +#include <linux/kernel.h>
[]
> +static void adjust_compensation(int target_ratio, unsigned int win)
> +{
> + int delta;
It'd be shorter code to use a temporary like
struct powerclamp_calibration_data *d = &cal_data[target_ratio];
> +
> + /*
> + * adjust compensations if confidence level has not been reached or
> + * there are too many wakeups during the last idle injection period, we
> + * cannot trust the data for compensation.
> + */
> + if (cal_data[target_ratio].confidence >= CONFIDENCE_OK ||
> + atomic_read(&idle_wakeup_counter) >
> + win * num_online_cpus())
> + return;
> +
> + delta = set_target_ratio - current_ratio;
> + /* filter out bad data */
> + if (delta >= 0 && delta <= (1+target_ratio/10)) {
> + if (cal_data[target_ratio].steady_comp)
> + cal_data[target_ratio].steady_comp =
> + roundup(delta+
> + cal_data[target_ratio].steady_comp,
> + 2)/2;
so that this fits on a single line and becomes:
if (d->steady_comp)
d->steady_comp = roundup(delta + d->steady_comp, 2) / 2;
etc.
What clamps target_ratio to the correct range?
I briefly scanned the code but didn't spot it.
^ permalink raw reply
* [PATCH v3 0/3]
From: Jacob Pan @ 2012-11-26 15:19 UTC (permalink / raw)
To: Linux PM, LKML
Cc: Peter Zijlstra, Rafael Wysocki, Len Brown, Thomas Gleixner,
H. Peter Anvin, Ingo Molnar, Zhang Rui, Rob Landley,
Arjan van de Ven, Paul McKenney, Jacob Pan
Minor syntax change based on Joe Perches comments.
https://lkml.org/lkml/2012/11/13/27
Missed the actual changes in v2.
We have done some experiment with idle injection on Intel platforms.
The idea is to use the increasingly power efficient package level
C-states for power capping and passive thermal control.
Documentation is included in the patch to explain the theory of
operation, performance implication, calibration, scalability, and user
interface. Please refer to the following file for more details.
Documentation/thermal/intel_powerclamp.txt
Arjan van de Ven created the original idea and driver, I have been
refining driver in hope that they can be to be useful beyond a proof
of concept.
Jacob Pan (3):
tick: export nohz tick idle symbols for module use
x86/nmi: export local_touch_nmi() symbol for modules
PM: Introduce Intel PowerClamp Driver
Documentation/thermal/intel_powerclamp.txt | 307 +++++++++++
arch/x86/kernel/nmi.c | 1 +
drivers/thermal/Kconfig | 10 +
drivers/thermal/Makefile | 1 +
drivers/thermal/intel_powerclamp.c | 766 ++++++++++++++++++++++++++++
kernel/time/tick-sched.c | 2 +
6 files changed, 1087 insertions(+)
create mode 100644 Documentation/thermal/intel_powerclamp.txt
create mode 100644 drivers/thermal/intel_powerclamp.c
--
1.7.9.5
^ permalink raw reply
* Re: [alsa-devel] [PATCH] usb: add USB_QUIRK_RESET_RESUME for M-Audio 49
From: Alan Stern @ 2012-11-26 21:54 UTC (permalink / raw)
To: Clemens Ladisch
Cc: Oliver Neukum, Takashi Iwai, Jonathan Nieder, Steffen Müller,
alsa-devel, Olivier MATZ, linux-pm, linux-usb, stable,
David Banks, Ralf Lang
In-Reply-To: <50B3CD29.2060505@ladisch.de>
On Mon, 26 Nov 2012, Clemens Ladisch wrote:
> Alan Stern wrote:
> > On Mon, 26 Nov 2012, Oliver Neukum wrote:
> >> On Monday 26 November 2012 14:43:13 Clemens Ladisch wrote:
> >>> usb_autopm_get_interface() cannot be called from the USB probe callback.
> >>
> >> You can use usb_autopm_get_interface_no_resume()
> >> During probe() the device is known to not be suspended.
> >
> > In fact, as far as I know you _can_ use usb_autopm_get_interface() from
> > within a probe routine. Is there some problem with it I'm not aware of?
>
> It returns -EACCES.
That's odd. -EACCES occurs only when the interface or the device it
belongs to is disabled for runtime PM. But the USB core enables
interfaces before probing, provided the driver's supports_autosuspend
flag is set.
Furthermore, -EACCES can occur in usb_autopm_get_interface() only when
the interface or its device is not currently resumed -- but USB devices
and interfaces are always resumed during a probe.
Do you have any idea about what's going wrong here? Or do I need to
investigate more closely?
Alan Stern
^ permalink raw reply
* Re: [PATCH 8/8] patch cpupower_ivy_bridge_support.patch
From: Rafael J. Wysocki @ 2012-11-26 20:49 UTC (permalink / raw)
To: linux-pm; +Cc: Thomas Renninger, cpufreq, linux
In-Reply-To: <201211261646.16882.trenn@suse.de>
On Monday, November 26, 2012 04:46:16 PM Thomas Renninger wrote:
> On Saturday, November 24, 2012 10:49:52 AM Rafael J. Wysocki wrote:
> > Please add (1) a useful subject, (2) a changelog and (3) a sign-off tag.
> Sure, sorry about that.
> But be careful, this one is wrong:
>
> > > + case 0x2D: /* SNB Xeon */
> > > + case 0x3A: /* IVB */
> > > + case 0x3D: /* IVB Xeon */
> It's family 0x3E
> a copy and paste bug that has been taken over from
> turbostat, there it already got adjusted from 0x3D to 0x3E.
>
> I resend the whole series today or tomorrow.
OK
Should I drop the current one for now?
Rafael
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
^ permalink raw reply
* Re: [alsa-devel] [PATCH] usb: add USB_QUIRK_RESET_RESUME for M-Audio 49
From: Clemens Ladisch @ 2012-11-26 20:12 UTC (permalink / raw)
To: Alan Stern
Cc: Oliver Neukum, Takashi Iwai, Jonathan Nieder, Steffen Müller,
alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw, Olivier MATZ,
linux-pm-u79uwXL29TY76Z2rM5mHXA, linux-usb-u79uwXL29TY76Z2rM5mHXA,
stable-u79uwXL29TY76Z2rM5mHXA, David Banks, Ralf Lang
In-Reply-To: <Pine.LNX.4.44L0.1211261111130.2168-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
Alan Stern wrote:
> On Mon, 26 Nov 2012, Oliver Neukum wrote:
>> On Monday 26 November 2012 14:43:13 Clemens Ladisch wrote:
>>> usb_autopm_get_interface() cannot be called from the USB probe callback.
>>
>> You can use usb_autopm_get_interface_no_resume()
>> During probe() the device is known to not be suspended.
>
> In fact, as far as I know you _can_ use usb_autopm_get_interface() from
> within a probe routine. Is there some problem with it I'm not aware of?
It returns -EACCES.
But _no_resume() appears to work just fine.
Regards,
Clemens
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v9 06/10] ata: zpodd: check zero power ready status
From: James Bottomley @ 2012-11-26 19:15 UTC (permalink / raw)
To: Alan Stern
Cc: Aaron Lu, Rafael J. Wysocki, Tejun Heo, Jeff Garzik, Jeff Wu,
Aaron Lu, linux-ide, linux-pm, linux-scsi, linux-acpi
In-Reply-To: <Pine.LNX.4.44L0.1211261120190.2168-100000@iolanthe.rowland.org>
On Mon, 2012-11-26 at 11:21 -0500, Alan Stern wrote:
> On Mon, 26 Nov 2012, James Bottomley wrote:
>
> > I'm also curious about driving sleep from autopm, since mode page timers
> > don't control the sleep transition.
>
> Is it feasible to do this the other way around? That is, to drive
> runtime suspend by noticing when the device decides to put itself into
> a low-power state?
Well, yes and no. The spec is annoyingly (and deliberately) vague about
what the states actually mean. The two states that the devices go into
because of timers is idle and standby. The supposedly deeper low power
state of sleep can only be reached by sending a command to the device.
The design is that software (or HBA drivers) don't really need to notice
idle and standby; the device automatically manages transitions between
them depending on command activity. For sleep, we do have to care (if
it actually makes some meaningful difference).
James
^ permalink raw reply
* [PATCH] cpufreq: ondemand: update sampling rate only on right CPUs
From: Fabio Baltieri @ 2012-11-26 18:10 UTC (permalink / raw)
To: Rafael J. Wysocki, cpufreq, linux-pm; +Cc: linux-kernel, Fabio Baltieri
Fix cpufreq_gov_ondemand to skip CPU where another governor is used.
The bug present itself as NULL pointer access on the mutex_lock() call,
an can be reproduced on an SMP machine by setting the default governor
to anything other than ondemand, setting a single CPU's governor to
ondemand, then changing the sample rate by writing on:
> /sys/devices/system/cpu/cpufreq/ondemand/sampling_rate
Backtrace:
Nov 26 17:36:54 balto kernel: [ 839.585241] BUG: unable to handle kernel NULL pointer dereference at (null)
Nov 26 17:36:54 balto kernel: [ 839.585311] IP: [<ffffffff8174e082>] __mutex_lock_slowpath+0xb2/0x170
[snip]
Nov 26 17:36:54 balto kernel: [ 839.587005] Call Trace:
Nov 26 17:36:54 balto kernel: [ 839.587030] [<ffffffff8174da82>] mutex_lock+0x22/0x40
Nov 26 17:36:54 balto kernel: [ 839.587067] [<ffffffff81610b8f>] store_sampling_rate+0xbf/0x150
Nov 26 17:36:54 balto kernel: [ 839.587110] [<ffffffff81031e9c>] ? __do_page_fault+0x1cc/0x4c0
Nov 26 17:36:54 balto kernel: [ 839.587153] [<ffffffff813309bf>] kobj_attr_store+0xf/0x20
Nov 26 17:36:54 balto kernel: [ 839.587192] [<ffffffff811bb62d>] sysfs_write_file+0xcd/0x140
Nov 26 17:36:54 balto kernel: [ 839.587234] [<ffffffff8114c12c>] vfs_write+0xac/0x180
Nov 26 17:36:54 balto kernel: [ 839.587271] [<ffffffff8114c472>] sys_write+0x52/0xa0
Nov 26 17:36:54 balto kernel: [ 839.587306] [<ffffffff810321ce>] ? do_page_fault+0xe/0x10
Nov 26 17:36:54 balto kernel: [ 839.587345] [<ffffffff81751202>] system_call_fastpath+0x16/0x1b
Signed-off-by: Fabio Baltieri <fabio.baltieri@linaro.org>
---
Hi Rafael,
this is based on a clean linux-pm linux-next branch (i.e. not with my other
patch-set applied), so expect a context conflict if both are applied.
Thanks,
Fabio
drivers/cpufreq/cpufreq_ondemand.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/cpufreq/cpufreq_ondemand.c b/drivers/cpufreq/cpufreq_ondemand.c
index cca3e9f..7731f7c 100644
--- a/drivers/cpufreq/cpufreq_ondemand.c
+++ b/drivers/cpufreq/cpufreq_ondemand.c
@@ -40,6 +40,10 @@
static struct dbs_data od_dbs_data;
static DEFINE_PER_CPU(struct od_cpu_dbs_info_s, od_cpu_dbs_info);
+#ifndef CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND
+static struct cpufreq_governor cpufreq_gov_ondemand;
+#endif
+
static struct od_dbs_tuners od_tuners = {
.up_threshold = DEF_FREQUENCY_UP_THRESHOLD,
.sampling_down_factor = DEF_SAMPLING_DOWN_FACTOR,
@@ -279,6 +283,10 @@ static void update_sampling_rate(unsigned int new_rate)
policy = cpufreq_cpu_get(cpu);
if (!policy)
continue;
+ if (policy->governor != &cpufreq_gov_ondemand) {
+ cpufreq_cpu_put(policy);
+ continue;
+ }
dbs_info = &per_cpu(od_cpu_dbs_info, policy->cpu);
cpufreq_cpu_put(policy);
--
1.7.12.1
^ permalink raw reply related
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