Re: [PATCH/Resend 2/2] arm: mach-omap2: prevent UART console idle on suspend while using no_console_suspend
Hi Kevin,
On Wednesday 20 March 2013 05:36 PM, Sourav Poddar wrote:
Realised the list to whom the patch was send got dropped. Ccing them
all..
On Wednesday 20 March 2013 05:18 PM, Sourav Poddar wrote:
Hi Kevin,
On Tuesday 19 March 2013 12:24 AM, Kevin Hilman wrote:
Sourav Poddarsourav.pod...@ti.com writes:
With dt boot, uart wakeup after suspend is non functional on
omap4/5 while using
no_console_suspend in the bootargs. With no_console_suspend
used, od-flags
should be ORed with OMAP_DEVICE_NO_IDLE_ON_SUSPEND, thereby not
allowing the console
to idle in the suspend path. For non-dt case, this was taken care
by platform data.
Tested on omap5430evm, omap4430sdp.
Cc: Santosh Shilimkarsantosh.shilim...@ti.com
Cc: Felipe Balbiba...@ti.com
Cc: Rajendra nayakrna...@ti.com
Signed-off-by: Sourav Poddarsourav.pod...@ti.com
This patch creates a dependency between omap_device (generic,
device-independent code) and a specific driver (UART.)
If you need to do something like this that's DT boot specific, then
we probably need some late initcall in serial.c to handle this. It
does
not belong in omap_device.
The following function omap_device_disable_idle_on_suspend(pdev)
should only
be called once the omap device has been build, which in the case of
device tree is
done in omap_device.c file. Moreover, the above call should be
executed conditionally
and should depend on the following two parameter.
[1] a. Whether no_console_suspend is set and
b. the device build is a console uart.
When I look closely into the serial.c file, I realised that
core_initcall(omap_serial_early_init) gets called irrespective
of dt/non dt boot and will take care of most of the stuff(checking
whether
no_console_suspend is used and which uart is used as a console
uart) which the
$subject patch is proposing.
But the problem is that we need to exchange the parsed information
from serial.c to the omap_device file for the condtional execution of
omap_device_disable_idle_on_suspend
In this case,
from serial.c we need
1. no_console_suspend = true
2. strcpy(console_name, oh_name), where oh_name corresponds to
the console uart.
then in omap_device.c do
if (no_console_suspend !strcmp(oh-name, console_name))
omap_device_disable_idle_on_suspend(pdev);
Please correct if I am understanding it incorrectly.
If the above understanding looks good to you, is there a way we can
make this
exchange of information happen between serial.c and omap_device.c file?
Any Input on this?
Thanks,
Sourav
Kevin
---
arch/arm/mach-omap2/omap_device.c | 34
+-
1 files changed, 33 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_device.c
b/arch/arm/mach-omap2/omap_device.c
index 381be7a..71f5a73 100644
--- a/arch/arm/mach-omap2/omap_device.c
+++ b/arch/arm/mach-omap2/omap_device.c
@@ -35,11 +35,17 @@
#includelinux/pm_runtime.h
#includelinux/of.h
#includelinux/notifier.h
+#includelinux/platform_data/serial-omap.h
#include soc.h
#include omap_device.h
#include omap_hwmod.h
+#define MAX_UART_HWMOD_NAME_LEN 16
+
+static u8 no_console_suspend;
+static u8 console_uart_num;
+
/* Private functions */
static void _add_clkdev(struct omap_device *od, const char
*clk_alias,
@@ -108,6 +114,12 @@ static void _add_hwmod_clocks_clkdev(struct
omap_device *od,
_add_clkdev(od, oh-opt_clks[i].role, oh-opt_clks[i].clk);
}
+static char *cmdline_find_option(char *str)
+{
+extern char *saved_command_line;
+
+return strstr(saved_command_line, str);
+}
/**
* omap_device_build_from_dt - build an omap_device with multiple
hwmods
@@ -129,6 +141,7 @@ static int omap_device_build_from_dt(struct
platform_device *pdev)
struct device_node *node = pdev-dev.of_node;
const char *oh_name;
int oh_cnt, i, ret = 0;
+static u8 console_uart_id;
oh_cnt = of_property_count_strings(node, ti,hwmods);
if (!oh_cnt || IS_ERR_VALUE(oh_cnt)) {
@@ -170,7 +183,12 @@ static int omap_device_build_from_dt(struct
platform_device *pdev)
r-name = dev_name(pdev-dev);
}
-if (of_get_property(node, ti,no_idle_on_suspend, NULL))
+if (no_console_suspend !strncmp(oh-name, uart, 4)) {
+if (console_uart_num == console_uart_id)
+omap_device_disable_idle_on_suspend(pdev);
+else
+console_uart_id++;
+} else if (of_get_property(node, ti,no_idle_on_suspend, NULL))
omap_device_disable_idle_on_suspend(pdev);
pdev-dev.pm_domain =omap_device_pm_domain;
@@ -838,7 +856,21 @@ static struct notifier_block platform_nb = {
static int __init omap_device_init(void)
{
+int i;
+char uart_name[MAX_UART_HWMOD_NAME_LEN];
+
bus_register_notifier(platform_bus_type,platform_nb);
+
+if (cmdline_find_option(no_console_suspend)) {
+no_console_suspend = true;
+for (i = 0; i OMAP_MAX_HSUART_PORTS; i++) {
+
[PATCH 1/3] ARM: dts: AM33XX: Add pinmux configuration for CPSW to beaglebone
Add pinmux configurations for MII based CPSW ethernet to am335x-bone.
In this patch, only single named mode/state is added and these pins
are configured during pinctrl driver initialization.
Default mode is nothing but the values required for the module during
active state. With this configurations module is functional as
expected.
Signed-off-by: Mugunthan V N mugunthan...@ti.com
---
arch/arm/boot/dts/am335x-bone.dts | 25 -
1 file changed, 24 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/am335x-bone.dts
b/arch/arm/boot/dts/am335x-bone.dts
index 11b240c..f90e665 100644
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone.dts
@@ -26,7 +26,7 @@
am33xx_pinmux: pinmux@44e10800 {
pinctrl-names = default;
- pinctrl-0 = user_leds_s0;
+ pinctrl-0 = user_leds_s0 cpsw_s0;
user_leds_s0: user_leds_s0 {
pinctrl-single,pins =
@@ -36,6 +36,29 @@
0x60 0x17 /* gpmc_a8.gpio1_24,
OUTPUT_PULLUP | MODE7 */
;
};
+
+ cpsw_s0: cpsw_s0 {
+ pinctrl-single,pins =
+ /* Slave 1 */
+ 0x110 0x20 /* mii1_rxerr.mii1_rxerr, MODE0
| INPUT */
+ 0x114 0x0 /* mii1_txen.mii1_txen, MODE0 |
OUTPUT */
+ 0x118 0x20 /* mii1_rxdv.mii1_rxdv, MODE0 |
INPUT_PULLDOWN */
+ 0x11c 0x0 /* mii1_txd3.mii1_txd3, MODE0 |
OUTPUT */
+ 0x120 0x0 /* mii1_txd2.mii1_txd2, MODE0 |
OUTPUT */
+ 0x124 0x0 /* mii1_txd1.mii1_txd1, MODE0 |
OUTPUT */
+ 0x128 0x0 /* mii1_txd0.mii1_txd0, MODE0 |
OUTPUT */
+ 0x12c 0x20 /* mii1_txclk.mii1_txclk, MODE0
| INPUT_PULLDOWN */
+ 0x130 0x20 /* mii1_rxclk.mii1_rxclk, MODE0
| INPUT_PULLDOWN */
+ 0x134 0x20 /* mii1_rxd3.mii1_rxd3, MODE0 |
INPUT_PULLDOWN */
+ 0x138 0x20 /* mii1_rxd2.mii1_rxd2, MODE0 |
INPUT_PULLDOWN */
+ 0x13c 0x20 /* mii1_rxd1.mii1_rxd1, MODE0 |
INPUT_PULLDOWN */
+ 0x140 0x20 /* mii1_rxd0.mii1_rxd0, MODE0 |
INPUT_PULLDOWN */
+
+ /* MDIO */
+ 0x148 0x30 /* mdio_data.mdio_data, MODE0 |
INPUT_PULLUP */
+ 0x14c 0x10 /* mdio_clk.mdio_clk, MODE0 |
OUTPUT_PULLUP */
+ ;
+ };
};
ocp {
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] ARM: dts: AM33XX: Add pinmux configuration for CPSW to EVMsk
Add pinmux configurations for RGMII based CPSW ethernet to am335x-evmsk.
In this patch, only single named mode/state is added and these pins
are configured during pinctrl driver initialization.
Default mode is nothing but the values required for the module during
active state. With this configurations module is functional as
expected.
Signed-off-by: Mugunthan V N mugunthan...@ti.com
---
arch/arm/boot/dts/am335x-evmsk.dts | 38 +++-
1 file changed, 37 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/am335x-evmsk.dts
b/arch/arm/boot/dts/am335x-evmsk.dts
index f297b85..9b29ad4 100644
--- a/arch/arm/boot/dts/am335x-evmsk.dts
+++ b/arch/arm/boot/dts/am335x-evmsk.dts
@@ -32,7 +32,7 @@
am33xx_pinmux: pinmux@44e10800 {
pinctrl-names = default;
- pinctrl-0 = user_leds_s0 gpio_keys_s0;
+ pinctrl-0 = user_leds_s0 gpio_keys_s0 cpsw_s0;
user_leds_s0: user_leds_s0 {
pinctrl-single,pins =
@@ -51,6 +51,42 @@
0x9c 0x27 /* gpmc_ben0_cle.gpio2_5, INPUT
| MODE7 */
;
};
+
+ cpsw_s0: cpsw_s0 {
+ pinctrl-single,pins =
+ /* Slave 1 */
+ 0x114 0x2 /* mii1_txen.rgmii1_tctl, MODE2
| OUTPUT */
+ 0x118 0x22 /* mii1_rxdv.rgmii1_rctl, MODE2
| INPUT_PULLDOWN */
+ 0x11c 0x2 /* mii1_txd3.rgmii1_td3, MODE2
| OUTPUT */
+ 0x120 0x2 /* mii1_txd2.rgmii1_td2, MODE2
| OUTPUT */
+ 0x124 0x2 /* mii1_txd1.rgmii1_td1, MODE2
| OUTPUT */
+ 0x128 0x2 /* mii1_txd0.rgmii1_td0, MODE2
| OUTPUT */
+ 0x12c 0x2 /* mii1_txclk.rgmii1_tclk,
MODE2 | OUTPUT */
+ 0x130 0x22 /* mii1_rxclk.rgmii1_rclk,
MODE2 | INPUT_PULLDOWN */
+ 0x134 0x22 /* mii1_rxd3.rgmii1_rd3, MODE2
| INPUT_PULLDOWN */
+ 0x138 0x22 /* mii1_rxd2.rgmii1_rd2, MODE2
| INPUT_PULLDOWN */
+ 0x13c 0x22 /* mii1_rxd1.rgmii1_rd1, MODE2
| INPUT_PULLDOWN */
+ 0x140 0x22 /* mii1_rxd0.rgmii1_rd0, MODE2
| INPUT_PULLDOWN */
+
+ /* Slave 2 */
+ 0x40 0x2/* gpmc_a0.rgmii2_tctl, MODE2
| OUTPUT */
+ 0x44 0x22 /* gpmc_a1.rgmii2_rctl, MODE2
| INPUT_PULLDOWN */
+ 0x48 0x2/* gpmc_a2.rgmii2_td3, MODE2 |
OUTPUT */
+ 0x4c 0x2/* gpmc_a3.rgmii2_td2, MODE2 |
OUTPUT */
+ 0x50 0x2/* gpmc_a4.rgmii2_td1, MODE2 |
OUTPUT */
+ 0x54 0x2/* gpmc_a5.rgmii2_td0, MODE2 |
OUTPUT */
+ 0x58 0x2/* gpmc_a6.rgmii2_tclk, MODE2
| OUTPUT */
+ 0x5c 0x22 /* gpmc_a7.rgmii2_rclk, MODE2
| INPUT_PULLDOWN */
+ 0x60 0x22 /* gpmc_a8.rgmii2_rd3, MODE2 |
INPUT_PULLDOWN */
+ 0x64 0x22 /* gpmc_a9.rgmii2_rd2, MODE2 |
INPUT_PULLDOWN */
+ 0x68 0x22 /* gpmc_a10.rgmii2_rd1, MODE2
| INPUT_PULLDOWN */
+ 0x6c 0x22 /* gpmc_a11.rgmii2_rd0, MODE2
| INPUT_PULLDOWN */
+
+ /* MDIO */
+ 0x148 0x30 /* mdio_data.mdio_data, MODE0 |
INPUT_PULLUP */
+ 0x14c 0x10 /* mdio_clk.mdio_clk, MODE0 |
OUTPUT_PULLUP */
+ ;
+ };
};
ocp {
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/3] add pin-mux configuration for AM33xx CPSW
Adding pinmux configuration to AM33xx board dts file. Mugunthan V N (3): ARM: dts: AM33XX: Add pinmux configuration for CPSW to beaglebone ARM: dts: AM33XX: Add pinmux configuration for CPSW to EVMsk ARM: dts: AM33XX: Add pinmux configuration for CPSW to am335x EVM arch/arm/boot/dts/am335x-bone.dts | 25 +++- arch/arm/boot/dts/am335x-evm.dts | 24 ++- arch/arm/boot/dts/am335x-evmsk.dts | 38 +++- 3 files changed, 84 insertions(+), 3 deletions(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] ARM: dts: AM33XX: Add pinmux configuration for CPSW to am335x EVM
Add pinmux configurations for RGMII based CPSW ethernet to am335x-evm.
In this patch, only single named mode/state is added and these pins
are configured during pinctrl driver initialization.
Default mode is nothing but the values required for the module during
active state. With this configurations module is functional as
expected.
Signed-off-by: Mugunthan V N mugunthan...@ti.com
---
arch/arm/boot/dts/am335x-evm.dts | 24 +++-
1 file changed, 23 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts
index d649644..9327d7d 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -26,7 +26,7 @@
am33xx_pinmux: pinmux@44e10800 {
pinctrl-names = default;
- pinctrl-0 = matrix_keypad_s0 volume_keys_s0;
+ pinctrl-0 = matrix_keypad_s0 volume_keys_s0 cpsw_s0;
matrix_keypad_s0: matrix_keypad_s0 {
pinctrl-single,pins =
@@ -44,6 +44,28 @@
0x154 0x27 /* spi0_d0.gpio0_3, INPUT |
MODE7 */
;
};
+
+ cpsw_s0: cpsw_s0 {
+ pinctrl-single,pins =
+ /* Slave 1 */
+ 0x114 0x2 /* mii1_txen.rgmii1_tctl, MODE2
| OUTPUT */
+ 0x118 0x22 /* mii1_rxdv.rgmii1_rctl, MODE2
| INPUT_PULLDOWN */
+ 0x11c 0x2 /* mii1_txd3.rgmii1_td3, MODE2
| OUTPUT */
+ 0x120 0x2 /* mii1_txd2.rgmii1_td2, MODE2
| OUTPUT */
+ 0x124 0x2 /* mii1_txd1.rgmii1_td1, MODE2
| OUTPUT */
+ 0x128 0x2 /* mii1_txd0.rgmii1_td0, MODE2
| OUTPUT */
+ 0x12c 0x2 /* mii1_txclk.rgmii1_tclk,
MODE2 | OUTPUT */
+ 0x130 0x22 /* mii1_rxclk.rgmii1_rclk,
MODE2 | INPUT_PULLDOWN */
+ 0x134 0x22 /* mii1_rxd3.rgmii1_rd3, MODE2
| INPUT_PULLDOWN */
+ 0x138 0x22 /* mii1_rxd2.rgmii1_rd2, MODE2
| INPUT_PULLDOWN */
+ 0x13c 0x22 /* mii1_rxd1.rgmii1_rd1, MODE2
| INPUT_PULLDOWN */
+ 0x140 0x22 /* mii1_rxd0.rgmii1_rd0, MODE2
| INPUT_PULLDOWN */
+
+ /* MDIO */
+ 0x148 0x30 /* mdio_data.mdio_data, MODE0 |
INPUT_PULLUP */
+ 0x14c 0x10 /* mdio_clk.mdio_clk, MODE0 |
OUTPUT_PULLUP */
+ ;
+ };
};
ocp {
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] cpufreq: drivers: Remove unnecessary assignments of policy- members
On 3/24/2013 8:59 PM, Viresh Kumar wrote:
Some assignments of policy- min/max/cur/cpuinfo.min_freq/cpuinfo.max_freq
aren't required as part of it is done by cpufreq driver or cpufreq core.
Remove them.
At some places we merge multiple lines together too.
Cc: Sekhar Nori nsek...@ti.com
Cc: Sascha Hauer ker...@pengutronix.de
Cc: Paul Mundt let...@linux-sh.org
Cc: linux...@vger.kernel.org
Cc: linux-omap@vger.kernel.org
Signed-off-by: Viresh Kumar viresh.ku...@linaro.org
---
Documentation/cpu-freq/cpu-drivers.txt | 5 +++--
arch/arm/mach-davinci/cpufreq.c| 4
arch/arm/mach-imx/cpufreq.c| 3 ---
arch/sh/kernel/cpufreq.c | 9 +++--
drivers/cpufreq/cpufreq-nforce2.c | 6 ++
drivers/cpufreq/omap-cpufreq.c | 4 +---
6 files changed, 9 insertions(+), 22 deletions(-)
diff --git a/Documentation/cpu-freq/cpu-drivers.txt
b/Documentation/cpu-freq/cpu-drivers.txt
index 72f70b1..c94383f 100644
--- a/Documentation/cpu-freq/cpu-drivers.txt
+++ b/Documentation/cpu-freq/cpu-drivers.txt
@@ -108,8 +108,9 @@ policy-governor must contain the default
policy for
cpufreq_driver.target is called with
these values.
-For setting some of these values, the frequency table helpers might be
-helpful. See the section 2 for more information on them.
+For setting some of these values (cpuinfo.min[max]_freq, policy-min[max]),
the
+frequency table helpers might be helpful. See the section 2 for more
information
+on them.
SMP systems normally have same clock source for a group of cpus. For these
the
.init() would be called only once for the first online cpu. Here the .init()
diff --git a/arch/arm/mach-davinci/cpufreq.c b/arch/arm/mach-davinci/cpufreq.c
index 8fb0c2a..ff46862 100644
--- a/arch/arm/mach-davinci/cpufreq.c
+++ b/arch/arm/mach-davinci/cpufreq.c
@@ -149,10 +149,6 @@ static int davinci_cpu_init(struct cpufreq_policy
*policy)
policy-cpuinfo.max_freq = policy-max;
}
- policy-min = policy-cpuinfo.min_freq;
- policy-max = policy-cpuinfo.max_freq;
- policy-cur = davinci_getspeed(0);
There is a line in the code a little above the ones you deleted that
also sets these same variables. I guess you were relying on that line to
set policy-cur, but that also sets policy-{min, max} which can be
cleaned up.
Thanks,
Sekhar
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] cpufreq: drivers: Remove unnecessary assignments of policy- members
On 25 March 2013 14:06, Sekhar Nori nsek...@ti.com wrote:
There is a line in the code a little above the ones you deleted that
also sets these same variables. I guess you were relying on that line to
set policy-cur, but that also sets policy-{min, max} which can be
cleaned up.
This code is rather confusing or wrong, this was the state of code before
this patch:
policy-cur = policy-min = policy-max = davinci_getspeed(0);
if (freq_table) {
result = cpufreq_frequency_table_cpuinfo(policy, freq_table);
if (!result)
cpufreq_frequency_table_get_attr(freq_table,
policy-cpu);
} else {
policy-cpuinfo.min_freq = policy-min;
policy-cpuinfo.max_freq = policy-max;
}
policy-min = policy-cpuinfo.min_freq;
policy-max = policy-cpuinfo.max_freq;
policy-cur = davinci_getspeed(0);
The tricky part is if/else, where if don't return error if
cpufreq_frequency_table_cpuinfo() fails. We want to set -min[max]
and cpuinfo.min[max] always. And i can see this code not doing that for some
case even with my patch.
Possible scenarios:
1. Valid freq_table: My patch + what you suggested is required.
2. Invalid freq_table: We never set cpuinfo.min[max] with or without my patch
3. No freq_table: Only my patch is required.
If i do what you suggested then 2 and 3 would fail... If you want to
return error
in case cpufreq_frequency_table_cpuinfo(), then i can fix it properly.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: hw_breakpoint: Enable debug powerdown only if system supports 'has_ossr'
Will, On Tuesday 19 March 2013 03:58 PM, Will Deacon wrote: On Tue, Mar 19, 2013 at 06:39:38AM +, Santosh Shilimkar wrote: On Monday 18 March 2013 10:36 PM, Will Deacon wrote: [..] Well, we could just add the warn_once prints but that doesn't stop debug from breaking after the first pm/suspend/hotplug operation. Probably we should drop the $subject patch approach and use warn_once at least for current rc. Ofcourse it doesn't help to get working hw_breakpoint support. Patch end of the email with warn_once. Yeah, I'll merge that, but it's a real shame that this breaks hardware debug on one of the few platforms where it was reported to work. Are you going to send the patch for 3.9-rcx ? As I said before without the patch OMAP4 CPUILDE is unusable because of that debug noise and hence it will be good to get that patch in Regards, Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] cpufreq: drivers: Remove unnecessary assignments of policy- members
On 3/25/2013 2:15 PM, Viresh Kumar wrote:
On 25 March 2013 14:06, Sekhar Nori nsek...@ti.com wrote:
There is a line in the code a little above the ones you deleted that
also sets these same variables. I guess you were relying on that line to
set policy-cur, but that also sets policy-{min, max} which can be
cleaned up.
This code is rather confusing or wrong, this was the state of code before
this patch:
policy-cur = policy-min = policy-max = davinci_getspeed(0);
if (freq_table) {
result = cpufreq_frequency_table_cpuinfo(policy, freq_table);
if (!result)
cpufreq_frequency_table_get_attr(freq_table,
policy-cpu);
} else {
policy-cpuinfo.min_freq = policy-min;
policy-cpuinfo.max_freq = policy-max;
}
policy-min = policy-cpuinfo.min_freq;
policy-max = policy-cpuinfo.max_freq;
policy-cur = davinci_getspeed(0);
The tricky part is if/else, where if don't return error if
cpufreq_frequency_table_cpuinfo() fails. We want to set -min[max]
and cpuinfo.min[max] always. And i can see this code not doing that for some
case even with my patch.
Possible scenarios:
1. Valid freq_table: My patch + what you suggested is required.
2. Invalid freq_table: We never set cpuinfo.min[max] with or without my patch
3. No freq_table: Only my patch is required.
If i do what you suggested then 2 and 3 would fail... If you want to
return error
in case cpufreq_frequency_table_cpuinfo(), then i can fix it properly.
So down in the cpufreq driver probe below, we bail out if freq_table is
not provided. So all this checking for freq_table in the code you pasted
above is superfluous. If you can clean that part up and add checking for
cpufreq_frequency_table_cpuinfo() as you proposed, I will be glad to
test it out ;)
Thanks,
Sekhar
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 00/18] ARM: OMAP5: PM: Add MPUSS suspend and CPUidle support
Kevin,
Here is the refreshed version(v2) of the OMAP5 PM suspport which was posted
earlier (March 1st 2013). Patch-set incorporates comments from Nishant
Menon (Thanks for review NM) and his acked-by tags. I would like to get this
queued for 3.10 merge window if you are ok with the series.
Series is built on top of my pull requests [1] [2] [3] sent to Tony and your
'for_3.10/pm/cleanup' branch. For testing, I have created a branch [4]
which put together all the needed dependencies, fixes which should make it
to 3.10 merge window.
Series adds OMAP5 MPUSS power management support for system wide suspend
and CPUidle. Its heavy re-use from OMAP4 and hence only ~400 odd lines are
needed to add OMAP5 PM support on top of existing OMAP4 PM support.
OMAP5 adds a mercury retention feature which is an enhancement of
existing retention feature to reduce the leakage. No change in
programming model except one time enabling of mercury retention
during init.
One more notable change in OMAP5 vs OMAP4 devices, CPUx power domains
support retention state which lets you hit MPUSS and Core retention with
very low latency C-states.
Tested on OMAP4430 SDP, OMAP4460 Panda, OMAP5430 SDP and OMAP5432 Panda
devices with suspend and CPUIdle. Rootfs is mounted over ramdisk since
the mmc and nfs based fs needs DMA engine patches. For suspend wakeup,
I used Sourav's couple of serial wakeup wip patches from the lists.
The following changes since commit 9981cde24de52e5bb9a7cd918d1e54de241f85c9:
Merge branch 'for_3.10/omap5_data_files' of
git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux into
for_3.10/omap5_pm (2013-03-25 12:29:34 +0530)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux.git
for_3.10/omap5_pm
for you to fetch changes up to 75bd846d3103da858a208fe07127151903d1f608:
ARM: OMAP5: PM: handle device instance for warm reset (2013-03-25 12:37:44
+0530)
Nishanth Menon (1):
ARM: OMAP5: PM: handle device instance for warm reset
Santosh Shilimkar (17):
ARM: OMAP4+: PM: Consolidate MPU subsystem PM code for re-use
ARM: OMAP5: PM: Update CPU context register offset
ARM: OMAP4+: PM: Consolidate and use OMAP4 PM code for OMAP5
ARM: OMAP5: PM: Set MPUSS-EMIF clock-domain static dependency
ARM: OMAP5: PM: Enables ES2 PM mode by default
ARM: OMAP5: PM: Enable Mercury retention mode on CPUx powerdomains
ARM: OMAP5: Add init_late() hook to enable pm initialization
ARM: OMAP5: PM: Add CPU power off in hotplug path
ARM: OMAP4+: PM: Restore CPU power state to ON with clockdomain force
wakeup method
ARM: OMAP5: PM: Add MPU Open Switch Retention support
ARM: OMAP5: PM: Add L2 memory power down support
ARM: OMAP4: CPUidle: Avoid double idle driver registration
ARM: OMAP: CPUidle: Unregister drivere on device registration failure
ARM: OMAP4: CPUidle: Make C-state description field more precise
ARM: OMAP4+: CPUidle: Consolidate idle driver for OMAP5 support
ARM: OMAP4+: CPUidle: Deprecate use of
omap4_mpuss_read_prev_context_state()
ARM: OMAP4+: CPUidle: Add OMAP5 idle driver support
arch/arm/mach-omap2/Kconfig|1 +
arch/arm/mach-omap2/Makefile | 12 +-
arch/arm/mach-omap2/board-generic.c|1 +
arch/arm/mach-omap2/common.h |8 +-
arch/arm/mach-omap2/cpuidle34xx.c |6 +-
.../{cpuidle44xx.c = cpuidle_omap4plus.c} | 151 ---
arch/arm/mach-omap2/io.c |8 +
arch/arm/mach-omap2/omap-mpuss-lowpower.c | 155 +++-
arch/arm/mach-omap2/omap-secure.h |9 ++
arch/arm/mach-omap2/omap-smp.c | 12 +-
arch/arm/mach-omap2/omap-wakeupgen.c | 30 +++-
arch/arm/mach-omap2/omap-wakeupgen.h |1 +
arch/arm/mach-omap2/omap4-sar-layout.h |2 +
arch/arm/mach-omap2/{pm44xx.c = pm_omap4plus.c} | 90 ++--
arch/arm/mach-omap2/prminst44xx.c | 10 +-
.../mach-omap2/{sleep44xx.S = sleep_omap4plus.S} | 106 +
16 files changed, 512 insertions(+), 90 deletions(-)
rename arch/arm/mach-omap2/{cpuidle44xx.c = cpuidle_omap4plus.c} (58%)
rename arch/arm/mach-omap2/{pm44xx.c = pm_omap4plus.c} (74%)
rename arch/arm/mach-omap2/{sleep44xx.S = sleep_omap4plus.S} (77%)
--
Regards,
Santosh
[1] http://www.spinics.net/lists/arm-kernel/msg231512.html
[2] http://www.spinics.net/lists/arm-kernel/msg231513.html
[3] http://www.spinics.net/lists/arm-kernel/msg231514.html
[4] git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux.git
testing/3.10/omap5_int
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 01/18] ARM: OMAP4+: PM: Consolidate MPU subsystem PM code for re-use
OMAP5 and future OMAP based SOCs has backward compatible MPUSS
IP block with OMAP4. It's programming model is mostly similar.
Hence consolidate the OMAP MPUSS code so that it can be re-used
on OMAP5 and future SOCs.
No functional change.
Acked-by: Nishanth Menon n...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/omap-mpuss-lowpower.c | 65 -
1 file changed, 54 insertions(+), 11 deletions(-)
diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
index d650f91..d9e4843 100644
--- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
+++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
@@ -71,10 +71,46 @@ struct omap4_cpu_pm_info {
void (*secondary_startup)(void);
};
+/**
+ * struct cpu_pm_ops - CPU pm operations
+ * @finish_suspend:CPU suspend finisher function pointer
+ * @resume:CPU resume function pointer
+ * @scu_prepare: CPU Snoop Control program function pointer
+ *
+ * Structure holds functions pointer for CPU low power operations like
+ * suspend, resume and scu programming.
+ */
+struct cpu_pm_ops {
+ int (*finish_suspend)(unsigned long cpu_state);
+ void (*resume)(void);
+ void (*scu_prepare)(unsigned int cpu_id, unsigned int cpu_state);
+};
+
+extern int omap4_finish_suspend(unsigned long cpu_state);
+extern void omap4_cpu_resume(void);
+
static DEFINE_PER_CPU(struct omap4_cpu_pm_info, omap4_pm_info);
static struct powerdomain *mpuss_pd;
static void __iomem *sar_base;
+static int default_finish_suspend(unsigned long cpu_state)
+{
+ omap_do_wfi();
+ return 0;
+}
+
+static void dummy_cpu_resume(void)
+{}
+
+static void dummy_scu_prepare(unsigned int cpu_id, unsigned int cpu_state)
+{}
+
+struct cpu_pm_ops omap_pm_ops = {
+ .finish_suspend = default_finish_suspend,
+ .resume = dummy_cpu_resume,
+ .scu_prepare= dummy_scu_prepare,
+};
+
/*
* Program the wakeup routine address for the CPU0 and CPU1
* used for OFF or DORMANT wakeup.
@@ -172,11 +208,12 @@ static void save_l2x0_context(void)
{
u32 val;
void __iomem *l2x0_base = omap4_get_l2cache_base();
-
- val = __raw_readl(l2x0_base + L2X0_AUX_CTRL);
- __raw_writel(val, sar_base + L2X0_AUXCTRL_OFFSET);
- val = __raw_readl(l2x0_base + L2X0_PREFETCH_CTRL);
- __raw_writel(val, sar_base + L2X0_PREFETCH_CTRL_OFFSET);
+ if (l2x0_base) {
+ val = __raw_readl(l2x0_base + L2X0_AUX_CTRL);
+ __raw_writel(val, sar_base + L2X0_AUXCTRL_OFFSET);
+ val = __raw_readl(l2x0_base + L2X0_PREFETCH_CTRL);
+ __raw_writel(val, sar_base + L2X0_PREFETCH_CTRL_OFFSET);
+ }
}
#else
static void save_l2x0_context(void)
@@ -239,17 +276,17 @@ int omap4_enter_lowpower(unsigned int cpu, unsigned int
power_state)
cpu_clear_prev_logic_pwrst(cpu);
pwrdm_set_next_pwrst(pm_info-pwrdm, power_state);
- set_cpu_wakeup_addr(cpu, virt_to_phys(omap4_cpu_resume));
- scu_pwrst_prepare(cpu, power_state);
+ set_cpu_wakeup_addr(cpu, virt_to_phys(omap_pm_ops.resume));
+ omap_pm_ops.scu_prepare(cpu, power_state);
l2x0_pwrst_prepare(cpu, save_state);
/*
* Call low level function with targeted low power state.
*/
if (save_state)
- cpu_suspend(save_state, omap4_finish_suspend);
+ cpu_suspend(save_state, omap_pm_ops.finish_suspend);
else
- omap4_finish_suspend(save_state);
+ omap_pm_ops.finish_suspend(save_state);
/*
* Restore the CPUx power state to ON otherwise CPUx
@@ -285,14 +322,14 @@ int __cpuinit omap4_hotplug_cpu(unsigned int cpu,
unsigned int power_state)
pwrdm_clear_all_prev_pwrst(pm_info-pwrdm);
pwrdm_set_next_pwrst(pm_info-pwrdm, power_state);
set_cpu_wakeup_addr(cpu, virt_to_phys(pm_info-secondary_startup));
- scu_pwrst_prepare(cpu, power_state);
+ omap_pm_ops.scu_prepare(cpu, power_state);
/*
* CPU never retuns back if targeted power state is OFF mode.
* CPU ONLINE follows normal CPU ONLINE ptah via
* omap_secondary_startup().
*/
- omap4_finish_suspend(cpu_state);
+ omap_pm_ops.finish_suspend(cpu_state);
pwrdm_set_next_pwrst(pm_info-pwrdm, PWRDM_POWER_ON);
return 0;
@@ -369,6 +406,12 @@ int __init omap4_mpuss_init(void)
save_l2x0_context();
+ if (cpu_is_omap44xx()) {
+ omap_pm_ops.finish_suspend = omap4_finish_suspend;
+ omap_pm_ops.resume = omap4_cpu_resume;
+ omap_pm_ops.scu_prepare = scu_pwrst_prepare;
+ }
+
return 0;
}
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at
[PATCH v2 02/18] ARM: OMAP5: PM: Update CPU context register offset
On OMAP5, RM_CPUi_CPUi_CONTEXT offset has changed. Update the code
so that same code works for OMAP4+ devices.
Acked-by: Nishanth Menon n...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/omap-mpuss-lowpower.c | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
index d9e4843..b1441b1 100644
--- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
+++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
@@ -56,6 +56,7 @@
#include omap4-sar-layout.h
#include pm.h
#include prcm_mpu44xx.h
+#include prcm_mpu54xx.h
#include prminst44xx.h
#include prcm44xx.h
#include prm44xx.h
@@ -92,6 +93,7 @@ extern void omap4_cpu_resume(void);
static DEFINE_PER_CPU(struct omap4_cpu_pm_info, omap4_pm_info);
static struct powerdomain *mpuss_pd;
static void __iomem *sar_base;
+static u32 cpu_context_offset;
static int default_finish_suspend(unsigned long cpu_state)
{
@@ -164,14 +166,14 @@ static inline void cpu_clear_prev_logic_pwrst(unsigned
int cpu_id)
if (cpu_id) {
reg = omap4_prcm_mpu_read_inst_reg(OMAP4430_PRCM_MPU_CPU1_INST,
- OMAP4_RM_CPU1_CPU1_CONTEXT_OFFSET);
+ cpu_context_offset);
omap4_prcm_mpu_write_inst_reg(reg, OMAP4430_PRCM_MPU_CPU1_INST,
- OMAP4_RM_CPU1_CPU1_CONTEXT_OFFSET);
+ cpu_context_offset);
} else {
reg = omap4_prcm_mpu_read_inst_reg(OMAP4430_PRCM_MPU_CPU0_INST,
- OMAP4_RM_CPU0_CPU0_CONTEXT_OFFSET);
+ cpu_context_offset);
omap4_prcm_mpu_write_inst_reg(reg, OMAP4430_PRCM_MPU_CPU0_INST,
- OMAP4_RM_CPU0_CPU0_CONTEXT_OFFSET);
+ cpu_context_offset);
}
}
@@ -410,6 +412,9 @@ int __init omap4_mpuss_init(void)
omap_pm_ops.finish_suspend = omap4_finish_suspend;
omap_pm_ops.resume = omap4_cpu_resume;
omap_pm_ops.scu_prepare = scu_pwrst_prepare;
+ cpu_context_offset = OMAP4_RM_CPU0_CPU0_CONTEXT_OFFSET;
+ } else if (soc_is_omap54xx()) {
+ cpu_context_offset = OMAP54XX_RM_CPU0_CPU0_CONTEXT_OFFSET;
}
return 0;
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 03/18] ARM: OMAP4+: PM: Consolidate and use OMAP4 PM code for OMAP5
OMAP5 has backward compatible PRCM block and it's programming
model is mostly similar to OMAP4. Same is going to be maintained
for future OMAP4 based SOCs. Hence consolidate the OMAP4 power
management code so that it can be re-used on OMAP5 and later devices.
With consolidated code, let basic power management code build
for OMAP5 devices. While at it, update the kernel-doc for omap4_pm_init().
Acked-by: Nishanth Menon n...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/Makefile |9 ++--
arch/arm/mach-omap2/{pm44xx.c = pm_omap4plus.c} | 54
.../mach-omap2/{sleep44xx.S = sleep_omap4plus.S} |0
3 files changed, 49 insertions(+), 14 deletions(-)
rename arch/arm/mach-omap2/{pm44xx.c = pm_omap4plus.c} (86%)
rename arch/arm/mach-omap2/{sleep44xx.S = sleep_omap4plus.S} (100%)
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 5d5ff91..d91ae0f 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -35,14 +35,14 @@ obj-$(CONFIG_SOC_HAS_OMAP2_SDRC)+= sdrc.o
obj-$(CONFIG_SMP) += omap-smp.o omap-headsmp.o
obj-$(CONFIG_HOTPLUG_CPU) += omap-hotplug.o
omap-4-5-common= omap4-common.o
omap-wakeupgen.o \
- sleep44xx.o
+ sleep_omap4plus.o
obj-$(CONFIG_ARCH_OMAP4) += $(omap-4-5-common)
obj-$(CONFIG_SOC_OMAP5)+= $(omap-4-5-common)
plus_sec := $(call as-instr,.arch_extension sec,+sec)
AFLAGS_omap-headsmp.o :=-Wa,-march=armv7-a$(plus_sec)
AFLAGS_omap-smc.o :=-Wa,-march=armv7-a$(plus_sec)
-AFLAGS_sleep44xx.o :=-Wa,-march=armv7-a$(plus_sec)
+AFLAGS_sleep_omap4plus.o :=-Wa,-march=armv7-a$(plus_sec)
# Functions loaded to SRAM
obj-$(CONFIG_SOC_OMAP2420) += sram242x.o
@@ -80,11 +80,12 @@ endif
obj-$(CONFIG_OMAP_PM_NOOP) += omap-pm-noop.o
ifeq ($(CONFIG_PM),y)
+omap4plus-common-pm= omap-mpuss-lowpower.o pm_omap4plus.o
obj-$(CONFIG_ARCH_OMAP2) += pm24xx.o
obj-$(CONFIG_ARCH_OMAP2) += sleep24xx.o
obj-$(CONFIG_ARCH_OMAP3) += pm34xx.o sleep34xx.o
-obj-$(CONFIG_ARCH_OMAP4) += pm44xx.o omap-mpuss-lowpower.o
-obj-$(CONFIG_SOC_OMAP5)+= omap-mpuss-lowpower.o
+obj-$(CONFIG_ARCH_OMAP4) += $(omap4plus-common-pm)
+obj-$(CONFIG_SOC_OMAP5)+= $(omap4plus-common-pm)
obj-$(CONFIG_PM_DEBUG) += pm-debug.o
obj-$(CONFIG_POWER_AVS_OMAP) += sr_device.o
diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm_omap4plus.c
similarity index 86%
rename from arch/arm/mach-omap2/pm44xx.c
rename to arch/arm/mach-omap2/pm_omap4plus.c
index 5ba6d88..e920c34 100644
--- a/arch/arm/mach-omap2/pm44xx.c
+++ b/arch/arm/mach-omap2/pm_omap4plus.c
@@ -1,7 +1,7 @@
/*
- * OMAP4 Power Management Routines
+ * OMAP4PLUS Power Management Routines
*
- * Copyright (C) 2010-2011 Texas Instruments, Inc.
+ * Copyright (C) 2010-2013 Texas Instruments, Inc.
* Rajendra Nayak rna...@ti.com
* Santosh Shilimkar santosh.shilim...@ti.com
*
@@ -135,16 +135,16 @@ static void omap_default_idle(void)
}
/**
- * omap4_pm_init - Init routine for OMAP4 PM
+ * omap4_init_static_deps - Add OMAP4 static dependencies
*
- * Initializes all powerdomain and clockdomain target states
- * and all PRCM settings.
+ * Add needed static clockdomain dependencies on OMAP4 devices.
+ * Return: 0 on success or 'err' on failures
*/
-int __init omap4_pm_init(void)
+static inline int omap4_init_static_deps(void)
{
- int ret;
struct clockdomain *emif_clkdm, *mpuss_clkdm, *l3_1_clkdm;
struct clockdomain *ducati_clkdm, *l3_2_clkdm;
+ int ret = 0;
if (omap_rev() == OMAP4430_REV_ES1_0) {
WARN(1, Power Management not supported on OMAP4430 ES1.0\n);
@@ -163,7 +163,7 @@ int __init omap4_pm_init(void)
ret = pwrdm_for_each(pwrdms_setup, NULL);
if (ret) {
pr_err(Failed to setup powerdomains\n);
- goto err2;
+ return ret;
}
/*
@@ -179,7 +179,7 @@ int __init omap4_pm_init(void)
ducati_clkdm = clkdm_lookup(ducati_clkdm);
if ((!mpuss_clkdm) || (!emif_clkdm) || (!l3_1_clkdm) ||
(!l3_2_clkdm) || (!ducati_clkdm))
- goto err2;
+ return -EINVAL;
ret = clkdm_add_wkdep(mpuss_clkdm, emif_clkdm);
ret |= clkdm_add_wkdep(mpuss_clkdm, l3_1_clkdm);
@@ -188,9 +188,42 @@ int __init omap4_pm_init(void)
ret |= clkdm_add_wkdep(ducati_clkdm, l3_2_clkdm);
if (ret) {
pr_err(Failed to add MPUSS - L3/EMIF/L4PER, DUCATI - L3
wakeup dependency\n);
+ return
[PATCH v2 04/18] ARM: OMAP5: PM: Set MPUSS-EMIF clock-domain static dependency
With EMIF clock-domain put under hardware supervised control, memory
corruption and untraceable crashes are observed on OMAP5. Further
investigation revealed that there is a weakness in the PRCM on this
specific dynamic dependency.
Async bridge issue which resulted in memory corruption and lock on
OMAP4 continue to exist on OMAP5 too unfortunately and hence the
MPU - EMIF static dependency continue to be there.
Acked-by: Nishanth Menon n...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/pm_omap4plus.c | 42 +---
1 file changed, 39 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/pm_omap4plus.c
b/arch/arm/mach-omap2/pm_omap4plus.c
index e920c34..2dadb4e 100644
--- a/arch/arm/mach-omap2/pm_omap4plus.c
+++ b/arch/arm/mach-omap2/pm_omap4plus.c
@@ -195,6 +195,37 @@ static inline int omap4_init_static_deps(void)
}
/**
+ * omap5_init_static_deps - Add OMAP5 static dependencies
+ *
+ * Add needed static clockdomain dependencies on OMAP5 devices.
+ * Return: 0 on success or 'err' on failures
+ */
+static inline int omap5_init_static_deps(void)
+{
+ struct clockdomain *mpuss_clkdm, *emif_clkdm;
+ int ret = 0;
+
+ /*
+* The dynamic dependency between MPUSS - EMIF is broken and has
+* not worked as expected on OMAP5 too. Async bridge issue which
+* resulted in memory corruption and lock on OMAP4 continue to
+* exist on OMAP5 too and hence the MPU - EMIF dependency to avoid
+* random crashes and lockups.
+*/
+ mpuss_clkdm = clkdm_lookup(mpu_clkdm);
+ emif_clkdm = clkdm_lookup(emif_clkdm);
+ if (!mpuss_clkdm || !emif_clkdm)
+ return -EINVAL;
+
+ ret = clkdm_add_wkdep(mpuss_clkdm, emif_clkdm);
+ if (ret)
+ pr_err(%s: Failed to add static dependency with %d\n,
+ __func__, ret);
+
+ return ret;
+}
+
+/**
* omap4_pm_init - Init routine for OMAP4+ devices
*
* Initializes all powerdomain and clockdomain target states
@@ -218,10 +249,15 @@ int __init omap4_pm_init(void)
goto err2;
}
- if (cpu_is_omap44xx()) {
+ if (cpu_is_omap44xx())
ret = omap4_init_static_deps();
- if (ret)
- goto err2;
+ else if (soc_is_omap54xx())
+ ret = omap5_init_static_deps();
+
+ if (ret) {
+ pr_err(%s: Failed to initialise static dependency with %d\n,
+ __func__, ret);
+ goto err2;
}
ret = omap4_mpuss_init();
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 06/18] ARM: OMAP5: PM: Enable Mercury retention mode on CPUx powerdomains
In addition to the standard power-management technique, the OMAP5
MPU subsystem also employs an SR3-APG (mercury) power management
technology to reduce leakage.
It allows for full logic and memories retention on MPU_C0 and MPU_C1 and
is controlled by the PRCM_MPU.
Acked-by: Nishanth Menon n...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/omap-mpuss-lowpower.c | 27 +++
1 file changed, 27 insertions(+)
diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
index b1441b1..d390d18 100644
--- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
+++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
@@ -62,6 +62,10 @@
#include prm44xx.h
#include prm-regbits-44xx.h
+/* Add defines needed for mercury mode. Refer MPU's PRM_PSCON_COUNT */
+#define PRM_PSCON_HG_EN(1 24)
+#define PRM_PSCON_HG_RAMPUP(1 25)
+
#ifdef CONFIG_SMP
struct omap4_cpu_pm_info {
@@ -337,6 +341,28 @@ int __cpuinit omap4_hotplug_cpu(unsigned int cpu, unsigned
int power_state)
return 0;
}
+/**
+ * enable_mercury_retention_mode: Enable OMAP5 mercury retention feature
+ *
+ * OMAP5 devices supports SR3-APG (mercury) power management technology to
+ * reduce leakage. It allows for full logic and memories retention on
+ * MPU_C0 and MPU_C1 and is controlled by the PRCM_MPU. The function enable
+ * the mercury retention feature.
+ */
+static void enable_mercury_retention_mode(void)
+{
+ u32 reg;
+
+ /*
+* To enable mercury mode, both HG_EN and HG_RAMPUP needs to be
+* enabled from PRM_PSCON_COUNT register.
+*/
+ reg = omap4_prcm_mpu_read_inst_reg(OMAP54XX_PRCM_MPU_DEVICE_INST,
+ OMAP54XX_PRCM_MPU_PRM_PSCON_COUNT_OFFSET);
+ reg |= PRM_PSCON_HG_EN | PRM_PSCON_HG_RAMPUP;
+ omap4_prcm_mpu_write_inst_reg(reg, OMAP54XX_PRCM_MPU_DEVICE_INST,
+ OMAP54XX_PRCM_MPU_PRM_PSCON_COUNT_OFFSET);
+}
/*
* Initialise OMAP4 MPUSS
@@ -415,6 +441,7 @@ int __init omap4_mpuss_init(void)
cpu_context_offset = OMAP4_RM_CPU0_CPU0_CONTEXT_OFFSET;
} else if (soc_is_omap54xx()) {
cpu_context_offset = OMAP54XX_RM_CPU0_CPU0_CONTEXT_OFFSET;
+ enable_mercury_retention_mode();
}
return 0;
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 05/18] ARM: OMAP5: PM: Enables ES2 PM mode by default
Enables MPUSS ES2 power management mode using ES2_PM_MODE in
AMBA_IF_MODE register.
0x0: ES1 behavior, CPU cores would enter and exit OFF mode together. Broken
0x1: ES2 behavior, CPU cores are allowed to enter/exit OFF mode independently.
The AMBA_IF_MODE register value is stored on SAR RAM and restored by
ROM code.
Acked-by: Nishanth Menon n...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/omap-secure.h|2 ++
arch/arm/mach-omap2/omap-wakeupgen.c | 19 +++
arch/arm/mach-omap2/omap-wakeupgen.h |1 +
3 files changed, 22 insertions(+)
diff --git a/arch/arm/mach-omap2/omap-secure.h
b/arch/arm/mach-omap2/omap-secure.h
index 0e72917..82b3c4c 100644
--- a/arch/arm/mach-omap2/omap-secure.h
+++ b/arch/arm/mach-omap2/omap-secure.h
@@ -42,6 +42,8 @@
#define OMAP4_MON_L2X0_AUXCTRL_INDEX 0x109
#define OMAP4_MON_L2X0_PREFETCH_INDEX 0x113
+#define OMAP5_MON_AMBA_IF_INDEX0x108
+
/* Secure PPA(Primary Protected Application) APIs */
#define OMAP4_PPA_L2_POR_INDEX 0x23
#define OMAP4_PPA_CPU_ACTRL_SMP_INDEX 0x25
diff --git a/arch/arm/mach-omap2/omap-wakeupgen.c
b/arch/arm/mach-omap2/omap-wakeupgen.c
index f8bb3b9..8bcaa8c 100644
--- a/arch/arm/mach-omap2/omap-wakeupgen.c
+++ b/arch/arm/mach-omap2/omap-wakeupgen.c
@@ -42,6 +42,7 @@
#define CPU1_ID0x1
#define OMAP4_NR_BANKS 4
#define OMAP4_NR_IRQS 128
+#define OMAP5_AMBA_IF_PM_MODE (1 5)
static void __iomem *wakeupgen_base;
static void __iomem *sar_base;
@@ -265,6 +266,11 @@ static inline void omap5_irq_save_context(void)
val = __raw_readl(wakeupgen_base + OMAP_AUX_CORE_BOOT_0);
__raw_writel(val, sar_base + OMAP5_AUXCOREBOOT1_OFFSET);
+ /* Save AMBA_IF_PM_MODE regsiter */
+ val = __raw_readl(wakeupgen_base + OMAP_AMBA_IF_MODE);
+ val |= OMAP5_AMBA_IF_PM_MODE;
+ __raw_writel(val, sar_base + OMAP5_AMBA_IF_MODE_OFFSET);
+
/* Set the Backup Bit Mask status */
val = __raw_readl(sar_base + OMAP5_SAR_BACKUP_STATUS_OFFSET);
val |= SAR_BACKUP_STATUS_WAKEUPGEN;
@@ -402,6 +408,7 @@ int __init omap_wakeupgen_init(void)
{
int i;
unsigned int boot_cpu = smp_processor_id();
+ u32 val;
/* Not supported on OMAP4 ES1.0 silicon */
if (omap_rev() == OMAP4430_REV_ES1_0) {
@@ -443,6 +450,18 @@ int __init omap_wakeupgen_init(void)
for (i = 0; i max_irqs; i++)
irq_target_cpu[i] = boot_cpu;
+ /*
+* Enables OMAP5 ES2 PM Mode using ES2_PM_MODE in AMBA_IF_MODE
+* 0x0: ES1 behavior, CPU cores would enter and exit OFF mode together.
+* 0x1: ES2 behavior, CPU cores are allowed to enter/exit OFF mode
+* independently.
+*/
+ if (soc_is_omap54xx()) {
+ val = __raw_readl(wakeupgen_base + OMAP_AMBA_IF_MODE);
+ val |= OMAP5_AMBA_IF_PM_MODE;
+ omap_smc1(OMAP5_MON_AMBA_IF_INDEX, val);
+ }
+
irq_hotplug_init();
irq_pm_init();
diff --git a/arch/arm/mach-omap2/omap-wakeupgen.h
b/arch/arm/mach-omap2/omap-wakeupgen.h
index b0fd16f..b3c8ecc 100644
--- a/arch/arm/mach-omap2/omap-wakeupgen.h
+++ b/arch/arm/mach-omap2/omap-wakeupgen.h
@@ -27,6 +27,7 @@
#define OMAP_WKG_ENB_E_1 0x420
#define OMAP_AUX_CORE_BOOT_0 0x800
#define OMAP_AUX_CORE_BOOT_1 0x804
+#define OMAP_AMBA_IF_MODE 0x80c
#define OMAP_PTMSYNCREQ_MASK 0xc00
#define OMAP_PTMSYNCREQ_EN 0xc04
#define OMAP_TIMESTAMPCYCLELO 0xc08
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 07/18] ARM: OMAP5: Add init_late() hook to enable pm initialization
With consolidated code, now we can add the .init_late hook for
OMAP5 to enable power management and mux initialization.
Acked-by: Nishanth Menon n...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/board-generic.c |1 +
arch/arm/mach-omap2/common.h|3 ++-
arch/arm/mach-omap2/io.c|8
3 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/board-generic.c
b/arch/arm/mach-omap2/board-generic.c
index e54a480..8e261a6 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -180,6 +180,7 @@ DT_MACHINE_START(OMAP5_DT, Generic OMAP5 (Flattened Device
Tree))
.init_irq = omap_gic_of_init,
.init_machine = omap_generic_init,
.init_time = omap5_realtime_timer_init,
+ .init_late = omap5_init_late,
.dt_compat = omap5_boards_compat,
.restart= omap44xx_restart,
MACHINE_END
diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index 40f4a03..f75d972 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -59,7 +59,7 @@ static inline int omap3_pm_init(void)
}
#endif
-#if defined(CONFIG_PM) defined(CONFIG_ARCH_OMAP4)
+#if defined(CONFIG_PM) (defined(CONFIG_ARCH_OMAP4) ||
defined(CONFIG_SOC_OMAP5))
int omap4_pm_init(void);
#else
static inline int omap4_pm_init(void)
@@ -108,6 +108,7 @@ void omap35xx_init_late(void);
void omap3630_init_late(void);
void am35xx_init_late(void);
void ti81xx_init_late(void);
+void omap5_init_late(void);
int omap2_common_pm_late_init(void);
#if defined(CONFIG_SOC_OMAP2420) || defined(CONFIG_SOC_OMAP2430)
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index e948a39..cdd1264 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -636,6 +636,14 @@ void __init omap5_init_early(void)
omap_hwmod_init_postsetup();
}
+
+void __init omap5_init_late(void)
+{
+ omap_mux_late_init();
+ omap2_common_pm_late_init();
+ omap4_pm_init();
+ omap2_clk_enable_autoidle_all();
+}
#endif
void __init omap_sdrc_init(struct omap_sdrc_params *sdrc_cs0,
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 09/18] ARM: OMAP4+: PM: Restore CPU power state to ON with clockdomain force wakeup method
While waking up CPU from off state using clock domain force wakeup, restore
the CPU power state to ON state before putting CPU clock domain under
hardware control. Otherwise CPU wakeup might fail. The change is recommended
for all OMAP4+ devices though the PRCM weakness was observed on OMAP5
devices first.
So update the code accordingly.
Acked-by: Nishanth Menon n...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/cpuidle44xx.c |1 +
arch/arm/mach-omap2/omap-smp.c| 12 ++--
2 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle44xx.c
b/arch/arm/mach-omap2/cpuidle44xx.c
index 944e64a..9de47a7 100644
--- a/arch/arm/mach-omap2/cpuidle44xx.c
+++ b/arch/arm/mach-omap2/cpuidle44xx.c
@@ -131,6 +131,7 @@ static int omap4_enter_idle_coupled(struct cpuidle_device
*dev,
/* Wakeup CPU1 only if it is not offlined */
if (dev-cpu == 0 cpumask_test_cpu(1, cpu_online_mask)) {
clkdm_wakeup(cpu_clkdm[1]);
+ omap_set_pwrdm_state(cpu_pd[1], PWRDM_POWER_ON);
clkdm_allow_idle(cpu_clkdm[1]);
}
diff --git a/arch/arm/mach-omap2/omap-smp.c b/arch/arm/mach-omap2/omap-smp.c
index 0cbb677..e4441cc 100644
--- a/arch/arm/mach-omap2/omap-smp.c
+++ b/arch/arm/mach-omap2/omap-smp.c
@@ -83,6 +83,7 @@ static int __cpuinit omap4_boot_secondary(unsigned int cpu,
struct task_struct *
{
static struct clockdomain *cpu1_clkdm;
static bool booted;
+ static struct powerdomain *cpu1_pwrdm;
void __iomem *base = omap_get_wakeupgen_base();
/*
@@ -102,8 +103,10 @@ static int __cpuinit omap4_boot_secondary(unsigned int
cpu, struct task_struct *
else
__raw_writel(0x20, base + OMAP_AUX_CORE_BOOT_0);
- if (!cpu1_clkdm)
+ if (!cpu1_clkdm !cpu1_pwrdm) {
cpu1_clkdm = clkdm_lookup(mpu1_clkdm);
+ cpu1_pwrdm = pwrdm_lookup(cpu1_pwrdm);
+ }
/*
* The SGI(Software Generated Interrupts) are not wakeup capable
@@ -116,7 +119,7 @@ static int __cpuinit omap4_boot_secondary(unsigned int cpu,
struct task_struct *
* Section :
* 4.3.4.2 Power States of CPU0 and CPU1
*/
- if (booted) {
+ if (booted cpu1_pwrdm cpu1_clkdm) {
/*
* GIC distributor control register has changed between
* CortexA9 r1pX and r2pX. The Control Register secure
@@ -137,7 +140,12 @@ static int __cpuinit omap4_boot_secondary(unsigned int
cpu, struct task_struct *
gic_dist_disable();
}
+ /*
+* Ensure that CPU power state is set to ON to avoid CPU
+* powerdomain transition on wfi
+*/
clkdm_wakeup(cpu1_clkdm);
+ omap_set_pwrdm_state(cpu1_pwrdm, PWRDM_POWER_ON);
clkdm_allow_idle(cpu1_clkdm);
if (IS_PM44XX_ERRATUM(PM_OMAP4_ROM_SMP_BOOT_ERRATUM_GICD)) {
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 11/18] ARM: OMAP5: PM: Add L2 memory power down support
When the entire MPUSS cluster is powered down in device off state, L2 cache
memory looses it's content and hence while targetting such a state,
l2 cache needs to be flushed to main memory.
Add the necessary low power code support for the same.
Acked-by: Nishanth Menon n...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/omap-secure.h |1 +
arch/arm/mach-omap2/sleep_omap4plus.S | 21 +
2 files changed, 22 insertions(+)
diff --git a/arch/arm/mach-omap2/omap-secure.h
b/arch/arm/mach-omap2/omap-secure.h
index 1739468..a171a5a 100644
--- a/arch/arm/mach-omap2/omap-secure.h
+++ b/arch/arm/mach-omap2/omap-secure.h
@@ -47,6 +47,7 @@
#define OMAP4_MON_L2X0_PREFETCH_INDEX 0x113
#define OMAP5_MON_CACHES_CLEAN_INDEX 0x103
#define OMAP5_MON_AUX_CTRL_INDEX 0x107
+#define OMAP5_MON_L2AUX_CTRL_INDEX 0x104
#define OMAP5_MON_AMBA_IF_INDEX0x108
diff --git a/arch/arm/mach-omap2/sleep_omap4plus.S
b/arch/arm/mach-omap2/sleep_omap4plus.S
index 4a5e2e4..288f62f 100644
--- a/arch/arm/mach-omap2/sleep_omap4plus.S
+++ b/arch/arm/mach-omap2/sleep_omap4plus.S
@@ -337,6 +337,7 @@ ENDPROC(omap4_cpu_resume)
* 0 - Nothing lost and no need to save: MPUSS INA/CSWR
* 1 - CPUx L1 and logic lost: CPU OFF, MPUSS INA/CSWR
* 2 - CPUx L1 and logic lost + GIC lost: MPUSS OSWR
+ * 3 - CPUx L1 and logic lost + GIC,L2 lost: MPU OSWR L2 lost(debug only)
*/
ENTRY(omap5_finish_suspend)
stmfd sp!, {r4-r12, lr}
@@ -391,6 +392,26 @@ skip_secure_l1_clean_op:
isb
dsb
+ bl omap4_get_sar_ram_base
+ mov r8, r0
+ mrc p15, 0, r5, c0, c0, 5 @ Read MPIDR
+ andsr5, r5, #0x0f
+ ldreq r0, [r8, #L2X0_SAVE_OFFSET0]@ Retrieve L2 state
+ ldrne r0, [r8, #L2X0_SAVE_OFFSET1]
+ cmp r0, #3
+ bne do_wfi
+ bl omap4_get_sar_ram_base
+ ldr r9, [r0, #OMAP_TYPE_OFFSET]
+ cmp r9, #0x1@ Check for HS device
+ bne skip_secure_l2_clean_op
+ mov r0, #1 @ Clean secure L2
+ stmfd r13!, {r4-r12, r14}
+ ldr r12, =OMAP5_MON_CACHES_CLEAN_INDEX
+ DO_SMC
+ ldmfd r13!, {r4-r12, r14}
+skip_secure_l2_clean_op:
+ bl v7_flush_dcache_all
+
do_wfi:
bl omap_do_wfi
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 08/18] ARM: OMAP5: PM: Add CPU power off in hotplug path
Add power management code to handle the CPU off mode to enable CPUP hotplug
mode for OMAP5 devices. Separate suspend finisher is used for OMAP5(Cortex-A15)
because it doesn't use SCU power status register and external PL310 L2 cache
which makes code flow bit different.
Acked-by: Nishanth Menon n...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/omap-mpuss-lowpower.c | 30 ---
arch/arm/mach-omap2/omap-secure.h |1 +
arch/arm/mach-omap2/omap4-sar-layout.h|2 +
arch/arm/mach-omap2/sleep_omap4plus.S | 84 +
4 files changed, 110 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
index d390d18..096f489 100644
--- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
+++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
@@ -81,6 +81,7 @@ struct omap4_cpu_pm_info {
* @finish_suspend:CPU suspend finisher function pointer
* @resume:CPU resume function pointer
* @scu_prepare: CPU Snoop Control program function pointer
+ * @hotplug_restart: CPU hotplug restart kernel hook pointer
*
* Structure holds functions pointer for CPU low power operations like
* suspend, resume and scu programming.
@@ -89,10 +90,12 @@ struct cpu_pm_ops {
int (*finish_suspend)(unsigned long cpu_state);
void (*resume)(void);
void (*scu_prepare)(unsigned int cpu_id, unsigned int cpu_state);
+ void (*hotplug_restart)(void);
};
extern int omap4_finish_suspend(unsigned long cpu_state);
extern void omap4_cpu_resume(void);
+extern int omap5_finish_suspend(unsigned long cpu_state);
static DEFINE_PER_CPU(struct omap4_cpu_pm_info, omap4_pm_info);
static struct powerdomain *mpuss_pd;
@@ -115,6 +118,7 @@ struct cpu_pm_ops omap_pm_ops = {
.finish_suspend = default_finish_suspend,
.resume = dummy_cpu_resume,
.scu_prepare= dummy_scu_prepare,
+ .hotplug_restart= dummy_cpu_resume,
};
/*
@@ -327,7 +331,7 @@ int __cpuinit omap4_hotplug_cpu(unsigned int cpu, unsigned
int power_state)
pwrdm_clear_all_prev_pwrst(pm_info-pwrdm);
pwrdm_set_next_pwrst(pm_info-pwrdm, power_state);
- set_cpu_wakeup_addr(cpu, virt_to_phys(pm_info-secondary_startup));
+ set_cpu_wakeup_addr(cpu, virt_to_phys(omap_pm_ops.hotplug_restart));
omap_pm_ops.scu_prepare(cpu, power_state);
/*
@@ -370,6 +374,7 @@ static void enable_mercury_retention_mode(void)
int __init omap4_mpuss_init(void)
{
struct omap4_cpu_pm_info *pm_info;
+ u32 cpu_wakeup_addr = 0;
if (omap_rev() == OMAP4430_REV_ES1_0) {
WARN(1, Power Management not supported on OMAP4430 ES1.0\n);
@@ -379,9 +384,13 @@ int __init omap4_mpuss_init(void)
sar_base = omap4_get_sar_ram_base();
/* Initilaise per CPU PM information */
+ if (cpu_is_omap44xx())
+ cpu_wakeup_addr = CPU0_WAKEUP_NS_PA_ADDR_OFFSET;
+ else if (soc_is_omap54xx())
+ cpu_wakeup_addr = OMAP5_CPU0_WAKEUP_NS_PA_ADDR_OFFSET;
pm_info = per_cpu(omap4_pm_info, 0x0);
pm_info-scu_sar_addr = sar_base + SCU_OFFSET0;
- pm_info-wkup_sar_addr = sar_base + CPU0_WAKEUP_NS_PA_ADDR_OFFSET;
+ pm_info-wkup_sar_addr = sar_base + cpu_wakeup_addr;
pm_info-l2x0_sar_addr = sar_base + L2X0_SAVE_OFFSET0;
pm_info-pwrdm = pwrdm_lookup(cpu0_pwrdm);
if (!pm_info-pwrdm) {
@@ -396,14 +405,14 @@ int __init omap4_mpuss_init(void)
/* Initialise CPU0 power domain state to ON */
pwrdm_set_next_pwrst(pm_info-pwrdm, PWRDM_POWER_ON);
+ if (cpu_is_omap44xx())
+ cpu_wakeup_addr = CPU1_WAKEUP_NS_PA_ADDR_OFFSET;
+ else if (soc_is_omap54xx())
+ cpu_wakeup_addr = OMAP5_CPU1_WAKEUP_NS_PA_ADDR_OFFSET;
pm_info = per_cpu(omap4_pm_info, 0x1);
pm_info-scu_sar_addr = sar_base + SCU_OFFSET1;
- pm_info-wkup_sar_addr = sar_base + CPU1_WAKEUP_NS_PA_ADDR_OFFSET;
+ pm_info-wkup_sar_addr = sar_base + cpu_wakeup_addr;
pm_info-l2x0_sar_addr = sar_base + L2X0_SAVE_OFFSET1;
- if (cpu_is_omap446x())
- pm_info-secondary_startup = omap_secondary_startup_4460;
- else
- pm_info-secondary_startup = omap_secondary_startup;
pm_info-pwrdm = pwrdm_lookup(cpu1_pwrdm);
if (!pm_info-pwrdm) {
@@ -436,14 +445,21 @@ int __init omap4_mpuss_init(void)
if (cpu_is_omap44xx()) {
omap_pm_ops.finish_suspend = omap4_finish_suspend;
+ omap_pm_ops.hotplug_restart = omap_secondary_startup;
omap_pm_ops.resume = omap4_cpu_resume;
omap_pm_ops.scu_prepare = scu_pwrst_prepare;
cpu_context_offset = OMAP4_RM_CPU0_CPU0_CONTEXT_OFFSET;
} else if (soc_is_omap54xx()) {
+ omap_pm_ops.finish_suspend =
[PATCH v2 16/18] ARM: OMAP4+: CPUidle: Deprecate use of omap4_mpuss_read_prev_context_state()
Current OMAP4 CPUIdle driver is using omap4_mpuss_read_prev_context_state()
function to check whether the MPU cluster lost context or not. Thanks to
couple CPUIdle, cluster low power entry is almost guaranteed and hence
the programmed cluster check is enough in idle exit path. The API was
more of an optimization for corner cases, where if the cluster low power
entry fails for some reason, the cluster context restore gets skipped.
Moving forward, OMAP CPUidle drivers needs to be moved to drivers/idle/*
once the PRM/CM code gets moved to drivers. This patch also reduces one
dependency with platform code for idle driver movement.
Acked-by: Nishanth Menon n...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/common.h |5 -
arch/arm/mach-omap2/cpuidle44xx.c |3 ++-
arch/arm/mach-omap2/omap-mpuss-lowpower.c | 14 --
3 files changed, 2 insertions(+), 20 deletions(-)
diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index f75d972..6b97d42 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -250,7 +250,6 @@ extern int omap4_enter_lowpower(unsigned int cpu, unsigned
int power_state);
extern int omap4_finish_suspend(unsigned long cpu_state);
extern void omap4_cpu_resume(void);
extern int omap4_hotplug_cpu(unsigned int cpu, unsigned int power_state);
-extern u32 omap4_mpuss_read_prev_context_state(void);
#else
static inline int omap4_enter_lowpower(unsigned int cpu,
unsigned int power_state)
@@ -278,10 +277,6 @@ static inline int omap4_finish_suspend(unsigned long
cpu_state)
static inline void omap4_cpu_resume(void)
{}
-static inline u32 omap4_mpuss_read_prev_context_state(void)
-{
- return 0;
-}
#endif
struct omap_sdrc_params;
diff --git a/arch/arm/mach-omap2/cpuidle44xx.c
b/arch/arm/mach-omap2/cpuidle44xx.c
index ac6d526..e6218d3 100644
--- a/arch/arm/mach-omap2/cpuidle44xx.c
+++ b/arch/arm/mach-omap2/cpuidle44xx.c
@@ -146,7 +146,8 @@ static int omap_enter_idle_coupled(struct cpuidle_device
*dev,
* Call idle CPU cluster PM exit notifier chain
* to restore GIC and wakeupgen context.
*/
- if (omap4_mpuss_read_prev_context_state())
+ if ((cx-mpu_state == PWRDM_POWER_RET)
+ (cx-mpu_logic_state == PWRDM_POWER_OFF))
cpu_cluster_pm_exit();
clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, cpu_id);
diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
index 995443a..6e917d7 100644
--- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
+++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
@@ -185,20 +185,6 @@ static inline void cpu_clear_prev_logic_pwrst(unsigned int
cpu_id)
}
}
-/**
- * omap4_mpuss_read_prev_context_state:
- * Function returns the MPUSS previous context state
- */
-u32 omap4_mpuss_read_prev_context_state(void)
-{
- u32 reg;
-
- reg = omap4_prminst_read_inst_reg(OMAP4430_PRM_PARTITION,
- OMAP4430_PRM_MPU_INST, OMAP4_RM_MPU_MPU_CONTEXT_OFFSET);
- reg = OMAP4430_LOSTCONTEXT_DFF_MASK;
- return reg;
-}
-
/*
* Store the CPU cluster state for L2X0 low power operations.
*/
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 17/18] ARM: OMAP4+: CPUidle: Add OMAP5 idle driver support
The OMAP5 idle driver can re-use OMAP4 CPUidle driver implementation thanks
to compatible MPUSS design.
Though unlike OMAP4, on OMAP5 devices, MPUSS CSWR (Close Switch Retention)
power states can be achieved with respective power states on CPU0 and CPU1
power domain. This mode was broken on OMAP4 devices because of hardware
limitation. Also there is no CPU low power entry order requirement like
master CPU etc for CSWR C-state, which is icing on the cake. Code makes
use of voting scheme for cluster low power state to support MPUSS CSWR
C-state.
Supported OMAP5 CPUidle C-states:
C1 - CPU0 ON(WFI) + CPU1 ON(WFI) + MPUSS ON
C2 - CPU0 CSWR + CPU1 CSWR + MPUSS CSWR
C3 - CPU0 OFF + CPU1 OFF + MPUSS OSWR
Acked-by: Nishanth Menon n...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/Kconfig|1 +
arch/arm/mach-omap2/Makefile |3 +-
.../{cpuidle44xx.c = cpuidle_omap4plus.c} | 110 +++-
arch/arm/mach-omap2/omap-mpuss-lowpower.c |7 +-
arch/arm/mach-omap2/pm_omap4plus.c |2 +-
5 files changed, 115 insertions(+), 8 deletions(-)
rename arch/arm/mach-omap2/{cpuidle44xx.c = cpuidle_omap4plus.c} (69%)
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index b9c0ed3..838ea67 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -105,6 +105,7 @@ config SOC_OMAP5
select HAVE_SMP
select COMMON_CLK
select HAVE_ARM_ARCH_TIMER
+ select ARCH_NEEDS_CPU_IDLE_COUPLED
comment OMAP Core Type
depends on ARCH_OMAP2
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index d91ae0f..ddaaa6c 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -102,7 +102,8 @@ endif
ifeq ($(CONFIG_CPU_IDLE),y)
obj-$(CONFIG_ARCH_OMAP3)+= cpuidle34xx.o
-obj-$(CONFIG_ARCH_OMAP4)+= cpuidle44xx.o
+obj-$(CONFIG_ARCH_OMAP4) += cpuidle_omap4plus.o
+obj-$(CONFIG_SOC_OMAP5)+= cpuidle_omap4plus.o
endif
# PRCM
diff --git a/arch/arm/mach-omap2/cpuidle44xx.c
b/arch/arm/mach-omap2/cpuidle_omap4plus.c
similarity index 69%
rename from arch/arm/mach-omap2/cpuidle44xx.c
rename to arch/arm/mach-omap2/cpuidle_omap4plus.c
index e6218d3..defb830 100644
--- a/arch/arm/mach-omap2/cpuidle44xx.c
+++ b/arch/arm/mach-omap2/cpuidle_omap4plus.c
@@ -22,12 +22,14 @@
#include pm.h
#include prm.h
#include clockdomain.h
+#include soc.h
/* Machine specific information */
struct idle_statedata {
u32 cpu_state;
u32 mpu_logic_state;
u32 mpu_state;
+ u32 mpu_state_vote;
};
static struct idle_statedata omap4_idle_data[] = {
@@ -48,17 +50,36 @@ static struct idle_statedata omap4_idle_data[] = {
},
};
+static struct idle_statedata omap5_idle_data[] = {
+ {
+ .cpu_state = PWRDM_POWER_ON,
+ .mpu_state = PWRDM_POWER_ON,
+ .mpu_logic_state = PWRDM_POWER_RET,
+ },
+ {
+ .cpu_state = PWRDM_POWER_RET,
+ .mpu_state = PWRDM_POWER_RET,
+ .mpu_logic_state = PWRDM_POWER_RET,
+ },
+ {
+ .cpu_state = PWRDM_POWER_OFF,
+ .mpu_state = PWRDM_POWER_RET,
+ .mpu_logic_state = PWRDM_POWER_OFF,
+ },
+};
+
static struct powerdomain *mpu_pd, *cpu_pd[NR_CPUS];
static struct clockdomain *cpu_clkdm[NR_CPUS];
static atomic_t abort_barrier;
static bool cpu_done[NR_CPUS];
-static struct idle_statedata *state_ptr = omap4_idle_data[0];
+static struct idle_statedata *state_ptr;
+static DEFINE_RAW_SPINLOCK(mpu_lock);
/* Private functions */
/**
- * omap_enter_idle_[simple/coupled] - OMAP4PLUS cpuidle entry functions
+ * omap_enter_idle_[simple/smp/coupled] - OMAP4PLUS cpuidle entry functions
* @dev: cpuidle device
* @drv: cpuidle driver
* @index: the index of state to be entered
@@ -131,6 +152,8 @@ static int omap_enter_idle_coupled(struct cpuidle_device
*dev,
/* Wakeup CPU1 only if it is not offlined */
if (dev-cpu == 0 cpumask_test_cpu(1, cpu_online_mask)) {
+ /* Restore MPU PD state post idle */
+ omap_set_pwrdm_state(mpu_pd, PWRDM_POWER_ON);
clkdm_wakeup(cpu_clkdm[1]);
omap_set_pwrdm_state(cpu_pd[1], PWRDM_POWER_ON);
clkdm_allow_idle(cpu_clkdm[1]);
@@ -159,6 +182,37 @@ fail:
return index;
}
+static int omap_enter_idle_smp(struct cpuidle_device *dev,
+ struct cpuidle_driver *drv,
+ int index)
+{
+ struct idle_statedata *cx = state_ptr + index;
+ int cpu_id = smp_processor_id();
+ unsigned long flag;
+
+ clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, cpu_id);
+
+ raw_spin_lock_irqsave(mpu_lock, flag);
+ cx-mpu_state_vote++;
+
[PATCH v2 15/18] ARM: OMAP4+: CPUidle: Consolidate idle driver for OMAP5 support
The OMAP5 idle driver can re-use most of OMAP4 CPUidle driver
implementation. Also the next derivative SOCs are going to re-use
the MPUSS so, same driver with minor updates can be re-used.
Prepare the code so that its easier to add CPUidle support for
OMAP5 devices.
Acked-by: Nishanth Menon n...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/cpuidle44xx.c | 31 ---
1 file changed, 16 insertions(+), 15 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle44xx.c
b/arch/arm/mach-omap2/cpuidle44xx.c
index b8a22f0..ac6d526 100644
--- a/arch/arm/mach-omap2/cpuidle44xx.c
+++ b/arch/arm/mach-omap2/cpuidle44xx.c
@@ -1,7 +1,7 @@
/*
- * OMAP4 CPU idle Routines
+ * OMAP4PLUS CPU idle Routines
*
- * Copyright (C) 2011 Texas Instruments, Inc.
+ * Copyright (C) 2011-2013 Texas Instruments, Inc.
* Santosh Shilimkar santosh.shilim...@ti.com
* Rajendra Nayak rna...@ti.com
*
@@ -24,13 +24,13 @@
#include clockdomain.h
/* Machine specific information */
-struct omap4_idle_statedata {
+struct idle_statedata {
u32 cpu_state;
u32 mpu_logic_state;
u32 mpu_state;
};
-static struct omap4_idle_statedata omap4_idle_data[] = {
+static struct idle_statedata omap4_idle_data[] = {
{
.cpu_state = PWRDM_POWER_ON,
.mpu_state = PWRDM_POWER_ON,
@@ -53,11 +53,12 @@ static struct clockdomain *cpu_clkdm[NR_CPUS];
static atomic_t abort_barrier;
static bool cpu_done[NR_CPUS];
+static struct idle_statedata *state_ptr = omap4_idle_data[0];
/* Private functions */
/**
- * omap4_enter_idle_coupled_[simple/coupled] - OMAP4 cpuidle entry functions
+ * omap_enter_idle_[simple/coupled] - OMAP4PLUS cpuidle entry functions
* @dev: cpuidle device
* @drv: cpuidle driver
* @index: the index of state to be entered
@@ -66,7 +67,7 @@ static bool cpu_done[NR_CPUS];
* specified low power state selected by the governor.
* Returns the amount of time spent in the low power state.
*/
-static int omap4_enter_idle_simple(struct cpuidle_device *dev,
+static int omap_enter_idle_simple(struct cpuidle_device *dev,
struct cpuidle_driver *drv,
int index)
{
@@ -74,11 +75,11 @@ static int omap4_enter_idle_simple(struct cpuidle_device
*dev,
return index;
}
-static int omap4_enter_idle_coupled(struct cpuidle_device *dev,
+static int omap_enter_idle_coupled(struct cpuidle_device *dev,
struct cpuidle_driver *drv,
int index)
{
- struct omap4_idle_statedata *cx = omap4_idle_data[index];
+ struct idle_statedata *cx = state_ptr + index;
int cpu_id = smp_processor_id();
/*
@@ -167,7 +168,7 @@ static void omap_setup_broadcast_timer(void *arg)
clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ON, cpu);
}
-static DEFINE_PER_CPU(struct cpuidle_device, omap4_idle_dev);
+static DEFINE_PER_CPU(struct cpuidle_device, omap_idle_dev);
static struct cpuidle_driver omap4_idle_driver = {
.name = omap4_idle,
@@ -179,7 +180,7 @@ static struct cpuidle_driver omap4_idle_driver = {
.exit_latency = 2 + 2,
.target_residency = 5,
.flags = CPUIDLE_FLAG_TIME_VALID,
- .enter = omap4_enter_idle_simple,
+ .enter = omap_enter_idle_simple,
.name = C1,
.desc = CPUx ON, MPUSS ON
},
@@ -188,7 +189,7 @@ static struct cpuidle_driver omap4_idle_driver = {
.exit_latency = 328 + 440,
.target_residency = 960,
.flags = CPUIDLE_FLAG_TIME_VALID | CPUIDLE_FLAG_COUPLED,
- .enter = omap4_enter_idle_coupled,
+ .enter = omap_enter_idle_coupled,
.name = C2,
.desc = CPUx OFF, MPUSS CSWR,
},
@@ -197,7 +198,7 @@ static struct cpuidle_driver omap4_idle_driver = {
.exit_latency = 460 + 518,
.target_residency = 1100,
.flags = CPUIDLE_FLAG_TIME_VALID | CPUIDLE_FLAG_COUPLED,
- .enter = omap4_enter_idle_coupled,
+ .enter = omap_enter_idle_coupled,
.name = C3,
.desc = CPUx OFF, MPUSS OSWR,
},
@@ -209,9 +210,9 @@ static struct cpuidle_driver omap4_idle_driver = {
/* Public functions */
/**
- * omap4_idle_init - Init routine for OMAP4 idle
+ * omap4_idle_init - Init routine for OMAP4PLUS idle
*
- * Registers the OMAP4 specific cpuidle driver to the cpuidle
+ * Registers the OMAP4PLUS specific cpuidle driver to the cpuidle
* framework with the valid set of states.
*/
int __init omap4_idle_init(void)
@@ -239,7 +240,7 @@ int __init
[PATCH v2 18/18] ARM: OMAP5: PM: handle device instance for warm reset
From: Nishanth Menon n...@ti.com
OMAP5 and OMAP4 have different device instance offsets.
So to handle them properly, use a runtime detected instance offset
Other bit offsets and register offsets remained constant.
Creating a new function is not really worthwhile here as the logic
will be replicated without much benefit.
Signed-off-by: Nishanth Menon n...@ti.com
[santosh.shilim...@ti.com: Refreshed patch against 3.9]
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/prminst44xx.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/prminst44xx.c
b/arch/arm/mach-omap2/prminst44xx.c
index c12320c..430fb1d 100644
--- a/arch/arm/mach-omap2/prminst44xx.c
+++ b/arch/arm/mach-omap2/prminst44xx.c
@@ -20,10 +20,12 @@
#include common.h
#include prcm-common.h
#include prm44xx.h
+#include prm54xx.h
#include prminst44xx.h
#include prm-regbits-44xx.h
#include prcm44xx.h
#include prcm_mpu44xx.h
+#include soc.h
static void __iomem *_prm_bases[OMAP4_MAX_PRCM_PARTITIONS];
@@ -165,17 +167,19 @@ int omap4_prminst_deassert_hardreset(u8 shift, u8 part,
s16 inst,
void omap4_prminst_global_warm_sw_reset(void)
{
u32 v;
+ s16 dev_inst = cpu_is_omap44xx() ? OMAP4430_PRM_DEVICE_INST :
+ OMAP54XX_PRM_DEVICE_INST;
v = omap4_prminst_read_inst_reg(OMAP4430_PRM_PARTITION,
- OMAP4430_PRM_DEVICE_INST,
+ dev_inst,
OMAP4_PRM_RSTCTRL_OFFSET);
v |= OMAP4430_RST_GLOBAL_WARM_SW_MASK;
omap4_prminst_write_inst_reg(v, OMAP4430_PRM_PARTITION,
-OMAP4430_PRM_DEVICE_INST,
+dev_inst,
OMAP4_PRM_RSTCTRL_OFFSET);
/* OCP barrier */
v = omap4_prminst_read_inst_reg(OMAP4430_PRM_PARTITION,
- OMAP4430_PRM_DEVICE_INST,
+ dev_inst,
OMAP4_PRM_RSTCTRL_OFFSET);
}
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 12/18] ARM: OMAP4: CPUidle: Avoid double idle driver registration
OMAP4 CPUidle driver registration call is under a loop which leads
to calling cpuidle_register_driver twice which is not intended.
Fix it by moving the driver registration outside the loop.
Reported-by: Nishanth Menon n...@ti.com
Acked-by: Nishanth Menon n...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/cpuidle44xx.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle44xx.c
b/arch/arm/mach-omap2/cpuidle44xx.c
index 9de47a7..d00b1ec 100644
--- a/arch/arm/mach-omap2/cpuidle44xx.c
+++ b/arch/arm/mach-omap2/cpuidle44xx.c
@@ -233,14 +233,14 @@ int __init omap4_idle_init(void)
/* Configure the broadcast timer on each cpu */
on_each_cpu(omap_setup_broadcast_timer, NULL, 1);
+ cpuidle_register_driver(omap4_idle_driver);
+
for_each_cpu(cpu_id, cpu_online_mask) {
dev = per_cpu(omap4_idle_dev, cpu_id);
dev-cpu = cpu_id;
#ifdef CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED
dev-coupled_cpus = *cpu_online_mask;
#endif
- cpuidle_register_driver(omap4_idle_driver);
-
if (cpuidle_register_device(dev)) {
pr_err(%s: CPUidle register failed\n, __func__);
return -EIO;
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 13/18] ARM: OMAP: CPUidle: Unregister drivere on device registration failure
If the CPUidle device registration fails for some reason, we should
unregister the driver on error path.
Fix the code accordingly. Also when at it, check of the driver registration
failure too.
Acked-by: Nishanth Menon n...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/cpuidle34xx.c |6 +-
arch/arm/mach-omap2/cpuidle44xx.c |6 +-
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c
b/arch/arm/mach-omap2/cpuidle34xx.c
index 06f567f..e193ea2 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -355,7 +355,10 @@ int __init omap3_idle_init(void)
if (!mpu_pd || !core_pd || !per_pd || !cam_pd)
return -ENODEV;
- cpuidle_register_driver(omap3_idle_driver);
+ if (cpuidle_register_driver(omap3_idle_driver)) {
+ pr_err(%s: CPUidle driver register failed\n, __func__);
+ return -EIO;
+ }
dev = per_cpu(omap3_idle_dev, smp_processor_id());
dev-cpu = 0;
@@ -363,6 +366,7 @@ int __init omap3_idle_init(void)
if (cpuidle_register_device(dev)) {
printk(KERN_ERR %s: CPUidle register device failed\n,
__func__);
+ cpuidle_unregister_driver(omap3_idle_driver);
return -EIO;
}
diff --git a/arch/arm/mach-omap2/cpuidle44xx.c
b/arch/arm/mach-omap2/cpuidle44xx.c
index d00b1ec..908114d 100644
--- a/arch/arm/mach-omap2/cpuidle44xx.c
+++ b/arch/arm/mach-omap2/cpuidle44xx.c
@@ -233,7 +233,10 @@ int __init omap4_idle_init(void)
/* Configure the broadcast timer on each cpu */
on_each_cpu(omap_setup_broadcast_timer, NULL, 1);
- cpuidle_register_driver(omap4_idle_driver);
+ if (cpuidle_register_driver(omap4_idle_driver)) {
+ pr_err(%s: CPUidle driver register failed\n, __func__);
+ return -EIO;
+ }
for_each_cpu(cpu_id, cpu_online_mask) {
dev = per_cpu(omap4_idle_dev, cpu_id);
@@ -243,6 +246,7 @@ int __init omap4_idle_init(void)
#endif
if (cpuidle_register_device(dev)) {
pr_err(%s: CPUidle register failed\n, __func__);
+ cpuidle_unregister_driver(omap4_idle_driver);
return -EIO;
}
}
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 14/18] ARM: OMAP4: CPUidle: Make C-state description field more precise
It is useful to know the CPU power state along with MPUSS power state
in a supported C-state. Since the data is available via sysfs, one can
avoid scrolling the source code for precise construction of C-state.
Reported-by: Nishanth Menon n...@ti.com
Acked-by: Nishanth Menon n...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/cpuidle44xx.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle44xx.c
b/arch/arm/mach-omap2/cpuidle44xx.c
index 908114d..b8a22f0 100644
--- a/arch/arm/mach-omap2/cpuidle44xx.c
+++ b/arch/arm/mach-omap2/cpuidle44xx.c
@@ -181,7 +181,7 @@ static struct cpuidle_driver omap4_idle_driver = {
.flags = CPUIDLE_FLAG_TIME_VALID,
.enter = omap4_enter_idle_simple,
.name = C1,
- .desc = MPUSS ON
+ .desc = CPUx ON, MPUSS ON
},
{
/* C2 - CPU0 OFF + CPU1 OFF + MPU CSWR */
@@ -190,7 +190,7 @@ static struct cpuidle_driver omap4_idle_driver = {
.flags = CPUIDLE_FLAG_TIME_VALID | CPUIDLE_FLAG_COUPLED,
.enter = omap4_enter_idle_coupled,
.name = C2,
- .desc = MPUSS CSWR,
+ .desc = CPUx OFF, MPUSS CSWR,
},
{
/* C3 - CPU0 OFF + CPU1 OFF + MPU OSWR */
@@ -199,7 +199,7 @@ static struct cpuidle_driver omap4_idle_driver = {
.flags = CPUIDLE_FLAG_TIME_VALID | CPUIDLE_FLAG_COUPLED,
.enter = omap4_enter_idle_coupled,
.name = C3,
- .desc = MPUSS OSWR,
+ .desc = CPUx OFF, MPUSS OSWR,
},
},
.state_count = ARRAY_SIZE(omap4_idle_data),
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 10/18] ARM: OMAP5: PM: Add MPU Open Switch Retention support
In MPUSS OSWR(Open Switch Retention), entire CPU cluster is powered down
except L2 cache memory. For MPUSS OSWR state, both CPU's needs to be in
power off state.
Acked-by: Nishanth Menon n...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/omap-mpuss-lowpower.c |1 +
arch/arm/mach-omap2/omap-secure.h |5 +
arch/arm/mach-omap2/omap-wakeupgen.c | 11 ++-
arch/arm/mach-omap2/sleep_omap4plus.S |1 +
4 files changed, 13 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
index 096f489..995443a 100644
--- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
+++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
@@ -452,6 +452,7 @@ int __init omap4_mpuss_init(void)
} else if (soc_is_omap54xx()) {
omap_pm_ops.finish_suspend = omap5_finish_suspend;
omap_pm_ops.hotplug_restart = omap5_secondary_startup;
+ omap_pm_ops.resume = cpu_resume;
cpu_context_offset = OMAP54XX_RM_CPU0_CPU0_CONTEXT_OFFSET;
enable_mercury_retention_mode();
}
diff --git a/arch/arm/mach-omap2/omap-secure.h
b/arch/arm/mach-omap2/omap-secure.h
index 6f4dbee..1739468 100644
--- a/arch/arm/mach-omap2/omap-secure.h
+++ b/arch/arm/mach-omap2/omap-secure.h
@@ -34,6 +34,10 @@
#define OMAP4_HAL_SAVEHW_INDEX 0x1b
#define OMAP4_HAL_SAVEALL_INDEX0x1c
#define OMAP4_HAL_SAVEGIC_INDEX0x1d
+#define OMAP5_HAL_SAVESECURERAM_INDEX 0x1c
+#define OMAP5_HAL_SAVEHW_INDEX 0x1d
+#define OMAP5_HAL_SAVEALL_INDEX0x1e
+#define OMAP5_HAL_SAVEGIC_INDEX0x1f
/* Secure Monitor mode APIs */
#define OMAP4_MON_SCU_PWR_INDEX0x108
@@ -42,6 +46,7 @@
#define OMAP4_MON_L2X0_AUXCTRL_INDEX 0x109
#define OMAP4_MON_L2X0_PREFETCH_INDEX 0x113
#define OMAP5_MON_CACHES_CLEAN_INDEX 0x103
+#define OMAP5_MON_AUX_CTRL_INDEX 0x107
#define OMAP5_MON_AMBA_IF_INDEX0x108
diff --git a/arch/arm/mach-omap2/omap-wakeupgen.c
b/arch/arm/mach-omap2/omap-wakeupgen.c
index 8bcaa8c..1697cec 100644
--- a/arch/arm/mach-omap2/omap-wakeupgen.c
+++ b/arch/arm/mach-omap2/omap-wakeupgen.c
@@ -50,7 +50,7 @@ static DEFINE_RAW_SPINLOCK(wakeupgen_lock);
static unsigned int irq_target_cpu[MAX_IRQS];
static unsigned int irq_banks = MAX_NR_REG_BANKS;
static unsigned int max_irqs = MAX_IRQS;
-static unsigned int omap_secure_apis;
+static unsigned int omap_secure_apis, secure_api_index;
/*
* Static helper functions.
@@ -320,7 +320,7 @@ static void irq_sar_clear(void)
static void irq_save_secure_context(void)
{
u32 ret;
- ret = omap_secure_dispatcher(OMAP4_HAL_SAVEGIC_INDEX,
+ ret = omap_secure_dispatcher(secure_api_index,
FLAG_START_CRITICAL,
0, 0, 0, 0, 0);
if (ret != API_HAL_RET_VALUE_OK)
@@ -382,9 +382,7 @@ static struct notifier_block irq_notifier_block = {
static void __init irq_pm_init(void)
{
- /* FIXME: Remove this when MPU OSWR support is added */
- if (!soc_is_omap54xx())
- cpu_pm_register_notifier(irq_notifier_block);
+ cpu_pm_register_notifier(irq_notifier_block);
}
#else
static void __init irq_pm_init(void)
@@ -425,6 +423,9 @@ int __init omap_wakeupgen_init(void)
irq_banks = OMAP4_NR_BANKS;
max_irqs = OMAP4_NR_IRQS;
omap_secure_apis = 1;
+ secure_api_index = OMAP4_HAL_SAVEGIC_INDEX;
+ } else if (soc_is_omap54xx()) {
+ secure_api_index = OMAP5_HAL_SAVEGIC_INDEX;
}
/* Clear all IRQ bitmasks at wakeupGen level */
diff --git a/arch/arm/mach-omap2/sleep_omap4plus.S
b/arch/arm/mach-omap2/sleep_omap4plus.S
index 5a372a6..4a5e2e4 100644
--- a/arch/arm/mach-omap2/sleep_omap4plus.S
+++ b/arch/arm/mach-omap2/sleep_omap4plus.S
@@ -336,6 +336,7 @@ ENDPROC(omap4_cpu_resume)
* save_state =
* 0 - Nothing lost and no need to save: MPUSS INA/CSWR
* 1 - CPUx L1 and logic lost: CPU OFF, MPUSS INA/CSWR
+ * 2 - CPUx L1 and logic lost + GIC lost: MPUSS OSWR
*/
ENTRY(omap5_finish_suspend)
stmfd sp!, {r4-r12, lr}
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Overo expansion board selection with Kconfig (Was: Re: Display related board specific boot args)
On 2013-03-22 17:36, Tony Lindgren wrote:
Would the Kconfig option be acceptable?
Yes I think that's better than cmdline option in this case considering that
the cmdline option won't be needed at some point in the future.
Here's a diff for the changes for Overo. This is not a real patch yet,
just an RFC for the naming of the Kconfig options, and if this approach
is generally ok. Some other boards need similar setup also, but I think
Overo is the most complex case.
I only handle the displays here, and only three overo expansion boards.
I didn't find any of the expansion boards having analog TV out, so I removed
it.
I'm not sure if MACH_XXX style options should be reserved for boards only. It
just seemed like a logical way to extend the MACH_OVERO with
MACH_OVERO_EXPANSION_XXX.
Tomi
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 8111cd9..f30aadb 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -238,6 +238,28 @@ config MACH_OVERO
default y
select OMAP_PACKAGE_CBB
+choice
+ depends on MACH_OVERO
+ default MACH_OVERO_EXPANSION_PALO43
+ prompt Overo Expansion Board
+
+config MACH_OVERO_EXPANSION_PALO43
+ bool Gumstix Overo Palo43 Expansion Board
+ help
+ Palo43 Expansion board with Samsung 4.3 480x272 LCD.
+
+config MACH_OVERO_EXPANSION_PALO35
+ bool Gumstix Overo Palo35 Expansion Board
+ help
+ Palo35 Expansion board with LG 3.5 320x240 LCD.
+
+config MACH_OVERO_EXPANSION_SUMMIT
+ bool Gumstix Overo Summit Expansion Board
+ help
+ Summit expansion board with DVI output.
+
+endchoice
+
config MACH_OMAP3EVM
bool OMAP 3530 EVM board
depends on ARCH_OMAP3
diff --git a/arch/arm/mach-omap2/board-overo.c
b/arch/arm/mach-omap2/board-overo.c
index 86bab51..d9df651 100644
--- a/arch/arm/mach-omap2/board-overo.c
+++ b/arch/arm/mach-omap2/board-overo.c
@@ -145,9 +145,6 @@ static void __init overo_init_smsc911x(void)
static inline void __init overo_init_smsc911x(void) { return; }
#endif
-/* DSS */
-static int lcd_enabled;
-static int dvi_enabled;
#define OVERO_GPIO_LCD_EN 144
#define OVERO_GPIO_LCD_BL 145
@@ -168,6 +165,8 @@ static void __init overo_display_init(void)
gpio_export(OVERO_GPIO_LCD_BL, 0);
}
+#if defined(CONFIG_MACH_OVERO_EXPANSION_SUMMIT)
+
static struct tfp410_platform_data dvi_panel = {
.i2c_bus_num= 3,
.power_down_gpio= -1,
@@ -181,23 +180,56 @@ static struct omap_dss_device overo_dvi_device = {
.phy.dpi.data_lines = 24,
};
-static struct omap_dss_device overo_tv_device = {
- .name = tv,
- .driver_name = venc,
- .type = OMAP_DISPLAY_TYPE_VENC,
- .phy.venc.type = OMAP_DSS_VENC_TYPE_SVIDEO,
+static struct omap_dss_device *overo_dss_devices[] = {
+ overo_dvi_device,
};
+static struct omap_dss_board_info overo_dss_data = {
+ .num_devices= ARRAY_SIZE(overo_dss_devices),
+ .devices= overo_dss_devices,
+ .default_device = overo_dvi_device,
+};
+
+#elif defined(CONFIG_MACH_OVERO_EXPANSION_PALO35)
+
static int overo_panel_enable_lcd(struct omap_dss_device *dssdev)
{
- if (dvi_enabled) {
- printk(KERN_ERR cannot enable LCD, DVI is enabled\n);
- return -EINVAL;
- }
+ gpio_set_value(OVERO_GPIO_LCD_EN, 1);
+ gpio_set_value(OVERO_GPIO_LCD_BL, 1);
+ return 0;
+}
+
+static void overo_panel_disable_lcd(struct omap_dss_device *dssdev)
+{
+ gpio_set_value(OVERO_GPIO_LCD_EN, 0);
+ gpio_set_value(OVERO_GPIO_LCD_BL, 0);
+}
+
+static struct omap_dss_device overo_lcd35_device = {
+ .type = OMAP_DISPLAY_TYPE_DPI,
+ .name = lcd35,
+ .driver_name= lgphilips_lb035q02_panel,
+ .phy.dpi.data_lines = 24,
+ .platform_enable= overo_panel_enable_lcd,
+ .platform_disable = overo_panel_disable_lcd,
+};
+
+static struct omap_dss_device *overo_dss_devices[] = {
+ overo_lcd35_device,
+};
+static struct omap_dss_board_info overo_dss_data = {
+ .num_devices= ARRAY_SIZE(overo_dss_devices),
+ .devices= overo_dss_devices,
+ .default_device = overo_lcd35_device,
+};
+
+#elif defined(CONFIG_MACH_OVERO_EXPANSION_PALO43)
+
+static int overo_panel_enable_lcd(struct omap_dss_device *dssdev)
+{
gpio_set_value(OVERO_GPIO_LCD_EN, 1);
gpio_set_value(OVERO_GPIO_LCD_BL, 1);
- lcd_enabled = 1;
return 0;
}
@@ -205,7 +237,6 @@ static void overo_panel_disable_lcd(struct omap_dss_device
*dssdev)
{
gpio_set_value(OVERO_GPIO_LCD_EN, 0);
gpio_set_value(OVERO_GPIO_LCD_BL, 0);
- lcd_enabled = 0;
}
static struct panel_generic_dpi_data lcd43_panel = {
@@ -222,34 +253,18 @@ static struct omap_dss_device overo_lcd43_device = {
.phy.dpi.data_lines = 24,
};
-#if
Re: [PATCH 2/2] cpufreq: drivers: Remove unnecessary assignments of policy- members
On 25 March 2013 15:11, Sekhar Nori nsek...@ti.com wrote:
So down in the cpufreq driver probe below, we bail out if freq_table is
not provided. So all this checking for freq_table in the code you pasted
above is superfluous. If you can clean that part up and add checking for
cpufreq_frequency_table_cpuinfo() as you proposed, I will be glad to
test it out ;)
Attached is the complete patch and following is your fixup for davinci
(just to review):
diff --git a/arch/arm/mach-davinci/cpufreq.c b/arch/arm/mach-davinci/cpufreq.c
index ff46862..7c2e943 100644
--- a/arch/arm/mach-davinci/cpufreq.c
+++ b/arch/arm/mach-davinci/cpufreq.c
@@ -137,18 +137,17 @@ static int davinci_cpu_init(struct cpufreq_policy *policy)
return result;
}
- policy-cur = policy-min = policy-max = davinci_getspeed(0);
-
- if (freq_table) {
- result = cpufreq_frequency_table_cpuinfo(policy, freq_table);
- if (!result)
- cpufreq_frequency_table_get_attr(freq_table,
- policy-cpu);
- } else {
- policy-cpuinfo.min_freq = policy-min;
- policy-cpuinfo.max_freq = policy-max;
+ policy-cur = davinci_getspeed(0);
+
+ result = cpufreq_frequency_table_cpuinfo(policy, freq_table);
+ if (result) {
+ pr_err(%s: cpufreq_frequency_table_cpuinfo() failed,
+ __func__);
+ return result;
}
+ cpufreq_frequency_table_get_attr(freq_table, policy-cpu);
+
/*
* Time measurement across the target() function yields ~1500-1800us
* time taken with no drivers on notification list.
0001-cpufreq-drivers-Remove-unnecessary-assignments-of-po.patch
Description: Binary data
Re: [PATCH 0/6] mfd: omap-usb-host: Device tree support for 3.10
Hi Samuel, I've rebased this now on top of 3.9-rc4. Please pull this into your next branch when appropriate. Thanks. The following changes since commit 8bb9660418e05bb1845ac1a2428444d78e322cc7: Linux 3.9-rc4 (2013-03-23 16:52:44 -0700) are available in the git repository at: git://github.com/rogerq/linux.git usbhost-mfd-next Roger Quadros (5): mfd: omap-usb-host: update nports in platform_data mfd: omap-usb-host: Remove PHY reset handling code mfd: omap-usb-tll: move configuration code to omap_tll_init() mfd: omap-usb-tll: Add device tree support and binding information mfd: omap-usb-host: Add device tree support and binding information .../devicetree/bindings/mfd/omap-usb-host.txt | 80 .../devicetree/bindings/mfd/omap-usb-tll.txt | 17 ++ drivers/mfd/omap-usb-host.c| 200 ++- drivers/mfd/omap-usb-tll.c | 214 ++-- drivers/mfd/omap-usb.h |5 +- 5 files changed, 362 insertions(+), 154 deletions(-) create mode 100644 Documentation/devicetree/bindings/mfd/omap-usb-host.txt create mode 100644 Documentation/devicetree/bindings/mfd/omap-usb-tll.txt cheers, -roger On 03/12/2013 12:25 PM, Roger Quadros wrote: Hi Samuel, These patches implement device tree support for the OMAP High Speed USB Host subsystem. The corresponding EHCI SoC patches will be sent separately and this set has no build dependencies with them. Patch 3 is acutally a bug fix which should go into 3.9-rc. I've sent it separately to you before. The following changes since commit f6161aa153581da4a3867a2d1a7caf4be19b6ec9: Linux 3.9-rc2 (2013-03-10 16:54:19 -0700) are available in the git repository at: git://github.com/rogerq/linux.git usbhost-mfd-next Roger Quadros (6): mfd: omap-usb-host: update nports in platform_data mfd: omap-usb-host: Remove PHY reset handling code mfd: omap-usb-host: Actually update hostconfig mfd: omap-usb-tll: move configuration code to omap_tll_init() mfd: omap-usb-tll: Add device tree support and binding information mfd: omap-usb-host: Add device tree support and binding information .../devicetree/bindings/mfd/omap-usb-host.txt | 80 .../devicetree/bindings/mfd/omap-usb-tll.txt | 17 ++ drivers/mfd/omap-usb-host.c| 206 ++- drivers/mfd/omap-usb-tll.c | 214 ++-- drivers/mfd/omap-usb.h |5 +- 5 files changed, 365 insertions(+), 157 deletions(-) create mode 100644 Documentation/devicetree/bindings/mfd/omap-usb-host.txt create mode 100644 Documentation/devicetree/bindings/mfd/omap-usb-tll.txt -- cheers, -roger -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: hw_breakpoint: Enable debug powerdown only if system supports 'has_ossr'
On Mon, Mar 25, 2013 at 09:11:00AM +, Santosh Shilimkar wrote: Will, Hi Santosh, Are you going to send the patch for 3.9-rcx ? As I said before without the patch OMAP4 CPUILDE is unusable because of that debug noise and hence it will be good to get that patch in It's in Russell's tree, so should be queued for mainline fairly soon. Will -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: hw_breakpoint: Enable debug powerdown only if system supports 'has_ossr'
On Monday 25 March 2013 04:19 PM, Will Deacon wrote: On Mon, Mar 25, 2013 at 09:11:00AM +, Santosh Shilimkar wrote: Will, Hi Santosh, Are you going to send the patch for 3.9-rcx ? As I said before without the patch OMAP4 CPUILDE is unusable because of that debug noise and hence it will be good to get that patch in It's in Russell's tree, so should be queued for mainline fairly soon. Thanks Will !! Regards Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: AM33XX: Add missing .clkdm_name to clkdiv32k_ick clock
During common-clock migration, .clkdm_name field got missed for clkdiv32k_ick clock, which leaves clk_24mhz_clkdm unused; so boot process will try to disable the clockdomain even childs of this clock is enabled, which keeps child modules in idle mode. This fixes the kernel crash observed on AM335xEVM-Sk platform, where clkdiv32_ick clock is being used as a gpio debounce clock and since clkdiv32k_ick is in idle mode it leads to below crash - Crash Log: = [2.598347] Unhandled fault: external abort on non-linefetch (0x1028) at 0xfa1ac150 [2.606434] Internal error: : 1028 [#1] SMP ARM [2.611207] Modules linked in: [2.614449] CPU: 0Not tainted (3.8.4-01382-g1f449cd-dirty #4) [2.620973] PC is at _set_gpio_debounce+0x60/0x104 [2.626025] LR is at clk_enable+0x30/0x3c [2.630249] pc : [c02e2850]lr : [c0449ad8]psr: 6193 [2.630249] sp : cf053df8 ip : 0001 fp : cf19e000 [2.642308] r10: cdc56800 r9 : cf19e010 r8 : cf0b8410 [2.647802] r7 : 0002 r6 : 0004 r5 : 00a0 r4 : cf0b8410 [2.654668] r3 : fa1ac150 r2 : fa1ac000 r1 : r0 : [2.661540] Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel [2.669324] Control: 10c5387d Table: 80004019 DAC: 0017 [2.675372] Process swapper/0 (pid: 1, stack limit = 0xcf052240) [2.681688] Stack: (0xcf053df8 to 0xcf054000) [2.686279] 3de0: cf0b846c 2113 [2.694892] 3e00: 1388 c02e2924 0002 cf0b848c 2113 1388 c02e0258 [2.703508] 3e20: cdc57ce8 cdca2784 c00028d8 cdc56800 c040ba10 cdc57c50 c08374e0 [2.712115] 3e40: 0001 0028 cdca2784 cdca2740 cdc57c00 cdc56800 c040bc58 [2.720727] 3e60: cf1a0bd0 cf19e010 c08374e0 c0d96ffc c08374e0 cf19e010 c08374e0 [2.729341] 3e80: c076c7b0 c07421c4 c0331c90 c0331c78 c033092c cf19e010 c08374e0 [2.737957] 3ea0: cf19e044 c0330bd8 cf19e010 c08374e0 c0330c84 [2.746573] 3ec0: c08374e0 c0330bf0 c032f2f8 cf0222a8 cf198a10 c08374e0 c08265c8 [2.755185] 3ee0: cdbca7c0 c033015c c067d1e0 c08374e0 c08374e0 c0844600 cf052000 [2.763793] 3f00: c03311b8 c0776fb0 c0844600 cf052000 [2.772393] 3f20: c07421c4 c0008818 0001dd4e 0007 c076c7b0 07753841 [2.780998] 3f40: 9a64d806 9a64d806 6113 c0776fb0 0007 c0776f90 [2.789603] 3f60: c0844600 00af c0793ee8 c07421c4 c07428f8 0007 0007 [2.798217] 3f80: c07421c4 c0513f0c [2.806827] 3fa0: c0513f14 c0013490 [2.815447] 3fc0: [2.824058] 3fe0: 0013 eebff7f9 3a5f1b7e [2.832668] [c02e2850] (_set_gpio_debounce+0x60/0x104) from [c02e2924] (gpio_debounce+0x30/0x44) [2.842272] [c02e2924] (gpio_debounce+0x30/0x44) from [c02e0258] (gpio_set_debounce+0xc4/0xdc) [2.851714] [c02e0258] (gpio_set_debounce+0xc4/0xdc) from [c040ba10] (gpio_keys_setup_key+0x190/0x268) [2.861871] [c040ba10] (gpio_keys_setup_key+0x190/0x268) from [c040bc58] (gpio_keys_probe+0x170/0x274) [2.872046] [c040bc58] (gpio_keys_probe+0x170/0x274) from [c0331c90] (platform_drv_probe+0x18/0x1c) [2.881940] [c0331c90] (platform_drv_probe+0x18/0x1c) from [c033092c] (really_probe+0x60/0x1f4) [2.891453] [c033092c] (really_probe+0x60/0x1f4) from [c0330bd8] (driver_probe_device+0x30/0x48) [2.901064] [c0330bd8] (driver_probe_device+0x30/0x48) from [c0330c84] (__driver_attach+0x94/0x98) [2.910858] [c0330c84] (__driver_attach+0x94/0x98) from [c032f2f8] (bus_for_each_dev+0x64/0x88) [2.920380] [c032f2f8] (bus_for_each_dev+0x64/0x88) from [c033015c] (bus_add_driver+0xa0/0x240) [2.929900] [c033015c] (bus_add_driver+0xa0/0x240) from [c03311b8] (driver_register+0x78/0x144) [2.939434] [c03311b8] (driver_register+0x78/0x144) from [c0008818] (do_one_initcall+0x118/0x180) [2.949160] [c0008818] (do_one_initcall+0x118/0x180) from [c07428f8] (kernel_init_freeable+0xfc/0x1cc) [2.959343] [c07428f8] (kernel_init_freeable+0xfc/0x1cc) from [c0513f14] (kernel_init+0x8/0xe4) [2.968867] [c0513f14] (kernel_init+0x8/0xe4) from [c0013490] (ret_from_fork+0x14/0x24) [2.977663] Code: e5943108 e5942008 e1d331be e0823003 (e5932000) [2.984092] ---[ end trace d1c5f252789a330b ]--- [2.989241] Kernel panic - not syncing: Attempted to kill init! exitcode=0x000b [2.989241] Signed-off-by: Vaibhav Hiremath hvaib...@ti.com Cc: Tony
Re: [PATCH v2 00/18] ARM: OMAP5: PM: Add MPUSS suspend and CPUidle support
Hi Santosh,
On Monday 25 March 2013 03:34 PM, Santosh Shilimkar wrote:
Kevin,
Here is the refreshed version(v2) of the OMAP5 PM suspport which was posted
earlier (March 1st 2013). Patch-set incorporates comments from Nishant
Menon (Thanks for review NM) and his acked-by tags. I would like to get this
queued for 3.10 merge window if you are ok with the series.
Series is built on top of my pull requests [1] [2] [3] sent to Tony and your
'for_3.10/pm/cleanup' branch. For testing, I have created a branch [4]
which put together all the needed dependencies, fixes which should make it
to 3.10 merge window.
Series adds OMAP5 MPUSS power management support for system wide suspend
and CPUidle. Its heavy re-use from OMAP4 and hence only ~400 odd lines are
needed to add OMAP5 PM support on top of existing OMAP4 PM support.
OMAP5 adds a mercury retention feature which is an enhancement of
existing retention feature to reduce the leakage. No change in
programming model except one time enabling of mercury retention
during init.
One more notable change in OMAP5 vs OMAP4 devices, CPUx power domains
support retention state which lets you hit MPUSS and Core retention with
very low latency C-states.
Tested on OMAP4430 SDP, OMAP4460 Panda, OMAP5430 SDP and OMAP5432 Panda
devices with suspend and CPUIdle. Rootfs is mounted over ramdisk since
the mmc and nfs based fs needs DMA engine patches. For suspend wakeup,
I used Sourav's couple of serial wakeup wip patches from the lists.
I did the following build tests on [1]:
- Native omap2plus build
- Omap2 only build
- Omap3 only build
- Omap4 only build
- Omap5 only build
- AM33XX only build.
- omap1_defconfig
And also did functional testing on [2] where omap5_pm branch[1] is merged.
On OMAP5430 EVM:Suspend to RAM (UART wakeup)
CPU_IDLE
On OMAP4430 SDP:Suspend to RAM (UART wakeup)
CPU_IDLE
Note:
1) Disabled SMP for doing build test on Omap2/3 only builds.
2) If we enable CPU_IDLE on OMAP4430, debug message flood from
reset_ctrl_regs() will appear.
As this is already disussed and a patch is already sent on Mainline
Will get more info on this here[3]
Tested-by: Lokesh Vutla lokeshvu...@ti.com
Thanks and Regards,
Lokesh
[1] git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux
for_3.10/omap5_pm
[2] git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux.git
testing/3.10/omap5_int
[3] https://lkml.org/lkml/2013/3/13/50
The following changes since commit 9981cde24de52e5bb9a7cd918d1e54de241f85c9:
Merge branch 'for_3.10/omap5_data_files' of
git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux into
for_3.10/omap5_pm (2013-03-25 12:29:34 +0530)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux.git
for_3.10/omap5_pm
for you to fetch changes up to 75bd846d3103da858a208fe07127151903d1f608:
ARM: OMAP5: PM: handle device instance for warm reset (2013-03-25 12:37:44
+0530)
Nishanth Menon (1):
ARM: OMAP5: PM: handle device instance for warm reset
Santosh Shilimkar (17):
ARM: OMAP4+: PM: Consolidate MPU subsystem PM code for re-use
ARM: OMAP5: PM: Update CPU context register offset
ARM: OMAP4+: PM: Consolidate and use OMAP4 PM code for OMAP5
ARM: OMAP5: PM: Set MPUSS-EMIF clock-domain static dependency
ARM: OMAP5: PM: Enables ES2 PM mode by default
ARM: OMAP5: PM: Enable Mercury retention mode on CPUx powerdomains
ARM: OMAP5: Add init_late() hook to enable pm initialization
ARM: OMAP5: PM: Add CPU power off in hotplug path
ARM: OMAP4+: PM: Restore CPU power state to ON with clockdomain force
wakeup method
ARM: OMAP5: PM: Add MPU Open Switch Retention support
ARM: OMAP5: PM: Add L2 memory power down support
ARM: OMAP4: CPUidle: Avoid double idle driver registration
ARM: OMAP: CPUidle: Unregister drivere on device registration failure
ARM: OMAP4: CPUidle: Make C-state description field more precise
ARM: OMAP4+: CPUidle: Consolidate idle driver for OMAP5 support
ARM: OMAP4+: CPUidle: Deprecate use of
omap4_mpuss_read_prev_context_state()
ARM: OMAP4+: CPUidle: Add OMAP5 idle driver support
arch/arm/mach-omap2/Kconfig|1 +
arch/arm/mach-omap2/Makefile | 12 +-
arch/arm/mach-omap2/board-generic.c|1 +
arch/arm/mach-omap2/common.h |8 +-
arch/arm/mach-omap2/cpuidle34xx.c |6 +-
.../{cpuidle44xx.c = cpuidle_omap4plus.c} | 151 ---
arch/arm/mach-omap2/io.c |8 +
arch/arm/mach-omap2/omap-mpuss-lowpower.c | 155 +++-
arch/arm/mach-omap2/omap-secure.h
Re: [PATCH v2 00/18] ARM: OMAP5: PM: Add MPUSS suspend and CPUidle support
On Monday 25 March 2013 05:16 PM, Lokesh Vutla wrote: Hi Santosh, On Monday 25 March 2013 03:34 PM, Santosh Shilimkar wrote: Kevin, Here is the refreshed version(v2) of the OMAP5 PM suspport which was posted earlier (March 1st 2013). Patch-set incorporates comments from Nishant Menon (Thanks for review NM) and his acked-by tags. I would like to get this queued for 3.10 merge window if you are ok with the series. Series is built on top of my pull requests [1] [2] [3] sent to Tony and your 'for_3.10/pm/cleanup' branch. For testing, I have created a branch [4] which put together all the needed dependencies, fixes which should make it to 3.10 merge window. Series adds OMAP5 MPUSS power management support for system wide suspend and CPUidle. Its heavy re-use from OMAP4 and hence only ~400 odd lines are needed to add OMAP5 PM support on top of existing OMAP4 PM support. OMAP5 adds a mercury retention feature which is an enhancement of existing retention feature to reduce the leakage. No change in programming model except one time enabling of mercury retention during init. One more notable change in OMAP5 vs OMAP4 devices, CPUx power domains support retention state which lets you hit MPUSS and Core retention with very low latency C-states. Tested on OMAP4430 SDP, OMAP4460 Panda, OMAP5430 SDP and OMAP5432 Panda devices with suspend and CPUIdle. Rootfs is mounted over ramdisk since the mmc and nfs based fs needs DMA engine patches. For suspend wakeup, I used Sourav's couple of serial wakeup wip patches from the lists. I did the following build tests on [1]: - Native omap2plus build - Omap2 only build - Omap3 only build - Omap4 only build - Omap5 only build - AM33XX only build. - omap1_defconfig Thanks for the build coverage. And also did functional testing on [2] where omap5_pm branch[1] is merged. On OMAP5430 EVM: Suspend to RAM (UART wakeup) CPU_IDLE On OMAP4430 SDP: Suspend to RAM (UART wakeup) CPU_IDLE Excellent. Note: 1) Disabled SMP for doing build test on Omap2/3 only builds. I noticed this one as well. 2) If we enable CPU_IDLE on OMAP4430, debug message flood from reset_ctrl_regs() will appear. As this is already disussed and a patch is already sent on Mainline Will get more info on this here[3] Yep. I applied the patch while testing. The patch is already in RMK's queue as per Will D. Tested-by: Lokesh Vutla lokeshvu...@ti.com Thanks a bunch for detailed testing and your tested-by tag. Regards, Santosh [1] git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux for_3.10/omap5_pm [2] git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux.git testing/3.10/omap5_int [3] https://lkml.org/lkml/2013/3/13/50 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 00/18] ARM: OMAP5: PM: Add MPUSS suspend and CPUidle support
Hi Santosh,
On Monday 25 March 2013 03:34 PM, Santosh Shilimkar wrote:
Kevin,
Here is the refreshed version(v2) of the OMAP5 PM suspport which was posted
earlier (March 1st 2013). Patch-set incorporates comments from Nishant
Menon (Thanks for review NM) and his acked-by tags. I would like to get this
queued for 3.10 merge window if you are ok with the series.
Series is built on top of my pull requests [1] [2] [3] sent to Tony and your
'for_3.10/pm/cleanup' branch. For testing, I have created a branch [4]
which put together all the needed dependencies, fixes which should make it
to 3.10 merge window.
Series adds OMAP5 MPUSS power management support for system wide suspend
and CPUidle. Its heavy re-use from OMAP4 and hence only ~400 odd lines are
needed to add OMAP5 PM support on top of existing OMAP4 PM support.
OMAP5 adds a mercury retention feature which is an enhancement of
existing retention feature to reduce the leakage. No change in
programming model except one time enabling of mercury retention
during init.
One more notable change in OMAP5 vs OMAP4 devices, CPUx power domains
support retention state which lets you hit MPUSS and Core retention with
very low latency C-states.
Tested on OMAP4430 SDP, OMAP4460 Panda, OMAP5430 SDP and OMAP5432 Panda
devices with suspend and CPUIdle. Rootfs is mounted over ramdisk since
the mmc and nfs based fs needs DMA engine patches. For suspend wakeup,
I used Sourav's couple of serial wakeup wip patches from the lists.
The following changes since commit 9981cde24de52e5bb9a7cd918d1e54de241f85c9:
Merge branch 'for_3.10/omap5_data_files' of
git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux into
for_3.10/omap5_pm (2013-03-25 12:29:34 +0530)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux.git
for_3.10/omap5_pm
for you to fetch changes up to 75bd846d3103da858a208fe07127151903d1f608:
ARM: OMAP5: PM: handle device instance for warm reset (2013-03-25 12:37:44
+0530)
Nishanth Menon (1):
ARM: OMAP5: PM: handle device instance for warm reset
Santosh Shilimkar (17):
ARM: OMAP4+: PM: Consolidate MPU subsystem PM code for re-use
ARM: OMAP5: PM: Update CPU context register offset
ARM: OMAP4+: PM: Consolidate and use OMAP4 PM code for OMAP5
ARM: OMAP5: PM: Set MPUSS-EMIF clock-domain static dependency
ARM: OMAP5: PM: Enables ES2 PM mode by default
ARM: OMAP5: PM: Enable Mercury retention mode on CPUx powerdomains
ARM: OMAP5: Add init_late() hook to enable pm initialization
ARM: OMAP5: PM: Add CPU power off in hotplug path
ARM: OMAP4+: PM: Restore CPU power state to ON with clockdomain force
wakeup method
ARM: OMAP5: PM: Add MPU Open Switch Retention support
ARM: OMAP5: PM: Add L2 memory power down support
ARM: OMAP4: CPUidle: Avoid double idle driver registration
ARM: OMAP: CPUidle: Unregister drivere on device registration failure
ARM: OMAP4: CPUidle: Make C-state description field more precise
ARM: OMAP4+: CPUidle: Consolidate idle driver for OMAP5 support
ARM: OMAP4+: CPUidle: Deprecate use of
omap4_mpuss_read_prev_context_state()
ARM: OMAP4+: CPUidle: Add OMAP5 idle driver support
arch/arm/mach-omap2/Kconfig|1 +
arch/arm/mach-omap2/Makefile | 12 +-
arch/arm/mach-omap2/board-generic.c|1 +
arch/arm/mach-omap2/common.h |8 +-
arch/arm/mach-omap2/cpuidle34xx.c |6 +-
.../{cpuidle44xx.c = cpuidle_omap4plus.c} | 151 ---
arch/arm/mach-omap2/io.c |8 +
arch/arm/mach-omap2/omap-mpuss-lowpower.c | 155 +++-
arch/arm/mach-omap2/omap-secure.h |9 ++
arch/arm/mach-omap2/omap-smp.c | 12 +-
arch/arm/mach-omap2/omap-wakeupgen.c | 30 +++-
arch/arm/mach-omap2/omap-wakeupgen.h |1 +
arch/arm/mach-omap2/omap4-sar-layout.h |2 +
arch/arm/mach-omap2/{pm44xx.c = pm_omap4plus.c} | 90 ++--
arch/arm/mach-omap2/prminst44xx.c | 10 +-
.../mach-omap2/{sleep44xx.S = sleep_omap4plus.S} | 106 +
16 files changed, 512 insertions(+), 90 deletions(-)
rename arch/arm/mach-omap2/{cpuidle44xx.c = cpuidle_omap4plus.c} (58%)
rename arch/arm/mach-omap2/{pm44xx.c = pm_omap4plus.c} (74%)
rename arch/arm/mach-omap2/{sleep44xx.S = sleep_omap4plus.S} (77%)
Build tested [1] for omap2plus_defconfig.
For [2], where omap5_pm_branch[1] is merged, testing details are as follows:
* Boot tested on omap4430 sdp, omap5 evm.
* Wakeup from UART after suspend using dt was tested on omap4430sdp and
omap5430 evm.
Note: For the above UART testing, we need to append
no_console_suspend in our
bootargs.
Re: [PATCH] ARM: AM33XX: Add missing .clkdm_name to clkdiv32k_ick clock
On Monday 25 March 2013 05:07 PM, Vaibhav Hiremath wrote:
During common-clock migration, .clkdm_name field got missed
for clkdiv32k_ick clock, which leaves clk_24mhz_clkdm
unused; so boot process will try to disable the clockdomain
even childs of this clock is enabled, which keeps child modules
in idle mode.
The patch looks fine but I feel the change log certainly needs an
update. The clkdm association with the clks is maintained for those
clks which have a hard requirement that the clkdm be force woken up
before the clk can be enabled. If thats the case for clkdiv32k_ick,
then what you are doing makes sense, but the changelog is certainlly
confusing when it says 'boot process will try to disable the clockdomain'
This fixes the kernel crash observed on AM335xEVM-Sk platform,
where clkdiv32_ick clock is being used as a gpio debounce clock
and since clkdiv32k_ick is in idle mode it leads to below crash -
Crash Log:
=
[2.598347] Unhandled fault: external abort on non-linefetch (0x1028) at
0xfa1ac150
[2.606434] Internal error: : 1028 [#1] SMP ARM
[2.611207] Modules linked in:
[2.614449] CPU: 0Not tainted (3.8.4-01382-g1f449cd-dirty #4)
[2.620973] PC is at _set_gpio_debounce+0x60/0x104
[2.626025] LR is at clk_enable+0x30/0x3c
[2.630249] pc : [c02e2850]lr : [c0449ad8]psr: 6193
[2.630249] sp : cf053df8 ip : 0001 fp : cf19e000
[2.642308] r10: cdc56800 r9 : cf19e010 r8 : cf0b8410
[2.647802] r7 : 0002 r6 : 0004 r5 : 00a0 r4 : cf0b8410
[2.654668] r3 : fa1ac150 r2 : fa1ac000 r1 : r0 :
[2.661540] Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM
Segment kernel
[2.669324] Control: 10c5387d Table: 80004019 DAC: 0017
[2.675372] Process swapper/0 (pid: 1, stack limit = 0xcf052240)
[2.681688] Stack: (0xcf053df8 to 0xcf054000)
[2.686279] 3de0: cf0b846c 2113
[2.694892] 3e00: 1388 c02e2924 0002 cf0b848c
2113 1388 c02e0258
[2.703508] 3e20: cdc57ce8 cdca2784 c00028d8 cdc56800
c040ba10 cdc57c50 c08374e0
[2.712115] 3e40: 0001 0028 cdca2784 cdca2740 cdc57c00
cdc56800 c040bc58
[2.720727] 3e60: cf1a0bd0 cf19e010 c08374e0 c0d96ffc c08374e0
cf19e010 c08374e0
[2.729341] 3e80: c076c7b0 c07421c4 c0331c90 c0331c78
c033092c cf19e010 c08374e0
[2.737957] 3ea0: cf19e044 c0330bd8
cf19e010 c08374e0 c0330c84
[2.746573] 3ec0: c08374e0 c0330bf0 c032f2f8 cf0222a8
cf198a10 c08374e0 c08265c8
[2.755185] 3ee0: cdbca7c0 c033015c c067d1e0 c08374e0 c08374e0
c0844600 cf052000
[2.763793] 3f00: c03311b8 c0776fb0 c0844600
cf052000
[2.772393] 3f20: c07421c4 c0008818 0001dd4e 0007
c076c7b0 07753841
[2.780998] 3f40: 9a64d806 9a64d806 6113
c0776fb0 0007 c0776f90
[2.789603] 3f60: c0844600 00af c0793ee8 c07421c4
c07428f8 0007 0007
[2.798217] 3f80: c07421c4 c0513f0c
[2.806827] 3fa0: c0513f14 c0013490
[2.815447] 3fc0:
[2.824058] 3fe0: 0013
eebff7f9 3a5f1b7e
[2.832668] [c02e2850] (_set_gpio_debounce+0x60/0x104) from
[c02e2924] (gpio_debounce+0x30/0x44)
[2.842272] [c02e2924] (gpio_debounce+0x30/0x44) from [c02e0258]
(gpio_set_debounce+0xc4/0xdc)
[2.851714] [c02e0258] (gpio_set_debounce+0xc4/0xdc) from
[c040ba10] (gpio_keys_setup_key+0x190/0x268)
[2.861871] [c040ba10] (gpio_keys_setup_key+0x190/0x268) from
[c040bc58] (gpio_keys_probe+0x170/0x274)
[2.872046] [c040bc58] (gpio_keys_probe+0x170/0x274) from
[c0331c90] (platform_drv_probe+0x18/0x1c)
[2.881940] [c0331c90] (platform_drv_probe+0x18/0x1c) from
[c033092c] (really_probe+0x60/0x1f4)
[2.891453] [c033092c] (really_probe+0x60/0x1f4) from [c0330bd8]
(driver_probe_device+0x30/0x48)
[2.901064] [c0330bd8] (driver_probe_device+0x30/0x48) from
[c0330c84] (__driver_attach+0x94/0x98)
[2.910858] [c0330c84] (__driver_attach+0x94/0x98) from
[c032f2f8] (bus_for_each_dev+0x64/0x88)
[2.920380] [c032f2f8] (bus_for_each_dev+0x64/0x88) from
[c033015c] (bus_add_driver+0xa0/0x240)
[2.929900] [c033015c] (bus_add_driver+0xa0/0x240) from
[c03311b8] (driver_register+0x78/0x144)
[2.939434] [c03311b8] (driver_register+0x78/0x144) from
[c0008818] (do_one_initcall+0x118/0x180)
[2.949160] [c0008818] (do_one_initcall+0x118/0x180) from
[c07428f8] (kernel_init_freeable+0xfc/0x1cc)
Re: [alsa-devel] channel swapping issue on OMAP3/TWL4030 is back
On 03/22/2013 05:35 PM, Russell King - ARM Linux wrote: On Fri, Mar 22, 2013 at 02:04:42PM +0100, Peter Ujfalusi wrote: Russell: can we remove the tasklet use from dma-omap and start the DMA right away in omap_dma_issue_pending()? This is the only way to prevent channel swap when starting audio. What I fear is that we may run up against having too many DMA channels tied up to the peripherals. I structured the driver in this way to allow us to move the physical DMA channel allocation to that tasklet when that becomes a problem. Not only that but I was hoping to lift some more of this code out of DMA engine drivers, so DMA engine drivers had even less code in them. Not sure what you mean by this. Move dmaengine core's issue_pending to a tasklet or is only OMAP internal restructuring? I guess we could keep the tasklet, but mark the audio DMA channels as pre-reserved and arrange for pre-reserved channels to avoid the tasklet, rather than throwing the tasklet out completely. Not sure if we really want to pre-reserve the DMA channels for audio: on OMAP3 we have 5 McBSP - 10 DMA channels on OMAP4 we have 4 McBSP, one McPDM, one DMIC and one McASP + we have the AESS/ABE - 8 + 2 + 1 + 1 + 8 (AESS/ABE). Do we really want to pre-allocate DMA channel for all of these? We could look omap_chan.cyclic which gives good indication that the channel is used for audio since only audio is using cyclic mode. I have a patch which removes the tasklet from omap-dma.c and it is working fine on my systems (OMAP3 Zoom2, BeagleBoard, OMAP4 PandBoard, OMAP4 Blaze). I can modify it to not remove the taskelt, but when the omap_chan.cyclic is true we would instead of starting the tasklet we just start the DMA right away. -- Péter -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 00/18] ARM: OMAP5: PM: Add MPUSS suspend and CPUidle support
On Monday 25 March 2013 05:57 PM, Sourav Poddar wrote:
Hi Santosh,
On Monday 25 March 2013 03:34 PM, Santosh Shilimkar wrote:
Kevin,
Here is the refreshed version(v2) of the OMAP5 PM suspport which was posted
earlier (March 1st 2013). Patch-set incorporates comments from Nishant
Menon (Thanks for review NM) and his acked-by tags. I would like to get this
queued for 3.10 merge window if you are ok with the series.
Series is built on top of my pull requests [1] [2] [3] sent to Tony and your
'for_3.10/pm/cleanup' branch. For testing, I have created a branch [4]
which put together all the needed dependencies, fixes which should make it
to 3.10 merge window.
Series adds OMAP5 MPUSS power management support for system wide suspend
and CPUidle. Its heavy re-use from OMAP4 and hence only ~400 odd lines are
needed to add OMAP5 PM support on top of existing OMAP4 PM support.
OMAP5 adds a mercury retention feature which is an enhancement of
existing retention feature to reduce the leakage. No change in
programming model except one time enabling of mercury retention
during init.
One more notable change in OMAP5 vs OMAP4 devices, CPUx power domains
support retention state which lets you hit MPUSS and Core retention with
very low latency C-states.
Tested on OMAP4430 SDP, OMAP4460 Panda, OMAP5430 SDP and OMAP5432 Panda
devices with suspend and CPUIdle. Rootfs is mounted over ramdisk since
the mmc and nfs based fs needs DMA engine patches. For suspend wakeup,
I used Sourav's couple of serial wakeup wip patches from the lists.
The following changes since commit 9981cde24de52e5bb9a7cd918d1e54de241f85c9:
Merge branch 'for_3.10/omap5_data_files' of
git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux into
for_3.10/omap5_pm (2013-03-25 12:29:34 +0530)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux.git
for_3.10/omap5_pm
for you to fetch changes up to 75bd846d3103da858a208fe07127151903d1f608:
ARM: OMAP5: PM: handle device instance for warm reset (2013-03-25
12:37:44 +0530)
Nishanth Menon (1):
ARM: OMAP5: PM: handle device instance for warm reset
Santosh Shilimkar (17):
ARM: OMAP4+: PM: Consolidate MPU subsystem PM code for re-use
ARM: OMAP5: PM: Update CPU context register offset
ARM: OMAP4+: PM: Consolidate and use OMAP4 PM code for OMAP5
ARM: OMAP5: PM: Set MPUSS-EMIF clock-domain static dependency
ARM: OMAP5: PM: Enables ES2 PM mode by default
ARM: OMAP5: PM: Enable Mercury retention mode on CPUx powerdomains
ARM: OMAP5: Add init_late() hook to enable pm initialization
ARM: OMAP5: PM: Add CPU power off in hotplug path
ARM: OMAP4+: PM: Restore CPU power state to ON with clockdomain force
wakeup method
ARM: OMAP5: PM: Add MPU Open Switch Retention support
ARM: OMAP5: PM: Add L2 memory power down support
ARM: OMAP4: CPUidle: Avoid double idle driver registration
ARM: OMAP: CPUidle: Unregister drivere on device registration failure
ARM: OMAP4: CPUidle: Make C-state description field more precise
ARM: OMAP4+: CPUidle: Consolidate idle driver for OMAP5 support
ARM: OMAP4+: CPUidle: Deprecate use of
omap4_mpuss_read_prev_context_state()
ARM: OMAP4+: CPUidle: Add OMAP5 idle driver support
arch/arm/mach-omap2/Kconfig|1 +
arch/arm/mach-omap2/Makefile | 12 +-
arch/arm/mach-omap2/board-generic.c|1 +
arch/arm/mach-omap2/common.h |8 +-
arch/arm/mach-omap2/cpuidle34xx.c |6 +-
.../{cpuidle44xx.c = cpuidle_omap4plus.c} | 151
---
arch/arm/mach-omap2/io.c |8 +
arch/arm/mach-omap2/omap-mpuss-lowpower.c | 155
+++-
arch/arm/mach-omap2/omap-secure.h |9 ++
arch/arm/mach-omap2/omap-smp.c | 12 +-
arch/arm/mach-omap2/omap-wakeupgen.c | 30 +++-
arch/arm/mach-omap2/omap-wakeupgen.h |1 +
arch/arm/mach-omap2/omap4-sar-layout.h |2 +
arch/arm/mach-omap2/{pm44xx.c = pm_omap4plus.c} | 90 ++--
arch/arm/mach-omap2/prminst44xx.c | 10 +-
.../mach-omap2/{sleep44xx.S = sleep_omap4plus.S} | 106 +
16 files changed, 512 insertions(+), 90 deletions(-)
rename arch/arm/mach-omap2/{cpuidle44xx.c = cpuidle_omap4plus.c} (58%)
rename arch/arm/mach-omap2/{pm44xx.c = pm_omap4plus.c} (74%)
rename arch/arm/mach-omap2/{sleep44xx.S = sleep_omap4plus.S} (77%)
Build tested [1] for omap2plus_defconfig.
For [2], where omap5_pm_branch[1] is merged, testing details are as follows:
* Boot tested on omap4430 sdp, omap5 evm.
* Wakeup from UART after suspend using dt was tested on omap4430sdp and
Re: [PATCH v2 00/18] ARM: OMAP5: PM: Add MPUSS suspend and CPUidle support
Hi Rajendra,
On Monday 25 March 2013 06:17 PM, Rajendra Nayak wrote:
On Monday 25 March 2013 05:57 PM, Sourav Poddar wrote:
Hi Santosh,
On Monday 25 March 2013 03:34 PM, Santosh Shilimkar wrote:
Kevin,
Here is the refreshed version(v2) of the OMAP5 PM suspport which was posted
earlier (March 1st 2013). Patch-set incorporates comments from Nishant
Menon (Thanks for review NM) and his acked-by tags. I would like to get this
queued for 3.10 merge window if you are ok with the series.
Series is built on top of my pull requests [1] [2] [3] sent to Tony and your
'for_3.10/pm/cleanup' branch. For testing, I have created a branch [4]
which put together all the needed dependencies, fixes which should make it
to 3.10 merge window.
Series adds OMAP5 MPUSS power management support for system wide suspend
and CPUidle. Its heavy re-use from OMAP4 and hence only ~400 odd lines are
needed to add OMAP5 PM support on top of existing OMAP4 PM support.
OMAP5 adds a mercury retention feature which is an enhancement of
existing retention feature to reduce the leakage. No change in
programming model except one time enabling of mercury retention
during init.
One more notable change in OMAP5 vs OMAP4 devices, CPUx power domains
support retention state which lets you hit MPUSS and Core retention with
very low latency C-states.
Tested on OMAP4430 SDP, OMAP4460 Panda, OMAP5430 SDP and OMAP5432 Panda
devices with suspend and CPUIdle. Rootfs is mounted over ramdisk since
the mmc and nfs based fs needs DMA engine patches. For suspend wakeup,
I used Sourav's couple of serial wakeup wip patches from the lists.
The following changes since commit 9981cde24de52e5bb9a7cd918d1e54de241f85c9:
Merge branch 'for_3.10/omap5_data_files' of
git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux into
for_3.10/omap5_pm (2013-03-25 12:29:34 +0530)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux.git
for_3.10/omap5_pm
for you to fetch changes up to 75bd846d3103da858a208fe07127151903d1f608:
ARM: OMAP5: PM: handle device instance for warm reset (2013-03-25 12:37:44
+0530)
Nishanth Menon (1):
ARM: OMAP5: PM: handle device instance for warm reset
Santosh Shilimkar (17):
ARM: OMAP4+: PM: Consolidate MPU subsystem PM code for re-use
ARM: OMAP5: PM: Update CPU context register offset
ARM: OMAP4+: PM: Consolidate and use OMAP4 PM code for OMAP5
ARM: OMAP5: PM: Set MPUSS-EMIF clock-domain static dependency
ARM: OMAP5: PM: Enables ES2 PM mode by default
ARM: OMAP5: PM: Enable Mercury retention mode on CPUx powerdomains
ARM: OMAP5: Add init_late() hook to enable pm initialization
ARM: OMAP5: PM: Add CPU power off in hotplug path
ARM: OMAP4+: PM: Restore CPU power state to ON with clockdomain force
wakeup method
ARM: OMAP5: PM: Add MPU Open Switch Retention support
ARM: OMAP5: PM: Add L2 memory power down support
ARM: OMAP4: CPUidle: Avoid double idle driver registration
ARM: OMAP: CPUidle: Unregister drivere on device registration failure
ARM: OMAP4: CPUidle: Make C-state description field more precise
ARM: OMAP4+: CPUidle: Consolidate idle driver for OMAP5 support
ARM: OMAP4+: CPUidle: Deprecate use of
omap4_mpuss_read_prev_context_state()
ARM: OMAP4+: CPUidle: Add OMAP5 idle driver support
arch/arm/mach-omap2/Kconfig|1 +
arch/arm/mach-omap2/Makefile | 12 +-
arch/arm/mach-omap2/board-generic.c|1 +
arch/arm/mach-omap2/common.h |8 +-
arch/arm/mach-omap2/cpuidle34xx.c |6 +-
.../{cpuidle44xx.c = cpuidle_omap4plus.c} | 151
---
arch/arm/mach-omap2/io.c |8 +
arch/arm/mach-omap2/omap-mpuss-lowpower.c | 155
+++-
arch/arm/mach-omap2/omap-secure.h |9 ++
arch/arm/mach-omap2/omap-smp.c | 12 +-
arch/arm/mach-omap2/omap-wakeupgen.c | 30 +++-
arch/arm/mach-omap2/omap-wakeupgen.h |1 +
arch/arm/mach-omap2/omap4-sar-layout.h |2 +
arch/arm/mach-omap2/{pm44xx.c = pm_omap4plus.c} | 90 ++--
arch/arm/mach-omap2/prminst44xx.c | 10 +-
.../mach-omap2/{sleep44xx.S = sleep_omap4plus.S} | 106 +
16 files changed, 512 insertions(+), 90 deletions(-)
rename arch/arm/mach-omap2/{cpuidle44xx.c = cpuidle_omap4plus.c} (58%)
rename arch/arm/mach-omap2/{pm44xx.c = pm_omap4plus.c} (74%)
rename arch/arm/mach-omap2/{sleep44xx.S = sleep_omap4plus.S} (77%)
Build tested [1] for omap2plus_defconfig.
For [2], where omap5_pm_branch[1] is merged, testing details are as follows:
* Boot tested on omap4430 sdp, omap5 evm.
* Wakeup from UART after suspend using
Re: 3.9.0-rc3: BUG: Bad page state in process
On 25/03/13 13:30, Mark Jackson wrote: On our custom AM335x cpu board, I have had several kernel crashes via my userspace program. snip And here's another similar oops ... [16565.691706] Unable to handle kernel NULL pointer dereference at virtual address [16565.700289] pgd = cd07c000 [16565.703149] [] *pgd= [16565.706909] Internal error: Oops: 5 [#1] ARM [16565.711390] CPU: 0Not tainted (3.9.0-rc4-00026-g58216a6 #148) [16565.717886] PC is at free_pages_and_swap_cache+0x48/0xbc [16565.723457] LR is at release_pages+0x1d0/0x20c [16565.728117] pc : [c00be4ac]lr : [c009d474]psr: 2013 [16565.728117] sp : cf707d70 ip : fp : cf56edac [16565.740153] r10: cd079388 r9 : c0c8bac0 r8 : [16565.745624] r7 : 0001 r6 : cd079380 r5 : 0320 r4 : 000e [16565.752463] r3 : 00080068 r2 : r1 : r0 : cf707d2c [16565.759308] Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user [16565.766784] Control: 10c5387d Table: 8d07c019 DAC: 0015 [16565.772802] Process ccrt (pid: 800, stack limit = 0xcf706238) [16565.778820] Stack: (0xcf707d70 to 0xcf708000) [16565.783389] 7d60: 000b b6bb6000 0001 cf707e08 [16565.791961] 7d80: cf707e08 b6c0 c00aeb70 cf644d38 cf640700 cf644d00 [16565.800531] 7da0: 8e4d63cd cf56eda8 b6d97000 b6d96fff c0c8ba60 fe49 [16565.809102] 7dc0: 09bdd609 cf640700 cf707e08 cf52d868 cf644d00 [16565.817675] 7de0: cf39c680 c00af4b4 cf2fd640 cf640498 cf644d00 cf707e08 cf2ffc80 [16565.826251] 7e00: cf2fd640 c00b56a8 cf644d00 0001 0080 0400 [16565.834826] 7e20: 0400 cd079000 cf2ffc80 cf2fd640 cf52d868 cf644d00 cf39c680 c03ffc08 [16565.843397] 7e40: 6013 cf644d5c cf644d00 cf644d00 cf706000 cf2ffc80 c00364b8 [16565.851968] 7e60: cf644d00 cf52d4c0 cf706000 c00ccb4c cf2f7340 cf2ffc80 cf2f73a4 cf707e90 [16565.860541] 7e80: cf2f7374 cf706000 0001 c010a624 cf2ffc80 0080 0003 [16565.869118] 7ea0: cf706000 cf2ffd80 cf6003c0 c0579ddc cf706000 c0109b08 0320 c0075190 [16565.877691] 7ec0: 0002 c00cd214 cf52d4c0 c0579dc0 [16565.886262] 7ee0: 0002 c0579dc0 cf2ffc80 fff8 c057a71c c0579ddc [16565.894834] 7f00: cf706000 c010a3e8 0320 c00cd200 0001 c00cd150 befff000 [16565.903406] 7f20: cf706000 0001 cf38e548 cf706000 0001 0001 cf38e548 cf2ffc80 [16565.911976] 7f40: bebc3dac bebc34a8 c00cd750 0001 c00cd3bc 0ff0 [16565.920549] 7f60: cf2fd698 cf2fd640 cf52d6e0 cd046000 bebc3dac bebc34a8 [16565.929124] 7f80: 000b c0013968 cf706000 0001f190 c00cda58 b6e0c198 [16565.937703] 7fa0: b6e07ee8 c00137c0 b6e0c198 b6dfcd52 bebc34a8 bebc3dac b6e0c190 [16565.946280] 7fc0: b6e0c198 b6e07ee8 000b 42b0 0001394e bebc3900 0001f190 [16565.954852] 7fe0: b6e07f34 bebc3488 b6dfac38 b6dc9e88 0010 b6dfcd52 [16565.963451] [c00be4ac] (free_pages_and_swap_cache+0x48/0xbc) from [c00aeb70] (unmap_single_vma+0x3b0/0x5b8) [16565.974035] [c00aeb70] (unmap_single_vma+0x3b0/0x5b8) from [c00af4b4] (unmap_vmas+0x54/0x68) [16565.983253] [c00af4b4] (unmap_vmas+0x54/0x68) from [c00b56a8] (exit_mmap+0xd0/0x1f4) [16565.991746] [c00b56a8] (exit_mmap+0xd0/0x1f4) from [c00364b8] (mmput+0x34/0xb8) [16565.999783] [c00364b8] (mmput+0x34/0xb8) from [c00ccb4c] (flush_old_exec+0x240/0x4c8) [16566.008365] [c00ccb4c] (flush_old_exec+0x240/0x4c8) from [c010a624] (load_elf_binary+0x23c/0x11b0) [16566.018131] [c010a624] (load_elf_binary+0x23c/0x11b0) from [c00cd200] (search_binary_handler+0xe4/0x1f0) [16566.028437] [c00cd200] (search_binary_handler+0xe4/0x1f0) from [c00cd750] (do_execve+0x444/0x4fc) [16566.038107] [c00cd750] (do_execve+0x444/0x4fc) from [c00cda58] (sys_execve+0x30/0x44) [16566.046697] [c00cda58] (sys_execve+0x30/0x44) from [c00137c0] (ret_fast_syscall+0x0/0x3c) [16566.055635] Code: e2877001 e1540007 da15 e49a8004 (e5983000) [16566.062129] ---[ end trace d58a14e8bd6d8269 ]--- -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 3.9.0-rc3: BUG: Bad page state in process
On 25/03/13 13:59, Mark Jackson wrote: On 25/03/13 13:30, Mark Jackson wrote: On our custom AM335x cpu board, I have had several kernel crashes via my userspace program. snip And here's another similar oops ... snip Another big blowout ... [16910.346870] BUG: Bad page state in process ccrt pfn:8f94e [16910.352656] page:c0cb49c0 count:0 mapcount:1 mapping: (null) index:0xb6a21 [16910.360028] page flags: 0x80008(uptodate|swapbacked) [16910.365332] [c00190c0] (unwind_backtrace+0x0/0xf8) from [c0097dfc] (bad_page+0xa8/0x108) [16910.374211] [c0097dfc] (bad_page+0xa8/0x108) from [c0097f58] (free_pages_prepare+0xfc/0x108) [16910.383451] [c0097f58] (free_pages_prepare+0xfc/0x108) from [c009881c] (free_hot_cold_page+0x18/0x144) [16910.393602] [c009881c] (free_hot_cold_page+0x18/0x144) from [c0098b08] (free_hot_cold_page_list+0x2c/0x48) [16910.404112] [c0098b08] (free_hot_cold_page_list+0x2c/0x48) from [c009d474] (release_pages+0x1d0/0x20c) [16910.414264] [c009d474] (release_pages+0x1d0/0x20c) from [c00be510] (free_pages_and_swap_cache+0xac/0xbc) [16910.424608] [c00be510] (free_pages_and_swap_cache+0xac/0xbc) from [c00b56e8] (exit_mmap+0x110/0x1f4) [16910.434579] [c00b56e8] (exit_mmap+0x110/0x1f4) from [c00364b8] (mmput+0x34/0xb8) [16910.442713] [c00364b8] (mmput+0x34/0xb8) from [c00ccb4c] (flush_old_exec+0x240/0x4c8) [16910.451321] [c00ccb4c] (flush_old_exec+0x240/0x4c8) from [c010a624] (load_elf_binary+0x23c/0x11b0) [16910.461103] [c010a624] (load_elf_binary+0x23c/0x11b0) from [c00cd200] (search_binary_handler+0xe4/0x1f0) [16910.471429] [c00cd200] (search_binary_handler+0xe4/0x1f0) from [c00cd750] (do_execve+0x444/0x4fc) [16910.481121] [c00cd750] (do_execve+0x444/0x4fc) from [c00cda58] (sys_execve+0x30/0x44) [16910.489737] [c00cda58] (sys_execve+0x30/0x44) from [c00137c0] (ret_fast_syscall+0x0/0x3c) [16910.498694] BUG: Bad page state in process ccrt pfn:8f94c [16910.504484] page:c0cb4980 count:0 mapcount:1 mapping: (null) index:0xb6a1f [16910.511779] page flags: 0x80008(uptodate|swapbacked) [16910.517033] [c00190c0] (unwind_backtrace+0x0/0xf8) from [c0097dfc] (bad_page+0xa8/0x108) [16910.525906] [c0097dfc] (bad_page+0xa8/0x108) from [c0097f58] (free_pages_prepare+0xfc/0x108) [16910.535144] [c0097f58] (free_pages_prepare+0xfc/0x108) from [c009881c] (free_hot_cold_page+0x18/0x144) [16910.545290] [c009881c] (free_hot_cold_page+0x18/0x144) from [c0098b08] (free_hot_cold_page_list+0x2c/0x48) [16910.555799] [c0098b08] (free_hot_cold_page_list+0x2c/0x48) from [c009d474] (release_pages+0x1d0/0x20c) [16910.565945] [c009d474] (release_pages+0x1d0/0x20c) from [c00be510] (free_pages_and_swap_cache+0xac/0xbc) [16910.576271] [c00be510] (free_pages_and_swap_cache+0xac/0xbc) from [c00b56e8] (exit_mmap+0x110/0x1f4) [16910.586235] [c00b56e8] (exit_mmap+0x110/0x1f4) from [c00364b8] (mmput+0x34/0xb8) [16910.594375] [c00364b8] (mmput+0x34/0xb8) from [c00ccb4c] (flush_old_exec+0x240/0x4c8) [16910.602952] [c00ccb4c] (flush_old_exec+0x240/0x4c8) from [c010a624] (load_elf_binary+0x23c/0x11b0) [16910.612734] [c010a624] (load_elf_binary+0x23c/0x11b0) from [c00cd200] (search_binary_handler+0xe4/0x1f0) [16910.623062] [c00cd200] (search_binary_handler+0xe4/0x1f0) from [c00cd750] (do_execve+0x444/0x4fc) [16910.632752] [c00cd750] (do_execve+0x444/0x4fc) from [c00cda58] (sys_execve+0x30/0x44) [16910.641348] [c00cda58] (sys_execve+0x30/0x44) from [c00137c0] (ret_fast_syscall+0x0/0x3c) [16910.759432] BUG: Bad page state in process ccrt pfn:8f94e [16910.765348] page:c0cb49c0 count:1 mapcount:1 mapping: (null) index:0x2 [16910.772283] page flags: 0x0() [16910.775475] [c00190c0] (unwind_backtrace+0x0/0xf8) from [c0097dfc] (bad_page+0xa8/0x108) [16910.784360] [c0097dfc] (bad_page+0xa8/0x108) from [c0098fa0] (get_page_from_freelist+0x47c/0x57c) [16910.794056] [c0098fa0] (get_page_from_freelist+0x47c/0x57c) from [c0099320] (__alloc_pages_nodemask+0xd8/0x7bc) [16910.805030] [c0099320] (__alloc_pages_nodemask+0xd8/0x7bc) from [c00ae154] (do_wp_page+0xbc/0x728) [16910.814813] [c00ae154] (do_wp_page+0xbc/0x728) from [c00b0624] (handle_pte_fault+0x23c/0x6c4) [16910.824141] [c00b0624] (handle_pte_fault+0x23c/0x6c4) from [c00b0b3c] (handle_mm_fault+0x90/0xc0) [16910.833831] [c00b0b3c] (handle_mm_fault+0x90/0xc0) from [c001da08] (do_page_fault+0x220/0x38c) [16910.843251] [c001da08] (do_page_fault+0x220/0x38c) from [c0008498] (do_DataAbort+0x30/0x9c) [16910.852390] [c0008498] (do_DataAbort+0x30/0x9c) from [c0013534] (__dabt_usr+0x34/0x40) [16910.861068] Exception stack(0xcd057fb0 to 0xcd057ff8) [16910.866382] 7fa0: bedfe4c8 0002 0094 [16910.874974] 7fc0: b6eb1198 b6eacee8 b6ea1d52 42b0 0001394e bedfe900 0001f190 [16910.883568] 7fe0: b6eacf34 bedfe490 b6e9fc18 b6e9fc1c 0010 [16910.890504] BUG: Bad page state in process ccrt pfn:8f94c [16910.896271] page:c0cb4980 count:1 mapcount:1 mapping: (null) index:0x2 [16910.903217] page
Re: 3.9.0-rc3: BUG: Bad page state in process
2013/3/25 Mark Jackson mpfj-l...@mimc.co.uk: On 25/03/13 13:59, Mark Jackson wrote: On 25/03/13 13:30, Mark Jackson wrote: On our custom AM335x cpu board, I have had several kernel crashes via my userspace program. Is the problem still present when booting with nohlt ? snip And here's another similar oops ... snip Another big blowout ... [16910.346870] BUG: Bad page state in process ccrt pfn:8f94e [16910.352656] page:c0cb49c0 count:0 mapcount:1 mapping: (null) index:0xb6a21 [16910.360028] page flags: 0x80008(uptodate|swapbacked) [16910.365332] [c00190c0] (unwind_backtrace+0x0/0xf8) from [c0097dfc] (bad_page+0xa8/0x108) [16910.374211] [c0097dfc] (bad_page+0xa8/0x108) from [c0097f58] (free_pages_prepare+0xfc/0x108) [16910.383451] [c0097f58] (free_pages_prepare+0xfc/0x108) from [c009881c] (free_hot_cold_page+0x18/0x144) [16910.393602] [c009881c] (free_hot_cold_page+0x18/0x144) from [c0098b08] (free_hot_cold_page_list+0x2c/0x48) [16910.404112] [c0098b08] (free_hot_cold_page_list+0x2c/0x48) from [c009d474] (release_pages+0x1d0/0x20c) [16910.414264] [c009d474] (release_pages+0x1d0/0x20c) from [c00be510] (free_pages_and_swap_cache+0xac/0xbc) [16910.424608] [c00be510] (free_pages_and_swap_cache+0xac/0xbc) from [c00b56e8] (exit_mmap+0x110/0x1f4) [16910.434579] [c00b56e8] (exit_mmap+0x110/0x1f4) from [c00364b8] (mmput+0x34/0xb8) [16910.442713] [c00364b8] (mmput+0x34/0xb8) from [c00ccb4c] (flush_old_exec+0x240/0x4c8) [16910.451321] [c00ccb4c] (flush_old_exec+0x240/0x4c8) from [c010a624] (load_elf_binary+0x23c/0x11b0) [16910.461103] [c010a624] (load_elf_binary+0x23c/0x11b0) from [c00cd200] (search_binary_handler+0xe4/0x1f0) [16910.471429] [c00cd200] (search_binary_handler+0xe4/0x1f0) from [c00cd750] (do_execve+0x444/0x4fc) [16910.481121] [c00cd750] (do_execve+0x444/0x4fc) from [c00cda58] (sys_execve+0x30/0x44) [16910.489737] [c00cda58] (sys_execve+0x30/0x44) from [c00137c0] (ret_fast_syscall+0x0/0x3c) [16910.498694] BUG: Bad page state in process ccrt pfn:8f94c [16910.504484] page:c0cb4980 count:0 mapcount:1 mapping: (null) index:0xb6a1f [16910.511779] page flags: 0x80008(uptodate|swapbacked) [16910.517033] [c00190c0] (unwind_backtrace+0x0/0xf8) from [c0097dfc] (bad_page+0xa8/0x108) [16910.525906] [c0097dfc] (bad_page+0xa8/0x108) from [c0097f58] (free_pages_prepare+0xfc/0x108) [16910.535144] [c0097f58] (free_pages_prepare+0xfc/0x108) from [c009881c] (free_hot_cold_page+0x18/0x144) [16910.545290] [c009881c] (free_hot_cold_page+0x18/0x144) from [c0098b08] (free_hot_cold_page_list+0x2c/0x48) [16910.555799] [c0098b08] (free_hot_cold_page_list+0x2c/0x48) from [c009d474] (release_pages+0x1d0/0x20c) [16910.565945] [c009d474] (release_pages+0x1d0/0x20c) from [c00be510] (free_pages_and_swap_cache+0xac/0xbc) [16910.576271] [c00be510] (free_pages_and_swap_cache+0xac/0xbc) from [c00b56e8] (exit_mmap+0x110/0x1f4) [16910.586235] [c00b56e8] (exit_mmap+0x110/0x1f4) from [c00364b8] (mmput+0x34/0xb8) [16910.594375] [c00364b8] (mmput+0x34/0xb8) from [c00ccb4c] (flush_old_exec+0x240/0x4c8) [16910.602952] [c00ccb4c] (flush_old_exec+0x240/0x4c8) from [c010a624] (load_elf_binary+0x23c/0x11b0) [16910.612734] [c010a624] (load_elf_binary+0x23c/0x11b0) from [c00cd200] (search_binary_handler+0xe4/0x1f0) [16910.623062] [c00cd200] (search_binary_handler+0xe4/0x1f0) from [c00cd750] (do_execve+0x444/0x4fc) [16910.632752] [c00cd750] (do_execve+0x444/0x4fc) from [c00cda58] (sys_execve+0x30/0x44) [16910.641348] [c00cda58] (sys_execve+0x30/0x44) from [c00137c0] (ret_fast_syscall+0x0/0x3c) [16910.759432] BUG: Bad page state in process ccrt pfn:8f94e [16910.765348] page:c0cb49c0 count:1 mapcount:1 mapping: (null) index:0x2 [16910.772283] page flags: 0x0() [16910.775475] [c00190c0] (unwind_backtrace+0x0/0xf8) from [c0097dfc] (bad_page+0xa8/0x108) [16910.784360] [c0097dfc] (bad_page+0xa8/0x108) from [c0098fa0] (get_page_from_freelist+0x47c/0x57c) [16910.794056] [c0098fa0] (get_page_from_freelist+0x47c/0x57c) from [c0099320] (__alloc_pages_nodemask+0xd8/0x7bc) [16910.805030] [c0099320] (__alloc_pages_nodemask+0xd8/0x7bc) from [c00ae154] (do_wp_page+0xbc/0x728) [16910.814813] [c00ae154] (do_wp_page+0xbc/0x728) from [c00b0624] (handle_pte_fault+0x23c/0x6c4) [16910.824141] [c00b0624] (handle_pte_fault+0x23c/0x6c4) from [c00b0b3c] (handle_mm_fault+0x90/0xc0) [16910.833831] [c00b0b3c] (handle_mm_fault+0x90/0xc0) from [c001da08] (do_page_fault+0x220/0x38c) [16910.843251] [c001da08] (do_page_fault+0x220/0x38c) from [c0008498] (do_DataAbort+0x30/0x9c) [16910.852390] [c0008498] (do_DataAbort+0x30/0x9c) from [c0013534] (__dabt_usr+0x34/0x40) [16910.861068] Exception stack(0xcd057fb0 to 0xcd057ff8) [16910.866382] 7fa0: bedfe4c8 0002 0094 [16910.874974] 7fc0: b6eb1198 b6eacee8 b6ea1d52 42b0 0001394e bedfe900 0001f190 [16910.883568] 7fe0: b6eacf34 bedfe490
Re: 3.9.0-rc3: BUG: Bad page state in process
On 25/03/13 15:06, jean-philippe francois wrote: 2013/3/25 Mark Jackson mpfj-l...@mimc.co.uk: On 25/03/13 13:59, Mark Jackson wrote: On 25/03/13 13:30, Mark Jackson wrote: On our custom AM335x cpu board, I have had several kernel crashes via my userspace program. Is the problem still present when booting with nohlt ? Yes ... [0.00] Booting Linux on physical CPU 0x0 [0.00] Linux version 3.9.0-rc4-00026-g58216a6 (mpfj@mpfj-nanobone) (gcc version 4.5.4 (Buildroot 2012.11) ) #148 Mon Mar 25 09:19:57 GMT 2013 [0.00] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c53c7d [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache [0.00] Machine: Generic AM33XX (Flattened Device Tree), model: Newflow AM335x NanoBone [0.00] Memory policy: ECC disabled, Data cache writeback [0.00] CPU: All CPU(s) started in SVC mode. [0.00] AM335X ES1.0 (neon ) [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 64768 [0.00] Kernel command line: root=/dev/nfs nfsroot=10.0.0.100:/tftpboot/nanobone/rootfs rw ip=10.0.101.111::10.0.0.100:::eth0:off console=ttyO0,115200 no-hlt ... # ./ccrt -f target/ccrt.ccc 4 1 Setting up signal handler Loading XML XML mem usage = 1101660 in 55080 elements Assessing resources Creating langauge string store Creating variable store [ 13.323738] BUG: Bad page state in process ccrt pfn:8fba4 [ 13.329525] page:c0cb9480 count:0 mapcount:1 mapping: (null) index:0x49 [ 13.336623] page flags: 0x80008(uptodate|swapbacked) [ 13.341908] [c00190c0] (unwind_backtrace+0x0/0xf8) from [c0097dfc] (bad_page+0xa8/0x108) [ 13.350794] [c0097dfc] (bad_page+0xa8/0x108) from [c0097f58] (free_pages_prepare+0xfc/0x108) [ 13.360038] [c0097f58] (free_pages_prepare+0xfc/0x108) from [c009881c] (free_hot_cold_page+0x18/0x144) [ 13.370184] [c009881c] (free_hot_cold_page+0x18/0x144) from [c0098b08] (free_hot_cold_page_list+0x2c/0x48) [ 13.380699] [c0098b08] (free_hot_cold_page_list+0x2c/0x48) from [c009d474] (release_pages+0x1d0/0x20c) [ 13.390856] [c009d474] (release_pages+0x1d0/0x20c) from [c00be510] (free_pages_and_swap_cache+0xac/0xbc) [ 13.401202] [c00be510] (free_pages_and_swap_cache+0xac/0xbc) from [c00b56e8] (exit_mmap+0x110/0x1f4) [ 13.411167] [c00b56e8] (exit_mmap+0x110/0x1f4) from [c00364b8] (mmput+0x34/0xb8) [ 13.419317] [c00364b8] (mmput+0x34/0xb8) from [c00ccb4c] (flush_old_exec+0x240/0x4c8) [ 13.427918] [c00ccb4c] (flush_old_exec+0x240/0x4c8) from [c010a624] (load_elf_binary+0x23c/0x11b0) [ 13.437700] [c010a624] (load_elf_binary+0x23c/0x11b0) from [c00cd200] (search_binary_handler+0xe4/0x1f0) [ 13.448029] [c00cd200] (search_binary_handler+0xe4/0x1f0) from [c00cd750] (do_execve+0x444/0x4fc) [ 13.457722] [c00cd750] (do_execve+0x444/0x4fc) from [c00cda58] (sys_execve+0x30/0x44) [ 13.466332] [c00cda58] (sys_execve+0x30/0x44) from [c00137c0] (ret_fast_syscall+0x0/0x3c) [ 13.475303] BUG: Bad page state in process ccrt pfn:8fbf2 [ 13.481055] page:c0cb9e40 count:0 mapcount:1 mapping: (null) index:0x97 [ 13.488100] page flags: 0x80008(uptodate|swapbacked) [ 13.493356] [c00190c0] (unwind_backtrace+0x0/0xf8) from [c0097dfc] (bad_page+0xa8/0x108) [ 13.502207] [c0097dfc] (bad_page+0xa8/0x108) from [c0097f58] (free_pages_prepare+0xfc/0x108) [ 13.511443] [c0097f58] (free_pages_prepare+0xfc/0x108) from [c009881c] (free_hot_cold_page+0x18/0x144) [ 13.521610] [c009881c] (free_hot_cold_page+0x18/0x144) from [c0098b08] (free_hot_cold_page_list+0x2c/0x48) [ 13.532119] [c0098b08] (free_hot_cold_page_list+0x2c/0x48) from [c009d474] (release_pages+0x1d0/0x20c) [ 13.542265] [c009d474] (release_pages+0x1d0/0x20c) from [c00be510] (free_pages_and_swap_cache+0xac/0xbc) [ 13.552595] [c00be510] (free_pages_and_swap_cache+0xac/0xbc) from [c00b56e8] (exit_mmap+0x110/0x1f4) [ 13.562554] [c00b56e8] (exit_mmap+0x110/0x1f4) from [c00364b8] (mmput+0x34/0xb8) [ 13.570693] [c00364b8] (mmput+0x34/0xb8) from [c00ccb4c] (flush_old_exec+0x240/0x4c8) [ 13.579288] [c00ccb4c] (flush_old_exec+0x240/0x4c8) from [c010a624] (load_elf_binary+0x23c/0x11b0) [ 13.589070] [c010a624] (load_elf_binary+0x23c/0x11b0) from [c00cd200] (search_binary_handler+0xe4/0x1f0) [ 13.599395] [c00cd200] (search_binary_handler+0xe4/0x1f0) from [c00cd750] (do_execve+0x444/0x4fc) [ 13.609086] [c00cd750] (do_execve+0x444/0x4fc) from [c00cda58] (sys_execve+0x30/0x44) [ 13.617682] [c00cda58] (sys_execve+0x30/0x44) from [c00137c0] (ret_fast_syscall+0x0/0x3c) [ 13.736537] BUG: Bad page state in process ccrt pfn:8fba4 [ 13.742321] page:c0cb9480 count:1 mapcount:1 mapping: (null) index:0x2 [ 13.749332] page flags: 0x0() [ 13.752506] [c00190c0] (unwind_backtrace+0x0/0xf8) from [c0097dfc] (bad_page+0xa8/0x108) [ 13.761390] [c0097dfc] (bad_page+0xa8/0x108) from [c0098fa0] (get_page_from_freelist+0x47c/0x57c) [ 13.771086] [c0098fa0]
[PATCH] ASoC: omap: Call omap_mcbsp_set_threshold() from mcbsp hw_params
The omap PCM driver provides a set_threshold callback which gets called by the
PCM driver when either playback or capture is started. The only DAI driver which
sets this callback is the mcbsp driver. This patch removes the callback from the
PCM driver and moves the invocation of the omap_mcbsp_set_threshold() function
to the mcbsp hw_params callback since this is the only place where the threshold
size can change. Doing so allows us to use the default dmaengine PCM trigger
callback in the omap PCM driver.
Signed-off-by: Lars-Peter Clausen l...@metafoo.de
---
Only compile tested, but I don't see why it should not work
Signed-off-by: Lars-Peter Clausen l...@metafoo.de
---
sound/soc/omap/omap-mcbsp.c | 12 +---
sound/soc/omap/omap-pcm.c | 33 +
sound/soc/omap/omap-pcm.h | 1 -
3 files changed, 6 insertions(+), 40 deletions(-)
diff --git a/sound/soc/omap/omap-mcbsp.c b/sound/soc/omap/omap-mcbsp.c
index 8d2defd..406fc87 100644
--- a/sound/soc/omap/omap-mcbsp.c
+++ b/sound/soc/omap/omap-mcbsp.c
@@ -62,24 +62,22 @@ enum {
* Stream DMA parameters. DMA request line and port address are set runtime
* since they are different between OMAP1 and later OMAPs
*/
-static void omap_mcbsp_set_threshold(struct snd_pcm_substream *substream)
+static void omap_mcbsp_set_threshold(struct snd_pcm_substream *substream,
+ unsigned int packet_size)
{
struct snd_soc_pcm_runtime *rtd = substream-private_data;
struct snd_soc_dai *cpu_dai = rtd-cpu_dai;
struct omap_mcbsp *mcbsp = snd_soc_dai_get_drvdata(cpu_dai);
- struct omap_pcm_dma_data *dma_data;
int words;
- dma_data = snd_soc_dai_get_dma_data(rtd-cpu_dai, substream);
-
/*
* Configure McBSP threshold based on either:
* packet_size, when the sDMA is in packet mode, or based on the
* period size in THRESHOLD mode, otherwise use McBSP threshold = 1
* for mono streams.
*/
- if (dma_data-packet_size)
- words = dma_data-packet_size;
+ if (packet_size)
+ words = packet_size;
else
words = 1;
@@ -245,7 +243,6 @@ static int omap_mcbsp_dai_hw_params(struct
snd_pcm_substream *substream,
return -EINVAL;
}
if (mcbsp-pdata-buffer_size) {
- dma_data-set_threshold = omap_mcbsp_set_threshold;
if (mcbsp-dma_op_mode == MCBSP_DMA_MODE_THRESHOLD) {
int period_words, max_thrsh;
int divider = 0;
@@ -276,6 +273,7 @@ static int omap_mcbsp_dai_hw_params(struct
snd_pcm_substream *substream,
/* Use packet mode for non mono streams */
pkt_size = channels;
}
+ omap_mcbsp_set_threshold(substream, pkt_size);
}
dma_data-packet_size = pkt_size;
diff --git a/sound/soc/omap/omap-pcm.c b/sound/soc/omap/omap-pcm.c
index c722c2e..1626fb7 100644
--- a/sound/soc/omap/omap-pcm.c
+++ b/sound/soc/omap/omap-pcm.c
@@ -129,37 +129,6 @@ static int omap_pcm_hw_free(struct snd_pcm_substream
*substream)
return 0;
}
-static int omap_pcm_trigger(struct snd_pcm_substream *substream, int cmd)
-{
- struct snd_soc_pcm_runtime *rtd = substream-private_data;
- struct omap_pcm_dma_data *dma_data;
- int ret = 0;
-
- dma_data = snd_soc_dai_get_dma_data(rtd-cpu_dai, substream);
-
- switch (cmd) {
- case SNDRV_PCM_TRIGGER_START:
- case SNDRV_PCM_TRIGGER_RESUME:
- case SNDRV_PCM_TRIGGER_PAUSE_RELEASE:
- /* Configure McBSP internal buffer usage */
- if (dma_data-set_threshold)
- dma_data-set_threshold(substream);
- break;
-
- case SNDRV_PCM_TRIGGER_STOP:
- case SNDRV_PCM_TRIGGER_SUSPEND:
- case SNDRV_PCM_TRIGGER_PAUSE_PUSH:
- break;
- default:
- ret = -EINVAL;
- }
-
- if (ret == 0)
- ret = snd_dmaengine_pcm_trigger(substream, cmd);
-
- return ret;
-}
-
static snd_pcm_uframes_t omap_pcm_pointer(struct snd_pcm_substream *substream)
{
snd_pcm_uframes_t offset;
@@ -208,7 +177,7 @@ static struct snd_pcm_ops omap_pcm_ops = {
.ioctl = snd_pcm_lib_ioctl,
.hw_params = omap_pcm_hw_params,
.hw_free= omap_pcm_hw_free,
- .trigger= omap_pcm_trigger,
+ .trigger= snd_dmaengine_pcm_trigger,
.pointer= omap_pcm_pointer,
.mmap = omap_pcm_mmap,
};
diff --git a/sound/soc/omap/omap-pcm.h b/sound/soc/omap/omap-pcm.h
index cabe74c..39e6e45 100644
--- a/sound/soc/omap/omap-pcm.h
+++ b/sound/soc/omap/omap-pcm.h
@@ -31,7 +31,6 @@ struct omap_pcm_dma_data {
char*name; /* stream identifier */
int dma_req;/* DMA request line */
unsigned long port_addr;
Re: [alsa-devel] channel swapping issue on OMAP3/TWL4030 is back
On Mon, Mar 25, 2013 at 01:39:29PM +0100, Peter Ujfalusi wrote: On 03/22/2013 05:35 PM, Russell King - ARM Linux wrote: On Fri, Mar 22, 2013 at 02:04:42PM +0100, Peter Ujfalusi wrote: Russell: can we remove the tasklet use from dma-omap and start the DMA right away in omap_dma_issue_pending()? This is the only way to prevent channel swap when starting audio. What I fear is that we may run up against having too many DMA channels tied up to the peripherals. I structured the driver in this way to allow us to move the physical DMA channel allocation to that tasklet when that becomes a problem. Not only that but I was hoping to lift some more of this code out of DMA engine drivers, so DMA engine drivers had even less code in them. Not sure what you mean by this. Move dmaengine core's issue_pending to a tasklet or is only OMAP internal restructuring? There isn't any core issue_pending code. DMA engine is nothing much beyond a collection of drivers sort-of implementing a common API. Very little code is shared between drivers. What I'm talking about is having a physical channel scheduler in place across DMA engines which have more virtual channels than physical channels. Some DMA engine implementations sort of do this already (eg, AMBA PL08x stuff) but again, every driver implements this kind of thing by themselves. I guess we could keep the tasklet, but mark the audio DMA channels as pre-reserved and arrange for pre-reserved channels to avoid the tasklet, rather than throwing the tasklet out completely. Not sure if we really want to pre-reserve the DMA channels for audio: on OMAP3 we have 5 McBSP - 10 DMA channels on OMAP4 we have 4 McBSP, one McPDM, one DMIC and one McASP + we have the AESS/ABE - 8 + 2 + 1 + 1 + 8 (AESS/ABE). Do we really want to pre-allocate DMA channel for all of these? Well, at the moment we are effectively pre-allocating a physical channel for every virtual channel - as each virtual channel gets allocated. So, the physical channels are currently being permanently tied up. With a scheduling core, we need some way to dynamically reallocate physical channels depending on the workload presented on the virtual channels. However, as we're still having to deal with the OMAP private DMA API, we can only change physical channels from task (or tasklet) context. So, the only way to have audio channels in a condition where they can be startable immediately in issue_pending is to avoid the tasklet, and the only way to avoid that tasklet (where that tasklet eventually becomes the channel scheduler) is to have pre-allocated the physical channel. I have a patch which removes the tasklet from omap-dma.c and it is working fine on my systems (OMAP3 Zoom2, BeagleBoard, OMAP4 PandBoard, OMAP4 Blaze). I'm sure you have, but that breaks the future direction of the driver to dynamically allocate the physical channels. Had TI not effectively terminated my contract, I might be further forward with this. As things are, lack of contract and such like, all the OMAP work I was doing got shelved around Christmas time. If you stop paying people, they generally stop doing useful work for you... -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: convert arm/arm64 arch timer to use CLKSRC_OF init
On Thu, Mar 21, 2013 at 11:06:47AM +, Mark Rutland wrote: On TC2 this series leads to using the vexpress 24MHz clock as the sched clock in preference to the architected timer: Architected local timer running at 24.00MHz (virt). Switching to timer-based delay loop Registered arch_counter_get_cntvct+0x0/0x14 as sched_clock source sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every 178956ms Registered versatile_read_sched_clock+0x0/0x28 as sched_clock source As they both have the same frequency, neither overrides the other, and whichever gets registered last is used as the sched_clock. As accesses to the architected timer are going to have a much lower overhead, this isn't very nice (and it could be better to use it even if it had a lower frequency). I'll remind people that sched_clock() is supposed to be functional at the point in the boot sequence where the call to sched_init() is called. That is after setup_arch() and *before* time_init() is called. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 09/12] staging: ti-soc-thermal: fix several kernel-doc warnings and error
On Tue, Mar 19, 2013 at 10:54:25AM -0400, Eduardo Valentin wrote: This patch updates the documentation to remove all warnings and errors reported by scripts/kernel-doc. Most are missing arguments due to wrong format. Cc: Nishanth Menon n...@ti.com Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com In the future, don't put empty lines between the Cc: and signed-off-by: lines please, I had to hand-edit all of these to fix that... greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OK to use commit 71856843 as base for further omap clean up?
Hi Russell, On 03/19/2013 12:59 PM, Tony Lindgren wrote: Hi Russell, Can we use your commit 71856843 (ARM: OMAP: use consistent error checking) as an immutable base for further omap dmtimer and gpmc work? I saw that you updated your clean-up branch. Ok to use the below commit [1] as a base for some v3.10 updates? Cheers Jon [1] http://ftp.arm.linux.org.uk/git/gitweb.cgi?p=linux-arm.git;a=commit;h=71856843fb1d8ee455a4c1a60696c74afa4809e5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: convert arm/arm64 arch timer to use CLKSRC_OF init
On 03/25/2013 12:26 PM, Russell King - ARM Linux wrote: On Thu, Mar 21, 2013 at 11:06:47AM +, Mark Rutland wrote: On TC2 this series leads to using the vexpress 24MHz clock as the sched clock in preference to the architected timer: Architected local timer running at 24.00MHz (virt). Switching to timer-based delay loop Registered arch_counter_get_cntvct+0x0/0x14 as sched_clock source sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every 178956ms Registered versatile_read_sched_clock+0x0/0x28 as sched_clock source As they both have the same frequency, neither overrides the other, and whichever gets registered last is used as the sched_clock. As accesses to the architected timer are going to have a much lower overhead, this isn't very nice (and it could be better to use it even if it had a lower frequency). I'll remind people that sched_clock() is supposed to be functional at the point in the boot sequence where the call to sched_init() is called. That is after setup_arch() and *before* time_init() is called. I count integrator-cp, realview, versatile and non-DT VExpress that do this (not surprisingly) and 25 platforms or timer implementations plus arm64 that do sched_clock setup in time_init. What's broken by not moving these earlier? We could probably fix arch timers relatively easily, but supporting the numerous memory-mapped timers will be harder. Most timers are also dependent on the clocks being initialized. That's really an orthogonal issue to what this patch series solves. This series is about selecting the best sched_clock when multiple timers are present. Perhaps one that is setup in init_early should be preferred over one setup in init_time. I'm not sure how to detect that. Rob -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] gpio/omap: implement irq_enable/disable using mask/unmask.
Hi,
On Thu, Dec 20, 2012 at 10:16:56AM -0600, Jon Hunter wrote:
On 12/19/2012 11:59 PM, Santosh Shilimkar wrote:
On Monday 17 December 2012 02:57 PM, Andreas Fenkart wrote:
Please add some changelog here too.
::
In pm suspend the omap_hsmmc driver can't detect SDIO IRQs. This
is worked around by reconfiguring the SDIO IRQ pin (dat1) as a
GPIO before entering suspend and back upon resume. This requires
low overhead functions for enable/disable of GPIO IRQs.
Signed-off-by: Andreas Fenkart andreas.fenk...@streamunlimited.com
---
Patch seems straight forward thought will be interesting where you found
the need of it.
The only item that I was thinking of if the behaviour of mask/unmask
should be different from enable/disable?
When a gpio interrupt is masked, the gpio event will still be latched in
the interrupt status register so when you unmask it later you may get an
interrupt straight away. However, if the interrupt is disabled then gpio
events occurring will not be latched/stored.
Thanks for clarification.
The HW seems to support this, see Fig 25-3 in the manual.
https://www.google.com/search?q=spruh73c
This problem though, applies only to edge triggered irqs.
In the case of level triggered the mask/unmask implementation
clears irqs upon resume. This is safe, because if the level still
indicates irq, it will be latched again and if not, the HW needs
no service.
For edge triggered the current implementation of mask/unmask
seems to behave more like enable/disable:
- irq detection is disabled during the masking period, which is
like disable according above description. But leaves a small
window for latching another one that is not served immediately,
which is more like masking
static void gpio_mask_irq(struct irq_data *d)
{
spin_lock_irqsave(bank-lock, flags);
_set_gpio_irqenable(bank, gpio, 0);
--- new irqs latched here ---
_set_gpio_triggering(bank, GPIO_INDEX(bank, gpio),
IRQ_TYPE_NONE);
spin_unlock_irqrestore(bank-lock, flags);
}
- does not clear latched irqs upon resume. So not all irq raised
after unmask are new, on the other hand some irqs that
occured during the masking period might be lost.
I am also interested in the need for this, and if we should have a true
enable/disable here.
Since SDIO irqs are level triggered, I'm still okay with my patch.
For edge triggered though, it probably needs some more thoughts.
Suggestions? Should I split masking/disabling functions and make
them behave properly according above semantics or are you fine with
the interim solution of mapping enable/disable to mask/unmask?
rgds,
Andi
drivers/gpio/gpio-omap.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index d335af1..c1951ec 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -815,6 +815,8 @@ static struct irq_chip gpio_irq_chip = {
.irq_unmask= gpio_unmask_irq,
.irq_set_type= gpio_irq_type,
.irq_set_wake= gpio_wake_enable,
+.irq_disable= gpio_mask_irq,
+.irq_enable = gpio_unmask_irq,
};
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: convert arm/arm64 arch timer to use CLKSRC_OF init
On Monday 25 March 2013, Rob Herring wrote: I count integrator-cp, realview, versatile and non-DT VExpress that do this (not surprisingly) and 25 platforms or timer implementations plus arm64 that do sched_clock setup in time_init. What's broken by not moving these earlier? timekeeping_init() will leave the persistent_clock_exist variable as false, which is read in rtc_suspend() and timekeeping_inject_sleeptime(). For all I can tell, you will get a little jitter every time you do a suspend in that case. Or perhaps it means the system clock will be forwarded by the amount of time spent in suspend twice after wakeup, but I'm probably misreading the code for that case. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: convert arm/arm64 arch timer to use CLKSRC_OF init
On 03/25/2013 03:36 PM, Arnd Bergmann wrote: On Monday 25 March 2013, Rob Herring wrote: I count integrator-cp, realview, versatile and non-DT VExpress that do this (not surprisingly) and 25 platforms or timer implementations plus arm64 that do sched_clock setup in time_init. What's broken by not moving these earlier? timekeeping_init() will leave the persistent_clock_exist variable as false, which is read in rtc_suspend() and timekeeping_inject_sleeptime(). Are you mixing up the persistent_clock and sched_clock here? From a generic stand-point they have different requirements. For all I can tell, you will get a little jitter every time you do a suspend in that case. Or perhaps it means the system clock will be forwarded by the amount of time spent in suspend twice after wakeup, but I'm probably misreading the code for that case. No, you shouldn't see timekeeping being incremented twice, we check in rtc_resume code if the persistent clock is present if so we won't inject any measured suspend time there. But you're probably right that we're being a little overly paranoid checking the same value twice. As far as the benefit to the persistent clock: it is just a little better to use, since we can access it earlier in resume, prior to interrupts being enabled. So we should see less time error introduced each suspend. thanks -john -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] spi: spi-omap2-mcspi.c: Add dts for slave device configuration.
TI omap2 mcspi allows the slave devices to configure the behavior of
the SPI master. This patch adds device tree support to the existing
options.
Signed-off-by: Matthias Brugger matthias@gmail.com
---
Documentation/devicetree/bindings/spi/omap-spi.txt | 23
drivers/spi/spi-omap2-mcspi.c | 41 ++
2 files changed, 64 insertions(+)
diff --git a/Documentation/devicetree/bindings/spi/omap-spi.txt
b/Documentation/devicetree/bindings/spi/omap-spi.txt
index 938809c..fef16bf 100644
--- a/Documentation/devicetree/bindings/spi/omap-spi.txt
+++ b/Documentation/devicetree/bindings/spi/omap-spi.txt
@@ -10,8 +10,20 @@ Required properties:
input. The default is D0 as input and
D1 as output.
+SPI Controller specific data in SPI slave nodes:
+
+- The spi slave nodes can provide the following information which is used
+ by the spi controller.
+
+- ti,spi-cs-per-word: Set chipselect to be toggled on every word send.
+
+- ti,spi-turbo-mode: Set turbo mode for this device.
+
+
Example:
+- SoC Specific Portion:
+
mcspi1: mcspi@1 {
#address-cells = 1;
#size-cells = 0;
@@ -20,3 +32,14 @@ mcspi1: mcspi@1 {
ti,spi-num-cs = 4;
};
+- Board Specific Portion:
+
+ spi-device@0 {
+ #address-cells = 1;
+ #size-cells = 1;
+
+ controller-data {
+ ti,spi-cs-per-word = 1;
+ ti,spi-turbo-mode = 0;
+ };
+ };
diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi/spi-omap2-mcspi.c
index 893c3d7..1ae5009 100644
--- a/drivers/spi/spi-omap2-mcspi.c
+++ b/drivers/spi/spi-omap2-mcspi.c
@@ -731,11 +731,47 @@ static u32 omap2_mcspi_calc_divisor(u32 speed_hz)
return 15;
}
+static struct omap2_mcspi_device_config *omap2_mcspi_get_slave_ctrldata(
+ struct spi_device *spi)
+{
+ struct omap2_mcspi_device_config *cd;
+ struct device_node *slave_np, *data_np = NULL;
+
+ slave_np = spi-dev.of_node;
+ if (!slave_np) {
+ dev_err(spi-dev, device node not found\n);
+ return ERR_PTR(-EINVAL);
+ }
+
+ data_np = of_get_child_by_name(slave_np, controller-data);
+ if (!data_np) {
+ dev_err(spi-dev, child node 'controller-data' not found\n);
+ return ERR_PTR(-EINVAL);
+ }
+
+ cd = kzalloc(sizeof(*cd), GFP_KERNEL);
+ if (!cd) {
+ dev_err(spi-dev, could not allocate memory for controller
data\n);
+ of_node_put(data_np);
+ return ERR_PTR(-ENOMEM);
+ }
+
+ if (of_get_property(data_np, ti,spi-cs-per-word, NULL))
+ cd-cs_per_word = 1;
+
+ if (of_get_property(data_np, ti,spi-turbo-mode, NULL))
+ cd-turbo_mode = 1;
+
+ of_node_put(data_np);
+ return cd;
+}
+
/* called only when no transfer is active to this device */
static int omap2_mcspi_setup_transfer(struct spi_device *spi,
struct spi_transfer *t)
{
struct omap2_mcspi_cs *cs = spi-controller_state;
+ struct omap2_mcspi_device_config *cd = spi-controller_data;
struct omap2_mcspi *mcspi;
struct spi_master *spi_cntrl;
u32 l = 0, div = 0;
@@ -745,6 +781,11 @@ static int omap2_mcspi_setup_transfer(struct spi_device
*spi,
mcspi = spi_master_get_devdata(spi-master);
spi_cntrl = mcspi-master;
+ if (!cd spi-dev.of_node) {
+ cd = omap2_mcspi_get_slave_ctrldata(spi);
+ spi-controller_data = cd;
+ }
+
if (t != NULL t-bits_per_word)
word_len = t-bits_per_word;
--
1.7.11.7
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] ADP1653 board code for Nokia RX-51
Hi Sakari, On Sunday 24 March 2013 23:46:01 Sakari Ailus wrote: Pali Rohár wrote: On Thursday 07 March 2013 23:18:27 Sakari Ailus wrote: On Wed, Mar 06, 2013 at 10:44:41PM +0100, Sebastian Reichel wrote: On Wed, Mar 06, 2013 at 09:20:16PM +0100, Pali Rohár wrote: On Wednesday 06 March 2013 21:12:06 Pali Rohár wrote: On Sunday 17 February 2013 20:03:03 Aaro Koskinen wrote: On Sun, Feb 17, 2013 at 04:16:49PM +0100, Pali Rohár wrote: +/* + * arch/arm/mach-omap2/board-rx51-camera.c + * + * Copyright (C) 2008 Nokia Corporation + * + * Contact: Sakari Ailus sakari.ai...@nokia.com + * Tuukka Toivonen tuukka.o.toivo...@nokia.com You should put these people to CC... Just to see if the addresses are still valid (which I doubt). Ok, trying :-) I got Delivery Status Notification (Failure) for both addresses. This is expected. Sakari Ailus hosts some code on github [0], which has the following email address: sakari.ailus+gitori...@retiisi.org.uk I added it to this mail's CC. [0] https://gitorious.org/~sailus Nice to hear people are interested in this. ;-) The primary reason I haven't tried submitting this to mainline is that ARM board code has a bad reputation these days. The N900 does not have yet support for device tree (AFAIK), which also would require a few bits and pieces on the flash driver to work. Also the sensor and lens drivers would need at least some work before being ready for submission to mainline for camera to be usable. Unfortunately I haven't had recently time to work on this. N9(50) support has higher priority for myself. That, too, is pending the DT support for the device. There's indeed more up-to-date code in my repository. Even if it's not too close to mainline anymore it should be a better starting point than the old kernel from MeeGo. URL:https://gitorious.org/omap3camera/pages/Home Hi, this board code is same in your git repository and on meego obs. Patch only adding support for adp1653 driver which is already in upstream kernel. Are there any other problems with this patch to go for upstream? A few more things comes to mind. We depend a little bit on actual board code; it's not only static data. That's the configuration of the external clock from the ISP to the sensor. That should move to the common clock framework so that the ISP registers the clock and the sensor driver can then use it. AFAIR Laurent has done some work on that. Yes. I hope to get the patches in v3.10. The peculiar detail of the rx51 is that there's a switch on the camera CCP2 bus that selects either sensor (primary or secondary). Both sensors are connected to the same receiver. That isn't properly modelled currently at all, so that's why we have rx51_camera_set_xshutdown(). I guess it'd still work if you only power (i.e. open) either of the devices at a time, though. Have you thought about how we could model that ? That should be all. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: convert arm/arm64 arch timer to use CLKSRC_OF init
On Mon, Mar 25, 2013 at 09:28:10PM +, Rob Herring wrote: On 03/25/2013 12:26 PM, Russell King - ARM Linux wrote: On Thu, Mar 21, 2013 at 11:06:47AM +, Mark Rutland wrote: On TC2 this series leads to using the vexpress 24MHz clock as the sched clock in preference to the architected timer: Architected local timer running at 24.00MHz (virt). Switching to timer-based delay loop Registered arch_counter_get_cntvct+0x0/0x14 as sched_clock source sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every 178956ms Registered versatile_read_sched_clock+0x0/0x28 as sched_clock source As they both have the same frequency, neither overrides the other, and whichever gets registered last is used as the sched_clock. As accesses to the architected timer are going to have a much lower overhead, this isn't very nice (and it could be better to use it even if it had a lower frequency). I'll remind people that sched_clock() is supposed to be functional at the point in the boot sequence where the call to sched_init() is called. That is after setup_arch() and *before* time_init() is called. I count integrator-cp, realview, versatile and non-DT VExpress that do this (not surprisingly) and 25 platforms or timer implementations plus arm64 that do sched_clock setup in time_init. Before time_init(), sched_clock() currently returns 0 with the architected timers (though I don't particularly like this for arm64). Marc Rutland has patches to make arch_timer_read_counter() a function which always returns the virtual counter. It requires the CNTVOFF register to be set to 0 on AArch32 during boot. But this way sched_clock() on arm64 would always return meaningful values as we have the architected timers. -- Catalin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] omap: fix typo CONFIG_BRIDGE_DVFS
Commit 90173882ed15a8034d6d162da5f343a2c7d87587 (omap: add dsp platform
device) used CONFIG_BRIDGE_DVFS were it obviously meant
CONFIG_TIDSPBRIDGE_DVFS. Fix that.
Signed-off-by: Paul Bolle pebo...@tiscali.nl
---
Untested. As this typo has been in the tree since v2.6.37, this really
needs some testing.
arch/arm/mach-omap2/dsp.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/dsp.c b/arch/arm/mach-omap2/dsp.c
index b155500..b8208b4 100644
--- a/arch/arm/mach-omap2/dsp.c
+++ b/arch/arm/mach-omap2/dsp.c
@@ -26,7 +26,7 @@
#include control.h
#include cm2xxx_3xxx.h
#include prm2xxx_3xxx.h
-#ifdef CONFIG_BRIDGE_DVFS
+#ifdef CONFIG_TIDSPBRIDGE_DVFS
#include omap-pm.h
#endif
@@ -35,7 +35,7 @@
static struct platform_device *omap_dsp_pdev;
static struct omap_dsp_platform_data omap_dsp_pdata __initdata = {
-#ifdef CONFIG_BRIDGE_DVFS
+#ifdef CONFIG_TIDSPBRIDGE_DVFS
.dsp_set_min_opp = omap_pm_dsp_set_min_opp,
.dsp_get_opp = omap_pm_dsp_get_opp,
.cpu_set_freq = omap_pm_cpu_set_freq,
--
1.7.11.7
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 09/12] staging: ti-soc-thermal: fix several kernel-doc warnings and error
On 25-03-2013 14:22, Greg KH wrote: On Tue, Mar 19, 2013 at 10:54:25AM -0400, Eduardo Valentin wrote: This patch updates the documentation to remove all warnings and errors reported by scripts/kernel-doc. Most are missing arguments due to wrong format. Cc: Nishanth Menon n...@ti.com Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com In the future, don't put empty lines between the Cc: and signed-off-by: lines please, I had to hand-edit all of these to fix that... Ok. Sure.. My bad.. greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: convert arm/arm64 arch timer to use CLKSRC_OF init
On 03/25/2013 05:53 PM, John Stultz wrote: On 03/25/2013 03:36 PM, Arnd Bergmann wrote: On Monday 25 March 2013, Rob Herring wrote: I count integrator-cp, realview, versatile and non-DT VExpress that do this (not surprisingly) and 25 platforms or timer implementations plus arm64 that do sched_clock setup in time_init. What's broken by not moving these earlier? timekeeping_init() will leave the persistent_clock_exist variable as false, which is read in rtc_suspend() and timekeeping_inject_sleeptime(). Are you mixing up the persistent_clock and sched_clock here? From a generic stand-point they have different requirements. Yes. We're talking about sched_clock here. What would be the benefit of having it setup before sched_init vs. later in time_init? Rob -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] ARM: AM33XX: Add missing .clkdm_name to clkdiv32k_ick clock
-Original Message-
From: Nayak, Rajendra
Sent: Monday, March 25, 2013 6:07 PM
To: Hiremath, Vaibhav
Cc: linux-omap@vger.kernel.org; Tony Lindgren; Paul Walmsley; linux-
arm-ker...@lists.infradead.org
Subject: Re: [PATCH] ARM: AM33XX: Add missing .clkdm_name to
clkdiv32k_ick clock
On Monday 25 March 2013 05:07 PM, Vaibhav Hiremath wrote:
During common-clock migration, .clkdm_name field got missed
for clkdiv32k_ick clock, which leaves clk_24mhz_clkdm
unused; so boot process will try to disable the clockdomain
even childs of this clock is enabled, which keeps child modules
in idle mode.
The patch looks fine but I feel the change log certainly needs an
update. The clkdm association with the clks is maintained for those
clks which have a hard requirement that the clkdm be force woken up
before the clk can be enabled. If thats the case for clkdiv32k_ick,
then what you are doing makes sense,
Yes, that’s correct. Just again to put more clarity on this,
AM33xx clock-tree is slightly deviated compared to OMAP3/4, where
We do not have MODULE_MODE clock nodes populated in tree, since
HWMOD is handing it. CLKDIV32K_CLK is special clock gate, where
it is being used as MODULE_MODE, but in reality it is simple
clock_gate. We had multiple discussion in the past related to this
and infact I went back to design team on this, explained about
how this inconsistency is hampering SW design and recommended to fix
this in next SoC.
More discussion can be found @
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg69087.html
Coming back to your comment, I will change commit description
And also try to add above details.
Thanks,
Vaibhav
but the changelog is certainlly
confusing when it says 'boot process will try to disable the
clockdomain'
This fixes the kernel crash observed on AM335xEVM-Sk platform,
where clkdiv32_ick clock is being used as a gpio debounce clock
and since clkdiv32k_ick is in idle mode it leads to below crash -
Crash Log:
=
[2.598347] Unhandled fault: external abort on non-linefetch
(0x1028) at
0xfa1ac150
[2.606434] Internal error: : 1028 [#1] SMP ARM
[2.611207] Modules linked in:
[2.614449] CPU: 0Not tainted (3.8.4-01382-g1f449cd-dirty #4)
[2.620973] PC is at _set_gpio_debounce+0x60/0x104
[2.626025] LR is at clk_enable+0x30/0x3c
[2.630249] pc : [c02e2850]lr : [c0449ad8]psr:
6193
[2.630249] sp : cf053df8 ip : 0001 fp : cf19e000
[2.642308] r10: cdc56800 r9 : cf19e010 r8 : cf0b8410
[2.647802] r7 : 0002 r6 : 0004 r5 : 00a0 r4 :
cf0b8410
[2.654668] r3 : fa1ac150 r2 : fa1ac000 r1 : r0 :
[2.661540] Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM
Segment kernel
[2.669324] Control: 10c5387d Table: 80004019 DAC: 0017
[2.675372] Process swapper/0 (pid: 1, stack limit = 0xcf052240)
[2.681688] Stack: (0xcf053df8 to 0xcf054000)
[2.686279] 3de0: cf0b846c 2113
[2.694892] 3e00: 1388 c02e2924 0002 cf0b848c
2113 1388 c02e0258
[2.703508] 3e20: cdc57ce8 cdca2784 c00028d8 cdc56800
c040ba10 cdc57c50 c08374e0
[2.712115] 3e40: 0001 0028 cdca2784 cdca2740 cdc57c00
cdc56800 c040bc58
[2.720727] 3e60: cf1a0bd0 cf19e010 c08374e0 c0d96ffc c08374e0
cf19e010 c08374e0
[2.729341] 3e80: c076c7b0 c07421c4 c0331c90 c0331c78
c033092c cf19e010 c08374e0
[2.737957] 3ea0: cf19e044 c0330bd8
cf19e010 c08374e0 c0330c84
[2.746573] 3ec0: c08374e0 c0330bf0 c032f2f8 cf0222a8
cf198a10 c08374e0 c08265c8
[2.755185] 3ee0: cdbca7c0 c033015c c067d1e0 c08374e0 c08374e0
c0844600 cf052000
[2.763793] 3f00: c03311b8 c0776fb0 c0844600
cf052000
[2.772393] 3f20: c07421c4 c0008818 0001dd4e 0007
c076c7b0 07753841
[2.780998] 3f40: 9a64d806 9a64d806 6113
c0776fb0 0007 c0776f90
[2.789603] 3f60: c0844600 00af c0793ee8 c07421c4
c07428f8 0007 0007
[2.798217] 3f80: c07421c4 c0513f0c
[2.806827] 3fa0: c0513f14 c0013490
[2.815447] 3fc0:
[2.824058] 3fe0: 0013
eebff7f9 3a5f1b7e
[2.832668] [c02e2850] (_set_gpio_debounce+0x60/0x104) from
[c02e2924] (gpio_debounce+0x30/0x44)
[2.842272] [c02e2924] (gpio_debounce+0x30/0x44) from
[c02e0258]
(gpio_set_debounce+0xc4/0xdc)
[2.851714] [c02e0258] (gpio_set_debounce+0xc4/0xdc) from
[c040ba10]
Re: [PATCH] ARM: AM33XX: Add missing .clkdm_name to clkdiv32k_ick clock
On Tuesday 26 March 2013 10:42 AM, Hiremath, Vaibhav wrote: -Original Message- From: Nayak, Rajendra Sent: Monday, March 25, 2013 6:07 PM To: Hiremath, Vaibhav Cc: linux-omap@vger.kernel.org; Tony Lindgren; Paul Walmsley; linux- arm-ker...@lists.infradead.org Subject: Re: [PATCH] ARM: AM33XX: Add missing .clkdm_name to clkdiv32k_ick clock On Monday 25 March 2013 05:07 PM, Vaibhav Hiremath wrote: During common-clock migration, .clkdm_name field got missed for clkdiv32k_ick clock, which leaves clk_24mhz_clkdm unused; so boot process will try to disable the clockdomain even childs of this clock is enabled, which keeps child modules in idle mode. The patch looks fine but I feel the change log certainly needs an update. The clkdm association with the clks is maintained for those clks which have a hard requirement that the clkdm be force woken up before the clk can be enabled. If thats the case for clkdiv32k_ick, then what you are doing makes sense, Yes, that’s correct. Just again to put more clarity on this, AM33xx clock-tree is slightly deviated compared to OMAP3/4, where We do not have MODULE_MODE clock nodes populated in tree, since HWMOD is handing it. CLKDIV32K_CLK is special clock gate, where it is being used as MODULE_MODE, but in reality it is simple clock_gate. We had multiple discussion in the past related to this and infact I went back to design team on this, explained about how this inconsistency is hampering SW design and recommended to fix this in next SoC. More discussion can be found @ http://www.mail-archive.com/linux-omap@vger.kernel.org/msg69087.html Coming back to your comment, I will change commit description And also try to add above details. Great, thanks. I also had a brief look at the am335x clock data yesterday and found most clocks with clkdm associations are actually mux clocks. Do you really need those? clkdm associations make sense for gate clocks. You should be very easily able to convert these over to generic mux types if you can drop the clkdm handling part for those muxes. Thanks, Vaibhav but the changelog is certainlly confusing when it says 'boot process will try to disable the clockdomain' This fixes the kernel crash observed on AM335xEVM-Sk platform, where clkdiv32_ick clock is being used as a gpio debounce clock and since clkdiv32k_ick is in idle mode it leads to below crash - Crash Log: = [2.598347] Unhandled fault: external abort on non-linefetch (0x1028) at 0xfa1ac150 [2.606434] Internal error: : 1028 [#1] SMP ARM [2.611207] Modules linked in: [2.614449] CPU: 0Not tainted (3.8.4-01382-g1f449cd-dirty #4) [2.620973] PC is at _set_gpio_debounce+0x60/0x104 [2.626025] LR is at clk_enable+0x30/0x3c [2.630249] pc : [c02e2850]lr : [c0449ad8]psr: 6193 [2.630249] sp : cf053df8 ip : 0001 fp : cf19e000 [2.642308] r10: cdc56800 r9 : cf19e010 r8 : cf0b8410 [2.647802] r7 : 0002 r6 : 0004 r5 : 00a0 r4 : cf0b8410 [2.654668] r3 : fa1ac150 r2 : fa1ac000 r1 : r0 : [2.661540] Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel [2.669324] Control: 10c5387d Table: 80004019 DAC: 0017 [2.675372] Process swapper/0 (pid: 1, stack limit = 0xcf052240) [2.681688] Stack: (0xcf053df8 to 0xcf054000) [2.686279] 3de0: cf0b846c 2113 [2.694892] 3e00: 1388 c02e2924 0002 cf0b848c 2113 1388 c02e0258 [2.703508] 3e20: cdc57ce8 cdca2784 c00028d8 cdc56800 c040ba10 cdc57c50 c08374e0 [2.712115] 3e40: 0001 0028 cdca2784 cdca2740 cdc57c00 cdc56800 c040bc58 [2.720727] 3e60: cf1a0bd0 cf19e010 c08374e0 c0d96ffc c08374e0 cf19e010 c08374e0 [2.729341] 3e80: c076c7b0 c07421c4 c0331c90 c0331c78 c033092c cf19e010 c08374e0 [2.737957] 3ea0: cf19e044 c0330bd8 cf19e010 c08374e0 c0330c84 [2.746573] 3ec0: c08374e0 c0330bf0 c032f2f8 cf0222a8 cf198a10 c08374e0 c08265c8 [2.755185] 3ee0: cdbca7c0 c033015c c067d1e0 c08374e0 c08374e0 c0844600 cf052000 [2.763793] 3f00: c03311b8 c0776fb0 c0844600 cf052000 [2.772393] 3f20: c07421c4 c0008818 0001dd4e 0007 c076c7b0 07753841 [2.780998] 3f40: 9a64d806 9a64d806 6113 c0776fb0 0007 c0776f90 [2.789603] 3f60: c0844600 00af c0793ee8 c07421c4 c07428f8 0007 0007 [2.798217] 3f80: c07421c4 c0513f0c [2.806827] 3fa0: c0513f14 c0013490 [2.815447] 3fc0: [2.824058] 3fe0:
RE: [PATCH] ARM: AM33XX: Add missing .clkdm_name to clkdiv32k_ick clock
-Original Message- From: Nayak, Rajendra Sent: Tuesday, March 26, 2013 10:51 AM To: Hiremath, Vaibhav Cc: linux-omap@vger.kernel.org; Tony Lindgren; Paul Walmsley; linux- arm-ker...@lists.infradead.org Subject: Re: [PATCH] ARM: AM33XX: Add missing .clkdm_name to clkdiv32k_ick clock On Tuesday 26 March 2013 10:42 AM, Hiremath, Vaibhav wrote: -Original Message- From: Nayak, Rajendra Sent: Monday, March 25, 2013 6:07 PM To: Hiremath, Vaibhav Cc: linux-omap@vger.kernel.org; Tony Lindgren; Paul Walmsley; linux- arm-ker...@lists.infradead.org Subject: Re: [PATCH] ARM: AM33XX: Add missing .clkdm_name to clkdiv32k_ick clock On Monday 25 March 2013 05:07 PM, Vaibhav Hiremath wrote: During common-clock migration, .clkdm_name field got missed for clkdiv32k_ick clock, which leaves clk_24mhz_clkdm unused; so boot process will try to disable the clockdomain even childs of this clock is enabled, which keeps child modules in idle mode. The patch looks fine but I feel the change log certainly needs an update. The clkdm association with the clks is maintained for those clks which have a hard requirement that the clkdm be force woken up before the clk can be enabled. If thats the case for clkdiv32k_ick, then what you are doing makes sense, Yes, that’s correct. Just again to put more clarity on this, AM33xx clock-tree is slightly deviated compared to OMAP3/4, where We do not have MODULE_MODE clock nodes populated in tree, since HWMOD is handing it. CLKDIV32K_CLK is special clock gate, where it is being used as MODULE_MODE, but in reality it is simple clock_gate. We had multiple discussion in the past related to this and infact I went back to design team on this, explained about how this inconsistency is hampering SW design and recommended to fix this in next SoC. More discussion can be found @ http://www.mail-archive.com/linux-omap@vger.kernel.org/msg69087.html Coming back to your comment, I will change commit description And also try to add above details. Great, thanks. I also had a brief look at the am335x clock data yesterday and found most clocks with clkdm associations are actually mux clocks. Do you really need those? clkdm associations make sense for gate clocks. You should be very easily able to convert these over to generic mux types if you can drop the clkdm handling part for those muxes. We need that, and for the exact same reason you pointed out in last response We need to enabled the clockdomain before enabling the module clock. With not having leaf clocks in clock-tree HWMOD data points to parent clock, Which in most of the cases ends up into clock mux. So in order to have Link between hwmod-clock-clock-domain we need that entry. Thanks, Vaibhav -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
