* Re: [PATCH 00/33] Build ppc64le kernel using ABIv2
From: Ulrich Weigand @ 2014-03-25 13:18 UTC (permalink / raw)
To: Anton Blanchard; +Cc: mikey, amodra, rusty, mjw, paulus, linuxppc-dev
In-Reply-To: <1395747879-5948-1-git-send-email-anton@samba.org>
Anton Blanchard <anton@samba.org> wrote on 25.03.2014 12:44:06:
> There are two known outstanding issues:
>
> - If a kernel module calls into an exported assembly function
> which in turns calls out to C, r2 is going to be wrong. One example
> is __copy_tofrom_user_power7.
>
> The reason is _GLOBAL() doesn't have a global entry point setup
> with the associated addis/addi used to create r2. I tried adding
> it and quickly realised that _GLOBAL is used places that will not
> tolerate the addi/addis (eg __start()).
You probably should have two different macros _GLOBAL_TOC vs. _GLOBAL
(or _GLOBAL vs. _GLOBAL_NOTOC), and use the variant that provides a
global entry point setting up the TOC only with those functions that
actually require a TOC.
> - arch/powerpc/platforms/pseries/hvCall.S assumes we always have a
> parameter save area, which is incorrect for ABIv2. I tried to be
> intelligent and use the toc save area to store some information
> but that failed as soon as we started using modules. It would be
> nice to avoid a stack frame in the common (tracepoints disabled)
> case, but we may end up having to allocate one.
When I looked at this last time, I remarked:
>./platforms/pseries/hvCall.S:
>./platforms/cell/beat_hvCall.S:
>Looks safe since all functions are called via varargs prototypes
>(or > 8 integer arguments).
Checking again, this still seems true. These are the prototypes
for all the functions in hvCall.S:
long plpar_hcall_norets(unsigned long opcode, ...);
long plpar_hcall(unsigned long opcode, unsigned long *retbuf, ...);
long plpar_hcall_raw(unsigned long opcode, unsigned long *retbuf, ...);
long plpar_hcall9(unsigned long opcode, unsigned long *retbuf, ...);
long plpar_hcall9_raw(unsigned long opcode, unsigned long *retbuf, ...);
Functions like that *will* always have a save area allocated by
the caller, even in the ELFv2 ABI.
Am I missing something here?
Bye,
Ulrich
^ permalink raw reply
* [PATCH v3 0/3] Support of the kmcoge4 board
From: Valentin Longchamp @ 2014-03-25 13:41 UTC (permalink / raw)
To: Scott Wood, linuxppc-dev; +Cc: devicetree, Valentin Longchamp
This series adds support for Keymile's COGE4 board, called kmcoge4. This
board is the reference design for further designs at Keymile around the
P2040/P2041 SoCs from Freescale. This reference design is internally
called kmp204x.
Changes in v3:
- add a patch with the bindings for the KEYMILE FPGAs
- add the compatible strings for the localbus nodes
- remove the IRQ part of the board-control node as it is currently being
reworked
Changes in v2:
- add a patch so that the Zarlink vendor prefix is defined
- add some nodes on the localbus CS when possible
- only use the corenet_generic machine and add kmcoge4 to the supported
boards instead of defining a new kmp204x machine
- set better and more precise device nodes for the spi devices
- remove the partion layout for the spi_flash@0
Valentin Longchamp (3):
devicetree: bindings: add Zarlink to the vendor prefixes
devcietree: bindings: add some MFD Keymile FPGAs
powerpc/mpc85xx: add support for Keymile's kmcoge4 board
Documentation/devicetree/bindings/mfd/bfticu.txt | 26 +++
Documentation/devicetree/bindings/mfd/qriox.txt | 17 ++
.../devicetree/bindings/vendor-prefixes.txt | 2 +
arch/powerpc/boot/dts/kmcoge4.dts | 157 ++++++++++++++
arch/powerpc/configs/85xx/kmp204x_defconfig | 227 +++++++++++++++++++++
arch/powerpc/platforms/85xx/Kconfig | 2 +-
arch/powerpc/platforms/85xx/corenet_generic.c | 3 +-
7 files changed, 432 insertions(+), 2 deletions(-)
create mode 100644 Documentation/devicetree/bindings/mfd/bfticu.txt
create mode 100644 Documentation/devicetree/bindings/mfd/qriox.txt
create mode 100644 arch/powerpc/boot/dts/kmcoge4.dts
create mode 100644 arch/powerpc/configs/85xx/kmp204x_defconfig
--
1.8.0.1
^ permalink raw reply
* [PATCH v3 1/3] devicetree: bindings: add Zarlink to the vendor prefixes
From: Valentin Longchamp @ 2014-03-25 13:41 UTC (permalink / raw)
To: Scott Wood, linuxppc-dev; +Cc: devicetree, Valentin Longchamp
In-Reply-To: <1395754915-14534-1-git-send-email-valentin.longchamp@keymile.com>
Even though the company belongs to Microsemi, many chips are still
labeled as Zarlink. Among them is the family of network clock generators,
the zl3034x.
Signed-off-by: Valentin Longchamp <valentin.longchamp@keymile.com>
---
Changes in v3: None
Changes in v2:
- add a patch so that the Zarlink vendor prefix is defined
Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 40ce2df..4a6eba0 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -95,3 +95,4 @@ winbond Winbond Electronics corp.
wlf Wolfson Microelectronics
wm Wondermedia Technologies, Inc.
xlnx Xilinx
+zarlink Zarlink Semiconductor
--
1.8.0.1
^ permalink raw reply related
* [PATCH v3 2/3] devcietree: bindings: add some MFD Keymile FPGAs
From: Valentin Longchamp @ 2014-03-25 13:41 UTC (permalink / raw)
To: Scott Wood, linuxppc-dev; +Cc: devicetree, Valentin Longchamp
In-Reply-To: <1395754915-14534-1-git-send-email-valentin.longchamp@keymile.com>
These are the bindings for 2 MFD devices used on some of the Keymile boards.
The first one is the chassis managmenet bfticu FPGA.
The second one is the board controller (reset, LEDs, GPIOs) QRIO CPDL.
These FPGAs are used in the kmcoge4 board.
This patch also add KEYMILE to the vendor-prefixes.
Signed-off-by: Valentin Longchamp <valentin.longchamp@keymile.com>
---
Changes in v3:
- add a patch with the bindings for the KEYMILE FPGAs
Changes in v2: None
Documentation/devicetree/bindings/mfd/bfticu.txt | 26 ++++++++++++++++++++++
Documentation/devicetree/bindings/mfd/qriox.txt | 17 ++++++++++++++
.../devicetree/bindings/vendor-prefixes.txt | 1 +
3 files changed, 44 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mfd/bfticu.txt
create mode 100644 Documentation/devicetree/bindings/mfd/qriox.txt
diff --git a/Documentation/devicetree/bindings/mfd/bfticu.txt b/Documentation/devicetree/bindings/mfd/bfticu.txt
new file mode 100644
index 0000000..92de32e
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/bfticu.txt
@@ -0,0 +1,26 @@
+KEYMILE bfticu Chassis Management FPGA
+
+The bfticu is a multifunction device that manages the whole chassis.
+Its main functionality is to collect IRQs from the whole chassis and signals
+them to a single controller.
+
+Required properties:
+- compatible: "keymile,bfticu"
+- interrupt-controller: the bfticu FPGA is an interrupt controller
+- interrupts: the main IRQ line to signal the collected IRQs
+- #interrupt-cells : is 2
+ - The 1st cell is the local IRQ number on the bfticu
+ - The 2nd cell is the type of the IRQ (IRQ_TYPE_xxx)
+- interrupt-parent: the parent IRQ ctrl the main IRQ is connected to
+- reg: access on the parent local bus (chip select, offset in chip select, size)
+
+Example:
+
+ chassis-mgmt@3,0 {
+ compatible = "keymile,bfticu";
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ reg = <3 0 0x100>;
+ interrupt-parent = <&mpic>;
+ interrupts = <6 1 0 0>;
+ };
diff --git a/Documentation/devicetree/bindings/mfd/qriox.txt b/Documentation/devicetree/bindings/mfd/qriox.txt
new file mode 100644
index 0000000..f301e2d
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/qriox.txt
@@ -0,0 +1,17 @@
+KEYMILE qrio Board Control CPLD
+
+The qrio is a multifunction device that controls the KEYMILE boards based on
+the kmp204x design.
+It is consists of a reset controller, watchdog timer, LEDs, and 2 IRQ capable
+GPIO blocks.
+
+Required properties:
+- compatible: "keymile,qriox"
+- reg: access on the parent local bus (chip select, offset in chip select, size)
+
+Example:
+
+ board-control@1,0 {
+ compatible = "keymile,qriox";
+ reg = <1 0 0x80>;
+ };
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 4a6eba0..913a007 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -49,6 +49,7 @@ img Imagination Technologies Ltd.
intercontrol Inter Control Group
isl Intersil
karo Ka-Ro electronics GmbH
+keymile KEYMILE GmbH
lg LG Corporation
linux Linux-specific binding
lsi LSI Corp. (LSI Logic)
--
1.8.0.1
^ permalink raw reply related
* [PATCH v3 3/3] powerpc/mpc85xx: add support for Keymile's kmcoge4 board
From: Valentin Longchamp @ 2014-03-25 13:41 UTC (permalink / raw)
To: Scott Wood, linuxppc-dev; +Cc: devicetree, Valentin Longchamp
In-Reply-To: <1395754915-14534-1-git-send-email-valentin.longchamp@keymile.com>
This patch introduces the support for Keymile's kmcoge4 board which is
the internal reference design for boards based on Freescale's
P2040/P2041 SoCs. This internal reference design is named kmp204x.
The peripherals used on this board are:
- SPI NOR Flash as bootloader medium
- NAND Flash with a ubi partition
- 2 PCIe busses (hosts 1 and 3)
- 3 FMAN Ethernet devices (FMAN1 DTSEC1/2/5)
- 4 Local Bus windows, with one dedicated to the QRIO reset/power mgmt
CPLD
- 2 I2C busses
- last but not least, the mandatory serial port
The patch also adds a defconfig file for this reference design that is
necessary because of the lowmem option that must be set higher due to
the number of PCIe devices with big ioremapped mem ranges on the boad.
Signed-off-by: Valentin Longchamp <valentin.longchamp@keymile.com>
---
Changes in v3:
- add the compatible strings for the localbus nodes
- remove the IRQ part of the board-control node as it is currently being
reworked
Changes in v2:
- add some nodes on the localbus CS when possible
- only use the corenet_generic machine and add kmcoge4 to the supported
boards instead of defining a new kmp204x machine
- set better and more precise device nodes for the spi devices
- remove the partion layout for the spi_flash@0
arch/powerpc/boot/dts/kmcoge4.dts | 157 ++++++++++++++++++
arch/powerpc/configs/85xx/kmp204x_defconfig | 227 ++++++++++++++++++++++++++
arch/powerpc/platforms/85xx/Kconfig | 2 +-
arch/powerpc/platforms/85xx/corenet_generic.c | 3 +-
4 files changed, 387 insertions(+), 2 deletions(-)
create mode 100644 arch/powerpc/boot/dts/kmcoge4.dts
create mode 100644 arch/powerpc/configs/85xx/kmp204x_defconfig
diff --git a/arch/powerpc/boot/dts/kmcoge4.dts b/arch/powerpc/boot/dts/kmcoge4.dts
new file mode 100644
index 0000000..bcd0263
--- /dev/null
+++ b/arch/powerpc/boot/dts/kmcoge4.dts
@@ -0,0 +1,157 @@
+/*
+ * Keymile kmcoge4 Device Tree Source, based on the P2041RDB DTS
+ *
+ * (C) Copyright 2014
+ * Valentin Longchamp, Keymile AG, valentin.longchamp@keymile.com
+ *
+ * Copyright 2011 Freescale Semiconductor 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.
+ */
+
+/include/ "fsl/p2041si-pre.dtsi"
+
+/ {
+ model = "keymile,kmcoge4";
+ compatible = "keymile,kmcoge4", "keymile,kmp204x";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ interrupt-parent = <&mpic>;
+
+ memory {
+ device_type = "memory";
+ };
+
+ dcsr: dcsr@f00000000 {
+ ranges = <0x00000000 0xf 0x00000000 0x01008000>;
+ };
+
+ soc: soc@ffe000000 {
+ ranges = <0x00000000 0xf 0xfe000000 0x1000000>;
+ reg = <0xf 0xfe000000 0 0x00001000>;
+ spi@110000 {
+ flash@0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "spansion,s25fl256s1";
+ reg = <0>;
+ spi-max-frequency = <20000000>; /* input clock */
+ };
+
+ network_clock@1 {
+ compatible = "zarlink,zl30343";
+ reg = <1>;
+ spi-max-frequency = <8000000>;
+ };
+
+ flash@2 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "micron,m25p32";
+ reg = <2>;
+ spi-max-frequency = <15000000>;
+ };
+ };
+
+ i2c@119000 {
+ status = "disabled";
+ };
+
+ i2c@119100 {
+ status = "disabled";
+ };
+
+ usb0: usb@210000 {
+ status = "disabled";
+ };
+
+ usb1: usb@211000 {
+ status = "disabled";
+ };
+
+ sata@220000 {
+ status = "disabled";
+ };
+
+ sata@221000 {
+ status = "disabled";
+ };
+ };
+
+ rio: rapidio@ffe0c0000 {
+ status = "disabled";
+ };
+
+ lbc: localbus@ffe124000 {
+ reg = <0xf 0xfe124000 0 0x1000>;
+ ranges = <0 0 0xf 0xffa00000 0x00040000 /* LB 0 */
+ 1 0 0xf 0xfb000000 0x00010000 /* LB 1 */
+ 2 0 0xf 0xd0000000 0x10000000 /* LB 2 */
+ 3 0 0xf 0xe0000000 0x10000000>; /* LB 3 */
+
+ nand@0,0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "fsl,elbc-fcm-nand";
+ reg = <0 0 0x40000>;
+
+ partition@0 {
+ label = "ubi0";
+ reg = <0x0 0x10000000>;
+ };
+ };
+
+ board-control@1,0 {
+ compatible = "keymile,qriox";
+ reg = <1 0 0x80>;
+ };
+
+ chassis-mgmt@3,0 {
+ compatible = "keymile,bfticu";
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ reg = <3 0 0x100>;
+ interrupt-parent = <&mpic>;
+ interrupts = <6 1 0 0>;
+ };
+ };
+
+ pci0: pcie@ffe200000 {
+ reg = <0xf 0xfe200000 0 0x1000>;
+ ranges = <0x02000000 0 0xe0000000 0xc 0x00000000 0x0 0x20000000
+ 0x01000000 0 0x00000000 0xf 0xf8000000 0x0 0x00010000>;
+ pcie@0 {
+ ranges = <0x02000000 0 0xe0000000
+ 0x02000000 0 0xe0000000
+ 0 0x20000000
+
+ 0x01000000 0 0x00000000
+ 0x01000000 0 0x00000000
+ 0 0x00010000>;
+ };
+ };
+
+ pci1: pcie@ffe201000 {
+ status = "disabled";
+ };
+
+ pci2: pcie@ffe202000 {
+ reg = <0xf 0xfe202000 0 0x1000>;
+ ranges = <0x02000000 0 0xe0000000 0xc 0x20000000 0 0x20000000
+ 0x01000000 0 0x00000000 0xf 0xf8010000 0 0x00010000>;
+ pcie@0 {
+ ranges = <0x02000000 0 0xe0000000
+ 0x02000000 0 0xe0000000
+ 0 0x20000000
+
+ 0x01000000 0 0x00000000
+ 0x01000000 0 0x00000000
+ 0 0x00010000>;
+ };
+ };
+};
+
+/include/ "fsl/p2041si-post.dtsi"
diff --git a/arch/powerpc/configs/85xx/kmp204x_defconfig b/arch/powerpc/configs/85xx/kmp204x_defconfig
new file mode 100644
index 0000000..afd9a3f
--- /dev/null
+++ b/arch/powerpc/configs/85xx/kmp204x_defconfig
@@ -0,0 +1,227 @@
+CONFIG_PPC_85xx=y
+CONFIG_SMP=y
+CONFIG_NR_CPUS=8
+CONFIG_SYSVIPC=y
+CONFIG_POSIX_MQUEUE=y
+CONFIG_AUDIT=y
+CONFIG_NO_HZ=y
+CONFIG_HIGH_RES_TIMERS=y
+CONFIG_BSD_PROCESS_ACCT=y
+CONFIG_IKCONFIG=y
+CONFIG_IKCONFIG_PROC=y
+CONFIG_LOG_BUF_SHIFT=14
+CONFIG_CGROUPS=y
+CONFIG_CGROUP_SCHED=y
+CONFIG_RELAY=y
+CONFIG_BLK_DEV_INITRD=y
+CONFIG_KALLSYMS_ALL=y
+CONFIG_EMBEDDED=y
+CONFIG_PERF_EVENTS=y
+CONFIG_SLAB=y
+CONFIG_MODULES=y
+CONFIG_MODULE_UNLOAD=y
+CONFIG_MODULE_FORCE_UNLOAD=y
+CONFIG_MODVERSIONS=y
+# CONFIG_BLK_DEV_BSG is not set
+CONFIG_PARTITION_ADVANCED=y
+CONFIG_MAC_PARTITION=y
+CONFIG_CORENET_GENERIC=y
+CONFIG_MPIC_MSGR=y
+CONFIG_HIGHMEM=y
+# CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set
+CONFIG_BINFMT_MISC=m
+CONFIG_KEXEC=y
+CONFIG_FORCE_MAX_ZONEORDER=13
+CONFIG_PCI=y
+CONFIG_PCIEPORTBUS=y
+# CONFIG_PCIEASPM is not set
+CONFIG_PCI_MSI=y
+CONFIG_ADVANCED_OPTIONS=y
+CONFIG_LOWMEM_SIZE_BOOL=y
+CONFIG_LOWMEM_SIZE=0x20000000
+CONFIG_NET=y
+CONFIG_PACKET=y
+CONFIG_UNIX=y
+CONFIG_XFRM_USER=y
+CONFIG_XFRM_SUB_POLICY=y
+CONFIG_XFRM_STATISTICS=y
+CONFIG_NET_KEY=y
+CONFIG_NET_KEY_MIGRATE=y
+CONFIG_INET=y
+CONFIG_IP_MULTICAST=y
+CONFIG_IP_ADVANCED_ROUTER=y
+CONFIG_IP_MULTIPLE_TABLES=y
+CONFIG_IP_ROUTE_MULTIPATH=y
+CONFIG_IP_ROUTE_VERBOSE=y
+CONFIG_IP_PNP=y
+CONFIG_IP_PNP_DHCP=y
+CONFIG_IP_PNP_BOOTP=y
+CONFIG_IP_PNP_RARP=y
+CONFIG_NET_IPIP=y
+CONFIG_IP_MROUTE=y
+CONFIG_IP_PIMSM_V1=y
+CONFIG_IP_PIMSM_V2=y
+CONFIG_INET_AH=y
+CONFIG_INET_ESP=y
+CONFIG_INET_IPCOMP=y
+# CONFIG_INET_LRO is not set
+CONFIG_IPV6=y
+CONFIG_IP_SCTP=m
+CONFIG_TIPC=y
+CONFIG_NET_SCHED=y
+CONFIG_NET_SCH_CBQ=y
+CONFIG_NET_SCH_HTB=y
+CONFIG_NET_SCH_HFSC=y
+CONFIG_NET_SCH_PRIO=y
+CONFIG_NET_SCH_MULTIQ=y
+CONFIG_NET_SCH_RED=y
+CONFIG_NET_SCH_SFQ=y
+CONFIG_NET_SCH_TEQL=y
+CONFIG_NET_SCH_TBF=y
+CONFIG_NET_SCH_GRED=y
+CONFIG_NET_CLS_BASIC=y
+CONFIG_NET_CLS_TCINDEX=y
+CONFIG_NET_CLS_U32=y
+CONFIG_CLS_U32_PERF=y
+CONFIG_CLS_U32_MARK=y
+CONFIG_NET_CLS_FLOW=y
+CONFIG_NET_CLS_CGROUP=y
+CONFIG_UEVENT_HELPER_PATH="/sbin/mdev"
+CONFIG_DEVTMPFS=y
+CONFIG_MTD=y
+CONFIG_MTD_CMDLINE_PARTS=y
+CONFIG_MTD_BLOCK=y
+CONFIG_MTD_CFI=y
+CONFIG_MTD_CFI_AMDSTD=y
+CONFIG_MTD_PHYSMAP_OF=y
+CONFIG_MTD_M25P80=y
+CONFIG_MTD_PHRAM=y
+CONFIG_MTD_NAND=y
+CONFIG_MTD_NAND_ECC_BCH=y
+CONFIG_MTD_NAND_FSL_ELBC=y
+CONFIG_MTD_UBI=y
+CONFIG_MTD_UBI_GLUEBI=y
+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=2048
+CONFIG_EEPROM_AT24=y
+CONFIG_SCSI=y
+CONFIG_BLK_DEV_SD=y
+CONFIG_CHR_DEV_ST=y
+CONFIG_BLK_DEV_SR=y
+CONFIG_CHR_DEV_SG=y
+CONFIG_SCSI_MULTI_LUN=y
+CONFIG_SCSI_LOGGING=y
+CONFIG_SCSI_SYM53C8XX_2=y
+CONFIG_NETDEVICES=y
+# CONFIG_NET_VENDOR_3COM is not set
+# CONFIG_NET_VENDOR_ADAPTEC is not set
+# CONFIG_NET_VENDOR_ALTEON is not set
+# CONFIG_NET_VENDOR_AMD is not set
+# CONFIG_NET_VENDOR_ATHEROS is not set
+# CONFIG_NET_CADENCE is not set
+# CONFIG_NET_VENDOR_BROADCOM is not set
+# CONFIG_NET_VENDOR_BROCADE is not set
+# CONFIG_NET_VENDOR_CHELSIO is not set
+# CONFIG_NET_VENDOR_CISCO is not set
+# CONFIG_NET_VENDOR_DEC is not set
+# CONFIG_NET_VENDOR_DLINK is not set
+# CONFIG_NET_VENDOR_EMULEX is not set
+# CONFIG_NET_VENDOR_EXAR is not set
+CONFIG_FSL_PQ_MDIO=y
+CONFIG_FSL_XGMAC_MDIO=y
+# CONFIG_NET_VENDOR_HP is not set
+# CONFIG_NET_VENDOR_INTEL is not set
+# CONFIG_NET_VENDOR_MARVELL is not set
+# CONFIG_NET_VENDOR_MELLANOX is not set
+# CONFIG_NET_VENDOR_MICREL is not set
+# CONFIG_NET_VENDOR_MICROCHIP is not set
+# CONFIG_NET_VENDOR_MYRI is not set
+# CONFIG_NET_VENDOR_NATSEMI is not set
+# CONFIG_NET_VENDOR_NVIDIA is not set
+# CONFIG_NET_VENDOR_OKI is not set
+# CONFIG_NET_PACKET_ENGINE is not set
+# CONFIG_NET_VENDOR_QLOGIC is not set
+# CONFIG_NET_VENDOR_REALTEK is not set
+# CONFIG_NET_VENDOR_RDC is not set
+# CONFIG_NET_VENDOR_SEEQ is not set
+# CONFIG_NET_VENDOR_SILAN is not set
+# CONFIG_NET_VENDOR_SIS is not set
+# CONFIG_NET_VENDOR_SMSC is not set
+# CONFIG_NET_VENDOR_STMICRO is not set
+# CONFIG_NET_VENDOR_SUN is not set
+# CONFIG_NET_VENDOR_TEHUTI is not set
+# CONFIG_NET_VENDOR_TI is not set
+# CONFIG_NET_VENDOR_VIA is not set
+# CONFIG_NET_VENDOR_WIZNET is not set
+# CONFIG_NET_VENDOR_XILINX is not set
+CONFIG_MARVELL_PHY=y
+CONFIG_VITESSE_PHY=y
+CONFIG_FIXED_PHY=y
+# CONFIG_WLAN is not set
+# CONFIG_INPUT_MOUSEDEV is not set
+# CONFIG_INPUT_KEYBOARD is not set
+# CONFIG_INPUT_MOUSE is not set
+CONFIG_SERIO_LIBPS2=y
+# CONFIG_LEGACY_PTYS is not set
+CONFIG_PPC_EPAPR_HV_BYTECHAN=y
+CONFIG_SERIAL_8250=y
+CONFIG_SERIAL_8250_CONSOLE=y
+CONFIG_SERIAL_8250_MANY_PORTS=y
+CONFIG_SERIAL_8250_DETECT_IRQ=y
+CONFIG_SERIAL_8250_RSA=y
+CONFIG_NVRAM=y
+CONFIG_I2C=y
+CONFIG_I2C_CHARDEV=y
+CONFIG_I2C_MUX=y
+CONFIG_I2C_MUX_PCA954x=y
+CONFIG_I2C_MPC=y
+CONFIG_SPI=y
+CONFIG_SPI_FSL_SPI=y
+CONFIG_SPI_FSL_ESPI=y
+CONFIG_SPI_SPIDEV=m
+CONFIG_PTP_1588_CLOCK=y
+# CONFIG_HWMON is not set
+CONFIG_VIDEO_OUTPUT_CONTROL=y
+# CONFIG_USB_SUPPORT is not set
+CONFIG_EDAC=y
+CONFIG_EDAC_MM_EDAC=y
+CONFIG_EDAC_MPC85XX=y
+CONFIG_RTC_CLASS=y
+CONFIG_RTC_DRV_DS3232=y
+CONFIG_RTC_DRV_CMOS=y
+CONFIG_UIO=y
+CONFIG_STAGING=y
+# CONFIG_NET_VENDOR_SILICOM is not set
+CONFIG_CLK_PPC_CORENET=y
+CONFIG_EXT2_FS=y
+CONFIG_NTFS_FS=y
+CONFIG_PROC_KCORE=y
+CONFIG_TMPFS=y
+CONFIG_JFFS2_FS=y
+CONFIG_UBIFS_FS=y
+CONFIG_CRAMFS=y
+CONFIG_SQUASHFS=y
+CONFIG_SQUASHFS_XZ=y
+CONFIG_NFS_FS=y
+CONFIG_NFS_V4=y
+CONFIG_ROOT_NFS=y
+CONFIG_NLS_ISO8859_1=y
+CONFIG_NLS_UTF8=m
+CONFIG_CRC_ITU_T=m
+CONFIG_DEBUG_INFO=y
+CONFIG_MAGIC_SYSRQ=y
+CONFIG_DEBUG_SHIRQ=y
+CONFIG_DETECT_HUNG_TASK=y
+CONFIG_SCHEDSTATS=y
+CONFIG_RCU_TRACE=y
+CONFIG_UPROBE_EVENT=y
+CONFIG_CRYPTO_NULL=y
+CONFIG_CRYPTO_PCBC=m
+CONFIG_CRYPTO_MD4=y
+CONFIG_CRYPTO_SHA256=y
+CONFIG_CRYPTO_SHA512=y
+# CONFIG_CRYPTO_ANSI_CPRNG is not set
+CONFIG_CRYPTO_DEV_FSL_CAAM=y
diff --git a/arch/powerpc/platforms/85xx/Kconfig b/arch/powerpc/platforms/85xx/Kconfig
index c17aae8..fb98fd6 100644
--- a/arch/powerpc/platforms/85xx/Kconfig
+++ b/arch/powerpc/platforms/85xx/Kconfig
@@ -263,7 +263,7 @@ config CORENET_GENERIC
help
This option enables support for the FSL CoreNet based boards.
For 32bit kernel, the following boards are supported:
- P2041 RDB, P3041 DS and P4080 DS
+ P2041 RDB, P3041 DS, P4080 DS and kmcoge4
For 64bit kernel, the following boards are supported:
T4240 QDS and B4 QDS
The following boards are supported for both 32bit and 64bit kernel:
diff --git a/arch/powerpc/platforms/85xx/corenet_generic.c b/arch/powerpc/platforms/85xx/corenet_generic.c
index fbd871e..8c065ae 100644
--- a/arch/powerpc/platforms/85xx/corenet_generic.c
+++ b/arch/powerpc/platforms/85xx/corenet_generic.c
@@ -56,7 +56,7 @@ void __init corenet_gen_setup_arch(void)
swiotlb_detect_4g();
- pr_info("%s board from Freescale Semiconductor\n", ppc_md.name);
+ pr_info("%s board\n", ppc_md.name);
}
static const struct of_device_id of_device_ids[] = {
@@ -106,6 +106,7 @@ static const char * const boards[] __initconst = {
"fsl,B4860QDS",
"fsl,B4420QDS",
"fsl,B4220QDS",
+ "keymile,kmcoge4",
NULL
};
--
1.8.0.1
^ permalink raw reply related
* Re: [PATCH v3 1/3] devicetree: bindings: add Zarlink to the vendor prefixes
From: Rob Herring @ 2014-03-25 13:56 UTC (permalink / raw)
To: Valentin Longchamp; +Cc: Scott Wood, devicetree@vger.kernel.org, linuxppc-dev
In-Reply-To: <1395754915-14534-2-git-send-email-valentin.longchamp@keymile.com>
On Tue, Mar 25, 2014 at 8:41 AM, Valentin Longchamp
<valentin.longchamp@keymile.com> wrote:
> Even though the company belongs to Microsemi, many chips are still
> labeled as Zarlink. Among them is the family of network clock generators,
> the zl3034x.
>
> Signed-off-by: Valentin Longchamp <valentin.longchamp@keymile.com>
Acked-by: Rob Herring <robh@kernel.org>
>
> ---
> Changes in v3: None
> Changes in v2:
> - add a patch so that the Zarlink vendor prefix is defined
>
> Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
> index 40ce2df..4a6eba0 100644
> --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
> +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
> @@ -95,3 +95,4 @@ winbond Winbond Electronics corp.
> wlf Wolfson Microelectronics
> wm Wondermedia Technologies, Inc.
> xlnx Xilinx
> +zarlink Zarlink Semiconductor
> --
> 1.8.0.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] video/fsl: Fix the sleep function for FSL DIU module
From: Timur Tabi @ 2014-03-25 15:54 UTC (permalink / raw)
To: Dongsheng Wang; +Cc: scottwood, linux-fbdev, linuxppc-dev, jason.jin
In-Reply-To: <1395734180-45012-1-git-send-email-dongsheng.wang@freescale.com>
On 03/25/2014 02:56 AM, Dongsheng Wang wrote:
> From: Jason Jin <Jason.Jin@freescale.com>
>
> For deep sleep, the diu module will power off, when wake up
> from the deep sleep, the registers need to be reinitialized.
>
> Signed-off-by: Jason Jin <Jason.Jin@freescale.com>
> Signed-off-by: Wang Dongsheng <dongsheng.wang@freescale.com>
>
> diff --git a/drivers/video/fsl-diu-fb.c b/drivers/video/fsl-diu-fb.c
> index e8758b9..7ec780c 100644
> --- a/drivers/video/fsl-diu-fb.c
> +++ b/drivers/video/fsl-diu-fb.c
> @@ -1628,9 +1628,18 @@ static int fsl_diu_suspend(struct platform_device *ofdev, pm_message_t state)
> static int fsl_diu_resume(struct platform_device *ofdev)
> {
> struct fsl_diu_data *data;
> + struct mfb_info *mfbi;
You don't need this, if ...
> + int i;
>
> data = dev_get_drvdata(&ofdev->dev);
> - enable_lcdc(data->fsl_diu_info);
> + fsl_diu_enable_interrupts(data);
> + update_lcdc(data->fsl_diu_info);
> +
> + for (i = 0; i < NUM_AOIS; i++) {
> + mfbi = &data->mfb[i];
> + if (mfbi->count)
... you do this:
if (data->mfb[i].count)
Also, 'i' should be an 'unsigned int'.
> + fsl_diu_enable_panel(&data->fsl_diu_info[i]);
> + }
>
> return 0;
> }
>
Other than that, this seems okay.
^ permalink raw reply
* Re: Bug in reclaim logic with exhausted nodes?
From: Christoph Lameter @ 2014-03-25 16:17 UTC (permalink / raw)
To: Nishanth Aravamudan; +Cc: linux-mm, mgorman, linuxppc-dev, anton, rientjes
In-Reply-To: <20140324230550.GB18778@linux.vnet.ibm.com>
On Mon, 24 Mar 2014, Nishanth Aravamudan wrote:
> Anyone have any ideas here?
Dont do that? Check on boot to not allow exhausting a node with huge
pages?
^ permalink raw reply
* Re: Bug in reclaim logic with exhausted nodes?
From: Nishanth Aravamudan @ 2014-03-25 16:23 UTC (permalink / raw)
To: Christoph Lameter; +Cc: linux-mm, mgorman, linuxppc-dev, anton, rientjes
In-Reply-To: <alpine.DEB.2.10.1403251116490.16557@nuc>
On 25.03.2014 [11:17:57 -0500], Christoph Lameter wrote:
> On Mon, 24 Mar 2014, Nishanth Aravamudan wrote:
>
> > Anyone have any ideas here?
>
> Dont do that? Check on boot to not allow exhausting a node with huge
> pages?
Gigantic hugepages are allocated by the hypervisor (not the Linux VM),
and we don't control where the allocation occurs. Yes, ideally, they
would be interleaved to avoid this situation, but I can also see reasons
for having them all be from one node so that tasks can be affinitized
and get the guarantee of the 16GB pagesize benefit.
Thanks,
Nish
^ permalink raw reply
* Re: Bug in reclaim logic with exhausted nodes?
From: Christoph Lameter @ 2014-03-25 16:53 UTC (permalink / raw)
To: Nishanth Aravamudan; +Cc: linux-mm, mgorman, linuxppc-dev, anton, rientjes
In-Reply-To: <20140325162303.GA29977@linux.vnet.ibm.com>
On Tue, 25 Mar 2014, Nishanth Aravamudan wrote:
> On 25.03.2014 [11:17:57 -0500], Christoph Lameter wrote:
> > On Mon, 24 Mar 2014, Nishanth Aravamudan wrote:
> >
> > > Anyone have any ideas here?
> >
> > Dont do that? Check on boot to not allow exhausting a node with huge
> > pages?
>
> Gigantic hugepages are allocated by the hypervisor (not the Linux VM),
Ok so the kernel starts booting up and then suddenly the hypervisor takes
the 2 16G pages before even the slab allocator is working?
Not sure if I understand that correctly.
^ permalink raw reply
* Re: [PATCH 1/1] mm: move FAULT_AROUND_ORDER to arch/
From: Kirill A. Shutemov @ 2014-03-25 17:36 UTC (permalink / raw)
To: Madhavan Srinivasan
Cc: linux-arch, riel, rusty, peterz, x86, linux-kernel, linux-mm, ak,
paulus, mgorman, akpm, linuxppc-dev, mingo, kirill.shutemov
In-Reply-To: <1395730215-11604-2-git-send-email-maddy@linux.vnet.ibm.com>
On Tue, Mar 25, 2014 at 12:20:15PM +0530, Madhavan Srinivasan wrote:
> Kirill A. Shutemov with the commit 96bacfe542 introduced
> vm_ops->map_pages() for mapping easy accessible pages around
> fault address in hope to reduce number of minor page faults.
> Based on his workload runs, suggested FAULT_AROUND_ORDER
> (knob to control the numbers of pages to map) is 4.
>
> This patch moves the FAULT_AROUND_ORDER macro to arch/ for
> architecture maintainers to decide on suitable FAULT_AROUND_ORDER
> value based on performance data for that architecture.
>
> Signed-off-by: Madhavan Srinivasan <maddy@linux.vnet.ibm.com>
> ---
> arch/powerpc/include/asm/pgtable.h | 6 ++++++
> arch/x86/include/asm/pgtable.h | 5 +++++
> include/asm-generic/pgtable.h | 10 ++++++++++
> mm/memory.c | 2 --
> 4 files changed, 21 insertions(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/pgtable.h b/arch/powerpc/include/asm/pgtable.h
> index 3ebb188..9fcbd48 100644
> --- a/arch/powerpc/include/asm/pgtable.h
> +++ b/arch/powerpc/include/asm/pgtable.h
> @@ -19,6 +19,12 @@ struct mm_struct;
> #endif
>
> /*
> + * With a few real world workloads that were run,
> + * the performance data showed that a value of 3 is more advantageous.
> + */
> +#define FAULT_AROUND_ORDER 3
> +
> +/*
> * We save the slot number & secondary bit in the second half of the
> * PTE page. We use the 8 bytes per each pte entry.
> */
> diff --git a/arch/x86/include/asm/pgtable.h b/arch/x86/include/asm/pgtable.h
> index 938ef1d..8387a65 100644
> --- a/arch/x86/include/asm/pgtable.h
> +++ b/arch/x86/include/asm/pgtable.h
> @@ -7,6 +7,11 @@
> #include <asm/pgtable_types.h>
>
> /*
> + * Based on Kirill's test results, fault around order is set to 4
> + */
> +#define FAULT_AROUND_ORDER 4
> +
> +/*
> * Macro to mark a page protection value as UC-
> */
> #define pgprot_noncached(prot) \
> diff --git a/include/asm-generic/pgtable.h b/include/asm-generic/pgtable.h
> index 1ec08c1..62f7f07 100644
> --- a/include/asm-generic/pgtable.h
> +++ b/include/asm-generic/pgtable.h
> @@ -7,6 +7,16 @@
> #include <linux/mm_types.h>
> #include <linux/bug.h>
>
> +
> +/*
> + * Fault around order is a control knob to decide the fault around pages.
> + * Default value is set to 0UL (disabled), but the arch can override it as
> + * desired.
> + */
> +#ifndef FAULT_AROUND_ORDER
> +#define FAULT_AROUND_ORDER 0UL
> +#endif
FAULT_AROUND_ORDER == 0 case should be handled separately in
do_read_fault(): no reason to go to do_fault_around() if we are going to
fault in only one page.
--
Kirill A. Shutemov
^ permalink raw reply
* Re: [PATCH 1/1] mm: move FAULT_AROUND_ORDER to arch/
From: Dave Hansen @ 2014-03-25 17:50 UTC (permalink / raw)
To: Kirill A. Shutemov, Madhavan Srinivasan
Cc: linux-arch, riel, rusty, peterz, x86, linux-kernel, linux-mm, ak,
paulus, mgorman, akpm, linuxppc-dev, mingo, kirill.shutemov
In-Reply-To: <20140325173605.GA21411@node.dhcp.inet.fi>
On 03/25/2014 10:36 AM, Kirill A. Shutemov wrote:
>> > +/*
>> > + * Fault around order is a control knob to decide the fault around pages.
>> > + * Default value is set to 0UL (disabled), but the arch can override it as
>> > + * desired.
>> > + */
>> > +#ifndef FAULT_AROUND_ORDER
>> > +#define FAULT_AROUND_ORDER 0UL
>> > +#endif
> FAULT_AROUND_ORDER == 0 case should be handled separately in
> do_read_fault(): no reason to go to do_fault_around() if we are going to
> fault in only one page.
Isn't this the kind of thing we want to do in Kconfig?
^ permalink raw reply
* Re: Bug in reclaim logic with exhausted nodes?
From: Nishanth Aravamudan @ 2014-03-25 18:10 UTC (permalink / raw)
To: Christoph Lameter; +Cc: linux-mm, mgorman, linuxppc-dev, anton, rientjes
In-Reply-To: <alpine.DEB.2.10.1403251152250.16870@nuc>
On 25.03.2014 [11:53:48 -0500], Christoph Lameter wrote:
> On Tue, 25 Mar 2014, Nishanth Aravamudan wrote:
>
> > On 25.03.2014 [11:17:57 -0500], Christoph Lameter wrote:
> > > On Mon, 24 Mar 2014, Nishanth Aravamudan wrote:
> > >
> > > > Anyone have any ideas here?
> > >
> > > Dont do that? Check on boot to not allow exhausting a node with huge
> > > pages?
> >
> > Gigantic hugepages are allocated by the hypervisor (not the Linux VM),
>
> Ok so the kernel starts booting up and then suddenly the hypervisor takes
> the 2 16G pages before even the slab allocator is working?
There is nothing "sudden" about it.
On power, very early, we find the 16G pages (gpages in the powerpc arch
code) in the device-tree:
early_setup ->
early_init_mmu ->
htab_initialize ->
htab_init_page_sizes ->
htab_dt_scan_hugepage_blocks ->
memblock_reserve
which marks the memory
as reserved
add_gpage
which saves the address
off so future calls for
alloc_bootmem_huge_page()
hugetlb_init ->
hugetlb_init_hstates ->
hugetlb_hstate_alloc_pages ->
alloc_bootmem_huge_page
> Not sure if I understand that correctly.
Basically this is present memory that is "reserved" for the 16GB usage
per the LPAR configuration. We honor that configuration in Linux based
upon the contents of the device-tree. It just so happens in the
configuration from my original e-mail that a consequence of this is that
a NUMA node has memory (topologically), but none of that memory is free,
nor will it ever be free.
Perhaps, in this case, we could just remove that node from the N_MEMORY
mask? Memory allocations will never succeed from the node, and we can
never free these 16GB pages. It is really not any different than a
memoryless node *except* when you are using the 16GB pages.
Thanks,
Nish
^ permalink raw reply
* Re: [PATCH v4 09/11] powerpc/perf: add support for the hv 24x7 interface
From: Cody P Schafer @ 2014-03-25 18:19 UTC (permalink / raw)
To: Anton Blanchard
Cc: Peter Zijlstra, LKML, Michael Ellerman, Ingo Molnar,
Paul Mackerras, Arnaldo Carvalho de Melo, scottwood, Linux PPC
In-Reply-To: <20140325214356.4a2f7d95@kryten>
On 03/25/2014 03:43 AM, Anton Blanchard wrote:
>
> Hi Cody,
>
> hv-24x7: could not obtain capabilities, error 0x fffffffffffffffe, not enabling
> hv-gpci: could not obtain capabilities, error 0x fffffffffffffffe, not enabling
>
>> + pr_info("could not obtain capabilities, error 0x%80lx, not enabling\n",
>
> That's a lot of padding :)
>
> I think this should also be a pr_debug, considering this is not relevant
> to most ppc64 boxes.
I'm fine with that. It should probably be "0x%08lx" not "0x%80lx", not
sure when I screwed that up.
^ permalink raw reply
* Re: Bug in reclaim logic with exhausted nodes?
From: Christoph Lameter @ 2014-03-25 18:25 UTC (permalink / raw)
To: Nishanth Aravamudan; +Cc: linux-mm, mgorman, linuxppc-dev, anton, rientjes
In-Reply-To: <20140325181010.GB29977@linux.vnet.ibm.com>
On Tue, 25 Mar 2014, Nishanth Aravamudan wrote:
> On power, very early, we find the 16G pages (gpages in the powerpc arch
> code) in the device-tree:
>
> early_setup ->
> early_init_mmu ->
> htab_initialize ->
> htab_init_page_sizes ->
> htab_dt_scan_hugepage_blocks ->
> memblock_reserve
> which marks the memory
> as reserved
> add_gpage
> which saves the address
> off so future calls for
> alloc_bootmem_huge_page()
>
> hugetlb_init ->
> hugetlb_init_hstates ->
> hugetlb_hstate_alloc_pages ->
> alloc_bootmem_huge_page
>
> > Not sure if I understand that correctly.
>
> Basically this is present memory that is "reserved" for the 16GB usage
> per the LPAR configuration. We honor that configuration in Linux based
> upon the contents of the device-tree. It just so happens in the
> configuration from my original e-mail that a consequence of this is that
> a NUMA node has memory (topologically), but none of that memory is free,
> nor will it ever be free.
Well dont do that
> Perhaps, in this case, we could just remove that node from the N_MEMORY
> mask? Memory allocations will never succeed from the node, and we can
> never free these 16GB pages. It is really not any different than a
> memoryless node *except* when you are using the 16GB pages.
That looks to be the correct way to handle things. Maybe mark the node as
offline or somehow not present so that the kernel ignores it.
^ permalink raw reply
* Re: [PATCH v4 09/11] powerpc/perf: add support for the hv 24x7 interface
From: Cody P Schafer @ 2014-03-25 18:32 UTC (permalink / raw)
To: Anton Blanchard
Cc: Peter Zijlstra, LKML, Michael Ellerman, Ingo Molnar,
Paul Mackerras, Arnaldo Carvalho de Melo, scottwood, Linux PPC
In-Reply-To: <20140325214356.4a2f7d95@kryten>
On 03/25/2014 03:43 AM, Anton Blanchard wrote:
>
> Hi Cody,
>
> hv-24x7: could not obtain capabilities, error 0x fffffffffffffffe, not enabling
> hv-gpci: could not obtain capabilities, error 0x fffffffffffffffe, not enabling
>
>> + pr_info("could not obtain capabilities, error 0x%80lx, not enabling\n",
>
> That's a lot of padding :)
>
> I think this should also be a pr_debug, considering this is not relevant
> to most ppc64 boxes.
Yep, s/info/debug/ makes sense. The format should have been "%08lx" not
"%80lx", not sure when I screwed that up.
^ permalink raw reply
* Re: Bug in reclaim logic with exhausted nodes?
From: Nishanth Aravamudan @ 2014-03-25 18:37 UTC (permalink / raw)
To: Christoph Lameter; +Cc: linux-mm, mgorman, linuxppc-dev, anton, rientjes
In-Reply-To: <alpine.DEB.2.10.1403251323030.26744@nuc>
On 25.03.2014 [13:25:30 -0500], Christoph Lameter wrote:
> On Tue, 25 Mar 2014, Nishanth Aravamudan wrote:
>
> > On power, very early, we find the 16G pages (gpages in the powerpc arch
> > code) in the device-tree:
> >
> > early_setup ->
> > early_init_mmu ->
> > htab_initialize ->
> > htab_init_page_sizes ->
> > htab_dt_scan_hugepage_blocks ->
> > memblock_reserve
> > which marks the memory
> > as reserved
> > add_gpage
> > which saves the address
> > off so future calls for
> > alloc_bootmem_huge_page()
> >
> > hugetlb_init ->
> > hugetlb_init_hstates ->
> > hugetlb_hstate_alloc_pages ->
> > alloc_bootmem_huge_page
> >
> > > Not sure if I understand that correctly.
> >
> > Basically this is present memory that is "reserved" for the 16GB usage
> > per the LPAR configuration. We honor that configuration in Linux based
> > upon the contents of the device-tree. It just so happens in the
> > configuration from my original e-mail that a consequence of this is that
> > a NUMA node has memory (topologically), but none of that memory is free,
> > nor will it ever be free.
>
> Well dont do that
I appreciate the help you're offering, but that's really not an option.
The customer/user has configured the system in such a way so they can
leverage the gigantic pages. And *most* everything seems to work fine
except for the case I mentioned in my original e-mail. I guess we could
fewer 16GB pages if it would exhaust a NUMA node, but ... I think the
underlying mapping would be a 16GB one, so it will not be accurate from
a performance perspective (although it should perform better).
> > Perhaps, in this case, we could just remove that node from the N_MEMORY
> > mask? Memory allocations will never succeed from the node, and we can
> > never free these 16GB pages. It is really not any different than a
> > memoryless node *except* when you are using the 16GB pages.
>
> That looks to be the correct way to handle things. Maybe mark the node as
> offline or somehow not present so that the kernel ignores it.
Ok, I'll consider these options. Thanks!
-Nish
^ permalink raw reply
* [PATCH 0/5] Convert last few uses of __FUNCTION__ to __func__
From: Joe Perches @ 2014-03-25 19:35 UTC (permalink / raw)
To: linux-kernel
Cc: intel-gfx, dri-devel, linux-mm, xen-devel, linuxppc-dev,
drbd-user
Outside of staging, there aren't any more uses of __FUNCTION__ now...
Joe Perches (5):
powerpc: Convert last uses of __FUNCTION__ to __func__
x86: Convert last uses of __FUNCTION__ to __func__
block: Convert last uses of __FUNCTION__ to __func__
i915: Convert last uses of __FUNCTION__ to __func__
slab: Convert last uses of __FUNCTION__ to __func__
arch/powerpc/platforms/pseries/nvram.c | 11 +++++------
arch/x86/kernel/hpet.c | 2 +-
arch/x86/kernel/rtc.c | 4 ++--
arch/x86/platform/intel-mid/intel_mid_vrtc.c | 2 +-
drivers/block/drbd/drbd_int.h | 8 ++++----
drivers/block/xen-blkfront.c | 4 ++--
drivers/gpu/drm/i915/dvo_ns2501.c | 15 ++++++---------
mm/slab.h | 2 +-
8 files changed, 22 insertions(+), 26 deletions(-)
--
1.8.1.2.459.gbcd45b4.dirty
^ permalink raw reply
* [PATCH 1/5] powerpc: Convert last uses of __FUNCTION__ to __func__
From: Joe Perches @ 2014-03-25 19:35 UTC (permalink / raw)
To: linux-kernel; +Cc: Paul Mackerras, linuxppc-dev
In-Reply-To: <cover.1395775901.git.joe@perches.com>
Just about all of these have been converted to __func__,
so convert the last uses.
Signed-off-by: Joe Perches <joe@perches.com>
---
arch/powerpc/platforms/pseries/nvram.c | 11 +++++------
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/nvram.c b/arch/powerpc/platforms/pseries/nvram.c
index d7096f2..0cc240b 100644
--- a/arch/powerpc/platforms/pseries/nvram.c
+++ b/arch/powerpc/platforms/pseries/nvram.c
@@ -298,13 +298,13 @@ int nvram_write_os_partition(struct nvram_os_partition *part, char * buff,
rc = ppc_md.nvram_write((char *)&info, sizeof(struct err_log_info), &tmp_index);
if (rc <= 0) {
- pr_err("%s: Failed nvram_write (%d)\n", __FUNCTION__, rc);
+ pr_err("%s: Failed nvram_write (%d)\n", __func__, rc);
return rc;
}
rc = ppc_md.nvram_write(buff, length, &tmp_index);
if (rc <= 0) {
- pr_err("%s: Failed nvram_write (%d)\n", __FUNCTION__, rc);
+ pr_err("%s: Failed nvram_write (%d)\n", __func__, rc);
return rc;
}
@@ -351,15 +351,14 @@ int nvram_read_partition(struct nvram_os_partition *part, char *buff,
sizeof(struct err_log_info),
&tmp_index);
if (rc <= 0) {
- pr_err("%s: Failed nvram_read (%d)\n", __FUNCTION__,
- rc);
+ pr_err("%s: Failed nvram_read (%d)\n", __func__, rc);
return rc;
}
}
rc = ppc_md.nvram_read(buff, length, &tmp_index);
if (rc <= 0) {
- pr_err("%s: Failed nvram_read (%d)\n", __FUNCTION__, rc);
+ pr_err("%s: Failed nvram_read (%d)\n", __func__, rc);
return rc;
}
@@ -869,7 +868,7 @@ static void oops_to_nvram(struct kmsg_dumper *dumper,
break;
default:
pr_err("%s: ignoring unrecognized KMSG_DUMP_* reason %d\n",
- __FUNCTION__, (int) reason);
+ __func__, (int) reason);
return;
}
--
1.8.1.2.459.gbcd45b4.dirty
^ permalink raw reply related
* Re: Ask for help about fsl ppc toolchian issue "Illegal instruction"
From: Scott Wood @ 2014-03-25 23:05 UTC (permalink / raw)
To: wyang; +Cc: 许久成, linuxppc-dev@ozlabs.org
In-Reply-To: <533114A4.4080608@gmail.com>
On Tue, 2014-03-25 at 13:31 +0800, wyang wrote:
>
> On 03/25/2014 10:17 AM, 许久成 wrote:
>
> > Hi All,
> >
> >
> > We run into an issue when use e500mc toolchain g++ to compile c++
> > code for p2020 platform, the code as below:
>
> Hmm, p2020 should be e500 core rather than e500mc. Additionally, you
> should use gdb to debug it, and check which instruction is illegal.
It's probably a floating point instruction. e500v2 (and thus p2020)
does not support normal PPC floating point. You need to use the right
toolchain.
-Scott
^ permalink raw reply
* Re: [RFC PATCH] Remove CONFIG_DCACHE_WORD_ACCESS
From: Joe Perches @ 2014-03-26 4:54 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Anton Blanchard
Cc: linux-arch, Russell King, Catalin Marinas, x86, Will Deacon,
linux-kernel, Ingo Molnar, Paul Mackerras, Alexander Viro,
H. Peter Anvin, linux-fsdevel, Thomas Gleixner, linuxppc-dev,
linux-arm-kernel
In-Reply-To: <1394570240.4840.48.camel@pasglop>
On Wed, 2014-03-12 at 07:37 +1100, Benjamin Herrenschmidt wrote:
> On Tue, 2014-03-04 at 12:23 -0800, Joe Perches wrote:
> > It seems to duplicate CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS
> > so use that instead.
> >
> > This changes the !CPU_LITTLE_ENDIAN powerpc arch to use unaligned
> > accesses in fs/dcache.c and fs/namei.c as
> > CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS is enabled for that arch.
> >
> > Remove the now unused DCACHE_WORD_ACCESS defines & uses.
>
> Interesting.. we have word-at-a-time but we never enabled
> DCACHE_WORD_ACCESS, I wonder why that is. In fact, we should
> probably do it for LE as well for P8 if we can make a P8
> only config option...
>
> Anton, what do you reckon here ?
Anton, do you have an opinion here?
> Cheers,
> Ben.
>
> > Signed-off-by: Joe Perches <joe@perches.com>
> > ---
> > arch/arm/Kconfig | 1 -
> > arch/arm/include/asm/word-at-a-time.h | 4 ++--
> > arch/arm64/Kconfig | 1 -
> > arch/x86/Kconfig | 1 -
> > fs/Kconfig | 4 ----
> > fs/dcache.c | 2 +-
> > fs/namei.c | 2 +-
> > 7 files changed, 4 insertions(+), 11 deletions(-)
> >
> > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> > index 623a272..d5a2e60 100644
> > --- a/arch/arm/Kconfig
> > +++ b/arch/arm/Kconfig
> > @@ -12,7 +12,6 @@ config ARM
> > select BUILDTIME_EXTABLE_SORT if MMU
> > select CLONE_BACKWARDS
> > select CPU_PM if (SUSPEND || CPU_IDLE)
> > - select DCACHE_WORD_ACCESS if HAVE_EFFICIENT_UNALIGNED_ACCESS
> > select GENERIC_ATOMIC64 if (CPU_V7M || CPU_V6 || !CPU_32v6K || !AEABI)
> > select GENERIC_CLOCKEVENTS_BROADCAST if SMP
> > select GENERIC_IDLE_POLL_SETUP
> > diff --git a/arch/arm/include/asm/word-at-a-time.h b/arch/arm/include/asm/word-at-a-time.h
> > index a6d0a29..778b2ad 100644
> > --- a/arch/arm/include/asm/word-at-a-time.h
> > +++ b/arch/arm/include/asm/word-at-a-time.h
> > @@ -54,7 +54,7 @@ static inline unsigned long find_zero(unsigned long mask)
> > #include <asm-generic/word-at-a-time.h>
> > #endif
> >
> > -#ifdef CONFIG_DCACHE_WORD_ACCESS
> > +#ifdef CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS
> >
> > /*
> > * Load an unaligned word from kernel space.
> > @@ -94,5 +94,5 @@ static inline unsigned long load_unaligned_zeropad(const void *addr)
> > return ret;
> > }
> >
> > -#endif /* DCACHE_WORD_ACCESS */
> > +#endif /* HAVE_EFFICIENT_UNALIGNED_ACCESS */
> > #endif /* __ASM_ARM_WORD_AT_A_TIME_H */
> > diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> > index 764d682..2d6978c 100644
> > --- a/arch/arm64/Kconfig
> > +++ b/arch/arm64/Kconfig
> > @@ -13,7 +13,6 @@ config ARM64
> > select CLONE_BACKWARDS
> > select COMMON_CLK
> > select CPU_PM if (SUSPEND || CPU_IDLE)
> > - select DCACHE_WORD_ACCESS
> > select GENERIC_CLOCKEVENTS
> > select GENERIC_CLOCKEVENTS_BROADCAST if SMP
> > select GENERIC_IOMAP
> > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> > index abb261e..60cfa073 100644
> > --- a/arch/x86/Kconfig
> > +++ b/arch/x86/Kconfig
> > @@ -98,7 +98,6 @@ config X86
> > select CLKEVT_I8253
> > select ARCH_HAVE_NMI_SAFE_CMPXCHG
> > select GENERIC_IOMAP
> > - select DCACHE_WORD_ACCESS
> > select GENERIC_SMP_IDLE_THREAD
> > select ARCH_WANT_IPC_PARSE_VERSION if X86_32
> > select HAVE_ARCH_SECCOMP_FILTER
> > diff --git a/fs/Kconfig b/fs/Kconfig
> > index 312393f..7511271 100644
> > --- a/fs/Kconfig
> > +++ b/fs/Kconfig
> > @@ -4,10 +4,6 @@
> >
> > menu "File systems"
> >
> > -# Use unaligned word dcache accesses
> > -config DCACHE_WORD_ACCESS
> > - bool
> > -
> > if BLOCK
> >
> > source "fs/ext2/Kconfig"
> > diff --git a/fs/dcache.c b/fs/dcache.c
> > index 265e0ce..4e3c195 100644
> > --- a/fs/dcache.c
> > +++ b/fs/dcache.c
> > @@ -163,7 +163,7 @@ int proc_nr_dentry(ctl_table *table, int write, void __user *buffer,
> > * Compare 2 name strings, return 0 if they match, otherwise non-zero.
> > * The strings are both count bytes long, and count is non-zero.
> > */
> > -#ifdef CONFIG_DCACHE_WORD_ACCESS
> > +#ifdef CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS
> >
> > #include <asm/word-at-a-time.h>
> > /*
> > diff --git a/fs/namei.c b/fs/namei.c
> > index 385f781..1ee33ca 100644
> > --- a/fs/namei.c
> > +++ b/fs/namei.c
> > @@ -1618,7 +1618,7 @@ static inline int nested_symlink(struct path *path, struct nameidata *nd)
> > * the final mask". Again, that could be replaced with a
> > * efficient population count instruction or similar.
> > */
> > -#ifdef CONFIG_DCACHE_WORD_ACCESS
> > +#ifdef CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS
> >
> > #include <asm/word-at-a-time.h>
^ permalink raw reply
* [PATCH] phy/at8031: enable at8031 to work on interrupt mode
From: Zhao Qiang @ 2014-03-26 6:45 UTC (permalink / raw)
To: linuxppc-dev, B07421; +Cc: Zhao Qiang, R63061
The at8031 can work on polling mode and interrupt mode.
Add ack_interrupt and config intr funcs to enable
interrupt mode for it.
Signed-off-by: Zhao Qiang <B45475@freescale.com>
---
drivers/net/phy/at803x.c | 30 ++++++++++++++++++++++++++++++
1 file changed, 30 insertions(+)
diff --git a/drivers/net/phy/at803x.c b/drivers/net/phy/at803x.c
index bc71947..d034ef5 100644
--- a/drivers/net/phy/at803x.c
+++ b/drivers/net/phy/at803x.c
@@ -27,6 +27,9 @@
#define AT803X_MMD_ACCESS_CONTROL 0x0D
#define AT803X_MMD_ACCESS_CONTROL_DATA 0x0E
#define AT803X_FUNC_DATA 0x4003
+#define AT803X_INER 0x0012
+#define AT803X_INER_INIT 0xec00
+#define AT803X_INSR 0x0013
#define AT803X_DEBUG_ADDR 0x1D
#define AT803X_DEBUG_DATA 0x1E
#define AT803X_DEBUG_SYSTEM_MODE_CTRL 0x05
@@ -191,6 +194,31 @@ static int at803x_config_init(struct phy_device *phydev)
return 0;
}
+static int at803x_ack_interrupt(struct phy_device *phydev)
+{
+ int err;
+
+ err = phy_read(phydev, AT803X_INSR);
+
+ return (err < 0) ? err : 0;
+}
+
+static int at803x_config_intr(struct phy_device *phydev)
+{
+ int err;
+ int value;
+
+ value = phy_read(phydev, AT803X_INER);
+
+ if (phydev->interrupts == PHY_INTERRUPT_ENABLED)
+ err = phy_write(phydev, AT803X_INER,
+ (value | AT803X_INER_INIT));
+ else
+ err = phy_write(phydev, AT803X_INER, value);
+
+ return err;
+}
+
static struct phy_driver at803x_driver[] = {
{
/* ATHEROS 8035 */
@@ -240,6 +268,8 @@ static struct phy_driver at803x_driver[] = {
.flags = PHY_HAS_INTERRUPT,
.config_aneg = genphy_config_aneg,
.read_status = genphy_read_status,
+ .ack_interrupt = &at803x_ack_interrupt,
+ .config_intr = &at803x_config_intr,
.driver = {
.owner = THIS_MODULE,
},
--
1.8.5
^ permalink raw reply related
* Re: [PATCH 6/7] DMA: Freescale: use spin_lock_bh instead of spin_lock_irqsave
From: Vinod Koul @ 2014-03-26 7:01 UTC (permalink / raw)
To: hongbo.zhang
Cc: vinod.koul, linux-kernel, scottwood, dmaengine, dan.j.williams,
linuxppc-dev
In-Reply-To: <1389851246-8564-7-git-send-email-hongbo.zhang@freescale.com>
On Thu, 2014-01-16 at 13:47 +0800, hongbo.zhang@freescale.com wrote:
> From: Hongbo Zhang <hongbo.zhang@freescale.com>
>
> The usage of spin_lock_irqsave() is a stronger locking mechanism than is
> required throughout the driver. The minimum locking required should be used
> instead. Interrupts will be turned off and context will be saved, it is
> unnecessary to use irqsave.
>
> This patch changes all instances of spin_lock_irqsave() to spin_lock_bh(). All
> manipulation of protected fields is done using tasklet context or weaker, which
> makes spin_lock_bh() the correct choice.
>
> Signed-off-by: Hongbo Zhang <hongbo.zhang@freescale.com>
> Signed-off-by: Qiang Liu <qiang.liu@freescale.com>
> ---
> drivers/dma/fsldma.c | 25 ++++++++++---------------
> 1 file changed, 10 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
> index bbace54..437794e 100644
> --- a/drivers/dma/fsldma.c
> +++ b/drivers/dma/fsldma.c
> @@ -396,10 +396,9 @@ static dma_cookie_t fsl_dma_tx_submit(struct dma_async_tx_descriptor *tx)
> struct fsldma_chan *chan = to_fsl_chan(tx->chan);
> struct fsl_desc_sw *desc = tx_to_fsl_desc(tx);
> struct fsl_desc_sw *child;
> - unsigned long flags;
> dma_cookie_t cookie = -EINVAL;
>
> - spin_lock_irqsave(&chan->desc_lock, flags);
> + spin_lock_bh(&chan->desc_lock);
>
> /*
> * assign cookies to all of the software descriptors
> @@ -412,7 +411,7 @@ static dma_cookie_t fsl_dma_tx_submit(struct dma_async_tx_descriptor *tx)
> /* put this transaction onto the tail of the pending queue */
> append_ld_queue(chan, desc);
>
> - spin_unlock_irqrestore(&chan->desc_lock, flags);
> + spin_unlock_bh(&chan->desc_lock);
>
> return cookie;
> }
> @@ -731,15 +730,14 @@ static void fsldma_free_desc_list_reverse(struct fsldma_chan *chan,
> static void fsl_dma_free_chan_resources(struct dma_chan *dchan)
> {
> struct fsldma_chan *chan = to_fsl_chan(dchan);
> - unsigned long flags;
>
> chan_dbg(chan, "free all channel resources\n");
> - spin_lock_irqsave(&chan->desc_lock, flags);
> + spin_lock_bh(&chan->desc_lock);
> fsldma_cleanup_descriptors(chan);
> fsldma_free_desc_list(chan, &chan->ld_pending);
> fsldma_free_desc_list(chan, &chan->ld_running);
> fsldma_free_desc_list(chan, &chan->ld_completed);
> - spin_unlock_irqrestore(&chan->desc_lock, flags);
> + spin_unlock_bh(&chan->desc_lock);
>
> dma_pool_destroy(chan->desc_pool);
> chan->desc_pool = NULL;
> @@ -958,7 +956,6 @@ static int fsl_dma_device_control(struct dma_chan *dchan,
> {
> struct dma_slave_config *config;
> struct fsldma_chan *chan;
> - unsigned long flags;
> int size;
>
> if (!dchan)
> @@ -968,7 +965,7 @@ static int fsl_dma_device_control(struct dma_chan *dchan,
>
> switch (cmd) {
> case DMA_TERMINATE_ALL:
> - spin_lock_irqsave(&chan->desc_lock, flags);
> + spin_lock_bh(&chan->desc_lock);
>
> /* Halt the DMA engine */
> dma_halt(chan);
> @@ -979,7 +976,7 @@ static int fsl_dma_device_control(struct dma_chan *dchan,
> fsldma_free_desc_list(chan, &chan->ld_completed);
> chan->idle = true;
>
> - spin_unlock_irqrestore(&chan->desc_lock, flags);
> + spin_unlock_bh(&chan->desc_lock);
> return 0;
>
> case DMA_SLAVE_CONFIG:
> @@ -1021,11 +1018,10 @@ static int fsl_dma_device_control(struct dma_chan *dchan,
> static void fsl_dma_memcpy_issue_pending(struct dma_chan *dchan)
> {
> struct fsldma_chan *chan = to_fsl_chan(dchan);
> - unsigned long flags;
>
> - spin_lock_irqsave(&chan->desc_lock, flags);
> + spin_lock_bh(&chan->desc_lock);
> fsl_chan_xfer_ld_queue(chan);
> - spin_unlock_irqrestore(&chan->desc_lock, flags);
> + spin_unlock_bh(&chan->desc_lock);
> }
>
> /**
> @@ -1124,11 +1120,10 @@ static irqreturn_t fsldma_chan_irq(int irq, void *data)
> static void dma_do_tasklet(unsigned long data)
> {
> struct fsldma_chan *chan = (struct fsldma_chan *)data;
> - unsigned long flags;
>
> chan_dbg(chan, "tasklet entry\n");
>
> - spin_lock_irqsave(&chan->desc_lock, flags);
> + spin_lock_bh(&chan->desc_lock);
okay here is the problem :(
You moved to _bh variant. So if you grab the lock in rest of the code
and irq gets triggered then here we will be spinning to grab the lock.
So effectively you made right locking solution into deadlock situation!
>
> /* the hardware is now idle and ready for more */
> chan->idle = true;
> @@ -1136,7 +1131,7 @@ static void dma_do_tasklet(unsigned long data)
> /* Run all cleanup for descriptors which have been completed */
> fsldma_cleanup_descriptors(chan);
>
> - spin_unlock_irqrestore(&chan->desc_lock, flags);
> + spin_unlock_bh(&chan->desc_lock);
>
> chan_dbg(chan, "tasklet exit\n");
> }
--
Vinod Koul
Intel Corp.
^ permalink raw reply
* Re: Build regressions/improvements in v3.14-rc8
From: Geert Uytterhoeven @ 2014-03-26 7:55 UTC (permalink / raw)
To: linux-kernel@vger.kernel.org; +Cc: linuxppc-dev@lists.ozlabs.org, Linux-sh list
In-Reply-To: <1395820064-19148-1-git-send-email-geert@linux-m68k.org>
On Wed, Mar 26, 2014 at 8:47 AM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> JFYI, when comparing v3.14-rc8[1] to v3.14-rc7[3], the summaries are:
> - build errors: +6/-1
+ /scratch/kisskb/src/arch/powerpc/include/asm/io.h: error:
'virt_phys_offset' undeclared (first use in this function): =>
814:16, 807:16, 770:9, 787:17
+ /scratch/kisskb/src/include/linux/mm.h: error: 'virt_phys_offset'
undeclared (first use in this function): => 890:9, 1402:20, 494:22
powerpc-randconfig
+ /scratch/kisskb/src/arch/sh/drivers/dma/dma-sh.c: error:
'CHCR_TS_HIGH_MASK' undeclared (first use in this function): => 98:12
+ /scratch/kisskb/src/arch/sh/drivers/dma/dma-sh.c: error:
'CHCR_TS_HIGH_SHIFT' undeclared (first use in this function): =>
98:34, 145:10
+ /scratch/kisskb/src/arch/sh/drivers/dma/dma-sh.c: error:
'CHCR_TS_LOW_MASK' undeclared (first use in this function): => 97:21
+ /scratch/kisskb/src/arch/sh/drivers/dma/dma-sh.c: error:
'CHCR_TS_LOW_SHIFT' undeclared (first use in this function): =>
97:42, 145:10
sh-randconfig
> [1] http://kisskb.ellerman.id.au/kisskb/head/7303/ (all 119 configs)
> [3] http://kisskb.ellerman.id.au/kisskb/head/7277/ (all 119 configs)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 10/33] powerpc: Ignore TOC relocations
From: Alan Modra @ 2014-03-26 9:36 UTC (permalink / raw)
To: Anton Blanchard; +Cc: mikey, rusty, ulrich.weigand, mjw, paulus, linuxppc-dev
In-Reply-To: <1395747879-5948-11-git-send-email-anton@samba.org>
On Tue, Mar 25, 2014 at 10:44:16PM +1100, Anton Blanchard wrote:
> The linker fixes up TOC. relocations, so prom_init_check.sh should
> ignore them.
Err, .TOC. you mean. Presumably something strips off the leading dot
somewhere?
> -btext_setup_display"
> +btext_setup_display TOC."
--
Alan Modra
Australia Development Lab, IBM
^ 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