RE: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20 state and altivec idle
-Original Message-
From: Wood Scott-B07421
Sent: Saturday, October 19, 2013 3:22 AM
To: Wang Dongsheng-B40534
Cc: Bhushan Bharat-R65777; Wood Scott-B07421; linuxppc-
d...@lists.ozlabs.org
Subject: Re: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20 state and
altivec idle
On Thu, 2013-10-17 at 22:02 -0500, Wang Dongsheng-B40534 wrote:
-Original Message-
From: Bhushan Bharat-R65777
Sent: Thursday, October 17, 2013 2:46 PM
To: Wang Dongsheng-B40534; Wood Scott-B07421
Cc: linuxppc-dev@lists.ozlabs.org
Subject: RE: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20 state
and altivec idle
-Original Message-
From: Wang Dongsheng-B40534
Sent: Thursday, October 17, 2013 11:22 AM
To: Bhushan Bharat-R65777; Wood Scott-B07421
Cc: linuxppc-dev@lists.ozlabs.org
Subject: RE: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20
state and altivec idle
-Original Message-
From: Bhushan Bharat-R65777
Sent: Thursday, October 17, 2013 11:20 AM
To: Wang Dongsheng-B40534; Wood Scott-B07421
Cc: linuxppc-dev@lists.ozlabs.org
Subject: RE: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20
state and altivec idle
-Original Message-
From: Wang Dongsheng-B40534
Sent: Thursday, October 17, 2013 8:16 AM
To: Bhushan Bharat-R65777; Wood Scott-B07421
Cc: linuxppc-dev@lists.ozlabs.org
Subject: RE: [PATCH v5 4/4] powerpc/85xx: add sysfs for
pw20 state and altivec idle
-Original Message-
From: Bhushan Bharat-R65777
Sent: Thursday, October 17, 2013 1:01 AM
To: Wang Dongsheng-B40534; Wood Scott-B07421
Cc: linuxppc-dev@lists.ozlabs.org
Subject: RE: [PATCH v5 4/4] powerpc/85xx: add sysfs for
pw20 state and altivec idle
-Original Message-
From: Wang Dongsheng-B40534
Sent: Tuesday, October 15, 2013 2:51 PM
To: Wood Scott-B07421
Cc: Bhushan Bharat-R65777;
linuxppc-dev@lists.ozlabs.org; Wang
Dongsheng-B40534
Subject: [PATCH v5 4/4] powerpc/85xx: add sysfs for
pw20 state and
altivec idle
From: Wang Dongsheng dongsheng.w...@freescale.com
Add a sys interface to enable/diable pw20 state or
altivec idle, and
control the
wait entry time.
Enable/Disable interface:
0, disable. 1, enable.
/sys/devices/system/cpu/cpuX/pw20_state
/sys/devices/system/cpu/cpuX/altivec_idle
Set wait time interface:(Nanosecond)
/sys/devices/system/cpu/cpuX/pw20_wait_time
/sys/devices/system/cpu/cpuX/altivec_idle_wait_time
Example: Base on TBfreq is 41MHZ.
1~48(ns): TB[63]
49~97(ns): TB[62]
98~195(ns): TB[61]
196~390(ns): TB[60]
391~780(ns): TB[59]
781~1560(ns): TB[58]
...
Signed-off-by: Wang Dongsheng
dongsheng.w...@freescale.com
---
*v5:
Change get_idle_ticks_bit function implementation.
*v4:
Move code from 85xx/common.c to kernel/sysfs.c.
Remove has_pw20_altivec_idle function.
Change wait entry_bit to wait time.
diff --git a/arch/powerpc/kernel/sysfs.c
b/arch/powerpc/kernel/sysfs.c
index
27a90b9..10d1128 100644
--- a/arch/powerpc/kernel/sysfs.c
+++ b/arch/powerpc/kernel/sysfs.c
@@ -85,6 +85,284 @@ __setup(smt-snooze-delay=,
setup_smt_snooze_delay);
#endif /* CONFIG_PPC64 */
+#ifdef CONFIG_FSL_SOC
+#define MAX_BIT63
+
+static u64 pw20_wt;
+static u64 altivec_idle_wt;
+
+static unsigned int get_idle_ticks_bit(u64 ns) {
+ u64 cycle;
+
+ if (ns = 1)
+ cycle = div_u64(ns + 500, 1000) *
tb_ticks_per_usec;
+ else
+ cycle = div_u64(ns * tb_ticks_per_usec,
1000);
+
+ if (!cycle)
+ return 0;
+
+ return ilog2(cycle); }
+
+static void do_show_pwrmgtcr0(void *val) {
+ u32 *value = val;
+
+ *value = mfspr(SPRN_PWRMGTCR0); }
+
+static ssize_t show_pw20_state(struct device *dev,
+ struct device_attribute *attr,
char
*buf) {
+ u32 value;
+ unsigned int cpu = dev-id;
+
+ smp_call_function_single(cpu, do_show_pwrmgtcr0
RE: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20 state and altivec idle
-Original Message-
From: Wood Scott-B07421
Sent: Saturday, October 19, 2013 3:23 AM
To: Wang Dongsheng-B40534
Cc: Wood Scott-B07421; Bhushan Bharat-R65777; linuxppc-
d...@lists.ozlabs.org
Subject: Re: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20 state and
altivec idle
On Thu, 2013-10-17 at 21:36 -0500, Wang Dongsheng-B40534 wrote:
-Original Message-
From: Wood Scott-B07421
Sent: Friday, October 18, 2013 12:52 AM
To: Wang Dongsheng-B40534
Cc: Bhushan Bharat-R65777; Wood Scott-B07421; linuxppc-
d...@lists.ozlabs.org
Subject: Re: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20 state
and altivec idle
On Thu, 2013-10-17 at 00:51 -0500, Wang Dongsheng-B40534 wrote:
-Original Message-
From: Bhushan Bharat-R65777
Sent: Thursday, October 17, 2013 11:20 AM
To: Wang Dongsheng-B40534; Wood Scott-B07421
Cc: linuxppc-dev@lists.ozlabs.org
Subject: RE: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20
state and altivec idle
-Original Message-
From: Wang Dongsheng-B40534
Sent: Thursday, October 17, 2013 8:16 AM
To: Bhushan Bharat-R65777; Wood Scott-B07421
Cc: linuxppc-dev@lists.ozlabs.org
Subject: RE: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20
state and altivec idle
-Original Message-
From: Bhushan Bharat-R65777
Sent: Thursday, October 17, 2013 1:01 AM
To: Wang Dongsheng-B40534; Wood Scott-B07421
Cc: linuxppc-dev@lists.ozlabs.org
Subject: RE: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20
state and altivec idle
-Original Message-
From: Wang Dongsheng-B40534
Sent: Tuesday, October 15, 2013 2:51 PM
To: Wood Scott-B07421
Cc: Bhushan Bharat-R65777; linuxppc-dev@lists.ozlabs.org;
Wang
Dongsheng-B40534
Subject: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20
state and
altivec idle
+static ssize_t show_pw20_wait_time(struct device *dev,
+ struct device_attribute *attr,
char
*buf) {
+ u32 value;
+ u64 tb_cycle;
+ s64 time;
+
+ unsigned int cpu = dev-id;
+
+ if (!pw20_wt) {
+ smp_call_function_single(cpu, do_show_pwrmgtcr0,
+value,
1);
+ value = (value PWRMGTCR0_PW20_ENT)
+
PWRMGTCR0_PW20_ENT_SHIFT;
+
+ tb_cycle = (1 (MAX_BIT - value)) * 2;
Is value = 0 and value = 1 legal? These will make tb_cycle =
0,
+ time = div_u64(tb_cycle * 1000,
tb_ticks_per_usec)
- 1;
And time = -1;
Please look at the end of the function, :)
return sprintf(buf, %llu\n, time 0 ? time : 0);
I know you return 0 if value = 0/1, my question was that, is
this correct as per specification?
Ahh, also for value upto 7 you will return 0, no?
If value = 0, MAX_BIT - value = 63 tb_cycle = 0x_,
Actually, tb_cycle will be undefined because you shifted a 32-bit
value
(1) by more than 31 bits. s/1/1ULL/
Actually, we have been discussing this situation that could not have
happened.
See !pw20_wt branch, this branch is read default wait bit.
The default wait bit is 50, the time is about 1ms.
The default wait bit cannot less than 50, means the wait entry time
cannot greater than 1ms.
We have already begun benchmark test, and we got a preliminary results.
55, 56, 57bit looks good, but we need more benchmark to get the default
bit.
What does the default have to do with it? The user could have set a
different value, and then read it back.
Plus, how much time corresponds to bit 50 depends on the actual timebase
frequency which could vary.
if (!pw20_wt) {
smp_call_function_single(cpu, do_show_pwrmgtcr0, value, 1);
value = (value PWRMGTCR0_PW20_ENT)
PWRMGTCR0_PW20_ENT_SHIFT;
tb_cycle = (1 (MAX_BIT - value)) * 2;
time = tb_cycle * (1000 / tb_ticks_per_usec) - 1;
} else {
time = pw20_wt;
}
As we have discussed before we need a variable to save To save the users to set
wait-entry-time value.
See the code, if user have set a value, and the value will be set in pw20_wt.
When the user read it back, the code will do time = pw20_wt branch.
When the user not set the wait-entry-time value and read this sys interface,
the code will do the following branch.
smp_call_function_single(cpu, do_show_pwrmgtcr0, value, 1);
value = (value PWRMGTCR0_PW20_ENT
RE: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20 state and altivec idle
-Original Message-
From: Bhushan Bharat-R65777
Sent: Thursday, October 17, 2013 2:00 PM
To: Wang Dongsheng-B40534; Wood Scott-B07421
Cc: linuxppc-dev@lists.ozlabs.org
Subject: RE: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20 state and
altivec idle
-Original Message-
From: Wang Dongsheng-B40534
Sent: Thursday, October 17, 2013 11:22 AM
To: Bhushan Bharat-R65777; Wood Scott-B07421
Cc: linuxppc-dev@lists.ozlabs.org
Subject: RE: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20 state and
altivec idle
-Original Message-
From: Bhushan Bharat-R65777
Sent: Thursday, October 17, 2013 11:20 AM
To: Wang Dongsheng-B40534; Wood Scott-B07421
Cc: linuxppc-dev@lists.ozlabs.org
Subject: RE: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20 state
and altivec idle
-Original Message-
From: Wang Dongsheng-B40534
Sent: Thursday, October 17, 2013 8:16 AM
To: Bhushan Bharat-R65777; Wood Scott-B07421
Cc: linuxppc-dev@lists.ozlabs.org
Subject: RE: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20 state
and altivec idle
-Original Message-
From: Bhushan Bharat-R65777
Sent: Thursday, October 17, 2013 1:01 AM
To: Wang Dongsheng-B40534; Wood Scott-B07421
Cc: linuxppc-dev@lists.ozlabs.org
Subject: RE: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20
state and altivec idle
-Original Message-
From: Wang Dongsheng-B40534
Sent: Tuesday, October 15, 2013 2:51 PM
To: Wood Scott-B07421
Cc: Bhushan Bharat-R65777; linuxppc-dev@lists.ozlabs.org; Wang
Dongsheng-B40534
Subject: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20 state
and
altivec idle
From: Wang Dongsheng dongsheng.w...@freescale.com
Add a sys interface to enable/diable pw20 state or altivec
idle, and
control the
wait entry time.
Enable/Disable interface:
0, disable. 1, enable.
/sys/devices/system/cpu/cpuX/pw20_state
/sys/devices/system/cpu/cpuX/altivec_idle
Set wait time interface:(Nanosecond)
/sys/devices/system/cpu/cpuX/pw20_wait_time
/sys/devices/system/cpu/cpuX/altivec_idle_wait_time
Example: Base on TBfreq is 41MHZ.
1~48(ns): TB[63]
49~97(ns): TB[62]
98~195(ns): TB[61]
196~390(ns): TB[60]
391~780(ns): TB[59]
781~1560(ns): TB[58]
...
Signed-off-by: Wang Dongsheng dongsheng.w...@freescale.com
---
*v5:
Change get_idle_ticks_bit function implementation.
*v4:
Move code from 85xx/common.c to kernel/sysfs.c.
Remove has_pw20_altivec_idle function.
Change wait entry_bit to wait time.
diff --git a/arch/powerpc/kernel/sysfs.c
b/arch/powerpc/kernel/sysfs.c
index
27a90b9..10d1128 100644
--- a/arch/powerpc/kernel/sysfs.c
+++ b/arch/powerpc/kernel/sysfs.c
@@ -85,6 +85,284 @@ __setup(smt-snooze-delay=,
setup_smt_snooze_delay);
#endif /* CONFIG_PPC64 */
+#ifdef CONFIG_FSL_SOC
+#define MAX_BIT63
+
+static u64 pw20_wt;
+static u64 altivec_idle_wt;
+
+static unsigned int get_idle_ticks_bit(u64 ns) {
+ u64 cycle;
+
+ if (ns = 1)
+ cycle = div_u64(ns + 500, 1000) * tb_ticks_per_usec;
+ else
+ cycle = div_u64(ns * tb_ticks_per_usec, 1000);
+
+ if (!cycle)
+ return 0;
+
+ return ilog2(cycle);
+}
+
+static void do_show_pwrmgtcr0(void *val) {
+ u32 *value = val;
+
+ *value = mfspr(SPRN_PWRMGTCR0); }
+
+static ssize_t show_pw20_state(struct device *dev,
+ struct device_attribute *attr, char
*buf) {
+ u32 value;
+ unsigned int cpu = dev-id;
+
+ smp_call_function_single(cpu, do_show_pwrmgtcr0, value, 1);
+
+ value = PWRMGTCR0_PW20_WAIT;
+
+ return sprintf(buf, %u\n, value ? 1 : 0); }
+
+static void do_store_pw20_state(void *val) {
+ u32 *value = val;
+ u32 pw20_state;
+
+ pw20_state = mfspr(SPRN_PWRMGTCR0);
+
+ if (*value)
+ pw20_state |= PWRMGTCR0_PW20_WAIT;
+ else
+ pw20_state = ~PWRMGTCR0_PW20_WAIT;
+
+ mtspr(SPRN_PWRMGTCR0, pw20_state); }
+
+static ssize_t store_pw20_state(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t count) {
+ u32 value;
+ unsigned int cpu = dev-id;
+
+ if (kstrtou32(buf, 0, value))
+ return -EINVAL;
+
+ if (value 1)
+ return -EINVAL
RE: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20 state and altivec idle
-Original Message-
From: Wood Scott-B07421
Sent: Friday, October 18, 2013 12:52 AM
To: Wang Dongsheng-B40534
Cc: Bhushan Bharat-R65777; Wood Scott-B07421; linuxppc-
d...@lists.ozlabs.org
Subject: Re: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20 state and
altivec idle
On Thu, 2013-10-17 at 00:51 -0500, Wang Dongsheng-B40534 wrote:
-Original Message-
From: Bhushan Bharat-R65777
Sent: Thursday, October 17, 2013 11:20 AM
To: Wang Dongsheng-B40534; Wood Scott-B07421
Cc: linuxppc-dev@lists.ozlabs.org
Subject: RE: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20 state
and altivec idle
-Original Message-
From: Wang Dongsheng-B40534
Sent: Thursday, October 17, 2013 8:16 AM
To: Bhushan Bharat-R65777; Wood Scott-B07421
Cc: linuxppc-dev@lists.ozlabs.org
Subject: RE: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20 state
and altivec idle
-Original Message-
From: Bhushan Bharat-R65777
Sent: Thursday, October 17, 2013 1:01 AM
To: Wang Dongsheng-B40534; Wood Scott-B07421
Cc: linuxppc-dev@lists.ozlabs.org
Subject: RE: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20
state and altivec idle
-Original Message-
From: Wang Dongsheng-B40534
Sent: Tuesday, October 15, 2013 2:51 PM
To: Wood Scott-B07421
Cc: Bhushan Bharat-R65777; linuxppc-dev@lists.ozlabs.org; Wang
Dongsheng-B40534
Subject: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20 state
and
altivec idle
+static ssize_t show_pw20_wait_time(struct device *dev,
+ struct device_attribute *attr, char
*buf) {
+ u32 value;
+ u64 tb_cycle;
+ s64 time;
+
+ unsigned int cpu = dev-id;
+
+ if (!pw20_wt) {
+ smp_call_function_single(cpu, do_show_pwrmgtcr0, value,
1);
+ value = (value PWRMGTCR0_PW20_ENT)
+ PWRMGTCR0_PW20_ENT_SHIFT;
+
+ tb_cycle = (1 (MAX_BIT - value)) * 2;
Is value = 0 and value = 1 legal? These will make tb_cycle = 0,
+ time = div_u64(tb_cycle * 1000, tb_ticks_per_usec) - 1;
And time = -1;
Please look at the end of the function, :)
return sprintf(buf, %llu\n, time 0 ? time : 0);
I know you return 0 if value = 0/1, my question was that, is this
correct as per specification?
Ahh, also for value upto 7 you will return 0, no?
If value = 0, MAX_BIT - value = 63
tb_cycle = 0x_,
Actually, tb_cycle will be undefined because you shifted a 32-bit value
(1) by more than 31 bits. s/1/1ULL/
Actually, we have been discussing this situation that could not have happened.
See !pw20_wt branch, this branch is read default wait bit.
The default wait bit is 50, the time is about 1ms.
The default wait bit cannot less than 50, means the wait entry time cannot
greater than 1ms.
We have already begun benchmark test, and we got a preliminary results.
55, 56, 57bit looks good, but we need more benchmark to get the default bit.
if (!pw20_wt) {
smp_call_function_single(cpu, do_show_pwrmgtcr0, value, 1);
value = (value PWRMGTCR0_PW20_ENT)
PWRMGTCR0_PW20_ENT_SHIFT;
tb_cycle = (1 (MAX_BIT - value)) * 2;
time = div_u64(tb_cycle * 1000, tb_ticks_per_usec) - 1;
} else {
time = pw20_wt;
}
If it caused confusion, we can add a comment. As I discuss with Bharat.
tb_cycle * 1000 will overflow, but this situation is not possible.
Because if the value = 0 means this feature will be disable.
Now The default wait bit is 50(MAX_BIT - value, value = 13), the
PW20/Altivec Idle wait entry time is about 1ms, this time is very long
for wait idle time, and it's cannot be increased(means (MAX_BIT -
value) cannot greater than 50).
Why can it not be increased?
see above, :)
-dongsheng
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20 state and altivec idle
-Original Message-
From: Bhushan Bharat-R65777
Sent: Thursday, October 17, 2013 2:46 PM
To: Wang Dongsheng-B40534; Wood Scott-B07421
Cc: linuxppc-dev@lists.ozlabs.org
Subject: RE: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20 state and
altivec idle
-Original Message-
From: Wang Dongsheng-B40534
Sent: Thursday, October 17, 2013 11:22 AM
To: Bhushan Bharat-R65777; Wood Scott-B07421
Cc: linuxppc-dev@lists.ozlabs.org
Subject: RE: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20 state
and altivec idle
-Original Message-
From: Bhushan Bharat-R65777
Sent: Thursday, October 17, 2013 11:20 AM
To: Wang Dongsheng-B40534; Wood Scott-B07421
Cc: linuxppc-dev@lists.ozlabs.org
Subject: RE: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20
state and altivec idle
-Original Message-
From: Wang Dongsheng-B40534
Sent: Thursday, October 17, 2013 8:16 AM
To: Bhushan Bharat-R65777; Wood Scott-B07421
Cc: linuxppc-dev@lists.ozlabs.org
Subject: RE: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20
state and altivec idle
-Original Message-
From: Bhushan Bharat-R65777
Sent: Thursday, October 17, 2013 1:01 AM
To: Wang Dongsheng-B40534; Wood Scott-B07421
Cc: linuxppc-dev@lists.ozlabs.org
Subject: RE: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20
state and altivec idle
-Original Message-
From: Wang Dongsheng-B40534
Sent: Tuesday, October 15, 2013 2:51 PM
To: Wood Scott-B07421
Cc: Bhushan Bharat-R65777; linuxppc-dev@lists.ozlabs.org;
Wang
Dongsheng-B40534
Subject: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20
state and
altivec idle
From: Wang Dongsheng dongsheng.w...@freescale.com
Add a sys interface to enable/diable pw20 state or altivec
idle, and
control the
wait entry time.
Enable/Disable interface:
0, disable. 1, enable.
/sys/devices/system/cpu/cpuX/pw20_state
/sys/devices/system/cpu/cpuX/altivec_idle
Set wait time interface:(Nanosecond)
/sys/devices/system/cpu/cpuX/pw20_wait_time
/sys/devices/system/cpu/cpuX/altivec_idle_wait_time
Example: Base on TBfreq is 41MHZ.
1~48(ns): TB[63]
49~97(ns): TB[62]
98~195(ns): TB[61]
196~390(ns): TB[60]
391~780(ns): TB[59]
781~1560(ns): TB[58]
...
Signed-off-by: Wang Dongsheng
dongsheng.w...@freescale.com
---
*v5:
Change get_idle_ticks_bit function implementation.
*v4:
Move code from 85xx/common.c to kernel/sysfs.c.
Remove has_pw20_altivec_idle function.
Change wait entry_bit to wait time.
diff --git a/arch/powerpc/kernel/sysfs.c
b/arch/powerpc/kernel/sysfs.c
index
27a90b9..10d1128 100644
--- a/arch/powerpc/kernel/sysfs.c
+++ b/arch/powerpc/kernel/sysfs.c
@@ -85,6 +85,284 @@ __setup(smt-snooze-delay=,
setup_smt_snooze_delay);
#endif /* CONFIG_PPC64 */
+#ifdef CONFIG_FSL_SOC
+#define MAX_BIT63
+
+static u64 pw20_wt;
+static u64 altivec_idle_wt;
+
+static unsigned int get_idle_ticks_bit(u64 ns) {
+ u64 cycle;
+
+ if (ns = 1)
+ cycle = div_u64(ns + 500, 1000) *
tb_ticks_per_usec;
+ else
+ cycle = div_u64(ns * tb_ticks_per_usec, 1000);
+
+ if (!cycle)
+ return 0;
+
+ return ilog2(cycle);
+}
+
+static void do_show_pwrmgtcr0(void *val) {
+ u32 *value = val;
+
+ *value = mfspr(SPRN_PWRMGTCR0); }
+
+static ssize_t show_pw20_state(struct device *dev,
+ struct device_attribute *attr,
char
*buf) {
+ u32 value;
+ unsigned int cpu = dev-id;
+
+ smp_call_function_single(cpu, do_show_pwrmgtcr0, value,
+1);
+
+ value = PWRMGTCR0_PW20_WAIT;
+
+ return sprintf(buf, %u\n, value ? 1 : 0); }
+
+static void do_store_pw20_state(void *val) {
+ u32 *value = val;
+ u32 pw20_state;
+
+ pw20_state = mfspr(SPRN_PWRMGTCR0);
+
+ if (*value)
+ pw20_state |= PWRMGTCR0_PW20_WAIT;
+ else
+ pw20_state = ~PWRMGTCR0_PW20_WAIT;
+
+ mtspr(SPRN_PWRMGTCR0, pw20_state
RE: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20 state and altivec idle
-Original Message-
From: Bhushan Bharat-R65777
Sent: Thursday, October 17, 2013 1:01 AM
To: Wang Dongsheng-B40534; Wood Scott-B07421
Cc: linuxppc-dev@lists.ozlabs.org
Subject: RE: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20 state and
altivec idle
-Original Message-
From: Wang Dongsheng-B40534
Sent: Tuesday, October 15, 2013 2:51 PM
To: Wood Scott-B07421
Cc: Bhushan Bharat-R65777; linuxppc-dev@lists.ozlabs.org; Wang
Dongsheng-B40534
Subject: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20 state and
altivec idle
From: Wang Dongsheng dongsheng.w...@freescale.com
Add a sys interface to enable/diable pw20 state or altivec idle, and
control the
wait entry time.
Enable/Disable interface:
0, disable. 1, enable.
/sys/devices/system/cpu/cpuX/pw20_state
/sys/devices/system/cpu/cpuX/altivec_idle
Set wait time interface:(Nanosecond)
/sys/devices/system/cpu/cpuX/pw20_wait_time
/sys/devices/system/cpu/cpuX/altivec_idle_wait_time
Example: Base on TBfreq is 41MHZ.
1~48(ns): TB[63]
49~97(ns): TB[62]
98~195(ns): TB[61]
196~390(ns): TB[60]
391~780(ns): TB[59]
781~1560(ns): TB[58]
...
Signed-off-by: Wang Dongsheng dongsheng.w...@freescale.com
---
*v5:
Change get_idle_ticks_bit function implementation.
*v4:
Move code from 85xx/common.c to kernel/sysfs.c.
Remove has_pw20_altivec_idle function.
Change wait entry_bit to wait time.
diff --git a/arch/powerpc/kernel/sysfs.c b/arch/powerpc/kernel/sysfs.c
index
27a90b9..10d1128 100644
--- a/arch/powerpc/kernel/sysfs.c
+++ b/arch/powerpc/kernel/sysfs.c
@@ -85,6 +85,284 @@ __setup(smt-snooze-delay=,
setup_smt_snooze_delay);
#endif /* CONFIG_PPC64 */
+#ifdef CONFIG_FSL_SOC
+#define MAX_BIT63
+
+static u64 pw20_wt;
+static u64 altivec_idle_wt;
+
+static unsigned int get_idle_ticks_bit(u64 ns) {
+ u64 cycle;
+
+ if (ns = 1)
+ cycle = div_u64(ns + 500, 1000) * tb_ticks_per_usec;
+ else
+ cycle = div_u64(ns * tb_ticks_per_usec, 1000);
+
+ if (!cycle)
+ return 0;
+
+ return ilog2(cycle);
+}
+
+static void do_show_pwrmgtcr0(void *val) {
+ u32 *value = val;
+
+ *value = mfspr(SPRN_PWRMGTCR0);
+}
+
+static ssize_t show_pw20_state(struct device *dev,
+ struct device_attribute *attr, char *buf) {
+ u32 value;
+ unsigned int cpu = dev-id;
+
+ smp_call_function_single(cpu, do_show_pwrmgtcr0, value, 1);
+
+ value = PWRMGTCR0_PW20_WAIT;
+
+ return sprintf(buf, %u\n, value ? 1 : 0); }
+
+static void do_store_pw20_state(void *val) {
+ u32 *value = val;
+ u32 pw20_state;
+
+ pw20_state = mfspr(SPRN_PWRMGTCR0);
+
+ if (*value)
+ pw20_state |= PWRMGTCR0_PW20_WAIT;
+ else
+ pw20_state = ~PWRMGTCR0_PW20_WAIT;
+
+ mtspr(SPRN_PWRMGTCR0, pw20_state);
+}
+
+static ssize_t store_pw20_state(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+ u32 value;
+ unsigned int cpu = dev-id;
+
+ if (kstrtou32(buf, 0, value))
+ return -EINVAL;
+
+ if (value 1)
+ return -EINVAL;
+
+ smp_call_function_single(cpu, do_store_pw20_state, value, 1);
+
+ return count;
+}
+
+static ssize_t show_pw20_wait_time(struct device *dev,
+ struct device_attribute *attr, char *buf) {
+ u32 value;
+ u64 tb_cycle;
+ s64 time;
+
+ unsigned int cpu = dev-id;
+
+ if (!pw20_wt) {
+ smp_call_function_single(cpu, do_show_pwrmgtcr0, value, 1);
+ value = (value PWRMGTCR0_PW20_ENT)
+ PWRMGTCR0_PW20_ENT_SHIFT;
+
+ tb_cycle = (1 (MAX_BIT - value)) * 2;
Is value = 0 and value = 1 legal? These will make tb_cycle = 0,
+ time = div_u64(tb_cycle * 1000, tb_ticks_per_usec) - 1;
And time = -1;
Please look at the end of the function, :)
return sprintf(buf, %llu\n, time 0 ? time : 0);
-dongsheng
+ } else {
+ time = pw20_wt;
+ }
+
+ return sprintf(buf, %llu\n, time 0 ? time : 0);
}
+
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20 state and altivec idle
-Original Message-
From: Bhushan Bharat-R65777
Sent: Thursday, October 17, 2013 11:20 AM
To: Wang Dongsheng-B40534; Wood Scott-B07421
Cc: linuxppc-dev@lists.ozlabs.org
Subject: RE: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20 state and
altivec idle
-Original Message-
From: Wang Dongsheng-B40534
Sent: Thursday, October 17, 2013 8:16 AM
To: Bhushan Bharat-R65777; Wood Scott-B07421
Cc: linuxppc-dev@lists.ozlabs.org
Subject: RE: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20 state and
altivec idle
-Original Message-
From: Bhushan Bharat-R65777
Sent: Thursday, October 17, 2013 1:01 AM
To: Wang Dongsheng-B40534; Wood Scott-B07421
Cc: linuxppc-dev@lists.ozlabs.org
Subject: RE: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20 state
and altivec idle
-Original Message-
From: Wang Dongsheng-B40534
Sent: Tuesday, October 15, 2013 2:51 PM
To: Wood Scott-B07421
Cc: Bhushan Bharat-R65777; linuxppc-dev@lists.ozlabs.org; Wang
Dongsheng-B40534
Subject: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20 state and
altivec idle
From: Wang Dongsheng dongsheng.w...@freescale.com
Add a sys interface to enable/diable pw20 state or altivec idle,
and
control the
wait entry time.
Enable/Disable interface:
0, disable. 1, enable.
/sys/devices/system/cpu/cpuX/pw20_state
/sys/devices/system/cpu/cpuX/altivec_idle
Set wait time interface:(Nanosecond)
/sys/devices/system/cpu/cpuX/pw20_wait_time
/sys/devices/system/cpu/cpuX/altivec_idle_wait_time
Example: Base on TBfreq is 41MHZ.
1~48(ns): TB[63]
49~97(ns): TB[62]
98~195(ns): TB[61]
196~390(ns): TB[60]
391~780(ns): TB[59]
781~1560(ns): TB[58]
...
Signed-off-by: Wang Dongsheng dongsheng.w...@freescale.com
---
*v5:
Change get_idle_ticks_bit function implementation.
*v4:
Move code from 85xx/common.c to kernel/sysfs.c.
Remove has_pw20_altivec_idle function.
Change wait entry_bit to wait time.
diff --git a/arch/powerpc/kernel/sysfs.c
b/arch/powerpc/kernel/sysfs.c
index
27a90b9..10d1128 100644
--- a/arch/powerpc/kernel/sysfs.c
+++ b/arch/powerpc/kernel/sysfs.c
@@ -85,6 +85,284 @@ __setup(smt-snooze-delay=,
setup_smt_snooze_delay);
#endif /* CONFIG_PPC64 */
+#ifdef CONFIG_FSL_SOC
+#define MAX_BIT63
+
+static u64 pw20_wt;
+static u64 altivec_idle_wt;
+
+static unsigned int get_idle_ticks_bit(u64 ns) {
+ u64 cycle;
+
+ if (ns = 1)
+ cycle = div_u64(ns + 500, 1000) * tb_ticks_per_usec;
+ else
+ cycle = div_u64(ns * tb_ticks_per_usec, 1000);
+
+ if (!cycle)
+ return 0;
+
+ return ilog2(cycle);
+}
+
+static void do_show_pwrmgtcr0(void *val) {
+ u32 *value = val;
+
+ *value = mfspr(SPRN_PWRMGTCR0);
+}
+
+static ssize_t show_pw20_state(struct device *dev,
+ struct device_attribute *attr, char
*buf) {
+ u32 value;
+ unsigned int cpu = dev-id;
+
+ smp_call_function_single(cpu, do_show_pwrmgtcr0, value, 1);
+
+ value = PWRMGTCR0_PW20_WAIT;
+
+ return sprintf(buf, %u\n, value ? 1 : 0); }
+
+static void do_store_pw20_state(void *val) {
+ u32 *value = val;
+ u32 pw20_state;
+
+ pw20_state = mfspr(SPRN_PWRMGTCR0);
+
+ if (*value)
+ pw20_state |= PWRMGTCR0_PW20_WAIT;
+ else
+ pw20_state = ~PWRMGTCR0_PW20_WAIT;
+
+ mtspr(SPRN_PWRMGTCR0, pw20_state); }
+
+static ssize_t store_pw20_state(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t count) {
+ u32 value;
+ unsigned int cpu = dev-id;
+
+ if (kstrtou32(buf, 0, value))
+ return -EINVAL;
+
+ if (value 1)
+ return -EINVAL;
+
+ smp_call_function_single(cpu, do_store_pw20_state, value, 1);
+
+ return count;
+}
+
+static ssize_t show_pw20_wait_time(struct device *dev,
+ struct device_attribute *attr, char
*buf) {
+ u32 value;
+ u64 tb_cycle;
+ s64 time;
+
+ unsigned int cpu = dev-id;
+
+ if (!pw20_wt) {
+ smp_call_function_single(cpu, do_show_pwrmgtcr0, value,
1);
+ value = (value PWRMGTCR0_PW20_ENT)
+ PWRMGTCR0_PW20_ENT_SHIFT;
+
+ tb_cycle = (1 (MAX_BIT - value)) * 2;
Is value = 0 and value
RE: [PATCH v4 4/4] powerpc/85xx: add sysfs for pw20 state and altivec idle
-Original Message- From: Wood Scott-B07421 Sent: Tuesday, October 08, 2013 10:50 PM To: Wang Dongsheng-B40534 Cc: Wood Scott-B07421; Bhushan Bharat-R65777; linuxppc- d...@lists.ozlabs.org Subject: Re: [PATCH v4 4/4] powerpc/85xx: add sysfs for pw20 state and altivec idle On Mon, 2013-10-07 at 22:58 -0500, Wang Dongsheng-B40534 wrote: -Original Message- From: Wood Scott-B07421 Sent: Tuesday, October 01, 2013 7:06 AM To: Wang Dongsheng-B40534 Cc: Wood Scott-B07421; Bhushan Bharat-R65777; linuxppc- d...@lists.ozlabs.org Subject: Re: [PATCH v4 4/4] powerpc/85xx: add sysfs for pw20 state and altivec idle On Sun, 2013-09-29 at 01:57 -0500, Wang Dongsheng-B40534 wrote: I think we need to do this: #define U64_LOW_MASK0xULL #define U64_MASK0xULL u32 tmp_rem; u64 ns_u_rem, ns_u, ns_l, ns_l_carry; u64 cycle; ns_u = ns 32; ns_l = ns U64_LOW_MASK; ns_l *= tb_ticks_per_usec; ns_l_carry = ns_l 32; ns_u *= tb_ticks_per_usec; ns_u += ns_l_carry; ns_u = div_u64_rem(ns_u, 1000, tmp_rem); ns_u_rem = tmp_rem; ns_l = (ns_l U64_LOW_MASK) | ((ns_u_rem) 32); ns_l = div_u64(ns_l, 1000); if (ns_u 32) cycle = U64_MASK; else cycle = (ns_u 32) | (ns_l U64_LOW_MASK); I has already tested this code, and works good. :) Ugh. I don't think we need to get this complicated (and I'd rather not spend the time verifying the correctness of this). If for some reason we did need something like this in some other context (I don't want to see it just for pw20), I'd be more inclined to see general 128-bit mult/divide support. I would like to use my version,:), because it can handle any situation and we do not need to restrict users. It also would take more time to review than I have to spend on it, not to mention the impact on anyone in the future that wants to understand or maintain this code -- all for very unlikely situations (and the failure in those very unlikely situations is just that we go into PW20 more often than intended). OK, I will use your verison, :) if (ns = 1) cycle = ((ns + 500) / 1000) * tb_ticks_per_usec; else cycle = div_u64((u64)ns * tb_ticks_per_usec, 1000); -dongsheng -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH v4 4/4] powerpc/85xx: add sysfs for pw20 state and altivec idle
-Original Message- From: Wood Scott-B07421 Sent: Tuesday, October 01, 2013 7:06 AM To: Wang Dongsheng-B40534 Cc: Wood Scott-B07421; Bhushan Bharat-R65777; linuxppc- d...@lists.ozlabs.org Subject: Re: [PATCH v4 4/4] powerpc/85xx: add sysfs for pw20 state and altivec idle On Sun, 2013-09-29 at 01:57 -0500, Wang Dongsheng-B40534 wrote: -Original Message- From: Wood Scott-B07421 Sent: Saturday, September 28, 2013 5:33 AM To: Wang Dongsheng-B40534 Cc: Wood Scott-B07421; Bhushan Bharat-R65777; linuxppc- d...@lists.ozlabs.org Subject: Re: [PATCH v4 4/4] powerpc/85xx: add sysfs for pw20 state and altivec idle On Thu, 2013-09-26 at 22:34 -0500, Wang Dongsheng-B40534 wrote: cycle = div_u64(ns * tb_ticks_per_usec, 1000); It's look good. But why we need: if (ns = 1) cycle = ((ns + 500) / 1000) * tb_ticks_per_usec; ? I think cycle = div_u64(ns * tb_ticks_per_usec, 1000) is good enough. :) It's to deal with overflow if a very large value of ns is provided (and/or tb_ticks_per_usec is larger than we expect). :), as I think, it's to deal with overflow. But you version cannot do deal with it. Because ns is u64, if ns 0x_fe0b, ns + 500 will overflow, And if tb_ticks_per_usec 1000 and ns (0x_ / 10) cycle also will overflow. Sigh... It significantly increases the value of ns at which you'll get overflow problems. :-) I was more concerned with large-but-somewhat- reasonable values of ns (e.g. than with trying to handle every possible input. Even without that test, getting overflow is stretching the bounds of reasonableness (e.g. a 1 GHz timebase would require a timeout of over 7 months to overflow), but it was low-hanging fruit. And the worst case is we go to pw20 sooner than the user wanted, so let's not go too overboard. I doubt you would see 0x_fe0b except if someone is trying to disable it by setting 0x_ even though a separate API is provided to cleanly disable it. I think we need to do this: #define U64_LOW_MASK0xULL #define U64_MASK0xULL u32 tmp_rem; u64 ns_u_rem, ns_u, ns_l, ns_l_carry; u64 cycle; ns_u = ns 32; ns_l = ns U64_LOW_MASK; ns_l *= tb_ticks_per_usec; ns_l_carry = ns_l 32; ns_u *= tb_ticks_per_usec; ns_u += ns_l_carry; ns_u = div_u64_rem(ns_u, 1000, tmp_rem); ns_u_rem = tmp_rem; ns_l = (ns_l U64_LOW_MASK) | ((ns_u_rem) 32); ns_l = div_u64(ns_l, 1000); if (ns_u 32) cycle = U64_MASK; else cycle = (ns_u 32) | (ns_l U64_LOW_MASK); I has already tested this code, and works good. :) Ugh. I don't think we need to get this complicated (and I'd rather not spend the time verifying the correctness of this). If for some reason we did need something like this in some other context (I don't want to see it just for pw20), I'd be more inclined to see general 128-bit mult/divide support. I would like to use my version,:), because it can handle any situation and we do not need to restrict users. Here is a kind of special way to get the cycle. If this 128-bit situation is more and more, at that time we go to support it. -dongsheng -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH v4 4/4] powerpc/85xx: add sysfs for pw20 state and altivec idle
-Original Message-
From: Wood Scott-B07421
Sent: Saturday, September 28, 2013 5:33 AM
To: Wang Dongsheng-B40534
Cc: Wood Scott-B07421; Bhushan Bharat-R65777; linuxppc-
d...@lists.ozlabs.org
Subject: Re: [PATCH v4 4/4] powerpc/85xx: add sysfs for pw20 state and
altivec idle
On Thu, 2013-09-26 at 22:34 -0500, Wang Dongsheng-B40534 wrote:
-Original Message-
From: Wood Scott-B07421
Sent: Friday, September 27, 2013 5:37 AM
To: Wang Dongsheng-B40534
Cc: Bhushan Bharat-R65777; Wood Scott-B07421; linuxppc-
d...@lists.ozlabs.org
Subject: Re: [PATCH v4 4/4] powerpc/85xx: add sysfs for pw20 state
and altivec idle
On Thu, 2013-09-26 at 01:18 -0500, Wang Dongsheng-B40534 wrote:
-Original Message-
From: Bhushan Bharat-R65777
Sent: Thursday, September 26, 2013 12:23 PM
To: Wang Dongsheng-B40534; Wood Scott-B07421
Cc: linuxppc-dev@lists.ozlabs.org
Subject: RE: [PATCH v4 4/4] powerpc/85xx: add sysfs for pw20
state and altivec idle
-Original Message-
From: Wang Dongsheng-B40534
Sent: Thursday, September 26, 2013 8:02 AM
To: Wood Scott-B07421
Cc: Bhushan Bharat-R65777; linuxppc-dev@lists.ozlabs.org
Subject: RE: [PATCH v4 4/4] powerpc/85xx: add sysfs for pw20
state and altivec idle
-Original Message-
From: Wood Scott-B07421
Sent: Thursday, September 26, 2013 1:57 AM
To: Wang Dongsheng-B40534
Cc: Bhushan Bharat-R65777; Wood Scott-B07421; linuxppc-
d...@lists.ozlabs.org
Subject: Re: [PATCH v4 4/4] powerpc/85xx: add sysfs for pw20
state and altivec idle
On Wed, 2013-09-25 at 03:10 -0500, Wang Dongsheng-B40534
wrote:
-Original Message-
From: Bhushan Bharat-R65777
Sent: Wednesday, September 25, 2013 2:23 PM
To: Wang Dongsheng-B40534; Wood Scott-B07421
Cc: linuxppc-dev@lists.ozlabs.org; Wang Dongsheng-B40534
Subject: RE: [PATCH v4 4/4] powerpc/85xx: add sysfs for
pw20 state and altivec idle
-Original Message-
From: Linuxppc-dev [mailto:linuxppc-dev-
bounces+bharat.bhushan=freescale@lists.ozlabs.org]
bounces+On Behalf Of Dongsheng
Wang
Sent: Tuesday, September 24, 2013 2:59 PM
To: Wood Scott-B07421
Cc: linuxppc-dev@lists.ozlabs.org; Wang
Dongsheng-B40534
Subject: [PATCH v4 4/4] powerpc/85xx: add sysfs for
pw20 state and altivec idle
From: Wang Dongsheng dongsheng.w...@freescale.com
Add a sys interface to enable/diable pw20 state or
altivec idle, and control the wait entry time.
Enable/Disable interface:
0, disable. 1, enable.
/sys/devices/system/cpu/cpuX/pw20_state
/sys/devices/system/cpu/cpuX/altivec_idle
Set wait time interface:(Nanosecond)
/sys/devices/system/cpu/cpuX/pw20_wait_time
/sys/devices/system/cpu/cpuX/altivec_idle_wait_time
Example: Base on TBfreq is 41MHZ.
1~47(ns): TB[63]
48~95(ns): TB[62]
96~191(ns): TB[61]
192~383(ns): TB[62]
384~767(ns): TB[60]
...
Signed-off-by: Wang Dongsheng
dongsheng.w...@freescale.com
---
*v4:
Move code from 85xx/common.c to kernel/sysfs.c.
Remove has_pw20_altivec_idle function.
Change wait entry_bit to wait time.
arch/powerpc/kernel/sysfs.c | 291
1 file changed, 291 insertions(+)
diff --git a/arch/powerpc/kernel/sysfs.c
b/arch/powerpc/kernel/sysfs.c index 27a90b9..23fece6
100644
--- a/arch/powerpc/kernel/sysfs.c
+++ b/arch/powerpc/kernel/sysfs.c
@@ -85,6 +85,279 @@ __setup(smt-snooze-delay=,
setup_smt_snooze_delay);
#endif /* CONFIG_PPC64 */
+#ifdef CONFIG_FSL_SOC
+#define MAX_BIT63
+
+static u64 pw20_wt;
+static u64 altivec_idle_wt;
+
+static unsigned int get_idle_ticks_bit(u64 ns) {
+ u64 cycle;
+
+ cycle = div_u64(ns, 1000 / tb_ticks_per_usec);
When tb_ticks_per_usec 1000 (timebase frequency
1GHz) then this will always be ns, which is not correct,
no?
Actually it'll be a divide by zero in that case.
tb_ticks_per_usec = ppc_tb_freq / 100; Means TB freq
should be more than 1MHZ.
if ppc_tb_freq less than 100, the tb_ticks_per_usec will
be a divide by zero.
If this condition is established, I think
RE: [PATCH v4 4/4] powerpc/85xx: add sysfs for pw20 state and altivec idle
-Original Message-
From: Bhushan Bharat-R65777
Sent: Thursday, September 26, 2013 12:23 PM
To: Wang Dongsheng-B40534; Wood Scott-B07421
Cc: linuxppc-dev@lists.ozlabs.org
Subject: RE: [PATCH v4 4/4] powerpc/85xx: add sysfs for pw20 state and
altivec idle
-Original Message-
From: Wang Dongsheng-B40534
Sent: Thursday, September 26, 2013 8:02 AM
To: Wood Scott-B07421
Cc: Bhushan Bharat-R65777; linuxppc-dev@lists.ozlabs.org
Subject: RE: [PATCH v4 4/4] powerpc/85xx: add sysfs for pw20 state and
altivec idle
-Original Message-
From: Wood Scott-B07421
Sent: Thursday, September 26, 2013 1:57 AM
To: Wang Dongsheng-B40534
Cc: Bhushan Bharat-R65777; Wood Scott-B07421; linuxppc-
d...@lists.ozlabs.org
Subject: Re: [PATCH v4 4/4] powerpc/85xx: add sysfs for pw20 state
and altivec idle
On Wed, 2013-09-25 at 03:10 -0500, Wang Dongsheng-B40534 wrote:
-Original Message-
From: Bhushan Bharat-R65777
Sent: Wednesday, September 25, 2013 2:23 PM
To: Wang Dongsheng-B40534; Wood Scott-B07421
Cc: linuxppc-dev@lists.ozlabs.org; Wang Dongsheng-B40534
Subject: RE: [PATCH v4 4/4] powerpc/85xx: add sysfs for pw20
state and altivec idle
-Original Message-
From: Linuxppc-dev [mailto:linuxppc-dev-
bounces+bharat.bhushan=freescale@lists.ozlabs.org] On
bounces+Behalf Of Dongsheng
Wang
Sent: Tuesday, September 24, 2013 2:59 PM
To: Wood Scott-B07421
Cc: linuxppc-dev@lists.ozlabs.org; Wang Dongsheng-B40534
Subject: [PATCH v4 4/4] powerpc/85xx: add sysfs for pw20 state
and altivec idle
From: Wang Dongsheng dongsheng.w...@freescale.com
Add a sys interface to enable/diable pw20 state or altivec
idle, and control the wait entry time.
Enable/Disable interface:
0, disable. 1, enable.
/sys/devices/system/cpu/cpuX/pw20_state
/sys/devices/system/cpu/cpuX/altivec_idle
Set wait time interface:(Nanosecond)
/sys/devices/system/cpu/cpuX/pw20_wait_time
/sys/devices/system/cpu/cpuX/altivec_idle_wait_time
Example: Base on TBfreq is 41MHZ.
1~47(ns): TB[63]
48~95(ns): TB[62]
96~191(ns): TB[61]
192~383(ns): TB[62]
384~767(ns): TB[60]
...
Signed-off-by: Wang Dongsheng dongsheng.w...@freescale.com
---
*v4:
Move code from 85xx/common.c to kernel/sysfs.c.
Remove has_pw20_altivec_idle function.
Change wait entry_bit to wait time.
arch/powerpc/kernel/sysfs.c | 291
1 file changed, 291 insertions(+)
diff --git a/arch/powerpc/kernel/sysfs.c
b/arch/powerpc/kernel/sysfs.c index 27a90b9..23fece6 100644
--- a/arch/powerpc/kernel/sysfs.c
+++ b/arch/powerpc/kernel/sysfs.c
@@ -85,6 +85,279 @@ __setup(smt-snooze-delay=,
setup_smt_snooze_delay);
#endif /* CONFIG_PPC64 */
+#ifdef CONFIG_FSL_SOC
+#define MAX_BIT63
+
+static u64 pw20_wt;
+static u64 altivec_idle_wt;
+
+static unsigned int get_idle_ticks_bit(u64 ns) {
+ u64 cycle;
+
+ cycle = div_u64(ns, 1000 / tb_ticks_per_usec);
When tb_ticks_per_usec 1000 (timebase frequency 1GHz) then
this will always be ns, which is not correct, no?
Actually it'll be a divide by zero in that case.
tb_ticks_per_usec = ppc_tb_freq / 100; Means TB freq should be
more than 1MHZ.
if ppc_tb_freq less than 100, the tb_ticks_per_usec will be a
divide by zero.
If this condition is established, I think kernel cannot work as a
normal.
So I think we need to believe that the variable is not zero.
We do believe it is non-zero but greater than 1000 :)
And I think TB freq
should not less than 1MHZ on PPC platform, because if TB freq less
than 1MHZ, the precision time will become very poor and system
response time will be slower.
Not sure what you are describing here related to divide by zero we are
mentioning.
You are talking about if tb_ticks_per_usec is ZERO and we are talking
about if (1000/tb_ticks_per_usec) will be zero.
BTW, div_u64() handle the case where divider is zero.
cycle = div_u64(ns, 1000 / tb_ticks_per_usec);
For this, I think we were discussing the two issues:
1. Scott talking about, when the tb_ticks_per_usec is a zero.
This situation is about tb_ticks_per_usec, and possible to zero. So I answered
Scott.
If I misunderstand scott, please ignore it. :)
2. You are talking about 1000/tb_ticks_per_usec is a zero.
This situation is about TB freq 1GHZ.
I will fix this issue. Like I said before,
If timebase frequency 1GHz, this should be tb_ticks_per_usec / 1000 and to
get tb_ticks_per_nsec.
This should be changed to cycle = ns * tb_ticks_per_nsec;
#define TB_FREQ_1GHZ
RE: [PATCH v4 4/4] powerpc/85xx: add sysfs for pw20 state and altivec idle
-Original Message-
From: Wood Scott-B07421
Sent: Friday, September 27, 2013 5:37 AM
To: Wang Dongsheng-B40534
Cc: Bhushan Bharat-R65777; Wood Scott-B07421; linuxppc-
d...@lists.ozlabs.org
Subject: Re: [PATCH v4 4/4] powerpc/85xx: add sysfs for pw20 state and
altivec idle
On Thu, 2013-09-26 at 01:18 -0500, Wang Dongsheng-B40534 wrote:
-Original Message-
From: Bhushan Bharat-R65777
Sent: Thursday, September 26, 2013 12:23 PM
To: Wang Dongsheng-B40534; Wood Scott-B07421
Cc: linuxppc-dev@lists.ozlabs.org
Subject: RE: [PATCH v4 4/4] powerpc/85xx: add sysfs for pw20 state
and altivec idle
-Original Message-
From: Wang Dongsheng-B40534
Sent: Thursday, September 26, 2013 8:02 AM
To: Wood Scott-B07421
Cc: Bhushan Bharat-R65777; linuxppc-dev@lists.ozlabs.org
Subject: RE: [PATCH v4 4/4] powerpc/85xx: add sysfs for pw20 state
and altivec idle
-Original Message-
From: Wood Scott-B07421
Sent: Thursday, September 26, 2013 1:57 AM
To: Wang Dongsheng-B40534
Cc: Bhushan Bharat-R65777; Wood Scott-B07421; linuxppc-
d...@lists.ozlabs.org
Subject: Re: [PATCH v4 4/4] powerpc/85xx: add sysfs for pw20
state and altivec idle
On Wed, 2013-09-25 at 03:10 -0500, Wang Dongsheng-B40534 wrote:
-Original Message-
From: Bhushan Bharat-R65777
Sent: Wednesday, September 25, 2013 2:23 PM
To: Wang Dongsheng-B40534; Wood Scott-B07421
Cc: linuxppc-dev@lists.ozlabs.org; Wang Dongsheng-B40534
Subject: RE: [PATCH v4 4/4] powerpc/85xx: add sysfs for pw20
state and altivec idle
-Original Message-
From: Linuxppc-dev [mailto:linuxppc-dev-
bounces+bharat.bhushan=freescale@lists.ozlabs.org] On
bounces+Behalf Of Dongsheng
Wang
Sent: Tuesday, September 24, 2013 2:59 PM
To: Wood Scott-B07421
Cc: linuxppc-dev@lists.ozlabs.org; Wang Dongsheng-B40534
Subject: [PATCH v4 4/4] powerpc/85xx: add sysfs for pw20
state and altivec idle
From: Wang Dongsheng dongsheng.w...@freescale.com
Add a sys interface to enable/diable pw20 state or altivec
idle, and control the wait entry time.
Enable/Disable interface:
0, disable. 1, enable.
/sys/devices/system/cpu/cpuX/pw20_state
/sys/devices/system/cpu/cpuX/altivec_idle
Set wait time interface:(Nanosecond)
/sys/devices/system/cpu/cpuX/pw20_wait_time
/sys/devices/system/cpu/cpuX/altivec_idle_wait_time
Example: Base on TBfreq is 41MHZ.
1~47(ns): TB[63]
48~95(ns): TB[62]
96~191(ns): TB[61]
192~383(ns): TB[62]
384~767(ns): TB[60]
...
Signed-off-by: Wang Dongsheng
dongsheng.w...@freescale.com
---
*v4:
Move code from 85xx/common.c to kernel/sysfs.c.
Remove has_pw20_altivec_idle function.
Change wait entry_bit to wait time.
arch/powerpc/kernel/sysfs.c | 291
1 file changed, 291 insertions(+)
diff --git a/arch/powerpc/kernel/sysfs.c
b/arch/powerpc/kernel/sysfs.c index 27a90b9..23fece6
100644
--- a/arch/powerpc/kernel/sysfs.c
+++ b/arch/powerpc/kernel/sysfs.c
@@ -85,6 +85,279 @@ __setup(smt-snooze-delay=,
setup_smt_snooze_delay);
#endif /* CONFIG_PPC64 */
+#ifdef CONFIG_FSL_SOC
+#define MAX_BIT63
+
+static u64 pw20_wt;
+static u64 altivec_idle_wt;
+
+static unsigned int get_idle_ticks_bit(u64 ns) {
+ u64 cycle;
+
+ cycle = div_u64(ns, 1000 / tb_ticks_per_usec);
When tb_ticks_per_usec 1000 (timebase frequency 1GHz)
then this will always be ns, which is not correct, no?
Actually it'll be a divide by zero in that case.
tb_ticks_per_usec = ppc_tb_freq / 100; Means TB freq should be
more than 1MHZ.
if ppc_tb_freq less than 100, the tb_ticks_per_usec will be a
divide by zero.
If this condition is established, I think kernel cannot work as a
normal.
So I think we need to believe that the variable is not zero.
We do believe it is non-zero but greater than 1000 :)
And I think TB freq
should not less than 1MHZ on PPC platform, because if TB freq less
than 1MHZ, the precision time will become very poor and system
response time will be slower.
Not sure what you are describing here related to divide by zero we
are mentioning.
You are talking about if tb_ticks_per_usec is ZERO and we are
talking about if (1000/tb_ticks_per_usec) will be zero.
BTW, div_u64() handle the case
RE: [PATCH v4 4/4] powerpc/85xx: add sysfs for pw20 state and altivec idle
-Original Message-
From: Bhushan Bharat-R65777
Sent: Wednesday, September 25, 2013 2:23 PM
To: Wang Dongsheng-B40534; Wood Scott-B07421
Cc: linuxppc-dev@lists.ozlabs.org; Wang Dongsheng-B40534
Subject: RE: [PATCH v4 4/4] powerpc/85xx: add sysfs for pw20 state and
altivec idle
-Original Message-
From: Linuxppc-dev [mailto:linuxppc-dev-
bounces+bharat.bhushan=freescale@lists.ozlabs.org] On Behalf Of
bounces+Dongsheng
Wang
Sent: Tuesday, September 24, 2013 2:59 PM
To: Wood Scott-B07421
Cc: linuxppc-dev@lists.ozlabs.org; Wang Dongsheng-B40534
Subject: [PATCH v4 4/4] powerpc/85xx: add sysfs for pw20 state and
altivec idle
From: Wang Dongsheng dongsheng.w...@freescale.com
Add a sys interface to enable/diable pw20 state or altivec idle, and
control the wait entry time.
Enable/Disable interface:
0, disable. 1, enable.
/sys/devices/system/cpu/cpuX/pw20_state
/sys/devices/system/cpu/cpuX/altivec_idle
Set wait time interface:(Nanosecond)
/sys/devices/system/cpu/cpuX/pw20_wait_time
/sys/devices/system/cpu/cpuX/altivec_idle_wait_time
Example: Base on TBfreq is 41MHZ.
1~47(ns): TB[63]
48~95(ns): TB[62]
96~191(ns): TB[61]
192~383(ns): TB[62]
384~767(ns): TB[60]
...
Signed-off-by: Wang Dongsheng dongsheng.w...@freescale.com
---
*v4:
Move code from 85xx/common.c to kernel/sysfs.c.
Remove has_pw20_altivec_idle function.
Change wait entry_bit to wait time.
arch/powerpc/kernel/sysfs.c | 291
1 file changed, 291 insertions(+)
diff --git a/arch/powerpc/kernel/sysfs.c b/arch/powerpc/kernel/sysfs.c
index 27a90b9..23fece6 100644
--- a/arch/powerpc/kernel/sysfs.c
+++ b/arch/powerpc/kernel/sysfs.c
@@ -85,6 +85,279 @@ __setup(smt-snooze-delay=,
setup_smt_snooze_delay);
#endif /* CONFIG_PPC64 */
+#ifdef CONFIG_FSL_SOC
+#define MAX_BIT63
+
+static u64 pw20_wt;
+static u64 altivec_idle_wt;
+
+static unsigned int get_idle_ticks_bit(u64 ns) {
+ u64 cycle;
+
+ cycle = div_u64(ns, 1000 / tb_ticks_per_usec);
When tb_ticks_per_usec 1000 (timebase frequency 1GHz) then this will
always be ns, which is not correct, no?
1000 / tb_ticks_per_usec means nsec_ticks_per_tb
If timebase frequency 1GHz, this should be tb_ticks_per_usec / 1000 and to
get tb_ticks_per_nsec.
This should be changed to cycle = ns * tb_ticks_per_nsec;
But at present we do not have such a platform that timebase frequency more than
1GHz. And I think it is not need to support such a situation. Because we have
no environment to test it.
If later there will be more than 1GHZ platform at that time to add this support.
Thanks.
-dongsheng
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH v4 4/4] powerpc/85xx: add sysfs for pw20 state and altivec idle
-Original Message-
From: Wood Scott-B07421
Sent: Thursday, September 26, 2013 1:57 AM
To: Wang Dongsheng-B40534
Cc: Bhushan Bharat-R65777; Wood Scott-B07421; linuxppc-
d...@lists.ozlabs.org
Subject: Re: [PATCH v4 4/4] powerpc/85xx: add sysfs for pw20 state and
altivec idle
On Wed, 2013-09-25 at 03:10 -0500, Wang Dongsheng-B40534 wrote:
-Original Message-
From: Bhushan Bharat-R65777
Sent: Wednesday, September 25, 2013 2:23 PM
To: Wang Dongsheng-B40534; Wood Scott-B07421
Cc: linuxppc-dev@lists.ozlabs.org; Wang Dongsheng-B40534
Subject: RE: [PATCH v4 4/4] powerpc/85xx: add sysfs for pw20 state
and altivec idle
-Original Message-
From: Linuxppc-dev [mailto:linuxppc-dev-
bounces+bharat.bhushan=freescale@lists.ozlabs.org] On Behalf
bounces+Of Dongsheng
Wang
Sent: Tuesday, September 24, 2013 2:59 PM
To: Wood Scott-B07421
Cc: linuxppc-dev@lists.ozlabs.org; Wang Dongsheng-B40534
Subject: [PATCH v4 4/4] powerpc/85xx: add sysfs for pw20 state and
altivec idle
From: Wang Dongsheng dongsheng.w...@freescale.com
Add a sys interface to enable/diable pw20 state or altivec idle,
and control the wait entry time.
Enable/Disable interface:
0, disable. 1, enable.
/sys/devices/system/cpu/cpuX/pw20_state
/sys/devices/system/cpu/cpuX/altivec_idle
Set wait time interface:(Nanosecond)
/sys/devices/system/cpu/cpuX/pw20_wait_time
/sys/devices/system/cpu/cpuX/altivec_idle_wait_time
Example: Base on TBfreq is 41MHZ.
1~47(ns): TB[63]
48~95(ns): TB[62]
96~191(ns): TB[61]
192~383(ns): TB[62]
384~767(ns): TB[60]
...
Signed-off-by: Wang Dongsheng dongsheng.w...@freescale.com
---
*v4:
Move code from 85xx/common.c to kernel/sysfs.c.
Remove has_pw20_altivec_idle function.
Change wait entry_bit to wait time.
arch/powerpc/kernel/sysfs.c | 291
1 file changed, 291 insertions(+)
diff --git a/arch/powerpc/kernel/sysfs.c
b/arch/powerpc/kernel/sysfs.c index 27a90b9..23fece6 100644
--- a/arch/powerpc/kernel/sysfs.c
+++ b/arch/powerpc/kernel/sysfs.c
@@ -85,6 +85,279 @@ __setup(smt-snooze-delay=,
setup_smt_snooze_delay);
#endif /* CONFIG_PPC64 */
+#ifdef CONFIG_FSL_SOC
+#define MAX_BIT63
+
+static u64 pw20_wt;
+static u64 altivec_idle_wt;
+
+static unsigned int get_idle_ticks_bit(u64 ns) {
+ u64 cycle;
+
+ cycle = div_u64(ns, 1000 / tb_ticks_per_usec);
When tb_ticks_per_usec 1000 (timebase frequency 1GHz) then this
will always be ns, which is not correct, no?
Actually it'll be a divide by zero in that case.
tb_ticks_per_usec = ppc_tb_freq / 100; Means TB freq should be more than
1MHZ.
if ppc_tb_freq less than 100, the tb_ticks_per_usec will be a divide by
zero.
If this condition is established, I think kernel cannot work as a normal.
So I think we need to believe that the variable is not zero. And I think TB
freq should not less than 1MHZ on PPC platform, because if TB freq less than
1MHZ, the precision time will become very poor and system response time will be
slower.
1000 / tb_ticks_per_usec means nsec_ticks_per_tb
If timebase frequency 1GHz, this should be tb_ticks_per_usec / 1000
and to get tb_ticks_per_nsec.
This should be changed to cycle = ns * tb_ticks_per_nsec;
But at present we do not have such a platform that timebase frequency
more than 1GHz. And I think it is not need to support such a situation.
Because we have no environment to test it.
You can test it by hacking a wrong timebase frequency in and seeing what
the calculation does.
Or do something like this:
if (ns = 1)
cycle = ((ns + 500) / 1000) * tb_ticks_per_usec;
else
cycle = div_u64((u64)ns * tb_ticks_per_usec, 1000);
We cannot do this, because if (ns+500) 1000, we cannot get the entry bit,
it'll always zero bit.
We must to use per_nsec_tb_ticks, like my code 1000 / tb_ticks_per_usec.
...which can be tested just by varying ns.
If later there will be more than 1GHZ platform at that time to add this
support.
Yes, I agree this point. :)
-dongsheng
There almost certainly won't be timebases that run that fast, but divide
by zero is a rather nasty way of responding if such a thing does happen.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH v4 1/4] powerpc/fsl: add E6500 PVR and SPRN_PWRMGTCR0 define
/* * For the 8xx processors, all of them report the same PVR family for * the PowerPC core. The various versions of these processors must be diff -- git a/arch/powerpc/include/asm/reg_booke.h b/arch/powerpc/include/asm/reg_booke.h index ed8f836..4a6457e 100644 --- a/arch/powerpc/include/asm/reg_booke.h +++ b/arch/powerpc/include/asm/reg_booke.h @@ -170,6 +170,7 @@ #define SPRN_L2CSR10x3FA /* L2 Data Cache Control and Status Register 1 */ #define SPRN_DCCR 0x3FA /* Data Cache Cacheability Register */ #define SPRN_ICCR 0x3FB /* Instruction Cache Cacheability Register */ +#define SPRN_PWRMGTCR00x3FB /* Power management control register 0 */ Is this generic for booke or e6500 specific? I can't see this register either in ISA and EREF. Yes, now only e6500 have this register. There is no problem in this definition, because no conflict in FSL platform. Also I can see SPRN_ICCR also with same SPRN, how that is possible? Its possibly because the register maybe in implementation specific region. I'm guessing ICCR is a 40x specific register. Yes, kumar is right. Its use only in 4xx series of chips. ICTC(arch/powerpc/include/asm/reg.h) also use 0x3FB, Its use only in 6xx series of chips. -dongsheng ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH v4 1/4] powerpc/fsl: add E6500 PVR and SPRN_PWRMGTCR0 define
-Original Message- From: Bhushan Bharat-R65777 Sent: Wednesday, September 25, 2013 11:43 AM To: Kumar Gala Cc: Wang Dongsheng-B40534; Wood Scott-B07421; linuxppc- d...@lists.ozlabs.org Subject: RE: [PATCH v4 1/4] powerpc/fsl: add E6500 PVR and SPRN_PWRMGTCR0 define -Original Message- From: Kumar Gala [mailto:ga...@kernel.crashing.org] Sent: Tuesday, September 24, 2013 9:19 PM To: Bhushan Bharat-R65777 Cc: Wang Dongsheng-B40534; Wood Scott-B07421; linuxppc-dev@lists.ozlabs.org Subject: Re: [PATCH v4 1/4] powerpc/fsl: add E6500 PVR and SPRN_PWRMGTCR0 define On Sep 24, 2013, at 6:21 AM, Bhushan Bharat-R65777 wrote: -Original Message- From: Linuxppc-dev [mailto:linuxppc-dev- bounces+bharat.bhushan=freescale@lists.ozlabs.org] On Behalf Of bounces+Dongsheng Wang Sent: Tuesday, September 24, 2013 2:58 PM To: Wood Scott-B07421 Cc: linuxppc-dev@lists.ozlabs.org; Wang Dongsheng-B40534 Subject: [PATCH v4 1/4] powerpc/fsl: add E6500 PVR and SPRN_PWRMGTCR0 define From: Wang Dongsheng dongsheng.w...@freescale.com E6500 PVR and SPRN_PWRMGTCR0 will be used in subsequent pw20/altivec idle patches. Signed-off-by: Wang Dongsheng dongsheng.w...@freescale.com --- *v3: Add bit definitions for PWRMGTCR0. arch/powerpc/include/asm/reg.h | 2 ++ arch/powerpc/include/asm/reg_booke.h | 9 + 2 files changed, 11 insertions(+) diff --git a/arch/powerpc/include/asm/reg.h b/arch/powerpc/include/asm/reg.h index 64264bf..d4160ca 100644 --- a/arch/powerpc/include/asm/reg.h +++ b/arch/powerpc/include/asm/reg.h @@ -1053,6 +1053,8 @@ #define PVR_8560 0x8020 #define PVR_VER_E500V1 0x8020 #define PVR_VER_E500V2 0x8021 +#define PVR_VER_E6500 0x8040 + /* * For the 8xx processors, all of them report the same PVR family for * the PowerPC core. The various versions of these processors must be diff -- git a/arch/powerpc/include/asm/reg_booke.h b/arch/powerpc/include/asm/reg_booke.h index ed8f836..4a6457e 100644 --- a/arch/powerpc/include/asm/reg_booke.h +++ b/arch/powerpc/include/asm/reg_booke.h @@ -170,6 +170,7 @@ #define SPRN_L2CSR1 0x3FA /* L2 Data Cache Control and Status Register 1 */ #define SPRN_DCCR0x3FA /* Data Cache Cacheability Register */ #define SPRN_ICCR0x3FB /* Instruction Cache Cacheability Register */ +#define SPRN_PWRMGTCR0 0x3FB /* Power management control register 0 */ Is this generic for booke or e6500 specific? I can't see this register either in ISA and EREF. Also I can see SPRN_ICCR also with same SPRN, how that is possible? Its possibly because the register maybe in implementation specific region. I'm guessing ICCR is a 40x specific register. Kumar, this seems to create confusion? I don't think this define will create a confusion, because this is only SPR number definition and we already have a document(like EREF, ISA, this register define in E6500-EREF) to describe these registers. There are no conflicts and other platform and different platforms for the same register have different purposes, it looks normal. Instead we should put together, so as to remind that the SPR will be reuse from other platforms. -dongsheng ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH v3 4/4] powerpc/85xx: add sysfs for pw20 state and altivec idle
-Original Message- From: Wood Scott-B07421 Sent: Tuesday, September 17, 2013 5:09 AM To: Wang Dongsheng-B40534 Cc: Wood Scott-B07421; ga...@kernel.crashing.org; linuxppc- d...@lists.ozlabs.org Subject: Re: [PATCH v3 4/4] powerpc/85xx: add sysfs for pw20 state and altivec idle On Thu, 2013-09-12 at 21:53 -0500, Wang Dongsheng-B40534 wrote: -Original Message- From: Wood Scott-B07421 Sent: Friday, September 13, 2013 2:07 AM To: Wang Dongsheng-B40534 Cc: Wood Scott-B07421; ga...@kernel.crashing.org; linuxppc- d...@lists.ozlabs.org Subject: Re: [PATCH v3 4/4] powerpc/85xx: add sysfs for pw20 state and altivec idle On Wed, 2013-09-11 at 22:48 -0500, Wang Dongsheng-B40534 wrote: -Original Message- From: Wood Scott-B07421 Sent: Thursday, September 12, 2013 7:04 AM To: Wang Dongsheng-B40534 Cc: ga...@kernel.crashing.org; linuxppc-dev@lists.ozlabs.org Subject: Re: [PATCH v3 4/4] powerpc/85xx: add sysfs for pw20 state and altivec idle On Wed, 2013-09-11 at 13:56 +0800, Dongsheng Wang wrote: From: Wang Dongsheng dongsheng.w...@freescale.com Add a sys interface to enable/diable pw20 state or altivec idle, and control the wait entry time. Enable/Disable interface: 0, disable. 1, enable. /sys/devices/system/cpu/cpuX/pw20_state /sys/devices/system/cpu/cpuX/altivec_idle Set wait entry bit interface: bit value range 0~63, 0 bit is Mintime, 63 bit is Maxtime. /sys/devices/system/cpu/cpuX/pw20_wait_entry_bit /sys/devices/system/cpu/cpuX/altivec_idle_wait_entry_bit I'm no fan of the way powerpc does bit numbering, but don't flip it around here -- you'll just cause confusion. OK. 0 bit is maxtime, 63 bit is mintime. Better yet, this interface should take real time units rather than a timebase bit. I think the real time is not suitable, because timebase bit does not correspond with real time. It's a bit sloppy due to how the hardware works, but you could convert it like you did in earlier patches. Semantically it should probably be the minimum time to wait before entering the low power state. But there has a problem, we can't convert bit to the real time when user read this sysfs. Like: echo 1000(us) /sys/*/pw20_wait_entry_bit, after convert we get bit is 49. cat /sys/*/pw20_wait_entry_bit, after convert the time is 1598(us). The read out of the time is not real time. Unless we define a variable to save the real time. It's not the end of the world if the value is different when read back. It just gets rounded up when you write it. Ok, make a variable to save it. Also, you disable the power saving mode if the maximum interval is selected, It's not disable the pw20 state or altivec idle, just max-delay entry time. No, the code checks for zero to set or clear the enabling bit (e.g. PW20_WAIT). There has pw20_state/altivec_idle sys interface to control enable/disable, There is only to control wait bit. Did you mean remove pw20_state/altivec_idle sys interface, and reuse pw20_wait_entry_bit/altivec_idle* sys interface? When echo zero into pw20_wait_entry_bit we just to disable pw20 state, I think that is reasonable. :) Sorry, I misread the patch and didn't realize these were separate interfaces. Keep the pw20_state/altivec_idle interfaces. -dongsheng ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH v3 4/4] powerpc/85xx: add sysfs for pw20 state and altivec idle
-Original Message- From: Wood Scott-B07421 Sent: Friday, September 13, 2013 2:07 AM To: Wang Dongsheng-B40534 Cc: Wood Scott-B07421; ga...@kernel.crashing.org; linuxppc- d...@lists.ozlabs.org Subject: Re: [PATCH v3 4/4] powerpc/85xx: add sysfs for pw20 state and altivec idle On Wed, 2013-09-11 at 22:48 -0500, Wang Dongsheng-B40534 wrote: -Original Message- From: Wood Scott-B07421 Sent: Thursday, September 12, 2013 7:04 AM To: Wang Dongsheng-B40534 Cc: ga...@kernel.crashing.org; linuxppc-dev@lists.ozlabs.org Subject: Re: [PATCH v3 4/4] powerpc/85xx: add sysfs for pw20 state and altivec idle On Wed, 2013-09-11 at 13:56 +0800, Dongsheng Wang wrote: From: Wang Dongsheng dongsheng.w...@freescale.com Add a sys interface to enable/diable pw20 state or altivec idle, and control the wait entry time. Enable/Disable interface: 0, disable. 1, enable. /sys/devices/system/cpu/cpuX/pw20_state /sys/devices/system/cpu/cpuX/altivec_idle Set wait entry bit interface: bit value range 0~63, 0 bit is Mintime, 63 bit is Maxtime. /sys/devices/system/cpu/cpuX/pw20_wait_entry_bit /sys/devices/system/cpu/cpuX/altivec_idle_wait_entry_bit I'm no fan of the way powerpc does bit numbering, but don't flip it around here -- you'll just cause confusion. OK. 0 bit is maxtime, 63 bit is mintime. Better yet, this interface should take real time units rather than a timebase bit. I think the real time is not suitable, because timebase bit does not correspond with real time. It's a bit sloppy due to how the hardware works, but you could convert it like you did in earlier patches. Semantically it should probably be the minimum time to wait before entering the low power state. But there has a problem, we can't convert bit to the real time when user read this sysfs. Like: echo 1000(us) /sys/*/pw20_wait_entry_bit, after convert we get bit is 49. cat /sys/*/pw20_wait_entry_bit, after convert the time is 1598(us). The read out of the time is not real time. Unless we define a variable to save the real time. Also, you disable the power saving mode if the maximum interval is selected, It's not disable the pw20 state or altivec idle, just max-delay entry time. No, the code checks for zero to set or clear the enabling bit (e.g. PW20_WAIT). There has pw20_state/altivec_idle sys interface to control enable/disable, There is only to control wait bit. Did you mean remove pw20_state/altivec_idle sys interface, and reuse pw20_wait_entry_bit/altivec_idle* sys interface? When echo zero into pw20_wait_entry_bit we just to disable pw20 state, I think that is reasonable. :) ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH v3 2/4] powerpc/85xx: add hardware automatically enter altivec idle state
-Original Message- From: Wood Scott-B07421 Sent: Thursday, September 12, 2013 6:43 AM To: Wang Dongsheng-B40534 Cc: ga...@kernel.crashing.org; linuxppc-dev@lists.ozlabs.org Subject: Re: [PATCH v3 2/4] powerpc/85xx: add hardware automatically enter altivec idle state On Wed, 2013-09-11 at 13:56 +0800, Dongsheng Wang wrote: From: Wang Dongsheng dongsheng.w...@freescale.com Each core's AltiVec unit may be placed into a power savings mode by turning off power to the unit. Core hardware will automatically power down the AltiVec unit after no AltiVec instructions have executed in N cycles. The AltiVec power-control is triggered by hardware. Signed-off-by: Wang Dongsheng dongsheng.w...@freescale.com --- *v3: Assembly code instead of C code. *v2: Remove: delete setup_idle_hw_governor function. delete Fix erratum for rev1. Move: move setup_* into __setup/restore_cpu_e6500. arch/powerpc/kernel/cpu_setup_fsl_booke.S | 20 1 file changed, 20 insertions(+) diff --git a/arch/powerpc/kernel/cpu_setup_fsl_booke.S b/arch/powerpc/kernel/cpu_setup_fsl_booke.S index bfb18c7..3c03c109 100644 --- a/arch/powerpc/kernel/cpu_setup_fsl_booke.S +++ b/arch/powerpc/kernel/cpu_setup_fsl_booke.S @@ -53,11 +53,30 @@ _GLOBAL(__e500_dcache_setup) isync blr +/* + * FIXME - We don't know the AltiVec application scenarios. + */ +#define AV_WAIT_IDLE_BIT 50 /* 1ms, TB frequency is 41.66MHZ */ +_GLOBAL(setup_altivec_idle) + mfspr r3, SPRN_PWRMGTCR0 + + /* Enable Altivec Idle */ + orisr3, r3, PWRMGTCR0_AV_IDLE_PD_EN@h + li r4, AV_WAIT_IDLE_BIT + + /* Set Automatic AltiVec Idle Count */ + rlwimi r3, r4, PWRMGTCR0_AV_IDLE_CNT_SHIFT, PWRMGTCR0_AV_IDLE_CNT + + mtspr SPRN_PWRMGTCR0, r3 + + blr The FIXME comment is not clear. If you mean that we haven't yet done testing to determine a reasonable default value for AV_WAIT_IDLE_BIT, then just say that. Likewise with the FIXME comment in the pw20 patch -- the uncertainty is due to a lack of investigation, not because we don't know the current state of the cpu load. While some workloads may want a different value than whatever default we set, that's what the sysfs interface is for. The only thing missing here is benchmarking to determine a good overall default. Thanks. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH v3 4/4] powerpc/85xx: add sysfs for pw20 state and altivec idle
-Original Message-
From: Wood Scott-B07421
Sent: Thursday, September 12, 2013 7:04 AM
To: Wang Dongsheng-B40534
Cc: ga...@kernel.crashing.org; linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH v3 4/4] powerpc/85xx: add sysfs for pw20 state and
altivec idle
On Wed, 2013-09-11 at 13:56 +0800, Dongsheng Wang wrote:
From: Wang Dongsheng dongsheng.w...@freescale.com
Add a sys interface to enable/diable pw20 state or altivec idle, and
control the wait entry time.
Enable/Disable interface:
0, disable. 1, enable.
/sys/devices/system/cpu/cpuX/pw20_state
/sys/devices/system/cpu/cpuX/altivec_idle
Set wait entry bit interface:
bit value range 0~63, 0 bit is Mintime, 63 bit is Maxtime.
/sys/devices/system/cpu/cpuX/pw20_wait_entry_bit
/sys/devices/system/cpu/cpuX/altivec_idle_wait_entry_bit
I'm no fan of the way powerpc does bit numbering, but don't flip it
around here -- you'll just cause confusion.
OK. 0 bit is maxtime, 63 bit is mintime.
Better yet, this interface should take real time units rather than a
timebase bit.
I think the real time is not suitable, because timebase bit does not correspond
with
real time.
Also, you disable the power saving mode if the maximum interval is
selected,
It's not disable the pw20 state or altivec idle, just max-delay entry time.
but the documentation doesn't say that -- and the documentation
should be in the code (or other easily findable place), not just in the
commit message.
Also add a comment in the 85xx/common.c ?
Signed-off-by: Wang Dongsheng dongsheng.w...@freescale.com
---
diff --git a/arch/powerpc/kernel/cpu_setup_fsl_booke.S
b/arch/powerpc/kernel/cpu_setup_fsl_booke.S
index 7389d49..7395d79 100644
--- a/arch/powerpc/kernel/cpu_setup_fsl_booke.S
+++ b/arch/powerpc/kernel/cpu_setup_fsl_booke.S
@@ -53,6 +53,21 @@ _GLOBAL(__e500_dcache_setup)
isync
blr
+_GLOBAL(has_pw20_altivec_idle)
+ /* 0 false, 1 true */
+ li r3, 0
+
+ /* PW20 AltiVec idle feature only exists for E6500 */
+ mfspr r0, SPRN_PVR
+ rlwinm r4, r0, 16, 16, 31
+ lis r12, 0
+ ori r12, r12, PVR_VER_E6500@l
+ cmpwr4, r12
+ bne 2f
+ li r3, 1
+2:
+ blr
Why is this in asm? And shouldn't this go in the cputable somehow?
Not a special reason for this, just asm...
I see that, we can use cpu_spec-pvr_value in c code.
+static void query_pwrmgtcr0(void *val) {
+ u32 *value = val;
+
+ *value = mfspr(SPRN_PWRMGTCR0);
+}
+
+static ssize_t show_pw20_state(struct device *dev,
+ struct device_attribute *attr, char *buf) {
+ u32 value;
+ unsigned int cpu = dev-id;
+
+ smp_call_function_single(cpu, query_pwrmgtcr0, value, 1);
+
+ value = PWRMGTCR0_PW20_WAIT;
+
+ return sprintf(buf, %u\n, value ? 1 : 0); }
+
+static void control_pw20_state(void *val) {
+ u32 *value = val;
+ u32 pw20_state;
+
+ pw20_state = mfspr(SPRN_PWRMGTCR0);
+
+ if (*value)
+ pw20_state |= PWRMGTCR0_PW20_WAIT;
+ else
+ pw20_state = ~PWRMGTCR0_PW20_WAIT;
+
+ mtspr(SPRN_PWRMGTCR0, pw20_state);
+}
+
+static ssize_t store_pw20_state(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t count)
The difference between query/show and control/store is a bit awkward...
I'd s/query/do_show/ and s/control/do_store/ (or local_ or other
appropriate prefix).
do_show/do_store looks better than others.
+static ssize_t show_altivec_idle_wait_entry_bit(struct device *dev,
+ struct device_attribute *attr, char *buf) {
+ u32 value;
+ unsigned int cpu = dev-id;
+
+ smp_call_function_single(cpu, query_pwrmgtcr0, value, 1);
+
+ value = MAX_BIT - ((value PWRMGTCR0_AV_IDLE_CNT)
+ PWRMGTCR0_AV_IDLE_CNT_SHIFT);
+
+ return sprintf(buf, wait entry bit is %u\n, value); }
Reading a sysfs value should just return the value, not a human-readable
string.
Thanks.
+static DEVICE_ATTR(pw20_state, 0644, show_pw20_state,
+store_pw20_state); static DEVICE_ATTR(pw20_wait_entry_bit, 0644,
show_pw20_wait_entry_bit,
+ store_pw20_wait_entry_bit);
+
+static DEVICE_ATTR(altivec_idle, 0644, show_altivec_idle,
+store_altivec_idle); static DEVICE_ATTR(altivec_idle_wait_entry_bit,
0644,
+ show_altivec_idle_wait_entry_bit,
+ store_altivec_idle_wait_entry_bit);
I'd make these 0600, given their ability to spam other CPUs with IPIs
even on read.
Thanks.
+static int __init create_pw20_altivec_sysfs(void) {
+ int i;
+ struct device *cpu_dev;
+
+ if (!has_pw20_altivec_idle())
+ return -ENODEV;
+
+ for_each_possible_cpu(i) {
+ cpu_dev = get_cpu_device(i
RE: [PATCH v2 2/3] powerpc/85xx: add hardware automatically enter altivec idle state
-Original Message- From: Wang Dongsheng-B40534 Sent: Tuesday, August 27, 2013 4:42 PM To: Wood Scott-B07421; ga...@kernel.crashing.org Cc: linuxppc-dev@lists.ozlabs.org; Wang Dongsheng-B40534 Subject: [PATCH v2 2/3] powerpc/85xx: add hardware automatically enter altivec idle state From: Wang Dongsheng dongsheng.w...@freescale.com Each core's AltiVec unit may be placed into a power savings mode by turning off power to the unit. Core hardware will automatically power down the AltiVec unit after no AltiVec instructions have executed in N cycles. The AltiVec power-control is triggered by hardware. Signed-off-by: Wang Dongsheng dongsheng.w...@freescale.com --- *v2: Remove: delete setup_idle_hw_governor function. delete Fix erratum for rev1. Move: move setup_* into __setup/restore_cpu_e6500. diff --git a/arch/powerpc/include/asm/reg_booke.h b/arch/powerpc/include/asm/reg_booke.h index 86ede76..8364bbe 100644 --- a/arch/powerpc/include/asm/reg_booke.h +++ b/arch/powerpc/include/asm/reg_booke.h @@ -217,6 +217,9 @@ #define CCR1_DPC0x0100 /* Disable L1 I-Cache/D-Cache parity checking */ #define CCR1_TCS0x0080 /* Timer Clock Select */ +/* Bit definitions for PWRMGTCR0. */ +#define PWRMGTCR0_ALTIVEC_IDLE (1 22) /* Altivec idle enable */ + /* Bit definitions for the MCSR. */ #define MCSR_MCS 0x8000 /* Machine Check Summary */ #define MCSR_IB 0x4000 /* Instruction PLB Error */ diff --git a/arch/powerpc/kernel/cpu_setup_fsl_booke.S b/arch/powerpc/kernel/cpu_setup_fsl_booke.S index bfb18c7..90bbb46 100644 --- a/arch/powerpc/kernel/cpu_setup_fsl_booke.S +++ b/arch/powerpc/kernel/cpu_setup_fsl_booke.S @@ -58,6 +58,7 @@ _GLOBAL(__setup_cpu_e6500) #ifdef CONFIG_PPC64 bl .setup_altivec_ivors #endif + bl setup_altivec_idle bl __setup_cpu_e5500 mtlrr6 blr @@ -119,6 +120,7 @@ _GLOBAL(__setup_cpu_e5500) _GLOBAL(__restore_cpu_e6500) mflrr5 bl .setup_altivec_ivors + bl setup_altivec_idle bl __restore_cpu_e5500 mtlrr5 blr diff --git a/arch/powerpc/platforms/85xx/common.c b/arch/powerpc/platforms/85xx/common.c index d0861a0..93b563b 100644 --- a/arch/powerpc/platforms/85xx/common.c +++ b/arch/powerpc/platforms/85xx/common.c @@ -11,6 +11,16 @@ #include mpc85xx.h +#define MAX_BIT 64 + This should be change to 63, i will fix this in next patch. - dongsheng ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 1/2] powerpc/85xx: add hardware automatically enter altivec idle state
-Original Message- From: Wood Scott-B07421 Sent: Friday, August 23, 2013 11:31 PM To: Wang Dongsheng-B40534 Cc: Wood Scott-B07421; Kumar Gala; Zhao Chenhui-B35336; linuxppc- d...@lists.ozlabs.org Subject: Re: [PATCH 1/2] powerpc/85xx: add hardware automatically enter altivec idle state On Thu, 2013-08-22 at 21:52 -0500, Wang Dongsheng-B40534 wrote: -Original Message- From: Wood Scott-B07421 Sent: Thursday, August 22, 2013 11:19 PM To: Wang Dongsheng-B40534 Cc: Wood Scott-B07421; Kumar Gala; Zhao Chenhui-B35336; linuxppc- d...@lists.ozlabs.org Subject: Re: [PATCH 1/2] powerpc/85xx: add hardware automatically enter altivec idle state On Wed, 2013-08-21 at 22:13 -0500, Wang Dongsheng-B40534 wrote: -Original Message- From: Wood Scott-B07421 Sent: Tuesday, August 20, 2013 8:39 AM To: Wang Dongsheng-B40534 Cc: Wood Scott-B07421; Kumar Gala; linuxppc-dev@lists.ozlabs.org Subject: Re: [PATCH 1/2] powerpc/85xx: add hardware automatically enter altivec idle state It just seems wrong to have an ad-hoc mechanism for running core-specific code when we have cputable... If we really need this, maybe we should add a cpu_setup_late function pointer. With your patch, when does the power management register get set when hot plugging a cpu? Um.. I don't deal with this situation. I will fix it. __setup/restore_cpu_e6500 looks good. But only bootcpu call __setup_cpu_e6500, not on each cpu. I think this is a bug. Other CPUs call __restore_cpu_e6500. No, there is bootcore of secondary thread, and other cores of first thread call __restore_cpu_e6500. This is the upstream list -- there is no e6500 thread support yet. :-) But in the SDK I do see generic_secondary_common_init being called from generic_secondary_thread_init, which means __restore_cpu_e6500 will be called. Thanks. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 1/2] powerpc/85xx: add hardware automatically enter altivec idle state
-Original Message- From: Wood Scott-B07421 Sent: Thursday, August 22, 2013 11:19 PM To: Wang Dongsheng-B40534 Cc: Wood Scott-B07421; Kumar Gala; Zhao Chenhui-B35336; linuxppc- d...@lists.ozlabs.org Subject: Re: [PATCH 1/2] powerpc/85xx: add hardware automatically enter altivec idle state On Wed, 2013-08-21 at 22:13 -0500, Wang Dongsheng-B40534 wrote: -Original Message- From: Wood Scott-B07421 Sent: Tuesday, August 20, 2013 8:39 AM To: Wang Dongsheng-B40534 Cc: Wood Scott-B07421; Kumar Gala; linuxppc-dev@lists.ozlabs.org Subject: Re: [PATCH 1/2] powerpc/85xx: add hardware automatically enter altivec idle state It just seems wrong to have an ad-hoc mechanism for running core-specific code when we have cputable... If we really need this, maybe we should add a cpu_setup_late function pointer. With your patch, when does the power management register get set when hot plugging a cpu? Um.. I don't deal with this situation. I will fix it. __setup/restore_cpu_e6500 looks good. But only bootcpu call __setup_cpu_e6500, not on each cpu. I think this is a bug. Other CPUs call __restore_cpu_e6500. No, there is bootcore of secondary thread, and other cores of first thread call __restore_cpu_e6500. This flow is correct? As for the PVR check, the upstream kernel doesn't need to care about rev1, so knowing it's an e6500 is good enough. But AltiVec idle PW20 cannot work on rev1 platform. We didn't have to deal with it? Upstream does not run on rev1. :), But already have customers in the use of rev1. Why we don't need to care about that? rev1 is not production-qualified. Those customers are supposed to only be using rev1 for evaluation and early development. It's not that we don't care about rev1 now (we have the SDK for that) but that we won't care about it long-term and don't want to have to carry around a bunch of baggage for it. Some of the workarounds are pretty nasty (especially A- 006198). Thanks. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH V5 3/5] POWER/cpuidle: Generic IBM-POWER backend cpuidle driver.
diff --git a/drivers/cpuidle/Kconfig b/drivers/cpuidle/Kconfig
index 0e2cd5c..e805dcd 100644
--- a/drivers/cpuidle/Kconfig
+++ b/drivers/cpuidle/Kconfig
Maybe drivers/cpuidle/Kconfig.powerpc is better? Like arm.
+obj-$(CONFIG_CPU_IDLE_IBM_POWER) += cpuidle-ibm-power.o
diff --git a/drivers/cpuidle/cpuidle-ibm-power.c
b/drivers/cpuidle/cpuidle-ibm-power.c
new file mode 100644
index 000..4ee5a94
--- /dev/null
+++ b/drivers/cpuidle/cpuidle-ibm-power.c
@@ -0,0 +1,304 @@
+/*
+ * cpuidle-ibm-power - idle state cpuidle driver.
+ * Adapted from drivers/idle/intel_idle.c and
+ * drivers/acpi/processor_idle.c
+ *
+ */
+
+#include linux/kernel.h
+#include linux/module.h
+#include linux/init.h
+#include linux/moduleparam.h
+#include linux/cpuidle.h
+#include linux/cpu.h
+#include linux/notifier.h
+
+#include asm/paca.h
+#include asm/reg.h
+#include asm/machdep.h
+#include asm/firmware.h
+#include asm/runlatch.h
+#include asm/plpar_wrappers.h
+
+struct cpuidle_driver power_idle_driver = {
+ .name = IBM-POWER-Idle,
+ .owner= THIS_MODULE,
+};
+
+#define MAX_IDLE_STATE_COUNT 2
+
+static int max_idle_state = MAX_IDLE_STATE_COUNT - 1;
Again, do not use the macro.
+static struct cpuidle_state *cpuidle_state_table;
+
+static inline void idle_loop_prolog(unsigned long *in_purr)
+{
+ *in_purr = mfspr(SPRN_PURR);
+ /*
+ * Indicate to the HV that we are idle. Now would be
+ * a good time to find other work to dispatch.
+ */
+ get_lppaca()-idle = 1;
+}
+
+static inline void idle_loop_epilog(unsigned long in_purr)
+{
+ get_lppaca()-wait_state_cycles += mfspr(SPRN_PURR) - in_purr;
+ get_lppaca()-idle = 0;
+}
+
+static int snooze_loop(struct cpuidle_device *dev,
+ struct cpuidle_driver *drv,
+ int index)
+{
+ unsigned long in_purr;
+
+ idle_loop_prolog(in_purr);
+ local_irq_enable();
snooze_loop has already registered in cpuidle framework to handle snooze state.
where disable the irq? Why do enable here?
+/*
+ * States for dedicated partition case.
+ */
+static struct cpuidle_state dedicated_states[MAX_IDLE_STATE_COUNT] = {
+ { /* Snooze */
+ .name = snooze,
+ .desc = snooze,
+ .flags = CPUIDLE_FLAG_TIME_VALID,
+ .exit_latency = 0,
+ .target_residency = 0,
+ .enter = snooze_loop },
+ { /* CEDE */
+ .name = CEDE,
+ .desc = CEDE,
+ .flags = CPUIDLE_FLAG_TIME_VALID,
+ .exit_latency = 10,
+ .target_residency = 100,
+ .enter = dedicated_cede_loop },
+};
+
+/*
+ * States for shared partition case.
+ */
+static struct cpuidle_state shared_states[MAX_IDLE_STATE_COUNT] = {
+ { /* Shared Cede */
+ .name = Shared Cede,
+ .desc = Shared Cede,
+ .flags = CPUIDLE_FLAG_TIME_VALID,
+ .exit_latency = 0,
+ .target_residency = 0,
+ .enter = shared_cede_loop },
+};
+
+static void __exit power_processor_idle_exit(void)
+{
+
+ unregister_cpu_notifier(setup_hotplug_notifier);
Remove a blank line.
+ cpuidle_unregister(power_idle_driver);
+ return;
+}
+
+module_init(power_processor_idle_init);
+module_exit(power_processor_idle_exit);
+
Did you have tested the module? If not tested, please don't use the module.
+MODULE_AUTHOR(Deepthi Dharwar deep...@linux.vnet.ibm.com);
+MODULE_DESCRIPTION(Cpuidle driver for IBM POWER platforms);
+MODULE_LICENSE(GPL);
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 1/2] powerpc/85xx: add hardware automatically enter altivec idle state
-Original Message- From: Wood Scott-B07421 Sent: Tuesday, August 20, 2013 8:39 AM To: Wang Dongsheng-B40534 Cc: Wood Scott-B07421; Kumar Gala; linuxppc-dev@lists.ozlabs.org Subject: Re: [PATCH 1/2] powerpc/85xx: add hardware automatically enter altivec idle state On Sun, 2013-08-18 at 21:53 -0500, Wang Dongsheng-B40534 wrote: Thanks for your feedback. -Original Message- From: Wood Scott-B07421 Sent: Saturday, August 17, 2013 12:51 AM To: Kumar Gala Cc: Wang Dongsheng-B40534; linuxppc-dev@lists.ozlabs.org Subject: Re: [PATCH 1/2] powerpc/85xx: add hardware automatically enter altivec idle state On Fri, 2013-08-16 at 06:02 -0500, Kumar Gala wrote: On Aug 16, 2013, at 2:23 AM, Dongsheng Wang wrote: From: Wang Dongsheng dongsheng.w...@freescale.com Each core's AltiVec unit may be placed into a power savings mode by turning off power to the unit. Core hardware will automatically power down the AltiVec unit after no AltiVec instructions have executed in N cycles. The AltiVec power-control is triggered by hardware. Signed-off-by: Wang Dongsheng dongsheng.w...@freescale.com Why treat this as a idle HW governor vs just some one time setup at boot of the time delay? It is being done as one-time setup, despite the function name. Maybe it should be moved into __setup/restore_cpu_e6500 (BTW, we really should refactor those to reduce duplication) with the timebase bit number hardcoded rather than a time in us. The frequency of the different platforms timebase is not the same. It's close enough. Remember, this number is a vague initial guess, not something that's been carefully calibrated. Though, it would make it harder to substitute the number with one that's been more carefully calibrated... but wouldn't different chips possibly have different optimal delays anyway? If we use it, we need to set different timebase bit on each platform. That is why I did not put the code in __setup/restore_cpu_e6500, I need use tb_ticks_per_usec to get timebase bit. So we only need to set a time for each platform, and not set different timebase bit. It just seems wrong to have an ad-hoc mechanism for running core-specific code when we have cputable... If we really need this, maybe we should add a cpu_setup_late function pointer. With your patch, when does the power management register get set when hot plugging a cpu? Um.. I don't deal with this situation. I will fix it. __setup/restore_cpu_e6500 looks good. But only bootcpu call __setup_cpu_e6500, not on each cpu. I think this is a bug. Fix code: diff --git a/arch/powerpc/kernel/head_64.S b/arch/powerpc/kernel/head_64.S index 2cfed9e..2a9a718 100644 --- a/arch/powerpc/kernel/head_64.S +++ b/arch/powerpc/kernel/head_64.S @@ -603,6 +603,9 @@ __secondary_start: /* Set thread priority to MEDIUM */ HMT_MEDIUM +#ifdef CONFIG_PPC_BOOK3E + bl call_setup_cpu /* Call setup_cpu for this CPU */ +#endif /* Initialize the kernel stack */ LOAD_REG_ADDR(r3, current_set) sldir28,r24,3 /* get current_set[cpu#] */ diff --git a/arch/powerpc/kernel/misc_64.S b/arch/powerpc/kernel/misc_64.S index b863b87..7d84bf4 100644 --- a/arch/powerpc/kernel/misc_64.S +++ b/arch/powerpc/kernel/misc_64.S @@ -55,6 +55,17 @@ _GLOBAL(call_handle_irq) mtlrr0 blr +_GLOBAL(call_setup_cpu) + LOAD_REG_ADDR(r4, cur_cpu_spec) + ld r4, 0(r4) + ld r5, CPU_SPEC_SETUP(r4) + + cmpwi 0, r5, 0 + beqlr + ld r5, 0(r5) + mtctr r5 + bctr + .section.toc,aw PPC64_CACHES: .tc ppc64_caches[TC],ppc64_caches As for the PVR check, the upstream kernel doesn't need to care about rev1, so knowing it's an e6500 is good enough. But AltiVec idle PW20 cannot work on rev1 platform. We didn't have to deal with it? Upstream does not run on rev1. :), But already have customers in the use of rev1. Why we don't need to care about that? ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 1/2] powerpc/85xx: add hardware automatically enter altivec idle state
Thanks for your feedback. -Original Message- From: Wood Scott-B07421 Sent: Saturday, August 17, 2013 12:51 AM To: Kumar Gala Cc: Wang Dongsheng-B40534; linuxppc-dev@lists.ozlabs.org Subject: Re: [PATCH 1/2] powerpc/85xx: add hardware automatically enter altivec idle state On Fri, 2013-08-16 at 06:02 -0500, Kumar Gala wrote: On Aug 16, 2013, at 2:23 AM, Dongsheng Wang wrote: From: Wang Dongsheng dongsheng.w...@freescale.com Each core's AltiVec unit may be placed into a power savings mode by turning off power to the unit. Core hardware will automatically power down the AltiVec unit after no AltiVec instructions have executed in N cycles. The AltiVec power-control is triggered by hardware. Signed-off-by: Wang Dongsheng dongsheng.w...@freescale.com Why treat this as a idle HW governor vs just some one time setup at boot of the time delay? It is being done as one-time setup, despite the function name. Maybe it should be moved into __setup/restore_cpu_e6500 (BTW, we really should refactor those to reduce duplication) with the timebase bit number hardcoded rather than a time in us. The frequency of the different platforms timebase is not the same. If we use it, we need to set different timebase bit on each platform. That is why I did not put the code in __setup/restore_cpu_e6500, I need use tb_ticks_per_usec to get timebase bit. So we only need to set a time for each platform, and not set different timebase bit. As for the PVR check, the upstream kernel doesn't need to care about rev1, so knowing it's an e6500 is good enough. But AltiVec idle PW20 cannot work on rev1 platform. We didn't have to deal with it? -dongsheng ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH] powerpc: add the missing required isync for the coherent icache flush
-Original Message- From: Linuxppc-dev [mailto:linuxppc-dev- bounces+b40534=freescale@lists.ozlabs.org] On Behalf Of Kevin Hao Sent: Thursday, August 15, 2013 7:56 PM To: Benjamin Herrenschmidt Cc: linuxppc Subject: [PATCH] powerpc: add the missing required isync for the coherent icache flush Even we don't need to flush the dcache and invalidate the icache on the CPU which has coherent icache. But we do need an isync to discard the prefetched instructions in this case. Signed-off-by: Kevin Hao haoke...@gmail.com --- arch/powerpc/kernel/misc_32.S | 2 ++ arch/powerpc/kernel/misc_64.S | 1 + 2 files changed, 3 insertions(+) diff --git a/arch/powerpc/kernel/misc_32.S b/arch/powerpc/kernel/misc_32.S index 777d999..0b84c8d 100644 --- a/arch/powerpc/kernel/misc_32.S +++ b/arch/powerpc/kernel/misc_32.S @@ -433,6 +433,7 @@ _GLOBAL(invalidate_dcache_range) */ _GLOBAL(__flush_dcache_icache) BEGIN_FTR_SECTION + isync There is not touch the icache, why need we to do this? blr END_FTR_SECTION_IFSET(CPU_FTR_COHERENT_ICACHE) rlwinm r3,r3,0,0,31-PAGE_SHIFT /* Get page base address */ @@ -474,6 +475,7 @@ END_MMU_FTR_SECTION_IFSET(MMU_FTR_TYPE_44x) */ _GLOBAL(__flush_dcache_icache_phys) BEGIN_FTR_SECTION + isync blr /* for 601, do nothing */ END_FTR_SECTION_IFSET(CPU_FTR_COHERENT_ICACHE) mfmsr r10 diff --git a/arch/powerpc/kernel/misc_64.S b/arch/powerpc/kernel/misc_64.S index 992a78e..d74fefb 100644 --- a/arch/powerpc/kernel/misc_64.S +++ b/arch/powerpc/kernel/misc_64.S @@ -69,6 +69,7 @@ PPC64_CACHES: _KPROBE(flush_icache_range) BEGIN_FTR_SECTION + isync blr END_FTR_SECTION_IFSET(CPU_FTR_COHERENT_ICACHE) /* -- 1.8.3.1 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [RFC PATCH V3 3/5] powerpc/cpuidle: Generic powerpc backend cpuidle driver.
I think we should move the states and handle function to arch/power/platform*
The states and handle function is belong to backend driver, not for this,
different platform have different state.
Different platforms to make their own deal with these states.
I think we cannot put all the status of different platforms and handler in this
driver.
diff --git a/drivers/cpuidle/Kconfig b/drivers/cpuidle/Kconfig
index 0e2cd5c..99ee5d4 100644
--- a/drivers/cpuidle/Kconfig
+++ b/drivers/cpuidle/Kconfig
@@ -42,6 +42,13 @@ config CPU_IDLE_ZYNQ
help
Select this to enable cpuidle on Xilinx Zynq processors.
+config CPU_IDLE_POWERPC
+ bool CPU Idle driver for POWERPC platforms
+ depends on PPC64
Why not PPC?
+ default y
+help
+ Select this option to enable processor idle state management
+ for POWERPC platform.
endif
config ARCH_NEEDS_CPU_IDLE_COUPLED
diff --git a/drivers/cpuidle/Makefile b/drivers/cpuidle/Makefile
index 8767a7b..d12e205 100644
--- a/drivers/cpuidle/Makefile
+++ b/drivers/cpuidle/Makefile
@@ -8,3 +8,5 @@ obj-$(CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED) += coupled.o
obj-$(CONFIG_CPU_IDLE_CALXEDA) += cpuidle-calxeda.o
obj-$(CONFIG_ARCH_KIRKWOOD) += cpuidle-kirkwood.o
obj-$(CONFIG_CPU_IDLE_ZYNQ) += cpuidle-zynq.o
+
+obj-$(CONFIG_CPU_IDLE_POWERPC) += cpuidle-powerpc.o
diff --git a/drivers/cpuidle/cpuidle-powerpc.c b/drivers/cpuidle/cpuidle-
powerpc.c
new file mode 100644
index 000..5756085
--- /dev/null
+++ b/drivers/cpuidle/cpuidle-powerpc.c
@@ -0,0 +1,361 @@
+/*
+ * processor_idle - idle state cpuidle driver.
+ * Adapted from drivers/idle/intel_idle.c and
+ * drivers/acpi/processor_idle.c
+ *
+ */
+
+#include linux/kernel.h
+#include linux/module.h
+#include linux/init.h
+#include linux/moduleparam.h
+#include linux/cpuidle.h
+#include linux/cpu.h
+#include linux/notifier.h
+
+#include asm/paca.h
+#include asm/reg.h
+#include asm/machdep.h
+#include asm/firmware.h
+#include asm/runlatch.h
+#include asm/plpar_wrappers.h
+
+struct cpuidle_driver powerpc_idle_driver = {
+ .name = powerpc_idle,
+ .owner= THIS_MODULE,
+};
+
+#define MAX_IDLE_STATE_COUNT 2
+
+static int max_idle_state = MAX_IDLE_STATE_COUNT - 1;
If this is a generic driver, do not define MAX_IDLE_STATE_COUNT, because we
don't know how many state on other platforms.
How about using ARRAY_SIZE to get the max idle state?
+static struct cpuidle_device __percpu *powerpc_cpuidle_devices;
+static struct cpuidle_state *cpuidle_state_table;
+
Should be remove all about *device*.
If the notifier handle using device, you can use
cpuidle_devices(include/linux/cpuidle.h).
+static inline void idle_loop_prolog(unsigned long *in_purr)
+{
+ *in_purr = mfspr(SPRN_PURR);
+ /*
+ * Indicate to the HV that we are idle. Now would be
+ * a good time to find other work to dispatch.
+ */
+ set_lppaca_idle(1);
+}
+
+static inline void idle_loop_epilog(unsigned long in_purr)
+{
+ add_lppaca_wait_state(mfspr(SPRN_PURR) - in_purr);
+ set_lppaca_idle(0);
+}
+
+static int snooze_loop(struct cpuidle_device *dev,
+ struct cpuidle_driver *drv,
+ int index)
+{
+ unsigned long in_purr;
+
+ idle_loop_prolog(in_purr);
+ local_irq_enable();
+ set_thread_flag(TIF_POLLING_NRFLAG);
+
+ while (!need_resched()) {
+ ppc64_runlatch_off();
+ HMT_low();
+ HMT_very_low();
+ }
+
+ HMT_medium();
+ clear_thread_flag(TIF_POLLING_NRFLAG);
+ smp_mb();
+
+ idle_loop_epilog(in_purr);
+
+ return index;
+}
+
+static void check_and_cede_processor(void)
+{
+ /*
+ * Ensure our interrupt state is properly tracked,
+ * also checks if no interrupt has occurred while we
+ * were soft-disabled
+ */
+ if (prep_irq_for_idle()) {
+ cede_processor();
+#ifdef CONFIG_TRACE_IRQFLAGS
+ /* Ensure that H_CEDE returns with IRQs on */
+ if (WARN_ON(!(mfmsr() MSR_EE)))
+ __hard_irq_enable();
+#endif
+ }
+}
+
+static int dedicated_cede_loop(struct cpuidle_device *dev,
+ struct cpuidle_driver *drv,
+ int index)
+{
+ unsigned long in_purr;
+
+ idle_loop_prolog(in_purr);
+ set_lppaca_donate_dedicated_cpu(1);
+
+ ppc64_runlatch_off();
+ HMT_medium();
+ check_and_cede_processor();
+
+ set_lppaca_donate_dedicated_cpu(0);
+ idle_loop_epilog(in_purr);
+
+ return index;
+}
+
+static int shared_cede_loop(struct cpuidle_device *dev,
+ struct cpuidle_driver *drv,
+ int index)
+{
+ unsigned long in_purr;
+
+ idle_loop_prolog(in_purr);
+
+ /*
+ * Yield the processor to the hypervisor. We return if
+
RE: [PATCH 2/2] powerpc/hibernate: add restore mmu context after resume
-Original Message- From: Benjamin Herrenschmidt [mailto:b...@kernel.crashing.org] Sent: Saturday, July 13, 2013 7:07 AM To: Wood Scott-B07421 Cc: Wang Dongsheng-B40534; Wood Scott-B07421; johan...@sipsolutions.net; an...@enomsg.org; ga...@kernel.crashing.org; linuxppc- d...@lists.ozlabs.org Subject: Re: [PATCH 2/2] powerpc/hibernate: add restore mmu context after resume On Fri, 2013-07-12 at 16:54 -0500, Scott Wood wrote: set_context() doesn't exist for hash MMUs. Whatever you do, please try actually building it on various targets, including both 32 and 64 bits, and both hash and non-hash. And make sure that whatever effect PPC32 was depending on switch_mmu_context for is preserved, including on non-booke. The right thing to do is probably to have the various tlb_* files How about mmu_context_* files to provide a pair of save/restore context functions? provide a pair of save/restore functions that do the right thing for that specific MMU type. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH] cpuidle: add freescale e500 family porcessors idle support
-Original Message-
From: Wood Scott-B07421
Sent: Wednesday, July 31, 2013 3:38 AM
To: Wang Dongsheng-B40534
Cc: r...@sisk.pl; daniel.lezc...@linaro.org; b...@kernel.crashing.org; Li
Yang-R58472; Zhao Chenhui-B35336; linux...@vger.kernel.org; linuxppc-
d...@lists.ozlabs.org
Subject: Re: [PATCH] cpuidle: add freescale e500 family porcessors idle
support
On 07/30/2013 02:00:03 AM, Dongsheng Wang wrote:
From: Wang Dongsheng dongsheng.w...@freescale.com
Add cpuidle support for e500 family, using cpuidle framework to
manage various low power modes. The new implementation will remain
compatible with original idle method.
Initially, this supports PW10, and subsequent patches will support
PW20/DOZE/NAP.
Could you explain what the cpuidle framework does for us that the
current idle code doesn't?
The current idle code, Only a state of low power can make the core idle.
The core can't get into more low power state.
In particular, what scenario do you see where we would require a
software
governor to choose between idle states, and how much power is saved
compared to a simpler approach? There is timer that can be used to
automatically enter PW20 after a certain amount of time in PW10.
Yes, the hardware can automatically enter PW20 state. But this is hardware
feature, we need to software to manage it. Only for PW20 state, we can drop
this cpuidle and using the hardware to control it. But if we need to support
PH10/PH15/PH20/PH30, the current idle code cannot support them.
How much better results do you get from a software governor? Do we even
have the right data to characterize each state so that a software governor
could make good decisions? Is cpuidle capable of governing the interval
of such a timer, rather than directly governing states?
From now on we did not benchmark these data, because we only have PW10 state.
I can do support doze/nap for e6500. To get some data to show you.
As for doze/nap, why would we want to use those on newer cores? Do you
have numbers for how much power each mode saves?
The PH state is plan to support, if the core can make into more low power state,
why not to do this.
PH10(doze)/PH15(nap)/PH20/PH30, These states can save more CPU power.
Active governors may be useful on older cores that only have doze/nap,
to
select between them, but if that's the use case then why start with
pw10?
Pw10 is supported on E500MC/E5500/E6500. And we plan to support PW20 for E65OO
core.
I will take doze/nap up a bit later.
And I'd want to see numbers for how much power nap saves versus doze.
Signed-off-by: Wang Dongsheng dongsheng.w...@freescale.com
---
This patch keep using cpuidle_register_device(), because we need to
support cpu
hotplug. I will fix device issue in this driver, after
Deepthi Dharwar deep...@linux.vnet.ibm.com add a hotplug handler
into cpuidle
freamwork.
Where's the diffstat?
See, http://patchwork.ozlabs.org/patch/260997/
@@ -0,0 +1,222 @@
+/*
+ * Copyright 2013 Freescale Semiconductor, Inc.
+ *
+ * CPU Idle driver for Freescale PowerPC e500 family processors.
+ *
+ * This program is free software; you can redistribute it and/or
modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * Author: Wang Dongsheng dongsheng.w...@freescale.com
+ */
Is this derived from some other file? It looks like it... Where's the
attribution?
The copyright is from drivers/cpufreq/ppc-corenet-cpufreq.c
+#include linux/cpu.h
+#include linux/cpuidle.h
+#include linux/init.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/notifier.h
+
+#include asm/machdep.h
+
+static struct cpuidle_driver e500_idle_driver = {
+ .name = e500_idle,
+ .owner = THIS_MODULE,
+};
+
+static struct cpuidle_device __percpu *e500_cpuidle_devices;
+
+static void e500_cpuidle(void)
+{
+ /*
+* This would call on the cpuidle framework, and the back-end
+* driver to go to idle states.
+*/
+ if (cpuidle_idle_call()) {
+ /*
+* On error, execute default handler
+* to go into low thread priority and possibly
+* low power mode.
+*/
+ HMT_low();
+ HMT_very_low();
This HMT stuff doesn't do anything on e500 derivatives AFAIK.
Yes, there should do nothing, let arch_cpu_idle to do the failed.
+static struct cpuidle_state fsl_pw_idle_states[] = {
+ {
+ .name = pw10,
+ .desc = pw10,
+ .flags = CPUIDLE_FLAG_TIME_VALID,
+ .exit_latency = 0,
+ .target_residency = 0,
+ .enter = pw10_enter
Where is pw10_enter defined?
In this patch..
+static int cpu_is_feature(unsigned long feature)
+{
+ return (cur_cpu_spec-cpu_features == feature);
+}
+
+static int __init e500_idle_init(void
RE: [PATCH] cpuidle: fix unremovable issue for module driver
-Original Message-
From: Daniel Lezcano [mailto:daniel.lezc...@linaro.org]
Sent: Tuesday, July 30, 2013 5:28 PM
To: Wang Dongsheng-B40534
Cc: r...@sisk.pl; linux...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH] cpuidle: fix unremovable issue for module driver
On 07/30/2013 08:55 AM, Dongsheng Wang wrote:
From: Wang Dongsheng dongsheng.w...@freescale.com
After __cpuidle_register_device, the cpu incs are added up, but decs
are not, thus the module refcount is not match. So the module exit
function can not be executed when we do remove operation. Move
module_put into __cpuidle_register_device to fix it.
Sorry, I still don't get it :/
register-module_get
unregister-module_put
you change it by:
register-module_get
register-module_put
unregister-none
which is wrong.
module_get-set per cpu incs=1
module_put-set per cpu decs=1
module_refcount- incs - decs;
unregister usually call in module-exit function.
But if module_refcount is not zero, the module-exit() cannot be executed.
See, kernel/module.c +874
delete_module()--try_stop_module();
Test Log:
root:~# rmmod cpuidle-e500
module_refcount: incs[9], decs[1]
rmmod: can't unload 'cpuidle_e500': Resource temporarily unavailable
Can you describe the problem you are facing ? (a bit more than I can't
unload the module).
Signed-off-by: Wang Dongsheng dongsheng.w...@freescale.com
diff --git a/drivers/cpuidle/cpuidle.c b/drivers/cpuidle/cpuidle.c
index d75040d..e964ada 100644
--- a/drivers/cpuidle/cpuidle.c
+++ b/drivers/cpuidle/cpuidle.c
@@ -351,11 +351,8 @@ EXPORT_SYMBOL_GPL(cpuidle_disable_device);
static void __cpuidle_unregister_device(struct cpuidle_device *dev)
{
- struct cpuidle_driver *drv = cpuidle_get_cpu_driver(dev);
-
list_del(dev-device_list);
per_cpu(cpuidle_devices, dev-cpu) = NULL;
- module_put(drv-owner);
}
static int __cpuidle_device_init(struct cpuidle_device *dev) @@
-384,6 +381,8 @@ static int __cpuidle_register_device(struct
cpuidle_device *dev)
per_cpu(cpuidle_devices, dev-cpu) = dev;
list_add(dev-device_list, cpuidle_detected_devices);
+ module_put(drv-owner);
+
ret = cpuidle_coupled_register_device(dev);
if (ret) {
__cpuidle_unregister_device(dev);
--
http://www.linaro.org/ Linaro.org │ Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro Facebook |
http://twitter.com/#!/linaroorg Twitter |
http://www.linaro.org/linaro-blog/ Blog
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH] cpuidle: add freescale e500 family porcessors idle support
-Original Message-
From: Daniel Lezcano [mailto:daniel.lezc...@linaro.org]
Sent: Tuesday, July 30, 2013 5:51 PM
To: Wang Dongsheng-B40534
Cc: Wood Scott-B07421; r...@sisk.pl; b...@kernel.crashing.org; Li Yang-
R58472; Zhao Chenhui-B35336; linux...@vger.kernel.org; linuxppc-
d...@lists.ozlabs.org
Subject: Re: [PATCH] cpuidle: add freescale e500 family porcessors idle
support
On 07/30/2013 09:00 AM, Dongsheng Wang wrote:
From: Wang Dongsheng dongsheng.w...@freescale.com
Add cpuidle support for e500 family, using cpuidle framework to manage
various low power modes. The new implementation will remain compatible
with original idle method.
Initially, this supports PW10, and subsequent patches will support
PW20/DOZE/NAP.
Signed-off-by: Wang Dongsheng dongsheng.w...@freescale.com
---
This patch keep using cpuidle_register_device(), because we need to
support cpu hotplug. I will fix device issue in this driver, after
Deepthi Dharwar deep...@linux.vnet.ibm.com add a hotplug handler
into cpuidle freamwork.
diff --git a/arch/powerpc/include/asm/machdep.h
b/arch/powerpc/include/asm/machdep.h
index 8b48090..cbdbe25 100644
--- a/arch/powerpc/include/asm/machdep.h
+++ b/arch/powerpc/include/asm/machdep.h
@@ -271,6 +271,16 @@ extern void power7_idle(void); extern void
ppc6xx_idle(void); extern void book3e_idle(void);
+/* Wait for Interrupt */
+static inline void fsl_cpuidle_wait(void) { #ifdef CONFIG_PPC64
+ book3e_idle();
+#else
+ e500_idle();
+#endif
+}
+
/*
* ppc_md contains a copy of the machine description structure for the
* current platform. machine_id contains the initial address where the
diff --git a/drivers/cpuidle/Kconfig b/drivers/cpuidle/Kconfig
index b3fb81d..7ed114b 100644
--- a/drivers/cpuidle/Kconfig
+++ b/drivers/cpuidle/Kconfig
@@ -35,6 +35,11 @@ depends on ARM
source drivers/cpuidle/Kconfig.arm
endmenu
+menu PowerPC CPU Idle Drivers
+depends on PPC32 || PPC64
+source drivers/cpuidle/Kconfig.powerpc
+endmenu
+
endif
config ARCH_NEEDS_CPU_IDLE_COUPLED
diff --git a/drivers/cpuidle/Kconfig.powerpc
b/drivers/cpuidle/Kconfig.powerpc
new file mode 100644
index 000..9f3f5ef
--- /dev/null
+++ b/drivers/cpuidle/Kconfig.powerpc
@@ -0,0 +1,9 @@
+#
+# PowerPC CPU Idle drivers
+#
+
+config PPC_E500_CPUIDLE
+ bool CPU Idle Driver for E500 family processors
+ depends on FSL_SOC_BOOKE
+ help
+ Select this to enable cpuidle on e500 family processors.
diff --git a/drivers/cpuidle/Makefile b/drivers/cpuidle/Makefile
index 0b9d200..0dde3db 100644
--- a/drivers/cpuidle/Makefile
+++ b/drivers/cpuidle/Makefile
@@ -11,3 +11,7 @@ obj-$(CONFIG_ARM_HIGHBANK_CPUIDLE)+= cpuidle-
calxeda.o
obj-$(CONFIG_ARM_KIRKWOOD_CPUIDLE) += cpuidle-kirkwood.o
obj-$(CONFIG_ARM_ZYNQ_CPUIDLE) += cpuidle-zynq.o
obj-$(CONFIG_ARM_U8500_CPUIDLE) += cpuidle-ux500.o
+
+
##
+# PowerPC platform drivers
+obj-$(CONFIG_PPC_E500_CPUIDLE) += cpuidle-e500.o
diff --git a/drivers/cpuidle/cpuidle-e500.c b/drivers/cpuidle/cpuidle-
e500.c
new file mode 100644
index 000..1919cea
--- /dev/null
+++ b/drivers/cpuidle/cpuidle-e500.c
@@ -0,0 +1,222 @@
+/*
+ * Copyright 2013 Freescale Semiconductor, Inc.
+ *
+ * CPU Idle driver for Freescale PowerPC e500 family processors.
+ *
+ * This program is free software; you can redistribute it and/or
modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * Author: Wang Dongsheng dongsheng.w...@freescale.com
+ */
+
+#include linux/cpu.h
+#include linux/cpuidle.h
+#include linux/init.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/notifier.h
+
+#include asm/machdep.h
+
+static struct cpuidle_driver e500_idle_driver = {
+ .name = e500_idle,
+ .owner = THIS_MODULE,
+};
+
+static struct cpuidle_device __percpu *e500_cpuidle_devices;
+
+static void e500_cpuidle(void)
+{
+ /*
+* This would call on the cpuidle framework, and the back-end
+* driver to go to idle states.
+*/
+ if (cpuidle_idle_call()) {
+ /*
+* On error, execute default handler
+* to go into low thread priority and possibly
+* low power mode.
+*/
+ HMT_low();
+ HMT_very_low();
+ }
+}
Nope, this is not the place to add such function.
Thanks.
But Why not? On powerpc there is already have a cpuidle method. We need to
compatible them.
Um.. arch/powerpc/platforms/xxx ?
+static int pw10_enter(struct cpuidle_device *dev,
+ struct cpuidle_driver *drv, int index)
+{
+ fsl_cpuidle_wait();
+ return index;
+}
+
+static
RE: [PATCH V2 4/6] cpuidle/pseries: Move the pseries_idle backend driver to sysdev.
-Original Message-
From: Deepthi Dharwar [mailto:deep...@linux.vnet.ibm.com]
Sent: Wednesday, July 31, 2013 10:59 AM
To: b...@kernel.crashing.org; daniel.lezc...@linaro.org; linux-
ker...@vger.kernel.org; mich...@ellerman.id.au;
srivatsa.b...@linux.vnet.ibm.com; pre...@linux.vnet.ibm.com;
sva...@linux.vnet.ibm.com; linuxppc-dev@lists.ozlabs.org
Cc: r...@sisk.pl; Wang Dongsheng-B40534; linux...@vger.kernel.org
Subject: [PATCH V2 4/6] cpuidle/pseries: Move the pseries_idle backend
driver to sysdev.
Move pseries_idle backend driver code to arch/powerpc/sysdev
so that the code can be used for a common driver for powernv
and pseries. This removes a lot of code duplicacy.
Why not drivers/cpuidle/?
I think it should be move to drivers/cpuidle.
-dongsheng
Signed-off-by: Deepthi Dharwar deep...@linux.vnet.ibm.com
---
arch/powerpc/platforms/pseries/Kconfig |9 -
arch/powerpc/platforms/pseries/Makefile |1
arch/powerpc/platforms/pseries/processor_idle.c | 384 -
--
arch/powerpc/sysdev/Kconfig |9 +
arch/powerpc/sysdev/Makefile|1
arch/powerpc/sysdev/processor_idle.c| 384
+++
6 files changed, 394 insertions(+), 394 deletions(-)
delete mode 100644 arch/powerpc/platforms/pseries/processor_idle.c
create mode 100644 arch/powerpc/sysdev/processor_idle.c
diff --git a/arch/powerpc/platforms/pseries/Kconfig
b/arch/powerpc/platforms/pseries/Kconfig
index 62b4f80..bb59bb0 100644
--- a/arch/powerpc/platforms/pseries/Kconfig
+++ b/arch/powerpc/platforms/pseries/Kconfig
@@ -119,12 +119,3 @@ config DTL
which are accessible through a debugfs file.
Say N if you are unsure.
-
-config PSERIES_IDLE
- bool Cpuidle driver for pSeries platforms
- depends on CPU_IDLE
- depends on PPC_PSERIES
- default y
- help
- Select this option to enable processor idle state management
- through cpuidle subsystem.
diff --git a/arch/powerpc/platforms/pseries/Makefile
b/arch/powerpc/platforms/pseries/Makefile
index 8ae0103..4b22379 100644
--- a/arch/powerpc/platforms/pseries/Makefile
+++ b/arch/powerpc/platforms/pseries/Makefile
@@ -21,7 +21,6 @@ obj-$(CONFIG_HCALL_STATS) += hvCall_inst.o
obj-$(CONFIG_CMM)+= cmm.o
obj-$(CONFIG_DTL)+= dtl.o
obj-$(CONFIG_IO_EVENT_IRQ) += io_event_irq.o
-obj-$(CONFIG_PSERIES_IDLE) += processor_idle.o
ifeq ($(CONFIG_PPC_PSERIES),y)
obj-$(CONFIG_SUSPEND)+= suspend.o
diff --git a/arch/powerpc/platforms/pseries/processor_idle.c
b/arch/powerpc/platforms/pseries/processor_idle.c
deleted file mode 100644
index 0d75a54..000
--- a/arch/powerpc/platforms/pseries/processor_idle.c
+++ /dev/null
@@ -1,384 +0,0 @@
-/*
- * processor_idle - idle state cpuidle driver.
- * Adapted from drivers/idle/intel_idle.c and
- * drivers/acpi/processor_idle.c
- *
- */
-
-#include linux/kernel.h
-#include linux/module.h
-#include linux/init.h
-#include linux/moduleparam.h
-#include linux/cpuidle.h
-#include linux/cpu.h
-#include linux/notifier.h
-
-#include asm/paca.h
-#include asm/reg.h
-#include asm/machdep.h
-#include asm/firmware.h
-#include asm/runlatch.h
-#include asm/plpar_wrappers.h
-
-/* Snooze Delay, pseries_idle */
-DECLARE_PER_CPU(long, smt_snooze_delay);
-
-struct cpuidle_driver pseries_idle_driver = {
- .name = pseries_idle,
- .owner= THIS_MODULE,
-};
-
-#define MAX_IDLE_STATE_COUNT 2
-
-static int max_idle_state = MAX_IDLE_STATE_COUNT - 1;
-static struct cpuidle_device __percpu *pseries_cpuidle_devices;
-static struct cpuidle_state *cpuidle_state_table;
-
-static inline void idle_loop_prolog(unsigned long *in_purr)
-{
- *in_purr = mfspr(SPRN_PURR);
- /*
- * Indicate to the HV that we are idle. Now would be
- * a good time to find other work to dispatch.
- */
- get_lppaca()-idle = 1;
-}
-
-static inline void idle_loop_epilog(unsigned long in_purr)
-{
- get_lppaca()-wait_state_cycles += mfspr(SPRN_PURR) - in_purr;
- get_lppaca()-idle = 0;
-}
-
-static int snooze_loop(struct cpuidle_device *dev,
- struct cpuidle_driver *drv,
- int index)
-{
- unsigned long in_purr;
- int cpu = dev-cpu;
-
- idle_loop_prolog(in_purr);
- local_irq_enable();
- set_thread_flag(TIF_POLLING_NRFLAG);
-
- while ((!need_resched()) cpu_online(cpu)) {
- ppc64_runlatch_off();
- HMT_low();
- HMT_very_low();
- }
-
- HMT_medium();
- clear_thread_flag(TIF_POLLING_NRFLAG);
- smp_mb();
-
- idle_loop_epilog(in_purr);
-
- return index;
-}
-
-static void check_and_cede_processor(void)
-{
- /*
- * Ensure our interrupt state is properly tracked,
- * also checks if no interrupt has
RE: [PATCH V2 5/6] cpuidle/powerpc: Backend-powerpc idle driver for powernv and pseries.
-static int pseries_cpuidle_add_cpu_notifier(struct notifier_block *n,
+static int powerpc_cpuidle_add_cpu_notifier(struct notifier_block *n,
unsigned long action, void *hcpu)
{
int hotcpu = (unsigned long)hcpu;
struct cpuidle_device *dev =
- per_cpu_ptr(pseries_cpuidle_devices, hotcpu);
+ per_cpu_ptr(powerpc_cpuidle_devices, hotcpu);
if (dev cpuidle_get_driver()) {
switch (action) {
@@ -235,16 +270,16 @@ static int pseries_cpuidle_add_cpu_notifier(struct
notifier_block *n,
}
static struct notifier_block setup_hotplug_notifier = {
- .notifier_call = pseries_cpuidle_add_cpu_notifier,
+ .notifier_call = powerpc_cpuidle_add_cpu_notifier,
};
I think Daniel means move the notifier to cpuidle framework, not just powerpc.
And should be remove all about *device*. If the notifier handle using device,
you can use cpuidle_devices.
- dongsheng
-static int __init pseries_processor_idle_init(void)
+static int __init powerpc_processor_idle_init(void)
{
int retval;
- retval = pseries_idle_probe();
+ retval = powerpc_idle_probe();
if (retval)
return retval;
- pseries_cpuidle_driver_init();
- retval = cpuidle_register_driver(pseries_idle_driver);
+ powerpc_cpuidle_driver_init();
+ retval = cpuidle_register_driver(powerpc_idle_driver);
if (retval) {
- printk(KERN_DEBUG Registration of pseries driver failed.\n);
+ printk(KERN_DEBUG Registration of powerpc driver failed.\n);
return retval;
}
update_smt_snooze_delay(-1, per_cpu(smt_snooze_delay, 0));
- retval = pseries_idle_devices_init();
+ retval = powerpc_idle_devices_init();
Should be remove all *device*, using cpuidle_register.
- dongsheng
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH V2 4/6] cpuidle/pseries: Move the pseries_idle backend driver to sysdev.
Hi Preeti, -Original Message- From: Preeti U Murthy [mailto:pre...@linux.vnet.ibm.com] Sent: Wednesday, July 31, 2013 12:00 PM To: Wang Dongsheng-B40534 Cc: Deepthi Dharwar; b...@kernel.crashing.org; daniel.lezc...@linaro.org; linux-ker...@vger.kernel.org; mich...@ellerman.id.au; srivatsa.b...@linux.vnet.ibm.com; sva...@linux.vnet.ibm.com; linuxppc- d...@lists.ozlabs.org; r...@sisk.pl; linux...@vger.kernel.org Subject: Re: [PATCH V2 4/6] cpuidle/pseries: Move the pseries_idle backend driver to sysdev. Hi Dongsheng, On 07/31/2013 08:52 AM, Wang Dongsheng-B40534 wrote: -Original Message- From: Deepthi Dharwar [mailto:deep...@linux.vnet.ibm.com] Sent: Wednesday, July 31, 2013 10:59 AM To: b...@kernel.crashing.org; daniel.lezc...@linaro.org; linux- ker...@vger.kernel.org; mich...@ellerman.id.au; srivatsa.b...@linux.vnet.ibm.com; pre...@linux.vnet.ibm.com; sva...@linux.vnet.ibm.com; linuxppc-dev@lists.ozlabs.org Cc: r...@sisk.pl; Wang Dongsheng-B40534; linux...@vger.kernel.org Subject: [PATCH V2 4/6] cpuidle/pseries: Move the pseries_idle backend driver to sysdev. Move pseries_idle backend driver code to arch/powerpc/sysdev so that the code can be used for a common driver for powernv and pseries. This removes a lot of code duplicacy. Why not drivers/cpuidle/? I think it should be move to drivers/cpuidle. Please take a look at what the cpuidle under drivers has to provide. cpuidle has two parts to it. The front end and the back end. The front end constitutes the cpuidle governors, registering of arch specific cpuidle drivers, disabling and enabling of cpuidle feature. It is this front end code which is present under drivers/cpuidle. The arch specific cpuidle drivers which decide what needs to be done to enter a specific idle state chosen by the cpuidle governor is what constitutes the back end of cpuidle. This will not be in drivers/cpuidle but in an arch/ specific code. The cpuidle under drivers/cpuidle drives the idle power management, but the low level handling of the entry into idle states should be taken care of by the architecture. Your recent patch : cpuidle: add freescale e500 family porcessors idle support IMO should hook onto the backend cpuidle driver that this patchset provides. Sorry, I don't think so, cpuidle framework has been already very common. Here we just need to do state definition and handling. I wonder whether we need this layer. If your handle is platform dependent, it should be in arch/platform. If it is only for some platforms and the operation of these platforms can be multiplexed, Why cannot as a driver to put into driver/cpuidle? If it a general driver, I think we can put some common operating to driver/cpuidle and make the platform specific code to arch/powerpc/platform. This patch include front end and back end, not just back end. This patch include too many state of different platforms and handle function. This state and handle that should belong to itself platforms. Not a general way. If Deepthi will do a general powerpc cpuidle, I think, it's cannot just using the macro to distinguish platform. the front end code maybe move to driver/cpuidle(drvier register) should be better, make the Low Power State and what should be handle to arch/powerpc/platform/**, because different platforms have different state of low power consumption, and the processing method. The front end can provide some general methods to register into general powerpc cpuidle driver. -dongsheng ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [RFC 2/2] powerpc/cputable: add wait feature for CPU kernel features
-Original Message-
From: Wood Scott-B07421
Sent: Tuesday, July 30, 2013 1:27 AM
To: Wang Dongsheng-B40534
Cc: b...@kernel.crashing.org; ga...@kernel.crashing.org; Zhao Chenhui-
B35336; Li Yang-R58472; Wang Dongsheng-B40534
Subject: Re: [RFC 2/2] powerpc/cputable: add wait feature for CPU kernel
features
On 07/10/2013 03:27:56 AM, Dongsheng Wang wrote:
From: Wang Dongsheng dongsheng.w...@freescale.com
Signed-off-by: Wang Dongsheng dongsheng.w...@freescale.com
diff --git a/arch/powerpc/include/asm/cputable.h
b/arch/powerpc/include/asm/cputable.h
index 6f3887d..0a8d0cb 100644
--- a/arch/powerpc/include/asm/cputable.h
+++ b/arch/powerpc/include/asm/cputable.h
@@ -138,6 +138,7 @@ extern const char *powerpc_base_platform;
#define CPU_FTR_NOEXECUTE ASM_CONST(0x1000)
#define CPU_FTR_INDEXED_DCRASM_CONST(0x2000)
#define CPU_FTR_EMB_HV ASM_CONST(0x4000)
+#define CPU_FTR_CAN_WAIT ASM_CONST(0x8000)
Note that this is the last 32-bit CPU feature flag; it's time to start
thinking about other mechanisms. We should probably reserve feature
flags for things that need to use code patching due to being on a
performance critical path, and move other things into struct cpu_spec.
CPU_FTR_CAN_WAIT seems like a good candidate to be moved.
First of all, why should I do, I need to distinguish between the core, which
is to support the wait instruction. The CPU_FTR_CAN_WAIT looks easy.
How to fix this problem:
1/ I can drop this cpu feature, and move it into struct cpu_spec.
Add a pm_feature in struct cpu_spec? like,
struct cpu_spec {
...
unsigned long pm_features;
...
}
2/ Drop this cpu feature, using CPU_FTRS_E6500/CPU_FTRS_E5500.. to distinguish
wait or doze/nap.
Like,
CPU_FTRS_E500/CPU_FTRS_E500_2 support doze/nap.
CPU_FTRS_E500MC/CPU_FTRS_E5500/CPU_FTRS_E6500 support wait.
If using this method, inside the cpuidle driver needs to do a lot of judgment.
So I'm not sure this
is a very good solution.
Thanks.
- dongsheng
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [RFC 1/2] fsl/pm: combined the idle(PHPW) state
-Original Message-
From: Wood Scott-B07421
Sent: Tuesday, July 30, 2013 1:22 AM
To: Wang Dongsheng-B40534
Cc: b...@kernel.crashing.org; ga...@kernel.crashing.org; Zhao Chenhui-
B35336; Li Yang-R58472; Wang Dongsheng-B40534
Subject: Re: [RFC 1/2] fsl/pm: combined the idle(PHPW) state
On 07/10/2013 03:27:55 AM, Dongsheng Wang wrote:
From: Wang Dongsheng dongsheng.w...@freescale.com
move wait instructions from idle_e500.S to idle_book3e.S
idle_e500.S: rename e500_idle to e500_idle_ph.
What does _ph mean?
If this is a reference to the new PHnn/PWnn terminology used on e6500, I
don't see how that's relevant to this file, which isn't used on e6500.
Or if you do plan to use this on e6500, why?
ph10/ph15 means doze/nap on freescale e500 family processors. On the IBM
platform does not ph concept.
Yes, ph maybe that's not a good idea. We should keep e500_idle.
On e500 processor, there is doze/nap, but e500mc/e5500/e6500 is using wait.
I want to move wait from idle_e500.S into idle_book3e.S, but book3e means
64bit mode... Now 32bit using idle_e500, 64bit using idle_book3e, and the idle
method
does not distinguish according to the platform, only in accordance with the CPU
running mode(32bit/64bit) to distinguish.
So did you have any idea about this? Or another way as follows,
We do not touch idle_e500.S and idle_e6500.S, add fsl_cpuidle_wait() into
machdep.h
arch/powerpc/include/asm/machdep.h
/* Wait for Interrupt */
static inline void fsl_cpuidle_wait(void)
{
#ifdef CONFIG_PPC64
book3e_idle();
#else
e500_idle();
#endif
}
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 2/2] cpuidle: export cpuidle_idle_call symbol
-Original Message- From: Rafael J. Wysocki [mailto:r...@sisk.pl] Sent: Wednesday, July 24, 2013 5:33 AM To: Wang Dongsheng-B40534 Cc: daniel.lezc...@linaro.org; linux...@vger.kernel.org; linuxppc- d...@lists.ozlabs.org Subject: Re: [PATCH 2/2] cpuidle: export cpuidle_idle_call symbol On Tuesday, July 23, 2013 05:28:01 PM Dongsheng Wang wrote: From: Wang Dongsheng dongsheng.w...@freescale.com Export cpuidle_idle_call symbol, make this function can be invoked in the module. Why? On powerpc platform, there is already have cpu idle implementation. I want use cpuidle framework to control various low power modes. But need to be compatible with the current implementation. And driver should be as a module, The user can using this module at any time. We need cpuidle_idle_call to drive the new implementation in modules. Thanks. - dongsheng Rafael ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 1/2] cpuidle: fix cpu idle driver as a module can not remove
-Original Message- From: Rafael J. Wysocki [mailto:r...@sisk.pl] Sent: Wednesday, July 24, 2013 5:33 AM To: Wang Dongsheng-B40534 Cc: daniel.lezc...@linaro.org; linux...@vger.kernel.org; linuxppc- d...@lists.ozlabs.org Subject: Re: [PATCH 1/2] cpuidle: fix cpu idle driver as a module can not remove On Tuesday, July 23, 2013 05:28:00 PM Dongsheng Wang wrote: From: Wang Dongsheng dongsheng.w...@freescale.com The module can not be removed when execute rmmod. rmmod not use --force. Log: root:~# rmmod cpuidle-e500 incs[9], decs[1] rmmod: can't unload 'cpuidle_e500': Resource temporarily unavailable Signed-off-by: Wang Dongsheng dongsheng.w...@freescale.com Can you please check the current linux-next branch of the linux-pm.git tree and see if that doesn't conflict with the material in there? Also please explain in the changelog how your changes help to fix the problem. Yes, Linux-next branch also have this problem. Should I base on Linux-next to fix this problem? Thanks. - dongsheng ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH v2 1/2] powerpc: add Book E support to 64-bit hibernation
From: Wood Scott-B07421 Sent: Saturday, July 13, 2013 5:49 To: Wang Dongsheng-B40534 Cc: b...@kernel.crashing.org; linuxppc-dev@lists.ozlabs.org; Wang Dongsheng-B40534 Subject: Re: [PATCH v2 1/2] powerpc: add Book E support to 64-bit hibernation On 07/11/2013 11:58:08 PM, Dongsheng Wang wrote: + /* Invalidate all tlbs */ + bl _tlbil_all Again, this will break on non-booke. -Scott Thanks. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 2/2] powerpc/hibernate: add restore mmu context after resume
-Original Message-
From: Wood Scott-B07421
Sent: Thursday, July 11, 2013 5:43 AM
To: Wang Dongsheng-B40534
Cc: Wang Dongsheng-B40534; b...@kernel.crashing.org; Wood Scott-B07421;
johan...@sipsolutions.net; an...@enomsg.org; ga...@kernel.crashing.org;
linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH 2/2] powerpc/hibernate: add restore mmu context after
resume
On 07/10/2013 05:11:54 AM, Wang Dongsheng-B40534 wrote:
Hi scott ben,
About this patch do you have any suggestions?
Thanks
- dongsheng
-Original Message-
From: Wang Dongsheng-B40534
Sent: Sunday, June 09, 2013 6:38 PM
To: b...@kernel.crashing.org
Cc: johan...@sipsolutions.net; an...@enomsg.org; Wood Scott-B07421;
ga...@kernel.crashing.org; linuxppc-dev@lists.ozlabs.org; Wang
Dongsheng-
B40534
Subject: [PATCH 2/2] powerpc/hibernate: add restore mmu context
after
resume
add restore_mmu_context to replace switch_mmu_context in
restore_processor_state, because the switch_mmu_context will do a
whole pile of stuff that are probably completely unnecessary.
There just need to restore the existing process context, and
invalidate TLB for boot core.
Signed-off-by: Wang Dongsheng dongsheng.w...@freescale.com
---
arch/powerpc/include/asm/tlbflush.h | 2 ++
arch/powerpc/kernel/swsusp.c| 4 +---
arch/powerpc/mm/tlb_nohash.c| 12
3 files changed, 15 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/include/asm/tlbflush.h
b/arch/powerpc/include/asm/tlbflush.h
index 61a5927..c401fe3 100644
--- a/arch/powerpc/include/asm/tlbflush.h
+++ b/arch/powerpc/include/asm/tlbflush.h
@@ -44,6 +44,8 @@ extern void local_flush_tlb_page(struct
vm_area_struct
*vma, unsigned long vmadd
extern void __local_flush_tlb_page(struct mm_struct *mm, unsigned
long
vmaddr,
int tsize, int ind);
+extern void restore_mmu_context(void);
+
#ifdef CONFIG_SMP
extern void flush_tlb_mm(struct mm_struct *mm); extern void
flush_tlb_page(struct vm_area_struct *vma, unsigned
long
vmaddr);
diff --git a/arch/powerpc/kernel/swsusp.c
b/arch/powerpc/kernel/swsusp.c
index eae33e1..0b104d7 100644
--- a/arch/powerpc/kernel/swsusp.c
+++ b/arch/powerpc/kernel/swsusp.c
@@ -32,7 +32,5 @@ void save_processor_state(void)
void restore_processor_state(void)
{
-#ifdef CONFIG_PPC32
- switch_mmu_context(current-active_mm, current-active_mm);
-#endif
+ restore_mmu_context();
}
diff --git a/arch/powerpc/mm/tlb_nohash.c
b/arch/powerpc/mm/tlb_nohash.c
index df32a83..a5a0708 100644
--- a/arch/powerpc/mm/tlb_nohash.c
+++ b/arch/powerpc/mm/tlb_nohash.c
@@ -39,10 +39,12 @@
#include linux/of_fdt.h
#include linux/hugetlb.h
+#include asm/current.h
#include asm/tlbflush.h
#include asm/tlb.h
#include asm/code-patching.h
#include asm/hugetlb.h
+#include asm/mmu_context.h
#include mmu_decl.h
@@ -193,6 +195,16 @@ void local_flush_tlb_page(struct
vm_area_struct *vma,
unsigned long vmaddr)
}
EXPORT_SYMBOL(local_flush_tlb_page);
+void restore_mmu_context(void)
+{
+ struct mm_struct *mm = current-active_mm;
+
+ set_context(mm-context.id, mm-pgd);
+
+ _tlbil_all();
+}
+EXPORT_SYMBOL(restore_mmu_context);
What about targets that don't use tlb_nohash.c?
Yes, you are right, if we used PPC_STD_MMU, compilation error will occur.
And _tlbil_all should be remove, because all of the tlb already invalidated in
swsusp_*.S .
So we should invalid tlb in swsusp_asm64.S swsusp_booke.S on freescale
platform.
How about add restore_mmu_context(struct mm_struct* mm) into
arch/powerpc/include/asm/mmu_context.h
Path: arch/powerpc/include/asm/mmu_context.h
static void restore_mmu_context(struct mm_struct *mm)
{
set_context(mm-context.id, mm-pgd);
}
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [RFC 2/2] powerpc/cputable: add wait feature for CPU kernel features
-Original Message- From: Benjamin Herrenschmidt [mailto:b...@kernel.crashing.org] Sent: Wednesday, July 10, 2013 5:23 PM To: Wang Dongsheng-B40534 Cc: Wood Scott-B07421; ga...@kernel.crashing.org; Zhao Chenhui-B35336; Li Yang-R58472 Subject: Re: [RFC 2/2] powerpc/cputable: add wait feature for CPU kernel features On Wed, 2013-07-10 at 16:27 +0800, Dongsheng Wang wrote: From: Wang Dongsheng dongsheng.w...@freescale.com This is missing an explanation of what that feature bit means... possibly with a description of the corresponding HW feature. Ben. Yes, the wait instructions is for cpu idle, It will be make cpu into low power mode, like DOZE NAP. Each thread have this. Signed-off-by: Wang Dongsheng dongsheng.w...@freescale.com diff --git a/arch/powerpc/include/asm/cputable.h b/arch/powerpc/include/asm/cputable.h index 6f3887d..0a8d0cb 100644 --- a/arch/powerpc/include/asm/cputable.h +++ b/arch/powerpc/include/asm/cputable.h @@ -138,6 +138,7 @@ extern const char *powerpc_base_platform; #define CPU_FTR_NOEXECUTE ASM_CONST(0x1000) #define CPU_FTR_INDEXED_DCRASM_CONST(0x2000) #define CPU_FTR_EMB_HV ASM_CONST(0x4000) +#define CPU_FTR_CAN_WAIT ASM_CONST(0x8000) /* * Add the 64-bit processor unique features in the top half of the word; @@ -250,9 +251,11 @@ extern const char *powerpc_base_platform; #ifndef CONFIG_BDI_SWITCH #define CPU_FTR_MAYBE_CAN_DOZE CPU_FTR_CAN_DOZE #define CPU_FTR_MAYBE_CAN_NAP CPU_FTR_CAN_NAP +#define CPU_FTR_MAYBE_CAN_WAIT CPU_FTR_CAN_WAIT #else #define CPU_FTR_MAYBE_CAN_DOZE 0 #define CPU_FTR_MAYBE_CAN_NAP 0 +#define CPU_FTR_MAYBE_CAN_WAIT 0 #endif #define CLASSIC_PPC (!defined(CONFIG_8xx) !defined(CONFIG_4xx) \ @@ -370,15 +373,17 @@ extern const char *powerpc_base_platform; CPU_FTR_NODSISRALIGN | CPU_FTR_NOEXECUTE) #define CPU_FTRS_E500MC(CPU_FTR_USE_TB | CPU_FTR_NODSISRALIGN | \ CPU_FTR_L2CSR | CPU_FTR_LWSYNC | CPU_FTR_NOEXECUTE | \ - CPU_FTR_DBELL | CPU_FTR_DEBUG_LVL_EXC | CPU_FTR_EMB_HV) + CPU_FTR_DBELL | CPU_FTR_DEBUG_LVL_EXC | CPU_FTR_EMB_HV | \ + CPU_FTR_MAYBE_CAN_WAIT) #define CPU_FTRS_E5500 (CPU_FTR_USE_TB | CPU_FTR_NODSISRALIGN | \ CPU_FTR_L2CSR | CPU_FTR_LWSYNC | CPU_FTR_NOEXECUTE | \ CPU_FTR_DBELL | CPU_FTR_POPCNTB | CPU_FTR_POPCNTD | \ - CPU_FTR_DEBUG_LVL_EXC | CPU_FTR_EMB_HV) + CPU_FTR_DEBUG_LVL_EXC | CPU_FTR_EMB_HV | CPU_FTR_MAYBE_CAN_WAIT) #define CPU_FTRS_E6500 (CPU_FTR_USE_TB | CPU_FTR_NODSISRALIGN | \ CPU_FTR_L2CSR | CPU_FTR_LWSYNC | CPU_FTR_NOEXECUTE | \ CPU_FTR_DBELL | CPU_FTR_POPCNTB | CPU_FTR_POPCNTD | \ - CPU_FTR_DEBUG_LVL_EXC | CPU_FTR_EMB_HV | CPU_FTR_ALTIVEC_COMP) + CPU_FTR_DEBUG_LVL_EXC | CPU_FTR_EMB_HV | CPU_FTR_ALTIVEC_COMP | \ + CPU_FTR_MAYBE_CAN_WAIT) #define CPU_FTRS_GENERIC_32(CPU_FTR_COMMON | CPU_FTR_NODSISRALIGN) /* 64-bit CPUs */ ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 1/2] powerpc: add Book E support to 64-bit hibernation
Hi scott, Could you apply this patch? Thanks. -dongsheng -Original Message- From: Wang Dongsheng-B40534 Sent: Sunday, June 09, 2013 6:38 PM To: b...@kernel.crashing.org Cc: johan...@sipsolutions.net; an...@enomsg.org; Wood Scott-B07421; ga...@kernel.crashing.org; linuxppc-dev@lists.ozlabs.org; Wang Dongsheng- B40534 Subject: [PATCH 1/2] powerpc: add Book E support to 64-bit hibernation Update the 64-bit hibernation code to support Book E CPUs. Some registers and instructions are not defined for Book3e (SDR reg, tlbia instruction). SDR: Storage Description Register. Book3S and Book3E have different address translation mode, we do not need HTABORG HTABSIZE to translate virtual address to real address. More registers are saved in BookE-64bit.(TCR, SPRGx, ...) Signed-off-by: Wang Dongsheng dongsheng.w...@freescale.com --- * History: * Wood Scott(A): Please investigate the issue of whether we are loading *kernel module code in this step * R: Kernel will allocate the memory for module code segment and data *segment. First allocate a memory, and copy the umod to hdr members *of the struct load_info. Due to the temporary assigned module belongs *to the kernel space, so it belongs to the kernel data. * *The kernel of all data will be saved when hibernation suspend. So *the module which has already been inserted will be saved. arch/powerpc/kernel/swsusp_asm64.S | 64 -- 1 file changed, 62 insertions(+), 2 deletions(-) diff --git a/arch/powerpc/kernel/swsusp_asm64.S b/arch/powerpc/kernel/swsusp_asm64.S index 86ac1d9..608e4ceb 100644 --- a/arch/powerpc/kernel/swsusp_asm64.S +++ b/arch/powerpc/kernel/swsusp_asm64.S @@ -46,10 +46,29 @@ #define SL_r29 0xe8 #define SL_r30 0xf0 #define SL_r31 0xf8 -#define SL_SIZE SL_r31+8 +#define SL_SPRG0 0x100 +#define SL_SPRG1 0x108 +#define SL_SPRG2 0x110 +#define SL_SPRG3 0x118 +#define SL_SPRG4 0x120 +#define SL_SPRG5 0x128 +#define SL_SPRG6 0x130 +#define SL_SPRG7 0x138 +#define SL_TCR 0x140 +#define SL_SIZE SL_TCR+8 /* these macros rely on the save area being * pointed to by r11 */ + +#define SAVE_SPR(register) \ + mfspr r0,SPRN_##register ;\ + std r0,SL_##register(r11) +#define RESTORE_SPR(register)\ + ld r0,SL_##register(r11) ;\ + mtspr SPRN_##register,r0 +#define RESTORE_SPRG(n) \ + ld r0,SL_SPRG##n(r11) ;\ + mtsprg n,r0 #define SAVE_SPECIAL(special)\ mf##special r0 ;\ std r0, SL_##special(r11) @@ -103,8 +122,21 @@ _GLOBAL(swsusp_arch_suspend) SAVE_REGISTER(r30) SAVE_REGISTER(r31) SAVE_SPECIAL(MSR) - SAVE_SPECIAL(SDR1) SAVE_SPECIAL(XER) +#ifdef CONFIG_PPC_BOOK3S_64 + SAVE_SPECIAL(SDR1) +#else + SAVE_SPR(TCR) + /* Save SPRGs */ + SAVE_SPR(SPRG0) + SAVE_SPR(SPRG1) + SAVE_SPR(SPRG2) + SAVE_SPR(SPRG3) + SAVE_SPR(SPRG4) + SAVE_SPR(SPRG5) + SAVE_SPR(SPRG6) + SAVE_SPR(SPRG7) +#endif /* we push the stack up 128 bytes but don't store the * stack pointer on the stack like a real stackframe */ @@ -151,6 +183,7 @@ copy_page_loop: bne+copyloop nothing_to_copy: +#ifdef CONFIG_PPC_BOOK3S_64 /* flush caches */ lis r3, 0x10 mtctr r3 @@ -167,6 +200,7 @@ nothing_to_copy: sync tlbia +#endif ld r11,swsusp_save_area_ptr@toc(r2) @@ -208,16 +242,42 @@ nothing_to_copy: RESTORE_REGISTER(r29) RESTORE_REGISTER(r30) RESTORE_REGISTER(r31) + +#ifdef CONFIG_PPC_BOOK3S_64 /* can't use RESTORE_SPECIAL(MSR) */ ld r0, SL_MSR(r11) mtmsrd r0, 0 RESTORE_SPECIAL(SDR1) +#else + /* Save SPRGs */ + RESTORE_SPRG(0) + RESTORE_SPRG(1) + RESTORE_SPRG(2) + RESTORE_SPRG(3) + RESTORE_SPRG(4) + RESTORE_SPRG(5) + RESTORE_SPRG(6) + RESTORE_SPRG(7) + + RESTORE_SPECIAL(MSR) + + /* Restore TCR and clear any pending bits in TSR. */ + RESTORE_SPR(TCR) + lis r0, (TSR_ENW | TSR_WIS | TSR_DIS | TSR_FIS)@h + mtspr SPRN_TSR,r0 + + /* Kick decrementer */ + li r0,1 + mtdec r0 +#endif RESTORE_SPECIAL(XER) sync addir1,r1,-128 +#ifdef CONFIG_PPC_BOOK3S_64 bl slb_flush_and_rebolt +#endif bl do_after_copyback addir1,r1,128 -- 1.8.0 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [RFC 2/2] powerpc/cputable: add wait feature for CPU kernel features
-Original Message- From: Benjamin Herrenschmidt [mailto:b...@kernel.crashing.org] Sent: Wednesday, July 10, 2013 5:33 PM To: Wang Dongsheng-B40534 Cc: Wood Scott-B07421; ga...@kernel.crashing.org; Zhao Chenhui-B35336; Li Yang-R58472; linuxppc-dev@lists.ozlabs.org Subject: Re: [RFC 2/2] powerpc/cputable: add wait feature for CPU kernel features On Wed, 2013-07-10 at 09:29 +, Wang Dongsheng-B40534 wrote: Yes, the wait instructions is for cpu idle, It will be make cpu into low power mode, like DOZE NAP. Each thread have this. I don't need you to tell me by email, I need you to put a proper comment in the patch submission so it ends up in the repository and if possible a bit more detailed than that. Ben. Ok, Thanks ben. I will add a description for next RFC patch. - dongsheng ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 1/2] powerpc: add Book E support to 64-bit hibernation
-Original Message- From: Benjamin Herrenschmidt [mailto:b...@kernel.crashing.org] Sent: Wednesday, July 10, 2013 5:52 PM To: Wang Dongsheng-B40534 Cc: Wood Scott-B07421; johan...@sipsolutions.net; an...@enomsg.org; ga...@kernel.crashing.org; linuxppc-dev@lists.ozlabs.org Subject: Re: [PATCH 1/2] powerpc: add Book E support to 64-bit hibernation On Wed, 2013-07-10 at 09:41 +, Wang Dongsheng-B40534 wrote: Hi scott, Could you apply this patch? There were a numbre of comments, were there addressed ? Do you need to save all the SPRGs for example ? Ben. Um...yes, sorry, not all of the SPRGs. the discussion about SPRG1 and SPRG2. I can fix them, just to save SRPG1 SPRG2. But those registers can be used by software, I think those register should be save, even now some SPRG register not be use. Thanks. -dongsheng -Original Message- From: Wang Dongsheng-B40534 Sent: Sunday, June 09, 2013 6:38 PM To: b...@kernel.crashing.org Cc: johan...@sipsolutions.net; an...@enomsg.org; Wood Scott-B07421; ga...@kernel.crashing.org; linuxppc-dev@lists.ozlabs.org; Wang Dongsheng- B40534 Subject: [PATCH 1/2] powerpc: add Book E support to 64-bit hibernation Update the 64-bit hibernation code to support Book E CPUs. Some registers and instructions are not defined for Book3e (SDR reg, tlbia instruction). SDR: Storage Description Register. Book3S and Book3E have different address translation mode, we do not need HTABORG HTABSIZE to translate virtual address to real address. More registers are saved in BookE-64bit.(TCR, SPRGx, ...) Signed-off-by: Wang Dongsheng dongsheng.w...@freescale.com --- * History: * Wood Scott(A): Please investigate the issue of whether we are loading *kernel module code in this step * R: Kernel will allocate the memory for module code segment and data *segment. First allocate a memory, and copy the umod to hdr members *of the struct load_info. Due to the temporary assigned module belongs *to the kernel space, so it belongs to the kernel data. * *The kernel of all data will be saved when hibernation suspend. So *the module which has already been inserted will be saved. arch/powerpc/kernel/swsusp_asm64.S | 64 -- 1 file changed, 62 insertions(+), 2 deletions(-) diff --git a/arch/powerpc/kernel/swsusp_asm64.S b/arch/powerpc/kernel/swsusp_asm64.S index 86ac1d9..608e4ceb 100644 --- a/arch/powerpc/kernel/swsusp_asm64.S +++ b/arch/powerpc/kernel/swsusp_asm64.S @@ -46,10 +46,29 @@ #define SL_r29 0xe8 #define SL_r30 0xf0 #define SL_r31 0xf8 -#define SL_SIZE SL_r31+8 +#define SL_SPRG0 0x100 +#define SL_SPRG1 0x108 +#define SL_SPRG2 0x110 +#define SL_SPRG3 0x118 +#define SL_SPRG4 0x120 +#define SL_SPRG5 0x128 +#define SL_SPRG6 0x130 +#define SL_SPRG7 0x138 +#define SL_TCR 0x140 +#define SL_SIZE SL_TCR+8 /* these macros rely on the save area being * pointed to by r11 */ + +#define SAVE_SPR(register) \ + mfspr r0,SPRN_##register ;\ + std r0,SL_##register(r11) +#define RESTORE_SPR(register)\ + ld r0,SL_##register(r11) ;\ + mtspr SPRN_##register,r0 +#define RESTORE_SPRG(n) \ + ld r0,SL_SPRG##n(r11) ;\ + mtsprg n,r0 #define SAVE_SPECIAL(special)\ mf##special r0 ;\ std r0, SL_##special(r11) @@ -103,8 +122,21 @@ _GLOBAL(swsusp_arch_suspend) SAVE_REGISTER(r30) SAVE_REGISTER(r31) SAVE_SPECIAL(MSR) - SAVE_SPECIAL(SDR1) SAVE_SPECIAL(XER) +#ifdef CONFIG_PPC_BOOK3S_64 + SAVE_SPECIAL(SDR1) +#else + SAVE_SPR(TCR) + /* Save SPRGs */ + SAVE_SPR(SPRG0) + SAVE_SPR(SPRG1) + SAVE_SPR(SPRG2) + SAVE_SPR(SPRG3) + SAVE_SPR(SPRG4) + SAVE_SPR(SPRG5) + SAVE_SPR(SPRG6) + SAVE_SPR(SPRG7) +#endif /* we push the stack up 128 bytes but don't store the * stack pointer on the stack like a real stackframe */ @@ -151,6 +183,7 @@ copy_page_loop: bne+copyloop nothing_to_copy: +#ifdef CONFIG_PPC_BOOK3S_64 /* flush caches */ lis r3, 0x10 mtctr r3 @@ -167,6 +200,7 @@ nothing_to_copy: sync tlbia +#endif ld r11,swsusp_save_area_ptr@toc(r2) @@ -208,16 +242,42 @@ nothing_to_copy: RESTORE_REGISTER(r29) RESTORE_REGISTER(r30) RESTORE_REGISTER(r31) + +#ifdef CONFIG_PPC_BOOK3S_64 /* can't use RESTORE_SPECIAL(MSR) */ ld r0, SL_MSR(r11) mtmsrd r0, 0 RESTORE_SPECIAL(SDR1) +#else + /* Save SPRGs */ + RESTORE_SPRG(0) + RESTORE_SPRG(1) + RESTORE_SPRG(2) + RESTORE_SPRG(3) + RESTORE_SPRG(4) + RESTORE_SPRG(5
RE: [PATCH 2/2] powerpc/hibernate: add restore mmu context after resume
Hi scott ben,
About this patch do you have any suggestions?
Thanks
- dongsheng
-Original Message-
From: Wang Dongsheng-B40534
Sent: Sunday, June 09, 2013 6:38 PM
To: b...@kernel.crashing.org
Cc: johan...@sipsolutions.net; an...@enomsg.org; Wood Scott-B07421;
ga...@kernel.crashing.org; linuxppc-dev@lists.ozlabs.org; Wang Dongsheng-
B40534
Subject: [PATCH 2/2] powerpc/hibernate: add restore mmu context after
resume
add restore_mmu_context to replace switch_mmu_context in
restore_processor_state, because the switch_mmu_context will do
a whole pile of stuff that are probably completely unnecessary.
There just need to restore the existing process context, and
invalidate TLB for boot core.
Signed-off-by: Wang Dongsheng dongsheng.w...@freescale.com
---
arch/powerpc/include/asm/tlbflush.h | 2 ++
arch/powerpc/kernel/swsusp.c| 4 +---
arch/powerpc/mm/tlb_nohash.c| 12
3 files changed, 15 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/include/asm/tlbflush.h
b/arch/powerpc/include/asm/tlbflush.h
index 61a5927..c401fe3 100644
--- a/arch/powerpc/include/asm/tlbflush.h
+++ b/arch/powerpc/include/asm/tlbflush.h
@@ -44,6 +44,8 @@ extern void local_flush_tlb_page(struct vm_area_struct
*vma, unsigned long vmadd
extern void __local_flush_tlb_page(struct mm_struct *mm, unsigned long
vmaddr,
int tsize, int ind);
+extern void restore_mmu_context(void);
+
#ifdef CONFIG_SMP
extern void flush_tlb_mm(struct mm_struct *mm);
extern void flush_tlb_page(struct vm_area_struct *vma, unsigned long
vmaddr);
diff --git a/arch/powerpc/kernel/swsusp.c b/arch/powerpc/kernel/swsusp.c
index eae33e1..0b104d7 100644
--- a/arch/powerpc/kernel/swsusp.c
+++ b/arch/powerpc/kernel/swsusp.c
@@ -32,7 +32,5 @@ void save_processor_state(void)
void restore_processor_state(void)
{
-#ifdef CONFIG_PPC32
- switch_mmu_context(current-active_mm, current-active_mm);
-#endif
+ restore_mmu_context();
}
diff --git a/arch/powerpc/mm/tlb_nohash.c b/arch/powerpc/mm/tlb_nohash.c
index df32a83..a5a0708 100644
--- a/arch/powerpc/mm/tlb_nohash.c
+++ b/arch/powerpc/mm/tlb_nohash.c
@@ -39,10 +39,12 @@
#include linux/of_fdt.h
#include linux/hugetlb.h
+#include asm/current.h
#include asm/tlbflush.h
#include asm/tlb.h
#include asm/code-patching.h
#include asm/hugetlb.h
+#include asm/mmu_context.h
#include mmu_decl.h
@@ -193,6 +195,16 @@ void local_flush_tlb_page(struct vm_area_struct *vma,
unsigned long vmaddr)
}
EXPORT_SYMBOL(local_flush_tlb_page);
+void restore_mmu_context(void)
+{
+ struct mm_struct *mm = current-active_mm;
+
+ set_context(mm-context.id, mm-pgd);
+
+ _tlbil_all();
+}
+EXPORT_SYMBOL(restore_mmu_context);
+
/*
* And here are the SMP non-local implementations
*/
--
1.8.0
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH v3 1/4] powerpc/mpic: add irq_set_wake support
Hi Benjamin Kumar scott, I am not sure who can apply these patches... Scott already ACK these patches. A few days ago Scott have a pull request, Scott can accept them? Or ? [v3,1/4] powerpc/mpic: add irq_set_wake support http://patchwork.ozlabs.org/patch/234934/ [v3,2/4] powerpc/mpic: add global timer support http://patchwork.ozlabs.org/patch/234935/ [v3,3/4] powerpc/mpic: create mpic subsystem object http://patchwork.ozlabs.org/patch/234936 [v3,4/4] powerpc/fsl: add MPIC timer wakeup support http://patchwork.ozlabs.org/patch/234937/ Thanks. -dongsheng -Original Message- From: Wang Dongsheng-B40534 Sent: Sunday, June 09, 2013 4:20 PM To: 'Benjamin Herrenschmidt' Cc: linuxppc-dev@lists.ozlabs.org; Wood Scott-B07421; ga...@kernel.crashing.org Subject: RE: [PATCH v3 1/4] powerpc/mpic: add irq_set_wake support Hi ben, Could you apply these patches? Thanks. :) - dongsheng -Original Message- From: Benjamin Herrenschmidt [mailto:b...@kernel.crashing.org] Sent: Monday, May 13, 2013 1:00 PM To: Wang Dongsheng-B40534 Cc: linuxppc-dev@lists.ozlabs.org; Wood Scott-B07421; ga...@kernel.crashing.org Subject: Re: [PATCH v3 1/4] powerpc/mpic: add irq_set_wake support On Mon, 2013-05-13 at 04:25 +, Wang Dongsheng-B40534 wrote: Hi Benjamin, Could you apply these patches? I'll have a look, I was assuming Kumar would take them but since not I'll queue them up. Cheers, Ben. Scott already ACK. [v3,1/4] powerpc/mpic: add irq_set_wake support http://patchwork.ozlabs.org/patch/234934/ [v3,2/4] powerpc/mpic: add global timer support http://patchwork.ozlabs.org/patch/234935/ [v3,3/4] powerpc/mpic: create mpic subsystem object http://patchwork.ozlabs.org/patch/234936/ [v3,4/4] powerpc/fsl: add MPIC timer wakeup support http://patchwork.ozlabs.org/patch/234937/ Thanks. -Original Message- From: Wang Dongsheng-B40534 Sent: Friday, May 03, 2013 9:54 AM To: 'ga...@kernel.crashing.org' Cc: 'linuxppc-dev@lists.ozlabs.org'; Wood Scott-B07421; 'b...@kernel.crashing.org' Subject: RE: [PATCH v3 1/4] powerpc/mpic: add irq_set_wake support Hi Kumar, Could you apply these patches? Thanks. -Original Message- From: Wang Dongsheng-B40534 Sent: Tuesday, April 23, 2013 6:10 PM To: ga...@kernel.crashing.org Cc: linuxppc-dev@lists.ozlabs.org; Wood Scott-B07421 Subject: RE: [PATCH v3 1/4] powerpc/mpic: add irq_set_wake support Hi Kumar, Could you apply these patches? Thanks. [v3,1/4] powerpc/mpic: add irq_set_wake support http://patchwork.ozlabs.org/patch/234934/ [v3,2/4] powerpc/mpic: add global timer support http://patchwork.ozlabs.org/patch/234935/ [v3,3/4] powerpc/mpic: create mpic subsystem object http://patchwork.ozlabs.org/patch/234936/ [v3,4/4] powerpc/fsl: add MPIC timer wakeup support http://patchwork.ozlabs.org/patch/234937/ -Original Message- From: Wood Scott-B07421 Sent: Wednesday, April 17, 2013 7:30 AM To: Wang Dongsheng-B40534 Cc: Wood Scott-B07421; linuxppc-dev@lists.ozlabs.org; ga...@kernel.crashing.org Subject: Re: [PATCH v3 1/4] powerpc/mpic: add irq_set_wake support ACK -Scott On 04/16/2013 05:58:52 AM, Wang Dongsheng-B40534 wrote: Hi scott, Could you ACK these patches? [PATCH v3 2/4] powerpc/mpic: add global timer support [PATCH v3 3/4] powerpc/mpic: create mpic subsystem object [PATCH v3 4/4] powerpc/fsl: add MPIC timer wakeup support Thanks. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH v3 1/4] powerpc/mpic: add irq_set_wake support
-Original Message- From: Benjamin Herrenschmidt [mailto:b...@kernel.crashing.org] Sent: Monday, July 01, 2013 10:49 AM To: Wang Dongsheng-B40534 Cc: Wood Scott-B07421; ga...@kernel.crashing.org; linuxppc- d...@lists.ozlabs.org Subject: Re: [PATCH v3 1/4] powerpc/mpic: add irq_set_wake support On Mon, 2013-07-01 at 02:38 +, Wang Dongsheng-B40534 wrote: Hi Benjamin Kumar scott, I am not sure who can apply these patches... Scott already ACK these patches. A few days ago Scott have a pull request, Scott can accept them? Or ? I'm happy to pull from Scott. Thanks Ben. -dongsheng Do somebody other than me has access to an old Mac (a G5 for example) to check they don't break anything there ? Ben. [v3,1/4] powerpc/mpic: add irq_set_wake support http://patchwork.ozlabs.org/patch/234934/ [v3,2/4] powerpc/mpic: add global timer support http://patchwork.ozlabs.org/patch/234935/ [v3,3/4] powerpc/mpic: create mpic subsystem object http://patchwork.ozlabs.org/patch/234936 [v3,4/4] powerpc/fsl: add MPIC timer wakeup support http://patchwork.ozlabs.org/patch/234937/ Thanks. -dongsheng -Original Message- From: Wang Dongsheng-B40534 Sent: Sunday, June 09, 2013 4:20 PM To: 'Benjamin Herrenschmidt' Cc: linuxppc-dev@lists.ozlabs.org; Wood Scott-B07421; ga...@kernel.crashing.org Subject: RE: [PATCH v3 1/4] powerpc/mpic: add irq_set_wake support Hi ben, Could you apply these patches? Thanks. :) - dongsheng -Original Message- From: Benjamin Herrenschmidt [mailto:b...@kernel.crashing.org] Sent: Monday, May 13, 2013 1:00 PM To: Wang Dongsheng-B40534 Cc: linuxppc-dev@lists.ozlabs.org; Wood Scott-B07421; ga...@kernel.crashing.org Subject: Re: [PATCH v3 1/4] powerpc/mpic: add irq_set_wake support On Mon, 2013-05-13 at 04:25 +, Wang Dongsheng-B40534 wrote: Hi Benjamin, Could you apply these patches? I'll have a look, I was assuming Kumar would take them but since not I'll queue them up. Cheers, Ben. Scott already ACK. [v3,1/4] powerpc/mpic: add irq_set_wake support http://patchwork.ozlabs.org/patch/234934/ [v3,2/4] powerpc/mpic: add global timer support http://patchwork.ozlabs.org/patch/234935/ [v3,3/4] powerpc/mpic: create mpic subsystem object http://patchwork.ozlabs.org/patch/234936/ [v3,4/4] powerpc/fsl: add MPIC timer wakeup support http://patchwork.ozlabs.org/patch/234937/ Thanks. -Original Message- From: Wang Dongsheng-B40534 Sent: Friday, May 03, 2013 9:54 AM To: 'ga...@kernel.crashing.org' Cc: 'linuxppc-dev@lists.ozlabs.org'; Wood Scott-B07421; 'b...@kernel.crashing.org' Subject: RE: [PATCH v3 1/4] powerpc/mpic: add irq_set_wake support Hi Kumar, Could you apply these patches? Thanks. -Original Message- From: Wang Dongsheng-B40534 Sent: Tuesday, April 23, 2013 6:10 PM To: ga...@kernel.crashing.org Cc: linuxppc-dev@lists.ozlabs.org; Wood Scott-B07421 Subject: RE: [PATCH v3 1/4] powerpc/mpic: add irq_set_wake support Hi Kumar, Could you apply these patches? Thanks. [v3,1/4] powerpc/mpic: add irq_set_wake support http://patchwork.ozlabs.org/patch/234934/ [v3,2/4] powerpc/mpic: add global timer support http://patchwork.ozlabs.org/patch/234935/ [v3,3/4] powerpc/mpic: create mpic subsystem object http://patchwork.ozlabs.org/patch/234936/ [v3,4/4] powerpc/fsl: add MPIC timer wakeup support http://patchwork.ozlabs.org/patch/234937/ -Original Message- From: Wood Scott-B07421 Sent: Wednesday, April 17, 2013 7:30 AM To: Wang Dongsheng-B40534 Cc: Wood Scott-B07421; linuxppc-dev@lists.ozlabs.org; ga...@kernel.crashing.org Subject: Re: [PATCH v3 1/4] powerpc/mpic: add irq_set_wake support ACK -Scott On 04/16/2013 05:58:52 AM, Wang Dongsheng-B40534 wrote: Hi scott, Could you ACK these patches? [PATCH v3 2/4] powerpc/mpic: add global timer support [PATCH v3 3/4] powerpc/mpic: create mpic subsystem object [PATCH v3 4/4] powerpc/fsl: add MPIC timer wakeup support Thanks. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 1/2] powerpc: add Book E support to 64-bit hibernation
-Original Message- From: Wood Scott-B07421 Sent: Friday, June 14, 2013 12:51 AM To: Wang Dongsheng-B40534 Cc: Wood Scott-B07421; b...@kernel.crashing.org; johan...@sipsolutions.net; an...@enomsg.org; ga...@kernel.crashing.org; linuxppc-dev@lists.ozlabs.org Subject: Re: [PATCH 1/2] powerpc: add Book E support to 64-bit hibernation On 06/13/2013 04:55:43 AM, Wang Dongsheng-B40534 wrote: +#else + /* Save SPRGs */ + RESTORE_SPRG(0) + RESTORE_SPRG(1) + RESTORE_SPRG(2) + RESTORE_SPRG(3) + RESTORE_SPRG(4) + RESTORE_SPRG(5) + RESTORE_SPRG(6) + RESTORE_SPRG(7) Why do we need this on book3e and not on book3s? Book3e: SPRG1 used save paca, SPRG2 be defined SPRN_SPRG_TLB_EXFRAME,... I think those register should be save, even now some SPRG register not be use. Are those expected/allowed to change as a result of the restore? Those registers are used by software, some allowed to change. Exception handling is used in some registers, see exception-64e.h These registers can be modified and saved. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 1/2] powerpc: add Book E support to 64-bit hibernation
-Original Message- From: Wood Scott-B07421 Sent: Thursday, June 13, 2013 6:04 AM To: Wang Dongsheng-B40534 Cc: b...@kernel.crashing.org; johan...@sipsolutions.net; an...@enomsg.org; ga...@kernel.crashing.org; linuxppc-dev@lists.ozlabs.org; Wang Dongsheng- B40534 Subject: Re: [PATCH 1/2] powerpc: add Book E support to 64-bit hibernation On 06/09/2013 05:37:39 AM, Wang Dongsheng wrote: /* these macros rely on the save area being * pointed to by r11 */ + +#define SAVE_SPR(register) \ + mfspr r0,SPRN_##register ;\ + std r0,SL_##register(r11) +#define RESTORE_SPR(register) \ + ld r0,SL_##register(r11) ;\ + mtspr SPRN_##register,r0 +#define RESTORE_SPRG(n)\ + ld r0,SL_SPRG##n(r11) ;\ + mtsprg n,r0 #define SAVE_SPECIAL(special) \ mf##special r0 ;\ std r0, SL_##special(r11) Is there a particular SPR that you're trying to save, for which SAVE_SPECIAL doesn't work? Yes, like pid, tcr. +#else + /* Save SPRGs */ + RESTORE_SPRG(0) + RESTORE_SPRG(1) + RESTORE_SPRG(2) + RESTORE_SPRG(3) + RESTORE_SPRG(4) + RESTORE_SPRG(5) + RESTORE_SPRG(6) + RESTORE_SPRG(7) Why do we need this on book3e and not on book3s? Book3e: SPRG1 used save paca, SPRG2 be defined SPRN_SPRG_TLB_EXFRAME,... I think those register should be save, even now some SPRG register not be use. Book3s: Sorry, I not clear why book3s not do this. I think Anton or Ben could know the reason. + + RESTORE_SPECIAL(MSR) + + /* Restore TCR and clear any pending bits in TSR. */ + RESTORE_SPR(TCR) + lis r0, (TSR_ENW | TSR_WIS | TSR_DIS | TSR_FIS)@h + mtspr SPRN_TSR,r0 Please be internally consistent with whitespace after commas, even if the rest of the file is already inconsistent. :-P Thanks. + + /* Kick decrementer */ + li r0,1 + mtdec r0 Why doesn't book3s need to kick the decrementer? Sorry, I not clear why book3s not do this. I think Anton or Ben could know the reason. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH v2 2/2] powerpc/hibernate: PPC64 fix user threads access to kernel space
-Original Message-
From: Benjamin Herrenschmidt [mailto:b...@kernel.crashing.org]
Sent: Sunday, June 09, 2013 2:44 PM
To: Wang Dongsheng-B40534
Cc: johan...@sipsolutions.net; an...@enomsg.org; Wood Scott-B07421;
ga...@kernel.crashing.org; linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH v2 2/2] powerpc/hibernate: PPC64 fix user threads
access to kernel space
On Sun, 2013-06-09 at 13:22 +0800, Wang Dongsheng wrote:
If PID is used in the TLB, after hibernation resume, the user threads
will access to kernel space.
.../...
I think the explanation is way more convoluted and confusing here than
anything else.
Simply say that upon resume from hibernation, the MMU context needs to be
restored (this includes the PID register today it might include more if
we decided to pre-set some MAS for example
etc...) and be done with it.
Note that switch_mmu_context() used the way you do is quite full on, it
will do a whole pile of stuff that are probably completely unnecessary,
and in addition might still miss the need to completely flush the TLB
anyway.
I would suggest that instead, somebody adds the necessary routine to
tlb_nohash.c, something like restore_mmu_context() which will do that.
Thanks ben, This is a good idea.
We do not need to decide the current thread has a context in
restore_mmu_context().
Because the current has already get a context in hibernation suspend flow.
So we just need set set_context() in restore_mmu_context().
void restore_mmu_context(struct mm_struct *next) {
set_context(next-context.id, next-pgd);
}
-dongsheng
Cheers,
Ben.
Signed-off-by: Wang Dongsheng dongsheng.w...@freescale.com
---
arch/powerpc/kernel/swsusp.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/powerpc/kernel/swsusp.c
b/arch/powerpc/kernel/swsusp.c index eae33e1..1930e44 100644
--- a/arch/powerpc/kernel/swsusp.c
+++ b/arch/powerpc/kernel/swsusp.c
@@ -32,7 +32,5 @@ void save_processor_state(void)
void restore_processor_state(void)
{
-#ifdef CONFIG_PPC32
switch_mmu_context(current-active_mm, current-active_mm); -#endif
}
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH v2 2/2] powerpc/hibernate: PPC64 fix user threads access to kernel space
-Original Message-
From: Benjamin Herrenschmidt [mailto:b...@kernel.crashing.org]
Sent: Sunday, June 09, 2013 3:46 PM
To: Wang Dongsheng-B40534
Cc: johan...@sipsolutions.net; an...@enomsg.org; Wood Scott-B07421;
ga...@kernel.crashing.org; linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH v2 2/2] powerpc/hibernate: PPC64 fix user threads
access to kernel space
On Sun, 2013-06-09 at 07:44 +, Wang Dongsheng-B40534 wrote:
So we just need set set_context() in restore_mmu_context().
void restore_mmu_context(struct mm_struct *next) {
set_context(next-context.id, next-pgd); }
We probably also want to flush the TLB, just in case the boot kernel has
left something there (though I wouldn't expect it to have run userspace
it's not completely impossible).
Yes, but TLB has already invalidated.
See my other patch:
http://patchwork.ozlabs.org/patch/250006/
Cheers,
Ben.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH v3 1/4] powerpc/mpic: add irq_set_wake support
Hi ben, Could you apply these patches? Thanks. :) - dongsheng -Original Message- From: Benjamin Herrenschmidt [mailto:b...@kernel.crashing.org] Sent: Monday, May 13, 2013 1:00 PM To: Wang Dongsheng-B40534 Cc: linuxppc-dev@lists.ozlabs.org; Wood Scott-B07421; ga...@kernel.crashing.org Subject: Re: [PATCH v3 1/4] powerpc/mpic: add irq_set_wake support On Mon, 2013-05-13 at 04:25 +, Wang Dongsheng-B40534 wrote: Hi Benjamin, Could you apply these patches? I'll have a look, I was assuming Kumar would take them but since not I'll queue them up. Cheers, Ben. Scott already ACK. [v3,1/4] powerpc/mpic: add irq_set_wake support http://patchwork.ozlabs.org/patch/234934/ [v3,2/4] powerpc/mpic: add global timer support http://patchwork.ozlabs.org/patch/234935/ [v3,3/4] powerpc/mpic: create mpic subsystem object http://patchwork.ozlabs.org/patch/234936/ [v3,4/4] powerpc/fsl: add MPIC timer wakeup support http://patchwork.ozlabs.org/patch/234937/ Thanks. -Original Message- From: Wang Dongsheng-B40534 Sent: Friday, May 03, 2013 9:54 AM To: 'ga...@kernel.crashing.org' Cc: 'linuxppc-dev@lists.ozlabs.org'; Wood Scott-B07421; 'b...@kernel.crashing.org' Subject: RE: [PATCH v3 1/4] powerpc/mpic: add irq_set_wake support Hi Kumar, Could you apply these patches? Thanks. -Original Message- From: Wang Dongsheng-B40534 Sent: Tuesday, April 23, 2013 6:10 PM To: ga...@kernel.crashing.org Cc: linuxppc-dev@lists.ozlabs.org; Wood Scott-B07421 Subject: RE: [PATCH v3 1/4] powerpc/mpic: add irq_set_wake support Hi Kumar, Could you apply these patches? Thanks. [v3,1/4] powerpc/mpic: add irq_set_wake support http://patchwork.ozlabs.org/patch/234934/ [v3,2/4] powerpc/mpic: add global timer support http://patchwork.ozlabs.org/patch/234935/ [v3,3/4] powerpc/mpic: create mpic subsystem object http://patchwork.ozlabs.org/patch/234936/ [v3,4/4] powerpc/fsl: add MPIC timer wakeup support http://patchwork.ozlabs.org/patch/234937/ -Original Message- From: Wood Scott-B07421 Sent: Wednesday, April 17, 2013 7:30 AM To: Wang Dongsheng-B40534 Cc: Wood Scott-B07421; linuxppc-dev@lists.ozlabs.org; ga...@kernel.crashing.org Subject: Re: [PATCH v3 1/4] powerpc/mpic: add irq_set_wake support ACK -Scott On 04/16/2013 05:58:52 AM, Wang Dongsheng-B40534 wrote: Hi scott, Could you ACK these patches? [PATCH v3 2/4] powerpc/mpic: add global timer support [PATCH v3 3/4] powerpc/mpic: create mpic subsystem object [PATCH v3 4/4] powerpc/fsl: add MPIC timer wakeup support Thanks. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH] powerpc/mpc85xx: fix non-bootcpu cannot up after hibernation resume
Hi kumar, Could you apply this patche? Thanks. -dongsheng -Original Message- From: Anton Vorontsov [mailto:an...@scarybugs.org] On Behalf Of Anton Vorontsov Sent: Friday, May 24, 2013 1:34 AM To: Wang Dongsheng-B40534 Cc: pau...@samba.org; r...@sisk.pl; b...@kernel.crashing.org; johan...@sipsolutions.net; Wood Scott-B07421; Li Yang-R58472; Zhao Chenhui-B35336; linuxppc-dev@lists.ozlabs.org Subject: Re: [PATCH] powerpc/mpc85xx: fix non-bootcpu cannot up after hibernation resume Hi! On Tue, May 14, 2013 at 08:59:13AM +, Wang Dongsheng-B40534 wrote: I send to a wrong email address Anton Vorontsov avoront...@ru.mvista.com Add Anton Vorontsov anton.voront...@linaro.org to this email. I don't have any means to test it, but the patch itself looks good and the description makes sense. So, Reviewed-by: Anton Vorontsov an...@enomsg.org Thanks! Thanks all. -Original Message- From: Wang Dongsheng-B40534 Sent: Tuesday, May 14, 2013 4:06 PM To: avoront...@ru.mvista.com Cc: pau...@samba.org; r...@sisk.pl; b...@kernel.crashing.org; johan...@sipsolutions.net; Wood Scott-B07421; Li Yang-R58472; Zhao Chenhui-B35336; linuxppc-dev@lists.ozlabs.org; Wang Dongsheng-B40534 Subject: [PATCH] powerpc/mpc85xx: fix non-bootcpu cannot up after hibernation resume This problem belongs to the core synchronization issues. The cpu1 already updated spin_table values, but bootcore cannot get this value in time. After bootcpu hibiernation restore the pages. we are now running with the kernel data of the old kernel fully restored. if we reset the non-bootcpus that will be reset cache(tlb), the non-bootcpus will get new address(map virtual and physical address spaces). but bootcpu tlb cache still use boot kernel data, so we need to invalidate the bootcpu tlb cache make it to get new main memory data. log: Enabling non-boot CPUs ... smp_85xx_kick_cpu: timeout waiting for core 1 to reset smp: failed starting cpu 1 (rc -2) Error taking CPU1 up: -2 Signed-off-by: Wang Dongsheng dongsheng.w...@freescale.com diff --git a/arch/powerpc/kernel/swsusp_booke.S b/arch/powerpc/kernel/swsusp_booke.S index 11a3930..9503249 100644 --- a/arch/powerpc/kernel/swsusp_booke.S +++ b/arch/powerpc/kernel/swsusp_booke.S @@ -141,6 +141,19 @@ _GLOBAL(swsusp_arch_resume) lis r11,swsusp_save_area@h ori r11,r11,swsusp_save_area@l + /* + * The boot core get a virtual address, when the boot process, + * the virtual address corresponds to a physical address. After + * hibernation resume memory snapshots, The corresponding + * relationship between the virtual memory and physical memory + * might change again. We need to get a new page table. So we + * need to invalidate TLB after resume pages. + * + * Invalidations TLB Using tlbilx/tlbivax/MMUCSR0. + * tlbilx used here. + */ + bl _tlbil_all + lwz r4,SL_SPRG0(r11) mtsprg 0,r4 lwz r4,SL_SPRG1(r11) -- 1.8.0 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH v2 1/2] powerpc: add Book E support to 64-bit hibernation
Sorry, Please ignore this patch. This is replaced. Replace by: http://patchwork.ozlabs.org/patch/250032/ - dongsheng -Original Message- From: Wang Dongsheng-B40534 Sent: Sunday, June 09, 2013 1:21 PM To: johan...@sipsolutions.net; an...@enomsg.org; Wood Scott-B07421 Cc: ga...@kernel.crashing.org; linuxppc-dev@lists.ozlabs.org; Wang Dongsheng-B40534 Subject: [PATCH v2 1/2] powerpc: add Book E support to 64-bit hibernation Update the 64-bit hibernation code to support Book E CPUs. Some registers and instructions are not defined for Book3e (SDR reg, tlbia instruction). SDR: Storage Description Register. Book3S and Book3E have different address translation mode, we do not need HTABORG HTABSIZE to translate virtual address to real address. More registers are saved in BookE-64bit.(TCR, SPRGx, ...) Signed-off-by: Wang Dongsheng dongsheng.w...@freescale.com --- v2: * Add: _tlbil_all * * The boot core get a virtual address, when the boot process, * the virtual address corresponds to a physical address. After * hibernation resume memory snapshots, The corresponding * relationship between the virtual memory and physical memory * might change again. We need to get a new page table. So we * need to invalidate TLB after resume pages. * * Invalidations TLB Using tlbilx/tlbivax/MMUCSR0. * tlbilx used here. * * Add: save/restore PID * * We must restore PID register, because TLB will use PID. The * hibernation suspend flow is trapped from user space to kernel * space, the PID register is user thread pid. * * The hibernation resume is begin in kernel start flow, the PID * alway 0. After the kernel thread back to user thread, there is * not have context switch and the pid can not update, because the * kernel thread is trapped form user space. So if we did't restore * PID the user space of thread will be addressing in the kernel * space. * * There are two ways to restore PID: * 1/ In this file save/resotre PID register. * 2/ Form restore_processor_state to restore. this function will *do context switch. *switch_mmu_context(current-active_mm, current-active_mm) * * PPC32 Using the second method. For consistency reason, PPC64 * using the same way. * * History: * Wood Scott(A): Please investigate the issue of whether we are loading *kernel module code in this step * R: Kernel will allocate the memory for module code segment and data *segment. First allocate a memory, and copy the umod to hdr members *of the struct load_info. Due to the temporary assigned module belongs *to the kernel space, so it belongs to the kernel data. * *The kernel of all data will be saved when hibernation suspend. So *the module which has already been inserted will be saved. arch/powerpc/kernel/swsusp_asm64.S | 102 - 1 file changed, 100 insertions(+), 2 deletions(-) diff --git a/arch/powerpc/kernel/swsusp_asm64.S b/arch/powerpc/kernel/swsusp_asm64.S index 86ac1d9..c7e2b4a 100644 --- a/arch/powerpc/kernel/swsusp_asm64.S +++ b/arch/powerpc/kernel/swsusp_asm64.S @@ -46,10 +46,30 @@ #define SL_r29 0xe8 #define SL_r30 0xf0 #define SL_r31 0xf8 -#define SL_SIZE SL_r31+8 +#define SL_SPRG0 0x100 +#define SL_SPRG1 0x108 +#define SL_SPRG2 0x110 +#define SL_SPRG3 0x118 +#define SL_SPRG4 0x120 +#define SL_SPRG5 0x128 +#define SL_SPRG6 0x130 +#define SL_SPRG7 0x138 +#define SL_TCR 0x140 +#define SL_PID 0x148 +#define SL_SIZE SL_PID+8 /* these macros rely on the save area being * pointed to by r11 */ + +#define SAVE_SPR(register) \ + mfspr r0,SPRN_##register ;\ + std r0,SL_##register(r11) +#define RESTORE_SPR(register)\ + ld r0,SL_##register(r11) ;\ + mtspr SPRN_##register,r0 +#define RESTORE_SPRG(n) \ + ld r0,SL_SPRG##n(r11) ;\ + mtsprg n,r0 #define SAVE_SPECIAL(special)\ mf##special r0 ;\ std r0, SL_##special(r11) @@ -103,8 +123,22 @@ _GLOBAL(swsusp_arch_suspend) SAVE_REGISTER(r30) SAVE_REGISTER(r31) SAVE_SPECIAL(MSR) - SAVE_SPECIAL(SDR1) SAVE_SPECIAL(XER) +#ifdef CONFIG_PPC_BOOK3S_64 + SAVE_SPECIAL(SDR1) +#else + SAVE_SPR(TCR) + /* Save SPRGs */ + SAVE_SPR(SPRG0) + SAVE_SPR(SPRG1) + SAVE_SPR(SPRG2) + SAVE_SPR(SPRG3) + SAVE_SPR(SPRG4) + SAVE_SPR(SPRG5) + SAVE_SPR(SPRG6) + SAVE_SPR(SPRG7) + SAVE_SPR(PID); +#endif /* we push the stack up 128 bytes but don't store the * stack pointer on the stack like a real stackframe */ @@ -151,6 +185,7 @@ copy_page_loop: bne+copyloop nothing_to_copy: +#ifdef CONFIG_PPC_BOOK3S_64 /* flush caches */ lis
RE: [PATCH v2 2/2] powerpc/hibernate: PPC64 fix user threads access to kernel space
Sorry, Please ignore this patch.
This is replaced.
Replace by: http://patchwork.ozlabs.org/patch/250033/
- dongsheng
-Original Message-
From: Wang Dongsheng-B40534
Sent: Sunday, June 09, 2013 1:23 PM
To: b...@kernel.crashing.org; johan...@sipsolutions.net; an...@enomsg.org
Cc: Wood Scott-B07421; ga...@kernel.crashing.org; linuxppc-
d...@lists.ozlabs.org; Wang Dongsheng-B40534
Subject: [PATCH v2 2/2] powerpc/hibernate: PPC64 fix user threads access
to kernel space
If PID is used in the TLB, after hibernation resume, the user
threads will access to kernel space.
We must restore PID register, because TLB will use PID. The
hibernation suspend flow is trapped from user space to kernel
space, the PID register is user thread pid.
The hibernation resume is begin in kernel start flow, the PID
alway 0. After the kernel thread back to user thread, there is
not have context switch and the pid can not update, because the
kernel thread is trapped form user space. So if we did't restore
PID the user space of thread will be addressing in the kernel
space.
There are two ways to restore PID:
1/ In swsusp_arch_suspend/swsusp_arch_resume, save/resotre PID register.
2/ Form restore_processor_state to restore. this function will
do context switch.
switch_mmu_context(current-active_mm, current-active_mm)
PPC32 Using the second method. For consistency reason, PPC64 using
the same way.
Signed-off-by: Wang Dongsheng dongsheng.w...@freescale.com
---
arch/powerpc/kernel/swsusp.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/powerpc/kernel/swsusp.c b/arch/powerpc/kernel/swsusp.c
index eae33e1..1930e44 100644
--- a/arch/powerpc/kernel/swsusp.c
+++ b/arch/powerpc/kernel/swsusp.c
@@ -32,7 +32,5 @@ void save_processor_state(void)
void restore_processor_state(void)
{
-#ifdef CONFIG_PPC32
switch_mmu_context(current-active_mm, current-active_mm);
-#endif
}
--
1.8.0
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH] powerpc/mpc85xx: fix non-bootcpu cannot up after hibernation resume
Thanks anton. -Original Message- From: Anton Vorontsov [mailto:an...@scarybugs.org] On Behalf Of Anton Vorontsov Sent: Friday, May 24, 2013 1:34 AM To: Wang Dongsheng-B40534 Cc: pau...@samba.org; r...@sisk.pl; b...@kernel.crashing.org; johan...@sipsolutions.net; Wood Scott-B07421; Li Yang-R58472; Zhao Chenhui-B35336; linuxppc-dev@lists.ozlabs.org Subject: Re: [PATCH] powerpc/mpc85xx: fix non-bootcpu cannot up after hibernation resume Hi! On Tue, May 14, 2013 at 08:59:13AM +, Wang Dongsheng-B40534 wrote: I send to a wrong email address Anton Vorontsov avoront...@ru.mvista.com Add Anton Vorontsov anton.voront...@linaro.org to this email. I don't have any means to test it, but the patch itself looks good and the description makes sense. So, Reviewed-by: Anton Vorontsov an...@enomsg.org Thanks! Thanks all. -Original Message- From: Wang Dongsheng-B40534 Sent: Tuesday, May 14, 2013 4:06 PM To: avoront...@ru.mvista.com Cc: pau...@samba.org; r...@sisk.pl; b...@kernel.crashing.org; johan...@sipsolutions.net; Wood Scott-B07421; Li Yang-R58472; Zhao Chenhui-B35336; linuxppc-dev@lists.ozlabs.org; Wang Dongsheng-B40534 Subject: [PATCH] powerpc/mpc85xx: fix non-bootcpu cannot up after hibernation resume This problem belongs to the core synchronization issues. The cpu1 already updated spin_table values, but bootcore cannot get this value in time. After bootcpu hibiernation restore the pages. we are now running with the kernel data of the old kernel fully restored. if we reset the non-bootcpus that will be reset cache(tlb), the non-bootcpus will get new address(map virtual and physical address spaces). but bootcpu tlb cache still use boot kernel data, so we need to invalidate the bootcpu tlb cache make it to get new main memory data. log: Enabling non-boot CPUs ... smp_85xx_kick_cpu: timeout waiting for core 1 to reset smp: failed starting cpu 1 (rc -2) Error taking CPU1 up: -2 Signed-off-by: Wang Dongsheng dongsheng.w...@freescale.com diff --git a/arch/powerpc/kernel/swsusp_booke.S b/arch/powerpc/kernel/swsusp_booke.S index 11a3930..9503249 100644 --- a/arch/powerpc/kernel/swsusp_booke.S +++ b/arch/powerpc/kernel/swsusp_booke.S @@ -141,6 +141,19 @@ _GLOBAL(swsusp_arch_resume) lis r11,swsusp_save_area@h ori r11,r11,swsusp_save_area@l + /* + * The boot core get a virtual address, when the boot process, + * the virtual address corresponds to a physical address. After + * hibernation resume memory snapshots, The corresponding + * relationship between the virtual memory and physical memory + * might change again. We need to get a new page table. So we + * need to invalidate TLB after resume pages. + * + * Invalidations TLB Using tlbilx/tlbivax/MMUCSR0. + * tlbilx used here. + */ + bl _tlbil_all + lwz r4,SL_SPRG0(r11) mtsprg 0,r4 lwz r4,SL_SPRG1(r11) -- 1.8.0 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH] powerpc/mpc85xx: fix non-bootcpu cannot up after hibernation resume
I send to a wrong email address Anton Vorontsov avoront...@ru.mvista.com Add Anton Vorontsov anton.voront...@linaro.org to this email. Thanks all. -Original Message- From: Wang Dongsheng-B40534 Sent: Tuesday, May 14, 2013 4:06 PM To: avoront...@ru.mvista.com Cc: pau...@samba.org; r...@sisk.pl; b...@kernel.crashing.org; johan...@sipsolutions.net; Wood Scott-B07421; Li Yang-R58472; Zhao Chenhui-B35336; linuxppc-dev@lists.ozlabs.org; Wang Dongsheng-B40534 Subject: [PATCH] powerpc/mpc85xx: fix non-bootcpu cannot up after hibernation resume This problem belongs to the core synchronization issues. The cpu1 already updated spin_table values, but bootcore cannot get this value in time. After bootcpu hibiernation restore the pages. we are now running with the kernel data of the old kernel fully restored. if we reset the non-bootcpus that will be reset cache(tlb), the non-bootcpus will get new address(map virtual and physical address spaces). but bootcpu tlb cache still use boot kernel data, so we need to invalidate the bootcpu tlb cache make it to get new main memory data. log: Enabling non-boot CPUs ... smp_85xx_kick_cpu: timeout waiting for core 1 to reset smp: failed starting cpu 1 (rc -2) Error taking CPU1 up: -2 Signed-off-by: Wang Dongsheng dongsheng.w...@freescale.com diff --git a/arch/powerpc/kernel/swsusp_booke.S b/arch/powerpc/kernel/swsusp_booke.S index 11a3930..9503249 100644 --- a/arch/powerpc/kernel/swsusp_booke.S +++ b/arch/powerpc/kernel/swsusp_booke.S @@ -141,6 +141,19 @@ _GLOBAL(swsusp_arch_resume) lis r11,swsusp_save_area@h ori r11,r11,swsusp_save_area@l + /* + * The boot core get a virtual address, when the boot process, + * the virtual address corresponds to a physical address. After + * hibernation resume memory snapshots, The corresponding + * relationship between the virtual memory and physical memory + * might change again. We need to get a new page table. So we + * need to invalidate TLB after resume pages. + * + * Invalidations TLB Using tlbilx/tlbivax/MMUCSR0. + * tlbilx used here. + */ + bl _tlbil_all + lwz r4,SL_SPRG0(r11) mtsprg 0,r4 lwz r4,SL_SPRG1(r11) -- 1.8.0 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH v3 1/4] powerpc/mpic: add irq_set_wake support
Thanks ben. :) - dongsheng. -Original Message- From: Benjamin Herrenschmidt [mailto:b...@kernel.crashing.org] Sent: Monday, May 13, 2013 1:00 PM To: Wang Dongsheng-B40534 Cc: linuxppc-dev@lists.ozlabs.org; Wood Scott-B07421; ga...@kernel.crashing.org Subject: Re: [PATCH v3 1/4] powerpc/mpic: add irq_set_wake support On Mon, 2013-05-13 at 04:25 +, Wang Dongsheng-B40534 wrote: Hi Benjamin, Could you apply these patches? I'll have a look, I was assuming Kumar would take them but since not I'll queue them up. Cheers, Ben. Scott already ACK. [v3,1/4] powerpc/mpic: add irq_set_wake support http://patchwork.ozlabs.org/patch/234934/ [v3,2/4] powerpc/mpic: add global timer support http://patchwork.ozlabs.org/patch/234935/ [v3,3/4] powerpc/mpic: create mpic subsystem object http://patchwork.ozlabs.org/patch/234936/ [v3,4/4] powerpc/fsl: add MPIC timer wakeup support http://patchwork.ozlabs.org/patch/234937/ Thanks. -Original Message- From: Wang Dongsheng-B40534 Sent: Friday, May 03, 2013 9:54 AM To: 'ga...@kernel.crashing.org' Cc: 'linuxppc-dev@lists.ozlabs.org'; Wood Scott-B07421; 'b...@kernel.crashing.org' Subject: RE: [PATCH v3 1/4] powerpc/mpic: add irq_set_wake support Hi Kumar, Could you apply these patches? Thanks. -Original Message- From: Wang Dongsheng-B40534 Sent: Tuesday, April 23, 2013 6:10 PM To: ga...@kernel.crashing.org Cc: linuxppc-dev@lists.ozlabs.org; Wood Scott-B07421 Subject: RE: [PATCH v3 1/4] powerpc/mpic: add irq_set_wake support Hi Kumar, Could you apply these patches? Thanks. [v3,1/4] powerpc/mpic: add irq_set_wake support http://patchwork.ozlabs.org/patch/234934/ [v3,2/4] powerpc/mpic: add global timer support http://patchwork.ozlabs.org/patch/234935/ [v3,3/4] powerpc/mpic: create mpic subsystem object http://patchwork.ozlabs.org/patch/234936/ [v3,4/4] powerpc/fsl: add MPIC timer wakeup support http://patchwork.ozlabs.org/patch/234937/ -Original Message- From: Wood Scott-B07421 Sent: Wednesday, April 17, 2013 7:30 AM To: Wang Dongsheng-B40534 Cc: Wood Scott-B07421; linuxppc-dev@lists.ozlabs.org; ga...@kernel.crashing.org Subject: Re: [PATCH v3 1/4] powerpc/mpic: add irq_set_wake support ACK -Scott On 04/16/2013 05:58:52 AM, Wang Dongsheng-B40534 wrote: Hi scott, Could you ACK these patches? [PATCH v3 2/4] powerpc/mpic: add global timer support [PATCH v3 3/4] powerpc/mpic: create mpic subsystem object [PATCH v3 4/4] powerpc/fsl: add MPIC timer wakeup support Thanks. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH v3 1/4] powerpc/mpic: add irq_set_wake support
Hi Benjamin, Could you apply these patches? Scott already ACK. [v3,1/4] powerpc/mpic: add irq_set_wake support http://patchwork.ozlabs.org/patch/234934/ [v3,2/4] powerpc/mpic: add global timer support http://patchwork.ozlabs.org/patch/234935/ [v3,3/4] powerpc/mpic: create mpic subsystem object http://patchwork.ozlabs.org/patch/234936/ [v3,4/4] powerpc/fsl: add MPIC timer wakeup support http://patchwork.ozlabs.org/patch/234937/ Thanks. -Original Message- From: Wang Dongsheng-B40534 Sent: Friday, May 03, 2013 9:54 AM To: 'ga...@kernel.crashing.org' Cc: 'linuxppc-dev@lists.ozlabs.org'; Wood Scott-B07421; 'b...@kernel.crashing.org' Subject: RE: [PATCH v3 1/4] powerpc/mpic: add irq_set_wake support Hi Kumar, Could you apply these patches? Thanks. -Original Message- From: Wang Dongsheng-B40534 Sent: Tuesday, April 23, 2013 6:10 PM To: ga...@kernel.crashing.org Cc: linuxppc-dev@lists.ozlabs.org; Wood Scott-B07421 Subject: RE: [PATCH v3 1/4] powerpc/mpic: add irq_set_wake support Hi Kumar, Could you apply these patches? Thanks. [v3,1/4] powerpc/mpic: add irq_set_wake support http://patchwork.ozlabs.org/patch/234934/ [v3,2/4] powerpc/mpic: add global timer support http://patchwork.ozlabs.org/patch/234935/ [v3,3/4] powerpc/mpic: create mpic subsystem object http://patchwork.ozlabs.org/patch/234936/ [v3,4/4] powerpc/fsl: add MPIC timer wakeup support http://patchwork.ozlabs.org/patch/234937/ -Original Message- From: Wood Scott-B07421 Sent: Wednesday, April 17, 2013 7:30 AM To: Wang Dongsheng-B40534 Cc: Wood Scott-B07421; linuxppc-dev@lists.ozlabs.org; ga...@kernel.crashing.org Subject: Re: [PATCH v3 1/4] powerpc/mpic: add irq_set_wake support ACK -Scott On 04/16/2013 05:58:52 AM, Wang Dongsheng-B40534 wrote: Hi scott, Could you ACK these patches? [PATCH v3 2/4] powerpc/mpic: add global timer support [PATCH v3 3/4] powerpc/mpic: create mpic subsystem object [PATCH v3 4/4] powerpc/fsl: add MPIC timer wakeup support Thanks. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH v3 1/4] powerpc/mpic: add irq_set_wake support
Hi Kumar, Could you apply these patches? Thanks. -Original Message- From: Wang Dongsheng-B40534 Sent: Tuesday, April 23, 2013 6:10 PM To: ga...@kernel.crashing.org Cc: linuxppc-dev@lists.ozlabs.org; Wood Scott-B07421 Subject: RE: [PATCH v3 1/4] powerpc/mpic: add irq_set_wake support Hi Kumar, Could you apply these patches? Thanks. [v3,1/4] powerpc/mpic: add irq_set_wake support http://patchwork.ozlabs.org/patch/234934/ [v3,2/4] powerpc/mpic: add global timer support http://patchwork.ozlabs.org/patch/234935/ [v3,3/4] powerpc/mpic: create mpic subsystem object http://patchwork.ozlabs.org/patch/234936/ [v3,4/4] powerpc/fsl: add MPIC timer wakeup support http://patchwork.ozlabs.org/patch/234937/ -Original Message- From: Wood Scott-B07421 Sent: Wednesday, April 17, 2013 7:30 AM To: Wang Dongsheng-B40534 Cc: Wood Scott-B07421; linuxppc-dev@lists.ozlabs.org; ga...@kernel.crashing.org Subject: Re: [PATCH v3 1/4] powerpc/mpic: add irq_set_wake support ACK -Scott On 04/16/2013 05:58:52 AM, Wang Dongsheng-B40534 wrote: Hi scott, Could you ACK these patches? [PATCH v3 2/4] powerpc/mpic: add global timer support [PATCH v3 3/4] powerpc/mpic: create mpic subsystem object [PATCH v3 4/4] powerpc/fsl: add MPIC timer wakeup support Thanks. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH v3 1/4] powerpc/mpic: add irq_set_wake support
Hi Kumar, Could you apply these patches? Thanks. [v3,1/4] powerpc/mpic: add irq_set_wake support http://patchwork.ozlabs.org/patch/234934/ [v3,2/4] powerpc/mpic: add global timer support http://patchwork.ozlabs.org/patch/234935/ [v3,3/4] powerpc/mpic: create mpic subsystem object http://patchwork.ozlabs.org/patch/234936/ [v3,4/4] powerpc/fsl: add MPIC timer wakeup support http://patchwork.ozlabs.org/patch/234937/ -Original Message- From: Wood Scott-B07421 Sent: Wednesday, April 17, 2013 7:30 AM To: Wang Dongsheng-B40534 Cc: Wood Scott-B07421; linuxppc-dev@lists.ozlabs.org; ga...@kernel.crashing.org Subject: Re: [PATCH v3 1/4] powerpc/mpic: add irq_set_wake support ACK -Scott On 04/16/2013 05:58:52 AM, Wang Dongsheng-B40534 wrote: Hi scott, Could you ACK these patches? [PATCH v3 2/4] powerpc/mpic: add global timer support [PATCH v3 3/4] powerpc/mpic: create mpic subsystem object [PATCH v3 4/4] powerpc/fsl: add MPIC timer wakeup support Thanks. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH v3 1/4] powerpc/mpic: add irq_set_wake support
Hi scott,
Could you ACK these patches?
[PATCH v3 2/4] powerpc/mpic: add global timer support
[PATCH v3 3/4] powerpc/mpic: create mpic subsystem object
[PATCH v3 4/4] powerpc/fsl: add MPIC timer wakeup support
Thanks.
-Original Message-
From: Wang Dongsheng-B40534
Sent: Tuesday, April 09, 2013 10:22 AM
To: Wood Scott-B07421
Cc: linuxppc-dev@lists.ozlabs.org; Wang Dongsheng-B40534
Subject: [PATCH v3 1/4] powerpc/mpic: add irq_set_wake support
Add irq_set_wake support. Just add IRQF_NO_SUSPEND to desc-action-flag.
So the wake up interrupt will not be disable in suspend_device_irqs.
Signed-off-by: Wang Dongsheng dongsheng.w...@freescale.com
---
v3:
* Modify: Change EINVAL to ENXIO in mpic_irq_set_wake()
v2:
* Add: Check freescale chip in mpic_irq_set_wake().
* Remove: Support mpic_irq_set_wake() in ht_chip.
arch/powerpc/sysdev/mpic.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/arch/powerpc/sysdev/mpic.c b/arch/powerpc/sysdev/mpic.c
index 3b2efd4..ae709d2 100644
--- a/arch/powerpc/sysdev/mpic.c
+++ b/arch/powerpc/sysdev/mpic.c
@@ -920,6 +920,22 @@ int mpic_set_irq_type(struct irq_data *d, unsigned
int flow_type)
return IRQ_SET_MASK_OK_NOCOPY;
}
+static int mpic_irq_set_wake(struct irq_data *d, unsigned int on) {
+ struct irq_desc *desc = container_of(d, struct irq_desc, irq_data);
+ struct mpic *mpic = mpic_from_irq_data(d);
+
+ if (!(mpic-flags MPIC_FSL))
+ return -ENXIO;
+
+ if (on)
+ desc-action-flags |= IRQF_NO_SUSPEND;
+ else
+ desc-action-flags = ~IRQF_NO_SUSPEND;
+
+ return 0;
+}
+
void mpic_set_vector(unsigned int virq, unsigned int vector) {
struct mpic *mpic = mpic_from_irq(virq); @@ -957,6 +973,7 @@ static
struct irq_chip mpic_irq_chip = {
.irq_unmask = mpic_unmask_irq,
.irq_eoi= mpic_end_irq,
.irq_set_type = mpic_set_irq_type,
+ .irq_set_wake = mpic_irq_set_wake,
};
#ifdef CONFIG_SMP
@@ -971,6 +988,7 @@ static struct irq_chip mpic_tm_chip = {
.irq_mask = mpic_mask_tm,
.irq_unmask = mpic_unmask_tm,
.irq_eoi= mpic_end_irq,
+ .irq_set_wake = mpic_irq_set_wake,
};
#ifdef CONFIG_MPIC_U3_HT_IRQS
--
1.8.0
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH] powerpc: add Book E support to 64-bit hibernation
-Original Message- From: Wood Scott-B07421 Sent: Thursday, April 04, 2013 4:16 AM To: Wang Dongsheng-B40534 Cc: Wood Scott-B07421; Johannes Berg; linuxppc-dev@lists.ozlabs.org Subject: Re: [PATCH] powerpc: add Book E support to 64-bit hibernation On 04/03/2013 12:36:41 AM, Wang Dongsheng-B40534 wrote: -Original Message- From: Wood Scott-B07421 Sent: Wednesday, April 03, 2013 8:35 AM To: Wang Dongsheng-B40534 Cc: Wood Scott-B07421; Johannes Berg; linuxppc-dev@lists.ozlabs.org Subject: Re: [PATCH] powerpc: add Book E support to 64-bit hibernation On 04/02/2013 12:28:40 AM, Wang Dongsheng-B40534 wrote: Hi scott Johannes, Thanks for reviewing. @scott, About this patch, could you please help ack this patch? Please investigate the issue of whether we are loading kernel module code in this step, and whether cache flushing is needed as a result. Sorry, I am not very clear what you mean. When the kernel boot end, modprobe some xx.ko? Suppose, before the kernel was suspended, modules had been loaded. At what point do those modules get restored, and when does the cache get flushed? Before the kernel was suspended, modules had been loaded, the modules is already in memory. And /lib/modules/* is belong to vfs. When suspend to disk, all used pages will be saved.(Include VFS, Loaded modules) When restore, the kernel will not modprobe again. The non-bootcpu will restore all pages.(Include VFS, Loaded modules) So, It does not need to flush. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH v2 1/4] powerpc/mpic: add irq_set_wake support
-Original Message-
From: Wang Dongsheng-B40534
Sent: Wednesday, April 03, 2013 10:49 AM
To: Wood Scott-B07421
Cc: linuxppc-dev@lists.ozlabs.org
Subject: RE: [PATCH v2 1/4] powerpc/mpic: add irq_set_wake support
-Original Message-
From: Wood Scott-B07421
Sent: Wednesday, April 03, 2013 8:37 AM
To: Wang Dongsheng-B40534
Cc: linuxppc-dev@lists.ozlabs.org; Wang Dongsheng-B40534
Subject: Re: [PATCH v2 1/4] powerpc/mpic: add irq_set_wake support
On 04/02/2013 01:40:37 AM, Wang Dongsheng wrote:
Add irq_set_wake support. Just add IRQF_NO_SUSPEND to
desc-action-flag.
So the wake up interrupt will not be disable in suspend_device_irqs.
Signed-off-by: Wang Dongsheng dongsheng.w...@freescale.com
---
v2:
* Add: Check freescale chip in mpic_irq_set_wake().
* Remove: Support mpic_irq_set_wake() in ht_chip.
arch/powerpc/sysdev/mpic.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/arch/powerpc/sysdev/mpic.c b/arch/powerpc/sysdev/mpic.c
index 3b2efd4..50d1ee1 100644
--- a/arch/powerpc/sysdev/mpic.c
+++ b/arch/powerpc/sysdev/mpic.c
@@ -920,6 +920,22 @@ int mpic_set_irq_type(struct irq_data *d,
unsigned int flow_type)
return IRQ_SET_MASK_OK_NOCOPY;
}
+static int mpic_irq_set_wake(struct irq_data *d, unsigned int on) {
+ struct irq_desc *desc = container_of(d, struct irq_desc,
irq_data);
+ struct mpic *mpic = mpic_from_irq_data(d);
+
+ if (!(mpic-flags MPIC_FSL))
+ return -EINVAL;
I was thinking more along the lines of using MPIC_FSL during init to
decide whether to write this function to .irq_set_wake,
I think the static registration method is more reasonable. We must
consider readability. And mpic_irq_set_wake() will not be frequent calls.
So within
mpic_irq_set_wake() to decide is reasonable.
though that could probably wait until there's a second type of MPIC
that needs this (if ever).
Even if the mpic_irq_set_wake() register in the first type of MPIC that
is not belong MPIC_FSL, the function can return errno. I think the errno
should be -ENXIO.
See kernel/irq/manage.c, set_irq_wake_real() the return value.
The desc-irq_data.chip-irq_set_wake is null, the errno is -ENXIO.
s/-EINVAL/-ENXIO/
About patches, if there are no other suggestion I'll send the V3.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH v2 1/4] powerpc/mpic: add irq_set_wake support
-Original Message-
From: Wood Scott-B07421
Sent: Wednesday, April 03, 2013 8:37 AM
To: Wang Dongsheng-B40534
Cc: linuxppc-dev@lists.ozlabs.org; Wang Dongsheng-B40534
Subject: Re: [PATCH v2 1/4] powerpc/mpic: add irq_set_wake support
On 04/02/2013 01:40:37 AM, Wang Dongsheng wrote:
Add irq_set_wake support. Just add IRQF_NO_SUSPEND to
desc-action-flag.
So the wake up interrupt will not be disable in suspend_device_irqs.
Signed-off-by: Wang Dongsheng dongsheng.w...@freescale.com
---
v2:
* Add: Check freescale chip in mpic_irq_set_wake().
* Remove: Support mpic_irq_set_wake() in ht_chip.
arch/powerpc/sysdev/mpic.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/arch/powerpc/sysdev/mpic.c b/arch/powerpc/sysdev/mpic.c
index 3b2efd4..50d1ee1 100644
--- a/arch/powerpc/sysdev/mpic.c
+++ b/arch/powerpc/sysdev/mpic.c
@@ -920,6 +920,22 @@ int mpic_set_irq_type(struct irq_data *d,
unsigned int flow_type)
return IRQ_SET_MASK_OK_NOCOPY;
}
+static int mpic_irq_set_wake(struct irq_data *d, unsigned int on) {
+ struct irq_desc *desc = container_of(d, struct irq_desc,
irq_data);
+ struct mpic *mpic = mpic_from_irq_data(d);
+
+ if (!(mpic-flags MPIC_FSL))
+ return -EINVAL;
I was thinking more along the lines of using MPIC_FSL during init to
decide whether to write this function to .irq_set_wake,
I think the static registration method is more reasonable. We must consider
readability. And mpic_irq_set_wake() will not be frequent calls. So within
mpic_irq_set_wake() to decide is reasonable.
though that could probably wait until there's a second type of MPIC
that needs this (if ever).
Even if the mpic_irq_set_wake() register in the first type of MPIC that is not
belong MPIC_FSL, the function can return errno. I think the errno should be
-ENXIO.
See kernel/irq/manage.c, set_irq_wake_real() the return value.
The desc-irq_data.chip-irq_set_wake is null, the errno is -ENXIO.
s/-EINVAL/-ENXIO/
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH] powerpc: add Book E support to 64-bit hibernation
-Original Message- From: Wood Scott-B07421 Sent: Wednesday, April 03, 2013 8:35 AM To: Wang Dongsheng-B40534 Cc: Wood Scott-B07421; Johannes Berg; linuxppc-dev@lists.ozlabs.org Subject: Re: [PATCH] powerpc: add Book E support to 64-bit hibernation On 04/02/2013 12:28:40 AM, Wang Dongsheng-B40534 wrote: Hi scott Johannes, Thanks for reviewing. @scott, About this patch, could you please help ack this patch? Please investigate the issue of whether we are loading kernel module code in this step, and whether cache flushing is needed as a result. Sorry, I am not very clear what you mean. When the kernel boot end, modprobe some xx.ko? Is there any chance we could even be loading user code here, e.g. if it's mlocked and thus couldn't be swapped out? ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH] powerpc: add Book E support to 64-bit hibernation
Hi scott Johannes, Thanks for reviewing. @scott, About this patch, could you please help ack this patch? -Original Message- From: Wood Scott-B07421 Sent: Saturday, March 23, 2013 6:15 AM To: Johannes Berg Cc: Wang Dongsheng-B40534; linuxppc-dev@lists.ozlabs.org Subject: Re: [PATCH] powerpc: add Book E support to 64-bit hibernation On 03/22/2013 05:58:37 AM, Johannes Berg wrote: On Tue, 2013-03-19 at 17:16 -0500, Scott Wood wrote: I wonder about kernel modules, though flushing 32 MiB wouldn't be adequate there. Good question, but would they be running? You have to have everything built in that you need to load the image? Or maybe not, with the userspace image restoration that became possible at some point... Is that all that's being restored in this step, or would we be loading all modules that were loaded before suspend (as they're normally not swappable)? I'm not too familiar with what gets saved where. Yes, they would be restored since full memory is restored, but the kernel doing the restore hasn't typically had a chance to load modules. Although with uswsusp there probably are ways it can already have. If we're loading executable code that wasn't there before[1], we need to flush -- but there's no reason why modules would only be in the lower 32 MiB. -Scott [1] within the resume process, not before suspend ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 2/3] powerpc/mpic: add global timer support
-Original Message-
From: Wood Scott-B07421
Sent: Friday, March 29, 2013 3:48 AM
To: Wang Dongsheng-B40534
Cc: Wood Scott-B07421; Gala Kumar-B11780; linuxppc-dev@lists.ozlabs.org;
Li Yang-R58472
Subject: Re: [PATCH 2/3] powerpc/mpic: add global timer support
On 03/27/2013 09:29:26 PM, Wang Dongsheng-B40534 wrote:
-Original Message-
From: Wood Scott-B07421
Sent: Thursday, March 28, 2013 1:12 AM
To: Wang Dongsheng-B40534
Cc: Wood Scott-B07421; Gala Kumar-B11780;
linuxppc-dev@lists.ozlabs.org;
Li Yang-R58472
Subject: Re: [PATCH 2/3] powerpc/mpic: add global timer support
On 03/26/2013 10:23:38 PM, Wang Dongsheng-B40534 wrote:
-Original Message-
From: Wood Scott-B07421
Sent: Wednesday, March 27, 2013 1:32 AM
To: Wang Dongsheng-B40534
Cc: Wood Scott-B07421; Gala Kumar-B11780;
linuxppc-dev@lists.ozlabs.org;
Li Yang-R58472
Subject: Re: [PATCH 2/3] powerpc/mpic: add global timer support
On 03/25/2013 10:29:58 PM, Wang Dongsheng-B40534 wrote:
-Original Message-
From: Wood Scott-B07421
Sent: Saturday, March 23, 2013 6:30 AM
To: Wang Dongsheng-B40534
Cc: Wood Scott-B07421; Gala Kumar-B11780;
linuxppc-dev@lists.ozlabs.org;
Li Yang-R58472
Subject: Re: [PATCH 2/3] powerpc/mpic: add global timer
support
On 03/22/2013 01:14:51 AM, Wang Dongsheng-B40534 wrote:
-Original Message-
From: Wood Scott-B07421
Sent: Thursday, March 21, 2013 7:00 AM
To: Wang Dongsheng-B40534
Cc: Wood Scott-B07421; Gala Kumar-B11780;
linuxppc-dev@lists.ozlabs.org;
Li Yang-R58472
Subject: Re: [PATCH 2/3] powerpc/mpic: add global timer
support
BTW, the input clock frequency has been similarly
scaled,
yet
you
don't
try to scrounge up that information to get further
precision...
Let's go back patch, do you think the code is repeated?
I will remove if (!(priv-flags FSL_GLOBAL_TIMER))
branch,
there
will be no redundant code.
I'd rather that branch be kept and the more complicated
branch
deleted,
and priv-timerfreq frequency be adjusted on initialization
to
account
for the scaler.
static void convert_ticks_to_time(struct timer_group_priv
*priv,
const u64 ticks, struct timeval *time) {
u64 tmp_sec;
time-tv_sec = (__kernel_time_t)div_u64(ticks,
priv-timerfreq);
tmp_sec = (u64)time-tv_sec * (u64)priv-timerfreq;
time-tv_usec = (__kernel_suseconds_t)
div_u64((ticks - tmp_sec) * 100,
priv-timerfreq);
return;
}
timer_group_get_freq() {
...
if (priv-flags FSL_GLOBAL_TIMER) {
div = (1 (MPIC_TIMER_TCR_CLKDIV_64 8)) *
8;
priv-timerfreq /= div;
}
...
}
Do you want to do that?
if (priv-flags FSL_GLOBAL_TIMER)
priv-timerfreq /= 64;
...but otherwise yes.
Ok, I would like do this.
if (priv-flags FSL_GLOBAL_TIMER) {
div = (1 (MPIC_TIMER_TCR_CLKDIV_64 8)) * 8;
priv-timerfreq /= div;
Why? What do you get out of that obfuscation?
Change MPIC_TIMER_TCR_CLKDIV_64 to MPIC_TIMER_TCR_CLKDIV
OK, that would at least provide the ability to adjust the clock divider
in one place rather than two -- though I don't know why we'd ever need to
change the divider.
Thanks, next patch MPIC_TIMER_TCR_CLKDIV_64 will change to
MPIC_TIMER_TCR_CLKDIV. :)
div = (1 (MPIC_TIMER_TCR_CLKDIV_64 8)) * 8 --- div = (1
(MPIC_TIMER_TCR_CLKDIV 8)) * 8;
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 2/3] powerpc/mpic: add global timer support
-Original Message-
From: Wood Scott-B07421
Sent: Thursday, March 28, 2013 1:12 AM
To: Wang Dongsheng-B40534
Cc: Wood Scott-B07421; Gala Kumar-B11780; linuxppc-dev@lists.ozlabs.org;
Li Yang-R58472
Subject: Re: [PATCH 2/3] powerpc/mpic: add global timer support
On 03/26/2013 10:23:38 PM, Wang Dongsheng-B40534 wrote:
-Original Message-
From: Wood Scott-B07421
Sent: Wednesday, March 27, 2013 1:32 AM
To: Wang Dongsheng-B40534
Cc: Wood Scott-B07421; Gala Kumar-B11780;
linuxppc-dev@lists.ozlabs.org;
Li Yang-R58472
Subject: Re: [PATCH 2/3] powerpc/mpic: add global timer support
On 03/25/2013 10:29:58 PM, Wang Dongsheng-B40534 wrote:
-Original Message-
From: Wood Scott-B07421
Sent: Saturday, March 23, 2013 6:30 AM
To: Wang Dongsheng-B40534
Cc: Wood Scott-B07421; Gala Kumar-B11780;
linuxppc-dev@lists.ozlabs.org;
Li Yang-R58472
Subject: Re: [PATCH 2/3] powerpc/mpic: add global timer support
On 03/22/2013 01:14:51 AM, Wang Dongsheng-B40534 wrote:
-Original Message-
From: Wood Scott-B07421
Sent: Thursday, March 21, 2013 7:00 AM
To: Wang Dongsheng-B40534
Cc: Wood Scott-B07421; Gala Kumar-B11780;
linuxppc-dev@lists.ozlabs.org;
Li Yang-R58472
Subject: Re: [PATCH 2/3] powerpc/mpic: add global timer
support
BTW, the input clock frequency has been similarly scaled,
yet
you
don't
try to scrounge up that information to get further
precision...
Let's go back patch, do you think the code is repeated?
I will remove if (!(priv-flags FSL_GLOBAL_TIMER)) branch,
there
will be no redundant code.
I'd rather that branch be kept and the more complicated branch
deleted,
and priv-timerfreq frequency be adjusted on initialization to
account
for the scaler.
static void convert_ticks_to_time(struct timer_group_priv *priv,
const u64 ticks, struct timeval *time) {
u64 tmp_sec;
time-tv_sec = (__kernel_time_t)div_u64(ticks,
priv-timerfreq);
tmp_sec = (u64)time-tv_sec * (u64)priv-timerfreq;
time-tv_usec = (__kernel_suseconds_t)
div_u64((ticks - tmp_sec) * 100,
priv-timerfreq);
return;
}
timer_group_get_freq() {
...
if (priv-flags FSL_GLOBAL_TIMER) {
div = (1 (MPIC_TIMER_TCR_CLKDIV_64 8)) * 8;
priv-timerfreq /= div;
}
...
}
Do you want to do that?
if (priv-flags FSL_GLOBAL_TIMER)
priv-timerfreq /= 64;
...but otherwise yes.
Ok, I would like do this.
if (priv-flags FSL_GLOBAL_TIMER) {
div = (1 (MPIC_TIMER_TCR_CLKDIV_64 8)) * 8;
priv-timerfreq /= div;
Why? What do you get out of that obfuscation?
Change MPIC_TIMER_TCR_CLKDIV_64 to MPIC_TIMER_TCR_CLKDIV
/* Clock Ratio
* Divide by 64 0x0300
* Divide by 32 0x0200
* Divide by 16 0x0100
* Divide by 8 0x (Hardware default div)
*/
#define MPIC_TIMER_TCR_CLKDIV 0x0300
timer_group_init() {
...
/* Init FSL timer hardware */
if (priv-flags FSL_GLOBAL_TIMER)
setbits32(priv-group_tcr, MPIC_TIMER_TCR_CLKDIV);
...
}
mpic_timer_resume() {
...
/* Init FSL timer hardware */
if (priv-flags FSL_GLOBAL_TIMER)
setbits32(priv-group_tcr, MPIC_TIMER_TCR_CLKDIV);
...
}
Because macro is friendly, and other functions also used the macro.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 3/3] powerpc/fsl: add MPIC timer wakeup support
-Original Message-
From: Wood Scott-B07421
Sent: Thursday, March 28, 2013 4:26 AM
To: Wang Dongsheng-B40534
Cc: Wood Scott-B07421; Gala Kumar-B11780; linuxppc-dev@lists.ozlabs.org;
Zhao Chenhui-B35336; Li Yang-R58472
Subject: Re: [PATCH 3/3] powerpc/fsl: add MPIC timer wakeup support
On 03/26/2013 10:21:04 PM, Wang Dongsheng-B40534 wrote:
-Original Message-
From: Wood Scott-B07421
Sent: Wednesday, March 27, 2013 1:36 AM
To: Wang Dongsheng-B40534
Cc: Wood Scott-B07421; Gala Kumar-B11780;
linuxppc-dev@lists.ozlabs.org;
Zhao Chenhui-B35336; Li Yang-R58472
Subject: Re: [PATCH 3/3] powerpc/fsl: add MPIC timer wakeup support
On 03/25/2013 10:27:24 PM, Wang Dongsheng-B40534 wrote:
-Original Message-
From: Wood Scott-B07421
Sent: Saturday, March 23, 2013 6:11 AM
To: Wang Dongsheng-B40534
Cc: Wood Scott-B07421; Gala Kumar-B11780;
linuxppc-dev@lists.ozlabs.org;
Zhao Chenhui-B35336; Li Yang-R58472
Subject: Re: [PATCH 3/3] powerpc/fsl: add MPIC timer wakeup
support
On 03/22/2013 12:46:24 AM, Wang Dongsheng-B40534 wrote:
Under what case is unsafe, please make sense.
char buffer[1] = { '5' };
write(fd, buffer, 1);
What comes after that '5' byte in the pointer you pass to
kstrtol?
The buffer is userspace. It will fall in the kernel space.
Kernel will get a free page, and copy the buffer to page.
This page has been cleared before copy to page.
The page has already have null-terminated.
It doesn't allocate a whole page, it uses kmalloc (not kzalloc!).
Even
if kzalloc were used, a larger user buffer could be the exact size
of the
region that was allocated.
See memdup_user() in mm/util.c
Did you miss something?
See fill_write_buffer() in fs/sysfs/file.c. It's used
get_zeroed_page()...
OK, I was looking at fs/sysfs/bin.c which is something slightly different.
fill_write_buffer() forces the size to be no more than PAGE_SIZE - 1
so we know there's a terminator.
Perhaps kernel/rtmutex-tester.c and kernel/time/clocksource.c are
similarly confused?
Yes. But its depends on file-f_op.
See vfs_write in fs/read_write.c.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 3/3] powerpc/fsl: add MPIC timer wakeup support
-Original Message-
From: Wood Scott-B07421
Sent: Wednesday, March 27, 2013 1:36 AM
To: Wang Dongsheng-B40534
Cc: Wood Scott-B07421; Gala Kumar-B11780; linuxppc-dev@lists.ozlabs.org;
Zhao Chenhui-B35336; Li Yang-R58472
Subject: Re: [PATCH 3/3] powerpc/fsl: add MPIC timer wakeup support
On 03/25/2013 10:27:24 PM, Wang Dongsheng-B40534 wrote:
-Original Message-
From: Wood Scott-B07421
Sent: Saturday, March 23, 2013 6:11 AM
To: Wang Dongsheng-B40534
Cc: Wood Scott-B07421; Gala Kumar-B11780;
linuxppc-dev@lists.ozlabs.org;
Zhao Chenhui-B35336; Li Yang-R58472
Subject: Re: [PATCH 3/3] powerpc/fsl: add MPIC timer wakeup support
On 03/22/2013 12:46:24 AM, Wang Dongsheng-B40534 wrote:
-Original Message-
From: Wood Scott-B07421
Sent: Thursday, March 21, 2013 5:49 AM
To: Wang Dongsheng-B40534
Cc: Wood Scott-B07421; Gala Kumar-B11780;
linuxppc-dev@lists.ozlabs.org;
Zhao Chenhui-B35336; Li Yang-R58472
Subject: Re: [PATCH 3/3] powerpc/fsl: add MPIC timer wakeup
support
On 03/19/2013 10:48:53 PM, Wang Dongsheng-B40534 wrote:
while (*s) {
if ('0' = *s *s = '9')
val = *s - '0';
else if ('a' = _tolower(*s) _tolower(*s) =
'f')
val = _tolower(*s) - 'a' + 10;
else
break; //this will break out to
convert.
Really? How do you know that the next byte after the buffer
isn't a
valid hex digit? How do you even know that we won't take a
fault
accessing it?
Under what case is unsafe, please make sense.
char buffer[1] = { '5' };
write(fd, buffer, 1);
What comes after that '5' byte in the pointer you pass to kstrtol?
The buffer is userspace. It will fall in the kernel space.
Kernel will get a free page, and copy the buffer to page.
This page has been cleared before copy to page.
The page has already have null-terminated.
It doesn't allocate a whole page, it uses kmalloc (not kzalloc!). Even
if kzalloc were used, a larger user buffer could be the exact size of the
region that was allocated.
See memdup_user() in mm/util.c
Did you miss something?
See fill_write_buffer() in fs/sysfs/file.c. It's used get_zeroed_page()...
See SYSCALL_DEFINE3(write,...) in fs/read_write.c
[c000f1ff3a60] [c0008224] .show_stack+0x74/0x1b0 (unreliable)
[c000f1ff3b10] [c002f370] .fsl_timer_wakeup_store+0x30/0x200
[c000f1ff3bc0] [c030accc] .dev_attr_store+0x3c/0x50
[c000f1ff3c30] [c018c47c] .sysfs_write_file+0xec/0x1f0
[c000f1ff3ce0] [c010dfb4] .vfs_write+0xf4/0x1b0
[c000f1ff3d80] [c010e360] .SyS_write+0x60/0xe0
[c000f1ff3e30] [c590] syscall_exit+0x0/0x80
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 2/3] powerpc/mpic: add global timer support
-Original Message-
From: Wood Scott-B07421
Sent: Wednesday, March 27, 2013 1:32 AM
To: Wang Dongsheng-B40534
Cc: Wood Scott-B07421; Gala Kumar-B11780; linuxppc-dev@lists.ozlabs.org;
Li Yang-R58472
Subject: Re: [PATCH 2/3] powerpc/mpic: add global timer support
On 03/25/2013 10:29:58 PM, Wang Dongsheng-B40534 wrote:
-Original Message-
From: Wood Scott-B07421
Sent: Saturday, March 23, 2013 6:30 AM
To: Wang Dongsheng-B40534
Cc: Wood Scott-B07421; Gala Kumar-B11780;
linuxppc-dev@lists.ozlabs.org;
Li Yang-R58472
Subject: Re: [PATCH 2/3] powerpc/mpic: add global timer support
On 03/22/2013 01:14:51 AM, Wang Dongsheng-B40534 wrote:
-Original Message-
From: Wood Scott-B07421
Sent: Thursday, March 21, 2013 7:00 AM
To: Wang Dongsheng-B40534
Cc: Wood Scott-B07421; Gala Kumar-B11780;
linuxppc-dev@lists.ozlabs.org;
Li Yang-R58472
Subject: Re: [PATCH 2/3] powerpc/mpic: add global timer support
BTW, the input clock frequency has been similarly scaled, yet
you
don't
try to scrounge up that information to get further precision...
Let's go back patch, do you think the code is repeated?
I will remove if (!(priv-flags FSL_GLOBAL_TIMER)) branch,
there
will be no redundant code.
I'd rather that branch be kept and the more complicated branch
deleted,
and priv-timerfreq frequency be adjusted on initialization to
account
for the scaler.
static void convert_ticks_to_time(struct timer_group_priv *priv,
const u64 ticks, struct timeval *time) {
u64 tmp_sec;
time-tv_sec = (__kernel_time_t)div_u64(ticks,
priv-timerfreq);
tmp_sec = (u64)time-tv_sec * (u64)priv-timerfreq;
time-tv_usec = (__kernel_suseconds_t)
div_u64((ticks - tmp_sec) * 100, priv-timerfreq);
return;
}
timer_group_get_freq() {
...
if (priv-flags FSL_GLOBAL_TIMER) {
div = (1 (MPIC_TIMER_TCR_CLKDIV_64 8)) * 8;
priv-timerfreq /= div;
}
...
}
Do you want to do that?
if (priv-flags FSL_GLOBAL_TIMER)
priv-timerfreq /= 64;
...but otherwise yes.
Ok, I would like do this.
if (priv-flags FSL_GLOBAL_TIMER) {
div = (1 (MPIC_TIMER_TCR_CLKDIV_64 8)) * 8;
priv-timerfreq /= div;
}
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 3/3] powerpc/fsl: add MPIC timer wakeup support
-Original Message-
From: Wood Scott-B07421
Sent: Saturday, March 23, 2013 6:11 AM
To: Wang Dongsheng-B40534
Cc: Wood Scott-B07421; Gala Kumar-B11780; linuxppc-dev@lists.ozlabs.org;
Zhao Chenhui-B35336; Li Yang-R58472
Subject: Re: [PATCH 3/3] powerpc/fsl: add MPIC timer wakeup support
On 03/22/2013 12:46:24 AM, Wang Dongsheng-B40534 wrote:
-Original Message-
From: Wood Scott-B07421
Sent: Thursday, March 21, 2013 5:49 AM
To: Wang Dongsheng-B40534
Cc: Wood Scott-B07421; Gala Kumar-B11780;
linuxppc-dev@lists.ozlabs.org;
Zhao Chenhui-B35336; Li Yang-R58472
Subject: Re: [PATCH 3/3] powerpc/fsl: add MPIC timer wakeup support
On 03/19/2013 10:48:53 PM, Wang Dongsheng-B40534 wrote:
while (*s) {
if ('0' = *s *s = '9')
val = *s - '0';
else if ('a' = _tolower(*s) _tolower(*s) = 'f')
val = _tolower(*s) - 'a' + 10;
else
break; //this will break out to convert.
Really? How do you know that the next byte after the buffer isn't a
valid hex digit? How do you even know that we won't take a fault
accessing it?
Under what case is unsafe, please make sense.
char buffer[1] = { '5' };
write(fd, buffer, 1);
What comes after that '5' byte in the pointer you pass to kstrtol?
The buffer is userspace. It will fall in the kernel space.
Kernel will get a free page, and copy the buffer to page.
This page has been cleared before copy to page.
The page has already have null-terminated.
kstrtol is used in almost of sysfs interface, I think it should be
accepted in defaule :).
Just because a lot of other people copy blindly doesn't make it right.
Most of the examples I found use sscanf instead, though that has the same
problem.
I do see a few instances of the strings from sysfs write are not 0
terminated! in the comments, though (kernel/time/clocksource.c and
kernel/rtmutex-tester.c).
Also words written to sysfs files may, or may not, be \n terminated
in drivers/md/md.c.
It's not kstrtol doesn't work as well, They do not belong to this kind
of scenarios.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 2/3] powerpc/mpic: add global timer support
-Original Message-
From: Wood Scott-B07421
Sent: Saturday, March 23, 2013 6:30 AM
To: Wang Dongsheng-B40534
Cc: Wood Scott-B07421; Gala Kumar-B11780; linuxppc-dev@lists.ozlabs.org;
Li Yang-R58472
Subject: Re: [PATCH 2/3] powerpc/mpic: add global timer support
On 03/22/2013 01:14:51 AM, Wang Dongsheng-B40534 wrote:
-Original Message-
From: Wood Scott-B07421
Sent: Thursday, March 21, 2013 7:00 AM
To: Wang Dongsheng-B40534
Cc: Wood Scott-B07421; Gala Kumar-B11780;
linuxppc-dev@lists.ozlabs.org;
Li Yang-R58472
Subject: Re: [PATCH 2/3] powerpc/mpic: add global timer support
BTW, the input clock frequency has been similarly scaled, yet you
don't
try to scrounge up that information to get further precision...
Let's go back patch, do you think the code is repeated?
I will remove if (!(priv-flags FSL_GLOBAL_TIMER)) branch, there
will be no redundant code.
I'd rather that branch be kept and the more complicated branch deleted,
and priv-timerfreq frequency be adjusted on initialization to account
for the scaler.
static void convert_ticks_to_time(struct timer_group_priv *priv,
const u64 ticks, struct timeval *time)
{
u64 tmp_sec;
time-tv_sec = (__kernel_time_t)div_u64(ticks, priv-timerfreq);
tmp_sec = (u64)time-tv_sec * (u64)priv-timerfreq;
time-tv_usec = (__kernel_suseconds_t)
div_u64((ticks - tmp_sec) * 100, priv-timerfreq);
return;
}
timer_group_get_freq() {
...
if (priv-flags FSL_GLOBAL_TIMER) {
div = (1 (MPIC_TIMER_TCR_CLKDIV_64 8)) * 8;
priv-timerfreq /= div;
}
...
}
Do you want to do that?
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 2/3] powerpc/mpic: add global timer support
-Original Message-
From: Wood Scott-B07421
Sent: Thursday, March 21, 2013 7:00 AM
To: Wang Dongsheng-B40534
Cc: Wood Scott-B07421; Gala Kumar-B11780; linuxppc-dev@lists.ozlabs.org;
Li Yang-R58472
Subject: Re: [PATCH 2/3] powerpc/mpic: add global timer support
On 03/20/2013 01:45:03 AM, Wang Dongsheng-B40534 wrote:
-Original Message-
From: Wood Scott-B07421
Sent: Wednesday, March 20, 2013 6:59 AM
To: Wang Dongsheng-B40534
Cc: Wood Scott-B07421; Gala Kumar-B11780;
linuxppc-dev@lists.ozlabs.org;
Li Yang-R58472
Subject: Re: [PATCH 2/3] powerpc/mpic: add global timer support
On 03/19/2013 02:55:58 AM, Wang Dongsheng-B40534 wrote:
+static void convert_ticks_to_time(struct timer_group_priv
*priv,
+ const u64 ticks, struct timeval *time) {
+ u64 tmp_sec;
+ u32 rem_us;
+ u32 div;
+
+ if (!(priv-flags FSL_GLOBAL_TIMER)) {
+ time-tv_sec = (__kernel_time_t)
+ div_u64_rem(ticks, priv-timerfreq,
rem_us);
+ tmp_sec = (u64)time-tv_sec *
(u64)priv-timerfreq;
+ time-tv_usec = (__kernel_suseconds_t)
+ div_u64((ticks - tmp_sec) * 100,
priv-timerfreq);
+
+ return;
+ }
+
+ div = (1 (MPIC_TIMER_TCR_CLKDIV_64 8)) * 8;
+
+ time-tv_sec = (__kernel_time_t)div_u64(ticks, priv-
timerfreq
/ div);
+ tmp_sec = div_u64((u64)time-tv_sec *
(u64)priv-timerfreq,
div);
+
+ time-tv_usec = (__kernel_suseconds_t)
+ div_u64((ticks - tmp_sec) * 100,
priv-timerfreq /
div);
+
+ return;
Why don't you just adjust the clock frequency up front for
CLKDIV_64,
rather than introduce alternate (and untested!) code paths
throughout the
driver?
No, It cannot be integrated. The div cannot be removed.
Because if do priv-timerfreq /= div, that will affect the
accuracy.
Like:
3 * 5 / 2 = 7;
3 / 2 * 5 = 5;
I don't follow -- a change in the clock speed is a change in the
clock
speed, no matter how you accomplish it.
This is not change hardware clock frequency.
Citation needed. It looks like a change in the timer frequency to me:
Clock ratio. Specifies the ratio of the timer frequency to the MPIC
input clock (platform clock/2) . The
following clock ratios are supported:
00
01
10
11
Default. Divide by 8
Divide by 16
Divide by 32
Divide by 64
The end result is that the counter in the timer register changes only
1/64 as often as the input clock. There's nothing special about that,
compared to having an input clock that is 1/64 the speed.
The mpic timer hardware clock is not be changed after initialization.
This is just conversion ticks.
These calculated ticks will be set to the hardware.
How you round is a different question. You should probably be
rounding
up always, based on the final clock frequency -- though it's
unlikely to
matter much given the high precision of the timer relative to the
input
granularity.
Each ticks are based on the mpic timer hardware clock frequency.
The conversion and calculation are in order to make the tick value is
more
accurate, more close to real time.
If echo 40 seconds may be difference is not obvious. But echo
31536(10 years)
difference is obvious.
So basically you're taking advantage of the fact that you have what
appears to be a more precise value of the frequency than is expressible
in integer Hz -- but I think that's false precision; odds are the
frequency is not accurate to 1 Hz to begin with. Even if it is, I doubt
it's worth worrying about. The error as a percentage will still be very
small with an input frequency of many MHz. Does an error of a few
minutes really matter if you're delaying for 10 years? That's
acceptable
clock drift for something not synced to network time. The main thing is
to ensure that you round up, not down, so that software doesn't see an
early wakeup as measured by its own timers.
BTW, the input clock frequency has been similarly scaled, yet you don't
try to scrounge up that information to get further precision...
Let's go back patch, do you think the code is repeated?
I will remove if (!(priv-flags FSL_GLOBAL_TIMER)) branch, there will be no
redundant code.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 2/3] powerpc/mpic: add global timer support
-Original Message-
From: Wood Scott-B07421
Sent: Wednesday, March 20, 2013 6:59 AM
To: Wang Dongsheng-B40534
Cc: Wood Scott-B07421; Gala Kumar-B11780; linuxppc-dev@lists.ozlabs.org;
Li Yang-R58472
Subject: Re: [PATCH 2/3] powerpc/mpic: add global timer support
On 03/19/2013 02:55:58 AM, Wang Dongsheng-B40534 wrote:
+static void convert_ticks_to_time(struct timer_group_priv *priv,
+ const u64 ticks, struct timeval *time) {
+ u64 tmp_sec;
+ u32 rem_us;
+ u32 div;
+
+ if (!(priv-flags FSL_GLOBAL_TIMER)) {
+ time-tv_sec = (__kernel_time_t)
+ div_u64_rem(ticks, priv-timerfreq, rem_us);
+ tmp_sec = (u64)time-tv_sec * (u64)priv-timerfreq;
+ time-tv_usec = (__kernel_suseconds_t)
+ div_u64((ticks - tmp_sec) * 100,
priv-timerfreq);
+
+ return;
+ }
+
+ div = (1 (MPIC_TIMER_TCR_CLKDIV_64 8)) * 8;
+
+ time-tv_sec = (__kernel_time_t)div_u64(ticks, priv-
timerfreq
/ div);
+ tmp_sec = div_u64((u64)time-tv_sec * (u64)priv-timerfreq,
div);
+
+ time-tv_usec = (__kernel_suseconds_t)
+ div_u64((ticks - tmp_sec) * 100, priv-timerfreq /
div);
+
+ return;
Why don't you just adjust the clock frequency up front for
CLKDIV_64,
rather than introduce alternate (and untested!) code paths
throughout the
driver?
No, It cannot be integrated. The div cannot be removed.
Because if do priv-timerfreq /= div, that will affect the accuracy.
Like:
3 * 5 / 2 = 7;
3 / 2 * 5 = 5;
I don't follow -- a change in the clock speed is a change in the clock
speed, no matter how you accomplish it.
This is not change hardware clock frequency. The mpic timer hardware clock
is not be changed after initialization. This is just conversion ticks.
These calculated ticks will be set to the hardware.
How you round is a different question. You should probably be rounding
up always, based on the final clock frequency -- though it's unlikely to
matter much given the high precision of the timer relative to the input
granularity.
Each ticks are based on the mpic timer hardware clock frequency.
The conversion and calculation are in order to make the tick value is more
accurate, more close to real time.
If echo 40 seconds may be difference is not obvious. But echo 31536(10
years)
difference is obvious.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 3/3] powerpc/fsl: add MPIC timer wakeup support
Hi Scoot,
Thanks for reviewing.
-Original Message-
From: Wood Scott-B07421
Sent: Tuesday, March 19, 2013 8:31 AM
To: Wang Dongsheng-B40534
Cc: Gala Kumar-B11780; linuxppc-dev@lists.ozlabs.org; Wang Dongsheng-
B40534; Zhao Chenhui-B35336; Li Yang-R58472
Subject: Re: [PATCH 3/3] powerpc/fsl: add MPIC timer wakeup support
On 03/08/2013 01:38:47 AM, Wang Dongsheng wrote:
The driver provides a way to wake up the system by the MPIC timer.
For example,
echo 5 /sys/devices/system/mpic/timer_wakeup
echo standby /sys/power/state
After 5 seconds the MPIC timer will generate an interrupt to wake up
the system.
Signed-off-by: Wang Dongsheng dongsheng.w...@freescale.com
Signed-off-by: Zhao Chenhui chenhui.z...@freescale.com
Signed-off-by: Li Yang le...@freescale.com
Does this work with deep sleep (echo mem /sys/power/state on mpc8536,
p1022, etc) or just regular sleep?
The deep sleep can also work.
---
arch/powerpc/platforms/Kconfig |9 ++
arch/powerpc/sysdev/Makefile|1 +
arch/powerpc/sysdev/fsl_mpic_timer_wakeup.c | 185
+++
3 files changed, 195 insertions(+), 0 deletions(-) create mode
100644 arch/powerpc/sysdev/fsl_mpic_timer_wakeup.c
diff --git a/arch/powerpc/platforms/Kconfig
b/arch/powerpc/platforms/Kconfig index 5af04fa..487c37f 100644
--- a/arch/powerpc/platforms/Kconfig
+++ b/arch/powerpc/platforms/Kconfig
@@ -99,6 +99,15 @@ config MPIC_TIMER
only tested on fsl chip, but it can potentially support
other global timers complying to Open-PIC standard.
+config FSL_MPIC_TIMER_WAKEUP
+ tristate Freescale MPIC global timer wakeup driver
+ depends on FSL_SOC MPIC_TIMER
+ default n
+ help
+ This is only for freescale powerpc platform.
This sentence is redundant... It already says Freescale MPIC in the
name and depends on FSL_SOC MPIC_TIMER.
Um...yes, I will remove it.
+static irqreturn_t fsl_mpic_timer_irq(int irq, void *dev_id) {
+ struct fsl_mpic_timer_wakeup *wakeup = dev_id;
+
+ schedule_work(wakeup-free_work);
+ return IRQ_HANDLED;
+}
return wakeup-timer ? IRQ_HANDLED : IRQ_NONE;
Looks better, thanks.
+
+static ssize_t fsl_timer_wakeup_show(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
+{
+ struct timeval interval;
+ int val = 0;
+
+ mutex_lock(sysfs_lock);
+ if (fsl_wakeup-timer) {
+ mpic_get_remain_time(fsl_wakeup-timer, interval);
+ val = interval.tv_sec + 1;
+ }
+ mutex_unlock(sysfs_lock);
+
+ return sprintf(buf, %d\n, val);
+}
+
+static ssize_t fsl_timer_wakeup_store(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf,
+ size_t count)
+{
+ struct timeval interval;
+ int ret;
+
+ interval.tv_usec = 0;
+ if (kstrtol(buf, 0, interval.tv_sec))
+ return -EINVAL;
I don't think the buffer will NUL-terminated... Ordinarily there'll be
an LF terminator, but you can't rely on that (many other sysfs attributes
seem to, though...).
I think we don't need to care about LF terminator.
The kstrtol-- _kstrtoull has been done.
+ mutex_lock(sysfs_lock);
+
+ if (fsl_wakeup-timer !interval.tv_sec) {
+ disable_irq_wake(fsl_wakeup-timer-irq);
+ mpic_free_timer(fsl_wakeup-timer);
+ fsl_wakeup-timer = NULL;
+ mutex_unlock(sysfs_lock);
+
+ return count;
+ }
+
+ if (fsl_wakeup-timer) {
+ mutex_unlock(sysfs_lock);
+ return -EBUSY;
+ }
So to change an already-set timer you have to set it to zero and then to
what you want? Why not just do:
if (fsl_wakeup-timer) {
disable_irq_wake(...);
mpic_free_timer(...);
fsl_wakeup_timer = NULL;
}
if (!interval.tv_sec) {
mutex_unlock(sysfs_lock);
return count;
}
You can't break up the it.
if echo zero the code will cancel the timer that is currently running.
Not echo non-zero value just zero to cancel.
+ ret = subsys_system_register(mpic_subsys, NULL);
+ if (ret)
+ goto err;
Maybe arch/powerpc/sysdev/mpic.c should be doing this?
This can be registered by mpic. Maybe better than here.
+
+ for (i = 0; mpic_attributes[i]; i++) {
+ ret = device_create_file(mpic_subsys.dev_root,
+ mpic_attributes[i]);
+ if (ret)
+ goto err2;
+ }
Is this code ever going to register more than one?
No, just one. I only keep the style here.
If you don't think it's necessary I can remove this loop.
___
Linuxppc-dev mailing list
Linuxppc-dev
RE: [PATCH][UPSTEAM] powerpc/mpic: add irq_set_wake support
-Original Message-
From: Wood Scott-B07421
Sent: Tuesday, March 19, 2013 7:36 AM
To: Wang Dongsheng-B40534
Cc: linuxppc-dev@lists.ozlabs.org; ga...@kernel.crashing.org
Subject: Re: [PATCH][UPSTEAM] powerpc/mpic: add irq_set_wake support
On 01/30/2013 09:10:23 PM, Wang Dongsheng wrote:
Add irq_set_wake support. Just add IRQF_NO_SUSPEND to
desc-action-flag.
So the wake up interrupt will not be disable in suspend_device_irqs.
Signed-off-by: Wang Dongsheng dongsheng.w...@freescale.com
---
arch/powerpc/sysdev/mpic.c | 15 +++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/sysdev/mpic.c b/arch/powerpc/sysdev/mpic.c
index 9c6e535..2ed0220 100644
--- a/arch/powerpc/sysdev/mpic.c
+++ b/arch/powerpc/sysdev/mpic.c
@@ -920,6 +920,18 @@ int mpic_set_irq_type(struct irq_data *d,
unsigned int flow_type)
return IRQ_SET_MASK_OK_NOCOPY;
}
+static int mpic_irq_set_wake(struct irq_data *d, unsigned int on)
+{
+ struct irq_desc *desc = container_of(d, struct irq_desc,
irq_data);
+
+ if (on)
+ desc-action-flags |= IRQF_NO_SUSPEND;
+ else
+ desc-action-flags = ~IRQF_NO_SUSPEND;
+
+ return 0;
+}
This should really be something like fsl_mpic_irq_set_wake() and only
set when we have an FSL MPIC.
Thanks, Add #ifdef FSL_SOC to control.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 2/3] powerpc/mpic: add global timer support
+static void convert_ticks_to_time(struct timer_group_priv *priv,
+ const u64 ticks, struct timeval *time) {
+ u64 tmp_sec;
+ u32 rem_us;
+ u32 div;
+
+ if (!(priv-flags FSL_GLOBAL_TIMER)) {
+ time-tv_sec = (__kernel_time_t)
+ div_u64_rem(ticks, priv-timerfreq, rem_us);
+ tmp_sec = (u64)time-tv_sec * (u64)priv-timerfreq;
+ time-tv_usec = (__kernel_suseconds_t)
+ div_u64((ticks - tmp_sec) * 100,
priv-timerfreq);
+
+ return;
+ }
+
+ div = (1 (MPIC_TIMER_TCR_CLKDIV_64 8)) * 8;
+
+ time-tv_sec = (__kernel_time_t)div_u64(ticks, priv-timerfreq
/ div);
+ tmp_sec = div_u64((u64)time-tv_sec * (u64)priv-timerfreq,
div);
+
+ time-tv_usec = (__kernel_suseconds_t)
+ div_u64((ticks - tmp_sec) * 100, priv-timerfreq /
div);
+
+ return;
Why don't you just adjust the clock frequency up front for CLKDIV_64,
rather than introduce alternate (and untested!) code paths throughout the
driver?
No, It cannot be integrated. The div cannot be removed.
Because if do priv-timerfreq /= div, that will affect the accuracy.
Like:
3 * 5 / 2 = 7;
3 / 2 * 5 = 5;
BTW
if (!(priv-flags FSL_GLOBAL_TIMER)) {
time-tv_sec = (__kernel_time_t)
div_u64_rem(ticks, priv-timerfreq, rem_us);
tmp_sec = (u64)time-tv_sec * (u64)priv-timerfreq;
time-tv_usec = (__kernel_suseconds_t)
div_u64((ticks - tmp_sec) * 100, priv-timerfreq);
return;
}
This branch I has been tested.
Test methods:
1. Get timerfreq and set timerfreq.
timerfreq /= 64;(Clock ratio is divide by 64)
2. Clear FSL_GLOBAL_TIMER flag.
Test Log:
[root@p5020 root]# echo 20 /sys/devices/system/mpic/timer_wakeup
[root@p5020 root]# cat /sys/devices/system/mpic/timer_wakeup
sec = 18, ticks = 118295518.., timerfreq = 624..
19
[root@p5020 root]# cat /sys/devices/system/mpic/timer_wakeup
sec = 17, ticks = 110095766.., timerfreq = 624..
18
[root@p5020 root]# cat /sys/devices/system/mpic/timer_wakeup
sec = 16, ticks = 105095737.., timerfreq = 624..
17
[root@p5020 root]# cat /sys/devices/system/mpic/timer_wakeup
sec = 15, ticks = 99495711.., timerfreq = 624..
16
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 3/3] powerpc/fsl: add MPIC timer wakeup support
-Original Message-
From: Wood Scott-B07421
Sent: Wednesday, March 20, 2013 6:55 AM
To: Wang Dongsheng-B40534
Cc: Wood Scott-B07421; Gala Kumar-B11780; linuxppc-dev@lists.ozlabs.org;
Zhao Chenhui-B35336; Li Yang-R58472
Subject: Re: [PATCH 3/3] powerpc/fsl: add MPIC timer wakeup support
On 03/19/2013 01:25:42 AM, Wang Dongsheng-B40534 wrote:
-Original Message-
From: Wood Scott-B07421
Sent: Tuesday, March 19, 2013 8:31 AM
To: Wang Dongsheng-B40534
Cc: Gala Kumar-B11780; linuxppc-dev@lists.ozlabs.org; Wang
Dongsheng-
B40534; Zhao Chenhui-B35336; Li Yang-R58472
Subject: Re: [PATCH 3/3] powerpc/fsl: add MPIC timer wakeup support
On 03/08/2013 01:38:47 AM, Wang Dongsheng wrote:
+static ssize_t fsl_timer_wakeup_store(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf,
+ size_t count)
+{
+ struct timeval interval;
+ int ret;
+
+ interval.tv_usec = 0;
+ if (kstrtol(buf, 0, interval.tv_sec))
+ return -EINVAL;
I don't think the buffer will NUL-terminated... Ordinarily
there'll be
an LF terminator, but you can't rely on that (many other sysfs
attributes
seem to, though...).
I think we don't need to care about LF terminator.
The kstrtol-- _kstrtoull has been done.
My point is, what happens if userspace passes in a buffer that has no
terminator of any sort? kstrtol will continue reading beyond the end of
the buffer.
Do not care about terminator.
kstrtol-- _kstrtoull-- _parse_integer
_kstrtoull(...) {
...
rv = _parse_integer(s, base, _res);
if (rv KSTRTOX_OVERFLOW)
return -ERANGE;
rv = ~KSTRTOX_OVERFLOW;
if (rv == 0)
return -EINVAL;
s += rv;
if (*s == '\n')
s++;
if (*s)
return -EINVAL;
...
}
_parse_integer(...) {
...
while (*s) {
if ('0' = *s *s = '9')
val = *s - '0';
else if ('a' = _tolower(*s) _tolower(*s) = 'f')
val = _tolower(*s) - 'a' + 10;
else
break; //this will break out to convert.
if (val = base)
break;
}
...
}
+ mutex_lock(sysfs_lock);
+
+ if (fsl_wakeup-timer !interval.tv_sec) {
+ disable_irq_wake(fsl_wakeup-timer-irq);
+ mpic_free_timer(fsl_wakeup-timer);
+ fsl_wakeup-timer = NULL;
+ mutex_unlock(sysfs_lock);
+
+ return count;
+ }
+
+ if (fsl_wakeup-timer) {
+ mutex_unlock(sysfs_lock);
+ return -EBUSY;
+ }
So to change an already-set timer you have to set it to zero and
then to
what you want? Why not just do:
if (fsl_wakeup-timer) {
disable_irq_wake(...);
mpic_free_timer(...);
fsl_wakeup_timer = NULL;
}
if (!interval.tv_sec) {
mutex_unlock(sysfs_lock);
return count;
}
You can't break up the it.
if echo zero the code will cancel the timer that is currently running.
Not echo non-zero value just zero to cancel.
Echoing a nonzero value wouldn't just be to cancel, it would be to set a
new timer after cancelling the old.
If you think this way is better, I can change.
But why should do it?
Explicitly stop the timer (echo 0) before reuse it is more reasonable for me.
+ for (i = 0; mpic_attributes[i]; i++) {
+ ret = device_create_file(mpic_subsys.dev_root,
+ mpic_attributes[i]);
+ if (ret)
+ goto err2;
+ }
Is this code ever going to register more than one?
No, just one. I only keep the style here.
If you don't think it's necessary I can remove this loop.
I don't think it's necessary.
Ok, I will remove this loop.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 1/3] powerpc/mpic: add irq_set_wake support
Hi Benjamin Kumar,
I am not sure who can apply these patches...
Could you apply these patches?
Thanks.
[1/3] powerpc/mpic: add irq_set_wake support
http://patchwork.ozlabs.org/patch/226034/
[2/3] powerpc/mpic: add global timer support
http://patchwork.ozlabs.org/patch/226035/
[3/3] powerpc/fsl: add MPIC timer wakeup support
http://patchwork.ozlabs.org/patch/226036/
-Original Message-
From: Wang Dongsheng-B40534
Sent: Friday, March 08, 2013 3:39 PM
To: Wood Scott-B07421; Gala Kumar-B11780
Cc: linuxppc-dev@lists.ozlabs.org; Wang Dongsheng-B40534
Subject: [PATCH 1/3] powerpc/mpic: add irq_set_wake support
Add irq_set_wake support. Just add IRQF_NO_SUSPEND to desc-action-flag.
So the wake up interrupt will not be disable in suspend_device_irqs.
Signed-off-by: Wang Dongsheng dongsheng.w...@freescale.com
---
arch/powerpc/sysdev/mpic.c | 15 +++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/sysdev/mpic.c b/arch/powerpc/sysdev/mpic.c
index 3b2efd4..10e474e 100644
--- a/arch/powerpc/sysdev/mpic.c
+++ b/arch/powerpc/sysdev/mpic.c
@@ -920,6 +920,18 @@ int mpic_set_irq_type(struct irq_data *d, unsigned
int flow_type)
return IRQ_SET_MASK_OK_NOCOPY;
}
+static int mpic_irq_set_wake(struct irq_data *d, unsigned int on) {
+ struct irq_desc *desc = container_of(d, struct irq_desc, irq_data);
+
+ if (on)
+ desc-action-flags |= IRQF_NO_SUSPEND;
+ else
+ desc-action-flags = ~IRQF_NO_SUSPEND;
+
+ return 0;
+}
+
void mpic_set_vector(unsigned int virq, unsigned int vector) {
struct mpic *mpic = mpic_from_irq(virq); @@ -957,6 +969,7 @@ static
struct irq_chip mpic_irq_chip = {
.irq_unmask = mpic_unmask_irq,
.irq_eoi= mpic_end_irq,
.irq_set_type = mpic_set_irq_type,
+ .irq_set_wake = mpic_irq_set_wake,
};
#ifdef CONFIG_SMP
@@ -971,6 +984,7 @@ static struct irq_chip mpic_tm_chip = {
.irq_mask = mpic_mask_tm,
.irq_unmask = mpic_unmask_tm,
.irq_eoi= mpic_end_irq,
+ .irq_set_wake = mpic_irq_set_wake,
};
#ifdef CONFIG_MPIC_U3_HT_IRQS
@@ -981,6 +995,7 @@ static struct irq_chip mpic_irq_ht_chip = {
.irq_unmask = mpic_unmask_ht_irq,
.irq_eoi= mpic_end_ht_irq,
.irq_set_type = mpic_set_irq_type,
+ .irq_set_wake = mpic_irq_set_wake,
};
#endif /* CONFIG_MPIC_U3_HT_IRQS */
--
1.7.5.1
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH][UPSTEAM] powerpc/mpic: add irq_set_wake support
Hi Benjamin,
Could you please apply this patch?
Regards,
dongsheng
-Original Message-
From: Wang Dongsheng-B40534
Sent: Wednesday, February 20, 2013 1:58 PM
To: 'Kumar Gala'
Cc: linuxppc-dev@lists.ozlabs.org
Subject: RE: [PATCH][UPSTEAM] powerpc/mpic: add irq_set_wake support
-Original Message-
From: Kumar Gala [mailto:ga...@kernel.crashing.org]
Sent: Tuesday, February 19, 2013 3:43 AM
To: Wang Dongsheng-B40534
Cc: linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH][UPSTEAM] powerpc/mpic: add irq_set_wake support
On Jan 30, 2013, at 9:10 PM, Wang Dongsheng wrote:
Add irq_set_wake support. Just add IRQF_NO_SUSPEND to desc-action-
flag.
So the wake up interrupt will not be disable in suspend_device_irqs.
Signed-off-by: Wang Dongsheng dongsheng.w...@freescale.com
---
arch/powerpc/sysdev/mpic.c | 15 +++
1 files changed, 15 insertions(+), 0 deletions(-)
Why are we doing this globally for all interrupts? Don't we only have
some specific interrupts that wake us up?
Also, I'm guessing the wake behavior for interrupts is FSL specific so
should not apply to ALL users of MPIC.
That is IRQ wakeup (PM) control. Actually not all interrupts will be set.
We just let mpic have this ability. It's control by driver.
If a device has the ability to wake up system, this device driver can set
irq wake up(through enable/disable_irq_wake()), and the driver do not
need add a flag(IRQF_NO_SUSPEND) to request_irq().
for example,
suspend()
{
...;
enable_irq_wake(irq);
...;
}
resume()
{
...;
disable_irq_wake(irq);
...;
}
- k
diff --git a/arch/powerpc/sysdev/mpic.c b/arch/powerpc/sysdev/mpic.c
index 9c6e535..2ed0220 100644
--- a/arch/powerpc/sysdev/mpic.c
+++ b/arch/powerpc/sysdev/mpic.c
@@ -920,6 +920,18 @@ int mpic_set_irq_type(struct irq_data *d,
unsigned
int flow_type)
return IRQ_SET_MASK_OK_NOCOPY;
}
+static int mpic_irq_set_wake(struct irq_data *d, unsigned int on) {
+ struct irq_desc *desc = container_of(d, struct irq_desc,
+irq_data);
+
+ if (on)
+ desc-action-flags |= IRQF_NO_SUSPEND;
+ else
+ desc-action-flags = ~IRQF_NO_SUSPEND;
+
+ return 0;
+}
+
void mpic_set_vector(unsigned int virq, unsigned int vector) {
struct mpic *mpic = mpic_from_irq(virq); @@ -957,6 +969,7 @@ static
struct irq_chip mpic_irq_chip = {
.irq_unmask = mpic_unmask_irq,
.irq_eoi= mpic_end_irq,
.irq_set_type = mpic_set_irq_type,
+ .irq_set_wake = mpic_irq_set_wake,
};
#ifdef CONFIG_SMP
@@ -971,6 +984,7 @@ static struct irq_chip mpic_tm_chip = {
.irq_mask = mpic_mask_tm,
.irq_unmask = mpic_unmask_tm,
.irq_eoi= mpic_end_irq,
+ .irq_set_wake = mpic_irq_set_wake,
};
#ifdef CONFIG_MPIC_U3_HT_IRQS
@@ -981,6 +995,7 @@ static struct irq_chip mpic_irq_ht_chip = {
.irq_unmask = mpic_unmask_ht_irq,
.irq_eoi= mpic_end_ht_irq,
.irq_set_type = mpic_set_irq_type,
+ .irq_set_wake = mpic_irq_set_wake,
};
#endif /* CONFIG_MPIC_U3_HT_IRQS */
--
1.7.5.1
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [RFC][PATCH] powerpc: add Book E support to 64-bit hibernation
-Original Message- From: Johannes Berg [mailto:johan...@sipsolutions.net] Sent: Friday, February 22, 2013 5:09 PM To: Wang Dongsheng-B40534 Cc: b...@kernel.crashing.org; linuxppc-dev@lists.ozlabs.org; Wood Scott- B07421; Li Yang-R58472; Zhao Chenhui-B35336 Subject: Re: [RFC][PATCH] powerpc: add Book E support to 64-bit hibernation Hi, Subject: [RFC][PATCH] powerpc: add Book E support to 64-bit hibernation Any thoughts about this patch? Heh, honestly, no. I know nothing about Book E, and it's too long ago that I wrote (some of) the 64-bit hibernation code. Thanks for your feedback. Could you give me some advice about cache flush. It confused me that why only 1 MiB is flushed from KERNEL_START on Powermac G5. On FSL Book E(e500 family), Even if I don't flash cache, the work is also normal(Dcaches are kept coherent by hardware, and icaches are kept coherent by software). But I still worry about caches. Is there a need to flush L2 cache if I have already flushed L1 cache? Or on Powermac G5, flush caches is a general way? Powermac G5 Codes: /* flush caches */ lis r3, 0x10 mtctr r3 li r3, 0 ori r3, r3, CONFIG_KERNEL_START48 li r0, 48 sld r3, r3, r0 li r0, 0 1: dcbfr0,r3 addir3,r3,0x20 bdnz1b sync tlbia johannes ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [RFC][PATCH] powerpc: add Book E support to 64-bit hibernation
Hi Benjamin Johannes, Any thoughts about this patch? -Original Message- From: Wang Dongsheng-B40534 Sent: Thursday, February 07, 2013 10:25 AM To: linuxppc-dev@lists.ozlabs.org Cc: Wood Scott-B07421; Li Yang-R58472; Zhao Chenhui-B35336; Wang Dongsheng-B40534 Subject: [RFC][PATCH] powerpc: add Book E support to 64-bit hibernation Update the 64-bit hibernation code to support Book E CPUs. Some registers and instructions are not defined for Book3e (SDR reg, tlbia instruction). SDR: Storage Description Register. Book3S and Book3E have different address translation mode, we do not need HTABORG HTABSIZE to translate virtual address to real address. More registers are saved in BookE-64bit.(TCR, SPRGx) Signed-off-by: Wang Dongsheng dongsheng.w...@freescale.com --- Hopefully someone can give me some advice about cache flush. It confused me that why only 1 MiB is flushed from KERNEL_START on Book3S. Is there a need to flush L2 cache if I have already flushed L1 cache? If yes, how about L3 cache? Cache levels are different in cores, the instruction sets may also be different. 1 files changed, 62 insertions(+), 2 deletions(-) diff --git a/arch/powerpc/kernel/swsusp_asm64.S b/arch/powerpc/kernel/swsusp_asm64.S index 86ac1d9..608e4ceb 100644 --- a/arch/powerpc/kernel/swsusp_asm64.S +++ b/arch/powerpc/kernel/swsusp_asm64.S @@ -46,10 +46,29 @@ #define SL_r29 0xe8 #define SL_r30 0xf0 #define SL_r31 0xf8 -#define SL_SIZE SL_r31+8 +#define SL_SPRG0 0x100 +#define SL_SPRG1 0x108 +#define SL_SPRG2 0x110 +#define SL_SPRG3 0x118 +#define SL_SPRG4 0x120 +#define SL_SPRG5 0x128 +#define SL_SPRG6 0x130 +#define SL_SPRG7 0x138 +#define SL_TCR 0x140 +#define SL_SIZE SL_TCR+8 /* these macros rely on the save area being * pointed to by r11 */ + +#define SAVE_SPR(register) \ + mfspr r0,SPRN_##register ;\ + std r0,SL_##register(r11) +#define RESTORE_SPR(register)\ + ld r0,SL_##register(r11) ;\ + mtspr SPRN_##register,r0 +#define RESTORE_SPRG(n) \ + ld r0,SL_SPRG##n(r11) ;\ + mtsprg n,r0 #define SAVE_SPECIAL(special)\ mf##special r0 ;\ std r0, SL_##special(r11) @@ -103,8 +122,21 @@ _GLOBAL(swsusp_arch_suspend) SAVE_REGISTER(r30) SAVE_REGISTER(r31) SAVE_SPECIAL(MSR) - SAVE_SPECIAL(SDR1) SAVE_SPECIAL(XER) +#ifdef CONFIG_PPC_BOOK3S_64 + SAVE_SPECIAL(SDR1) +#else + SAVE_SPR(TCR) + /* Save SPRGs */ + SAVE_SPR(SPRG0) + SAVE_SPR(SPRG1) + SAVE_SPR(SPRG2) + SAVE_SPR(SPRG3) + SAVE_SPR(SPRG4) + SAVE_SPR(SPRG5) + SAVE_SPR(SPRG6) + SAVE_SPR(SPRG7) +#endif /* we push the stack up 128 bytes but don't store the * stack pointer on the stack like a real stackframe */ @@ -151,6 +183,7 @@ copy_page_loop: bne+copyloop nothing_to_copy: +#ifdef CONFIG_PPC_BOOK3S_64 /* flush caches */ lis r3, 0x10 mtctr r3 @@ -167,6 +200,7 @@ nothing_to_copy: sync tlbia +#endif ld r11,swsusp_save_area_ptr@toc(r2) @@ -208,16 +242,42 @@ nothing_to_copy: RESTORE_REGISTER(r29) RESTORE_REGISTER(r30) RESTORE_REGISTER(r31) + +#ifdef CONFIG_PPC_BOOK3S_64 /* can't use RESTORE_SPECIAL(MSR) */ ld r0, SL_MSR(r11) mtmsrd r0, 0 RESTORE_SPECIAL(SDR1) +#else + /* Save SPRGs */ + RESTORE_SPRG(0) + RESTORE_SPRG(1) + RESTORE_SPRG(2) + RESTORE_SPRG(3) + RESTORE_SPRG(4) + RESTORE_SPRG(5) + RESTORE_SPRG(6) + RESTORE_SPRG(7) + + RESTORE_SPECIAL(MSR) + + /* Restore TCR and clear any pending bits in TSR. */ + RESTORE_SPR(TCR) + lis r0, (TSR_ENW | TSR_WIS | TSR_DIS | TSR_FIS)@h + mtspr SPRN_TSR,r0 + + /* Kick decrementer */ + li r0,1 + mtdec r0 +#endif RESTORE_SPECIAL(XER) sync addir1,r1,-128 +#ifdef CONFIG_PPC_BOOK3S_64 bl slb_flush_and_rebolt +#endif bl do_after_copyback addir1,r1,128 -- 1.7.5.1 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH][UPSTEAM] powerpc/mpic: add irq_set_wake support
-Original Message-
From: Kumar Gala [mailto:ga...@kernel.crashing.org]
Sent: Tuesday, February 19, 2013 3:43 AM
To: Wang Dongsheng-B40534
Cc: linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH][UPSTEAM] powerpc/mpic: add irq_set_wake support
On Jan 30, 2013, at 9:10 PM, Wang Dongsheng wrote:
Add irq_set_wake support. Just add IRQF_NO_SUSPEND to desc-action-
flag.
So the wake up interrupt will not be disable in suspend_device_irqs.
Signed-off-by: Wang Dongsheng dongsheng.w...@freescale.com
---
arch/powerpc/sysdev/mpic.c | 15 +++
1 files changed, 15 insertions(+), 0 deletions(-)
Why are we doing this globally for all interrupts? Don't we only have
some specific interrupts that wake us up?
Also, I'm guessing the wake behavior for interrupts is FSL specific so
should not apply to ALL users of MPIC.
That is IRQ wakeup (PM) control. Actually not all interrupts will be set.
We just let mpic have this ability. It's control by driver.
If a device has the ability to wake up system, this device driver can set
irq wake up(through enable/disable_irq_wake()), and the driver do not need
add a flag(IRQF_NO_SUSPEND) to request_irq().
for example,
suspend()
{
...;
enable_irq_wake(irq);
...;
}
resume()
{
...;
disable_irq_wake(irq);
...;
}
- k
diff --git a/arch/powerpc/sysdev/mpic.c b/arch/powerpc/sysdev/mpic.c
index 9c6e535..2ed0220 100644
--- a/arch/powerpc/sysdev/mpic.c
+++ b/arch/powerpc/sysdev/mpic.c
@@ -920,6 +920,18 @@ int mpic_set_irq_type(struct irq_data *d, unsigned
int flow_type)
return IRQ_SET_MASK_OK_NOCOPY;
}
+static int mpic_irq_set_wake(struct irq_data *d, unsigned int on) {
+ struct irq_desc *desc = container_of(d, struct irq_desc, irq_data);
+
+ if (on)
+ desc-action-flags |= IRQF_NO_SUSPEND;
+ else
+ desc-action-flags = ~IRQF_NO_SUSPEND;
+
+ return 0;
+}
+
void mpic_set_vector(unsigned int virq, unsigned int vector) {
struct mpic *mpic = mpic_from_irq(virq); @@ -957,6 +969,7 @@ static
struct irq_chip mpic_irq_chip = {
.irq_unmask = mpic_unmask_irq,
.irq_eoi= mpic_end_irq,
.irq_set_type = mpic_set_irq_type,
+ .irq_set_wake = mpic_irq_set_wake,
};
#ifdef CONFIG_SMP
@@ -971,6 +984,7 @@ static struct irq_chip mpic_tm_chip = {
.irq_mask = mpic_mask_tm,
.irq_unmask = mpic_unmask_tm,
.irq_eoi= mpic_end_irq,
+ .irq_set_wake = mpic_irq_set_wake,
};
#ifdef CONFIG_MPIC_U3_HT_IRQS
@@ -981,6 +995,7 @@ static struct irq_chip mpic_irq_ht_chip = {
.irq_unmask = mpic_unmask_ht_irq,
.irq_eoi= mpic_end_ht_irq,
.irq_set_type = mpic_set_irq_type,
+ .irq_set_wake = mpic_irq_set_wake,
};
#endif /* CONFIG_MPIC_U3_HT_IRQS */
--
1.7.5.1
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH][UPSTEAM] powerpc/mpic: add irq_set_wake support
Hi Kumar,
Could you ack this patch?
Thanks.
-Original Message-
From: Wang Dongsheng-B40534
Sent: Thursday, January 31, 2013 11:10 AM
To: linuxppc-dev@lists.ozlabs.org
Cc: Wang Dongsheng-B40534
Subject: [PATCH][UPSTEAM] powerpc/mpic: add irq_set_wake support
Add irq_set_wake support. Just add IRQF_NO_SUSPEND to desc-action-flag.
So the wake up interrupt will not be disable in suspend_device_irqs.
Signed-off-by: Wang Dongsheng dongsheng.w...@freescale.com
---
arch/powerpc/sysdev/mpic.c | 15 +++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/sysdev/mpic.c b/arch/powerpc/sysdev/mpic.c
index 9c6e535..2ed0220 100644
--- a/arch/powerpc/sysdev/mpic.c
+++ b/arch/powerpc/sysdev/mpic.c
@@ -920,6 +920,18 @@ int mpic_set_irq_type(struct irq_data *d, unsigned
int flow_type)
return IRQ_SET_MASK_OK_NOCOPY;
}
+static int mpic_irq_set_wake(struct irq_data *d, unsigned int on)
+{
+ struct irq_desc *desc = container_of(d, struct irq_desc, irq_data);
+
+ if (on)
+ desc-action-flags |= IRQF_NO_SUSPEND;
+ else
+ desc-action-flags = ~IRQF_NO_SUSPEND;
+
+ return 0;
+}
+
void mpic_set_vector(unsigned int virq, unsigned int vector)
{
struct mpic *mpic = mpic_from_irq(virq);
@@ -957,6 +969,7 @@ static struct irq_chip mpic_irq_chip = {
.irq_unmask = mpic_unmask_irq,
.irq_eoi= mpic_end_irq,
.irq_set_type = mpic_set_irq_type,
+ .irq_set_wake = mpic_irq_set_wake,
};
#ifdef CONFIG_SMP
@@ -971,6 +984,7 @@ static struct irq_chip mpic_tm_chip = {
.irq_mask = mpic_mask_tm,
.irq_unmask = mpic_unmask_tm,
.irq_eoi= mpic_end_irq,
+ .irq_set_wake = mpic_irq_set_wake,
};
#ifdef CONFIG_MPIC_U3_HT_IRQS
@@ -981,6 +995,7 @@ static struct irq_chip mpic_irq_ht_chip = {
.irq_unmask = mpic_unmask_ht_irq,
.irq_eoi= mpic_end_ht_irq,
.irq_set_type = mpic_set_irq_type,
+ .irq_set_wake = mpic_irq_set_wake,
};
#endif /* CONFIG_MPIC_U3_HT_IRQS */
--
1.7.5.1
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
答复: [RFC PATCH] powerpc/fsl: add timer wakeup source
I'm pretty sure /proc/ is NOT where we want this exposed.
Should probably go under the sysfs directory of the mpic device. Or
better, make a generic interface for timer-based suspend wakeup (if
there
isn't one already). This current approach sits in an unpleasant
middle
ground between generic and device-specific.
/sys/power/wakeup_timer_seconds how about this?
I think it is a freescale generic interface, this interface control by
FSL_SOC SUSPEND.
There's no such thing as a Freescale generic interface. Linux APIs
are not organized by hardware vendor. Either make a truly generic
interface, reuse an existing one, or do something that is attached to
the specific driver.
Thanks, I think i can change mpic timer registration, i will use
platform_driver_register.
I will merge mpic timer and timer wakeup. In mpic timer the wakeup
function
controls by SUSPEND. The sys path is
/sys/devices/soc8572.4/ffe41100.timer/wakeup_seconds.
do you have any suggestions for this? or have a better idea about the sys path?
Use depends rather than if/else. Why do you need FSL_WAKEUP_SOURCE?
It lists all wake up source. If later have wakeup source can be
improved by
it to control. Buttons event wakeup source will be added after the
timer.
It does not list all wake up sources -- there's also ethernet, USB, etc.
fine, change to depends. thanks.
If the new time is zero, consider that a cancellation of the timer
and
don't request a new one or return -EINVAL.
Thanks, I think i should add comments. Let this patch easy to read.
Here is get a new timer.
If the new time is zero, consider that has been checked.
if (!time.tv_sec) {...} this is check zero.
The mpic_request_timer before this code.
Ah, I see. Wouldn't it be simpler to remove that block and just test
time.tv_sec when requesting the new timer?
Yes, wake up function only need seconds level, and it's just hold a timer.
echo zero to cancel, and echo a new time to update the timer time.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [RFC PATCH] powerpc/fsl: add timer wakeup source
-Original Message-
From: Wood Scott-B07421
Sent: Thursday, October 04, 2012 6:20 AM
To: Kumar Gala
Cc: Wang Dongsheng; Wood Scott-B07421; linuxppc-dev@lists.ozlabs.org list;
Wang Dongsheng-B40534; Li Yang-R58472; linux...@vger.kernel.org
Subject: Re: [RFC PATCH] powerpc/fsl: add timer wakeup source
On 10/03/2012 08:35:58 AM, Kumar Gala wrote:
On Oct 3, 2012, at 5:42 AM, Wang Dongsheng wrote:
This is only for freescale powerpc platform. The driver provides a
way
to wake up system. Proc
interface(/proc/powerpc/wakeup_timer_seconds).
eg: echo 5 /proc/powerpc/wakeup_timer_seconds, 5 seconds after
the system will be woken up. echo another time into proc
interface
to update the time.
Signed-off-by: Wang Dongsheng dongsheng.w...@freescale.com
Signed-off-by: Li Yang le...@freescale.com
---
arch/powerpc/platforms/Kconfig| 23 +++
arch/powerpc/platforms/Makefile |1 +
arch/powerpc/platforms/fsl_timer_wakeup.c | 217
+
3 files changed, 241 insertions(+)
create mode 100644 arch/powerpc/platforms/fsl_timer_wakeup.c
Adding the Linux PM list to see if there is some existing support for
this on other arch's in kernel.
I'm pretty sure /proc/ is NOT where we want this exposed.
Should probably go under the sysfs directory of the mpic device. Or
better, make a generic interface for timer-based suspend wakeup (if there
isn't one already). This current approach sits in an unpleasant middle
ground between generic and device-specific.
/sys/power/wakeup_timer_seconds how about this?
I think it is a freescale generic interface, this interface control by
FSL_SOC SUSPEND.
diff --git a/arch/powerpc/platforms/Kconfig
b/arch/powerpc/platforms/Kconfig
index b190a6e..7b9232a 100644
--- a/arch/powerpc/platforms/Kconfig
+++ b/arch/powerpc/platforms/Kconfig
@@ -99,6 +99,29 @@ config MPIC_TIMER
only tested on fsl chip, but it can potentially support
other global timers complying to Open-PIC standard.
+menuconfig FSL_WAKEUP_SOURCE
+ bool Freescale wakeup source
+ depends on FSL_SOC SUSPEND
+ default n
+ help
+ This option enables wakeup source for wake up system
+ features. This is only for freescale powerpc platform.
+
+if FSL_WAKEUP_SOURCE
+
+config FSL_TIMER_WAKEUP
+ tristate Freescale mpic global timer wakeup event
+ default n
+ help
+ This is only for freescale powerpc platform. The driver
+ provides a way to wake up system.
+ Proc interface(/proc/powerpc/wakeup_timer_seconds).
+ eg: echo 5 /proc/powerpc/wakeup_timer_seconds,
+ 5 seconds after the system will be woken up. echo another
+ time into proc interface to update the time.
+
+endif
Use depends rather than if/else. Why do you need FSL_WAKEUP_SOURCE?
It lists all wake up source. If later have wakeup source can be improved by
it to control. Buttons event wakeup source will be added after the timer.
These names are overly broad -- this is only for FSL MPIC, not for other
FSL chips (e.g. mpc83xx has a different global timer implementation, and
there's FSL ARM chips, etc).
Yes, thanks. Change to FSL_MPIC_TIMER_WAKEUP.
+static ssize_t timer_wakeup_write(struct file *file, const char
__user *buf,
+ size_t count, loff_t *off)
+{
+ struct fsl_timer_wakeup *priv;
+ struct inode *inode = file-f_path.dentry-d_inode;
+ struct proc_dir_entry *dp;
+ struct timeval time;
+ char *kbuf;
+
+ dp = PDE(inode);
+ priv = dp-data;
+
+ kbuf = kzalloc(count + 1, GFP_KERNEL);
+ if (!kbuf)
+ return -ENOMEM;
+
+ if (copy_from_user(kbuf, buf, count)) {
+ kfree(kbuf);
+ return -EFAULT;
+ }
+
+ kbuf[count] = '\0';
+
+ if (kstrtol(kbuf, 0, time.tv_sec)) {
+ kfree(kbuf);
+ return -EINVAL;
+ }
+
+ kfree(kbuf);
+
+ time.tv_usec = 0;
+
+ mutex_lock(priv-mutex);
+
+ if (!time.tv_sec) {
+ if (priv-timer) {
+ mpic_free_timer(priv-timer);
+ priv-timer = NULL;
+ }
+ mutex_unlock(priv-mutex);
+
+ return count;
+ }
+
+ if (priv-timer) {
+ mpic_free_timer(priv-timer);
+ priv-timer = NULL;
+ }
+
+ priv-timer = mpic_request_timer(timer_event_interrupt, priv,
time);
If the new time is zero, consider that a cancellation of the timer and
don't request a new one or return -EINVAL.
Thanks, I think i should add comments. Let this patch easy to read.
Here is get a new timer.
If the new time is zero, consider that has been checked.
if (!time.tv_sec) {...} this is check zero.
The mpic_request_timer before this code.
- Dongsheng
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo
RE: [PATCH v2 1/2] powerpc/mpic: Add Open-PIC global timer document
-Original Message-
From: Wood Scott-B07421
Sent: Wednesday, August 15, 2012 5:19 AM
To: Wang Dongsheng-B40534
Cc: Wood Scott-B07421; b...@kernel.crashing.org; pau...@samba.org;
linuxppc-dev@lists.ozlabs.org; devicetree-disc...@lists.ozlabs.org; Gala
Kumar-B11780; Li Yang-R58472
Subject: Re: [PATCH v2 1/2] powerpc/mpic: Add Open-PIC global timer
document
On 08/13/2012 09:40 PM, Wang Dongsheng-B40534 wrote:
+Example 2:
+
+ timer: timer@010f0 {
+ compatible = open-pic,global-timer;
+ device_type = open-pic;
+ reg = 0x010f0 4 0x01100 0x100;
+ interrupts = 0 0 3 0
+ 1 0 3 0
+ 2 0 3 0
+ 3 0 3 0;
+ };
4-cell interrupt specifiers are specific to Freescale MPICs. This
means there's no way to describe the timer interrupt on a non-
Freescale openpic.
Again, I suggest we not bother with this in the absence of an actual
need to support the timer on non-Freescale openpic in partitioned
scenarios.
The existing openpic node is sufficient to describe the
hardware in the absence of partitioning. We could have an
openpic-no-timer property to indicate that we're describing it
separately, so that the absence of a timer node isn't ambiguous as
to
whether it's an old tree or a partitioned scenario. An fsl,mpic
compatible would imply openpic-no-timer.
Note that I believe many of the non-Freescale openpic nodes are
going
to be found on systems with real Open Firmware, so we can't go
changing the device tree for them.
[Wang Dongsheng] In the Open-PIC specification, there are four timer.
interrupts = 0 0 3 0
1 0 3 0
2 0 3 0
3 0 3 0;
The interrupts just let user know there are four timers. Usage
based
interrupts
binding to change dts.
I can't understand the above or how it's a response to what I wrote.
[Wang Dongsheng] I mean this just to tell how many timers to support in
Open-PIC
specification. If someone needs to write interrupts into dts, this
must comply
with the specification of the interrupt to write. this is based on the
pic driver
should be changed in different platforms.
My point (beyond that examples provided should be valid for *some*
system) is there is no valid thing to put in the interrupts property
here when the interrupt controller is not fsl,mpic, so this doesn't
work.
[Wang Dongsheng] Fine, I will remove this document of Open-PIC global timer.
We only support mpic timer. Driver will be compatible with OPEN-PIC
specification. Let someone who cares about ordinary OpenPIC drivers add
support?
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH v2 2/2] powerpc/mpic: add global timer support
-Original Message-
From: Wood Scott-B07421
Sent: Saturday, August 11, 2012 4:38 AM
To: Wang Dongsheng-B40534
Cc: b...@kernel.crashing.org; pau...@samba.org; linuxppc-
d...@lists.ozlabs.org; Gala Kumar-B11780; Li Yang-R58472
Subject: Re: [PATCH v2 2/2] powerpc/mpic: add global timer support
On 08/10/2012 12:54 AM, dongsheng.w...@freescale.com wrote:
+static int group_get_freq(struct group_priv *priv) {
+ if (priv-flags FSL_GLOBAL_TIMER) {
+ ccbfreq = fsl_get_sys_freq();
+ priv-timerfreq = ccbfreq;
+ } else {
+ priv-timerfreq = in_be32(priv-group_tfrr);
+ }
FSL MPICs have TFRR too. I'm not sure that the lack of fsl,mpic is a
good indication that TFRR is being set (e.g. we have old device trees for
FSL chips with U-Boot that are labelled as ordinary openpics).
[Wang Dongsheng] yes, we have. But we do not used it. The TFRR register value
is zero.
+
+ if (priv-timerfreq = 0)
+ return -EINVAL;
+
+ return 0;
+}
timerfreq is unsigned. It can never be 0.
[Wang Dongsheng] Yeah. Thanks.
+
+static int group_init_regmap(struct device_node *np, struct
+group_priv *priv) {
+ priv-group_tfrr = of_iomap(np, 0);
+ if (!priv-group_tfrr) {
+ pr_err(%s: cannot ioremap tfrr address.\n,
+ np-full_name);
+ return -EINVAL;
+ }
+
+ priv-regs = of_iomap(np, 1);
+ if (!priv-regs) {
+ pr_err(%s: cannot ioremap timer register address.\n,
+ np-full_name);
+ return -EINVAL;
+ }
+
+ if (!(priv-flags FSL_GLOBAL_TIMER))
+ return 0;
+
+ priv-group_tcr = of_iomap(np, 2);
+ if (!priv-group_tcr) {
+ pr_err(%s: cannot ioremap tcr address.\n, np-full_name);
+ return -EINVAL;
+ }
This is not compatible with existing mpic timer nodes.
[Wang Dongsheng] Yeah, next patch to support that.
+ p = of_get_property(np, available-ranges, len);
+ if (p len % (2 * sizeof(u32)) != 0) {
+ pr_err(%s: malformed fsl,available-ranges property.\n,
+ np-full_name);
+ return -EINVAL;
+ }
You need to support fsl,available-ranges since that's in an accepted
binding and people could have partitioned setups already using it.
[Wang Dongsheng] FSL chip or OPEN-PIC specification(Only a group)
in each group only four timer. This is unified. So i use a generic name.
I think there is not compatible with existing mpic timer nodes.
p = of_get_property(np, available-ranges, len);
if (!p)
p = of_get_property(np, fsl,available-ranges, len);
if (p len % (2 * sizeof(u32)) != 0) {
pr_err(%s: malformed fsl,available-ranges property.\n,
np-full_name);
return -EINVAL;
}
You also have a mismatch between the property you check and the error
string.
[Wang Dongsheng] Yeah. :-(.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH v2 2/2] powerpc/mpic: add global timer support
-Original Message- From: Tabi Timur-B04825 Sent: Saturday, August 11, 2012 9:10 PM To: Wang Dongsheng-B40534 Cc: b...@kernel.crashing.org; pau...@samba.org; Wood Scott-B07421; Gala Kumar-B11780; linuxppc-dev@lists.ozlabs.org Subject: Re: [PATCH v2 2/2] powerpc/mpic: add global timer support On Fri, Aug 10, 2012 at 12:54 AM, dongsheng.w...@freescale.com wrote: From: Wang Dongsheng dongsheng.w...@freescale.com +EXPORT_SYMBOL_GPL(mpic_request_timer); Make these EXPORT_SYMBOL. No need for a GPL restriction. [Wang Dongsheng] Why? -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH v2 2/2] powerpc/mpic: add global timer support
-Original Message- From: Linuxppc-dev [mailto:linuxppc-dev- bounces+b40534=freescale@lists.ozlabs.org] On Behalf Of Wang Dongsheng-B40534 Sent: Monday, August 13, 2012 2:21 PM To: Tabi Timur-B04825 Cc: Gala Kumar-B11780; pau...@samba.org; linuxppc-dev@lists.ozlabs.org; Wood Scott-B07421 Subject: RE: [PATCH v2 2/2] powerpc/mpic: add global timer support -Original Message- From: Tabi Timur-B04825 Sent: Saturday, August 11, 2012 9:10 PM To: Wang Dongsheng-B40534 Cc: b...@kernel.crashing.org; pau...@samba.org; Wood Scott-B07421; Gala Kumar-B11780; linuxppc-dev@lists.ozlabs.org Subject: Re: [PATCH v2 2/2] powerpc/mpic: add global timer support On Fri, Aug 10, 2012 at 12:54 AM, dongsheng.w...@freescale.com wrote: From: Wang Dongsheng dongsheng.w...@freescale.com +EXPORT_SYMBOL_GPL(mpic_request_timer); Make these EXPORT_SYMBOL. No need for a GPL restriction. [Wang Dongsheng] Why? [Wang Dongsheng] Sorry, I just see the mail. Thanks. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH v2 2/2] powerpc/mpic: add global timer support
-Original Message-
From: Wood Scott-B07421
Sent: Tuesday, August 14, 2012 1:37 AM
To: Wang Dongsheng-B40534
Cc: Wood Scott-B07421; b...@kernel.crashing.org; pau...@samba.org;
linuxppc-dev@lists.ozlabs.org; Gala Kumar-B11780; Li Yang-R58472
Subject: Re: [PATCH v2 2/2] powerpc/mpic: add global timer support
On 08/13/2012 01:18 AM, Wang Dongsheng-B40534 wrote:
+ p = of_get_property(np, available-ranges, len);
+ if (p len % (2 * sizeof(u32)) != 0) {
+ pr_err(%s: malformed fsl,available-ranges property.\n,
+ np-full_name);
+ return -EINVAL;
+ }
You need to support fsl,available-ranges since that's in an accepted
binding and people could have partitioned setups already using it.
[Wang Dongsheng] FSL chip or OPEN-PIC specification(Only a group) in
each group only four timer. This is unified. So i use a generic name.
I think there is not compatible with existing mpic timer nodes.
We need to be compatible with existing trees, so you'd need to check for
both -- but I think any further discussion of the details is premature
until we decide whether this is worthwhile to begin with (both the
support of non-FSL timers, and the creation of a new device tree binding
which will not be implemented by many of the machines that have non-FSL
openpic because they run real Open Firmware).
[Wang Dongsheng]
p = of_get_property(np, available-ranges, len);
if (!p)
p = of_get_property(np, fsl,available-ranges, len);
this code be compatible with existing trees.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH v2 2/2] powerpc/mpic: add global timer support
-Original Message-
From: Wood Scott-B07421
Sent: Tuesday, August 14, 2012 10:05 AM
To: Wang Dongsheng-B40534
Cc: Wood Scott-B07421; b...@kernel.crashing.org; pau...@samba.org;
linuxppc-dev@lists.ozlabs.org; Gala Kumar-B11780; Li Yang-R58472
Subject: Re: [PATCH v2 2/2] powerpc/mpic: add global timer support
On 08/13/2012 09:00 PM, Wang Dongsheng-B40534 wrote:
-Original Message-
From: Wood Scott-B07421
Sent: Tuesday, August 14, 2012 1:37 AM
To: Wang Dongsheng-B40534
Cc: Wood Scott-B07421; b...@kernel.crashing.org; pau...@samba.org;
linuxppc-dev@lists.ozlabs.org; Gala Kumar-B11780; Li Yang-R58472
Subject: Re: [PATCH v2 2/2] powerpc/mpic: add global timer support
On 08/13/2012 01:18 AM, Wang Dongsheng-B40534 wrote:
+ p = of_get_property(np, available-ranges, len);
+ if (p len % (2 * sizeof(u32)) != 0) {
+ pr_err(%s: malformed fsl,available-ranges property.\n,
+ np-full_name);
+ return -EINVAL;
+ }
You need to support fsl,available-ranges since that's in an
accepted binding and people could have partitioned setups already
using it.
[Wang Dongsheng] FSL chip or OPEN-PIC specification(Only a group) in
each group only four timer. This is unified. So i use a generic name.
I think there is not compatible with existing mpic timer nodes.
We need to be compatible with existing trees, so you'd need to check
for both -- but I think any further discussion of the details is
premature until we decide whether this is worthwhile to begin with
(both the support of non-FSL timers, and the creation of a new device
tree binding which will not be implemented by many of the machines
that have non-FSL openpic because they run real Open Firmware).
[Wang Dongsheng]
p = of_get_property(np, available-ranges, len);
if (!p)
p = of_get_property(np, fsl,available-ranges, len);
this code be compatible with existing trees.
Yes, that's what I meant by checking both.
I still think we need to discuss why we're doing this first. What
specific machines are going to have these new openpic timer nodes?
[Wang Dongsheng] It's support to power management awakening. At present,
the power management more and more important. This way is important to wake
up machine. At least need support power management of machine still needs
such a driver.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH v2 2/2] powerpc/mpic: add global timer support
-Original Message-
From: Wood Scott-B07421
Sent: Tuesday, August 14, 2012 10:19 AM
To: Wang Dongsheng-B40534
Cc: Wood Scott-B07421; b...@kernel.crashing.org; pau...@samba.org;
linuxppc-dev@lists.ozlabs.org; Gala Kumar-B11780; Li Yang-R58472
Subject: Re: [PATCH v2 2/2] powerpc/mpic: add global timer support
On 08/13/2012 09:15 PM, Wang Dongsheng-B40534 wrote:
-Original Message-
From: Wood Scott-B07421
Sent: Tuesday, August 14, 2012 10:05 AM
To: Wang Dongsheng-B40534
Cc: Wood Scott-B07421; b...@kernel.crashing.org; pau...@samba.org;
linuxppc-dev@lists.ozlabs.org; Gala Kumar-B11780; Li Yang-R58472
Subject: Re: [PATCH v2 2/2] powerpc/mpic: add global timer support
On 08/13/2012 09:00 PM, Wang Dongsheng-B40534 wrote:
-Original Message-
From: Wood Scott-B07421
Sent: Tuesday, August 14, 2012 1:37 AM
To: Wang Dongsheng-B40534
Cc: Wood Scott-B07421; b...@kernel.crashing.org; pau...@samba.org;
linuxppc-dev@lists.ozlabs.org; Gala Kumar-B11780; Li Yang-R58472
Subject: Re: [PATCH v2 2/2] powerpc/mpic: add global timer support
On 08/13/2012 01:18 AM, Wang Dongsheng-B40534 wrote:
+ p = of_get_property(np, available-ranges, len);
+ if (p len % (2 * sizeof(u32)) != 0) {
+ pr_err(%s: malformed fsl,available-ranges property.\n,
+ np-full_name);
+ return -EINVAL;
+ }
You need to support fsl,available-ranges since that's in an
accepted binding and people could have partitioned setups already
using it.
[Wang Dongsheng] FSL chip or OPEN-PIC specification(Only a group)
in each group only four timer. This is unified. So i use a generic
name.
I think there is not compatible with existing mpic timer nodes.
We need to be compatible with existing trees, so you'd need to
check for both -- but I think any further discussion of the details
is premature until we decide whether this is worthwhile to begin
with (both the support of non-FSL timers, and the creation of a new
device tree binding which will not be implemented by many of the
machines that have non-FSL openpic because they run real Open
Firmware).
[Wang Dongsheng]
p = of_get_property(np, available-ranges, len);
if (!p)
p = of_get_property(np, fsl,available-ranges, len);
this code be compatible with existing trees.
Yes, that's what I meant by checking both.
I still think we need to discuss why we're doing this first. What
specific machines are going to have these new openpic timer nodes?
[Wang Dongsheng] It's support to power management awakening. At
present, the power management more and more important. This way is
important to wake up machine. At least need support power management
of machine still needs such a driver.
I mean specifically for the non-Freescale openpic nodes.
[Wang Dongsheng] I think non-Freescale chips can also use this function
to wake up the machine. And There is also an important feature, It can
periodically generate an interrupt. For example, the network periodically
check the hardware device(link status).
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH v2 1/2] powerpc/mpic: Add Open-PIC global timer document
-Original Message-
From: Wood Scott-B07421
Sent: Tuesday, August 14, 2012 1:40 AM
To: Wang Dongsheng-B40534
Cc: Wood Scott-B07421; b...@kernel.crashing.org; pau...@samba.org;
linuxppc-dev@lists.ozlabs.org; devicetree-disc...@lists.ozlabs.org; Gala
Kumar-B11780; Li Yang-R58472
Subject: Re: [PATCH v2 1/2] powerpc/mpic: Add Open-PIC global timer
document
On 08/13/2012 12:40 AM, Wang Dongsheng-B40534 wrote:
diff --git a/Documentation/devicetree/bindings/open-pic.txt
b/Documentation/devicetree/bindings/open-pic.txt
index 909a902..045c2e9 100644
--- a/Documentation/devicetree/bindings/open-pic.txt
+++ b/Documentation/devicetree/bindings/open-pic.txt
@@ -92,6 +92,52 @@ Example 2:
* References
+* Open PIC global timers
+
+Required properties:
+- compatible: open-pic,global-timer
open-pic isn't a vendor (or software project that acts like a
pseudo-vendor) -- I'd go with open-pic-global-timer.
[Wang Dongsheng] yes, open-pic-global-timer looks good.
+- reg : Contains two regions. The first is the timer frequency
+reporting
+ register for the group. The second is the main timer register
+bank
+ (GTCCR, GTBCR, GTVPR, GTDR).
Why not just put clock-frequency in the node, instead of describing
TFRR?
I don't think U-Boot currently sets TFRR.
[Wang Dongsheng] If during startup U-Boot do not set TFRR that is
unreasonable.
Too bad, it's what happens and we're not going to force users to update
U-Boot because of this.
+Example 2:
+
+ timer: timer@010f0 {
+ compatible = open-pic,global-timer;
+ device_type = open-pic;
+ reg = 0x010f0 4 0x01100 0x100;
+ interrupts = 0 0 3 0
+ 1 0 3 0
+ 2 0 3 0
+ 3 0 3 0;
+ };
4-cell interrupt specifiers are specific to Freescale MPICs. This
means there's no way to describe the timer interrupt on a non-
Freescale openpic.
Again, I suggest we not bother with this in the absence of an actual
need to support the timer on non-Freescale openpic in partitioned
scenarios.
The existing openpic node is sufficient to describe the
hardware in the absence of partitioning. We could have an
openpic-no-timer property to indicate that we're describing it
separately, so that the absence of a timer node isn't ambiguous as to
whether it's an old tree or a partitioned scenario. An fsl,mpic
compatible would imply openpic-no-timer.
Note that I believe many of the non-Freescale openpic nodes are going
to be found on systems with real Open Firmware, so we can't go
changing the device tree for them.
[Wang Dongsheng] In the Open-PIC specification, there are four timer.
interrupts = 0 0 3 0
1 0 3 0
2 0 3 0
3 0 3 0;
The interrupts just let user know there are four timers. Usage based
interrupts
binding to change dts.
I can't understand the above or how it's a response to what I wrote.
[Wang Dongsheng] I mean this just to tell how many timers to support in Open-PIC
specification. If someone needs to write interrupts into dts, this must comply
with the specification of the interrupt to write. this is based on the pic
driver
should be changed in different platforms.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH v2 1/2] powerpc/mpic: Add Open-PIC global timer document
a/Documentation/devicetree/bindings/powerpc/fsl/mpic-timer.txt b/Documentation/devicetree/bindings/powerpc/fsl/mpic-timer.txt index df41958..5aafca0 100644 --- a/Documentation/devicetree/bindings/powerpc/fsl/mpic-timer.txt +++ b/Documentation/devicetree/bindings/powerpc/fsl/mpic-timer.txt @@ -1,13 +1,14 @@ * Freescale MPIC timers Required properties: -- compatible: fsl,mpic-global-timer +- compatible: fsl,global-timer Why are renaming?.. also use of fsl,global-timer is to generic of a name for the this. [Wang Dongsheng] fsl,global-timer is generic of a name. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH v2 1/2] powerpc/mpic: Add Open-PIC global timer document
diff --git a/Documentation/devicetree/bindings/open-pic.txt
b/Documentation/devicetree/bindings/open-pic.txt
index 909a902..045c2e9 100644
--- a/Documentation/devicetree/bindings/open-pic.txt
+++ b/Documentation/devicetree/bindings/open-pic.txt
@@ -92,6 +92,52 @@ Example 2:
* References
+* Open PIC global timers
+
+Required properties:
+- compatible: open-pic,global-timer
open-pic isn't a vendor (or software project that acts like a
pseudo-vendor) -- I'd go with open-pic-global-timer.
[Wang Dongsheng] yes, open-pic-global-timer looks good.
+- reg : Contains two regions. The first is the timer frequency
+reporting
+ register for the group. The second is the main timer register bank
+ (GTCCR, GTBCR, GTVPR, GTDR).
Why not just put clock-frequency in the node, instead of describing TFRR?
I don't think U-Boot currently sets TFRR.
[Wang Dongsheng] If during startup U-Boot do not set TFRR that is unreasonable.
In Open-PIC this is not allowed. We used is the CCB frequency in FSL chip.
We do not need to care about the value of this register. But we must support
TFRR.
+ reg = 0x010f0 4 0x01100 0x100;
+
+ /* Another AMP partition is using timer */
+ available-ranges = 2 2;
+
+ interrupts = 2 0 3 0
+ 3 0 3 0;
+ };
+
+Example 2:
+
+ timer: timer@010f0 {
+ compatible = open-pic,global-timer;
+ device_type = open-pic;
+ reg = 0x010f0 4 0x01100 0x100;
+ interrupts = 0 0 3 0
+ 1 0 3 0
+ 2 0 3 0
+ 3 0 3 0;
+ };
4-cell interrupt specifiers are specific to Freescale MPICs. This means
there's no way to describe the timer interrupt on a non-Freescale openpic.
Again, I suggest we not bother with this in the absence of an actual need
to support the timer on non-Freescale openpic in partitioned scenarios.
The existing openpic node is sufficient to describe the
hardware in the absence of partitioning. We could have an
openpic-no-timer property to indicate that we're describing it
separately, so that the absence of a timer node isn't ambiguous as to
whether it's an old tree or a partitioned scenario. An fsl,mpic
compatible would imply openpic-no-timer.
Note that I believe many of the non-Freescale openpic nodes are going to
be found on systems with real Open Firmware, so we can't go changing the
device tree for them.
[Wang Dongsheng] In the Open-PIC specification, there are four timer.
interrupts = 0 0 3 0
1 0 3 0
2 0 3 0
3 0 3 0;
The interrupts just let user know there are four timers. Usage based
interrupts
binding to change dts.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH v2 2/2] powerpc/mpic: add global timer support
-Original Message-
From: Wood Scott-B07421
Sent: Saturday, August 11, 2012 3:40 AM
To: Wang Dongsheng-B40534
Cc: b...@kernel.crashing.org; pau...@samba.org; linuxppc-
d...@lists.ozlabs.org; Gala Kumar-B11780; Li Yang-R58472
Subject: Re: [PATCH v2 2/2] powerpc/mpic: add global timer support
On 08/10/2012 12:54 AM, dongsheng.w...@freescale.com wrote:
+static const struct of_device_id mpic_timer_ids[] = {
+ { .compatible = open-pic,global-timer, },
+ { .compatible = fsl,global-timer, },
+ {},
+};
+
+static int __init mpic_timer_init(void) {
+ struct device_node *np = NULL;
+
+ for_each_node_by_type(np, open-pic)
+ if (of_match_node(mpic_timer_ids, np))
+ group_init(np);
+
+ if (list_empty(group_list))
+ return -ENODEV;
+
+ return 0;
+}
+arch_initcall(mpic_timer_init);
Oh, and don't probe by device_type.
[Wang Dongsheng] fine. for_each_node_by_name.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
