* Re: [PATCH v9 12/13] KVM: PPC: Add support for IOMMU in-kernel handling
From: Benjamin Herrenschmidt @ 2013-09-05 4:05 UTC (permalink / raw)
To: Gleb Natapov
Cc: kvm, Alexey Kardashevskiy, Alexander Graf, kvm-ppc, linux-kernel,
linux-mm, Paul Mackerras, Paolo Bonzini, linuxppc-dev,
David Gibson
In-Reply-To: <20130903105315.GY22899@redhat.com>
On Tue, 2013-09-03 at 13:53 +0300, Gleb Natapov wrote:
> > Or supporting all IOMMU links (and leaving emulated stuff as is) in on
> > "device" is the last thing I have to do and then you'll ack the patch?
> >
> I am concerned more about API here. Internal implementation details I
> leave to powerpc experts :)
So Gleb, I want to step in for a bit here.
While I understand that the new KVM device API is all nice and shiny and that this
whole thing should probably have been KVM devices in the first place (had they
existed or had we been told back then), the point is, the API for handling
HW IOMMUs that Alexey is trying to add is an extension of an existing mechanism
used for emulated IOMMUs.
The internal data structure is shared, and fundamentally, by forcing him to
use that new KVM device for the "new stuff", we create a oddball API with
an ioctl for one type of iommu and a KVM device for the other, which makes
the implementation a complete mess in the kernel (and you should care :-)
So for something completely new, I would tend to agree with you. However, I
still think that for this specific case, we should just plonk-in the original
ioctl proposed by Alexey and be done with it.
Cheers,
Ben.
^ permalink raw reply
* [RFC PATCH v2 1/1] powerpc/embedded6xx: Add support for Motorola/Emerson MVME5100.
From: Stephen Chivers @ 2013-09-05 5:51 UTC (permalink / raw)
To: cproctor, schivers, linuxppc-dev, paulus, benh, scottwood
Add support for the Motorola/Emerson MVME5100 Single Board Computer.
The MVME5100 is a 6U form factor VME64 computer with:
- A single MPC7410 or MPC750 CPU
- A HAWK Processor Host Bridge (CPU to PCI) and
MultiProcessor Interrupt Controller (MPIC)
- Up to 500Mb of onboard memory
- A M48T37 Real Time Clock (RTC) and Non-Volatile Memory chip
- Two 16550 compatible UARTS
- Two Intel E100 Fast Ethernets
- Two PCI Mezzanine Card (PMC) Slots
- PPCBug Firmware
The HAWK PHB/MPIC is compatible with the MPC10x devices.
There is no onboard disk support. This is usually provided by
installing a PMC in the first PMC slot.
This patch revives the board support, it was present in early 2.6
series kernels. The board support in those days was by Matt Porter of
MontaVista Software.
CSC Australia has around 31 of these boards in service. The kernel in use
for the boards is based on 2.6.31. The boards are operated without disks
from a file server.
This patch is based on linux-3.11-rc7 and has been boot tested.
V1->V2:
Address comments by Kular Gama and Scott Wood.
Minor adjustment to platforms/embedded6xx/Kconfig to ensure
correct indentation where possible.
Signed-off-by: Stephen Chivers <schivers@csc.com>
---
arch/powerpc/boot/Makefile | 3 +-
arch/powerpc/boot/dts/mvme5100.dts | 186 +++++++++++++++++++++
arch/powerpc/boot/mvme5100.c | 27 +++
arch/powerpc/boot/wrapper | 4 +
arch/powerpc/configs/mvme5100_defconfig | 144 ++++++++++++++++
arch/powerpc/platforms/embedded6xx/Kconfig | 13 ++-
arch/powerpc/platforms/embedded6xx/Makefile | 1 +
arch/powerpc/platforms/embedded6xx/mvme5100.c | 219 +++++++++++++++++++++++++
8 files changed, 595 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index 6a15c96..5626a4e 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -94,7 +94,7 @@ src-plat-$(CONFIG_FSL_SOC_BOOKE) += cuboot-85xx.c cuboot-85xx-cpm2.c
src-plat-$(CONFIG_EMBEDDED6xx) += cuboot-pq2.c cuboot-mpc7448hpc2.c \
cuboot-c2k.c gamecube-head.S \
gamecube.c wii-head.S wii.c holly.c \
- prpmc2800.c
+ prpmc2800.c fixed-head.S mvme5100.c
src-plat-$(CONFIG_AMIGAONE) += cuboot-amigaone.c
src-plat-$(CONFIG_PPC_PS3) += ps3-head.S ps3-hvcall.S ps3.c
src-plat-$(CONFIG_EPAPR_BOOT) += epapr.c
@@ -285,6 +285,7 @@ image-$(CONFIG_MPC7448HPC2) += cuImage.mpc7448hpc2
image-$(CONFIG_PPC_C2K) += cuImage.c2k
image-$(CONFIG_GAMECUBE) += dtbImage.gamecube
image-$(CONFIG_WII) += dtbImage.wii
+image-$(CONFIG_MVME5100) += dtbImage.mvme5100
# Board port in arch/powerpc/platform/amigaone/Kconfig
image-$(CONFIG_AMIGAONE) += cuImage.amigaone
diff --git a/arch/powerpc/boot/dts/mvme5100.dts b/arch/powerpc/boot/dts/mvme5100.dts
new file mode 100644
index 0000000..db345e5
--- /dev/null
+++ b/arch/powerpc/boot/dts/mvme5100.dts
@@ -0,0 +1,186 @@
+/*
+ * Device Tree Souce for Motorola/Emerson MVME5100.
+ *
+ * Copyright 2013 CSC Australia Pty. Ltd.
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without
+ * any warranty of any kind, whether express or implied.
+ */
+
+/dts-v1/;
+
+/ {
+ model = "MVME5100";
+ compatible = "MVME5100";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ aliases {
+ serial0 = &serial0;
+ pci0 = &pci0;
+ };
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ PowerPC,7410 {
+ device_type = "cpu";
+ reg = <0x0>;
+ /* Following required by dtc but not used */
+ d-cache-line-size = <32>;
+ i-cache-line-size = <32>;
+ i-cache-size = <32768>;
+ d-cache-size = <32768>;
+ timebase-frequency = <25000000>;
+ clock-frequency = <500000000>;
+ bus-frequency = <100000000>;
+ };
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <0x0 0x20000000>;
+ };
+
+ hawk@fef80000 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "hawk-bridge", "simple-bus";
+ ranges = <0x0 0xfef80000 0x10000>;
+ reg = <0xfef80000 0x10000>;
+
+ serial0: serial@8000 {
+ device_type = "serial";
+ compatible = "ns16550";
+ reg = <0x8000 0x80>;
+ reg-shift = <4>;
+ clock-frequency = <1843200>;
+ current-speed = <9600>;
+ interrupts = <1 1>; // IRQ1 Level Active Low.
+ interrupt-parent = <&mpic>;
+ };
+
+ serial1: serial@8200 {
+ device_type = "serial";
+ compatible = "ns16550";
+ reg = <0x8200 0x80>;
+ reg-shift = <4>;
+ clock-frequency = <1843200>;
+ current-speed = <9600>;
+ interrupts = <1 1>; // IRQ1 Level Active Low.
+ interrupt-parent = <&mpic>;
+ };
+
+ mpic: interrupt-controller@f3f80000 {
+ #interrupt-cells = <2>;
+ #address-cells = <0>;
+ device_type = "open-pic";
+ compatible = "chrp,open-pic";
+ interrupt-controller;
+ reg = <0xf3f80000 0x40000>;
+ };
+
+ };
+
+ pci0: pci@feff0000 {
+ #address-cells = <3>;
+ #size-cells = <2>;
+ #interrupt-cells = <1>;
+ device_type = "pci";
+ compatible = "hawk-pci";
+ reg = <0xfec00000 0x400000>;
+ 8259-interrupt-acknowledge = <0xfeff0030>;
+ ranges = <0x1000000 0x0 0x0 0xfe000000 0x0 0x800000
+ 0x2000000 0x0 0x80000000 0x80000000 0x0 0x74000000>;
+ bus-range = <0 255>;
+ clock-frequency = <33333333>;
+ interrupt-parent = <&mpic>;
+ interrupt-map-mask = <0xf800 0x0 0x0 0x7>;
+ interrupt-map = <
+
+ /*
+ * This definition (IDSEL 11) duplicates the
+ * interrupts definition in the i8259
+ * interrupt controller below.
+ *
+ * Do not change the interrupt sense/polarity from
+ * 0x2 to anything else, doing so will cause endless
+ * "spurious" i8259 interrupts to be fielded.
+ */
+ // IDSEL 11 - iPMC712 PCI/ISA Bridge
+ 0x5800 0x0 0x0 0x1 &mpic 0x0 0x2
+ 0x5800 0x0 0x0 0x2 &mpic 0x0 0x2
+ 0x5800 0x0 0x0 0x3 &mpic 0x0 0x2
+ 0x5800 0x0 0x0 0x4 &mpic 0x0 0x2
+
+ /* IDSEL 12 - Not Used */
+
+ /* IDSEL 13 - Universe VME Bridge */
+ 0x6800 0x0 0x0 0x1 &mpic 0x5 0x1
+ 0x6800 0x0 0x0 0x2 &mpic 0x6 0x1
+ 0x6800 0x0 0x0 0x3 &mpic 0x7 0x1
+ 0x6800 0x0 0x0 0x4 &mpic 0x8 0x1
+
+ /* IDSEL 14 - ENET 1 */
+ 0x7000 0x0 0x0 0x1 &mpic 0x2 0x1
+
+ /* IDSEL 15 - Not Used */
+
+ /* IDSEL 16 - PMC Slot 1 */
+ 0x8000 0x0 0x0 0x1 &mpic 0x9 0x1
+ 0x8000 0x0 0x0 0x2 &mpic 0xa 0x1
+ 0x8000 0x0 0x0 0x3 &mpic 0xb 0x1
+ 0x8000 0x0 0x0 0x4 &mpic 0xc 0x1
+
+ /* IDSEL 17 - PMC Slot 2 */
+ 0x8800 0x0 0x0 0x1 &mpic 0xc 0x1
+ 0x8800 0x0 0x0 0x2 &mpic 0x9 0x1
+ 0x8800 0x0 0x0 0x3 &mpic 0xa 0x1
+ 0x8800 0x0 0x0 0x4 &mpic 0xb 0x1
+
+ /* IDSEL 18 - Not Used */
+
+ /* IDSEL 19 - ENET 2 */
+ 0x9800 0x0 0x0 0x1 &mpic 0xd 0x1
+
+ /* IDSEL 20 - PMCSPAN (PCI-X) */
+ 0xa000 0x0 0x0 0x1 &mpic 0x9 0x1
+ 0xa000 0x0 0x0 0x2 &mpic 0xa 0x1
+ 0xa000 0x0 0x0 0x3 &mpic 0xb 0x1
+ 0xa000 0x0 0x0 0x4 &mpic 0xc 0x1
+
+ >;
+
+ isa {
+ #address-cells = <2>;
+ #size-cells = <1>;
+ #interrupt-cells = <2>;
+ device_type = "isa";
+ compatible = "isa";
+ ranges = <0x00000001 0 0x01000000 0 0x00000000 0x00001000>;
+ interrupt-parent = <&i8259>;
+
+ i8259: interrupt-controller@20 {
+ #interrupt-cells = <2>;
+ #address-cells = <0>;
+ interrupts = <0 2>;
+ device_type = "interrupt-controller";
+ compatible = "chrp,iic";
+ interrupt-controller;
+ reg = <1 0x00000020 0x00000002
+ 1 0x000000a0 0x00000002
+ 1 0x000004d0 0x00000002>;
+ interrupt-parent = <&mpic>;
+ };
+
+ };
+
+ };
+
+ chosen {
+ linux,stdout-path = &serial0;
+ };
+
+};
diff --git a/arch/powerpc/boot/mvme5100.c b/arch/powerpc/boot/mvme5100.c
new file mode 100644
index 0000000..cb865f8
--- /dev/null
+++ b/arch/powerpc/boot/mvme5100.c
@@ -0,0 +1,27 @@
+/*
+ * Motorola/Emerson MVME5100 with PPCBug firmware.
+ *
+ * Author: Stephen Chivers <schivers@csc.com>
+ *
+ * Copyright 2013 CSC Australia Pty. Ltd.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ */
+#include "types.h"
+#include "ops.h"
+#include "io.h"
+
+BSS_STACK(4096);
+
+void platform_init(unsigned long r3, unsigned long r4, unsigned long r5)
+{
+ u32 heapsize;
+
+ heapsize = 0x8000000 - (u32)_end; /* 128M */
+ simple_alloc_init(_end, heapsize, 32, 64);
+ fdt_init(_dtb_start);
+ serial_console_init();
+}
diff --git a/arch/powerpc/boot/wrapper b/arch/powerpc/boot/wrapper
index 6761c74..9f8cb52 100755
--- a/arch/powerpc/boot/wrapper
+++ b/arch/powerpc/boot/wrapper
@@ -256,6 +256,10 @@ epapr)
link_address='0x20000000'
pie=-pie
;;
+mvme5100)
+ platformo="$object/fixed-head.o $object/mvme5100.o"
+ binary=y
+ ;;
esac
vmz="$tmpdir/`basename \"$kernel\"`.$ext"
diff --git a/arch/powerpc/configs/mvme5100_defconfig b/arch/powerpc/configs/mvme5100_defconfig
new file mode 100644
index 0000000..93c7752
--- /dev/null
+++ b/arch/powerpc/configs/mvme5100_defconfig
@@ -0,0 +1,144 @@
+CONFIG_SYSVIPC=y
+CONFIG_POSIX_MQUEUE=y
+CONFIG_NO_HZ=y
+CONFIG_HIGH_RES_TIMERS=y
+CONFIG_IKCONFIG=y
+CONFIG_IKCONFIG_PROC=y
+CONFIG_LOG_BUF_SHIFT=14
+# CONFIG_UTS_NS is not set
+# CONFIG_IPC_NS is not set
+# CONFIG_PID_NS is not set
+# CONFIG_NET_NS is not set
+CONFIG_CC_OPTIMIZE_FOR_SIZE=y
+# CONFIG_COMPAT_BRK is not set
+CONFIG_MODULES=y
+CONFIG_MODULE_UNLOAD=y
+# CONFIG_BLK_DEV_BSG is not set
+# CONFIG_PPC_CHRP is not set
+# CONFIG_PPC_PMAC is not set
+CONFIG_EMBEDDED6xx=y
+CONFIG_MVME5100=y
+CONFIG_KVM_GUEST=y
+CONFIG_HZ_100=y
+# CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set
+# CONFIG_COMPACTION is not set
+CONFIG_CMDLINE_BOOL=y
+CONFIG_CMDLINE="console=ttyS0,9600 ip=dhcp root=/dev/nfs"
+CONFIG_NET=y
+CONFIG_PACKET=y
+CONFIG_UNIX=y
+CONFIG_INET=y
+CONFIG_IP_MULTICAST=y
+CONFIG_IP_PNP=y
+CONFIG_IP_PNP_DHCP=y
+CONFIG_IP_PNP_BOOTP=y
+# CONFIG_INET_LRO is not set
+# CONFIG_IPV6 is not set
+CONFIG_NETFILTER=y
+CONFIG_NF_CONNTRACK=m
+CONFIG_NF_CT_PROTO_SCTP=m
+CONFIG_NF_CONNTRACK_AMANDA=m
+CONFIG_NF_CONNTRACK_FTP=m
+CONFIG_NF_CONNTRACK_H323=m
+CONFIG_NF_CONNTRACK_IRC=m
+CONFIG_NF_CONNTRACK_NETBIOS_NS=m
+CONFIG_NF_CONNTRACK_PPTP=m
+CONFIG_NF_CONNTRACK_SIP=m
+CONFIG_NF_CONNTRACK_TFTP=m
+CONFIG_NETFILTER_XT_MATCH_MAC=m
+CONFIG_NETFILTER_XT_MATCH_PKTTYPE=m
+CONFIG_NETFILTER_XT_MATCH_STATE=m
+CONFIG_NF_CONNTRACK_IPV4=m
+CONFIG_IP_NF_IPTABLES=m
+CONFIG_IP_NF_FILTER=m
+CONFIG_IP_NF_TARGET_REJECT=m
+CONFIG_IP_NF_MANGLE=m
+CONFIG_IP_NF_TARGET_ECN=m
+CONFIG_IP_NF_TARGET_TTL=m
+CONFIG_IP_NF_RAW=m
+CONFIG_IP_NF_ARPTABLES=m
+CONFIG_IP_NF_ARPFILTER=m
+CONFIG_IP_NF_ARP_MANGLE=m
+CONFIG_LAPB=m
+CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
+CONFIG_PROC_DEVICETREE=y
+CONFIG_BLK_DEV_LOOP=y
+CONFIG_BLK_DEV_RAM=y
+CONFIG_BLK_DEV_RAM_COUNT=2
+CONFIG_BLK_DEV_RAM_SIZE=8192
+CONFIG_EEPROM_LEGACY=m
+CONFIG_NETDEVICES=y
+CONFIG_TUN=m
+# CONFIG_NET_VENDOR_3COM is not set
+CONFIG_E100=y
+# CONFIG_WLAN is not set
+# CONFIG_INPUT_MOUSEDEV_PSAUX is not set
+# CONFIG_INPUT_KEYBOARD is not set
+# CONFIG_INPUT_MOUSE is not set
+# CONFIG_SERIO is not set
+CONFIG_SERIAL_8250=y
+CONFIG_SERIAL_8250_CONSOLE=y
+CONFIG_SERIAL_8250_NR_UARTS=10
+CONFIG_SERIAL_8250_EXTENDED=y
+CONFIG_SERIAL_8250_MANY_PORTS=y
+CONFIG_SERIAL_8250_SHARE_IRQ=y
+CONFIG_SERIAL_OF_PLATFORM=y
+CONFIG_HW_RANDOM=y
+CONFIG_I2C=y
+CONFIG_I2C_CHARDEV=y
+CONFIG_I2C_MPC=y
+# CONFIG_HWMON is not set
+CONFIG_VIDEO_OUTPUT_CONTROL=m
+# CONFIG_VGA_CONSOLE is not set
+# CONFIG_HID is not set
+# CONFIG_USB_SUPPORT is not set
+# CONFIG_IOMMU_SUPPORT is not set
+CONFIG_VME_BUS=m
+CONFIG_VME_CA91CX42=m
+CONFIG_EXT2_FS=m
+CONFIG_EXT3_FS=m
+# CONFIG_EXT3_DEFAULTS_TO_ORDERED is not set
+CONFIG_XFS_FS=m
+CONFIG_ISO9660_FS=m
+CONFIG_JOLIET=y
+CONFIG_ZISOFS=y
+CONFIG_UDF_FS=m
+CONFIG_MSDOS_FS=m
+CONFIG_VFAT_FS=m
+CONFIG_PROC_KCORE=y
+CONFIG_TMPFS=y
+CONFIG_NFS_FS=y
+CONFIG_NFS_V3_ACL=y
+CONFIG_NFS_V4=y
+CONFIG_ROOT_NFS=y
+CONFIG_NFSD=m
+CONFIG_NFSD_V3=y
+CONFIG_CIFS=m
+CONFIG_NLS=y
+CONFIG_NLS_CODEPAGE_437=m
+CONFIG_NLS_CODEPAGE_932=m
+CONFIG_NLS_ISO8859_1=m
+CONFIG_NLS_UTF8=m
+CONFIG_CRC_CCITT=m
+CONFIG_CRC_T10DIF=y
+CONFIG_XZ_DEC=y
+CONFIG_XZ_DEC_X86=y
+CONFIG_XZ_DEC_IA64=y
+CONFIG_XZ_DEC_ARM=y
+CONFIG_XZ_DEC_ARMTHUMB=y
+CONFIG_XZ_DEC_SPARC=y
+CONFIG_MAGIC_SYSRQ=y
+CONFIG_DEBUG_KERNEL=y
+CONFIG_DETECT_HUNG_TASK=y
+CONFIG_DEFAULT_HUNG_TASK_TIMEOUT=20
+CONFIG_CRYPTO_CBC=y
+CONFIG_CRYPTO_PCBC=m
+CONFIG_CRYPTO_MD5=y
+CONFIG_CRYPTO_MICHAEL_MIC=m
+CONFIG_CRYPTO_SHA1=m
+CONFIG_CRYPTO_BLOWFISH=m
+CONFIG_CRYPTO_DES=y
+CONFIG_CRYPTO_SERPENT=m
+CONFIG_CRYPTO_TWOFISH=m
+CONFIG_CRYPTO_DEFLATE=m
+# CONFIG_CRYPTO_ANSI_CPRNG is not set
diff --git a/arch/powerpc/platforms/embedded6xx/Kconfig b/arch/powerpc/platforms/embedded6xx/Kconfig
index 302ba43..c2a9f13 100644
--- a/arch/powerpc/platforms/embedded6xx/Kconfig
+++ b/arch/powerpc/platforms/embedded6xx/Kconfig
@@ -67,6 +67,18 @@ config PPC_C2K
This option enables support for the GE Fanuc C2K board (formerly
an SBS board).
+config MVME5100
+ bool "Motorola/Emerson MVME5100"
+ depends on EMBEDDED6xx
+ select MPIC
+ select PCI
+ select PPC_INDIRECT_PCI
+ select PPC_I8259
+ select PPC_NATIVE
+ help
+ This option enables support for the Motorola (now Emerson) MVME5100
+ board.
+
config TSI108_BRIDGE
bool
select PCI
@@ -113,4 +125,3 @@ config WII
help
Select WII if configuring for the Nintendo Wii.
More information at: <http://gc-linux.sourceforge.net/>
-
diff --git a/arch/powerpc/platforms/embedded6xx/Makefile b/arch/powerpc/platforms/embedded6xx/Makefile
index 66c23e4..cdd48d4 100644
--- a/arch/powerpc/platforms/embedded6xx/Makefile
+++ b/arch/powerpc/platforms/embedded6xx/Makefile
@@ -11,3 +11,4 @@ obj-$(CONFIG_USBGECKO_UDBG) += usbgecko_udbg.o
obj-$(CONFIG_GAMECUBE_COMMON) += flipper-pic.o
obj-$(CONFIG_GAMECUBE) += gamecube.o
obj-$(CONFIG_WII) += wii.o hlwd-pic.o
+obj-$(CONFIG_MVME5100) += mvme5100.o
diff --git a/arch/powerpc/platforms/embedded6xx/mvme5100.c b/arch/powerpc/platforms/embedded6xx/mvme5100.c
new file mode 100644
index 0000000..430745e
--- /dev/null
+++ b/arch/powerpc/platforms/embedded6xx/mvme5100.c
@@ -0,0 +1,219 @@
+/*
+ * Board setup routines for the Motorola/Emerson MVME5100.
+ *
+ * Copyright 2013 CSC Australia Pty. Ltd.
+ *
+ * Based on earlier code by:
+ *
+ * Matt Porter, MontaVista Software Inc.
+ * Copyright 2001 MontaVista Software Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ *
+ * Author: Stephen Chivers <schivers@csc.com>
+ *
+ */
+
+#include <linux/of_platform.h>
+
+#include <asm/i8259.h>
+#include <asm/pci-bridge.h>
+#include <asm/mpic.h>
+#include <asm/prom.h>
+#include <mm/mmu_decl.h>
+#include <asm/udbg.h>
+
+#define HAWK_MPIC_SIZE 0x00040000U
+#define MVME5100_PCI_MEM_OFFSET 0x00000000
+
+/* Board register addresses. */
+#define BOARD_STATUS_REG 0xfef88080
+#define BOARD_MODFAIL_REG 0xfef88090
+#define BOARD_MODRST_REG 0xfef880a0
+#define BOARD_TBEN_REG 0xfef880c0
+#define BOARD_SW_READ_REG 0xfef880e0
+#define BOARD_GEO_ADDR_REG 0xfef880e8
+#define BOARD_EXT_FEATURE1_REG 0xfef880f0
+#define BOARD_EXT_FEATURE2_REG 0xfef88100
+
+static unsigned int pci_membase;
+
+static void mvme5100_8259_cascade(unsigned int irq, struct irq_desc *desc)
+{
+ struct irq_chip *chip = irq_desc_get_chip(desc);
+ unsigned int cascade_irq = i8259_irq();
+
+ if (cascade_irq != NO_IRQ)
+ generic_handle_irq(cascade_irq);
+
+ chip->irq_eoi(&desc->irq_data);
+}
+
+static void __init mvme5100_pic_init(void)
+{
+ struct mpic *mpic;
+ struct device_node *np;
+ struct device_node *cp = NULL;
+ unsigned int cirq;
+ unsigned long intack = 0;
+ const u32 *prop = NULL;
+
+ np = of_find_node_by_type(NULL, "open-pic");
+ if (!np) {
+ pr_err("Could not find open-pic node\n");
+ return;
+ }
+
+ mpic = mpic_alloc(np, pci_membase, 0, 16, 256, " OpenPIC ");
+
+ BUG_ON(mpic == NULL);
+ of_node_put(np);
+
+ mpic_assign_isu(mpic, 0, pci_membase + 0x10000);
+
+ mpic_init(mpic);
+
+ cp = of_find_compatible_node(NULL, NULL, "chrp,iic");
+ if (cp == NULL) {
+ pr_warn("mvme5100_pic_init: couldn't find i8259\n");
+ return;
+ }
+
+ if ((cirq = irq_of_parse_and_map(cp, 0)) == NO_IRQ) {
+ pr_warn("mvme5100_pic_init: no cascade interrupt?\n");
+ return;
+ }
+
+ if ((np = of_find_compatible_node(NULL, "pci", "mpc10x-pci"))) {
+ prop = of_get_property(np, "8259-interrupt-acknowledge", NULL);
+
+ if (prop)
+ intack = prop[0];
+
+ of_node_put(np);
+ }
+
+ if (intack)
+ pr_debug("mvme5100_pic_init: PCI 8259 intack at 0x%016lx\n",
+ intack);
+
+ i8259_init(cp, intack);
+ of_node_put(cp);
+ irq_set_chained_handler(cirq, mvme5100_8259_cascade);
+}
+
+static int __init mvme5100_add_bridge(struct device_node *dev)
+{
+ const int *bus_range;
+ int len;
+ struct pci_controller *hose;
+ unsigned short devid;
+
+ pr_info("Adding PCI host bridge %s\n", dev->full_name);
+
+ bus_range = of_get_property(dev, "bus-range", &len);
+
+ hose = pcibios_alloc_controller(dev);
+ if (hose == NULL)
+ return -ENOMEM;
+
+ hose->first_busno = bus_range ? bus_range[0] : 0;
+ hose->last_busno = bus_range ? bus_range[1] : 0xff;
+
+ setup_indirect_pci(hose, 0xfe000cf8, 0xfe000cfc, 0);
+
+ pci_process_bridge_OF_ranges(hose, dev, 1);
+
+ early_read_config_word(hose, 0, 0, PCI_DEVICE_ID, &devid);
+
+ if (devid != PCI_DEVICE_ID_MOTOROLA_HAWK) {
+ pr_err("HAWK PHB not present?\n");
+ return 0;
+ }
+
+ early_read_config_dword( hose, 0, 0, PCI_BASE_ADDRESS_1, &pci_membase);
+
+ if (pci_membase == 0) {
+ pr_err("HAWK PHB mibar not correctly set?\n");
+ return 0;
+ }
+
+ pr_info("mvme5100_pic_init: pci_membase: %x\n", pci_membase);
+
+ return 0;
+}
+
+static __initdata struct of_device_id mvme5100_of_bus_ids[] = {
+ { .compatible = "hawk-bridge", },
+ {},
+};
+
+/*
+ * Setup the architecture
+ */
+static void __init mvme5100_setup_arch(void)
+{
+ struct device_node *np;
+
+ if (ppc_md.progress)
+ ppc_md.progress("mvme5100_setup_arch()", 0);
+
+ for_each_compatible_node(np, "pci", "hawk-pci")
+ mvme5100_add_bridge(np);
+
+}
+
+
+static void mvme5100_show_cpuinfo(struct seq_file *m)
+{
+ seq_printf(m, "Vendor\t\t: Motorola/Emerson\n");
+ seq_printf(m, "Machine\t\t: MVME5100\n");
+}
+
+static void mvme5100_restart(char *cmd)
+{
+ u_char *restart;
+
+ restart = ioremap(BOARD_MODRST_REG, 4);
+ local_irq_disable();
+ mtmsr(mfmsr() | MSR_IP);
+
+ out_8((u_char *) restart, 0x01);
+
+ while (1)
+ ;
+}
+
+/*
+ * Called very early, device-tree isn't unflattened
+ */
+static int __init mvme5100_probe(void)
+{
+ unsigned long root = of_get_flat_dt_root();
+
+ return of_flat_dt_is_compatible(root, "MVME5100");
+}
+
+static int __init probe_of_platform_devices(void)
+{
+
+ of_platform_bus_probe(NULL, mvme5100_of_bus_ids, NULL);
+ return 0;
+}
+
+machine_device_initcall(mvme5100, probe_of_platform_devices);
+
+define_machine(mvme5100) {
+ .name = "MVME5100",
+ .probe = mvme5100_probe,
+ .setup_arch = mvme5100_setup_arch,
+ .init_IRQ = mvme5100_pic_init,
+ .show_cpuinfo = mvme5100_show_cpuinfo,
+ .get_irq = mpic_get_irq,
+ .restart = mvme5100_restart,
+ .calibrate_decr = generic_calibrate_decr,
+ .progress = udbg_progress,
+};
^ permalink raw reply related
* [PATCH] powerpc: Correct FSCR bit definitions
From: Paul Mackerras @ 2013-09-05 6:01 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Michael Neuling
Commit 74e400cee6 ("powerpc: Rework setting up H/FSCR bit definitions")
ended up with incorrect bit numbers for FSCR_PM_LG and FSCR_BHRB_LG.
This fixes them.
Signed-off-by: Paul Mackerras <paulus@samba.org>
---
arch/powerpc/include/asm/reg.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/include/asm/reg.h b/arch/powerpc/include/asm/reg.h
index dc10bf5..10d1ef0 100644
--- a/arch/powerpc/include/asm/reg.h
+++ b/arch/powerpc/include/asm/reg.h
@@ -258,8 +258,8 @@
#define FSCR_TAR_LG 8 /* Enable Target Address Register */
#define FSCR_EBB_LG 7 /* Enable Event Based Branching */
#define FSCR_TM_LG 5 /* Enable Transactional Memory */
-#define FSCR_PM_LG 4 /* Enable prob/priv access to PMU SPRs */
-#define FSCR_BHRB_LG 3 /* Enable Branch History Rolling Buffer*/
+#define FSCR_BHRB_LG 4 /* Enable Branch History Rolling Buffer*/
+#define FSCR_PM_LG 3 /* Enable prob/priv access to PMU SPRs */
#define FSCR_DSCR_LG 2 /* Enable Data Stream Control Register */
#define FSCR_VECVSX_LG 1 /* Enable VMX/VSX */
#define FSCR_FP_LG 0 /* Enable Floating Point */
--
1.8.4.rc3
^ permalink raw reply related
* Re: [PATCH] powerpc: Correct FSCR bit definitions
From: Michael Neuling @ 2013-09-05 6:09 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <20130905060116.GA24607@drongo>
Paul Mackerras <paulus@samba.org> wrote:
> Commit 74e400cee6 ("powerpc: Rework setting up H/FSCR bit definitions")
> ended up with incorrect bit numbers for FSCR_PM_LG and FSCR_BHRB_LG.
> This fixes them.
>
> Signed-off-by: Paul Mackerras <paulus@samba.org>
Acked-by: Michael Neuling <mikey@neuling.org>
Sorry about that screw up.
Mikey
> ---
> arch/powerpc/include/asm/reg.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/reg.h b/arch/powerpc/include/asm/reg.h
> index dc10bf5..10d1ef0 100644
> --- a/arch/powerpc/include/asm/reg.h
> +++ b/arch/powerpc/include/asm/reg.h
> @@ -258,8 +258,8 @@
> #define FSCR_TAR_LG 8 /* Enable Target Address Register */
> #define FSCR_EBB_LG 7 /* Enable Event Based Branching */
> #define FSCR_TM_LG 5 /* Enable Transactional Memory */
> -#define FSCR_PM_LG 4 /* Enable prob/priv access to PMU SPRs */
> -#define FSCR_BHRB_LG 3 /* Enable Branch History Rolling Buffer*/
> +#define FSCR_BHRB_LG 4 /* Enable Branch History Rolling Buffer*/
> +#define FSCR_PM_LG 3 /* Enable prob/priv access to PMU SPRs */
> #define FSCR_DSCR_LG 2 /* Enable Data Stream Control Register */
> #define FSCR_VECVSX_LG 1 /* Enable VMX/VSX */
> #define FSCR_FP_LG 0 /* Enable Floating Point */
> --
> 1.8.4.rc3
>
^ permalink raw reply
* Re: Please pull 'next' branch of 5xxx tree
From: Benjamin Herrenschmidt @ 2013-09-05 6:50 UTC (permalink / raw)
To: Anatolij Gustschin; +Cc: linuxppc-dev
In-Reply-To: <20130903223914.78c7b44e@crub>
On Tue, 2013-09-03 at 22:39 +0200, Anatolij Gustschin wrote:
> Hi Ben !
>
> Please pull mpc5xxx patches for v3.12.
>
> There are cleanups for some mpc5121 specific drivers and DTS files
> in preparation to switch mpc5121 clock support to a clock driver
> based on common clock framework. Additionally Sebastian fixed the
> mpc52xx PIC driver so that it builds when using older gcc versions.
>
> All these patches have already been in linux-next for a while.
Thanks. BTW. Next time, any chance you can base this off the same point
in Linus tree where my next branch is based ? Or base of my next
branch :-)
It makes the merged a lot cleaner....
Cheers,
Ben.
> Thanks,
>
> Anatolij
>
>
> The following changes since commit d4e4ab86bcba5a72779c43dc1459f71fea3d89c8:
>
> Linux 3.11-rc5 (2013-08-11 18:04:20 -0700)
>
> are available in the git repository at:
>
> git://git.denx.de/linux-2.6-agust.git next
>
> for you to fetch changes up to f2110cb961200e5c382e9d0878ded015109b5dd6:
>
> dts: mpc512x: prepare for preprocessor support (2013-08-24 00:18:55 +0200)
>
> ----------------------------------------------------------------
> Gerhard Sittig (6):
> serial: mpc512x: cleanup clock API use
> USB: fsl-mph-dr-of: cleanup clock API use
> mtd: mpc5121_nfc: cleanup clock API use
> fsl-viu: cleanup clock API use
> powerpc: mpc512x: array decl for MCLK registers in CCM
> dts: mpc512x: prepare for preprocessor support
>
> Sebastian Siewior (1):
> powerpc: 52xx: provide a default in mpc52xx_irqhost_map()
>
> arch/powerpc/boot/dts/ac14xx.dts | 2 +-
> arch/powerpc/boot/dts/include/dt-bindings | 1 +
> arch/powerpc/boot/dts/mpc5121ads.dts | 2 +-
> arch/powerpc/boot/dts/pdm360ng.dts | 2 +-
> arch/powerpc/include/asm/mpc5121.h | 18 +-----
> arch/powerpc/platforms/52xx/mpc52xx_pic.c | 3 +-
> drivers/media/platform/fsl-viu.c | 23 ++++---
> drivers/mtd/nand/mpc5121_nfc.c | 21 ++++---
> drivers/tty/serial/mpc52xx_uart.c | 98 ++++++++++++++++++++++++-----
> drivers/usb/host/fsl-mph-dr-of.c | 16 ++---
> 10 files changed, 123 insertions(+), 63 deletions(-)
> create mode 120000 arch/powerpc/boot/dts/include/dt-bindings
^ permalink raw reply
* [PATCH] powerpc: Fix possible deadlock on page fault
From: Aneesh Kumar K.V @ 2013-09-05 7:17 UTC (permalink / raw)
To: benh, paulus; +Cc: linuxppc-dev, Aneesh Kumar K.V
From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
stack_grow_into/14082 is trying to acquire lock:
(&mm->mmap_sem){++++++}, at: [<c000000000206d28>] .might_fault+0x78/0xe0
but task is already holding lock:
(&mm->mmap_sem){++++++}, at: [<c0000000007ffd8c>] .do_page_fault+0x24c/0x910
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
----
lock(&mm->mmap_sem);
lock(&mm->mmap_sem);
*** DEADLOCK ***
May be due to missing lock nesting notation
1 lock held by stack_grow_into/14082:
#0: (&mm->mmap_sem){++++++}, at: [<c0000000007ffd8c>] .do_page_fault+0x24c/0x910
stack backtrace:
CPU: 21 PID: 14082 Comm: stack_grow_into Not tainted 3.10.0-10.el7.ppc64.debug #1
Call Trace:
[c0000003d396b850] [c000000000016e7c] .show_stack+0x7c/0x1f0 (unreliable)
[c0000003d396b920] [c000000000813fc8] .dump_stack+0x28/0x3c
[c0000003d396b990] [c000000000124b90] .__lock_acquire+0x1640/0x1800
[c0000003d396bab0] [c00000000012570c] .lock_acquire+0xac/0x250
[c0000003d396bb80] [c000000000206d54] .might_fault+0xa4/0xe0
[c0000003d396bbf0] [c0000000007ffe2c] .do_page_fault+0x2ec/0x910
[c0000003d396be30] [c0000000000092e8] handle_page_fault+0x10/0x30
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
---
arch/powerpc/mm/fault.c | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/mm/fault.c b/arch/powerpc/mm/fault.c
index 8726779..dc2902a 100644
--- a/arch/powerpc/mm/fault.c
+++ b/arch/powerpc/mm/fault.c
@@ -206,7 +206,7 @@ int __kprobes do_page_fault(struct pt_regs *regs, unsigned long address,
int trap = TRAP(regs);
int is_exec = trap == 0x400;
int fault;
- int rc = 0;
+ int rc = 0, store_update;
#if !(defined(CONFIG_4xx) || defined(CONFIG_BOOKE))
/*
@@ -280,6 +280,13 @@ int __kprobes do_page_fault(struct pt_regs *regs, unsigned long address,
perf_sw_event(PERF_COUNT_SW_PAGE_FAULTS, 1, regs, address);
+ /*
+ * We want to do this outside mmap_sem, because reading code around nip
+ * can result in fault, which will cause a deadlock when called with
+ * mmap_sem held
+ */
+ store_update = store_updates_sp(regs);
+
/* When running in the kernel we expect faults to occur only to
* addresses in user space. All other faults represent errors in the
* kernel and should generate an OOPS. Unfortunately, in the case of an
@@ -346,7 +353,7 @@ retry:
* expand the stack rather than segfaulting.
*/
if (address + 2048 < uregs->gpr[1]
- && (!user_mode(regs) || !store_updates_sp(regs)))
+ && (!user_mode(regs) || !store_update))
goto bad_area;
}
if (expand_stack(vma, address))
--
1.8.1.2
^ permalink raw reply related
* [PATCH v2 3/6] powerpc/pci: use pci_is_pcie() to simplify code
From: Yijing Wang @ 2013-09-05 7:55 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Bjorn Helgaas, James E.J. Bottomley
Cc: Gavin Shan, linux-pci, linux-kernel, Paul Mackerras, Hanjun Guo,
Yijing Wang, linuxppc-dev
In-Reply-To: <1378367730-25996-1-git-send-email-wangyijing@huawei.com>
Use pci_is_pcie() to simplify code.
Acked-by: Kumar Gala <galak@kernel.crashing.org>
Reviewed-by: Gavin Shan <shangw@linux.vnet.ibm.com>
Signed-off-by: Yijing Wang <wangyijing@huawei.com>
Cc: Gavin Shan <shangw@linux.vnet.ibm.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-kernel@vger.kernel.org
---
arch/powerpc/kernel/eeh.c | 3 +--
arch/powerpc/sysdev/fsl_pci.c | 2 +-
2 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/kernel/eeh.c b/arch/powerpc/kernel/eeh.c
index 55593ee..6ebbe54 100644
--- a/arch/powerpc/kernel/eeh.c
+++ b/arch/powerpc/kernel/eeh.c
@@ -189,8 +189,7 @@ static size_t eeh_gather_pci_data(struct eeh_dev *edev, char * buf, size_t len)
}
/* If PCI-E capable, dump PCI-E cap 10, and the AER */
- cap = pci_find_capability(dev, PCI_CAP_ID_EXP);
- if (cap) {
+ if (pci_is_pcie(dev)) {
n += scnprintf(buf+n, len-n, "pci-e cap10:\n");
printk(KERN_WARNING
"EEH: PCI-E capabilities and status follow:\n");
diff --git a/arch/powerpc/sysdev/fsl_pci.c b/arch/powerpc/sysdev/fsl_pci.c
index 46ac1dd..5402a1d 100644
--- a/arch/powerpc/sysdev/fsl_pci.c
+++ b/arch/powerpc/sysdev/fsl_pci.c
@@ -41,7 +41,7 @@ static void quirk_fsl_pcie_header(struct pci_dev *dev)
u8 hdr_type;
/* if we aren't a PCIe don't bother */
- if (!pci_find_capability(dev, PCI_CAP_ID_EXP))
+ if (!pci_is_pcie(dev))
return;
/* if we aren't in host mode don't bother */
--
1.7.1
^ permalink raw reply related
* Re: [PATCH] powerpc: Fix possible deadlock on page fault
From: Paul Mackerras @ 2013-09-05 9:53 UTC (permalink / raw)
To: Aneesh Kumar K.V; +Cc: linuxppc-dev
In-Reply-To: <1378365422-25203-1-git-send-email-aneesh.kumar@linux.vnet.ibm.com>
On Thu, Sep 05, 2013 at 12:47:02PM +0530, Aneesh Kumar K.V wrote:
> @@ -280,6 +280,13 @@ int __kprobes do_page_fault(struct pt_regs *regs, unsigned long address,
>
> perf_sw_event(PERF_COUNT_SW_PAGE_FAULTS, 1, regs, address);
>
> + /*
> + * We want to do this outside mmap_sem, because reading code around nip
> + * can result in fault, which will cause a deadlock when called with
> + * mmap_sem held
> + */
> + store_update = store_updates_sp(regs);
We should only call store_updates_sp() if user_mode(regs); that was
the previous behaviour.
Paul.
^ permalink raw reply
* Re: [PATCH] powerpc: Fix possible deadlock on page fault
From: Aneesh Kumar K.V @ 2013-09-05 11:48 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <20130905095316.GA18222@iris.ozlabs.ibm.com>
Paul Mackerras <paulus@samba.org> writes:
> On Thu, Sep 05, 2013 at 12:47:02PM +0530, Aneesh Kumar K.V wrote:
>
>> @@ -280,6 +280,13 @@ int __kprobes do_page_fault(struct pt_regs *regs, unsigned long address,
>>
>> perf_sw_event(PERF_COUNT_SW_PAGE_FAULTS, 1, regs, address);
>>
>> + /*
>> + * We want to do this outside mmap_sem, because reading code around nip
>> + * can result in fault, which will cause a deadlock when called with
>> + * mmap_sem held
>> + */
>> + store_update = store_updates_sp(regs);
>
> We should only call store_updates_sp() if user_mode(regs); that was
> the previous behaviour.
Updated to
diff --git a/arch/powerpc/mm/fault.c b/arch/powerpc/mm/fault.c
index 8726779..fad7af6 100644
--- a/arch/powerpc/mm/fault.c
+++ b/arch/powerpc/mm/fault.c
@@ -206,7 +206,7 @@ int __kprobes do_page_fault(struct pt_regs *regs, unsigned long address,
int trap = TRAP(regs);
int is_exec = trap == 0x400;
int fault;
- int rc = 0;
+ int rc = 0, store_update = 0;
#if !(defined(CONFIG_4xx) || defined(CONFIG_BOOKE))
/*
@@ -280,6 +280,14 @@ int __kprobes do_page_fault(struct pt_regs *regs, unsigned long address,
perf_sw_event(PERF_COUNT_SW_PAGE_FAULTS, 1, regs, address);
+ /*
+ * We want to do this outside mmap_sem, because reading code around nip
+ * can result in fault, which will cause a deadlock when called with
+ * mmap_sem held
+ */
+ if (user_mode(regs))
+ store_update = store_updates_sp(regs);
+
/* When running in the kernel we expect faults to occur only to
* addresses in user space. All other faults represent errors in the
* kernel and should generate an OOPS. Unfortunately, in the case of an
@@ -345,8 +353,7 @@ retry:
* between the last mapped region and the stack will
* expand the stack rather than segfaulting.
*/
- if (address + 2048 < uregs->gpr[1]
- && (!user_mode(regs) || !store_updates_sp(regs)))
+ if (address + 2048 < uregs->gpr[1] && !store_update)
goto bad_area;
}
if (expand_stack(vma, address))
^ permalink raw reply related
* [PATCH -V2] powerpc: Fix possible deadlock on page fault
From: Aneesh Kumar K.V @ 2013-09-05 11:49 UTC (permalink / raw)
To: benh, paulus; +Cc: linuxppc-dev, Aneesh Kumar K.V
From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
stack_grow_into/14082 is trying to acquire lock:
(&mm->mmap_sem){++++++}, at: [<c000000000206d28>] .might_fault+0x78/0xe0
but task is already holding lock:
(&mm->mmap_sem){++++++}, at: [<c0000000007ffd8c>] .do_page_fault+0x24c/0x910
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
----
lock(&mm->mmap_sem);
lock(&mm->mmap_sem);
*** DEADLOCK ***
May be due to missing lock nesting notation
1 lock held by stack_grow_into/14082:
#0: (&mm->mmap_sem){++++++}, at: [<c0000000007ffd8c>] .do_page_fault+0x24c/0x910
stack backtrace:
CPU: 21 PID: 14082 Comm: stack_grow_into Not tainted 3.10.0-10.el7.ppc64.debug #1
Call Trace:
[c0000003d396b850] [c000000000016e7c] .show_stack+0x7c/0x1f0 (unreliable)
[c0000003d396b920] [c000000000813fc8] .dump_stack+0x28/0x3c
[c0000003d396b990] [c000000000124b90] .__lock_acquire+0x1640/0x1800
[c0000003d396bab0] [c00000000012570c] .lock_acquire+0xac/0x250
[c0000003d396bb80] [c000000000206d54] .might_fault+0xa4/0xe0
[c0000003d396bbf0] [c0000000007ffe2c] .do_page_fault+0x2ec/0x910
[c0000003d396be30] [c0000000000092e8] handle_page_fault+0x10/0x30
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
---
arch/powerpc/mm/fault.c | 13 ++++++++++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/mm/fault.c b/arch/powerpc/mm/fault.c
index 8726779..fad7af6 100644
--- a/arch/powerpc/mm/fault.c
+++ b/arch/powerpc/mm/fault.c
@@ -206,7 +206,7 @@ int __kprobes do_page_fault(struct pt_regs *regs, unsigned long address,
int trap = TRAP(regs);
int is_exec = trap == 0x400;
int fault;
- int rc = 0;
+ int rc = 0, store_update = 0;
#if !(defined(CONFIG_4xx) || defined(CONFIG_BOOKE))
/*
@@ -280,6 +280,14 @@ int __kprobes do_page_fault(struct pt_regs *regs, unsigned long address,
perf_sw_event(PERF_COUNT_SW_PAGE_FAULTS, 1, regs, address);
+ /*
+ * We want to do this outside mmap_sem, because reading code around nip
+ * can result in fault, which will cause a deadlock when called with
+ * mmap_sem held
+ */
+ if (user_mode(regs))
+ store_update = store_updates_sp(regs);
+
/* When running in the kernel we expect faults to occur only to
* addresses in user space. All other faults represent errors in the
* kernel and should generate an OOPS. Unfortunately, in the case of an
@@ -345,8 +353,7 @@ retry:
* between the last mapped region and the stack will
* expand the stack rather than segfaulting.
*/
- if (address + 2048 < uregs->gpr[1]
- && (!user_mode(regs) || !store_updates_sp(regs)))
+ if (address + 2048 < uregs->gpr[1] && !store_update)
goto bad_area;
}
if (expand_stack(vma, address))
--
1.8.1.2
^ permalink raw reply related
* Re: [PATCH] powerpc: Fix possible deadlock on page fault
From: Benjamin Herrenschmidt @ 2013-09-05 11:50 UTC (permalink / raw)
To: Aneesh Kumar K.V; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <87a9jrwkuc.fsf@linux.vnet.ibm.com>
On Thu, 2013-09-05 at 17:18 +0530, Aneesh Kumar K.V wrote:
> Paul Mackerras <paulus@samba.org> writes:
>
> > On Thu, Sep 05, 2013 at 12:47:02PM +0530, Aneesh Kumar K.V wrote:
> >
> >> @@ -280,6 +280,13 @@ int __kprobes do_page_fault(struct pt_regs *regs, unsigned long address,
> >>
> >> perf_sw_event(PERF_COUNT_SW_PAGE_FAULTS, 1, regs, address);
> >>
> >> + /*
> >> + * We want to do this outside mmap_sem, because reading code around nip
> >> + * can result in fault, which will cause a deadlock when called with
> >> + * mmap_sem held
> >> + */
> >> + store_update = store_updates_sp(regs);
> >
> > We should only call store_updates_sp() if user_mode(regs); that was
> > the previous behaviour.
>
> Updated to
>
> diff --git a/arch/powerpc/mm/fault.c b/arch/powerpc/mm/fault.c
> index 8726779..fad7af6 100644
> --- a/arch/powerpc/mm/fault.c
> +++ b/arch/powerpc/mm/fault.c
> @@ -206,7 +206,7 @@ int __kprobes do_page_fault(struct pt_regs *regs, unsigned long address,
> int trap = TRAP(regs);
> int is_exec = trap == 0x400;
> int fault;
> - int rc = 0;
> + int rc = 0, store_update = 0;
Keep the "sp", in the name, it's confusing otherwise. It's not just
about "store update", it's about specifically recognizing instructions
used to update the stack frame in order to let them and only them
significantly lower the stack pointer.
Cheers,
Ben.
> #if !(defined(CONFIG_4xx) || defined(CONFIG_BOOKE))
> /*
> @@ -280,6 +280,14 @@ int __kprobes do_page_fault(struct pt_regs *regs, unsigned long address,
>
> perf_sw_event(PERF_COUNT_SW_PAGE_FAULTS, 1, regs, address);
>
> + /*
> + * We want to do this outside mmap_sem, because reading code around nip
> + * can result in fault, which will cause a deadlock when called with
> + * mmap_sem held
> + */
> + if (user_mode(regs))
> + store_update = store_updates_sp(regs);
> +
> /* When running in the kernel we expect faults to occur only to
> * addresses in user space. All other faults represent errors in the
> * kernel and should generate an OOPS. Unfortunately, in the case of an
> @@ -345,8 +353,7 @@ retry:
> * between the last mapped region and the stack will
> * expand the stack rather than segfaulting.
> */
> - if (address + 2048 < uregs->gpr[1]
> - && (!user_mode(regs) || !store_updates_sp(regs)))
> + if (address + 2048 < uregs->gpr[1] && !store_update)
> goto bad_area;
> }
> if (expand_stack(vma, address))
^ permalink raw reply
* Re: [PATCH] powerpc: Fix possible deadlock on page fault
From: Aneesh Kumar K.V @ 2013-09-05 12:35 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <1378381835.4321.169.camel@pasglop>
Benjamin Herrenschmidt <benh@kernel.crashing.org> writes:
> On Thu, 2013-09-05 at 17:18 +0530, Aneesh Kumar K.V wrote:
>> Paul Mackerras <paulus@samba.org> writes:
>>
>> > On Thu, Sep 05, 2013 at 12:47:02PM +0530, Aneesh Kumar K.V wrote:
>> >
>> >> @@ -280,6 +280,13 @@ int __kprobes do_page_fault(struct pt_regs *regs, unsigned long address,
>> >>
>> >> perf_sw_event(PERF_COUNT_SW_PAGE_FAULTS, 1, regs, address);
>> >>
>> >> + /*
>> >> + * We want to do this outside mmap_sem, because reading code around nip
>> >> + * can result in fault, which will cause a deadlock when called with
>> >> + * mmap_sem held
>> >> + */
>> >> + store_update = store_updates_sp(regs);
>> >
>> > We should only call store_updates_sp() if user_mode(regs); that was
>> > the previous behaviour.
>>
>> Updated to
>>
>> diff --git a/arch/powerpc/mm/fault.c b/arch/powerpc/mm/fault.c
>> index 8726779..fad7af6 100644
>> --- a/arch/powerpc/mm/fault.c
>> +++ b/arch/powerpc/mm/fault.c
>> @@ -206,7 +206,7 @@ int __kprobes do_page_fault(struct pt_regs *regs, unsigned long address,
>> int trap = TRAP(regs);
>> int is_exec = trap == 0x400;
>> int fault;
>> - int rc = 0;
>> + int rc = 0, store_update = 0;
>
> Keep the "sp", in the name, it's confusing otherwise. It's not just
> about "store update", it's about specifically recognizing instructions
> used to update the stack frame in order to let them and only them
> significantly lower the stack pointer.
>
Ok will do that. I posted a v2. So will wait for other feedback before i
post a new version.
-aneesh
^ permalink raw reply
* Re: [V2,2/2] powerpc/85xx: workaround for chips with MSI hardware errata
From: Scott Wood @ 2013-09-05 17:57 UTC (permalink / raw)
To: Jia Hongtao-B38951; +Cc: Wood Scott-B07421, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <412C8208B4A0464FA894C5F0C278CD5D01D40DC2@039-SN1MPN1-003.039d.mgd.msft.net>
On Wed, 2013-09-04 at 23:00 -0500, Jia Hongtao-B38951 wrote:
> > -----Original Message-----
> > From: Jia Hongtao-B38951
> > Sent: Monday, July 01, 2013 5:36 PM
> > To: Wood Scott-B07421
> > Cc: linuxppc-dev@lists.ozlabs.org; galak@kernel.crashing.org
> > Subject: RE: [V2,2/2] powerpc/85xx: workaround for chips with MSI
> > hardware errata
> >
> > > -----Original Message-----
> > > From: Wood Scott-B07421
> > > Sent: Friday, June 28, 2013 10:29 AM
> > > To: Jia Hongtao-B38951
> > > Cc: linuxppc-dev@lists.ozlabs.org; galak@kernel.crashing.org; Wood
> > > Scott-
> > > B07421
> > > Subject: Re: [V2,2/2] powerpc/85xx: workaround for chips with MSI
> > > hardware errata
> > >
> > > On Wed, Apr 03, 2013 at 10:03:18AM +0800, Hongtao Jia wrote:
> > > > The MPIC version 2.0 has a MSI errata (errata PIC1 of mpc8544), It
> > > > causes that neither MSI nor MSI-X can work fine. This is a
> > > > workaround to allow MSI-X to function properly.
> > > >
> > > > Signed-off-by: Liu Shuo <soniccat.liu@gmail.com>
> > > > Signed-off-by: Li Yang <leoli@freescale.com>
> > > > Signed-off-by: Jia Hongtao <hongtao.jia@freescale.com>
> > >
> > > Building on 83xx:
> > >
> > > arch/powerpc/sysdev/built-in.o: In function `fsl_of_msi_probe':
> > > fsl_msi.c:(.text+0x1464): undefined reference to
> > > `fsl_mpic_primary_get_version'
> > > make[1]: *** [vmlinux] Error 1
> > > make: *** [sub-make] Error 2
> > >
> > > fsl_msi.c supports IPIC as well.
> > >
> > > -Scott
> >
> > Hi Scott,
> > I updated the patch to fix this compile error just now.
> > please refer to:
> > http://patchwork.ozlabs.org/patch/256018/
> >
> > Thanks.
> > -Hongtao
>
> Hi Scott,
>
> The 83xx compile issue has already been fixed.
> Please have a review on this patch.
Oh, sorry -- I missed it because it was marked "Changes Requested".
I've changed the status and will consider it for the next batch of
"next" patches.
In the future, if a patch is miscategorized in patchwork (e.g. says
"changes requested" when there is no longer a need to submit a new
patch) please mention that specifically and provide the patchwork URL.
-Scott
^ permalink raw reply
* Re: [PATCH v9 12/13] KVM: PPC: Add support for IOMMU in-kernel handling
From: Gleb Natapov @ 2013-09-05 18:10 UTC (permalink / raw)
To: Alexey Kardashevskiy
Cc: kvm, Alexander Graf, kvm-ppc, linux-kernel, linux-mm,
Paul Mackerras, Paolo Bonzini, linuxppc-dev, David Gibson
In-Reply-To: <522607D8.4070408@ozlabs.ru>
On Wed, Sep 04, 2013 at 02:01:28AM +1000, Alexey Kardashevskiy wrote:
> On 09/03/2013 08:53 PM, Gleb Natapov wrote:
> > On Mon, Sep 02, 2013 at 01:14:29PM +1000, Alexey Kardashevskiy wrote:
> >> On 09/01/2013 10:06 PM, Gleb Natapov wrote:
> >>> On Wed, Aug 28, 2013 at 06:50:41PM +1000, Alexey Kardashevskiy wrote:
> >>>> This allows the host kernel to handle H_PUT_TCE, H_PUT_TCE_INDIRECT
> >>>> and H_STUFF_TCE requests targeted an IOMMU TCE table without passing
> >>>> them to user space which saves time on switching to user space and back.
> >>>>
> >>>> Both real and virtual modes are supported. The kernel tries to
> >>>> handle a TCE request in the real mode, if fails it passes the request
> >>>> to the virtual mode to complete the operation. If it a virtual mode
> >>>> handler fails, the request is passed to user space.
> >>>>
> >>>> The first user of this is VFIO on POWER. Trampolines to the VFIO external
> >>>> user API functions are required for this patch.
> >>>>
> >>>> This adds a "SPAPR TCE IOMMU" KVM device to associate a logical bus
> >>>> number (LIOBN) with an VFIO IOMMU group fd and enable in-kernel handling
> >>>> of map/unmap requests. The device supports a single attribute which is
> >>>> a struct with LIOBN and IOMMU fd. When the attribute is set, the device
> >>>> establishes the connection between KVM and VFIO.
> >>>>
> >>>> Tests show that this patch increases transmission speed from 220MB/s
> >>>> to 750..1020MB/s on 10Gb network (Chelsea CXGB3 10Gb ethernet card).
> >>>>
> >>>> Signed-off-by: Paul Mackerras <paulus@samba.org>
> >>>> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
> >>>>
> >>>> ---
> >>>>
> >>>> Changes:
> >>>> v9:
> >>>> * KVM_CAP_SPAPR_TCE_IOMMU ioctl to KVM replaced with "SPAPR TCE IOMMU"
> >>>> KVM device
> >>>> * release_spapr_tce_table() is not shared between different TCE types
> >>>> * reduced the patch size by moving VFIO external API
> >>>> trampolines to separate patche
> >>>> * moved documentation from Documentation/virtual/kvm/api.txt to
> >>>> Documentation/virtual/kvm/devices/spapr_tce_iommu.txt
> >>>>
> >>>> v8:
> >>>> * fixed warnings from check_patch.pl
> >>>>
> >>>> 2013/07/11:
> >>>> * removed multiple #ifdef IOMMU_API as IOMMU_API is always enabled
> >>>> for KVM_BOOK3S_64
> >>>> * kvmppc_gpa_to_hva_and_get also returns host phys address. Not much sense
> >>>> for this here but the next patch for hugepages support will use it more.
> >>>>
> >>>> 2013/07/06:
> >>>> * added realmode arch_spin_lock to protect TCE table from races
> >>>> in real and virtual modes
> >>>> * POWERPC IOMMU API is changed to support real mode
> >>>> * iommu_take_ownership and iommu_release_ownership are protected by
> >>>> iommu_table's locks
> >>>> * VFIO external user API use rewritten
> >>>> * multiple small fixes
> >>>>
> >>>> 2013/06/27:
> >>>> * tce_list page is referenced now in order to protect it from accident
> >>>> invalidation during H_PUT_TCE_INDIRECT execution
> >>>> * added use of the external user VFIO API
> >>>>
> >>>> 2013/06/05:
> >>>> * changed capability number
> >>>> * changed ioctl number
> >>>> * update the doc article number
> >>>>
> >>>> 2013/05/20:
> >>>> * removed get_user() from real mode handlers
> >>>> * kvm_vcpu_arch::tce_tmp usage extended. Now real mode handler puts there
> >>>> translated TCEs, tries realmode_get_page() on those and if it fails, it
> >>>> passes control over the virtual mode handler which tries to finish
> >>>> the request handling
> >>>> * kvmppc_lookup_pte() now does realmode_get_page() protected by BUSY bit
> >>>> on a page
> >>>> * The only reason to pass the request to user mode now is when the user mode
> >>>> did not register TCE table in the kernel, in all other cases the virtual mode
> >>>> handler is expected to do the job
> >>>> ---
> >>>> .../virtual/kvm/devices/spapr_tce_iommu.txt | 37 +++
> >>>> arch/powerpc/include/asm/kvm_host.h | 4 +
> >>>> arch/powerpc/kvm/book3s_64_vio.c | 310 ++++++++++++++++++++-
> >>>> arch/powerpc/kvm/book3s_64_vio_hv.c | 122 ++++++++
> >>>> arch/powerpc/kvm/powerpc.c | 1 +
> >>>> include/linux/kvm_host.h | 1 +
> >>>> virt/kvm/kvm_main.c | 5 +
> >>>> 7 files changed, 477 insertions(+), 3 deletions(-)
> >>>> create mode 100644 Documentation/virtual/kvm/devices/spapr_tce_iommu.txt
> >>>>
> >>>> diff --git a/Documentation/virtual/kvm/devices/spapr_tce_iommu.txt b/Documentation/virtual/kvm/devices/spapr_tce_iommu.txt
> >>>> new file mode 100644
> >>>> index 0000000..4bc8fc3
> >>>> --- /dev/null
> >>>> +++ b/Documentation/virtual/kvm/devices/spapr_tce_iommu.txt
> >>>> @@ -0,0 +1,37 @@
> >>>> +SPAPR TCE IOMMU device
> >>>> +
> >>>> +Capability: KVM_CAP_SPAPR_TCE_IOMMU
> >>>> +Architectures: powerpc
> >>>> +
> >>>> +Device type supported: KVM_DEV_TYPE_SPAPR_TCE_IOMMU
> >>>> +
> >>>> +Groups:
> >>>> + KVM_DEV_SPAPR_TCE_IOMMU_ATTR_LINKAGE
> >>>> + Attributes: single attribute with pair { LIOBN, IOMMU fd}
> >>>> +
> >>>> +This is completely made up device which provides API to link
> >>>> +logical bus number (LIOBN) and IOMMU group. The user space has
> >>>> +to create a new SPAPR TCE IOMMU device per a logical bus.
> >>>> +
> >>> Why not have one device that can handle multimple links?
> >>
> >>
> >> I can do that. If I make it so, it won't even look as a device at all, just
> >> some weird interface to KVM but ok. What bothers me is it is just a
> > May be I do not understand usage pattern here. Why do you feel that device
> > that can handle multiple links is worse than device per link? How many logical
> > buses is there usually? How often they created/destroyed? I am not insisting
> > on the change, just trying to understand why you do not like it.
>
>
> Is it usually one PCI host bus adapter per IOMMU group which is usually
> one PCI card or 2-3 cards if it is a legacy PCI-X, and they are created
> when QEMU-KVM starts. Not many. And they live till KVM ends.
>
> My point is why would I want to put all links to one device? It all is just
> a matter of taste and nothing more. Or I am missing something but I do not
> see what. If it is all about making thing to be kosher/halal/orthodox, then
> I have more stuff to do, like reworking the emulated TCEs. But if is it for
> (I do not know, just guessing) performance or something like that - then
> I'll fix it, I just need to know what I am fixing.
>
Each device creates an fd, if you can have a lot of them eventually this
will be a bottleneck. You are saying this is not the case, so lets go
with proposed interface.
--
Gleb.
^ permalink raw reply
* Re: [PATCH V2 2/2] powerpc/85xx: workaround for chips with MSI hardware errata
From: Kumar Gala @ 2013-09-05 18:34 UTC (permalink / raw)
To: Jia Hongtao; +Cc: B07421, linuxppc-dev
In-Reply-To: <1364954598-31914-2-git-send-email-hongtao.jia@freescale.com>
On Apr 2, 2013, at 9:03 PM, Jia Hongtao wrote:
> The MPIC version 2.0 has a MSI errata (errata PIC1 of mpc8544), It =
causes
> that neither MSI nor MSI-X can work fine. This is a workaround to =
allow
> MSI-X to function properly.
>=20
> Signed-off-by: Liu Shuo <soniccat.liu@gmail.com>
> Signed-off-by: Li Yang <leoli@freescale.com>
> Signed-off-by: Jia Hongtao <hongtao.jia@freescale.com>
> ---
> Changes for V2:
> * change the name of function mpic_has_errata() to =
mpic_has_erratum_pic1().
> * move MSI_HW_ERRATA_ENDIAN define to fsl_msi.h with all other =
defines.
>=20
> arch/powerpc/sysdev/fsl_msi.c | 40 =
+++++++++++++++++++++++++++++++++++++---
> arch/powerpc/sysdev/fsl_msi.h | 2 ++
> 2 files changed, 39 insertions(+), 3 deletions(-)
>=20
> diff --git a/arch/powerpc/sysdev/fsl_msi.c =
b/arch/powerpc/sysdev/fsl_msi.c
> index 178c994..ca1157a 100644
> --- a/arch/powerpc/sysdev/fsl_msi.c
> +++ b/arch/powerpc/sysdev/fsl_msi.c
> @@ -98,8 +98,18 @@ static int fsl_msi_init_allocator(struct fsl_msi =
*msi_data)
>=20
> static int fsl_msi_check_device(struct pci_dev *pdev, int nvec, int =
type)
> {
> - if (type =3D=3D PCI_CAP_ID_MSIX)
> - pr_debug("fslmsi: MSI-X untested, trying anyway.\n");
> + struct fsl_msi *msi;
> +
> + if (type =3D=3D PCI_CAP_ID_MSI) {
> + /*
> + * MPIC version 2.0 has erratum PIC1. For now MSI
> + * could not work. So check to prevent MSI from
> + * being used on the board with this erratum.
> + */
> + list_for_each_entry(msi, &msi_head, list)
> + if (msi->feature & MSI_HW_ERRATA_ENDIAN)
> + return -EINVAL;
> + }
>=20
> return 0;
> }
> @@ -142,7 +152,17 @@ static void fsl_compose_msi_msg(struct pci_dev =
*pdev, int hwirq,
> msg->address_lo =3D lower_32_bits(address);
> msg->address_hi =3D upper_32_bits(address);
>=20
> - msg->data =3D hwirq;
> + /*
> + * MPIC version 2.0 has erratum PIC1. It causes
> + * that neither MSI nor MSI-X can work fine.
> + * This is a workaround to allow MSI-X to function
> + * properly. It only works for MSI-X, we prevent
> + * MSI on buggy chips in fsl_msi_check_device().
> + */
> + if (msi_data->feature & MSI_HW_ERRATA_ENDIAN)
> + msg->data =3D __swab32(hwirq);
> + else
> + msg->data =3D hwirq;
>=20
> pr_debug("%s: allocated srs: %d, ibs: %d\n",
> __func__, hwirq / IRQS_PER_MSI_REG, hwirq % =
IRQS_PER_MSI_REG);
> @@ -361,6 +381,15 @@ static int fsl_msi_setup_hwirq(struct fsl_msi =
*msi, struct platform_device *dev,
> return 0;
> }
>=20
> +/* MPIC version 2.0 has erratum PIC1 */
> +static int mpic_has_erratum_pic1(void)
> +{
> + if (fsl_mpic_primary_get_version() =3D=3D 0x0200)
> + return 1;
> +
> + return 0;
> +}
> +
> static const struct of_device_id fsl_of_msi_ids[];
> static int fsl_of_msi_probe(struct platform_device *dev)
> {
> @@ -423,6 +452,11 @@ static int fsl_of_msi_probe(struct =
platform_device *dev)
>=20
> msi->feature =3D features->fsl_pic_ip;
>=20
> + if ((features->fsl_pic_ip & FSL_PIC_IP_MASK) =3D=3D =
FSL_PIC_IP_MPIC) {
> + if (mpic_has_erratum_pic1())
Get ride of the mpic_has_erratum_pic1() function and just put the test =
here
> + msi->feature |=3D MSI_HW_ERRATA_ENDIAN;
> + }
> +
> /*
> * Remember the phandle, so that we can match with any PCI nodes
> * that have an "fsl,msi" property.
> diff --git a/arch/powerpc/sysdev/fsl_msi.h =
b/arch/powerpc/sysdev/fsl_msi.h
> index 8225f86..7389e8e 100644
> --- a/arch/powerpc/sysdev/fsl_msi.h
> +++ b/arch/powerpc/sysdev/fsl_msi.h
> @@ -25,6 +25,8 @@
> #define FSL_PIC_IP_IPIC 0x00000002
> #define FSL_PIC_IP_VMPIC 0x00000003
>=20
> +#define MSI_HW_ERRATA_ENDIAN 0x00000010
> +
Why does this need to be in the header, why not just have it in the .c =
only
> struct fsl_msi {
> struct irq_domain *irqhost;
>=20
> --=20
> 1.8.0
>=20
^ permalink raw reply
* Re: [PATCH V2 2/2] powerpc/85xx: workaround for chips with MSI hardware errata
From: Scott Wood @ 2013-09-05 18:37 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Jia Hongtao, B07421
In-Reply-To: <C12D1FFD-4D98-48C1-8681-54489600F722@kernel.crashing.org>
On Thu, 2013-09-05 at 13:34 -0500, Kumar Gala wrote:
> On Apr 2, 2013, at 9:03 PM, Jia Hongtao wrote:
> > + msi->feature |= MSI_HW_ERRATA_ENDIAN;
> > + }
> > +
> > /*
> > * Remember the phandle, so that we can match with any PCI nodes
> > * that have an "fsl,msi" property.
> > diff --git a/arch/powerpc/sysdev/fsl_msi.h b/arch/powerpc/sysdev/fsl_msi.h
> > index 8225f86..7389e8e 100644
> > --- a/arch/powerpc/sysdev/fsl_msi.h
> > +++ b/arch/powerpc/sysdev/fsl_msi.h
> > @@ -25,6 +25,8 @@
> > #define FSL_PIC_IP_IPIC 0x00000002
> > #define FSL_PIC_IP_VMPIC 0x00000003
> >
> > +#define MSI_HW_ERRATA_ENDIAN 0x00000010
> > +
>
> Why does this need to be in the header, why not just have it in the .c only
Didn't you ask this last time around? :-)
This flag is part of the same numberspace as FSL_PIC_IP_xxx and thus
should be defined in the same place.
-Scott
^ permalink raw reply
* Re: [PATCH V2] powerpc: Add I2C bus multiplexer node for B4 and T4240QDS
From: Kumar Gala @ 2013-09-05 18:41 UTC (permalink / raw)
To: Jia Hongtao; +Cc: B07421, linuxppc-dev, Wei.Yang
In-Reply-To: <1378348907-3137-1-git-send-email-hongtao.jia@freescale.com>
On Sep 4, 2013, at 9:41 PM, Jia Hongtao wrote:
> In both B4 and T4240QDS platform PCA9547 I2C bus multiplexer is used.
> The sub-nodes are also reorganized according to right I2C topology.
>=20
> Signed-off-by: Jia Hongtao <hongtao.jia@freescale.com>
> ---
> V2 change log:
> Reorganized the sub-nodes under I2C multiplexer to represent right =
topology.
>=20
> arch/powerpc/boot/dts/b4qds.dtsi | 49 +++++++++++++++++-----------
> arch/powerpc/boot/dts/t4240qds.dts | 67 =
++++++++++++++++++++++----------------
> 2 files changed, 69 insertions(+), 47 deletions(-)
>=20
> diff --git a/arch/powerpc/boot/dts/b4qds.dtsi =
b/arch/powerpc/boot/dts/b4qds.dtsi
> index e6d2f8f..de8cb38 100644
> --- a/arch/powerpc/boot/dts/b4qds.dtsi
> +++ b/arch/powerpc/boot/dts/b4qds.dtsi
> @@ -120,25 +120,36 @@
> };
>=20
> i2c@118000 {
> - eeprom@50 {
> - compatible =3D "at24,24c64";
> - reg =3D <0x50>;
> - };
> - eeprom@51 {
> - compatible =3D "at24,24c256";
> - reg =3D <0x51>;
> - };
> - eeprom@53 {
> - compatible =3D "at24,24c256";
> - reg =3D <0x53>;
> - };
> - eeprom@57 {
> - compatible =3D "at24,24c256";
> - reg =3D <0x57>;
> - };
> - rtc@68 {
> - compatible =3D "dallas,ds3232";
> - reg =3D <0x68>;
> + pca9547@77 {
> + compatible =3D "philips,pca9547";
We seem to be using nxp instead of philips now.
> + reg =3D <0x77>;
> + #address-cells =3D <1>;
> + #size-cells =3D <0>;
> + channel@0 {
channel should probably be i2c
[same comments below]
> + #address-cells =3D <1>;
> + #size-cells =3D <0>;
> + reg =3D <0>;
> + eeprom@50 {
> + compatible =3D =
"at24,24c64";
> + reg =3D <0x50>;
> + };
> + eeprom@51 {
> + compatible =3D =
"at24,24c256";
> + reg =3D <0x51>;
> + };
> + eeprom@53 {
> + compatible =3D =
"at24,24c256";
> + reg =3D <0x53>;
> + };
> + eeprom@57 {
> + compatible =3D =
"at24,24c256";
> + reg =3D <0x57>;
> + };
> + rtc@68 {
> + compatible =3D =
"dallas,ds3232";
> + reg =3D <0x68>;
> + };
> + };
> };
> };
>=20
> diff --git a/arch/powerpc/boot/dts/t4240qds.dts =
b/arch/powerpc/boot/dts/t4240qds.dts
> index 0555976..ae68595 100644
> --- a/arch/powerpc/boot/dts/t4240qds.dts
> +++ b/arch/powerpc/boot/dts/t4240qds.dts
> @@ -118,34 +118,45 @@
> };
>=20
> i2c@118000 {
> - eeprom@51 {
> - compatible =3D "at24,24c256";
> - reg =3D <0x51>;
> - };
> - eeprom@52 {
> - compatible =3D "at24,24c256";
> - reg =3D <0x52>;
> - };
> - eeprom@53 {
> - compatible =3D "at24,24c256";
> - reg =3D <0x53>;
> - };
> - eeprom@54 {
> - compatible =3D "at24,24c256";
> - reg =3D <0x54>;
> - };
> - eeprom@55 {
> - compatible =3D "at24,24c256";
> - reg =3D <0x55>;
> - };
> - eeprom@56 {
> - compatible =3D "at24,24c256";
> - reg =3D <0x56>;
> - };
> - rtc@68 {
> - compatible =3D "dallas,ds3232";
> - reg =3D <0x68>;
> - interrupts =3D <0x1 0x1 0 0>;
> + pca9547@77 {
> + compatible =3D "philips,pca9547";
> + reg =3D <0x77>;
> + #address-cells =3D <1>;
> + #size-cells =3D <0>;
> + channel@0 {
> + #address-cells =3D <1>;
> + #size-cells =3D <0>;
> + reg =3D <0>;
> + eeprom@51 {
> + compatible =3D =
"at24,24c256";
> + reg =3D <0x51>;
> + };
> + eeprom@52 {
> + compatible =3D =
"at24,24c256";
> + reg =3D <0x52>;
> + };
> + eeprom@53 {
> + compatible =3D =
"at24,24c256";
> + reg =3D <0x53>;
> + };
> + eeprom@54 {
> + compatible =3D =
"at24,24c256";
> + reg =3D <0x54>;
> + };
> + eeprom@55 {
> + compatible =3D =
"at24,24c256";
> + reg =3D <0x55>;
> + };
> + eeprom@56 {
> + compatible =3D =
"at24,24c256";
> + reg =3D <0x56>;
> + };
> + rtc@68 {
> + compatible =3D =
"dallas,ds3232";
> + reg =3D <0x68>;
> + interrupts =3D <0x1 0x1 =
0 0>;
> + };
> + };
> };
> };
> };
> --=20
> 1.8.0
>=20
>=20
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [PATCH] powerpc: Add I2C bus multiplexer node for B4 and T4240QDS
From: Scott Wood @ 2013-09-05 18:40 UTC (permalink / raw)
To: Tang Yuantian-B29983
Cc: Wood Scott-B07421, linuxppc-dev@lists.ozlabs.org, Yang, Wei,
Jia Hongtao-B38951
In-Reply-To: <D07C73A334FF604B95B3CBD2A545D07B15056D07@039-SN2MPN1-011.039d.mgd.msft.net>
On Tue, 2013-09-03 at 22:30 -0500, Tang Yuantian-B29983 wrote:
> Hi,
>
> These eeproms are never used by kernel. So no need to add them.
The device tree describes the hardware, not what Linux does with it.
-Scott
^ permalink raw reply
* [PATCH v2] powerpc: Default arch idle could cede processor on pseries
From: Vaidyanathan Srinivasan @ 2013-09-05 18:55 UTC (permalink / raw)
To: Paul Mackerras, Benjamin Herrenschmidt; +Cc: Deepthi Dharwar, linuxppc-dev
Hi,
Idle routines on pseries were rearranged so that cpuidle can do an
optimized idle state selection. However, until cpuidle takes over
during boot, the idle loop spins for a short while. This actually
affected bootup time since spinning idle sibling threads slows down
master cpu that executes bootup code.
The following patch enables pseries system to yield to hypervisor and
stop spinning by calling cede_processor() until cpuidle can take over
and do optimal idle state selection.
Bootup time can be reduced to half on small guest where most of the
time is spend before device init.
Thanks Ben for the review and suggestions.
--Vaidy
powerpc: Default arch idle could cede processor on pseries
When adding cpuidle support to pSeries, we introduced two
regressions:
- The new cpuidle backend driver only works under hypervisors
supporting the "SLPLAR" option, which isn't the case of the
old POWER4 hypervisor and the HV "light" used on js2x blades
- The cpuidle driver registers fairly late, meaning that for
a significant portion of the boot process, we end up having
all threads spinning. This slows down the boot process and
increases the overall resource usage if the hypervisor has
shared processors.
This fixes it by implementing a "default" idle that will cede
to the hypervisor when possible, in a very simple way without
all the bells and whisles of cpuidle.
Reported-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Vaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com>
Acked-by: Deepthi Dharwar <deepthi@linux.vnet.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
diff --git a/arch/powerpc/platforms/pseries/setup.c b/arch/powerpc/platforms/pseries/setup.c
index c11c823..54b998f 100644
--- a/arch/powerpc/platforms/pseries/setup.c
+++ b/arch/powerpc/platforms/pseries/setup.c
@@ -354,7 +354,7 @@ static int alloc_dispatch_log_kmem_cache(void)
}
early_initcall(alloc_dispatch_log_kmem_cache);
-static void pSeries_idle(void)
+static void pseries_lpar_idle(void)
{
/* This would call on the cpuidle framework, and the back-end pseries
* driver to go to idle states
@@ -362,10 +362,22 @@ static void pSeries_idle(void)
if (cpuidle_idle_call()) {
/* On error, execute default handler
* to go into low thread priority and possibly
- * low power mode.
+ * low power mode by cedeing processor to hypervisor
*/
- HMT_low();
- HMT_very_low();
+
+ /* Indicate to hypervisor that we are idle. */
+ get_lppaca()->idle = 1;
+
+ /*
+ * Yield the processor to the hypervisor. We return if
+ * an external interrupt occurs (which are driven prior
+ * to returning here) or if a prod occurs from another
+ * processor. When returning here, external interrupts
+ * are enabled.
+ */
+ cede_processor();
+
+ get_lppaca()->idle = 0;
}
}
@@ -456,15 +468,14 @@ static void __init pSeries_setup_arch(void)
pSeries_nvram_init();
- if (firmware_has_feature(FW_FEATURE_SPLPAR)) {
+ if (firmware_has_feature(FW_FEATURE_LPAR)) {
vpa_init(boot_cpuid);
- ppc_md.power_save = pSeries_idle;
- }
-
- if (firmware_has_feature(FW_FEATURE_LPAR))
+ ppc_md.power_save = pseries_lpar_idle;
ppc_md.enable_pmcs = pseries_lpar_enable_pmcs;
- else
+ } else {
+ /* No special idle routine */
ppc_md.enable_pmcs = power4_enable_pmcs;
+ }
ppc_md.pcibios_root_bridge_prepare = pseries_root_bridge_prepare;
^ permalink raw reply related
* Re: [PATCH v2 3/3] powerpc/85xx: add hardware automatically enter pw20 state
From: Scott Wood @ 2013-09-05 18:56 UTC (permalink / raw)
To: Dongsheng Wang; +Cc: linuxppc-dev
In-Reply-To: <1377592900-5020-3-git-send-email-dongsheng.wang@freescale.com>
On Tue, 2013-08-27 at 16:41 +0800, Dongsheng Wang wrote:
> From: Wang Dongsheng <dongsheng.wang@freescale.com>
>
> Using hardware features make core automatically enter PW20 state.
> Set a TB count to hardware, the effective count begins when PW10
> is entered. When the effective period has expired, the core will
> proceed from PW10 to PW20 if no exit conditions have occurred during
> the period.
>
> Signed-off-by: Wang Dongsheng <dongsheng.wang@freescale.com>
> ---
> Remove:
> delete setup_idle_hw_governor function.
> delete "Fix erratum" for rev1.
>
> Move:
> move setup_* into __setup/restore_cpu_e6500.
>
> diff --git a/arch/powerpc/include/asm/reg_booke.h b/arch/powerpc/include/asm/reg_booke.h
> index 8364bbe..e846495 100644
> --- a/arch/powerpc/include/asm/reg_booke.h
> +++ b/arch/powerpc/include/asm/reg_booke.h
> @@ -219,6 +219,7 @@
>
> /* Bit definitions for PWRMGTCR0. */
> #define PWRMGTCR0_ALTIVEC_IDLE (1 << 22) /* Altivec idle enable */
> +#define PWRMGTCR0_PW20_WAIT (1 << 14) /* PW20 state enable bit */
>
> /* Bit definitions for the MCSR. */
> #define MCSR_MCS 0x80000000 /* Machine Check Summary */
> diff --git a/arch/powerpc/kernel/cpu_setup_fsl_booke.S b/arch/powerpc/kernel/cpu_setup_fsl_booke.S
> index 90bbb46..295ccb5 100644
> --- a/arch/powerpc/kernel/cpu_setup_fsl_booke.S
> +++ b/arch/powerpc/kernel/cpu_setup_fsl_booke.S
> @@ -59,6 +59,7 @@ _GLOBAL(__setup_cpu_e6500)
> bl .setup_altivec_ivors
> #endif
> bl setup_altivec_idle
> + bl setup_pw20_idle
> bl __setup_cpu_e5500
> mtlr r6
> blr
> @@ -121,6 +122,7 @@ _GLOBAL(__restore_cpu_e6500)
> mflr r5
> bl .setup_altivec_ivors
> bl setup_altivec_idle
> + bl setup_pw20_idle
> bl __restore_cpu_e5500
> mtlr r5
> blr
> diff --git a/arch/powerpc/platforms/85xx/common.c b/arch/powerpc/platforms/85xx/common.c
> index 93b563b..cdd526e 100644
> --- a/arch/powerpc/platforms/85xx/common.c
> +++ b/arch/powerpc/platforms/85xx/common.c
> @@ -15,12 +15,22 @@
>
> #define ALTIVEC_COUNT_OFFSET 16
> #define ALTIVEC_IDLE_COUNT_MASK 0x003f0000
> +#define PW20_COUNT_OFFSET 8
> +#define PW20_IDLE_COUNT_MASK 0x00003f00
>
> /*
> * FIXME - We don't know the AltiVec application scenarios.
> */
> #define ALTIVEC_IDLE_TIME_BIT 14 /* 1ms */
>
> +/*
> + * FIXME - We don't know, what time should we let the core into PW20 state.
> + * because we don't know the current state of the cpu load. And threads are
> + * independent, so we can not know the state of different thread has been
> + * idle.
> + */
> +#define PW20_IDLE_TIME_BIT 14 /* 1ms */
> +
> static struct of_device_id __initdata mpc85xx_common_ids[] = {
> { .type = "soc", },
> { .compatible = "soc", },
> @@ -125,3 +135,25 @@ void setup_altivec_idle(void)
>
> mtspr(SPRN_PWRMGTCR0, altivec_idle);
> }
> +
> +void setup_pw20_idle(void)
> +{
> + u32 pw20_idle;
> +
> + if (!has_pw20_altivec_idle())
> + return;
> +
> + pw20_idle = mfspr(SPRN_PWRMGTCR0);
> +
> + /* Set PW20_WAIT bit, Enable PW20 State */
> + pw20_idle |= PWRMGTCR0_PW20_WAIT;
> +
> + /* Set Automatic PW20 Core Idle Count */
> + /* clear count */
> + pw20_idle &= ~PW20_IDLE_COUNT_MASK;
> +
> + /* set count */
> + pw20_idle |= ((MAX_BIT - PW20_IDLE_TIME_BIT) << PW20_COUNT_OFFSET);
> +
> + mtspr(SPRN_PWRMGTCR0, pw20_idle);
> +}
You can't call C code from __restore_cpu_e6500 as you don't have a stack
yet.
-Scott
^ permalink raw reply
* Re: [PATCH v9 12/13] KVM: PPC: Add support for IOMMU in-kernel handling
From: Alexey Kardashevskiy @ 2013-09-05 23:38 UTC (permalink / raw)
To: Gleb Natapov
Cc: kvm, Alexander Graf, kvm-ppc, linux-kernel, linux-mm,
Paul Mackerras, Paolo Bonzini, linuxppc-dev, David Gibson
In-Reply-To: <20130905181010.GE13021@redhat.com>
On 09/06/2013 04:10 AM, Gleb Natapov wrote:
> On Wed, Sep 04, 2013 at 02:01:28AM +1000, Alexey Kardashevskiy wrote:
>> On 09/03/2013 08:53 PM, Gleb Natapov wrote:
>>> On Mon, Sep 02, 2013 at 01:14:29PM +1000, Alexey Kardashevskiy wrote:
>>>> On 09/01/2013 10:06 PM, Gleb Natapov wrote:
>>>>> On Wed, Aug 28, 2013 at 06:50:41PM +1000, Alexey Kardashevskiy wrote:
>>>>>> This allows the host kernel to handle H_PUT_TCE, H_PUT_TCE_INDIRECT
>>>>>> and H_STUFF_TCE requests targeted an IOMMU TCE table without passing
>>>>>> them to user space which saves time on switching to user space and back.
>>>>>>
>>>>>> Both real and virtual modes are supported. The kernel tries to
>>>>>> handle a TCE request in the real mode, if fails it passes the request
>>>>>> to the virtual mode to complete the operation. If it a virtual mode
>>>>>> handler fails, the request is passed to user space.
>>>>>>
>>>>>> The first user of this is VFIO on POWER. Trampolines to the VFIO external
>>>>>> user API functions are required for this patch.
>>>>>>
>>>>>> This adds a "SPAPR TCE IOMMU" KVM device to associate a logical bus
>>>>>> number (LIOBN) with an VFIO IOMMU group fd and enable in-kernel handling
>>>>>> of map/unmap requests. The device supports a single attribute which is
>>>>>> a struct with LIOBN and IOMMU fd. When the attribute is set, the device
>>>>>> establishes the connection between KVM and VFIO.
>>>>>>
>>>>>> Tests show that this patch increases transmission speed from 220MB/s
>>>>>> to 750..1020MB/s on 10Gb network (Chelsea CXGB3 10Gb ethernet card).
>>>>>>
>>>>>> Signed-off-by: Paul Mackerras <paulus@samba.org>
>>>>>> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
>>>>>>
>>>>>> ---
>>>>>>
>>>>>> Changes:
>>>>>> v9:
>>>>>> * KVM_CAP_SPAPR_TCE_IOMMU ioctl to KVM replaced with "SPAPR TCE IOMMU"
>>>>>> KVM device
>>>>>> * release_spapr_tce_table() is not shared between different TCE types
>>>>>> * reduced the patch size by moving VFIO external API
>>>>>> trampolines to separate patche
>>>>>> * moved documentation from Documentation/virtual/kvm/api.txt to
>>>>>> Documentation/virtual/kvm/devices/spapr_tce_iommu.txt
>>>>>>
>>>>>> v8:
>>>>>> * fixed warnings from check_patch.pl
>>>>>>
>>>>>> 2013/07/11:
>>>>>> * removed multiple #ifdef IOMMU_API as IOMMU_API is always enabled
>>>>>> for KVM_BOOK3S_64
>>>>>> * kvmppc_gpa_to_hva_and_get also returns host phys address. Not much sense
>>>>>> for this here but the next patch for hugepages support will use it more.
>>>>>>
>>>>>> 2013/07/06:
>>>>>> * added realmode arch_spin_lock to protect TCE table from races
>>>>>> in real and virtual modes
>>>>>> * POWERPC IOMMU API is changed to support real mode
>>>>>> * iommu_take_ownership and iommu_release_ownership are protected by
>>>>>> iommu_table's locks
>>>>>> * VFIO external user API use rewritten
>>>>>> * multiple small fixes
>>>>>>
>>>>>> 2013/06/27:
>>>>>> * tce_list page is referenced now in order to protect it from accident
>>>>>> invalidation during H_PUT_TCE_INDIRECT execution
>>>>>> * added use of the external user VFIO API
>>>>>>
>>>>>> 2013/06/05:
>>>>>> * changed capability number
>>>>>> * changed ioctl number
>>>>>> * update the doc article number
>>>>>>
>>>>>> 2013/05/20:
>>>>>> * removed get_user() from real mode handlers
>>>>>> * kvm_vcpu_arch::tce_tmp usage extended. Now real mode handler puts there
>>>>>> translated TCEs, tries realmode_get_page() on those and if it fails, it
>>>>>> passes control over the virtual mode handler which tries to finish
>>>>>> the request handling
>>>>>> * kvmppc_lookup_pte() now does realmode_get_page() protected by BUSY bit
>>>>>> on a page
>>>>>> * The only reason to pass the request to user mode now is when the user mode
>>>>>> did not register TCE table in the kernel, in all other cases the virtual mode
>>>>>> handler is expected to do the job
>>>>>> ---
>>>>>> .../virtual/kvm/devices/spapr_tce_iommu.txt | 37 +++
>>>>>> arch/powerpc/include/asm/kvm_host.h | 4 +
>>>>>> arch/powerpc/kvm/book3s_64_vio.c | 310 ++++++++++++++++++++-
>>>>>> arch/powerpc/kvm/book3s_64_vio_hv.c | 122 ++++++++
>>>>>> arch/powerpc/kvm/powerpc.c | 1 +
>>>>>> include/linux/kvm_host.h | 1 +
>>>>>> virt/kvm/kvm_main.c | 5 +
>>>>>> 7 files changed, 477 insertions(+), 3 deletions(-)
>>>>>> create mode 100644 Documentation/virtual/kvm/devices/spapr_tce_iommu.txt
>>>>>>
>>>>>> diff --git a/Documentation/virtual/kvm/devices/spapr_tce_iommu.txt b/Documentation/virtual/kvm/devices/spapr_tce_iommu.txt
>>>>>> new file mode 100644
>>>>>> index 0000000..4bc8fc3
>>>>>> --- /dev/null
>>>>>> +++ b/Documentation/virtual/kvm/devices/spapr_tce_iommu.txt
>>>>>> @@ -0,0 +1,37 @@
>>>>>> +SPAPR TCE IOMMU device
>>>>>> +
>>>>>> +Capability: KVM_CAP_SPAPR_TCE_IOMMU
>>>>>> +Architectures: powerpc
>>>>>> +
>>>>>> +Device type supported: KVM_DEV_TYPE_SPAPR_TCE_IOMMU
>>>>>> +
>>>>>> +Groups:
>>>>>> + KVM_DEV_SPAPR_TCE_IOMMU_ATTR_LINKAGE
>>>>>> + Attributes: single attribute with pair { LIOBN, IOMMU fd}
>>>>>> +
>>>>>> +This is completely made up device which provides API to link
>>>>>> +logical bus number (LIOBN) and IOMMU group. The user space has
>>>>>> +to create a new SPAPR TCE IOMMU device per a logical bus.
>>>>>> +
>>>>> Why not have one device that can handle multimple links?
>>>>
>>>>
>>>> I can do that. If I make it so, it won't even look as a device at all, just
>>>> some weird interface to KVM but ok. What bothers me is it is just a
>>> May be I do not understand usage pattern here. Why do you feel that device
>>> that can handle multiple links is worse than device per link? How many logical
>>> buses is there usually? How often they created/destroyed? I am not insisting
>>> on the change, just trying to understand why you do not like it.
>>
>>
>> Is it usually one PCI host bus adapter per IOMMU group which is usually
>> one PCI card or 2-3 cards if it is a legacy PCI-X, and they are created
>> when QEMU-KVM starts. Not many. And they live till KVM ends.
>>
>> My point is why would I want to put all links to one device? It all is just
>> a matter of taste and nothing more. Or I am missing something but I do not
>> see what. If it is all about making thing to be kosher/halal/orthodox, then
>> I have more stuff to do, like reworking the emulated TCEs. But if is it for
>> (I do not know, just guessing) performance or something like that - then
>> I'll fix it, I just need to know what I am fixing.
>>
> Each device creates an fd, if you can have a lot of them eventually this
> will be a bottleneck. You are saying this is not the case, so lets go
> with proposed interface.
Did you decide not to answer the email which Ben sent yesterday or you just
did not see it? Just checking :)
--
Alexey
^ permalink raw reply
* [PATCH 0/6] EEH Support for PHB3
From: Gavin Shan @ 2013-09-06 0:59 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Gavin Shan
Naturally, EEH has been supported for PHB3, but we had some mask bits
to disable it because the firmware isn't ready. The series of patch
instends to remove those "mask bits" and enable EEH for PHB3. Besides,
the output messages from EEH has been reordered to reflect the correct
steps during EEH recovery. Also, we have dedicated data struct for PHB3
diag-data, which is similiar to the case of P7IOC.
Note: We can't recover fenced PHB3 this moment because the f/w still have
some problems, which I'm tracing down. However, the fix shouldn't affect
the logic we have in Linux side.
In order to force frozen PE, you need issue following command or similiar
one on different PHB#:
echo 0x8000000000000000 > /sys/kernel/debug/powerpc/PCI0003/err_injct_outbound
---
arch/powerpc/include/asm/opal.h | 65 +++++++++++
arch/powerpc/kernel/eeh.c | 6 +-
arch/powerpc/platforms/powernv/eeh-ioda.c | 153 ++++++++++++++++++++++----
arch/powerpc/platforms/powernv/eeh-powernv.c | 5 +-
arch/powerpc/platforms/powernv/pci.h | 2 +-
5 files changed, 200 insertions(+), 31 deletions(-)
Thanks,
Gavin
^ permalink raw reply
* [PATCH 3/6] powerpc/eeh: Output error number
From: Gavin Shan @ 2013-09-06 1:00 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Gavin Shan
In-Reply-To: <1378429205-16248-1-git-send-email-shangw@linux.vnet.ibm.com>
The patch prints the error number while failing to retrieve error
log from firmware. It's helpful for debugging.
Signed-off-by: Gavin Shan <shangw@linux.vnet.ibm.com>
---
arch/powerpc/platforms/powernv/eeh-ioda.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/eeh-ioda.c b/arch/powerpc/platforms/powernv/eeh-ioda.c
index 3ee44b0..d60ba3b 100644
--- a/arch/powerpc/platforms/powernv/eeh-ioda.c
+++ b/arch/powerpc/platforms/powernv/eeh-ioda.c
@@ -590,8 +590,8 @@ static int ioda_eeh_get_log(struct eeh_pe *pe, int severity,
phb->diag.blob, PNV_PCI_DIAG_BUF_SIZE);
if (ret) {
spin_unlock_irqrestore(&phb->lock, flags);
- pr_warning("%s: Failed to get log for PHB#%x-PE#%x\n",
- __func__, hose->global_number, pe->addr);
+ pr_warning("%s: Can't get log for PHB#%x-PE#%x (%lld)\n",
+ __func__, hose->global_number, pe->addr, ret);
return -EIO;
}
--
1.7.5.4
^ permalink raw reply related
* [PATCH 4/6] powerpc/powernv: Double size of log blob
From: Gavin Shan @ 2013-09-06 1:00 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Gavin Shan
In-Reply-To: <1378429205-16248-1-git-send-email-shangw@linux.vnet.ibm.com>
Each PHB instance (struct pnv_phb) has its corresponding log blob,
which is used to hold the retrieved error log from firmware. The
current size of that (4096) isn't enough for PHB3 case and the patch
makes that double to 8192.
Signed-off-by: Gavin Shan <shangw@linux.vnet.ibm.com>
---
arch/powerpc/platforms/powernv/pci.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/pci.h b/arch/powerpc/platforms/powernv/pci.h
index d633c64..f4bccc8 100644
--- a/arch/powerpc/platforms/powernv/pci.h
+++ b/arch/powerpc/platforms/powernv/pci.h
@@ -17,7 +17,7 @@ enum pnv_phb_model {
PNV_PHB_MODEL_PHB3,
};
-#define PNV_PCI_DIAG_BUF_SIZE 4096
+#define PNV_PCI_DIAG_BUF_SIZE 8192
#define PNV_IODA_PE_DEV (1 << 0) /* PE has single PCI device */
#define PNV_IODA_PE_BUS (1 << 1) /* PE has primary PCI bus */
#define PNV_IODA_PE_BUS_ALL (1 << 2) /* PE has subordinate buses */
--
1.7.5.4
^ permalink raw reply related
* [PATCH 6/6] powerpc/eeh: Reorder output messages
From: Gavin Shan @ 2013-09-06 1:00 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Gavin Shan
In-Reply-To: <1378429205-16248-1-git-send-email-shangw@linux.vnet.ibm.com>
We already had some output messages from EEH core. Occasionally,
we can see the output messages from EEH core before the stack
dump. That's not what we expected. The patch fixes that and shows
the stack dump prior to output messages from EEH core.
Signed-off-by: Gavin Shan <shangw@linux.vnet.ibm.com>
---
arch/powerpc/kernel/eeh.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/kernel/eeh.c b/arch/powerpc/kernel/eeh.c
index 55593ee..1fb331d 100644
--- a/arch/powerpc/kernel/eeh.c
+++ b/arch/powerpc/kernel/eeh.c
@@ -327,11 +327,11 @@ static int eeh_phb_check_failure(struct eeh_pe *pe)
/* Isolate the PHB and send event */
eeh_pe_state_mark(phb_pe, EEH_PE_ISOLATED);
eeh_serialize_unlock(flags);
- eeh_send_failure_event(phb_pe);
pr_err("EEH: PHB#%x failure detected\n",
phb_pe->phb->global_number);
dump_stack();
+ eeh_send_failure_event(phb_pe);
return 1;
out:
@@ -454,8 +454,6 @@ int eeh_dev_check_failure(struct eeh_dev *edev)
eeh_pe_state_mark(pe, EEH_PE_ISOLATED);
eeh_serialize_unlock(flags);
- eeh_send_failure_event(pe);
-
/* Most EEH events are due to device driver bugs. Having
* a stack trace will help the device-driver authors figure
* out what happened. So print that out.
@@ -464,6 +462,8 @@ int eeh_dev_check_failure(struct eeh_dev *edev)
pe->addr, pe->phb->global_number);
dump_stack();
+ eeh_send_failure_event(pe);
+
return 1;
dn_unlock:
--
1.7.5.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox