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_BIT 63
+
+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
[PATCH V2] powerpc: Fix 64K page size support for PPC44x
PPC44x supports page sizes other than 4K however when 64K page sizes are selected compilation fails. This is due to a change in the definition of pgtable_t introduced by the following patch: commit 5c1f6ee9a31cbdac90bbb8ae1ba4475031ac74b4 Author: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com powerpc: Reduce PTE table memory wastage The above patch only implements the new layout for PPC64 so it doesn't compile for PPC32 with a 64K page size. Ideally we should implement the same layout for PPC32 however for the meantime this patch reverts the definition of pgtable_t for PPC32. Signed-off-by: Alistair Popple alist...@popple.id.au --- arch/powerpc/include/asm/page.h |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/powerpc/include/asm/page.h b/arch/powerpc/include/asm/page.h index b9f4262..7dde512 100644 --- a/arch/powerpc/include/asm/page.h +++ b/arch/powerpc/include/asm/page.h @@ -403,7 +403,7 @@ void arch_free_page(struct page *page, int order); struct vm_area_struct; -#ifdef CONFIG_PPC_64K_PAGES +#if defined(CONFIG_PPC_64K_PAGES) defined(CONFIG_PPC64) typedef pte_t *pgtable_t; #else typedef struct page *pgtable_t; -- 1.7.10.4 ___ 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: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: 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_BIT 63
+
+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
[PATCH] powerpc/p1010rdb:update mtd of nand to adapt to both old and new p1010rdb
P1010rdb-pa and p1010rdb-pb have different mtd of nand.
So update dts to adapt to both p1010rdb-pa and p1010rdb-pb.
Signed-off-by: Zhao Qiang b45...@freescale.com
---
arch/powerpc/boot/dts/p1010rdb-pa.dts | 40 +++
arch/powerpc/boot/dts/p1010rdb-pa_36b.dts | 40 +++
arch/powerpc/boot/dts/p1010rdb-pb.dts | 34 ++
arch/powerpc/boot/dts/p1010rdb-pb_36b.dts | 34 ++
arch/powerpc/boot/dts/p1010rdb.dtsi | 40 +--
5 files changed, 149 insertions(+), 39 deletions(-)
diff --git a/arch/powerpc/boot/dts/p1010rdb-pa.dts
b/arch/powerpc/boot/dts/p1010rdb-pa.dts
index f210ba5..76f252b 100644
--- a/arch/powerpc/boot/dts/p1010rdb-pa.dts
+++ b/arch/powerpc/boot/dts/p1010rdb-pa.dts
@@ -20,6 +20,46 @@
/include/ p1010rdb.dtsi
+ifc_nand {
+ partition@0 {
+ /* This location must not be altered */
+ /* 1MB for u-boot Bootloader Image */
+ reg = 0x0 0x0010;
+ label = NAND U-Boot Image;
+ read-only;
+ };
+
+ partition@10 {
+ /* 1MB for DTB Image */
+ reg = 0x0010 0x0010;
+ label = NAND DTB Image;
+ };
+
+ partition@20 {
+ /* 4MB for Linux Kernel Image */
+ reg = 0x0020 0x0040;
+ label = NAND Linux Kernel Image;
+ };
+
+ partition@60 {
+ /* 4MB for Compressed Root file System Image */
+ reg = 0x0060 0x0040;
+ label = NAND Compressed RFS Image;
+ };
+
+ partition@a0 {
+ /* 15MB for JFFS2 based Root file System */
+ reg = 0x00a0 0x00f0;
+ label = NAND JFFS2 Root File System;
+ };
+
+ partition@190 {
+ /* 7MB for User Area */
+ reg = 0x0190 0x0070;
+ label = NAND User area;
+ };
+};
+
phy0 {
interrupts = 3 1 0 0;
};
diff --git a/arch/powerpc/boot/dts/p1010rdb-pa_36b.dts
b/arch/powerpc/boot/dts/p1010rdb-pa_36b.dts
index 9740b0c..2961766 100644
--- a/arch/powerpc/boot/dts/p1010rdb-pa_36b.dts
+++ b/arch/powerpc/boot/dts/p1010rdb-pa_36b.dts
@@ -43,6 +43,46 @@
/include/ p1010rdb.dtsi
+ifc_nand {
+ partition@0 {
+ /* This location must not be altered */
+ /* 1MB for u-boot Bootloader Image */
+ reg = 0x0 0x0010;
+ label = NAND U-Boot Image;
+ read-only;
+ };
+
+ partition@10 {
+ /* 1MB for DTB Image */
+ reg = 0x0010 0x0010;
+ label = NAND DTB Image;
+ };
+
+ partition@20 {
+ /* 4MB for Linux Kernel Image */
+ reg = 0x0020 0x0040;
+ label = NAND Linux Kernel Image;
+ };
+
+ partition@60 {
+ /* 4MB for Compressed Root file System Image */
+ reg = 0x0060 0x0040;
+ label = NAND Compressed RFS Image;
+ };
+
+ partition@a0 {
+ /* 15MB for JFFS2 based Root file System */
+ reg = 0x00a0 0x00f0;
+ label = NAND JFFS2 Root File System;
+ };
+
+ partition@190 {
+ /* 7MB for User Area */
+ reg = 0x0190 0x0070;
+ label = NAND User area;
+ };
+};
+
phy0 {
interrupts = 3 1 0 0;
};
diff --git a/arch/powerpc/boot/dts/p1010rdb-pb.dts
b/arch/powerpc/boot/dts/p1010rdb-pb.dts
index 6eeb7d3..6187e9c 100644
--- a/arch/powerpc/boot/dts/p1010rdb-pb.dts
+++ b/arch/powerpc/boot/dts/p1010rdb-pb.dts
@@ -20,6 +20,40 @@
/include/ p1010rdb.dtsi
+ifc_nand {
+ partition@0 {
+ /* This location must not be altered */
+ /* 2MB for u-boot Image and environment */
+ reg = 0x0 0x0020;
+ label = NAND U-Boot Image and env;
+ read-only;
+ };
+
+ partition@20 {
+ /* 1MB for DTB Image */
+ reg = 0x0020 0x0010;
+ label = NAND DTB Image;
+ };
+
+ partition@30 {
+ /* 5MB for Linux Kernel Image */
+ reg = 0x0030 0x0050;
+ label = NAND Linux Kernel Image;
+ };
+
+ partition@80 {
+ /* 56MB for Compressed Root file System Image */
+ reg = 0x0080 0x0380;
+ label = NAND ROOTFS;
+ };
+
+ partition@400 {
+ /* 1984MB for User Area */
+ reg = 0x0400 0x7c00;
+ label = NAND User area;
+ };
+};
+
phy0 {
interrupts = 0 1 0 0;
};
diff --git a/arch/powerpc/boot/dts/p1010rdb-pb_36b.dts
b/arch/powerpc/boot/dts/p1010rdb-pb_36b.dts
index
Re: [PATCH 1/2] tty/hvc_console: Add DTR/RTS callback to handle HUPCL control
On Wed, Oct 16, 2013 at 06:21:12PM -0500, Benjamin Herrenschmidt wrote: On Wed, 2013-10-16 at 11:04 +0200, Hendrik Brueckner wrote: Indeed, two callbacks change the DTR line. The main difference is that tiocmget/tiocmset can be called from user space by ioctl. That's not the case for the dtr_cts callback. Also, tiocmget/tiocmset provide more flags that can be changed (ST, SR, CTS, CD, RNG, RI, ...) Assume we would like to unify them have a single callback to change DTR, then we have to take care of these differences. So the question to you now is whether you plan for a) other modem flags to be changed and b) if changing the DTR line (or other control flags) through an ioctl? Depending on your results, I could work on sth that helps us both and reduces the callbacks. Can we not just have the users of dtr_cts just call the backend's tiocmset ? That's possible. The only concern is that the tiocmset() callback could be triggered from within the hvc_console() layer as well as from user space via ioctl. For the hvc_iucv driver, I do not want to introduce this ioctl. One option would be to add parameter to the hvc_callbacks that indicate the origin so that a backend could filter. If they need to filter or clamp bits, we could handle all that in hvc_console by caching the user intended value and passing a cooked value down to the backend.. Sure the hvc_console layer could do as much as possible. None of that is urgent or anything, it's just odd and would be nice to cleanup. Thanks and kind regards, Hendrik ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCHv1 0/8] ALSA: Add SAI driver and enable SGT15000 codec.
Hi, Xiubo Li li.xi...@freescale.com wrote: The subject has a wrong name for the codec SGT1... instead of SGTL..., which will make it difficult to search for this thread in mail archives or in commit messages once this patches should be applied! Lothar Waßmann -- ___ Ka-Ro electronics GmbH | Pascalstraße 22 | D - 52076 Aachen Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10 Geschäftsführer: Matthias Kaussen Handelsregistereintrag: Amtsgericht Aachen, HRB 4996 www.karo-electronics.de | i...@karo-electronics.de ___ ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/vio: Fix modalias_show return values
On 10/16/2013 11:53 PM, Ben Hutchings wrote:
Commit e82b89a6f19bae73fb064d1b3dd91fcefbb478f4 introduces a trivial
local denial of service.
--- a/arch/powerpc/kernel/vio.c
+++ b/arch/powerpc/kernel/vio.c
@@ -1351,11 +1351,15 @@ static ssize_t modalias_show(struct devi
const char *cp;
dn = dev-of_node;
-if (!dn)
-return -ENODEV;
+if (!dn) {
+strcat(buf, \n);
Every read from the same sysfs file handle uses the same buffer, which
gets zero-initialised just once. So if I open the file, read it and
seek back to 0 repeatedly, I can make modalias_show() write arbitrary
numbers of newlines into *and beyond* that page-sized buffer.
Obviously strcat() should be strcpy().
D'oh! Of course -- I wasn't thinking clearly about that. I'll send out a new
patch.
P.
Ben.
+return strlen(buf);
+}
cp = of_get_property(dn, compatible, NULL);
-if (!cp)
-return -ENODEV;
+if (!cp) {
+strcat(buf, \n);
+return strlen(buf);
+}
return sprintf(buf, vio:T%sS%s\n, vio_dev-type, cp);
}
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] [PATCH] powerpc/vio: use strcpy in modalias_show
Commit e82b89a6f19bae73fb064d1b3dd91fcefbb478f4 used strcat instead of
strcpy which can result in an overflow of newlines on the buffer.
Signed-off-by: Prarit Bhargava
Cc: b...@kernel.crashing.org
Cc: b...@decadent.org.uk
Cc: sta...@vger.kernel.org
---
arch/powerpc/kernel/vio.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/vio.c b/arch/powerpc/kernel/vio.c
index d38cc08..cb92d82 100644
--- a/arch/powerpc/kernel/vio.c
+++ b/arch/powerpc/kernel/vio.c
@@ -1531,12 +1531,12 @@ static ssize_t modalias_show(struct device *dev, struct
device_attribute *attr,
dn = dev-of_node;
if (!dn) {
- strcat(buf, \n);
+ strcpy(buf, \n);
return strlen(buf);
}
cp = of_get_property(dn, compatible, NULL);
if (!cp) {
- strcat(buf, \n);
+ strcpy(buf, \n);
return strlen(buf);
}
--
1.7.9.3
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCHv1 1/8] ALSA: Add SAI SoC Digital Audio Interface driver.
Xiubo Li wrote: + res = platform_get_resource(pdev, IORESOURCE_MEM, 0); + sai-base = devm_ioremap_resource(pdev-dev, res); Why not use of_iomap()? ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
powerpc: Fix little endian issue in OF PCI scan
This issue was causing the QEMU emulated USB device to fail dring
PCI probe.
Signed-off-by: Anton Blanchard an...@samba.org
---
diff --git a/arch/powerpc/kernel/pci_of_scan.c
b/arch/powerpc/kernel/pci_of_scan.c
index 4368ec6..ac0b034 100644
--- a/arch/powerpc/kernel/pci_of_scan.c
+++ b/arch/powerpc/kernel/pci_of_scan.c
@@ -302,7 +302,7 @@ static struct pci_dev *of_scan_pci_dev(struct pci_bus *bus,
struct device_node *dn)
{
struct pci_dev *dev = NULL;
- const u32 *reg;
+ const __be32 *reg;
int reglen, devfn;
pr_debug( * %s\n, dn-full_name);
@@ -312,7 +312,7 @@ static struct pci_dev *of_scan_pci_dev(struct pci_bus *bus,
reg = of_get_property(dn, reg, reglen);
if (reg == NULL || reglen 20)
return NULL;
- devfn = (reg[0] 8) 0xff;
+ devfn = (of_read_number(reg, 1) 8) 0xff;
/* Check if the PCI device is already there */
dev = pci_get_slot(bus, devfn);
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/pseries: Fix endian issues in pseries iommu code
Signed-off-by: Anton Blanchard an...@samba.org
---
diff --git a/arch/powerpc/platforms/pseries/iommu.c
b/arch/powerpc/platforms/pseries/iommu.c
index 0307901..f253361 100644
--- a/arch/powerpc/platforms/pseries/iommu.c
+++ b/arch/powerpc/platforms/pseries/iommu.c
@@ -52,7 +52,7 @@
static void tce_invalidate_pSeries_sw(struct iommu_table *tbl,
- u64 *startp, u64 *endp)
+ __be64 *startp, __be64 *endp)
{
u64 __iomem *invalidate = (u64 __iomem *)tbl-it_index;
unsigned long start, end, inc;
@@ -86,7 +86,7 @@ static int tce_build_pSeries(struct iommu_table *tbl, long
index,
struct dma_attrs *attrs)
{
u64 proto_tce;
- u64 *tcep, *tces;
+ __be64 *tcep, *tces;
u64 rpn;
proto_tce = TCE_PCI_READ; // Read allowed
@@ -94,12 +94,12 @@ static int tce_build_pSeries(struct iommu_table *tbl, long
index,
if (direction != DMA_TO_DEVICE)
proto_tce |= TCE_PCI_WRITE;
- tces = tcep = ((u64 *)tbl-it_base) + index;
+ tces = tcep = ((__be64 *)tbl-it_base) + index;
while (npages--) {
/* can't move this out since we might cross MEMBLOCK boundary */
rpn = __pa(uaddr) TCE_SHIFT;
- *tcep = proto_tce | (rpn TCE_RPN_MASK) TCE_RPN_SHIFT;
+ *tcep = cpu_to_be64(proto_tce | (rpn TCE_RPN_MASK)
TCE_RPN_SHIFT);
uaddr += TCE_PAGE_SIZE;
tcep++;
@@ -113,9 +113,9 @@ static int tce_build_pSeries(struct iommu_table *tbl, long
index,
static void tce_free_pSeries(struct iommu_table *tbl, long index, long npages)
{
- u64 *tcep, *tces;
+ __be64 *tcep, *tces;
- tces = tcep = ((u64 *)tbl-it_base) + index;
+ tces = tcep = ((__be64 *)tbl-it_base) + index;
while (npages--)
*(tcep++) = 0;
@@ -126,11 +126,11 @@ static void tce_free_pSeries(struct iommu_table *tbl,
long index, long npages)
static unsigned long tce_get_pseries(struct iommu_table *tbl, long index)
{
- u64 *tcep;
+ __be64 *tcep;
- tcep = ((u64 *)tbl-it_base) + index;
+ tcep = ((__be64 *)tbl-it_base) + index;
- return *tcep;
+ return be64_to_cpu(*tcep);
}
static void tce_free_pSeriesLP(struct iommu_table*, long, long);
@@ -177,7 +177,7 @@ static int tce_build_pSeriesLP(struct iommu_table *tbl,
long tcenum,
return ret;
}
-static DEFINE_PER_CPU(u64 *, tce_page);
+static DEFINE_PER_CPU(__be64 *, tce_page);
static int tce_buildmulti_pSeriesLP(struct iommu_table *tbl, long tcenum,
long npages, unsigned long uaddr,
@@ -186,7 +186,7 @@ static int tce_buildmulti_pSeriesLP(struct iommu_table
*tbl, long tcenum,
{
u64 rc = 0;
u64 proto_tce;
- u64 *tcep;
+ __be64 *tcep;
u64 rpn;
long l, limit;
long tcenum_start = tcenum, npages_start = npages;
@@ -206,7 +206,7 @@ static int tce_buildmulti_pSeriesLP(struct iommu_table
*tbl, long tcenum,
* from iommu_alloc{,_sg}()
*/
if (!tcep) {
- tcep = (u64 *)__get_free_page(GFP_ATOMIC);
+ tcep = (__be64 *)__get_free_page(GFP_ATOMIC);
/* If allocation fails, fall back to the loop implementation */
if (!tcep) {
local_irq_restore(flags);
@@ -230,7 +230,7 @@ static int tce_buildmulti_pSeriesLP(struct iommu_table
*tbl, long tcenum,
limit = min_t(long, npages, 4096/TCE_ENTRY_SIZE);
for (l = 0; l limit; l++) {
- tcep[l] = proto_tce | (rpn TCE_RPN_MASK)
TCE_RPN_SHIFT;
+ tcep[l] = cpu_to_be64(proto_tce | (rpn TCE_RPN_MASK)
TCE_RPN_SHIFT);
rpn++;
}
@@ -329,16 +329,16 @@ struct direct_window {
/* Dynamic DMA Window support */
struct ddw_query_response {
- u32 windows_available;
- u32 largest_available_block;
- u32 page_size;
- u32 migration_capable;
+ __be32 windows_available;
+ __be32 largest_available_block;
+ __be32 page_size;
+ __be32 migration_capable;
};
struct ddw_create_response {
- u32 liobn;
- u32 addr_hi;
- u32 addr_lo;
+ __be32 liobn;
+ __be32 addr_hi;
+ __be32 addr_lo;
};
static LIST_HEAD(direct_window_list);
@@ -392,7 +392,8 @@ static int tce_setrange_multi_pSeriesLP(unsigned long
start_pfn,
unsigned long num_pfn, const void *arg)
{
const struct dynamic_dma_window_prop *maprange = arg;
- u64 *tcep, tce_size, num_tce, dma_offset, next, proto_tce, liobn;
+ u64 tce_size, num_tce, dma_offset, next, proto_tce, liobn;
+ __be64 *tcep;
u32 tce_shift;
u64 rc = 0;
long l, limit;
@@ -401,7 +402,7 @@ static int
RE: [PATCH] [PATCH] powerpc/vio: use strcpy in modalias_show
Commit e82b89a6f19bae73fb064d1b3dd91fcefbb478f4 used strcat instead of
strcpy which can result in an overflow of newlines on the buffer.
...
--- a/arch/powerpc/kernel/vio.c
+++ b/arch/powerpc/kernel/vio.c
@@ -1531,12 +1531,12 @@ static ssize_t modalias_show(struct device *dev,
struct device_attribute
*attr,
dn = dev-of_node;
if (!dn) {
- strcat(buf, \n);
+ strcpy(buf, \n);
return strlen(buf);
}
cp = of_get_property(dn, compatible, NULL);
if (!cp) {
- strcat(buf, \n);
+ strcpy(buf, \n);
return strlen(buf);
}
Why not just:
buf[0] = '\n';
buf[1] = 0;
return 1;
The assignment to buf[1] might not even be needed.
David
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] [PATCH] powerpc/vio: use strcpy in modalias_show
On 10/17/2013 08:22 AM, David Laight wrote:
Commit e82b89a6f19bae73fb064d1b3dd91fcefbb478f4 used strcat instead of
strcpy which can result in an overflow of newlines on the buffer.
...
--- a/arch/powerpc/kernel/vio.c
+++ b/arch/powerpc/kernel/vio.c
@@ -1531,12 +1531,12 @@ static ssize_t modalias_show(struct device *dev,
struct device_attribute
*attr,
dn = dev-of_node;
if (!dn) {
-strcat(buf, \n);
+strcpy(buf, \n);
return strlen(buf);
}
cp = of_get_property(dn, compatible, NULL);
if (!cp) {
-strcat(buf, \n);
+strcpy(buf, \n);
return strlen(buf);
}
Why not just:
buf[0] = '\n';
buf[1] = 0;
return 1;
The assignment to buf[1] might not even be needed.
Sure, I guess that'd work too. But it really seems like 1/2 a dozen of one and
six of the other. I'll defer to the preference of the maintainers to see what
they want.
P.
David
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCHv1 1/8] ALSA: Add SAI SoC Digital Audio Interface driver.
On 10/17/2013 02:15 PM, Timur Tabi wrote: Xiubo Li wrote: +res = platform_get_resource(pdev, IORESOURCE_MEM, 0); +sai-base = devm_ioremap_resource(pdev-dev, res); Why not use of_iomap()? Because it won't check for conflicting resource regions. - Lars ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCHv1 1/8] ALSA: Add SAI SoC Digital Audio Interface driver.
Lars-Peter Clausen wrote: +res = platform_get_resource(pdev, IORESOURCE_MEM, 0); +sai-base = devm_ioremap_resource(pdev-dev, res); Why not use of_iomap()? Because it won't check for conflicting resource regions. Maybe I've been out of the loop for too long, but why is that a particular problem with this driver? ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCHv1 1/8] ALSA: Add SAI SoC Digital Audio Interface driver.
On 10/17/2013 03:22 PM, Timur Tabi wrote: Lars-Peter Clausen wrote: +res = platform_get_resource(pdev, IORESOURCE_MEM, 0); +sai-base = devm_ioremap_resource(pdev-dev, res); Why not use of_iomap()? Because it won't check for conflicting resource regions. Maybe I've been out of the loop for too long, but why is that a particular problem with this driver? It is usually something you'd want to check in general to make sure that you don't have multiple device that access the same iomem region at the same time. - Lars ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [4/4] powerpc/mpc8548: Add workaround for erratum NMG_SRIO135
OK. I will do.
-Chenhui
From: Wood Scott-B07421
Sent: Thursday, October 17, 2013 7:20
To: Zhao Chenhui-B35336
Cc: linuxppc-dev@lists.ozlabs.org
Subject: Re: [4/4] powerpc/mpc8548: Add workaround for erratum NMG_SRIO135
On Tue, Mar 06, 2012 at 05:10:56PM +0800, chenhui zhao wrote:
From: chenhui zhao chenhui.z...@freescale.com
Issue:
Applications using lwarx/stwcx instructions in the core to
compete for a software lock or semaphore with a device on
RapidIO using read atomic set, clr, inc, or dec in a similar
manner may falsely result in both masters seeing the lock
as available. This could result in data corruption as
both masters try to modify the same piece of data protected
by the lock.
Workaround:
Set bits 13 and 29 of CCSR offset 0x01010 (EEBPCR register
of the ECM) during initialization and leave them set
indefinitely. This may slightly degrade overall system
performance.
Refer to SRIO39 in MPC8548 errata document.
Signed-off-by: Gong Chen g.c...@freescale.com
Signed-off-by: Zhao Chenhui chenhui.z...@freescale.com
Signed-off-by: Li Yang le...@freescale.com
---
arch/powerpc/sysdev/fsl_rio.c | 44 +
1 files changed, 44 insertions(+), 0 deletions(-)
[snip]
@@ -358,6 +391,17 @@ int fsl_rio_setup(struct platform_device *dev)
dev-dev.of_node-full_name);
return -EFAULT;
}
+
+ /* Fix erratum NMG_SRIO135 */
+ if (fsl_svr_is(SVR_8548) || fsl_svr_is(SVR_8548_E)) {
+ rc = fixup_erratum_srio135(dev-dev);
+ if (rc) {
+ dev_err(dev-dev,
+ Failed to fix the erratum NMG_SRIO135.);
+ return rc;
+ }
+ }
This needs to be respun based on the current tree.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCHv1 1/8] ALSA: Add SAI SoC Digital Audio Interface driver.
Lars-Peter Clausen wrote: Maybe I've been out of the loop for too long, but why is that a particular problem with this driver? It is usually something you'd want to check in general to make sure that you don't have multiple device that access the same iomem region at the same time. I understand that, but I'm trying to figure out why of_iomap() is okay for hundreds of other drivers, but not this one. I've used it dozens of times myself, without ever worrying about overlapping regions. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 0/3 v2] iommu/fsl: PAMU driver fixes.
Hi Joerg, Please consider these patches for 3.12. Regards Varun -Original Message- From: Sethi Varun-B16395 Sent: Wednesday, October 16, 2013 4:53 PM To: j...@8bytes.org; io...@lists.linux-foundation.org; linuxppc- d...@lists.ozlabs.org; linux-ker...@vger.kernel.org; Yoder Stuart-B08248; Wood Scott-B07421; alex.william...@redhat.com; Bhushan Bharat-R65777 Cc: Sethi Varun-B16395 Subject: [PATCH 0/3 v2] iommu/fsl: PAMU driver fixes. The first patch fixes a build failure, when we try to build for a Freescale platform without PCI support. The second patch enables a default DMA window for the device, once it's detached from a domain. In case of vfio, once device is detached from a guest it can be again used by the host. The last patch adds the maintainer entry for the Freescale PAMU driver. Varun Sethi (3): iommu/fsl: Factor out PCI specific code. iommu/fsl: Enable default DMA window for PCIe devices once detached Add maintainers entry for the Freescale PAMU driver. MAINTAINERS |7 ++ drivers/iommu/fsl_pamu.c| 43 ++--- drivers/iommu/fsl_pamu.h|1 + drivers/iommu/fsl_pamu_domain.c | 134 + -- 4 files changed, 128 insertions(+), 57 deletions(-) -- 1.7.9.5 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCHv1 1/8] ALSA: Add SAI SoC Digital Audio Interface driver.
On 10/17/2013 03:37 PM, Timur Tabi wrote: Lars-Peter Clausen wrote: Maybe I've been out of the loop for too long, but why is that a particular problem with this driver? It is usually something you'd want to check in general to make sure that you don't have multiple device that access the same iomem region at the same time. I understand that, but I'm trying to figure out why of_iomap() is okay for hundreds of other drivers, but not this one. I've used it dozens of times myself, without ever worrying about overlapping regions. The driver would work fine with just of_iomap(). But the resource range check comes basically for free and it does help to catch errors, so I'd recommend on using it rather than not using it. - Lars ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCHv1 1/8] ALSA: Add SAI SoC Digital Audio Interface driver.
On Thu, Oct 17, 2013 at 03:51:54PM +0200, Lars-Peter Clausen wrote: On 10/17/2013 03:37 PM, Timur Tabi wrote: I understand that, but I'm trying to figure out why of_iomap() is okay for hundreds of other drivers, but not this one. I've used it dozens of times myself, without ever worrying about overlapping regions. The driver would work fine with just of_iomap(). But the resource range check comes basically for free and it does help to catch errors, so I'd recommend on using it rather than not using it. There's also the fact that it's a devm_ function which means less error handling code that we can break which is nice. There's probably a case for an improved OF helper here... signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: IBM OpenPower 720 ipr driver woes
On 06/06/2013 08:24 PM, Gavin Shan wrote: On Thu, Jun 06, 2013 at 08:39:45AM -0400, Robert Knight wrote: On 06/06/2013 07:32 AM, Brian King wrote: On 06/05/2013 04:14 PM, Robert Knight wrote: On 6/3/2013 11:52 PM, Gavin Shan wrote: On Tue, Jun 04, 2013 at 01:16:52PM +1000, Tony Breeds wrote: On Mon, Jun 03, 2013 at 09:40:52PM -0400, Robert Knight wrote: On 6/3/2013 8:01 PM, Tony Breeds wrote: On Mon, Jun 03, 2013 at 05:20:12PM -0400, Robert Knight wrote: .../... Yes. I've started rebuilding the kernel and I'm up to the module building part, so I'd say it is solid. Will this patch make it into some version of the kernel? The patch is being pushed to mainline or linux-next, and backported to stable-kernel (v3.4+) What was killing me was that it would not complete boot. It now does. I see: [ 11.934481] scsi 0:0:15:0: Resetting device [ 11.934813] ipr 0001:d0:01.0: Adapter being reset as a result of error recovery. on each boot. It does not appear to affect operation. Thank you and the rest of the team for your rapid and helpful responses. Thanks, Gavin Well, it's four months later and I'm trying to get Fedora 20 Alpha to install on that same machine. It appears to still have the same problem. Did that patch ever make it into the mainline? Strangely, the kernel from the installer (using DVD image) does NOT have the problem, only the installed system. Regards, Robert ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v5] powerpc/mpc85xx: Update the clock nodes in device tree
On Wed, 2013-10-16 at 21:08 -0500, Tang Yuantian-B29983 wrote: That shows the dividers as being somewhere in between the PLL and the MUX. The MUX is where the divider is selected. There's nothing in the PLL's programming interface that relates to the dividers. As such it's simpler to model it as being part of the MUX. -Scott I don't know whether it is simpler, but modeling divider as being part of the MUX is your guess, right? If the divider is included in MUX, the MUX would not be called MUX. It's still selecting from multiple PLLs. I don't know whether divider module exists or not. If it exists, it should be part of PLL or between PLL and MUX. wherever it was, the device tree binding is appropriate. The device tree binding is unnecessarily complicated. The P3041RM shows exactly each PLL has 2 outputs which definitely have no divider at all. That diagram is a bit weird -- one of the outputs is used as is, and the other is split into 1/2 and 1/4. It doesn't really matter though; the end result is the same. We're describing the programming interface, not artwork choices in the manual. -Scott If the device tree needs to be modified, could you give me your suggestions? My suggestion is to have only one output per PLL node. The MUX node would have one input per PLL. Dividers would be handled internally to the MUX driver. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH -V2 00/14] Allow PR and HV KVM to coexist in one kernel
On 07.10.2013, at 18:47, Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com wrote: Hi All, This patch series support enabling HV and PR KVM together in the same kernel. We extend machine property with new property kvm_type. A value of HV will force HV KVM and PR PR KVM. If we don't specify kvm_type we will select the fastest KVM mode. ie, HV if that is supported otherwise PR. Thanks, applied all to kvm-ppc-queue. Alex ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH -V2 06/14] kvm: powerpc: booke: Convert BOOKE to use kvmppc_ops callbacks
On 07.10.2013, at 18:47, Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com wrote: From: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com Make required changes to get BOOKE configs to build with the introduction of kvmppc_ops callback Signed-off-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com This can not be a separate commit, as you're breaking bisectability for booke this way. I've squashed this in with the previous commit. Alex ___ 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
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/
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?
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 02/10][v6] powerpc/Power7: detect load/store instructions
|
| How about I add this to the function header ?
|
| * Please use the table in Appendix F (opcode maps) to determine
| * events selected by this function.
Here is the updated patch with the comment.
---
From 38d1f9ac67a7f50db593e5875a8de6a2ecbea8e0 Mon Sep 17 00:00:00 2001
From: Sukadev Bhattiprolu suka...@linux.vnet.ibm.com
Date: Fri, 23 Aug 2013 18:35:02 -0700
Subject: [PATCH 6/10][v6] powerpc/Power7: detect load/store instructions
Implement instr_is_load_store_2_06() to detect whether a given instruction
is one of the fixed-point or floating-point load/store instructions in the
POWER Instruction Set Architecture v2.06.
This function will be used in a follow-on patch to save memory hierarchy
information of the load/store on a Power7 system. (Power8 systems set some
bits in the SIER to identify load/store operations and hence don't need a
similar functionality).
Based on optimized code from Michael Ellerman and comments from Tom Musta.
Signed-off-by: Sukadev Bhattiprolu suka...@linux.vnet.ibm.com
---
Changelog[v6]
- [David Laight, Anshuman Khandual] Add a comment in function
header to help better understand which instructions are selected
by the instr_is_load_store_2_06().
- [Michael Ellerman, Tom Musta]: Optmize the implementation to
avoid for loop.
arch/powerpc/include/asm/code-patching.h |1 +
arch/powerpc/lib/code-patching.c | 48 ++
2 files changed, 49 insertions(+)
diff --git a/arch/powerpc/include/asm/code-patching.h
b/arch/powerpc/include/asm/code-patching.h
index a6f8c7a..9cc3ef1 100644
--- a/arch/powerpc/include/asm/code-patching.h
+++ b/arch/powerpc/include/asm/code-patching.h
@@ -34,6 +34,7 @@ int instr_is_branch_to_addr(const unsigned int *instr,
unsigned long addr);
unsigned long branch_target(const unsigned int *instr);
unsigned int translate_branch(const unsigned int *dest,
const unsigned int *src);
+int instr_is_load_store_2_06(const unsigned int *instr);
static inline unsigned long ppc_function_entry(void *func)
{
diff --git a/arch/powerpc/lib/code-patching.c b/arch/powerpc/lib/code-patching.c
index 2bc9db3..84571aa 100644
--- a/arch/powerpc/lib/code-patching.c
+++ b/arch/powerpc/lib/code-patching.c
@@ -159,6 +159,54 @@ unsigned int translate_branch(const unsigned int *dest,
const unsigned int *src)
return 0;
}
+/*
+ * Determine if the op code in the instruction corresponds to a load or
+ * store instruction. Ignore the vector load instructions like evlddepx,
+ * evstddepx for now.
+ *
+ * This function is valid for POWER ISA 2.06.
+ *
+ * Reference: PowerISA_V2.06B_Public.pdf, Sections 3.3.2 through 3.3.6
+ * and 4.6.2 through 4.6.4, Appendix F (Opcode Maps).
+ *
+ * Use the tables in Appendix F (Opcode Maps) to identify
+ * instructions selected by this function.
+ */
+int instr_is_load_store_2_06(const unsigned int *instr)
+{
+ unsigned int op, upper, lower;
+
+ op = instr_opcode(*instr);
+
+ if ((op = 32 op = 58) || (op == 61 || op == 62))
+ return true;
+
+ if (op != 31)
+ return false;
+
+ upper = op 5;
+ lower = op 0x1f;
+
+ /* Short circuit as many misses as we can */
+ if (lower 3 || lower 23)
+ return false;
+
+ if (lower == 3) {
+ if (upper = 16)
+ return true;
+
+ return false;
+ }
+
+ if (lower == 7 || lower == 12)
+ return true;
+
+ if (lower = 20) /* lower = 23 (implicit) */
+ return true;
+
+ return false;
+}
+
#ifdef CONFIG_CODE_PATCHING_SELFTEST
--
1.7.9.5
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCHv1 1/8] ALSA: Add SAI SoC Digital Audio Interface driver.
On 10/17/2013 11:01 AM, Xiubo Li wrote:
[...]
+static int fsl_sai_hw_params(struct snd_pcm_substream *substream,
+ struct snd_pcm_hw_params *params,
+ struct snd_soc_dai *cpu_dai)
+{
+ int ret;
+
+ ret = fsl_sai_hw_params_tr(substream, params, cpu_dai,
+ FSL_FMT_TRANSMITTER);
+ if (ret) {
+ dev_err(cpu_dai-dev,
+ Cannot set sai transmitter hw params: %d\n,
+ ret);
+ return ret;
+ }
+
+ ret = fsl_sai_hw_params_tr(substream, params, cpu_dai,
+ FSL_FMT_RECEIVER);
+ if (ret) {
+ dev_err(cpu_dai-dev,
+ Cannot set sai's receiver hw params: %d\n,
+ ret);
+ return ret;
+ }
Shouldn't, depending on the substream direction, either transmit or receiver
be configured, instead of always configuring both?
+
+ return 0;
+}
+
+static int fsl_sai_trigger(struct snd_pcm_substream *substream, int cmd,
+ struct snd_soc_dai *dai)
+{
+ struct fsl_sai *sai = snd_soc_dai_get_drvdata(dai);
+ unsigned int tcsr, rcsr;
+
+ tcsr = readl(sai-base + SAI_TCSR);
+ rcsr = readl(sai-base + SAI_RCSR);
+
+ switch (cmd) {
+ case SNDRV_PCM_TRIGGER_START:
+ case SNDRV_PCM_TRIGGER_RESUME:
+ case SNDRV_PCM_TRIGGER_PAUSE_RELEASE:
+ rcsr |= SAI_CSR_TERE | SAI_CSR_FRDE;
+ tcsr |= SAI_CSR_TERE | SAI_CSR_FRDE;
+ writel(rcsr, sai-base + SAI_RCSR);
+ udelay(10);
+ writel(tcsr, sai-base + SAI_TCSR);
+ break;
+
+ case SNDRV_PCM_TRIGGER_STOP:
+ case SNDRV_PCM_TRIGGER_SUSPEND:
+ case SNDRV_PCM_TRIGGER_PAUSE_PUSH:
+ tcsr = ~(SAI_CSR_TERE | SAI_CSR_FRDE);
+ rcsr = ~(SAI_CSR_TERE | SAI_CSR_FRDE);
+ writel(tcsr, sai-base + SAI_TCSR);
+ udelay(10);
+ writel(rcsr, sai-base + SAI_RCSR);
+ break;
+ default:
+ return -EINVAL;
+ }
+
Same here, shouldn't tx and rx be started independently depending on the
substream direction?
+ return 0;
+}
+
+static struct snd_soc_dai_ops fsl_sai_pcm_dai_ops = {
const
+ .set_sysclk = fsl_sai_set_dai_sysclk,
+ .set_clkdiv = fsl_sai_set_dai_clkdiv,
+ .set_fmt= fsl_sai_set_dai_fmt,
+ .set_tdm_slot = fsl_sai_set_dai_tdm_slot,
+ .hw_params = fsl_sai_hw_params,
+ .trigger= fsl_sai_trigger,
+};
[...]
+static const struct snd_soc_component_driver fsl_component = {
+ .name = fsl-sai,
+};
+
+static int fsl_sai_probe(struct platform_device *pdev)
+{
[...]
+
+ sai-dma_params_rx.addr = res-start + SAI_RDR;
+ sai-dma_params_rx.maxburst = 6;
+ index = of_property_match_string(np, dma-names, rx);
+ ret = of_parse_phandle_with_args(np, dmas, #dma-cells, index,
+ dma_args);
+ if (ret)
+ return ret;
+ sai-dma_params_rx.slave_id = dma_args.args[1];
+
+ sai-dma_params_tx.addr = res-start + SAI_TDR;
+ sai-dma_params_tx.maxburst = 6;
+ index = of_property_match_string(np, dma-names, tx);
+ ret = of_parse_phandle_with_args(np, dmas, #dma-cells, index,
+ dma_args);
+ if (ret)
+ return ret;
+ sai-dma_params_tx.slave_id = dma_args.args[1];
The driver should not have to manually parse the dma devicetree properties,
this is something that should be handled by the dma engine driver.
+
+ ret = snd_soc_register_component(pdev-dev, fsl_component,
+ fsl_sai_dai, 1);
+ if (ret)
+ return ret;
+
+ ret = fsl_pcm_dma_init(pdev);
+ if (ret)
+ goto out;
+
+ platform_set_drvdata(pdev, sai);
+
+ return 0;
+
+out:
+ snd_soc_unregister_component(pdev-dev);
+ return ret;
+}
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 5/7] jump_label: relax branch hinting restrictions
On Thu, 17 Oct 2013 12:10:28 +0200
Radim Krčmář rkrc...@redhat.com wrote:
We implemented the optimized branch selection in higher levels of api.
That made static_keys very unintuitive, so this patch introduces another
element to jump_table, carrying one bit that tells the underlying code
which branch to optimize.
It is now possible to select optimized branch for every jump_entry.
Current side effect is 1/3 increase increase in space, we could:
* use bitmasks and selectors on 2+ aligned code/struct.
- aligning jump target is easy, but because it is not done by default
and few bytes in .text are much worse that few kilos in .data,
I chose not to
- data is probably aligned by default on all current architectures,
but programmer can force misalignment of static_key
* optimize each architecture independently
- I can't test everything and this patch shouldn't break anything, so
others can contribute in the future
* choose something worse, like packing or splitting
* ignore
proof: example x86_64 disassembly: (F = )
struct static_key flexible_feature;
noinline void jump_label_experiment(void) {
if ( static_key_false(flexible_feature))
asm (push 0xa1);
else asm (push 0xa0);
if (!static_key_false(flexible_feature))
asm (push 0xb0);
else asm (push 0xb1);
if ( static_key_true(flexible_feature))
asm (push 0xc1);
else asm (push 0xc0);
if (!static_key_true(flexible_feature))
asm (push 0xd0);
else asm (push 0xd1);
}
Disassembly of section .text: (push marked by -)
F81002000 jump_label_experiment:
F81002000: e8 7b 29 75 00 callq F81754980 __fentry__
F81002005: 55 push %rbp
F81002006: 48 89 e5mov%rsp,%rbp
F81002009: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1)
F8100200e: -ff 34 25 a0 00 00 00pushq 0xa0
F81002015: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1)
F8100201a: -ff 34 25 b0 00 00 00pushq 0xb0
F81002021: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1)
F81002026: -ff 34 25 c1 00 00 00pushq 0xc1
F8100202d: 0f 1f 00nopl (%rax)
F81002030: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1)
F81002035: -ff 34 25 d1 00 00 00pushq 0xd1
F8100203c: 5d pop%rbp
F8100203d: 0f 1f 00nopl (%rax)
F81002040: c3 retq
This looks exactly like what we want. I take it this is with your
patch. What was the result before the patch?
-- Steve
F81002041: 0f 1f 80 00 00 00 00nopl 0x0(%rax)
F81002048: -ff 34 25 d0 00 00 00pushq 0xd0
F8100204f: 5d pop%rbp
F81002050: c3 retq
F81002051: 0f 1f 80 00 00 00 00nopl 0x0(%rax)
F81002058: -ff 34 25 c0 00 00 00pushq 0xc0
F8100205f: 90 nop
F81002060: eb cb jmpF8100202d [...]+0x2d
F81002062: 66 0f 1f 44 00 00 nopw 0x0(%rax,%rax,1)
F81002068: -ff 34 25 b1 00 00 00pushq 0xb1
F8100206f: 90 nop
F81002070: eb af jmpF81002021 [...]+0x21
F81002072: 66 0f 1f 44 00 00 nopw 0x0(%rax,%rax,1)
F81002078: -ff 34 25 a1 00 00 00pushq 0xa1
F8100207f: 90 nop
F81002080: eb 93 jmpF81002015 [...]+0x15
F81002082: 66 66 66 66 66 2e 0f[...]
F81002089: 1f 84 00 00 00 00 00
Contents of section .data: (relevant part of embedded __jump_table)
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH v5] powerpc/mpc85xx: Update the clock nodes in device tree
On Wed, 2013-10-16 at 21:08 -0500, Tang Yuantian-B29983 wrote: That shows the dividers as being somewhere in between the PLL and the MUX. The MUX is where the divider is selected. There's nothing in the PLL's programming interface that relates to the dividers. As such it's simpler to model it as being part of the MUX. -Scott I don't know whether it is simpler, but modeling divider as being part of the MUX is your guess, right? If the divider is included in MUX, the MUX would not be called MUX. It's still selecting from multiple PLLs. I don't know whether divider module exists or not. If it exists, it should be part of PLL or between PLL and MUX. wherever it was, the device tree binding is appropriate. The device tree binding is unnecessarily complicated. The P3041RM shows exactly each PLL has 2 outputs which definitely have no divider at all. That diagram is a bit weird -- one of the outputs is used as is, and the other is split into 1/2 and 1/4. It doesn't really matter though; the end result is the same. We're describing the programming interface, not artwork choices in the manual. -Scott If the device tree needs to be modified, could you give me your suggestions? My suggestion is to have only one output per PLL node. The MUX node would have one input per PLL. Dividers would be handled internally to the MUX driver. -Scott I don't think your suggestion is constructive. Your suggestion is on the premise of that the divider is part of MUX, And I think it should be part of PLL. MUX can't CREATE clock which PLL can. So my thought is more reasonable. If the device tree documents like what you said, it would have few help for driver. The reason is obvious that the driver is still going to deal with the divider detail which varies from platform to platform. I will document as it was unless you prove your suggestion. Thanks, Yuantian ___ 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: 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 -V2 06/14] kvm: powerpc: booke: Convert BOOKE to use kvmppc_ops callbacks
Alexander Graf ag...@suse.de writes: On 07.10.2013, at 18:47, Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com wrote: From: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com Make required changes to get BOOKE configs to build with the introduction of kvmppc_ops callback Signed-off-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com This can not be a separate commit, as you're breaking bisectability for booke this way. The only reason I split that into two was to make review easy. But yes when merging to your tree we should fold. I've squashed this in with the previous commit. Ok. -aneesh ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
