* Re: [PATCH 5/10] memory-hotplug : memory-hotplug: check page type in get_page_bootmem
From: KOSAKI Motohiro @ 2012-10-12 19:28 UTC (permalink / raw)
To: Yasuaki Ishimatsu
Cc: linux-s390, linux-ia64, wency, len.brown, linux-acpi, linux-sh,
x86, linux-kernel, cmetcalf, linux-mm, minchan.kim, rientjes,
sparclinux, cl, linuxppc-dev, akpm, liuj97
In-Reply-To: <506E46B6.3060502@jp.fujitsu.com>
On Thu, Oct 4, 2012 at 10:32 PM, Yasuaki Ishimatsu
<isimatu.yasuaki@jp.fujitsu.com> wrote:
> The function get_page_bootmem() may be called more than one time to the same
> page. There is no need to set page's type, private if the function is not
> the first time called to the page.
>
> Note: the patch is just optimization and does not fix any problem.
>
> CC: David Rientjes <rientjes@google.com>
> CC: Jiang Liu <liuj97@gmail.com>
> CC: Len Brown <len.brown@intel.com>
> CC: Christoph Lameter <cl@linux.com>
> Cc: Minchan Kim <minchan.kim@gmail.com>
> CC: Andrew Morton <akpm@linux-foundation.org>
> CC: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
> CC: Wen Congyang <wency@cn.fujitsu.com>
> Signed-off-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
> ---
> mm/memory_hotplug.c | 15 +++++++++++----
> 1 file changed, 11 insertions(+), 4 deletions(-)
>
> Index: linux-3.6/mm/memory_hotplug.c
> ===================================================================
> --- linux-3.6.orig/mm/memory_hotplug.c 2012-10-04 18:29:58.284676075 +0900
> +++ linux-3.6/mm/memory_hotplug.c 2012-10-04 18:30:03.454680542 +0900
> @@ -95,10 +95,17 @@ static void release_memory_resource(stru
> static void get_page_bootmem(unsigned long info, struct page *page,
> unsigned long type)
> {
> - page->lru.next = (struct list_head *) type;
> - SetPagePrivate(page);
> - set_page_private(page, info);
> - atomic_inc(&page->_count);
> + unsigned long page_type;
> +
> + page_type = (unsigned long)page->lru.next;
If I understand correctly, page->lru.next might be uninitialized yet.
Moreover, I have no seen any good effect in this patch. I don't understand
why we need to increase code complexity.
> + if (page_type < MEMORY_HOTPLUG_MIN_BOOTMEM_TYPE ||
> + page_type > MEMORY_HOTPLUG_MAX_BOOTMEM_TYPE){
> + page->lru.next = (struct list_head *)type;
> + SetPagePrivate(page);
> + set_page_private(page, info);
> + atomic_inc(&page->_count);
> + } else
> + atomic_inc(&page->_count);
> }
>
> /* reference to __meminit __free_pages_bootmem is valid
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo@kvack.org. For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* [PATCH 1/9] powerpc: 83xx: use module_i2c_driver macro
From: Devendra Naga @ 2012-10-13 19:03 UTC (permalink / raw)
To: Kumar Gala, Benjamin Herrenschmidt, Paul Mackerras, linuxppc-dev
Cc: Devendra Naga
replace the module init and exit calls containing the
i2c_add_driver and i2c_del_driver with the module_i2c_driver
macro as it does the same things as the code that is removed
Signed-off-by: Devendra Naga <devendra.aaru@gmail.com>
---
Not compile tested, because i dont have a ppc cross toolchain
arch/powerpc/platforms/83xx/mcu_mpc8349emitx.c | 13 +------------
1 files changed, 1 insertions(+), 12 deletions(-)
diff --git a/arch/powerpc/platforms/83xx/mcu_mpc8349emitx.c b/arch/powerpc/platforms/83xx/mcu_mpc8349emitx.c
index ef6537b..d27477b 100644
--- a/arch/powerpc/platforms/83xx/mcu_mpc8349emitx.c
+++ b/arch/powerpc/platforms/83xx/mcu_mpc8349emitx.c
@@ -232,18 +232,7 @@ static struct i2c_driver mcu_driver = {
.id_table = mcu_ids,
};
-static int __init mcu_init(void)
-{
- return i2c_add_driver(&mcu_driver);
-}
-module_init(mcu_init);
-
-static void __exit mcu_exit(void)
-{
- i2c_del_driver(&mcu_driver);
-}
-module_exit(mcu_exit);
-
+module_i2c_driver(mcu_driver);
MODULE_DESCRIPTION("Power Management and GPIO expander driver for "
"MPC8349E-mITX-compatible MCU");
MODULE_AUTHOR("Anton Vorontsov <avorontsov@ru.mvista.com>");
--
1.7.1
^ permalink raw reply related
* Re: [PATCH 1/9] powerpc: 83xx: use module_i2c_driver macro
From: devendra.aaru @ 2012-10-13 19:04 UTC (permalink / raw)
To: Kumar Gala, Benjamin Herrenschmidt, Paul Mackerras, linuxppc-dev
Cc: Devendra Naga
In-Reply-To: <1350154986-1478-1-git-send-email-devendra.aaru@gmail.com>
whoops, sorry, i made mistake in the patchset numbering,
please ignore this patch i will send a patch with the updated correct
number. actually there is only one patch. no 9 patches,
sorry for the noise,
devendra
^ permalink raw reply
* [PATCH 1/9] powerpc: 83xx: use module_i2c_driver macro
From: Devendra Naga @ 2012-10-13 19:05 UTC (permalink / raw)
To: Kumar Gala, Benjamin Herrenschmidt, Paul Mackerras, linuxppc-dev
Cc: Devendra Naga
replace the module init and exit calls containing the
i2c_add_driver and i2c_del_driver with the module_i2c_driver
macro as it does the same things as the code that is removed
Signed-off-by: Devendra Naga <devendra.aaru@gmail.com>
---
Not compile tested, because i dont have a ppc cross toolchain
arch/powerpc/platforms/83xx/mcu_mpc8349emitx.c | 13 +------------
1 files changed, 1 insertions(+), 12 deletions(-)
diff --git a/arch/powerpc/platforms/83xx/mcu_mpc8349emitx.c b/arch/powerpc/platforms/83xx/mcu_mpc8349emitx.c
index ef6537b..d27477b 100644
--- a/arch/powerpc/platforms/83xx/mcu_mpc8349emitx.c
+++ b/arch/powerpc/platforms/83xx/mcu_mpc8349emitx.c
@@ -232,18 +232,7 @@ static struct i2c_driver mcu_driver = {
.id_table = mcu_ids,
};
-static int __init mcu_init(void)
-{
- return i2c_add_driver(&mcu_driver);
-}
-module_init(mcu_init);
-
-static void __exit mcu_exit(void)
-{
- i2c_del_driver(&mcu_driver);
-}
-module_exit(mcu_exit);
-
+module_i2c_driver(mcu_driver);
MODULE_DESCRIPTION("Power Management and GPIO expander driver for "
"MPC8349E-mITX-compatible MCU");
MODULE_AUTHOR("Anton Vorontsov <avorontsov@ru.mvista.com>");
--
1.7.1
^ permalink raw reply related
* RE: gianfar driver crash on P1020
From: Avi Tsarfati @ 2012-10-14 12:10 UTC (permalink / raw)
To: Claudiu Manoil; +Cc: linuxppc-dev
In-Reply-To: <507452B0.7040401@freescale.com>
[-- Attachment #1.1: Type: text/plain, Size: 7132 bytes --]
Hi,
The patch you sent me will prevent TX timeouts that will trigger gianfar
stop(gfar_stop is causing the soft lockup) & start by network watchdog
and will solve my first problem.
But, I have this problem again while running some traffic (ping -s 1500
to and from my device) and configuring MTU or set eth interface down. In
both cases gfar_stop sometimes cause soft lockup of 2 minutes.
Trace in case of MTU set:
BR_1: port 1(eth0) entering forwarding state
PHY: mdio@ffe24000:01 - Link is Down
PHY: mdio@ffe24000:01 - Link is Up - 100/Half
PHY: mdio@ffe24000:01 - Link is Down
PHY: mdio@ffe24000:01 - Link is Up - 10/Half
PHY: mdio@ffe24000:01 - Link is Down
BR_1: port 1(eth0) entering disabled state
PHY: mdio@ffe24000:01 - Link is Up - 1000/Full
BR_1: port 1(eth0) entering forwarding state
BUG: soft lockup - CPU#0 stuck for 120s! [wavman:2348]
Modules linked in: xt_physdev xt_state xt_tcpudp ebt_mark ebt_mark_m
ebt_limit ebtable_nat ebtable_broute ebtable_filter ebtables
iptable_mangle iptable_nat nf_nat nf_conntrack_ipv4 nf_defrag_ipv4
nf_conntrack umac online_acs(P) dih(P) netlink_support(P) dfs_addon(P)
waran(P) ath_dev(P) ath_rate_atheros(P) addons_shared(P) ath_hal(P) adf
asf(P) iptable_filter ip_tables x_tables
NIP: c00513b8 LR: c00530b4 CTR: c005304c
REGS: c6009880 TRAP: 0901 Tainted: P (2.6.31)
MSR: 00029000 <EE,ME,CE> CR: 22028228 XER: 00000000
TASK = cd47aa30[2348] 'wavman' THREAD: c6008000
GPR00: 00000080 c6009930 cd47aa30 00000010 ca690a00 c6009b34 c6009ad8
d1880000
GPR08: 11b6598e 00000000 00000000 c0385f14 00000000
NIP [c00513b8] handle_IRQ_event+0x28/0x13c
LR [c00530b4] handle_fasteoi_irq+0x68/0xf0
Call Trace:
[c6009930] [00000004] 0x4 (unreliable)
[c6009950] [c00530b4] handle_fasteoi_irq+0x68/0xf0
[c6009960] [c0004f04] do_IRQ+0x98/0xb4
[c6009980] [c000fe58] ret_from_except+0x0/0x18
[c6009a40] [c0187ae0] stop_gfar+0x20/0x11c
[c6009a60] [c0189360] gfar_change_mtu+0x124/0x164
[c6009a80] [c01d5c30] dev_set_mtu+0x70/0xa4
[c6009a90] [c01e112c] do_setlink+0x1dc/0x348
[c6009ad0] [c01e2a9c] rtnl_newlink+0x330/0x460
[c6009bd0] [c01e2288] rtnetlink_rcv_msg+0x228/0x260
[c6009bf0] [c01ee0e8] netlink_rcv_skb+0x110/0x120
[c6009c10] [c01e204c] rtnetlink_rcv+0x28/0x3c
[c6009c30] [c01edd78] netlink_unicast+0x2c4/0x334
[c6009c70] [c01ee7ec] netlink_sendmsg+0x1c8/0x280
[c6009cc0] [c01c4c74] sock_sendmsg+0xac/0xe4
[c6009db0] [c01c4e80] sys_sendmsg+0x1d4/0x284
[c6009f00] [c01c58d4] sys_socketcall+0xe0/0x1f8
[c6009f40] [c000f804] ret_from_syscall+0x0/0x3c
Instruction dump:
801f0024 4bfffe3c 9421ffe0 7c0802a6 bf61000c 7c9f2378 90010024 7c7e1b78
80040004 70090020 40820008 7c008146 <3d20c02e> 3ba00000 3b69e138
3b800000
Trace in case of set eth down:
PHY: mdio@ffe24000:01 - Link is Up - 1000/Full
BR_1: port 1(eth0) entering forwarding state
BR_1: port 1(eth0) entering disabled state
BR_1: port 1(eth0) entering forwarding state
PHY: mdio@ffe24000:01 - Link is Up - 100/Full
BUG: soft lockup - CPU#0 stuck for 120s! [ip:8428]
Modules linked in: xt_physdev xt_state xt_tcpudp ebt_mark ebt_mark_m
ebt_limit ebtable_nat ebtable_broute ebtable_filter ebtables
iptable_mangle iptable_nat nf_nat nf_conntrack_ipv4 nf_defrag_ipv4
nf_conntrack rpldev umac online_acs(P) dih(P) netlink_support(P)
dfs_addon(P) waran(P) ath_dev(P) ath_rate_atheros(P) addons_shared(P)
ath_hal(P) adf asf(P) iptable_filter ip_tables x_tables
NIP: c00513b8 LR: c00530b4 CTR: c005304c
REGS: ca663bc0 TRAP: 0901 Tainted: P (2.6.31)
MSR: 00029000 <EE,ME,CE> CR: 22020428 XER: 00000000
TASK = c55c7390[8428] 'ip' THREAD: ca662000
GPR00: 00000080 ca663c70 c55c7390 00000010 c627cb00 c0364ae8 00000008
d1880000
GPR08: 4800f86b 00000000 00000000 c0385f14 00000000
NIP [c00513b8] handle_IRQ_event+0x28/0x13c
LR [c00530b4] handle_fasteoi_irq+0x68/0xf0
Call Trace:
[ca663c70] [ca662000] 0xca662000 (unreliable)
[ca663c90] [c00530b4] handle_fasteoi_irq+0x68/0xf0
[ca663ca0] [c0004f04] do_IRQ+0x98/0xb4
[ca663cc0] [c000fe58] ret_from_except+0x0/0x18
[ca663d80] [c0187af8] stop_gfar+0x38/0x11c
[ca663da0] [c01882c0] gfar_close+0x30/0xa0
[ca663dc0] [c01d62ec] dev_close+0x8c/0xe0
[ca663dd0] [c01d5db8] dev_change_flags+0x154/0x1ac
[ca663df0] [c022277c] devinet_ioctl+0x648/0x824
[ca663e60] [c0223294] inet_ioctl+0xcc/0xf8
[ca663e70] [c01c3c08] sock_ioctl+0x10c/0x2d0
[ca663e90] [c008bc60] vfs_ioctl+0x34/0x8c
[ca663ea0] [c008be84] do_vfs_ioctl+0x88/0x724
[ca663f10] [c008c560] sys_ioctl+0x40/0x74
[ca663f40] [c000f804] ret_from_syscall+0x0/0x3c
Instruction dump:
801f0024 4bfffe3c 9421ffe0 7c0802a6 bf61000c 7c9f2378 90010024 7c7e1b78
80040004 70090020 40820008 7c008146 <3d20c02e> 3ba00000 3b69e198
3b800000
A script (test_eth) that I run can reproduce it on my board.
Did you encounter such problem before ?
Thanks in advance,
Avi Tsarfati.
From: Claudiu Manoil [mailto:claudiu.manoil@freescale.com]
Sent: Tuesday, October 09, 2012 6:37 PM
To: Avi Tsarfati
Cc: linuxppc-dev@lists.ozlabs.org
Subject: Re: gianfar driver crash on P1020
Hello,
Did you try this patch?
http://patchwork.ozlabs.org/patch/186315/
Claudiu
On 10/9/2012 3:22 PM, Avi Tsarfati wrote:
Hi,
I have the same problem as you do.
Have you found the CPU stuck reason (or fix) in P1020RDB board ?
Thanks,
Avi Tsarfati.
************************************************************************
************
This footnote confirms that this email message has been scanned
by
PineApp Mail-SeCure for the presence of malicious code, vandals
& computer viruses(187).
************************************************************************
************
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
************************************************************************
************
This footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals &
computer viruses(100).
************************************************************************
************
************************************************************************
************
This footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals &
computer viruses(42).
************************************************************************
************
************************************************************************************
This footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals & computer viruses(187).
************************************************************************************
[-- Attachment #1.2: Type: text/html, Size: 19462 bytes --]
[-- Attachment #2: test_eth --]
[-- Type: application/octet-stream, Size: 361 bytes --]
#!/bin/bash
while [ 1 ]
do
echo "Setting auto negotiation"
ip link set eth0 down
ip link set eth0 address 00:18:25:F0:65:B3
ip link set eth0 up
ethtool -s eth0 autoneg on
sleep 5
echo "Setting 100M"
ip link set eth0 down
ip link set eth0 address 00:18:25:F0:65:B3
ip link set eth0 up
ethtool -s eth0 speed 100 duplex full autoneg off
sleep 5
done
^ permalink raw reply
* Re: [RFC][PATCH] perf: Add a few generic stalled-cycles events
From: Anshuman Khandual @ 2012-10-15 5:26 UTC (permalink / raw)
To: Sukadev Bhattiprolu
Cc: linuxppc-dev, peterz, Anton Blanchard, linux-kernel, eranian,
acme, robert.richter, mpjohn, paulus, mingo, asharma
In-Reply-To: <20121012012839.GA15348@us.ibm.com>
On 10/12/2012 06:58 AM, Sukadev Bhattiprolu wrote:
>
> From 89cb6a25b9f714e55a379467a832ee015014ed11 Mon Sep 17 00:00:00 2001
> From: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
> Date: Tue, 18 Sep 2012 10:59:01 -0700
> Subject: [PATCH] perf: Add a few generic stalled-cycles events
>
> The existing generic event 'stalled-cycles-backend' corresponds to
> PM_CMPLU_STALL event in Power7. While this event is useful, detailed
> performance analysis often requires us to find more specific reasons
> for the stalled cycle. For instance, stalled cycles in Power7 can
> occur due to, among others:
>
> - instruction fetch unit (IFU),
> - Load-store-unit (LSU),
> - Fixed point unit (FXU)
> - Branch unit (BRU)
>
> While it is possible to use raw codes to monitor these events, it quickly
> becomes cumbersome with performance analysis frequently requiring mapping
> the raw event codes in reports to their symbolic names.
>
> This patch is a proposal to try and generalize such perf events. Since
> the code changes are quite simple, I bunched all the 4 events together.
>
> I am not familiar with how readily these events would map to other
> architectures. Here is some information on the events for Power7:
>
> stalled-cycles-fixed-point (PM_CMPLU_STALL_FXU)
>
> Following a completion stall, the last instruction to finish
> before completion resumes was from the Fixed Point Unit.
>
> Completion stall is any period when no groups completed and
> the completion table was not empty for that thread.
>
> stalled-cycles-load-store (PM_CMPLU_STALL_LSU)
>
> Following a completion stall, the last instruction to finish
> before completion resumes was from the Load-Store Unit.
>
> stalled-cycles-instruction-fetch (PM_CMPLU_STALL_IFU)
>
> Following a completion stall, the last instruction to finish
> before completion resumes was from the Instruction Fetch Unit.
>
> stalled-cycles-branch (PM_CMPLU_STALL_BRU)
>
> Following a completion stall, the last instruction to finish
> before completion resumes was from the Branch Unit.
>
> Looking for feedback on this approach and if this can be further extended.
> Power7 has 530 events[2] out of which a "CPI stack analysis"[1] uses about 26
> events.
>
>
> [1] CPI Stack analysis
> https://www.power.org/documentation/commonly-used-metrics-for-performance-analysis
>
> [2] Power7 events:
> https://www.power.org/documentation/comprehensive-pmu-event-reference-power7/
Here we should try to come up with a generic list of places in the processor where
the cycles can stall.
PERF_COUNT_HW_STALLED_CYCLES_FIXED_POINT
PERF_COUNT_HW_STALLED_CYCLES_LOAD_STORE
PERF_COUNT_HW_STALLED_CYCLES_INSTRUCTION_FETCH
PERF_COUNT_HW_STALLED_CYCLES_BRANCH
PERF_COUNT_HW_STALLED_CYCLES_<ANY_OTHER_PLACE1>
PERF_COUNT_HW_STALLED_CYCLES_<ANY_OTHER_PLACE2>
PERF_COUNT_HW_STALLED_CYCLES_<ANY_OTHER_PLACE3>
-----------------------------------------------
This generic list can be a superset which can accommodate all the architecture
giving the flexibility to implement selectively there after. Stall locations are
very important from CPI analysis stand point with real world use cases. This will
definitely help us in that direction.
Regards
Anshuman
^ permalink raw reply
* [PATCH] powerpc: added DSCR support to ptrace
From: Alexey Kardashevskiy @ 2012-10-15 6:18 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Alexey Kardashevskiy, linuxppc-dev, Paul Mackerras,
Anton Blanchard, linux-kernel
The DSCR (aka Data Stream Control Register) is supported on some
server PowerPC chips and allow some control over the prefetch
of data streams.
The kernel already supports DSCR value per thread but there is also
a need in a ability to change it from an external process for
the specific pid.
The patch adds new register index PT_DSCR (index=44) which can be
set/get by:
ptrace(PTRACE_POKEUSER, traced_process, PT_DSCR << 3, dscr);
dscr = ptrace(PTRACE_PEEKUSER, traced_process, PT_DSCR << 3, NULL);
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
---
arch/powerpc/include/asm/ptrace.h | 3 ++-
arch/powerpc/kernel/ptrace.c | 16 ++++++++++++++++
2 files changed, 18 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/include/asm/ptrace.h b/arch/powerpc/include/asm/ptrace.h
index 84cc784..946c556 100644
--- a/arch/powerpc/include/asm/ptrace.h
+++ b/arch/powerpc/include/asm/ptrace.h
@@ -276,7 +276,8 @@ static inline unsigned long regs_get_kernel_stack_nth(struct pt_regs *regs,
#define PT_DAR 41
#define PT_DSISR 42
#define PT_RESULT 43
-#define PT_REGS_COUNT 44
+#define PT_DSCR 44
+#define PT_REGS_COUNT 45
#define PT_FPR0 48 /* each FP reg occupies 2 slots in this space */
diff --git a/arch/powerpc/kernel/ptrace.c b/arch/powerpc/kernel/ptrace.c
index 8d8e028..4798acf 100644
--- a/arch/powerpc/kernel/ptrace.c
+++ b/arch/powerpc/kernel/ptrace.c
@@ -179,6 +179,17 @@ static int set_user_msr(struct task_struct *task, unsigned long msr)
return 0;
}
+static unsigned long get_user_dscr(struct task_struct *task)
+{
+ return task->thread.dscr;
+}
+
+static int set_user_dscr(struct task_struct *task, unsigned long dscr)
+{
+ task->thread.dscr = dscr;
+ return 0;
+}
+
/*
* We prevent mucking around with the reserved area of trap
* which are used internally by the kernel.
@@ -200,6 +211,9 @@ unsigned long ptrace_get_reg(struct task_struct *task, int regno)
if (regno == PT_MSR)
return get_user_msr(task);
+ if (regno == PT_DSCR)
+ return get_user_dscr(task);
+
if (regno < (sizeof(struct pt_regs) / sizeof(unsigned long)))
return ((unsigned long *)task->thread.regs)[regno];
@@ -218,6 +232,8 @@ int ptrace_put_reg(struct task_struct *task, int regno, unsigned long data)
return set_user_msr(task, data);
if (regno == PT_TRAP)
return set_user_trap(task, data);
+ if (regno == PT_DSCR)
+ return set_user_dscr(task, data);
if (regno <= PT_MAX_PUT_REG) {
((unsigned long *)task->thread.regs)[regno] = data;
--
1.7.10.4
^ permalink raw reply related
* RE: [PATCH][v4] sata_fsl: add workaround for data length mismatch on freescale V2 controller
From: Xie Shaohui-B21989 @ 2012-10-15 7:52 UTC (permalink / raw)
To: jgarzik@pobox.com, linux-ide@vger.kernel.org
Cc: Bhartiya Anju-B07263, linuxppc-dev@lists.ozlabs.org,
linux-kernel@vger.kernel.org, Xie Shaohui-B21989
In-Reply-To: <1347331734-6540-1-git-send-email-Shaohui.Xie@freescale.com>
Hi,
Any comment for this patch? It's been over a month...
Best Regards,=20
Shaohui Xie
> -----Original Message-----
> From: Xie Shaohui-B21989
> Sent: Tuesday, September 11, 2012 10:49 AM
> To: jgarzik@pobox.com; linux-ide@vger.kernel.org
> Cc: linuxppc-dev@lists.ozlabs.org; linux-kernel@vger.kernel.org; Xie
> Shaohui-B21989; Bhartiya Anju-B07263
> Subject: [PATCH][v4] sata_fsl: add workaround for data length mismatch on
> freescale V2 controller
>=20
> The freescale V2 SATA controller checks if the received data length
> matches the programmed length 'ttl', if not, it assumes that this is an
> error.
> In ATAPI, the 'ttl' is based on max allocation length and not the actual
> data transfer length, controller will raise 'DLM' (Data length Mismatch)
> error bit in Hstatus register. Along with 'DLM', DE (Device error) and FE
> (fatal Error) bits are also set in Hstatus register, 'E' (Internal Error)
> bit is set in Serror register and CE (Command Error) and DE (Device error=
)
> registers have the corresponding bit set. In this condition, we need to
> clear errors in following way: in the service routine, based on 'DLM'
> flag, HCONTROL[27] operation clears Hstatus, CE and DE registers, clear
> Serror register.
>=20
> Signed-off-by: Shaohui Xie <Shaohui.Xie@freescale.com>
> Signed-off-by: Anju Bhartiya <Anju.Bhartiya@freescale.com>
> ---
> changes for v4:
> 1. put HCONTROL_CLEAR_ERROR to enum and rename it as CLEAR_ERROR;
>=20
> changes for v3:
> 1. not using uppercase for variable names; 2. remove unnecessary parens;
>=20
> changes for v2:
> 1. remove the using of quirk;
> 2. wrap errata codes in condition;
>=20
>=20
> drivers/ata/sata_fsl.c | 39 +++++++++++++++++++++++++++++++++++----
> 1 files changed, 35 insertions(+), 4 deletions(-)
>=20
> diff --git a/drivers/ata/sata_fsl.c b/drivers/ata/sata_fsl.c index
> d6577b9..124b2c1 100644
> --- a/drivers/ata/sata_fsl.c
> +++ b/drivers/ata/sata_fsl.c
> @@ -123,6 +123,7 @@ enum {
> ONLINE =3D (1 << 31),
> GOING_OFFLINE =3D (1 << 30),
> BIST_ERR =3D (1 << 29),
> + CLEAR_ERROR =3D (1 << 27),
>=20
> FATAL_ERR_HC_MASTER_ERR =3D (1 << 18),
> FATAL_ERR_PARITY_ERR_TX =3D (1 << 17),
> @@ -143,6 +144,7 @@ enum {
> FATAL_ERR_CRC_ERR_RX |
> FATAL_ERR_FIFO_OVRFL_TX | FATAL_ERR_FIFO_OVRFL_RX,
>=20
> + INT_ON_DATA_LENGTH_MISMATCH =3D (1 << 12),
> INT_ON_FATAL_ERR =3D (1 << 5),
> INT_ON_PHYRDY_CHG =3D (1 << 4),
>=20
> @@ -1181,25 +1183,54 @@ static void sata_fsl_host_intr(struct ata_port
> *ap)
> u32 hstatus, done_mask =3D 0;
> struct ata_queued_cmd *qc;
> u32 SError;
> + u32 tag;
> + u32 status_mask =3D INT_ON_ERROR;
>=20
> hstatus =3D ioread32(hcr_base + HSTATUS);
>=20
> sata_fsl_scr_read(&ap->link, SCR_ERROR, &SError);
>=20
> + /* Read command completed register */
> + done_mask =3D ioread32(hcr_base + CC);
> +
> + /* Workaround for data length mismatch errata */
> + if (unlikely(hstatus & INT_ON_DATA_LENGTH_MISMATCH)) {
> + for (tag =3D 0; tag < ATA_MAX_QUEUE; tag++) {
> + qc =3D ata_qc_from_tag(ap, tag);
> + if (qc && ata_is_atapi(qc->tf.protocol)) {
> + u32 hcontrol;
> + /* Set HControl[27] to clear error registers */
> + hcontrol =3D ioread32(hcr_base + HCONTROL);
> + iowrite32(hcontrol | CLEAR_ERROR,
> + hcr_base + HCONTROL);
> +
> + /* Clear HControl[27] */
> + iowrite32(hcontrol & ~CLEAR_ERROR,
> + hcr_base + HCONTROL);
> +
> + /* Clear SError[E] bit */
> + sata_fsl_scr_write(&ap->link, SCR_ERROR,
> + SError);
> +
> + /* Ignore fatal error and device error */
> + status_mask &=3D ~(INT_ON_SINGL_DEVICE_ERR
> + | INT_ON_FATAL_ERR);
> + break;
> + }
> + }
> + }
> +
> if (unlikely(SError & 0xFFFF0000)) {
> DPRINTK("serror @host_intr : 0x%x\n", SError);
> sata_fsl_error_intr(ap);
> }
>=20
> - if (unlikely(hstatus & INT_ON_ERROR)) {
> + if (unlikely(hstatus & status_mask)) {
> DPRINTK("error interrupt!!\n");
> sata_fsl_error_intr(ap);
> return;
> }
>=20
> - /* Read command completed register */
> - done_mask =3D ioread32(hcr_base + CC);
> -
> VPRINTK("Status of all queues :\n");
> VPRINTK("done_mask/CC =3D 0x%x, CA =3D 0x%x,
> CE=3D0x%x,CQ=3D0x%x,apqa=3D0x%x\n",
> done_mask,
> --
> 1.6.4
^ permalink raw reply
* Re: [PATCH -V8 04/11] arch/powerpc: Convert virtual address to vpn
From: Andreas Schwab @ 2012-10-15 8:51 UTC (permalink / raw)
To: Aneesh Kumar K.V; +Cc: paulus, linuxppc-dev
In-Reply-To: <1346945351-7672-5-git-send-email-aneesh.kumar__43423.5424655073$1346945525$gmane$org@linux.vnet.ibm.com>
"Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com> writes:
> diff --git a/arch/powerpc/kvm/book3s_32_mmu_host.c b/arch/powerpc/kvm/book3s_32_mmu_host.c
> index 837f13e..00aa612 100644
> --- a/arch/powerpc/kvm/book3s_32_mmu_host.c
> +++ b/arch/powerpc/kvm/book3s_32_mmu_host.c
> @@ -141,7 +141,7 @@ extern char etext[];
> int kvmppc_mmu_map_page(struct kvm_vcpu *vcpu, struct kvmppc_pte *orig_pte)
> {
> pfn_t hpaddr;
> - u64 va;
> + u64 vpn;
> u64 vsid;
> struct kvmppc_sid_map *map;
> volatile u32 *pteg;
> @@ -173,7 +173,7 @@ int kvmppc_mmu_map_page(struct kvm_vcpu *vcpu, struct kvmppc_pte *orig_pte)
> BUG_ON(!map);
>
> vsid = map->host_vsid;
> - va = (vsid << SID_SHIFT) | (eaddr & ~ESID_MASK);
> + vpn = (vsid << (SID_SHIFT - VPN_SHIFT)) | ((eaddr & ~ESID_MASK) >> VPN_SHIFT)
Where is VPN_SHIFT? Where is the semicolon?
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: [RFC][PATCH] perf: Add a few generic stalled-cycles events
From: Robert Richter @ 2012-10-15 15:55 UTC (permalink / raw)
To: Sukadev Bhattiprolu
Cc: peterz, Anton Blanchard, linux-kernel, eranian, acme,
linuxppc-dev, paulus, mpjohn, mingo, asharma
In-Reply-To: <20121012012839.GA15348@us.ibm.com>
On 11.10.12 18:28:39, Sukadev Bhattiprolu wrote:
> + { .type = PERF_TYPE_HARDWARE, .config = PERF_COUNT_HW_STALLED_CYCLES_FIXED_POINT },
> + { .type = PERF_TYPE_HARDWARE, .config = PERF_COUNT_HW_STALLED_CYCLES_LOAD_STORE },
> + { .type = PERF_TYPE_HARDWARE, .config = PERF_COUNT_HW_STALLED_CYCLES_INSTRUCTION_FETCH },
> + { .type = PERF_TYPE_HARDWARE, .config = PERF_COUNT_HW_STALLED_CYCLES_BRANCH },
Instead of adding new hardware event types I would prefer to use raw
events in conjunction with sysfs, see e.g. the intel-uncore
implementation. Something like:
$ find /sys/bus/event_source/devices/cpu/events/
...
/sys/bus/event_source/devices/cpu/events/stalled-cycles-fixed-point
/sys/bus/event_source/devices/cpu/events/stalled-cycles-load-store
/sys/bus/event_source/devices/cpu/events/stalled-cycles-instruction-fetch
/sys/bus/event_source/devices/cpu/events/stalled-cycles-branch
...
$ cat /sys/bus/event_source/devices/cpu/events/stalled-cycles-fixed-point
event=0xff,umask=0x00
Perf tool works then out-of-the-box with:
$ perf record -e cpu/stalled-cycles-fixed-point/ ...
The event string can easily be reused by other architectures as a
quasi standard.
-Robert
--
Advanced Micro Devices, Inc.
Operating System Research Center
^ permalink raw reply
* Re: [PATCH -V8 04/11] arch/powerpc: Convert virtual address to vpn
From: Aneesh Kumar K.V @ 2012-10-15 16:05 UTC (permalink / raw)
To: Andreas Schwab; +Cc: paulus, linuxppc-dev
In-Reply-To: <m2y5j8qft0.fsf@igel.home>
Andreas Schwab <schwab@linux-m68k.org> writes:
> "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com> writes:
>
>> diff --git a/arch/powerpc/kvm/book3s_32_mmu_host.c b/arch/powerpc/kvm/book3s_32_mmu_host.c
>> index 837f13e..00aa612 100644
>> --- a/arch/powerpc/kvm/book3s_32_mmu_host.c
>> +++ b/arch/powerpc/kvm/book3s_32_mmu_host.c
>> @@ -141,7 +141,7 @@ extern char etext[];
>> int kvmppc_mmu_map_page(struct kvm_vcpu *vcpu, struct kvmppc_pte *orig_pte)
>> {
>> pfn_t hpaddr;
>> - u64 va;
>> + u64 vpn;
>> u64 vsid;
>> struct kvmppc_sid_map *map;
>> volatile u32 *pteg;
>> @@ -173,7 +173,7 @@ int kvmppc_mmu_map_page(struct kvm_vcpu *vcpu, struct kvmppc_pte *orig_pte)
>> BUG_ON(!map);
>>
>> vsid = map->host_vsid;
>> - va = (vsid << SID_SHIFT) | (eaddr & ~ESID_MASK);
>> + vpn = (vsid << (SID_SHIFT - VPN_SHIFT)) | ((eaddr & ~ESID_MASK) >> VPN_SHIFT)
>
> Where is VPN_SHIFT? Where is the semicolon?
I had done a kvm build test with the changes, but missed the fact that
this is !SMP and PPC_BOOK3S_32. Will send a follow up patch.
-aneesh
^ permalink raw reply
* Re: [PATCH 15/25] powerpc/fsl_msi: add a const qualifier
From: Tabi Timur-B04825 @ 2012-10-15 16:14 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Arnd Bergmann, Tabi Timur-B04825, Rob Herring, Paul Mackerras,
kernel@pengutronix.de, linuxppc-dev@lists.ozlabs.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <1343034810-3386-16-git-send-email-u.kleine-koenig@pengutronix.de>
On Mon, Jul 23, 2012 at 4:13 AM, Uwe Kleine-K=F6nig
<u.kleine-koenig@pengutronix.de> wrote:
> This prepares *of_device_id.data becoming const. Without this change
> the following warning would occur:
>
> arch/powerpc/sysdev/fsl_msi.c: In function 'fsl_of_msi_probe':
> arch/powerpc/sysdev/fsl_msi.c:379:11: error: assignment discards =
'const' qualifier from pointer target type [-Werror]
>
> Signed-off-by: Uwe Kleine-K=F6nig <u.kleine-koenig@pengutronix.de>
Acked-by: Timur Tabi <timur@freescale.com>
--=20
Timur Tabi
Linux kernel developer at Freescale=
^ permalink raw reply
* Re: [PATCH -V8 04/11] arch/powerpc: Convert virtual address to vpn
From: Aneesh Kumar K.V @ 2012-10-15 16:28 UTC (permalink / raw)
To: Andreas Schwab; +Cc: paulus, linuxppc-dev
In-Reply-To: <87wqyrpvod.fsf@linux.vnet.ibm.com>
"Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com> writes:
> Andreas Schwab <schwab@linux-m68k.org> writes:
>
>> "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com> writes:
>>
>>> diff --git a/arch/powerpc/kvm/book3s_32_mmu_host.c b/arch/powerpc/kvm/book3s_32_mmu_host.c
>>> index 837f13e..00aa612 100644
>>> --- a/arch/powerpc/kvm/book3s_32_mmu_host.c
>>> +++ b/arch/powerpc/kvm/book3s_32_mmu_host.c
>>> @@ -141,7 +141,7 @@ extern char etext[];
>>> int kvmppc_mmu_map_page(struct kvm_vcpu *vcpu, struct kvmppc_pte *orig_pte)
>>> {
>>> pfn_t hpaddr;
>>> - u64 va;
>>> + u64 vpn;
>>> u64 vsid;
>>> struct kvmppc_sid_map *map;
>>> volatile u32 *pteg;
>>> @@ -173,7 +173,7 @@ int kvmppc_mmu_map_page(struct kvm_vcpu *vcpu, struct kvmppc_pte *orig_pte)
>>> BUG_ON(!map);
>>>
>>> vsid = map->host_vsid;
>>> - va = (vsid << SID_SHIFT) | (eaddr & ~ESID_MASK);
>>> + vpn = (vsid << (SID_SHIFT - VPN_SHIFT)) | ((eaddr & ~ESID_MASK) >> VPN_SHIFT)
>>
>> Where is VPN_SHIFT? Where is the semicolon?
>
> I had done a kvm build test with the changes, but missed the fact that
> this is !SMP and PPC_BOOK3S_32. Will send a follow up patch.
How about the below ? Any help on how to get this tested ?
diff --git a/arch/powerpc/include/asm/kvm_book3s_32.h b/arch/powerpc/include/asm/kvm_book3s_32.h
index 38040ff..ce0ef6c 100644
--- a/arch/powerpc/include/asm/kvm_book3s_32.h
+++ b/arch/powerpc/include/asm/kvm_book3s_32.h
@@ -42,5 +42,6 @@ static inline void svcpu_put(struct kvmppc_book3s_shadow_vcpu *svcpu)
#define SID_SHIFT 28
#define ESID_MASK 0xf0000000
#define VSID_MASK 0x00fffffff0000000ULL
+#define VPN_SHIFT 12
#endif /* __ASM_KVM_BOOK3S_32_H__ */
diff --git a/arch/powerpc/kvm/book3s_32_mmu_host.c b/arch/powerpc/kvm/book3s_32_mmu_host.c
index 00aa612..b0f625a 100644
--- a/arch/powerpc/kvm/book3s_32_mmu_host.c
+++ b/arch/powerpc/kvm/book3s_32_mmu_host.c
@@ -173,8 +173,8 @@ int kvmppc_mmu_map_page(struct kvm_vcpu *vcpu, struct kvmppc_pte *orig_pte)
BUG_ON(!map);
vsid = map->host_vsid;
- vpn = (vsid << (SID_SHIFT - VPN_SHIFT)) | ((eaddr & ~ESID_MASK) >> VPN_SHIFT)
-
+ vpn = (vsid << (SID_SHIFT - VPN_SHIFT)) |
+ ((eaddr & ~ESID_MASK) >> VPN_SHIFT);
next_pteg:
if (rr == 16) {
primary = !primary;
^ permalink raw reply related
* Re: [RFC][PATCH] perf: Add a few generic stalled-cycles events
From: Arun Sharma @ 2012-10-15 17:23 UTC (permalink / raw)
To: Robert Richter
Cc: peterz, Anton Blanchard, linux-kernel, eranian, acme,
linuxppc-dev, paulus, mpjohn, Sukadev Bhattiprolu, mingo
In-Reply-To: <20121015155534.GR8285@erda.amd.com>
On 10/15/12 8:55 AM, Robert Richter wrote:
[..]
> Perf tool works then out-of-the-box with:
>
> $ perf record -e cpu/stalled-cycles-fixed-point/ ...
>
> The event string can easily be reused by other architectures as a
> quasi standard.
I like Robert's proposal better. It's hard to model all the stall events
(eg: instruction decoder related stalls on x86) in a hardware
independent way.
Another area to think about: software engineers are generally busy and
have a limited amount of time to devote to hardware event based
optimizations. The most common question I hear is: what is the expected
perf gain if I fix this? It's hard to answer that with just the stall
events.
-Arun
^ permalink raw reply
* [PATCH 2/2] powerpc/86xx: fsl_pcibios_fixup_bus requires CONFIG_PCI
From: Timur Tabi @ 2012-10-15 19:52 UTC (permalink / raw)
To: Kumar Gala, paul.gortmaker, Anatolij Gustschin, linuxppc-dev
In-Reply-To: <1350330741-11390-1-git-send-email-timur@freescale.com>
Function fsl_pcibios_fixup_bus() is available only if PCI is enabled. The
MPC8610 HPCD platform file was not protecting the assigned with an #ifdef,
which results in a link failure when PCI is disabled. Every other platform
already has this #ifdef.
Signed-off-by: Timur Tabi <timur@freescale.com>
---
arch/powerpc/platforms/86xx/mpc8610_hpcd.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/platforms/86xx/mpc8610_hpcd.c b/arch/powerpc/platforms/86xx/mpc8610_hpcd.c
index a817398..04d9d31 100644
--- a/arch/powerpc/platforms/86xx/mpc8610_hpcd.c
+++ b/arch/powerpc/platforms/86xx/mpc8610_hpcd.c
@@ -353,5 +353,7 @@ define_machine(mpc86xx_hpcd) {
.time_init = mpc86xx_time_init,
.calibrate_decr = generic_calibrate_decr,
.progress = udbg_progress,
+#ifdef CONFIG_PCI
.pcibios_fixup_bus = fsl_pcibios_fixup_bus,
+#endif
};
--
1.7.3.4
^ permalink raw reply related
* [PATCH 1/2] [v2] powerpc/512x: don't compile any platform DIU code if the DIU is not enabled
From: Timur Tabi @ 2012-10-15 19:52 UTC (permalink / raw)
To: Kumar Gala, paul.gortmaker, Anatolij Gustschin, linuxppc-dev
If the DIU framebuffer driver is not enabled, then there's no point in
compiling any platform DIU code, because it will never be used. Most of
the platform code was protected in the appropriate #ifdef, but not all.
This caused a break in some randconfig builds.
This is only a problem on the 512x platforms. The P1022DS and MPC8610HPCD
platforms are already correct.
This patch reverts commit 12e36309f8774f4ccc769d5e3ff11ef092e524bc ("powerpc:
Option FB_FSL_DIU is not really optional for mpc512x") and restores the
ability to configure DIU support.
Signed-off-by: Timur Tabi <timur@freescale.com>
---
arch/powerpc/platforms/512x/Kconfig | 1 -
arch/powerpc/platforms/512x/mpc5121_ads.c | 3 +++
arch/powerpc/platforms/512x/mpc512x.h | 11 +++++++++--
arch/powerpc/platforms/512x/mpc512x_shared.c | 25 ++++---------------------
4 files changed, 16 insertions(+), 24 deletions(-)
diff --git a/arch/powerpc/platforms/512x/Kconfig b/arch/powerpc/platforms/512x/Kconfig
index b62508b..c169998 100644
--- a/arch/powerpc/platforms/512x/Kconfig
+++ b/arch/powerpc/platforms/512x/Kconfig
@@ -2,7 +2,6 @@ config PPC_MPC512x
bool "512x-based boards"
depends on 6xx
select FSL_SOC
- select FB_FSL_DIU
select IPIC
select PPC_CLOCK
select PPC_PCI_CHOICE
diff --git a/arch/powerpc/platforms/512x/mpc5121_ads.c b/arch/powerpc/platforms/512x/mpc5121_ads.c
index dcef6ad..0a134e0 100644
--- a/arch/powerpc/platforms/512x/mpc5121_ads.c
+++ b/arch/powerpc/platforms/512x/mpc5121_ads.c
@@ -42,7 +42,10 @@ static void __init mpc5121_ads_setup_arch(void)
for_each_compatible_node(np, "pci", "fsl,mpc5121-pci")
mpc83xx_add_bridge(np);
#endif
+
+#if defined(CONFIG_FB_FSL_DIU) || defined(CONFIG_FB_FSL_DIU_MODULE)
mpc512x_setup_diu();
+#endif
}
static void __init mpc5121_ads_init_IRQ(void)
diff --git a/arch/powerpc/platforms/512x/mpc512x.h b/arch/powerpc/platforms/512x/mpc512x.h
index 1ab6d11..c32b399 100644
--- a/arch/powerpc/platforms/512x/mpc512x.h
+++ b/arch/powerpc/platforms/512x/mpc512x.h
@@ -16,6 +16,13 @@ extern void __init mpc512x_init(void);
extern int __init mpc5121_clk_init(void);
void __init mpc512x_declare_of_platform_devices(void);
extern void mpc512x_restart(char *cmd);
-extern void mpc512x_init_diu(void);
-extern void mpc512x_setup_diu(void);
+
+#if defined(CONFIG_FB_FSL_DIU) || defined(CONFIG_FB_FSL_DIU_MODULE)
+void mpc512x_init_diu(void);
+void mpc512x_setup_diu(void);
+#else
+#define mpc512x_init_diu NULL
+#define mpc512x_setup_diu NULL
+#endif
+
#endif /* __MPC512X_H__ */
diff --git a/arch/powerpc/platforms/512x/mpc512x_shared.c b/arch/powerpc/platforms/512x/mpc512x_shared.c
index 1650e09..35f14fd 100644
--- a/arch/powerpc/platforms/512x/mpc512x_shared.c
+++ b/arch/powerpc/platforms/512x/mpc512x_shared.c
@@ -58,6 +58,8 @@ void mpc512x_restart(char *cmd)
;
}
+#if defined(CONFIG_FB_FSL_DIU) || defined(CONFIG_FB_FSL_DIU_MODULE)
+
struct fsl_diu_shared_fb {
u8 gamma[0x300]; /* 32-bit aligned! */
struct diu_ad ad0; /* 32-bit aligned! */
@@ -66,25 +68,6 @@ struct fsl_diu_shared_fb {
bool in_use;
};
-u32 mpc512x_get_pixel_format(enum fsl_diu_monitor_port port,
- unsigned int bits_per_pixel)
-{
- switch (bits_per_pixel) {
- case 32:
- return 0x88883316;
- case 24:
- return 0x88082219;
- case 16:
- return 0x65053118;
- }
- return 0x00000400;
-}
-
-void mpc512x_set_gamma_table(enum fsl_diu_monitor_port port,
- char *gamma_table_base)
-{
-}
-
void mpc512x_set_monitor_port(enum fsl_diu_monitor_port port)
{
}
@@ -320,14 +303,14 @@ void __init mpc512x_setup_diu(void)
}
}
- diu_ops.get_pixel_format = mpc512x_get_pixel_format;
- diu_ops.set_gamma_table = mpc512x_set_gamma_table;
diu_ops.set_monitor_port = mpc512x_set_monitor_port;
diu_ops.set_pixel_clock = mpc512x_set_pixel_clock;
diu_ops.valid_monitor_port = mpc512x_valid_monitor_port;
diu_ops.release_bootmem = mpc512x_release_bootmem;
}
+#endif
+
void __init mpc512x_init_IRQ(void)
{
struct device_node *np;
--
1.7.3.4
^ permalink raw reply related
* [PATCH] kvm/powerpc: Handle errors in secondary thread grabbing
From: Michael Ellerman @ 2012-10-16 0:15 UTC (permalink / raw)
To: linuxppc-dev, kvm-ppc; +Cc: Paul Mackerras
In the Book3s HV code, kvmppc_run_core() has logic to grab the secondary
threads of the physical core.
If for some reason a thread is stuck, kvmppc_grab_hwthread() can fail,
but currently we ignore the failure and continue into the guest. If the
stuck thread is in the kernel badness ensues.
Instead we should check for failure and bail out.
I've moved the grabbing prior to the startup of runnable threads, to simplify
the error case. AFAICS this is harmless, but I could be missing something
subtle.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
Or we could just BUG_ON() ?
---
arch/powerpc/kvm/book3s_hv.c | 22 ++++++++++++++++++----
1 file changed, 18 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
index 721d460..55925cd 100644
--- a/arch/powerpc/kvm/book3s_hv.c
+++ b/arch/powerpc/kvm/book3s_hv.c
@@ -884,16 +884,30 @@ static int kvmppc_run_core(struct kvmppc_vcore *vc)
if (vcpu->arch.ceded)
vcpu->arch.ptid = ptid++;
+ /*
+ * Grab any remaining hw threads so they can't go into the kernel.
+ * Do this early to simplify the cleanup path if it fails.
+ */
+ for (i = ptid; i < threads_per_core; ++i) {
+ int j, rc = kvmppc_grab_hwthread(vc->pcpu + i);
+ if (rc) {
+ for (j = i - 1; j ; j--)
+ kvmppc_release_hwthread(vc->pcpu + j);
+
+ list_for_each_entry(vcpu, &vc->runnable_threads,
+ arch.run_list)
+ vcpu->arch.ret = -EBUSY;
+
+ goto out;
+ }
+ }
+
vc->stolen_tb += mftb() - vc->preempt_tb;
vc->pcpu = smp_processor_id();
list_for_each_entry(vcpu, &vc->runnable_threads, arch.run_list) {
kvmppc_start_thread(vcpu);
kvmppc_create_dtl_entry(vcpu, vc);
}
- /* Grab any remaining hw threads so they can't go into the kernel */
- for (i = ptid; i < threads_per_core; ++i)
- kvmppc_grab_hwthread(vc->pcpu + i);
-
preempt_disable();
spin_unlock(&vc->lock);
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH] kvm/powerpc: Handle errors in secondary thread grabbing
From: Paul Mackerras @ 2012-10-16 3:13 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev, kvm-ppc
In-Reply-To: <1350346550-32539-1-git-send-email-michael@ellerman.id.au>
Michael,
On Tue, Oct 16, 2012 at 11:15:50AM +1100, Michael Ellerman wrote:
> In the Book3s HV code, kvmppc_run_core() has logic to grab the secondary
> threads of the physical core.
>
> If for some reason a thread is stuck, kvmppc_grab_hwthread() can fail,
> but currently we ignore the failure and continue into the guest. If the
> stuck thread is in the kernel badness ensues.
>
> Instead we should check for failure and bail out.
>
> I've moved the grabbing prior to the startup of runnable threads, to simplify
> the error case. AFAICS this is harmless, but I could be missing something
> subtle.
Thanks for looking at this - but in fact this is fixed by my patch
entitled "KVM: PPC: Book3S HV: Fix some races in starting secondary
threads" submitted back on August 28.
Regards,
Paul.
^ permalink raw reply
* Re: [RFC][PATCH] perf: Add a few generic stalled-cycles events
From: Anshuman Khandual @ 2012-10-16 5:28 UTC (permalink / raw)
To: Arun Sharma
Cc: linuxppc-dev, Robert Richter, Anton Blanchard, linux-kernel,
eranian, acme, peterz, paulus, mpjohn, Sukadev Bhattiprolu, mingo
In-Reply-To: <507C467E.8010205@fb.com>
On 10/15/2012 10:53 PM, Arun Sharma wrote:
> On 10/15/12 8:55 AM, Robert Richter wrote:
>
> [..]
>> Perf tool works then out-of-the-box with:
>>
>> $ perf record -e cpu/stalled-cycles-fixed-point/ ...
>>
>> The event string can easily be reused by other architectures as a
>> quasi standard.
>
> I like Robert's proposal better. It's hard to model all the stall events
> (eg: instruction decoder related stalls on x86) in a hardware
> independent way.
>
> Another area to think about: software engineers are generally busy and
> have a limited amount of time to devote to hardware event based
> optimizations. The most common question I hear is: what is the expected
> perf gain if I fix this? It's hard to answer that with just the stall
> events.
>
Hardware event based optimization is a very important aspect of real world application
tuning. CPI stack analysis is a good reason why perf should have stall events as generic
ones. But I am not clear on situations where we consider adding these new generic events
into linux/perf_event.h and the situations where we should go with the sys fs interface.
Could you please elaborate on this ?
Regards
Anshuman
^ permalink raw reply
* Re: [PATCH] kvm/powerpc: Handle errors in secondary thread grabbing
From: Michael Ellerman @ 2012-10-16 6:00 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, agraf, kvm-ppc
In-Reply-To: <20121016031352.GK1218@drongo>
On Tue, 2012-10-16 at 14:13 +1100, Paul Mackerras wrote:
> Michael,
>
> On Tue, Oct 16, 2012 at 11:15:50AM +1100, Michael Ellerman wrote:
> > In the Book3s HV code, kvmppc_run_core() has logic to grab the secondary
> > threads of the physical core.
> >
> > If for some reason a thread is stuck, kvmppc_grab_hwthread() can fail,
> > but currently we ignore the failure and continue into the guest. If the
> > stuck thread is in the kernel badness ensues.
> >
> > Instead we should check for failure and bail out.
> >
> > I've moved the grabbing prior to the startup of runnable threads, to simplify
> > the error case. AFAICS this is harmless, but I could be missing something
> > subtle.
>
> Thanks for looking at this - but in fact this is fixed by my patch
> entitled "KVM: PPC: Book3S HV: Fix some races in starting secondary
> threads" submitted back on August 28.
OK thanks. It seems that patch didn't make 3.7 ?
I don't see it in kvm-ppc-next either.
cheers
^ permalink raw reply
* Re: [m68k,powerpc,dma,ethernet,freescale RFA] Coldfire m54xx FEC ethernet driver
From: Greg Ungerer @ 2012-10-16 6:39 UTC (permalink / raw)
To: Philippe De Muyter
Cc: uClinux development list, netdev, linux-kernel, linux-m68k,
stany.marcel, linuxppc-dev
In-Reply-To: <20121009090758.GA14142@frolo.macqel>
Hi Philippe,
On 09/10/12 19:07, Philippe De Muyter wrote:
> [CCing lkml, linux-ppc, netdev, linux-m68k]
>
> Hello kernel sources architects
>
> I have a working driver for the m54xx FEC ethernet driver that I
> would like to integrate in the kernel tree. Problems are that
> - this driver needs an associated DMA driver (provided by FreeScale)
> wich is not dma-engine enabled
> - they're are already many fec drivers in the kernel tree, and
> at least one, fec_mpc52xx.c, seems to be very similar (information
> below), to the one for the mcf54xx, except it uses a differently
> named associated DMA driver (BestComm/SmartDma/SDMA) which is also
> not dma-engine enabled, and even kept hidden in /arch/powerpc where
> it is inaccessible when compiling for m68k. The underlying DMA part
> from Freescale however seems similar to the one used in the
> m54xx. (again, see information below)
>
> So, now I am lost, what should I do ?
>
> The current state of my patches
> [http://mailman.uclinux.org/pipermail/uclinux-dev/2012-September/052147.html]
> is pushing the freescale provided MCD_DMA dma driver to /drivers/dma,
> without adding the dma-engine compatibility layer, and adding the specific
> fec_m54xx ethernet driver to /drivers/net/ethernet/freescale
Do you get any responses?
I didn't see any...
Regards
Greg
> On Tue, Oct 09, 2012 at 04:12:44PM +1000, Greg Ungerer wrote:
>> Hi Philippe,
>>
>> On 05/10/12 01:03, Philippe De Muyter wrote:
>>> On Thu, Oct 04, 2012 at 04:56:01PM +0200, Philippe De Muyter wrote:
>>>> On Thu, Oct 04, 2012 at 11:33:32PM +1000, Greg Ungerer wrote:
>>>>>
>>>>> My biggest concern is the amount of MCD/DMA support code. And it is
>>>>> all done quite differently to everything else in the kernel. We may
>>>>> get a bit of push back from kernel folk who look after DMA.
>>>>
>>>> Actually, there is already a similar code in arch/powerpc/sysdev/bestcomm
>>>> (also from freescale, maybe an identical part, but I did not find any
>>>> usable doc), but the powerpc folks kept that hidden in the arch/powerpc
>>>> tree, instead of installing it in drivers/dma.
>>>
>>> The MCD DMA or DMA FEC code from freescale has a comment implying that
>>> this
>>> was first used in the MPC8220 part. And Montavista has a MPC8220 port,
>>> but
>>> I did not find it, so I do not know where they installed the MCD DMA
>>> driver.
>>
>> Ok, looks like there is a bit a variance in all this.
>
> I also began to read the mpc5200 user's guide parts about the fec and
> BestComm/SmartDma/SDMA (not sure which one is the official FreeScale name)
> and they look very similar, but not identical, to their m54xx counterparts.
>
> It seems possible to make the fec_mpc52xx.c driver work for the m54xx
> but that needs at least:
> - moving some files or part of them from /arch/powerpc/sysdev and
> /arch/powerpc/include/asm to /drivers/dma and /include/linux,
> - renaming the fec_mpc52xx files to a more sensible name,
> - providing out_be32 and in_be32 in /arch/m68k/include/asm/io.h,
> - and then unifying the interface to BestComm/SmartDma/SDMA and MCD_DMA
> in mcf_52xx.c.
>
> An additional problem is that the freescale docs for powerpcs and for
> coldfires do not use the same mnemonics for the same registers.
>
> e.g. FEC registers
> offset MPC5200 MCF5484
> ====== ======= =======
> 000 FEC_ID n/a
> 004 IEVENT EIR
> 008 IMASK EIMR
> 010 R_DES_ACTIVE n/a
> 014 X_DES_ACTIVE n/a
> 024 ECNTRL ECR
> 040 MII_DATA MDATA
> 044 MII_SPEED MSCR
> 064 MIB_CONTROL MIBC
> 084 R_CNTRL RCR
> 088 R_HASH RHR
> 0C4 X_CNTRL TCR
> 0E4 PADDR1 PALR
> 0E8 PADDR2 PAHR
> 0EC OP_PAUSE OPD
> 118 IADDR1 IAUR
> 11C IADDR1 IALR
> 120 GADDR1 GAUR
> 124 GADDR2 GALR
> 144 X_WMRK FECTFWR
> 184 RFIFO_DATA FECRFDR
> 188 RFIFO_STATUS FECRFSR
> 18C RFIFO_CONTROL FECRFCR
> 190 RFIFO_LRF_PTR FECRLRFP
> 194 RFIFO_LWF_PTR FECRLWFP
> 198 RFIFO_ALARM FECRFAR
> 19C RFIFO_RDPTR FECRFRP
> 1A0 RFIFO_WRPTR FECRFWP
> 1A4 TFIFO_DATA FECTFDR
> 1A8 TFIFO_STATUS FECTFSR
> 1AC TFIFO_CONTROL FECTFCR
> 1B0 TFIFO_LRF_PTR FECTLRFP
> 1B4 TFIFO_LWF_PTR FECTLWFP
> 1B8 TFIFO_ALARM FECTFAR
> 1BC TFIFO_RDPTR FECTFRP
> 1C0 TFIFO_WRPTR FECTFWP
> 1C4 RESET_CNTRL FECFRST
> 1C8 XMIT_FSM FECCTCWR
>
>> Probably the best thing to do is post the patches on the linux kernel
>> mailing list then, asking for direction on a dma driver.
>>
>> I have no problem with it going into the arch/m68k area. So that is
>> always an option.
>
> For the dma engines, the similarity is also obvious. For example, find
> below side by side mpc52xx and m54xx definitions for the
> main DMA registers :
>
> from mpc52xx.h from MCD_dma.h
> /* SDMA */ /* MCD_DMA */
> struct mpc52xx_sdma { struct dmaRegs {
> u32 taskBar; /* 0x00 */ u32 taskbar;
> u32 currentPointer; /* 0x04 */ u32 currPtr;
> u32 endPointer; /* 0x08 */ u32 endPtr;
> u32 variablePointer; /* 0x0c */ u32 varTablePtr;
>
> u8 IntVect1; /* 0x10 */ u16 dma_rsvd0;
> u8 IntVect2; /* 0x11 */
> u16 PtdCntrl; /* 0x12 */ u16 ptdControl;
>
> u32 IntPend; /* 0x14 */ u32 intPending;
> u32 IntMask; /* 0x18 */ u32 intMask;
>
> u16 tcr[16]; /* 0x1c .. 0x3a */ u16 taskControl[16];
>
> u8 ipr[32]; /* 0x3c .. 0x5b */ u8 priority[32];
>
> u32 cReqSelect; /* 0x5c */ u32 initiatorMux;
> u32 task_size0; /* 0x60 */ u32 taskSize0;
> u32 task_size1; /* 0x64 */ u32 taskSize1;
> u32 MDEDebug; /* 0x68 */ u32 dma_rsvd1;
> u32 ADSDebug; /* 0x6c */ u32 dma_rsvd2;
> u32 Value1; /* 0x70 */ u32 debugComp1;
> u32 Value2; /* 0x74 */ u32 debugComp2;
> u32 Control; /* 0x78 */ u32 debugControl;
> u32 Status; /* 0x7c */ u32 debugStatus;
> u32 PTDDebug; /* 0x80 */ u32 ptdDebug;
> }; };
>
>
>
>
--
------------------------------------------------------------------------
Greg Ungerer -- Principal Engineer EMAIL: gerg@snapgear.com
SnapGear Group, McAfee PHONE: +61 7 3435 2888
8 Gardner Close FAX: +61 7 3217 5323
Milton, QLD, 4064, Australia WEB: http://www.SnapGear.com
^ permalink raw reply
* Re: [m68k,powerpc,dma,ethernet,freescale RFA] Coldfire m54xx FEC ethernet driver
From: Philippe De Muyter @ 2012-10-16 8:03 UTC (permalink / raw)
To: Greg Ungerer
Cc: uClinux development list, netdev, linux-kernel, linux-m68k,
stany.marcel, linuxppc-dev
In-Reply-To: <507D0109.1010103@snapgear.com>
Hi Greg,
On Tue, Oct 16, 2012 at 04:39:05PM +1000, Greg Ungerer wrote:
> Hi Philippe,
>
> On 09/10/12 19:07, Philippe De Muyter wrote:
>> [CCing lkml, linux-ppc, netdev, linux-m68k]
>>
>> Hello kernel sources architects
>>
>> I have a working driver for the m54xx FEC ethernet driver that I
>> would like to integrate in the kernel tree. Problems are that
>> - this driver needs an associated DMA driver (provided by FreeScale)
>> wich is not dma-engine enabled
>> - they're are already many fec drivers in the kernel tree, and
>> at least one, fec_mpc52xx.c, seems to be very similar (information
>> below), to the one for the mcf54xx, except it uses a differently
>> named associated DMA driver (BestComm/SmartDma/SDMA) which is also
>> not dma-engine enabled, and even kept hidden in /arch/powerpc where
>> it is inaccessible when compiling for m68k. The underlying DMA part
>> from Freescale however seems similar to the one used in the
>> m54xx. (again, see information below)
>>
>> So, now I am lost, what should I do ?
>>
>> The current state of my patches
>> [http://mailman.uclinux.org/pipermail/uclinux-dev/2012-September/052147.html]
>> is pushing the freescale provided MCD_DMA dma driver to /drivers/dma,
>> without adding the dma-engine compatibility layer, and adding the specific
>> fec_m54xx ethernet driver to /drivers/net/ethernet/freescale
>
> Do you get any responses?
> I didn't see any...
No, and none also about my simpler patch moving arch/powerpc/sysdev/bestcomm
to drivers/dma/bestcomm (except a private and useful one telling me how to
set '-M' option as default for 'git format-patch'), but at least this simpler
patch seems to be in a wait bucket at
http://patchwork.ozlabs.org/project/linuxppc-dev/list/.
Regards
Philippe
PS: -M as default for 'git format-patch':
put
[diff]
renames = true
in .git/config
>
> Regards
> Greg
>
>
>
>> On Tue, Oct 09, 2012 at 04:12:44PM +1000, Greg Ungerer wrote:
>>> Hi Philippe,
>>>
>>> On 05/10/12 01:03, Philippe De Muyter wrote:
>>>> On Thu, Oct 04, 2012 at 04:56:01PM +0200, Philippe De Muyter wrote:
>>>>> On Thu, Oct 04, 2012 at 11:33:32PM +1000, Greg Ungerer wrote:
>>>>>>
>>>>>> My biggest concern is the amount of MCD/DMA support code. And it is
>>>>>> all done quite differently to everything else in the kernel. We may
>>>>>> get a bit of push back from kernel folk who look after DMA.
>>>>>
>>>>> Actually, there is already a similar code in
>>>>> arch/powerpc/sysdev/bestcomm
>>>>> (also from freescale, maybe an identical part, but I did not find any
>>>>> usable doc), but the powerpc folks kept that hidden in the arch/powerpc
>>>>> tree, instead of installing it in drivers/dma.
>>>>
>>>> The MCD DMA or DMA FEC code from freescale has a comment implying that
>>>> this
>>>> was first used in the MPC8220 part. And Montavista has a MPC8220 port,
>>>> but
>>>> I did not find it, so I do not know where they installed the MCD DMA
>>>> driver.
>>>
>>> Ok, looks like there is a bit a variance in all this.
>>
>> I also began to read the mpc5200 user's guide parts about the fec and
>> BestComm/SmartDma/SDMA (not sure which one is the official FreeScale name)
>> and they look very similar, but not identical, to their m54xx
>> counterparts.
>>
>> It seems possible to make the fec_mpc52xx.c driver work for the m54xx
>> but that needs at least:
>> - moving some files or part of them from /arch/powerpc/sysdev and
>> /arch/powerpc/include/asm to /drivers/dma and /include/linux,
>> - renaming the fec_mpc52xx files to a more sensible name,
>> - providing out_be32 and in_be32 in /arch/m68k/include/asm/io.h,
>> - and then unifying the interface to BestComm/SmartDma/SDMA and MCD_DMA
>> in mcf_52xx.c.
>>
>> An additional problem is that the freescale docs for powerpcs and for
>> coldfires do not use the same mnemonics for the same registers.
>>
>> e.g. FEC registers
>> offset MPC5200 MCF5484
>> ====== ======= =======
>> 000 FEC_ID n/a
>> 004 IEVENT EIR
>> 008 IMASK EIMR
>> 010 R_DES_ACTIVE n/a
>> 014 X_DES_ACTIVE n/a
>> 024 ECNTRL ECR
>> 040 MII_DATA MDATA
>> 044 MII_SPEED MSCR
>> 064 MIB_CONTROL MIBC
>> 084 R_CNTRL RCR
>> 088 R_HASH RHR
>> 0C4 X_CNTRL TCR
>> 0E4 PADDR1 PALR
>> 0E8 PADDR2 PAHR
>> 0EC OP_PAUSE OPD
>> 118 IADDR1 IAUR
>> 11C IADDR1 IALR
>> 120 GADDR1 GAUR
>> 124 GADDR2 GALR
>> 144 X_WMRK FECTFWR
>> 184 RFIFO_DATA FECRFDR
>> 188 RFIFO_STATUS FECRFSR
>> 18C RFIFO_CONTROL FECRFCR
>> 190 RFIFO_LRF_PTR FECRLRFP
>> 194 RFIFO_LWF_PTR FECRLWFP
>> 198 RFIFO_ALARM FECRFAR
>> 19C RFIFO_RDPTR FECRFRP
>> 1A0 RFIFO_WRPTR FECRFWP
>> 1A4 TFIFO_DATA FECTFDR
>> 1A8 TFIFO_STATUS FECTFSR
>> 1AC TFIFO_CONTROL FECTFCR
>> 1B0 TFIFO_LRF_PTR FECTLRFP
>> 1B4 TFIFO_LWF_PTR FECTLWFP
>> 1B8 TFIFO_ALARM FECTFAR
>> 1BC TFIFO_RDPTR FECTFRP
>> 1C0 TFIFO_WRPTR FECTFWP
>> 1C4 RESET_CNTRL FECFRST
>> 1C8 XMIT_FSM FECCTCWR
>>
>>> Probably the best thing to do is post the patches on the linux kernel
>>> mailing list then, asking for direction on a dma driver.
>>>
>>> I have no problem with it going into the arch/m68k area. So that is
>>> always an option.
>>
>> For the dma engines, the similarity is also obvious. For example, find
>> below side by side mpc52xx and m54xx definitions for the
>> main DMA registers :
>>
>> from mpc52xx.h from MCD_dma.h
>> /* SDMA */ /* MCD_DMA */
>> struct mpc52xx_sdma { struct dmaRegs {
>> u32 taskBar; /* 0x00 */ u32 taskbar;
>> u32 currentPointer; /* 0x04 */ u32 currPtr;
>> u32 endPointer; /* 0x08 */ u32 endPtr;
>> u32 variablePointer; /* 0x0c */ u32 varTablePtr;
>>
>> u8 IntVect1; /* 0x10 */ u16 dma_rsvd0;
>> u8 IntVect2; /* 0x11 */
>> u16 PtdCntrl; /* 0x12 */ u16 ptdControl;
>>
>> u32 IntPend; /* 0x14 */ u32 intPending;
>> u32 IntMask; /* 0x18 */ u32 intMask;
>>
>> u16 tcr[16]; /* 0x1c .. 0x3a */ u16 taskControl[16];
>>
>> u8 ipr[32]; /* 0x3c .. 0x5b */ u8 priority[32];
>>
>> u32 cReqSelect; /* 0x5c */ u32 initiatorMux;
>> u32 task_size0; /* 0x60 */ u32 taskSize0;
>> u32 task_size1; /* 0x64 */ u32 taskSize1;
>> u32 MDEDebug; /* 0x68 */ u32 dma_rsvd1;
>> u32 ADSDebug; /* 0x6c */ u32 dma_rsvd2;
>> u32 Value1; /* 0x70 */ u32 debugComp1;
>> u32 Value2; /* 0x74 */ u32 debugComp2;
>> u32 Control; /* 0x78 */ u32 debugControl;
>> u32 Status; /* 0x7c */ u32 debugStatus;
>> u32 PTDDebug; /* 0x80 */ u32 ptdDebug;
>> }; };
^ permalink raw reply
* Re: [RFC][PATCH] perf: Add a few generic stalled-cycles events
From: Robert Richter @ 2012-10-16 10:08 UTC (permalink / raw)
To: Sukadev Bhattiprolu
Cc: peterz, Anton Blanchard, linux-kernel, eranian, acme,
linuxppc-dev, paulus, mpjohn, mingo, asharma
In-Reply-To: <20121015155534.GR8285@erda.amd.com>
Sukadev,
On 15.10.12 17:55:34, Robert Richter wrote:
> On 11.10.12 18:28:39, Sukadev Bhattiprolu wrote:
> > + { .type = PERF_TYPE_HARDWARE, .config = PERF_COUNT_HW_STALLED_CYCLES_FIXED_POINT },
> > + { .type = PERF_TYPE_HARDWARE, .config = PERF_COUNT_HW_STALLED_CYCLES_LOAD_STORE },
> > + { .type = PERF_TYPE_HARDWARE, .config = PERF_COUNT_HW_STALLED_CYCLES_INSTRUCTION_FETCH },
> > + { .type = PERF_TYPE_HARDWARE, .config = PERF_COUNT_HW_STALLED_CYCLES_BRANCH },
>
> Instead of adding new hardware event types I would prefer to use raw
> events in conjunction with sysfs, see e.g. the intel-uncore
> implementation. Something like:
>
> $ find /sys/bus/event_source/devices/cpu/events/
> ...
> /sys/bus/event_source/devices/cpu/events/stalled-cycles-fixed-point
> /sys/bus/event_source/devices/cpu/events/stalled-cycles-load-store
> /sys/bus/event_source/devices/cpu/events/stalled-cycles-instruction-fetch
> /sys/bus/event_source/devices/cpu/events/stalled-cycles-branch
> ...
> $ cat /sys/bus/event_source/devices/cpu/events/stalled-cycles-fixed-point
> event=0xff,umask=0x00
>
> Perf tool works then out-of-the-box with:
>
> $ perf record -e cpu/stalled-cycles-fixed-point/ ...
I refer here to arch/x86/kernel/cpu/perf_event_intel_uncore.c (should
be in v3.7-rc1 or tip:perf/core). See the INTEL_UNCORE_EVENT_DESC()
macro and 'if (type->event_descs) ...' in uncore_type_init(). The code
should be reworked to be non-architectural.
PMU registration is implemented for a longer time already for all
architectures and pmu types:
/sys/bus/event_source/devices/*
But
/sys/bus/event_source/devices/*/events/
exists only for a small number of pmus. Perf tool support of this was
implemented with:
a6146d5 perf/tool: Add PMU event alias support
-Robert
--
Advanced Micro Devices, Inc.
Operating System Research Center
^ permalink raw reply
* [PATCH] powerpc: Build fix for powerpc KVM
From: Aneesh Kumar K.V @ 2012-10-16 12:15 UTC (permalink / raw)
To: benh, paulus, schwab; +Cc: linuxppc-dev, Aneesh Kumar K.V
From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
Fix build failure for powerpc KVM
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
---
arch/powerpc/include/asm/kvm_book3s_32.h | 1 +
arch/powerpc/kvm/book3s_32_mmu_host.c | 4 ++--
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/include/asm/kvm_book3s_32.h b/arch/powerpc/include/asm/kvm_book3s_32.h
index 38040ff..ce0ef6c 100644
--- a/arch/powerpc/include/asm/kvm_book3s_32.h
+++ b/arch/powerpc/include/asm/kvm_book3s_32.h
@@ -42,5 +42,6 @@ static inline void svcpu_put(struct kvmppc_book3s_shadow_vcpu *svcpu)
#define SID_SHIFT 28
#define ESID_MASK 0xf0000000
#define VSID_MASK 0x00fffffff0000000ULL
+#define VPN_SHIFT 12
#endif /* __ASM_KVM_BOOK3S_32_H__ */
diff --git a/arch/powerpc/kvm/book3s_32_mmu_host.c b/arch/powerpc/kvm/book3s_32_mmu_host.c
index 00aa612..b0f625a 100644
--- a/arch/powerpc/kvm/book3s_32_mmu_host.c
+++ b/arch/powerpc/kvm/book3s_32_mmu_host.c
@@ -173,8 +173,8 @@ int kvmppc_mmu_map_page(struct kvm_vcpu *vcpu, struct kvmppc_pte *orig_pte)
BUG_ON(!map);
vsid = map->host_vsid;
- vpn = (vsid << (SID_SHIFT - VPN_SHIFT)) | ((eaddr & ~ESID_MASK) >> VPN_SHIFT)
-
+ vpn = (vsid << (SID_SHIFT - VPN_SHIFT)) |
+ ((eaddr & ~ESID_MASK) >> VPN_SHIFT);
next_pteg:
if (rr == 16) {
primary = !primary;
--
1.7.10
^ permalink raw reply related
* Re: [RFC][PATCH] perf: Add a few generic stalled-cycles events
From: Stephane Eranian @ 2012-10-16 12:21 UTC (permalink / raw)
To: Robert Richter
Cc: Peter Zijlstra, Anton Blanchard, LKML, Arnaldo Carvalho de Melo,
linuxppc-dev, Paul Mackerras, mpjohn, Sukadev Bhattiprolu,
Ingo Molnar, Arun Sharma
In-Reply-To: <20121016100809.GS8285@erda.amd.com>
On Tue, Oct 16, 2012 at 12:08 PM, Robert Richter <robert.richter@amd.com> wrote:
> Sukadev,
>
> On 15.10.12 17:55:34, Robert Richter wrote:
>> On 11.10.12 18:28:39, Sukadev Bhattiprolu wrote:
>> > + { .type = PERF_TYPE_HARDWARE, .config = PERF_COUNT_HW_STALLED_CYCLES_FIXED_POINT },
>> > + { .type = PERF_TYPE_HARDWARE, .config = PERF_COUNT_HW_STALLED_CYCLES_LOAD_STORE },
>> > + { .type = PERF_TYPE_HARDWARE, .config = PERF_COUNT_HW_STALLED_CYCLES_INSTRUCTION_FETCH },
>> > + { .type = PERF_TYPE_HARDWARE, .config = PERF_COUNT_HW_STALLED_CYCLES_BRANCH },
>>
>> Instead of adding new hardware event types I would prefer to use raw
>> events in conjunction with sysfs, see e.g. the intel-uncore
>> implementation. Something like:
>>
In general, I don't like generic events and especially stall events. I
have not seen a clear definition of
what they mean. Without it, there is no way to understand how to map
them across architecture. If
the definition is too precise, you may not be able to find an exact
mapping. If the definition is to loose
then it is unclear what you are measuring.
Also this opens another can of worms which is that on some processors,
you may need more than
one event to encapsulate what the generic event is supposed to
measure. That means developing
a lot of code in the kernel to express and manage that. And of course,
you would not be able
to sample on those events (you cannot sample on a difference, for
instance). So all in all, I think
this is not a very good idea. You have to put this into the tool or a
library that auto-detects the
host CPU and programs the right set of events.
We've had that discussion many times. Just reiterating my personal
opinion on this.
>> $ find /sys/bus/event_source/devices/cpu/events/
>> ...
>> /sys/bus/event_source/devices/cpu/events/stalled-cycles-fixed-point
>> /sys/bus/event_source/devices/cpu/events/stalled-cycles-load-store
>> /sys/bus/event_source/devices/cpu/events/stalled-cycles-instruction-fetch
>> /sys/bus/event_source/devices/cpu/events/stalled-cycles-branch
>> ...
>> $ cat /sys/bus/event_source/devices/cpu/events/stalled-cycles-fixed-point
>> event=0xff,umask=0x00
>>
>> Perf tool works then out-of-the-box with:
>>
>> $ perf record -e cpu/stalled-cycles-fixed-point/ ...
>
> I refer here to arch/x86/kernel/cpu/perf_event_intel_uncore.c (should
> be in v3.7-rc1 or tip:perf/core). See the INTEL_UNCORE_EVENT_DESC()
> macro and 'if (type->event_descs) ...' in uncore_type_init(). The code
> should be reworked to be non-architectural.
>
> PMU registration is implemented for a longer time already for all
> architectures and pmu types:
>
> /sys/bus/event_source/devices/*
>
> But
>
> /sys/bus/event_source/devices/*/events/
>
> exists only for a small number of pmus. Perf tool support of this was
> implemented with:
>
> a6146d5 perf/tool: Add PMU event alias support
>
> -Robert
>
> --
> Advanced Micro Devices, Inc.
> Operating System Research Center
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox