* [RFC PATCH 5/5] powerpc: select HAVE_CONTEXT_TRACKING for pSeries
From: Li Zhong @ 2013-02-01 10:27 UTC (permalink / raw)
To: linux-kernel; +Cc: Li Zhong, fweisbec, paulus, paulmck, linuxppc-dev
In-Reply-To: <1359714465-6297-1-git-send-email-zhong@linux.vnet.ibm.com>
Start context tracking support from pSeries.
Signed-off-by: Li Zhong <zhong@linux.vnet.ibm.com>
---
arch/powerpc/platforms/pseries/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/powerpc/platforms/pseries/Kconfig b/arch/powerpc/platforms/pseries/Kconfig
index 837cf49..a9570fe 100644
--- a/arch/powerpc/platforms/pseries/Kconfig
+++ b/arch/powerpc/platforms/pseries/Kconfig
@@ -17,6 +17,7 @@ config PPC_PSERIES
select PPC_NATIVE
select PPC_PCI_CHOICE if EXPERT
select ZLIB_DEFLATE
+ select HAVE_CONTEXT_TRACKING
default y
config PPC_SPLPAR
--
1.7.9.5
^ permalink raw reply related
* Why is the e500v2 core not using cpuidle?
From: Thomas Waldecker @ 2013-02-01 12:06 UTC (permalink / raw)
To: Linux PPC dev mailing list (linuxppc-dev@lists.ozlabs.org)
Hi,
As part of my masterthesis I was just looking around the kernel=20
sources for cpuidle and figured out that the only CPU in the PowerPC=20
architecture using the cpuidle framework is the pseries.
I assume the e500v2 core is using the idle modes=20
in arch/powerpc/kernel/idle_e500.S
Why is there no support for the cpuidle framework?
How can I debug the e500 idle modes?=20
Are there any statistics?
I already ran PowerTOP on a QorIQ P2020 but it's almost useless=20
because the information is missing.
Kind regards,
Thomas Waldecker
^ permalink raw reply
* [PATCH] powerpc/512x: add function for CS parameter configuration
From: Anatolij Gustschin @ 2013-02-01 13:28 UTC (permalink / raw)
To: linuxppc-dev
Add ability to configure CS parameters for devices that need
different CS parameters setup after their configuration. I.e.
an FPGA device on LP bus can require different CS parameters
for its bus interface after loading firmware into it. A driver
can easily reconfigure the LPC CS parameters using this function.
Signed-off-by: Anatolij Gustschin <agust@denx.de>
---
arch/powerpc/include/asm/mpc5121.h | 16 +++++++++++++
arch/powerpc/platforms/512x/mpc512x_shared.c | 30 ++++++++++++++++++++++++++
2 files changed, 46 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/include/asm/mpc5121.h b/arch/powerpc/include/asm/mpc5121.h
index 8c0ab2c..738ebca 100644
--- a/arch/powerpc/include/asm/mpc5121.h
+++ b/arch/powerpc/include/asm/mpc5121.h
@@ -53,4 +53,20 @@ struct mpc512x_ccm {
u32 m4ccr; /* MSCAN4 CCR */
u8 res[0x98]; /* Reserved */
};
+
+/*
+ * LPC Module
+ */
+struct mpc512x_lpc {
+ u32 cs_cfg[8]; /* CS config */
+ u32 cs_ctrl; /* CS Control Register */
+ u32 cs_status; /* CS Status Register */
+ u32 burst_ctrl; /* CS Burst Control Register */
+ u32 deadcycle_ctrl; /* CS Deadcycle Control Register */
+ u32 holdcycle_ctrl; /* CS Holdcycle Control Register */
+ u32 alt; /* Address Latch Timing Register */
+};
+
+int mpc512x_cs_config(int cs, u32 val);
+
#endif /* __ASM_POWERPC_MPC5121_H__ */
diff --git a/arch/powerpc/platforms/512x/mpc512x_shared.c b/arch/powerpc/platforms/512x/mpc512x_shared.c
index c344438..112b4f6 100644
--- a/arch/powerpc/platforms/512x/mpc512x_shared.c
+++ b/arch/powerpc/platforms/512x/mpc512x_shared.c
@@ -436,3 +436,33 @@ void __init mpc512x_init(void)
mpc512x_restart_init();
mpc512x_psc_fifo_init();
}
+
+/**
+ * mpc512x_cs_config - Setup chip select configuration
+ * @cs: chip select number
+ * @val: chip select configuration value
+ *
+ * Perform chip select configuration for devices on LocalPlus Bus.
+ * Intended to dynamically reconfigure the chip select parameters
+ * for configurable devices on the bus.
+ */
+int mpc512x_cs_config(int cs, u32 val)
+{
+ static struct mpc512x_lpc __iomem *lpc;
+ struct device_node *np;
+
+ if (cs < 0 || cs > 7)
+ return -EINVAL;
+
+ if (!lpc) {
+ np = of_find_compatible_node(NULL, NULL, "fsl,mpc5121-lpc");
+ lpc = of_iomap(np, 0);
+ of_node_put(np);
+ if (!lpc)
+ return -ENOMEM;
+ }
+
+ out_be32(&lpc->cs_cfg[cs], val);
+ return 0;
+}
+EXPORT_SYMBOL_GPL(mpc512x_cs_config);
--
1.7.5.4
^ permalink raw reply related
* [PATCH 1/1] powerpc/85xx: Board support for ppa8548
From: Stef van Os @ 2013-02-01 15:36 UTC (permalink / raw)
To: Kumar Gala, linuxppc-dev; +Cc: Paul Mackerras, Stef van Os
Initial board support for the Prodrive PPA8548 AMC module. Board
is an MPC8548 AMC platform used in RapidIO systems. This module is
also used to test/work on mainline linux RapidIO software.
PPA8548 overview:
- 1.3 GHz Freescale PowerQUICC III MPC8548 processor
- 1 GB DDR2 @ 266 MHz
- 8 MB NOR flash
- Serial RapidIO 1.2
- 1 x 10/100/1000 BASE-T front ethernet
- 1 x 1000 BASE-BX ethernet on AMC connector
Signed-off-by: Stef van Os <stef.van.os@prodrive.nl>
---
arch/powerpc/boot/dts/ppa8548.dts | 238 +++++++++++++++++++++++++++
arch/powerpc/configs/85xx/ppa8548_defconfig | 65 ++++++++
arch/powerpc/platforms/85xx/Kconfig | 7 +
arch/powerpc/platforms/85xx/Makefile | 1 +
arch/powerpc/platforms/85xx/ppa8548.c | 119 +++++++++++++
5 files changed, 430 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/boot/dts/ppa8548.dts
create mode 100644 arch/powerpc/configs/85xx/ppa8548_defconfig
create mode 100644 arch/powerpc/platforms/85xx/ppa8548.c
diff --git a/arch/powerpc/boot/dts/ppa8548.dts b/arch/powerpc/boot/dts/ppa8548.dts
new file mode 100644
index 0000000..5eaba83
--- /dev/null
+++ b/arch/powerpc/boot/dts/ppa8548.dts
@@ -0,0 +1,238 @@
+/*
+ * PPA8548 Device Tree Source (36-bit address map)
+ * Copyright 2013 Prodrive B.V.
+ *
+ * Based on:
+ * MPC8548 CDS Device Tree Source (36-bit address map)
+ * Copyright 2012 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.
+ */
+
+/dts-v1/;
+
+/include/ "fsl/e500v2_power_isa.dtsi"
+
+/ {
+ model = "ppa8548";
+ compatible = "ppa8548";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ interrupt-parent = <&mpic>;
+
+ aliases {
+ serial0 = &serial0;
+ serial1 = &serial1;
+ ethernet0 = &enet0;
+ ethernet1 = &enet1;
+ rapidio0 = &rio;
+ };
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ PowerPC,8548@0 {
+ device_type = "cpu";
+ reg = <0x0>;
+ next-level-cache = <&L2>;
+ };
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <0 0 0x0 0x40000000>;
+ };
+
+ board_lbc: lbc: localbus@fe0005000 {
+ reg = <0xf 0xe0005000 0 0x1000>;
+ ranges = <0x0 0x0 0xf 0xff800000 0x00800000>;
+ };
+
+ board_soc: soc: soc8548@fe0000000 {
+ ranges = <0 0xf 0xe0000000 0x100000>;
+ };
+
+ rio: rapidio@fe00c0000 {
+ reg = <0xf 0xe00c0000 0x0 0x11000>;
+ port1 {
+ ranges = <0x0 0x0 0x0 0x80000000 0x0 0x40000000>;
+ };
+ };
+};
+
+&lbc {
+ #address-cells = <2>;
+ #size-cells = <1>;
+ compatible = "fsl,mpc8548-lbc", "fsl,pq3-localbus", "simple-bus";
+ interrupts = <19 2 0 0>;
+};
+
+&rio {
+ compatible = "fsl,srio";
+ interrupts = <48 2 0 0>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+ fsl,srio-rmu-handle = <&rmu>;
+ ranges;
+
+ port1 {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ cell-index = <1>;
+ };
+};
+
+&soc {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ device_type = "soc";
+ compatible = "fsl,mpc8548-immr", "simple-bus";
+ bus-frequency = <0>; // Filled out by uboot.
+
+ ecm-law@0 {
+ compatible = "fsl,ecm-law";
+ reg = <0x0 0x1000>;
+ fsl,num-laws = <10>;
+ };
+
+ ecm@1000 {
+ compatible = "fsl,mpc8548-ecm", "fsl,ecm";
+ reg = <0x1000 0x1000>;
+ interrupts = <17 2 0 0>;
+ };
+
+ memory-controller@2000 {
+ compatible = "fsl,mpc8548-memory-controller";
+ reg = <0x2000 0x1000>;
+ interrupts = <18 2 0 0>;
+ };
+
+/include/ "fsl/pq3-i2c-0.dtsi"
+/include/ "fsl/pq3-i2c-1.dtsi"
+/include/ "fsl/pq3-duart-0.dtsi"
+
+ L2: l2-cache-controller@20000 {
+ compatible = "fsl,mpc8548-l2-cache-controller";
+ reg = <0x20000 0x1000>;
+ cache-line-size = <32>; // 32 bytes
+ cache-size = <0x80000>; // L2, 512K
+ interrupts = <16 2 0 0>;
+ };
+
+/include/ "fsl/pq3-dma-0.dtsi"
+/include/ "fsl/pq3-etsec1-0.dtsi"
+/include/ "fsl/pq3-etsec1-1.dtsi"
+/include/ "fsl/pq3-etsec1-2.dtsi"
+/include/ "fsl/pq3-etsec1-3.dtsi"
+
+/include/ "fsl/pq3-sec2.1-0.dtsi"
+/include/ "fsl/pq3-mpic.dtsi"
+/include/ "fsl/pq3-rmu-0.dtsi"
+
+ global-utilities@e0000 {
+ compatible = "fsl,mpc8548-guts";
+ reg = <0xe0000 0x1000>;
+ fsl,has-rstcr;
+ };
+};
+
+&board_lbc {
+ nor@0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "cfi-flash";
+ reg = <0x0 0x0 0x00800000>;
+ bank-width = <2>;
+ device-width = <2>;
+
+ partition@0 {
+ reg = <0x0 0x7A0000>;
+ label = "user";
+ };
+
+ partition@7A0000 {
+ reg = <0x7A0000 0x20000>;
+ label = "env";
+ read-only;
+ };
+
+ partition@7C0000 {
+ reg = <0x7C0000 0x40000>;
+ label = "u-boot";
+ read-only;
+ };
+ };
+};
+
+&board_soc {
+ i2c@3000 {
+ rtc@6f {
+ compatible = "intersil,isl1208";
+ reg = <0x6f>;
+ };
+ };
+
+ i2c@3100 {
+ };
+
+ ethernet@24000 {
+ status = "disabled";
+ };
+
+ mdio@24520 {
+ phy0: ethernet-phy@0 {
+ interrupts = <7 1 0 0>;
+ reg = <0x0>;
+ device_type = "ethernet-phy";
+ };
+ phy1: ethernet-phy@1 {
+ interrupts = <8 1 0 0>;
+ reg = <0x1>;
+ device_type = "ethernet-phy";
+ };
+ tbi0: tbi-phy@11 {
+ reg = <0x11>;
+ device_type = "tbi-phy";
+ };
+ };
+
+ enet0: ethernet@25000 {
+ tbi-handle = <&tbi1>;
+ phy-handle = <&phy0>;
+ };
+
+ mdio@25520 {
+ tbi1: tbi-phy@11 {
+ reg = <0x11>;
+ device_type = "tbi-phy";
+ };
+ };
+
+ enet1: ethernet@26000 {
+ tbi-handle = <&tbi2>;
+ phy-handle = <&phy1>;
+ };
+
+ mdio@26520 {
+ tbi2: tbi-phy@11 {
+ reg = <0x11>;
+ device_type = "tbi-phy";
+ };
+ };
+
+ ethernet@27000 {
+ status = "disabled";
+ };
+
+ mdio@27520 {
+ tbi3: tbi-phy@11 {
+ reg = <0x11>;
+ device_type = "tbi-phy";
+ };
+ };
+};
+
diff --git a/arch/powerpc/configs/85xx/ppa8548_defconfig b/arch/powerpc/configs/85xx/ppa8548_defconfig
new file mode 100644
index 0000000..a11337d
--- /dev/null
+++ b/arch/powerpc/configs/85xx/ppa8548_defconfig
@@ -0,0 +1,65 @@
+CONFIG_PPC_85xx=y
+CONFIG_PPA8548=y
+CONFIG_DTC=y
+CONFIG_DEFAULT_UIMAGE=y
+CONFIG_IKCONFIG=y
+CONFIG_IKCONFIG_PROC=y
+# CONFIG_PCI is not set
+# CONFIG_USB_SUPPORT is not set
+CONFIG_ADVANCED_OPTIONS=y
+CONFIG_LOWMEM_SIZE_BOOL=y
+CONFIG_LOWMEM_SIZE=0x40000000
+CONFIG_LOWMEM_CAM_NUM_BOOL=y
+CONFIG_LOWMEM_CAM_NUM=4
+CONFIG_PAGE_OFFSET_BOOL=y
+CONFIG_PAGE_OFFSET=0xb0000000
+CONFIG_KERNEL_START_BOOL=y
+CONFIG_KERNEL_START=0xb0000000
+# CONFIG_PHYSICAL_START_BOOL is not set
+CONFIG_PHYSICAL_START=0x00000000
+CONFIG_PHYSICAL_ALIGN=0x04000000
+CONFIG_TASK_SIZE_BOOL=y
+CONFIG_TASK_SIZE=0xb0000000
+
+CONFIG_FSL_LBC=y
+CONFIG_FSL_DMA=y
+CONFIG_FSL_RIO=y
+
+CONFIG_RAPIDIO=y
+CONFIG_RAPIDIO_DMA_ENGINE=y
+CONFIG_RAPIDIO_TSI57X=y
+CONFIG_RAPIDIO_TSI568=y
+CONFIG_RAPIDIO_CPS_XX=y
+CONFIG_RAPIDIO_CPS_GEN2=y
+CONFIG_SERIAL_8250=y
+CONFIG_SERIAL_8250_CONSOLE=y
+CONFIG_PROC_DEVICETREE=y
+
+CONFIG_MTD=y
+CONFIG_MTD_BLKDEVS=y
+CONFIG_MTD_BLOCK=y
+CONFIG_MTD_CFI=y
+CONFIG_MTD_CFI_AMDSTD=y
+CONFIG_MTD_CFI_INTELEXT=y
+CONFIG_MTD_CHAR=y
+CONFIG_MTD_CMDLINE_PARTS=y
+CONFIG_MTD_CONCAT=y
+CONFIG_MTD_PARTITIONS=y
+CONFIG_MTD_PHYSMAP_OF=y
+
+CONFIG_I2C=y
+CONFIG_I2C_MPC=y
+CONFIG_I2C_CHARDEV
+CONFIG_RTC_CLASS=y
+CONFIG_RTC_HCTOSYS=y
+CONFIG_RTC_DRV_ISL1208=y
+
+CONFIG_NET=y
+CONFIG_INET=y
+CONFIG_IP_PNP=y
+CONFIG_NETDEVICES=y
+CONFIG_MII=y
+CONFIG_GIANFAR=y
+CONFIG_MARVELL_PHY=y
+CONFIG_NFS_FS=y
+CONFIG_ROOT_NFS=y
diff --git a/arch/powerpc/platforms/85xx/Kconfig b/arch/powerpc/platforms/85xx/Kconfig
index 02d02a0..803bfed 100644
--- a/arch/powerpc/platforms/85xx/Kconfig
+++ b/arch/powerpc/platforms/85xx/Kconfig
@@ -191,6 +191,13 @@ config SBC8548
help
This option enables support for the Wind River SBC8548 board
+config PPA8548
+ bool "Prodrive PPA8548"
+ help
+ This option enables support for the Prodrive PPA8548 board.
+ select DEFAULT_UIMAGE
+ select HAS_RAPIDIO
+
config GE_IMP3A
bool "GE Intelligent Platforms IMP3A"
select DEFAULT_UIMAGE
diff --git a/arch/powerpc/platforms/85xx/Makefile b/arch/powerpc/platforms/85xx/Makefile
index 76f679c..d5f4195 100644
--- a/arch/powerpc/platforms/85xx/Makefile
+++ b/arch/powerpc/platforms/85xx/Makefile
@@ -25,6 +25,7 @@ obj-$(CONFIG_P5040_DS) += p5040_ds.o corenet_ds.o
obj-$(CONFIG_STX_GP3) += stx_gp3.o
obj-$(CONFIG_TQM85xx) += tqm85xx.o
obj-$(CONFIG_SBC8548) += sbc8548.o
+obj-$(CONFIG_PPA8548) += ppa8548.o
obj-$(CONFIG_SOCRATES) += socrates.o socrates_fpga_pic.o
obj-$(CONFIG_KSI8560) += ksi8560.o
obj-$(CONFIG_XES_MPC85xx) += xes_mpc85xx.o
diff --git a/arch/powerpc/platforms/85xx/ppa8548.c b/arch/powerpc/platforms/85xx/ppa8548.c
new file mode 100644
index 0000000..80a9307
--- /dev/null
+++ b/arch/powerpc/platforms/85xx/ppa8548.c
@@ -0,0 +1,119 @@
+/*
+ * ppa8548 setup and early boot code.
+ *
+ * Copyright 2009 Prodrive B.V..
+ *
+ * By Stef van Os (see MAINTAINERS for contact information)
+ *
+ * Based on the SBC8548 support - Copyright 2007 Wind River Systems Inc.
+ * Based on the MPC8548CDS support - Copyright 2005 Freescale 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 <linux/stddef.h>
+#include <linux/kernel.h>
+#include <linux/init.h>
+#include <linux/errno.h>
+#include <linux/reboot.h>
+#include <linux/kdev_t.h>
+#include <linux/major.h>
+#include <linux/console.h>
+#include <linux/delay.h>
+#include <linux/seq_file.h>
+#include <linux/initrd.h>
+#include <linux/module.h>
+#include <linux/interrupt.h>
+#include <linux/fsl_devices.h>
+#include <linux/of_platform.h>
+
+#include <asm/pgtable.h>
+#include <asm/page.h>
+#include <asm/atomic.h>
+#include <asm/time.h>
+#include <asm/io.h>
+#include <asm/machdep.h>
+#include <asm/ipic.h>
+#include <asm/irq.h>
+#include <mm/mmu_decl.h>
+#include <asm/prom.h>
+#include <asm/udbg.h>
+#include <asm/mpic.h>
+
+#include <sysdev/fsl_soc.h>
+
+static void __init ppa8548_pic_init(void)
+{
+ struct mpic *mpic = mpic_alloc(NULL, 0, MPIC_BIG_ENDIAN,
+ 0, 256, " OpenPIC ");
+ BUG_ON(mpic == NULL);
+ mpic_init(mpic);
+}
+
+/*
+ * Setup the architecture
+ */
+static void __init ppa8548_setup_arch(void)
+{
+ if (ppc_md.progress)
+ ppc_md.progress("ppa8548_setup_arch()", 0);
+}
+
+static void ppa8548_show_cpuinfo(struct seq_file *m)
+{
+ uint pvid, svid, phid1;
+
+ pvid = mfspr(SPRN_PVR);
+ svid = mfspr(SPRN_SVR);
+
+ seq_printf(m, "Vendor\t\t: Prodrive B.V.\n");
+ seq_printf(m, "Machine\t\t: ppa8548\n");
+ seq_printf(m, "PVR\t\t: 0x%x\n", pvid);
+ seq_printf(m, "SVR\t\t: 0x%x\n", svid);
+
+ /* Display cpu Pll setting */
+ phid1 = mfspr(SPRN_HID1);
+ seq_printf(m, "PLL setting\t: 0x%x\n", ((phid1 >> 24) & 0x3f));
+}
+
+static struct of_device_id __initdata of_bus_ids[] = {
+ { .name = "soc", },
+ { .type = "soc", },
+ { .compatible = "simple-bus", },
+ { .compatible = "gianfar", },
+ { .compatible = "fsl,srio", },
+ {},
+};
+
+static int __init declare_of_platform_devices(void)
+{
+ of_platform_bus_probe(NULL, of_bus_ids, NULL);
+
+ return 0;
+}
+machine_device_initcall(ppa8548, declare_of_platform_devices);
+
+/*
+ * Called very early, device-tree isn't unflattened
+ */
+static int __init ppa8548_probe(void)
+{
+ unsigned long root = of_get_flat_dt_root();
+
+ return of_flat_dt_is_compatible(root, "ppa8548");
+}
+
+define_machine(ppa8548) {
+ .name = "ppa8548",
+ .probe = ppa8548_probe,
+ .setup_arch = ppa8548_setup_arch,
+ .init_IRQ = ppa8548_pic_init,
+ .show_cpuinfo = ppa8548_show_cpuinfo,
+ .get_irq = mpic_get_irq,
+ .restart = fsl_rstcr_restart,
+ .calibrate_decr = generic_calibrate_decr,
+ .progress = udbg_progress,
+};
--
1.7.2.5
^ permalink raw reply related
* Re: Why is the e500v2 core not using cpuidle?
From: Scott Wood @ 2013-02-01 18:15 UTC (permalink / raw)
To: Thomas Waldecker
Cc: Linux PPC dev mailing list (linuxppc-dev@lists.ozlabs.org)
In-Reply-To: <B88C075EE1324644BA0452D5EFDD58281395211D@TQ-MAIL.tq-net.de>
On 02/01/2013 06:06:05 AM, Thomas Waldecker wrote:
> Hi,
>=20
> As part of my masterthesis I was just looking around the kernel
> sources for cpuidle and figured out that the only CPU in the PowerPC
> architecture using the cpuidle framework is the pseries.
>=20
> I assume the e500v2 core is using the idle modes
> in arch/powerpc/kernel/idle_e500.S
>=20
> Why is there no support for the cpuidle framework?
Because nobody implemented it. :-)
The only reason I can think of to implement it on this chip would be to =20
dynamically choose when to enter nap versus doze, rather than always =20
just using doze. It's not clear whether the difference in power =20
savings is worth it -- do you have any way of measuring?
> How can I debug the e500 idle modes?
> Are there any statistics?
Top reports idle percentage...
> I already ran PowerTOP on a QorIQ P2020 but it's almost useless
> because the information is missing.
What information are you looking for?
-Scott=
^ permalink raw reply
* Re: [RFC PATCH v2 01/12] Add sys_hotplug.h for system device hotplug framework
From: Toshi Kani @ 2013-02-01 20:40 UTC (permalink / raw)
To: Greg KH
Cc: linux-s390@vger.kernel.org, jiang.liu@huawei.com,
wency@cn.fujitsu.com, linux-mm@kvack.org, yinghai@kernel.org,
linux-kernel@vger.kernel.org, Rafael J. Wysocki,
linux-acpi@vger.kernel.org, isimatu.yasuaki@jp.fujitsu.com,
srivatsa.bhat@linux.vnet.ibm.com, guohanjun@huawei.com,
bhelgaas@google.com, akpm@linux-foundation.org,
linuxppc-dev@lists.ozlabs.org, lenb@kernel.org
In-Reply-To: <20130201073010.GC1180@kroah.com>
On Fri, 2013-02-01 at 07:30 +0000, Greg KH wrote:
> On Thu, Jan 31, 2013 at 06:32:18PM -0700, Toshi Kani wrote:
> > This is already done for PCI host bridges and platform devices and I don't
> > > see why we can't do that for the other types of devices too.
> > >
> > > The only missing piece I see is a way to handle the "eject" problem, i.e.
> > > when we try do eject a device at the top of a subtree and need to tear down
> > > the entire subtree below it, but if that's going to lead to a system crash,
> > > for example, we want to cancel the eject. It seems to me that we'll need some
> > > help from the driver core here.
> >
> > There are three different approaches suggested for system device
> > hot-plug:
> > A. Proceed within system device bus scan.
> > B. Proceed within ACPI bus scan.
> > C. Proceed with a sequence (as a mini-boot).
> >
> > Option A uses system devices as tokens, option B uses acpi devices as
> > tokens, and option C uses resource tables as tokens, for their handlers.
> >
> > Here is summary of key questions & answers so far. I hope this
> > clarifies why I am suggesting option 3.
> >
> > 1. What are the system devices?
> > System devices provide system-wide core computing resources, which are
> > essential to compose a computer system. System devices are not
> > connected to any particular standard buses.
>
> Not a problem, lots of devices are not connected to any "particular
> standard busses". All this means is that system devices are connected
> to the "system" bus, nothing more.
Can you give me a few examples of other devices that support hotplug and
are not connected to any particular buses? I will investigate them to
see how they are managed to support hotplug.
> > 2. Why are the system devices special?
> > The system devices are initialized during early boot-time, by multiple
> > subsystems, from the boot-up sequence, in pre-defined order. They
> > provide low-level services to enable other subsystems to come up.
>
> Sorry, no, that doesn't mean they are special, nothing here is unique
> for the point of view of the driver model from any other device or bus.
I think system devices are unique in a sense that they are initialized
before drivers run.
> > 3. Why can't initialize the system devices from the driver structure at
> > boot?
> > The driver structure is initialized at the end of the boot sequence and
> > requires the low-level services from the system devices initialized
> > beforehand.
>
> Wait, what "driver structure"?
Sorry it was not clear. cpu_dev_init() and memory_dev_init() are called
from driver_init() at the end of the boot sequence, and initialize
system/cpu and system/memory devices. I assume they are the system bus
you are referring with option A.
> If you need to initialize the driver
> core earlier, then do so. Or, even better, just wait until enough of
> the system has come up and then go initialize all of the devices you
> have found so far as part of your boot process.
They are pseudo drivers that provide sysfs entry points of cpu and
memory. They do not actually initialize cpu and memory. I do not think
initializing cpu and memory fits into the driver model either, since
drivers should run after cpu and memory are initialized.
> None of the above things you have stated seem to have anything to do
> with your proposed patch, so I don't understand why you have mentioned
> them...
You suggested option A before, which uses system bus scan to initialize
all system devices at boot time as well as hot-plug. I tried to say
that this option would not be doable.
> > 4. Why do we need a new common framework?
> > Sysfs CPU and memory on-lining/off-lining are performed within the CPU
> > and memory modules. They are common code and do not depend on ACPI.
> > Therefore, a new common framework is necessary to integrate both
> > on-lining/off-lining operation and hot-plugging operation of system
> > devices into a single framework.
>
> {sigh}
>
> Removing and adding devices and handling hotplug operations is what the
> driver core was written for, almost 10 years ago. To somehow think that
> your devices are "special" just because they don't use ACPI is odd,
> because the driver core itself has nothing to do with ACPI. Don't get
> the current mix of x86 system code tied into ACPI confused with an
> driver core issues here please.
CPU online/offline operation is performed within the CPU module. Memory
online/offline operation is performed within the memory module. CPU and
memory hotplug operations are performed within ACPI. While they deal
with the same set of devices, they operate independently and are not
managed under a same framework.
I agree with you that not using ACPI is perfectly fine. My point is
that ACPI framework won't be able to manage operations that do not use
ACPI.
> > 5. Why can't do everything with ACPI bus scan?
> > Software dependency among system devices may not be dictated by the ACPI
> > hierarchy. For instance, memory should be initialized before CPUs (i.e.
> > a new cpu may need its local memory), but such ordering cannot be
> > guaranteed by the ACPI hierarchy. Also, as described in 4,
> > online/offline operations are independent from ACPI.
>
> That's fine, the driver core is independant from ACPI. I don't care how
> you do the scaning of your devices, but I do care about you creating new
> driver core pieces that duplicate the existing functionality of what we
> have today.
>
> In short, I like Rafael's proposal better, and I fail to see how
> anything you have stated here would matter in how this is implemented. :)
Doing everything within ACPI means we can only manage ACPI hotplug
operations, not online/offline operations. But I understand that you
concern about adding a new framework with option C. It is good to know
that you are fine with option B. :) So, I will step back, and think
about what we can do within ACPI.
Thanks,
-Toshi
^ permalink raw reply
* Re: [RFC PATCH v2 01/12] Add sys_hotplug.h for system device hotplug framework
From: Rafael J. Wysocki @ 2013-02-01 22:12 UTC (permalink / raw)
To: Greg KH
Cc: linux-s390, Toshi Kani, jiang.liu, wency, linux-acpi, yinghai,
linux-kernel, linux-mm, isimatu.yasuaki, srivatsa.bhat, guohanjun,
bhelgaas, akpm, linuxppc-dev, lenb
In-Reply-To: <20130201072312.GB1180@kroah.com>
On Friday, February 01, 2013 08:23:12 AM Greg KH wrote:
> On Thu, Jan 31, 2013 at 09:54:51PM +0100, Rafael J. Wysocki wrote:
> > > > But, again, I'm going to ask why you aren't using the existing cpu /
> > > > memory / bridge / node devices that we have in the kernel. Please use
> > > > them, or give me a _really_ good reason why they will not work.
> > >
> > > We cannot use the existing system devices or ACPI devices here. During
> > > hot-plug, ACPI handler sets this shp_device info, so that cpu and memory
> > > handlers (drivers/cpu.c and mm/memory_hotplug.c) can obtain their target
> > > device information in a platform-neutral way. During hot-add, we first
> > > creates an ACPI device node (i.e. device under /sys/bus/acpi/devices),
> > > but platform-neutral modules cannot use them as they are ACPI-specific.
> >
> > But suppose we're smart and have ACPI scan handlers that will create
> > "physical" device nodes for those devices during the ACPI namespace scan.
> > Then, the platform-neutral nodes will be able to bind to those "physical"
> > nodes. Moreover, it should be possible to get a hierarchy of device objects
> > this way that will reflect all of the dependencies we need to take into
> > account during hot-add and hot-remove operations. That may not be what we
> > have today, but I don't see any *fundamental* obstacles preventing us from
> > using this approach.
>
> I would _much_ rather see that be the solution here as I think it is the
> proper one.
>
> > This is already done for PCI host bridges and platform devices and I don't
> > see why we can't do that for the other types of devices too.
>
> I agree.
>
> > The only missing piece I see is a way to handle the "eject" problem, i.e.
> > when we try do eject a device at the top of a subtree and need to tear down
> > the entire subtree below it, but if that's going to lead to a system crash,
> > for example, we want to cancel the eject. It seems to me that we'll need some
> > help from the driver core here.
>
> I say do what we always have done here, if the user asked us to tear
> something down, let it happen as they are the ones that know best :)
>
> Seriously, I guess this gets back to the "fail disconnect" idea that the
> ACPI developers keep harping on. I thought we already resolved this
> properly by having them implement it in their bus code, no reason the
> same thing couldn't happen here, right?
Not really. :-) We haven't ever resolved that particular issue I'm afraid.
> I don't think the core needs to do anything special, but if so, I'll be glad
> to review it.
OK, so this is the use case. We have "eject" defined for something like
a container with a number of CPU cores, PCI host bridge, and a memory
controller under it. And a few pretty much arbitrary I/O devices as a bonus.
Now, there's a button on the system case labeled as "Eject" and if that button
is pressed, we're supposed to _try_ to eject all of those things at once. We
are allowed to fail that request, though, if that's problematic for some
reason, but we're supposed to let the BIOS know about that.
Do you seriously think that if that button is pressed, we should just proceed
with removing all that stuff no matter what? That'd be kind of like Russian
roulette for whoever pressed that button, because s/he could only press it and
wait for the system to either crash or not. Or maybe to crash a bit later
because of some delayed stuff that would hit one of those devices that had just
gone. Surely not a situation any admin of a high-availability system would
like to be in. :-)
Quite frankly, I have no idea how that can be addressed in a single bus type,
let alone ACPI (which is not even a proper bus type, just something pretending
to be one).
Thanks,
Rafael
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
^ permalink raw reply
* Re: [RFC PATCH v2 01/12] Add sys_hotplug.h for system device hotplug framework
From: Rafael J. Wysocki @ 2013-02-01 22:21 UTC (permalink / raw)
To: Toshi Kani
Cc: linux-s390@vger.kernel.org, jiang.liu@huawei.com,
wency@cn.fujitsu.com, linux-acpi@vger.kernel.org, Greg KH,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
isimatu.yasuaki@jp.fujitsu.com, yinghai@kernel.org,
srivatsa.bhat@linux.vnet.ibm.com, guohanjun@huawei.com,
bhelgaas@google.com, akpm@linux-foundation.org,
linuxppc-dev@lists.ozlabs.org, lenb@kernel.org
In-Reply-To: <1359751210.15120.278.camel@misato.fc.hp.com>
On Friday, February 01, 2013 01:40:10 PM Toshi Kani wrote:
> On Fri, 2013-02-01 at 07:30 +0000, Greg KH wrote:
> > On Thu, Jan 31, 2013 at 06:32:18PM -0700, Toshi Kani wrote:
> > > This is already done for PCI host bridges and platform devices and I don't
> > > > see why we can't do that for the other types of devices too.
> > > >
> > > > The only missing piece I see is a way to handle the "eject" problem, i.e.
> > > > when we try do eject a device at the top of a subtree and need to tear down
> > > > the entire subtree below it, but if that's going to lead to a system crash,
> > > > for example, we want to cancel the eject. It seems to me that we'll need some
> > > > help from the driver core here.
> > >
> > > There are three different approaches suggested for system device
> > > hot-plug:
> > > A. Proceed within system device bus scan.
> > > B. Proceed within ACPI bus scan.
> > > C. Proceed with a sequence (as a mini-boot).
> > >
> > > Option A uses system devices as tokens, option B uses acpi devices as
> > > tokens, and option C uses resource tables as tokens, for their handlers.
> > >
> > > Here is summary of key questions & answers so far. I hope this
> > > clarifies why I am suggesting option 3.
> > >
> > > 1. What are the system devices?
> > > System devices provide system-wide core computing resources, which are
> > > essential to compose a computer system. System devices are not
> > > connected to any particular standard buses.
> >
> > Not a problem, lots of devices are not connected to any "particular
> > standard busses". All this means is that system devices are connected
> > to the "system" bus, nothing more.
>
> Can you give me a few examples of other devices that support hotplug and
> are not connected to any particular buses? I will investigate them to
> see how they are managed to support hotplug.
>
> > > 2. Why are the system devices special?
> > > The system devices are initialized during early boot-time, by multiple
> > > subsystems, from the boot-up sequence, in pre-defined order. They
> > > provide low-level services to enable other subsystems to come up.
> >
> > Sorry, no, that doesn't mean they are special, nothing here is unique
> > for the point of view of the driver model from any other device or bus.
>
> I think system devices are unique in a sense that they are initialized
> before drivers run.
>
> > > 3. Why can't initialize the system devices from the driver structure at
> > > boot?
> > > The driver structure is initialized at the end of the boot sequence and
> > > requires the low-level services from the system devices initialized
> > > beforehand.
> >
> > Wait, what "driver structure"?
>
> Sorry it was not clear. cpu_dev_init() and memory_dev_init() are called
> from driver_init() at the end of the boot sequence, and initialize
> system/cpu and system/memory devices. I assume they are the system bus
> you are referring with option A.
>
> > If you need to initialize the driver
> > core earlier, then do so. Or, even better, just wait until enough of
> > the system has come up and then go initialize all of the devices you
> > have found so far as part of your boot process.
>
> They are pseudo drivers that provide sysfs entry points of cpu and
> memory. They do not actually initialize cpu and memory. I do not think
> initializing cpu and memory fits into the driver model either, since
> drivers should run after cpu and memory are initialized.
>
> > None of the above things you have stated seem to have anything to do
> > with your proposed patch, so I don't understand why you have mentioned
> > them...
>
> You suggested option A before, which uses system bus scan to initialize
> all system devices at boot time as well as hot-plug. I tried to say
> that this option would not be doable.
>
> > > 4. Why do we need a new common framework?
> > > Sysfs CPU and memory on-lining/off-lining are performed within the CPU
> > > and memory modules. They are common code and do not depend on ACPI.
> > > Therefore, a new common framework is necessary to integrate both
> > > on-lining/off-lining operation and hot-plugging operation of system
> > > devices into a single framework.
> >
> > {sigh}
> >
> > Removing and adding devices and handling hotplug operations is what the
> > driver core was written for, almost 10 years ago. To somehow think that
> > your devices are "special" just because they don't use ACPI is odd,
> > because the driver core itself has nothing to do with ACPI. Don't get
> > the current mix of x86 system code tied into ACPI confused with an
> > driver core issues here please.
>
> CPU online/offline operation is performed within the CPU module. Memory
> online/offline operation is performed within the memory module. CPU and
> memory hotplug operations are performed within ACPI. While they deal
> with the same set of devices, they operate independently and are not
> managed under a same framework.
>
> I agree with you that not using ACPI is perfectly fine. My point is
> that ACPI framework won't be able to manage operations that do not use
> ACPI.
>
> > > 5. Why can't do everything with ACPI bus scan?
> > > Software dependency among system devices may not be dictated by the ACPI
> > > hierarchy. For instance, memory should be initialized before CPUs (i.e.
> > > a new cpu may need its local memory), but such ordering cannot be
> > > guaranteed by the ACPI hierarchy. Also, as described in 4,
> > > online/offline operations are independent from ACPI.
> >
> > That's fine, the driver core is independant from ACPI. I don't care how
> > you do the scaning of your devices, but I do care about you creating new
> > driver core pieces that duplicate the existing functionality of what we
> > have today.
> >
> > In short, I like Rafael's proposal better, and I fail to see how
> > anything you have stated here would matter in how this is implemented. :)
>
> Doing everything within ACPI means we can only manage ACPI hotplug
> operations, not online/offline operations. But I understand that you
> concern about adding a new framework with option C. It is good to know
> that you are fine with option B. :) So, I will step back, and think
> about what we can do within ACPI.
Not much, because ACPI only knows about a subset of devices that may be
involved in that, and a limited one for that matter. For one example,
anything connected through PCI and not having a corresponding ACPI object (i.e.
pretty much every add-in card in existence) will be unknown to ACPI. And
say one of these things is a SATA controller with a number of disks under it
and so on. ACPI won't even know that it exists. Moreover, PCI won't know
that those disks exist. Etc.
Thanks,
Rafael
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
^ permalink raw reply
* Re: [RFC PATCH v2 01/12] Add sys_hotplug.h for system device hotplug framework
From: Toshi Kani @ 2013-02-01 23:12 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: linux-s390@vger.kernel.org, jiang.liu@huawei.com,
wency@cn.fujitsu.com, linux-acpi@vger.kernel.org, Greg KH,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
isimatu.yasuaki@jp.fujitsu.com, yinghai@kernel.org,
srivatsa.bhat@linux.vnet.ibm.com, guohanjun@huawei.com,
bhelgaas@google.com, akpm@linux-foundation.org,
linuxppc-dev@lists.ozlabs.org, lenb@kernel.org
In-Reply-To: <2370118.yuaZBuKn6n@vostro.rjw.lan>
On Fri, 2013-02-01 at 23:21 +0100, Rafael J. Wysocki wrote:
> On Friday, February 01, 2013 01:40:10 PM Toshi Kani wrote:
> > On Fri, 2013-02-01 at 07:30 +0000, Greg KH wrote:
> > > On Thu, Jan 31, 2013 at 06:32:18PM -0700, Toshi Kani wrote:
> > > > This is already done for PCI host bridges and platform devices and I don't
> > > > > see why we can't do that for the other types of devices too.
> > > > >
> > > > > The only missing piece I see is a way to handle the "eject" problem, i.e.
> > > > > when we try do eject a device at the top of a subtree and need to tear down
> > > > > the entire subtree below it, but if that's going to lead to a system crash,
> > > > > for example, we want to cancel the eject. It seems to me that we'll need some
> > > > > help from the driver core here.
> > > >
> > > > There are three different approaches suggested for system device
> > > > hot-plug:
> > > > A. Proceed within system device bus scan.
> > > > B. Proceed within ACPI bus scan.
> > > > C. Proceed with a sequence (as a mini-boot).
> > > >
> > > > Option A uses system devices as tokens, option B uses acpi devices as
> > > > tokens, and option C uses resource tables as tokens, for their handlers.
> > > >
> > > > Here is summary of key questions & answers so far. I hope this
> > > > clarifies why I am suggesting option 3.
> > > >
> > > > 1. What are the system devices?
> > > > System devices provide system-wide core computing resources, which are
> > > > essential to compose a computer system. System devices are not
> > > > connected to any particular standard buses.
> > >
> > > Not a problem, lots of devices are not connected to any "particular
> > > standard busses". All this means is that system devices are connected
> > > to the "system" bus, nothing more.
> >
> > Can you give me a few examples of other devices that support hotplug and
> > are not connected to any particular buses? I will investigate them to
> > see how they are managed to support hotplug.
> >
> > > > 2. Why are the system devices special?
> > > > The system devices are initialized during early boot-time, by multiple
> > > > subsystems, from the boot-up sequence, in pre-defined order. They
> > > > provide low-level services to enable other subsystems to come up.
> > >
> > > Sorry, no, that doesn't mean they are special, nothing here is unique
> > > for the point of view of the driver model from any other device or bus.
> >
> > I think system devices are unique in a sense that they are initialized
> > before drivers run.
> >
> > > > 3. Why can't initialize the system devices from the driver structure at
> > > > boot?
> > > > The driver structure is initialized at the end of the boot sequence and
> > > > requires the low-level services from the system devices initialized
> > > > beforehand.
> > >
> > > Wait, what "driver structure"?
> >
> > Sorry it was not clear. cpu_dev_init() and memory_dev_init() are called
> > from driver_init() at the end of the boot sequence, and initialize
> > system/cpu and system/memory devices. I assume they are the system bus
> > you are referring with option A.
> >
> > > If you need to initialize the driver
> > > core earlier, then do so. Or, even better, just wait until enough of
> > > the system has come up and then go initialize all of the devices you
> > > have found so far as part of your boot process.
> >
> > They are pseudo drivers that provide sysfs entry points of cpu and
> > memory. They do not actually initialize cpu and memory. I do not think
> > initializing cpu and memory fits into the driver model either, since
> > drivers should run after cpu and memory are initialized.
> >
> > > None of the above things you have stated seem to have anything to do
> > > with your proposed patch, so I don't understand why you have mentioned
> > > them...
> >
> > You suggested option A before, which uses system bus scan to initialize
> > all system devices at boot time as well as hot-plug. I tried to say
> > that this option would not be doable.
> >
> > > > 4. Why do we need a new common framework?
> > > > Sysfs CPU and memory on-lining/off-lining are performed within the CPU
> > > > and memory modules. They are common code and do not depend on ACPI.
> > > > Therefore, a new common framework is necessary to integrate both
> > > > on-lining/off-lining operation and hot-plugging operation of system
> > > > devices into a single framework.
> > >
> > > {sigh}
> > >
> > > Removing and adding devices and handling hotplug operations is what the
> > > driver core was written for, almost 10 years ago. To somehow think that
> > > your devices are "special" just because they don't use ACPI is odd,
> > > because the driver core itself has nothing to do with ACPI. Don't get
> > > the current mix of x86 system code tied into ACPI confused with an
> > > driver core issues here please.
> >
> > CPU online/offline operation is performed within the CPU module. Memory
> > online/offline operation is performed within the memory module. CPU and
> > memory hotplug operations are performed within ACPI. While they deal
> > with the same set of devices, they operate independently and are not
> > managed under a same framework.
> >
> > I agree with you that not using ACPI is perfectly fine. My point is
> > that ACPI framework won't be able to manage operations that do not use
> > ACPI.
> >
> > > > 5. Why can't do everything with ACPI bus scan?
> > > > Software dependency among system devices may not be dictated by the ACPI
> > > > hierarchy. For instance, memory should be initialized before CPUs (i.e.
> > > > a new cpu may need its local memory), but such ordering cannot be
> > > > guaranteed by the ACPI hierarchy. Also, as described in 4,
> > > > online/offline operations are independent from ACPI.
> > >
> > > That's fine, the driver core is independant from ACPI. I don't care how
> > > you do the scaning of your devices, but I do care about you creating new
> > > driver core pieces that duplicate the existing functionality of what we
> > > have today.
> > >
> > > In short, I like Rafael's proposal better, and I fail to see how
> > > anything you have stated here would matter in how this is implemented. :)
> >
> > Doing everything within ACPI means we can only manage ACPI hotplug
> > operations, not online/offline operations. But I understand that you
> > concern about adding a new framework with option C. It is good to know
> > that you are fine with option B. :) So, I will step back, and think
> > about what we can do within ACPI.
>
> Not much, because ACPI only knows about a subset of devices that may be
> involved in that, and a limited one for that matter. For one example,
> anything connected through PCI and not having a corresponding ACPI object (i.e.
> pretty much every add-in card in existence) will be unknown to ACPI. And
> say one of these things is a SATA controller with a number of disks under it
> and so on. ACPI won't even know that it exists. Moreover, PCI won't know
> that those disks exist. Etc.
Agreed. Thanks for bringing I/Os into the picture. I did not mention
them since they have not supported in this patchset, but we certainly
need to consider them into the design.
Thanks,
-Toshi
^ permalink raw reply
* Re: [PATCH 1/1] powerpc/85xx: Board support for ppa8548
From: Scott Wood @ 2013-02-02 0:31 UTC (permalink / raw)
To: Stef van Os; +Cc: Paul Mackerras, linuxppc-dev, Stef van Os
In-Reply-To: <1359733013-722-1-git-send-email-stef.van.os@prodrive.nl>
On 02/01/2013 09:36:53 AM, Stef van Os wrote:
> + memory {
> + device_type =3D "memory";
> + reg =3D <0 0 0x0 0x40000000>;
> + };
You have a "filled in by U-Boot" comment elsewhere in the file, but you =20
aren't letting U-Boot fill in the memory size?
> + board_lbc: lbc: localbus@fe0005000 {
> + reg =3D <0xf 0xe0005000 0 0x1000>;
> + ranges =3D <0x0 0x0 0xf 0xff800000 0x00800000>;
> + };
> +
> + board_soc: soc: soc8548@fe0000000 {
> + ranges =3D <0 0xf 0xe0000000 0x100000>;
> + };
I know some existing dts files do this, but there's no need for two =20
labels one one node.
> + rio: rapidio@fe00c0000 {
> + reg =3D <0xf 0xe00c0000 0x0 0x11000>;
> + port1 {
> + ranges =3D <0x0 0x0 0x0 0x80000000 0x0 =20
> 0x40000000>;
> + };
> + };
> +};
> +
> +&lbc {
> + #address-cells =3D <2>;
> + #size-cells =3D <1>;
> + compatible =3D "fsl,mpc8548-lbc", "fsl,pq3-localbus", =20
> "simple-bus";
> + interrupts =3D <19 2 0 0>;
> +};
> +
> +&rio {
> + compatible =3D "fsl,srio";
> + interrupts =3D <48 2 0 0>;
> + #address-cells =3D <2>;
> + #size-cells =3D <2>;
> + fsl,srio-rmu-handle =3D <&rmu>;
> + ranges;
> +
> + port1 {
> + #address-cells =3D <2>;
> + #size-cells =3D <2>;
> + cell-index =3D <1>;
> + };
> +};
> +
> +&soc {
> + #address-cells =3D <1>;
> + #size-cells =3D <1>;
> + device_type =3D "soc";
> + compatible =3D "fsl,mpc8548-immr", "simple-bus";
> + bus-frequency =3D <0>; // Filled out by uboot.
> +
> + ecm-law@0 {
> + compatible =3D "fsl,ecm-law";
> + reg =3D <0x0 0x1000>;
> + fsl,num-laws =3D <10>;
> + };
> +
> + ecm@1000 {
> + compatible =3D "fsl,mpc8548-ecm", "fsl,ecm";
> + reg =3D <0x1000 0x1000>;
> + interrupts =3D <17 2 0 0>;
> + };
> +
> + memory-controller@2000 {
> + compatible =3D "fsl,mpc8548-memory-controller";
> + reg =3D <0x2000 0x1000>;
> + interrupts =3D <18 2 0 0>;
> + };
> +
> +/include/ "fsl/pq3-i2c-0.dtsi"
> +/include/ "fsl/pq3-i2c-1.dtsi"
> +/include/ "fsl/pq3-duart-0.dtsi"
> +
> + L2: l2-cache-controller@20000 {
> + compatible =3D "fsl,mpc8548-l2-cache-controller";
> + reg =3D <0x20000 0x1000>;
> + cache-line-size =3D <32>; // 32 bytes
> + cache-size =3D <0x80000>; // L2, 512K
> + interrupts =3D <16 2 0 0>;
> + };
> +
> +/include/ "fsl/pq3-dma-0.dtsi"
> +/include/ "fsl/pq3-etsec1-0.dtsi"
> +/include/ "fsl/pq3-etsec1-1.dtsi"
> +/include/ "fsl/pq3-etsec1-2.dtsi"
> +/include/ "fsl/pq3-etsec1-3.dtsi"
> +
> +/include/ "fsl/pq3-sec2.1-0.dtsi"
> +/include/ "fsl/pq3-mpic.dtsi"
> +/include/ "fsl/pq3-rmu-0.dtsi"
> +
> + global-utilities@e0000 {
> + compatible =3D "fsl,mpc8548-guts";
> + reg =3D <0xe0000 0x1000>;
> + fsl,has-rstcr;
> + };
> +};
I guess the reason you're not using fsl/mpc8548si-post.dtsi is that you =20
don't want PCI. Maybe PCI and srio should be moved out of that file, =20
or ifdeffed if 85xx ever ends up using the preprocessor for its device =20
trees.
> diff --git a/arch/powerpc/platforms/85xx/ppa8548.c =20
> b/arch/powerpc/platforms/85xx/ppa8548.c
> new file mode 100644
> index 0000000..80a9307
> --- /dev/null
> +++ b/arch/powerpc/platforms/85xx/ppa8548.c
> @@ -0,0 +1,119 @@
> +/*
> + * ppa8548 setup and early boot code.
> + *
> + * Copyright 2009 Prodrive B.V..
> + *
> + * By Stef van Os (see MAINTAINERS for contact information)
> + *
> + * Based on the SBC8548 support - Copyright 2007 Wind River Systems =20
> Inc.
> + * Based on the MPC8548CDS support - Copyright 2005 Freescale Inc.
> + *
> + * This program is free software; you can redistribute it and/or =20
> modify it
> + * under the terms of the GNU General Public License as published =20
> by the
> + * Free Software Foundation; either version 2 of the License, or =20
> (at your
> + * option) any later version.
> + */
> +
> +#include <linux/stddef.h>
> +#include <linux/kernel.h>
> +#include <linux/init.h>
> +#include <linux/errno.h>
> +#include <linux/reboot.h>
> +#include <linux/kdev_t.h>
> +#include <linux/major.h>
> +#include <linux/console.h>
> +#include <linux/delay.h>
> +#include <linux/seq_file.h>
> +#include <linux/initrd.h>
> +#include <linux/module.h>
> +#include <linux/interrupt.h>
> +#include <linux/fsl_devices.h>
> +#include <linux/of_platform.h>
> +
> +#include <asm/pgtable.h>
> +#include <asm/page.h>
> +#include <asm/atomic.h>
> +#include <asm/time.h>
> +#include <asm/io.h>
> +#include <asm/machdep.h>
> +#include <asm/ipic.h>
> +#include <asm/irq.h>
> +#include <mm/mmu_decl.h>
> +#include <asm/prom.h>
> +#include <asm/udbg.h>
> +#include <asm/mpic.h>
> +
> +#include <sysdev/fsl_soc.h>
I doubt you need all of these.
E.g. asm/ipic.h is for 83xx and 512x chips. Some others are for things =20
that haven't been done by board files for years (e.g. kdev_t.h).
> +static void ppa8548_show_cpuinfo(struct seq_file *m)
> +{
> + uint pvid, svid, phid1;
> +
> + pvid =3D mfspr(SPRN_PVR);
> + svid =3D mfspr(SPRN_SVR);
> +
> + seq_printf(m, "Vendor\t\t: Prodrive B.V.\n");
> + seq_printf(m, "Machine\t\t: ppa8548\n");
> + seq_printf(m, "PVR\t\t: 0x%x\n", pvid);
> + seq_printf(m, "SVR\t\t: 0x%x\n", svid);
> +
> + /* Display cpu Pll setting */
> + phid1 =3D mfspr(SPRN_HID1);
> + seq_printf(m, "PLL setting\t: 0x%x\n", ((phid1 >> 24) & 0x3f));
> +}
PVR and ppc_md.name are already shown by the generic /proc/cpuinfo code.
-Scott=
^ permalink raw reply
* Re: [PATCH] powerpc/512x: add function for CS parameter configuration
From: Timur Tabi @ 2013-02-02 4:31 UTC (permalink / raw)
To: Anatolij Gustschin; +Cc: linuxppc-dev
In-Reply-To: <1359725305-23916-1-git-send-email-agust@denx.de>
On Fri, Feb 1, 2013 at 7:28 AM, Anatolij Gustschin <agust@denx.de> wrote:
> Add ability to configure CS parameters for devices that need
> different CS parameters setup after their configuration. I.e.
> an FPGA device on LP bus can require different CS parameters
> for its bus interface after loading firmware into it. A driver
> can easily reconfigure the LPC CS parameters using this function.
Could you define "CS" somewhere?
> +struct mpc512x_lpc {
> + u32 cs_cfg[8]; /* CS config */
> + u32 cs_ctrl; /* CS Control Register */
> + u32 cs_status; /* CS Status Register */
> + u32 burst_ctrl; /* CS Burst Control Register */
> + u32 deadcycle_ctrl; /* CS Deadcycle Control Register */
> + u32 holdcycle_ctrl; /* CS Holdcycle Control Register */
> + u32 alt; /* Address Latch Timing Register */
> +};
These should be __be32.
> +
> +int mpc512x_cs_config(int cs, u32 val);
> +
> #endif /* __ASM_POWERPC_MPC5121_H__ */
> diff --git a/arch/powerpc/platforms/512x/mpc512x_shared.c b/arch/powerpc/platforms/512x/mpc512x_shared.c
> index c344438..112b4f6 100644
> --- a/arch/powerpc/platforms/512x/mpc512x_shared.c
> +++ b/arch/powerpc/platforms/512x/mpc512x_shared.c
> @@ -436,3 +436,33 @@ void __init mpc512x_init(void)
> mpc512x_restart_init();
> mpc512x_psc_fifo_init();
> }
> +
> +/**
> + * mpc512x_cs_config - Setup chip select configuration
> + * @cs: chip select number
> + * @val: chip select configuration value
> + *
> + * Perform chip select configuration for devices on LocalPlus Bus.
> + * Intended to dynamically reconfigure the chip select parameters
> + * for configurable devices on the bus.
> + */
> +int mpc512x_cs_config(int cs, u32 val)
> +{
> + static struct mpc512x_lpc __iomem *lpc;
> + struct device_node *np;
> +
> + if (cs < 0 || cs > 7)
> + return -EINVAL;
If you make cs an unsigned int, you won't need to test for < 0.
> +
> + if (!lpc) {
> + np = of_find_compatible_node(NULL, NULL, "fsl,mpc5121-lpc");
> + lpc = of_iomap(np, 0);
> + of_node_put(np);
> + if (!lpc)
> + return -ENOMEM;
> + }
> +
> + out_be32(&lpc->cs_cfg[cs], val);
You forgot the iounmap() if lpc == NULL.
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(mpc512x_cs_config);
EXPORT_SYMBOL, please, to match the rest of the Freescale platforms.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [PATCH 1/1] powerpc/85xx: Board support for ppa8548
From: Timur Tabi @ 2013-02-02 4:34 UTC (permalink / raw)
To: Scott Wood; +Cc: Stef van Os, Paul Mackerras, linuxppc-dev
In-Reply-To: <1359765063.23561.14@snotra>
On Fri, Feb 1, 2013 at 6:31 PM, Scott Wood <scottwood@freescale.com> wrote:
>
> I guess the reason you're not using fsl/mpc8548si-post.dtsi is that you
> don't want PCI. Maybe PCI and srio should be moved out of that file, or
> ifdeffed if 85xx ever ends up using the preprocessor for its device trees.
Wouldn't it be easier to add status="disabled" in this dts file? I do
something similar with the LBC on the p1022rdk.
board_lbc: lbc: localbus@ffe05000 {
/* The P1022 RDK does not have any localbus devices */
status = "disabled";
};
^ permalink raw reply
* linux-next: build failure after merge of the tip tree
From: Stephen Rothwell @ 2013-02-02 5:04 UTC (permalink / raw)
To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
Cc: Sukadev Bhattiprolu, linux-next, linux-kernel, linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 3674 bytes --]
Hi all,
After merging the tip tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
arch/powerpc/perf/power7-pmu.c:397:2: error: initialization from incompatible pointer type [-Werror]
arch/powerpc/perf/power7-pmu.c:397:2: error: (near initialization for 'power7_events_attr[0]') [-Werror]
arch/powerpc/perf/power7-pmu.c:398:2: error: initialization from incompatible pointer type [-Werror]
arch/powerpc/perf/power7-pmu.c:398:2: error: (near initialization for 'power7_events_attr[1]') [-Werror]
arch/powerpc/perf/power7-pmu.c:399:2: error: initialization from incompatible pointer type [-Werror]
arch/powerpc/perf/power7-pmu.c:399:2: error: (near initialization for 'power7_events_attr[2]') [-Werror]
arch/powerpc/perf/power7-pmu.c:400:2: error: initialization from incompatible pointer type [-Werror]
arch/powerpc/perf/power7-pmu.c:400:2: error: (near initialization for 'power7_events_attr[3]') [-Werror]
arch/powerpc/perf/power7-pmu.c:401:2: error: initialization from incompatible pointer type [-Werror]
arch/powerpc/perf/power7-pmu.c:401:2: error: (near initialization for 'power7_events_attr[4]') [-Werror]
arch/powerpc/perf/power7-pmu.c:402:2: error: initialization from incompatible pointer type [-Werror]
arch/powerpc/perf/power7-pmu.c:402:2: error: (near initialization for 'power7_events_attr[5]') [-Werror]
arch/powerpc/perf/power7-pmu.c:403:2: error: initialization from incompatible pointer type [-Werror]
arch/powerpc/perf/power7-pmu.c:403:2: error: (near initialization for 'power7_events_attr[6]') [-Werror]
arch/powerpc/perf/power7-pmu.c:404:2: error: initialization from incompatible pointer type [-Werror]
arch/powerpc/perf/power7-pmu.c:404:2: error: (near initialization for 'power7_events_attr[7]') [-Werror]
arch/powerpc/perf/power7-pmu.c:406:2: error: initialization from incompatible pointer type [-Werror]
arch/powerpc/perf/power7-pmu.c:406:2: error: (near initialization for 'power7_events_attr[8]') [-Werror]
arch/powerpc/perf/power7-pmu.c:407:2: error: initialization from incompatible pointer type [-Werror]
arch/powerpc/perf/power7-pmu.c:407:2: error: (near initialization for 'power7_events_attr[9]') [-Werror]
arch/powerpc/perf/power7-pmu.c:408:2: error: initialization from incompatible pointer type [-Werror]
arch/powerpc/perf/power7-pmu.c:408:2: error: (near initialization for 'power7_events_attr[10]') [-Werror]
arch/powerpc/perf/power7-pmu.c:409:2: error: initialization from incompatible pointer type [-Werror]
arch/powerpc/perf/power7-pmu.c:409:2: error: (near initialization for 'power7_events_attr[11]') [-Werror]
arch/powerpc/perf/power7-pmu.c:410:2: error: initialization from incompatible pointer type [-Werror]
arch/powerpc/perf/power7-pmu.c:410:2: error: (near initialization for 'power7_events_attr[12]') [-Werror]
arch/powerpc/perf/power7-pmu.c:411:2: error: initialization from incompatible pointer type [-Werror]
arch/powerpc/perf/power7-pmu.c:411:2: error: (near initialization for 'power7_events_attr[13]') [-Werror]
arch/powerpc/perf/power7-pmu.c:412:2: error: initialization from incompatible pointer type [-Werror]
arch/powerpc/perf/power7-pmu.c:412:2: error: (near initialization for 'power7_events_attr[14]') [-Werror]
arch/powerpc/perf/power7-pmu.c:413:2: error: initialization from incompatible pointer type [-Werror]
arch/powerpc/perf/power7-pmu.c:413:2: error: (near initialization for 'power7_events_attr[15]') [-Werror]
Caused by commit 1c53a270724d ("perf/POWER7: Make generic event
translations available in sysfs").
I have used the tip tree from 20130128 for today.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH] PowerPC documentation: fixed path to the powerpc directory
From: Thomas Waldecker @ 2013-02-02 9:08 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, paulus, linux-kernel, rob, linux-doc
In-Reply-To: <1357858846.4838.92.camel@pasglop>
Hi Ben,
I sent it twice, sorry. I haven't seen it applied for a long time and
got no response.
It is already applied.
Kind regards,
Thomas
^ permalink raw reply
* AW: Why is the e500v2 core not using cpuidle?
From: Thomas Waldecker @ 2013-02-02 9:41 UTC (permalink / raw)
To: Scott Wood; +Cc: Linux PPC dev mailing list (linuxppc-dev@lists.ozlabs.org)
In-Reply-To: <1359742517.23561.2@snotra>
Hi Scott,=0A=
=0A=
>> Why is there no support for the cpuidle framework?=0A=
> Because nobody implemented it. :-)=0A=
That's the reason I thought before :-)=0A=
=0A=
> The only reason I can think of to implement it on this chip would be to=
=0A=
> dynamically choose when to enter nap versus doze, rather than always=0A=
> just using doze. It's not clear whether the difference in power=0A=
> savings is worth it -- do you have any way of measuring?=0A=
=0A=
Is the e500 only using doze? There are comments in the file =0A=
arch/powerpc/kernel/idle_e500.S=0A=
which are stating:=0A=
/* Go to NAP or DOZE now */=0A=
or=0A=
/* Return from NAP/DOZE ...*/=0A=
=0A=
and because of this comments I thought that both modes are in use.=0A=
=0A=
I have a way of measuring the power and it is also a small part of my maste=
rthesis,=0A=
but it is not very meaningful because at the measuring point there are othe=
r peripheral=0A=
components too.=0A=
=0A=
According to the comments can I activate the nap mode somehow?=0A=
=0A=
>> How can I debug the e500 idle modes?=0A=
>> Are there any statistics?=0A=
> Top reports idle percentage...=0A=
If the e500 and e500v2 are indeed using only the doze mode it =0A=
would be enough statistics.=0A=
=0A=
>> I already ran PowerTOP on a QorIQ P2020 but it's almost useless=0A=
>> because the information is missing.=0A=
> What information are you looking for?=0A=
=0A=
On my laptop I get detailled idle stats in PowerTOP 2.2=0A=
=0A=
Package | CPU 0=0A=
POLL 0.0% | POLL 0.0% 0.0 ms=0A=
C1 0.7% | C1 0.4% 0.2 ms=0A=
C2 86.0% | C2 86.8% 1.4 ms=0A=
=0A=
| CPU 1=0A=
| POLL 0.0% 0.4 ms=0A=
| C1 0.9% 0.6 ms=0A=
| C2 85.2% 1.5 ms=0A=
=0A=
It is using the sysfs interface=0A=
=0A=
thomas@localhost /s/d/s/c/c/cpuidle> pwd=0A=
/sys/devices/system/cpu/cpu0/cpuidle=0A=
thomas@localhost /s/d/s/c/c/cpuidle> tree=0A=
.=0A=
=86=80=80 state0=0A=
=81=9A=9A =86=80=80 desc=0A=
=81=9A=9A =86=80=80 disable=0A=
=81=9A=9A =86=80=80 latency=0A=
=81=9A=9A =86=80=80 name=0A=
=81=9A=9A =86=80=80 power=0A=
=81=9A=9A =86=80=80 time=0A=
=81=9A=9A =84=80=80 usage=0A=
=86=80=80 state1=0A=
(same as state0)=0A=
=84=80=80 state2=0A=
(also same as state 0)=0A=
thomas@localhost /s/d/s/c/c/cpuidle> cat */name=0A=
POLL=0A=
C1=0A=
C2=0A=
=0A=
Such statistics would be great for the doze, nap (and sleep for the whole p=
ackage).=0A=
=0A=
Kind regards,=0A=
Thomas=
^ permalink raw reply
* Re: [PATCH] powerpc/512x: add function for CS parameter configuration
From: Anatolij Gustschin @ 2013-02-02 12:02 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev
In-Reply-To: <CAOZdJXUfe5KWBtabUUPrGHhcFb6dbnPNJCsU23yoxb-4GeKQsg@mail.gmail.com>
On Fri, 1 Feb 2013 22:31:51 -0600
Timur Tabi <timur@tabi.org> wrote:
> On Fri, Feb 1, 2013 at 7:28 AM, Anatolij Gustschin <agust@denx.de> wrote:
> > Add ability to configure CS parameters for devices that need
> > different CS parameters setup after their configuration. I.e.
> > an FPGA device on LP bus can require different CS parameters
> > for its bus interface after loading firmware into it. A driver
> > can easily reconfigure the LPC CS parameters using this function.
>
> Could you define "CS" somewhere?
I'll define it in revised commit log in v2.
> > +struct mpc512x_lpc {
> > + u32 cs_cfg[8]; /* CS config */
> > + u32 cs_ctrl; /* CS Control Register */
> > + u32 cs_status; /* CS Status Register */
> > + u32 burst_ctrl; /* CS Burst Control Register */
> > + u32 deadcycle_ctrl; /* CS Deadcycle Control Register */
> > + u32 holdcycle_ctrl; /* CS Holdcycle Control Register */
> > + u32 alt; /* Address Latch Timing Register */
> > +};
>
> These should be __be32.
Why? To add a new bunch of sparse warnings?
...
> > + if (cs < 0 || cs > 7)
> > + return -EINVAL;
>
> If you make cs an unsigned int, you won't need to test for < 0.
can do that, yes.
> > +
> > + if (!lpc) {
> > + np = of_find_compatible_node(NULL, NULL, "fsl,mpc5121-lpc");
> > + lpc = of_iomap(np, 0);
> > + of_node_put(np);
> > + if (!lpc)
> > + return -ENOMEM;
> > + }
> > +
> > + out_be32(&lpc->cs_cfg[cs], val);
>
> You forgot the iounmap() if lpc == NULL.
No, it is intentional, no need to map/unmap again and again for all
subsequent calls.
> > + return 0;
> > +}
> > +EXPORT_SYMBOL_GPL(mpc512x_cs_config);
>
> EXPORT_SYMBOL, please, to match the rest of the Freescale platforms.
I'll change it in v2. Thanks!
Anatolij
^ permalink raw reply
* Re: [PATCH] powerpc/512x: add function for CS parameter configuration
From: Timur Tabi @ 2013-02-02 12:31 UTC (permalink / raw)
To: Anatolij Gustschin; +Cc: linuxppc-dev
In-Reply-To: <20130202130201.204ee2fd@crub>
Anatolij Gustschin wrote:
>>> +struct mpc512x_lpc {
>>> + u32 cs_cfg[8]; /* CS config */
>>> + u32 cs_ctrl; /* CS Control Register */
>>> + u32 cs_status; /* CS Status Register */
>>> + u32 burst_ctrl; /* CS Burst Control Register */
>>> + u32 deadcycle_ctrl; /* CS Deadcycle Control Register */
>>> + u32 holdcycle_ctrl; /* CS Holdcycle Control Register */
>>> + u32 alt; /* Address Latch Timing Register */
>>> +};
>>
>> These should be __be32.
>
> Why? To add a new bunch of sparse warnings?
Hmm... I thought that making them __be32 will *avoid* sparse warnings.
>> You forgot the iounmap() if lpc == NULL.
>
> No, it is intentional, no need to map/unmap again and again for all
> subsequent calls.
Sorry, for some reason I thought that lpc was a parameter that you passed in.
--
Timur Tabi
^ permalink raw reply
* Re: [RFC PATCH v2 01/12] Add sys_hotplug.h for system device hotplug framework
From: Greg KH @ 2013-02-02 14:58 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: linux-s390, Toshi Kani, jiang.liu, wency, linux-acpi, yinghai,
linux-kernel, linux-mm, isimatu.yasuaki, srivatsa.bhat, guohanjun,
bhelgaas, akpm, linuxppc-dev, lenb
In-Reply-To: <1987042.JQv02Zsfg5@vostro.rjw.lan>
On Fri, Feb 01, 2013 at 11:12:59PM +0100, Rafael J. Wysocki wrote:
> On Friday, February 01, 2013 08:23:12 AM Greg KH wrote:
> > On Thu, Jan 31, 2013 at 09:54:51PM +0100, Rafael J. Wysocki wrote:
> > > > > But, again, I'm going to ask why you aren't using the existing cpu /
> > > > > memory / bridge / node devices that we have in the kernel. Please use
> > > > > them, or give me a _really_ good reason why they will not work.
> > > >
> > > > We cannot use the existing system devices or ACPI devices here. During
> > > > hot-plug, ACPI handler sets this shp_device info, so that cpu and memory
> > > > handlers (drivers/cpu.c and mm/memory_hotplug.c) can obtain their target
> > > > device information in a platform-neutral way. During hot-add, we first
> > > > creates an ACPI device node (i.e. device under /sys/bus/acpi/devices),
> > > > but platform-neutral modules cannot use them as they are ACPI-specific.
> > >
> > > But suppose we're smart and have ACPI scan handlers that will create
> > > "physical" device nodes for those devices during the ACPI namespace scan.
> > > Then, the platform-neutral nodes will be able to bind to those "physical"
> > > nodes. Moreover, it should be possible to get a hierarchy of device objects
> > > this way that will reflect all of the dependencies we need to take into
> > > account during hot-add and hot-remove operations. That may not be what we
> > > have today, but I don't see any *fundamental* obstacles preventing us from
> > > using this approach.
> >
> > I would _much_ rather see that be the solution here as I think it is the
> > proper one.
> >
> > > This is already done for PCI host bridges and platform devices and I don't
> > > see why we can't do that for the other types of devices too.
> >
> > I agree.
> >
> > > The only missing piece I see is a way to handle the "eject" problem, i.e.
> > > when we try do eject a device at the top of a subtree and need to tear down
> > > the entire subtree below it, but if that's going to lead to a system crash,
> > > for example, we want to cancel the eject. It seems to me that we'll need some
> > > help from the driver core here.
> >
> > I say do what we always have done here, if the user asked us to tear
> > something down, let it happen as they are the ones that know best :)
> >
> > Seriously, I guess this gets back to the "fail disconnect" idea that the
> > ACPI developers keep harping on. I thought we already resolved this
> > properly by having them implement it in their bus code, no reason the
> > same thing couldn't happen here, right?
>
> Not really. :-) We haven't ever resolved that particular issue I'm afraid.
Ah, I didn't realize that.
> > I don't think the core needs to do anything special, but if so, I'll be glad
> > to review it.
>
> OK, so this is the use case. We have "eject" defined for something like
> a container with a number of CPU cores, PCI host bridge, and a memory
> controller under it. And a few pretty much arbitrary I/O devices as a bonus.
>
> Now, there's a button on the system case labeled as "Eject" and if that button
> is pressed, we're supposed to _try_ to eject all of those things at once. We
> are allowed to fail that request, though, if that's problematic for some
> reason, but we're supposed to let the BIOS know about that.
>
> Do you seriously think that if that button is pressed, we should just proceed
> with removing all that stuff no matter what? That'd be kind of like Russian
> roulette for whoever pressed that button, because s/he could only press it and
> wait for the system to either crash or not. Or maybe to crash a bit later
> because of some delayed stuff that would hit one of those devices that had just
> gone. Surely not a situation any admin of a high-availability system would
> like to be in. :-)
>
> Quite frankly, I have no idea how that can be addressed in a single bus type,
> let alone ACPI (which is not even a proper bus type, just something pretending
> to be one).
You don't have it as a single bus type, you have a controller somewhere,
off of the bus being destroyed, that handles sending remove events to
the device and tearing everything down. PCI does this from the very
beginning.
I know it's more complicated with these types of devices, and I think we
are getting closer to the correct solution, I just don't want to ever
see duplicate devices in the driver model for the same physical device.
thanks,
greg k-h
^ permalink raw reply
* Re: [RFC PATCH v2 01/12] Add sys_hotplug.h for system device hotplug framework
From: Greg KH @ 2013-02-02 15:01 UTC (permalink / raw)
To: Toshi Kani
Cc: linux-s390@vger.kernel.org, jiang.liu@huawei.com,
wency@cn.fujitsu.com, linux-mm@kvack.org, yinghai@kernel.org,
linux-kernel@vger.kernel.org, Rafael J. Wysocki,
linux-acpi@vger.kernel.org, isimatu.yasuaki@jp.fujitsu.com,
srivatsa.bhat@linux.vnet.ibm.com, guohanjun@huawei.com,
bhelgaas@google.com, akpm@linux-foundation.org,
linuxppc-dev@lists.ozlabs.org, lenb@kernel.org
In-Reply-To: <1359751210.15120.278.camel@misato.fc.hp.com>
On Fri, Feb 01, 2013 at 01:40:10PM -0700, Toshi Kani wrote:
> On Fri, 2013-02-01 at 07:30 +0000, Greg KH wrote:
> > On Thu, Jan 31, 2013 at 06:32:18PM -0700, Toshi Kani wrote:
> > > This is already done for PCI host bridges and platform devices and I don't
> > > > see why we can't do that for the other types of devices too.
> > > >
> > > > The only missing piece I see is a way to handle the "eject" problem, i.e.
> > > > when we try do eject a device at the top of a subtree and need to tear down
> > > > the entire subtree below it, but if that's going to lead to a system crash,
> > > > for example, we want to cancel the eject. It seems to me that we'll need some
> > > > help from the driver core here.
> > >
> > > There are three different approaches suggested for system device
> > > hot-plug:
> > > A. Proceed within system device bus scan.
> > > B. Proceed within ACPI bus scan.
> > > C. Proceed with a sequence (as a mini-boot).
> > >
> > > Option A uses system devices as tokens, option B uses acpi devices as
> > > tokens, and option C uses resource tables as tokens, for their handlers.
> > >
> > > Here is summary of key questions & answers so far. I hope this
> > > clarifies why I am suggesting option 3.
> > >
> > > 1. What are the system devices?
> > > System devices provide system-wide core computing resources, which are
> > > essential to compose a computer system. System devices are not
> > > connected to any particular standard buses.
> >
> > Not a problem, lots of devices are not connected to any "particular
> > standard busses". All this means is that system devices are connected
> > to the "system" bus, nothing more.
>
> Can you give me a few examples of other devices that support hotplug and
> are not connected to any particular buses? I will investigate them to
> see how they are managed to support hotplug.
Any device that is attached to any bus in the driver model can be
hotunplugged from userspace by telling it to be "unbound" from the
driver controlling it. Try it for any platform device in your system to
see how it happens.
> > > 2. Why are the system devices special?
> > > The system devices are initialized during early boot-time, by multiple
> > > subsystems, from the boot-up sequence, in pre-defined order. They
> > > provide low-level services to enable other subsystems to come up.
> >
> > Sorry, no, that doesn't mean they are special, nothing here is unique
> > for the point of view of the driver model from any other device or bus.
>
> I think system devices are unique in a sense that they are initialized
> before drivers run.
No, most all devices are "initialized" before a driver runs on it, USB
is one such example, PCI another, and I'm pretty sure that there are
others.
> > If you need to initialize the driver
> > core earlier, then do so. Or, even better, just wait until enough of
> > the system has come up and then go initialize all of the devices you
> > have found so far as part of your boot process.
>
> They are pseudo drivers that provide sysfs entry points of cpu and
> memory. They do not actually initialize cpu and memory. I do not think
> initializing cpu and memory fits into the driver model either, since
> drivers should run after cpu and memory are initialized.
We already represent CPUs in the sysfs tree, don't represent them in two
different places with two different structures. Use the existing ones
please.
> > None of the above things you have stated seem to have anything to do
> > with your proposed patch, so I don't understand why you have mentioned
> > them...
>
> You suggested option A before, which uses system bus scan to initialize
> all system devices at boot time as well as hot-plug. I tried to say
> that this option would not be doable.
I haven't yet been convinced otherwise, sorry. Please prove me wrong :)
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH 1/1] powerpc/85xx: Board support for ppa8548
From: Stef van Os @ 2013-02-02 19:25 UTC (permalink / raw)
To: Scott Wood; +Cc: Paul Mackerras, linuxppc-dev, timur.tabi
In-Reply-To: <1359765063.23561.14@snotra>
Thanks for the comment!
On 02/02/2013 01:31 AM, Scott Wood wrote:
> On 02/01/2013 09:36:53 AM, Stef van Os wrote:
>> + memory {
>> + device_type = "memory";
>> + reg = <0 0 0x0 0x40000000>;
>> + };
>
> You have a "filled in by U-Boot" comment elsewhere in the file, but
> you aren't letting U-Boot fill in the memory size?
>
The U-Boot used in this board currently does not call the
fdt_fixup_memory function. Would have been better, but changing it now
requires production image changes and requalification.
>> + board_lbc: lbc: localbus@fe0005000 {
>> + reg = <0xf 0xe0005000 0 0x1000>;
>> + ranges = <0x0 0x0 0xf 0xff800000 0x00800000>;
>> + };
>> +
>> + board_soc: soc: soc8548@fe0000000 {
>> + ranges = <0 0xf 0xe0000000 0x100000>;
>> + };
>
> I know some existing dts files do this, but there's no need for two
> labels one one node.
True, fixed in v2 of patch.
>
>> + rio: rapidio@fe00c0000 {
>> + reg = <0xf 0xe00c0000 0x0 0x11000>;
>> + port1 {
>> + ranges = <0x0 0x0 0x0 0x80000000 0x0 0x40000000>;
>> + };
>> + };
>> +};
>> +
>> +&lbc {
>> + #address-cells = <2>;
>> + #size-cells = <1>;
>> + compatible = "fsl,mpc8548-lbc", "fsl,pq3-localbus", "simple-bus";
>> + interrupts = <19 2 0 0>;
>> +};
>> +
>> +&rio {
>> + compatible = "fsl,srio";
>> + interrupts = <48 2 0 0>;
>> + #address-cells = <2>;
>> + #size-cells = <2>;
>> + fsl,srio-rmu-handle = <&rmu>;
>> + ranges;
>> +
>> + port1 {
>> + #address-cells = <2>;
>> + #size-cells = <2>;
>> + cell-index = <1>;
>> + };
>> +};
>> +
>> +&soc {
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> + device_type = "soc";
>> + compatible = "fsl,mpc8548-immr", "simple-bus";
>> + bus-frequency = <0>; // Filled out by uboot.
>> +
>> + ecm-law@0 {
>> + compatible = "fsl,ecm-law";
>> + reg = <0x0 0x1000>;
>> + fsl,num-laws = <10>;
>> + };
>> +
>> + ecm@1000 {
>> + compatible = "fsl,mpc8548-ecm", "fsl,ecm";
>> + reg = <0x1000 0x1000>;
>> + interrupts = <17 2 0 0>;
>> + };
>> +
>> + memory-controller@2000 {
>> + compatible = "fsl,mpc8548-memory-controller";
>> + reg = <0x2000 0x1000>;
>> + interrupts = <18 2 0 0>;
>> + };
>> +
>> +/include/ "fsl/pq3-i2c-0.dtsi"
>> +/include/ "fsl/pq3-i2c-1.dtsi"
>> +/include/ "fsl/pq3-duart-0.dtsi"
>> +
>> + L2: l2-cache-controller@20000 {
>> + compatible = "fsl,mpc8548-l2-cache-controller";
>> + reg = <0x20000 0x1000>;
>> + cache-line-size = <32>; // 32 bytes
>> + cache-size = <0x80000>; // L2, 512K
>> + interrupts = <16 2 0 0>;
>> + };
>> +
>> +/include/ "fsl/pq3-dma-0.dtsi"
>> +/include/ "fsl/pq3-etsec1-0.dtsi"
>> +/include/ "fsl/pq3-etsec1-1.dtsi"
>> +/include/ "fsl/pq3-etsec1-2.dtsi"
>> +/include/ "fsl/pq3-etsec1-3.dtsi"
>> +
>> +/include/ "fsl/pq3-sec2.1-0.dtsi"
>> +/include/ "fsl/pq3-mpic.dtsi"
>> +/include/ "fsl/pq3-rmu-0.dtsi"
>> +
>> + global-utilities@e0000 {
>> + compatible = "fsl,mpc8548-guts";
>> + reg = <0xe0000 0x1000>;
>> + fsl,has-rstcr;
>> + };
>> +};
>
> I guess the reason you're not using fsl/mpc8548si-post.dtsi is that
> you don't want PCI. Maybe PCI and srio should be moved out of that
> file, or ifdeffed if 85xx ever ends up using the preprocessor for its
> device trees.
>
I went with timur's solution, patch v2 uses mpc8548si-post.dtsi and
mpc8548si-pre.dtsi again, disabling everything that is not on the board.
>> diff --git a/arch/powerpc/platforms/85xx/ppa8548.c
>> b/arch/powerpc/platforms/85xx/ppa8548.c
>> new file mode 100644
>> index 0000000..80a9307
>> --- /dev/null
>> +++ b/arch/powerpc/platforms/85xx/ppa8548.c
>> @@ -0,0 +1,119 @@
>> +/*
>> + * ppa8548 setup and early boot code.
>> + *
>> + * Copyright 2009 Prodrive B.V..
>> + *
>> + * By Stef van Os (see MAINTAINERS for contact information)
>> + *
>> + * Based on the SBC8548 support - Copyright 2007 Wind River Systems
>> Inc.
>> + * Based on the MPC8548CDS support - Copyright 2005 Freescale 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 <linux/stddef.h>
>> +#include <linux/kernel.h>
>> +#include <linux/init.h>
>> +#include <linux/errno.h>
>> +#include <linux/reboot.h>
>> +#include <linux/kdev_t.h>
>> +#include <linux/major.h>
>> +#include <linux/console.h>
>> +#include <linux/delay.h>
>> +#include <linux/seq_file.h>
>> +#include <linux/initrd.h>
>> +#include <linux/module.h>
>> +#include <linux/interrupt.h>
>> +#include <linux/fsl_devices.h>
>> +#include <linux/of_platform.h>
>> +
>> +#include <asm/pgtable.h>
>> +#include <asm/page.h>
>> +#include <asm/atomic.h>
>> +#include <asm/time.h>
>> +#include <asm/io.h>
>> +#include <asm/machdep.h>
>> +#include <asm/ipic.h>
>> +#include <asm/irq.h>
>> +#include <mm/mmu_decl.h>
>> +#include <asm/prom.h>
>> +#include <asm/udbg.h>
>> +#include <asm/mpic.h>
>> +
>> +#include <sysdev/fsl_soc.h>
>
> I doubt you need all of these.
>
> E.g. asm/ipic.h is for 83xx and 512x chips. Some others are for
> things that haven't been done by board files for years (e.g. kdev_t.h).
Fixed in v2, 10 includes left, instead of 25+...
>
>> +static void ppa8548_show_cpuinfo(struct seq_file *m)
>> +{
>> + uint pvid, svid, phid1;
>> +
>> + pvid = mfspr(SPRN_PVR);
>> + svid = mfspr(SPRN_SVR);
>> +
>> + seq_printf(m, "Vendor\t\t: Prodrive B.V.\n");
>> + seq_printf(m, "Machine\t\t: ppa8548\n");
>> + seq_printf(m, "PVR\t\t: 0x%x\n", pvid);
>> + seq_printf(m, "SVR\t\t: 0x%x\n", svid);
>> +
>> + /* Display cpu Pll setting */
>> + phid1 = mfspr(SPRN_HID1);
>> + seq_printf(m, "PLL setting\t: 0x%x\n", ((phid1 >> 24) & 0x3f));
>> +}
>
> PVR and ppc_md.name are already shown by the generic /proc/cpuinfo code.
>
> -Scott
Fixed, removed PVR and Machine. SVR is still shown, because it is not in
generic cpuinfo code.
Will do a test run of the changes and send out v2 later this weekend.
Regards,
Stef
^ permalink raw reply
* Re: [RFC PATCH v2 01/12] Add sys_hotplug.h for system device hotplug framework
From: Rafael J. Wysocki @ 2013-02-02 20:15 UTC (permalink / raw)
To: Greg KH
Cc: linux-s390, Toshi Kani, jiang.liu, wency, linux-acpi, yinghai,
linux-kernel, linux-mm, isimatu.yasuaki, srivatsa.bhat, guohanjun,
bhelgaas, akpm, linuxppc-dev, lenb
In-Reply-To: <20130202145801.GB1434@kroah.com>
On Saturday, February 02, 2013 03:58:01 PM Greg KH wrote:
> On Fri, Feb 01, 2013 at 11:12:59PM +0100, Rafael J. Wysocki wrote:
> > On Friday, February 01, 2013 08:23:12 AM Greg KH wrote:
> > > On Thu, Jan 31, 2013 at 09:54:51PM +0100, Rafael J. Wysocki wrote:
> > > > > > But, again, I'm going to ask why you aren't using the existing cpu /
> > > > > > memory / bridge / node devices that we have in the kernel. Please use
> > > > > > them, or give me a _really_ good reason why they will not work.
> > > > >
> > > > > We cannot use the existing system devices or ACPI devices here. During
> > > > > hot-plug, ACPI handler sets this shp_device info, so that cpu and memory
> > > > > handlers (drivers/cpu.c and mm/memory_hotplug.c) can obtain their target
> > > > > device information in a platform-neutral way. During hot-add, we first
> > > > > creates an ACPI device node (i.e. device under /sys/bus/acpi/devices),
> > > > > but platform-neutral modules cannot use them as they are ACPI-specific.
> > > >
> > > > But suppose we're smart and have ACPI scan handlers that will create
> > > > "physical" device nodes for those devices during the ACPI namespace scan.
> > > > Then, the platform-neutral nodes will be able to bind to those "physical"
> > > > nodes. Moreover, it should be possible to get a hierarchy of device objects
> > > > this way that will reflect all of the dependencies we need to take into
> > > > account during hot-add and hot-remove operations. That may not be what we
> > > > have today, but I don't see any *fundamental* obstacles preventing us from
> > > > using this approach.
> > >
> > > I would _much_ rather see that be the solution here as I think it is the
> > > proper one.
> > >
> > > > This is already done for PCI host bridges and platform devices and I don't
> > > > see why we can't do that for the other types of devices too.
> > >
> > > I agree.
> > >
> > > > The only missing piece I see is a way to handle the "eject" problem, i.e.
> > > > when we try do eject a device at the top of a subtree and need to tear down
> > > > the entire subtree below it, but if that's going to lead to a system crash,
> > > > for example, we want to cancel the eject. It seems to me that we'll need some
> > > > help from the driver core here.
> > >
> > > I say do what we always have done here, if the user asked us to tear
> > > something down, let it happen as they are the ones that know best :)
> > >
> > > Seriously, I guess this gets back to the "fail disconnect" idea that the
> > > ACPI developers keep harping on. I thought we already resolved this
> > > properly by having them implement it in their bus code, no reason the
> > > same thing couldn't happen here, right?
> >
> > Not really. :-) We haven't ever resolved that particular issue I'm afraid.
>
> Ah, I didn't realize that.
>
> > > I don't think the core needs to do anything special, but if so, I'll be glad
> > > to review it.
> >
> > OK, so this is the use case. We have "eject" defined for something like
> > a container with a number of CPU cores, PCI host bridge, and a memory
> > controller under it. And a few pretty much arbitrary I/O devices as a bonus.
> >
> > Now, there's a button on the system case labeled as "Eject" and if that button
> > is pressed, we're supposed to _try_ to eject all of those things at once. We
> > are allowed to fail that request, though, if that's problematic for some
> > reason, but we're supposed to let the BIOS know about that.
> >
> > Do you seriously think that if that button is pressed, we should just proceed
> > with removing all that stuff no matter what? That'd be kind of like Russian
> > roulette for whoever pressed that button, because s/he could only press it and
> > wait for the system to either crash or not. Or maybe to crash a bit later
> > because of some delayed stuff that would hit one of those devices that had just
> > gone. Surely not a situation any admin of a high-availability system would
> > like to be in. :-)
> >
> > Quite frankly, I have no idea how that can be addressed in a single bus type,
> > let alone ACPI (which is not even a proper bus type, just something pretending
> > to be one).
>
> You don't have it as a single bus type, you have a controller somewhere,
> off of the bus being destroyed, that handles sending remove events to
> the device and tearing everything down. PCI does this from the very
> beginning.
Yes, but those are just remove events and we can only see how destructive they
were after the removal. The point is to be able to figure out whether or not
we *want* to do the removal in the first place.
Say you have a computing node which signals a hardware problem in a processor
package (the container with CPU cores, memory, PCI host bridge etc.). You
may want to eject that package, but you don't want to kill the system this
way. So if the eject is doable, it is very much desirable to do it, but if it
is not doable, you'd rather shut the box down and do the replacement afterward.
That may be costly, however (maybe weeks of computations), so it should be
avoided if possible, but not at the expense of crashing the box if the eject
doesn't work out.
> I know it's more complicated with these types of devices, and I think we
> are getting closer to the correct solution, I just don't want to ever
> see duplicate devices in the driver model for the same physical device.
Do you mean two things based on struct device for the same hardware component?
That's been happening already pretty much forever for every PCI device known
to the ACPI layer, for PNP and many others. However, those ACPI things are (or
rather should be, but we're going to clean that up) only for convenience (to be
able to see the namespace structure and related things in sysfs). So the stuff
under /sys/devices/LNXSYSTM\:00/ is not "real". In my view it shouldn't even
be under /sys/devices/ (/sys/firmware/acpi/ seems to be a better place for it),
but that may be difficult to change without breaking user space (maybe we can
just symlink it from /sys/devices/ or something). And the ACPI bus type
shouldn't even exist in my opinion.
There's much confusion in there and much work to clean that up, I agree, but
that's kind of separate from the hotplug thing.
Thanks,
Rafael
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
^ permalink raw reply
* Re: [PATCH 1/1] powerpc/85xx: Board support for ppa8548
From: Timur Tabi @ 2013-02-02 20:24 UTC (permalink / raw)
To: Stef van Os; +Cc: Scott Wood, linuxppc-dev, Paul Mackerras
In-Reply-To: <510D6819.7050002@prodrive.nl>
On Sat, Feb 2, 2013 at 1:25 PM, Stef van Os <stef.van.os@prodrive.nl> wrote:
>> I guess the reason you're not using fsl/mpc8548si-post.dtsi is that you
>> don't want PCI. Maybe PCI and srio should be moved out of that file, or
>> ifdeffed if 85xx ever ends up using the preprocessor for its device trees.
>>
> I went with timur's solution, patch v2 uses mpc8548si-post.dtsi and
> mpc8548si-pre.dtsi again, disabling everything that is not on the board.
FYI, someone posted some patches for dtc a couple months ago that
added an option to strip out disabled nodes when compiling the dts,
but those patches were rejected. In your case, those patches could
significantly reduce the size of the compiled dtb.
^ permalink raw reply
* Re: [PATCH v3 00/22] PCI: Iterate pci host bridge instead of pci root bus
From: Bjorn Helgaas @ 2013-02-02 21:50 UTC (permalink / raw)
To: Yinghai Lu
Cc: linux-ia64, Mauro Carvalho Chehab, David Airlie, linux-pci,
dri-devel, David Howells, Paul Mackerras, sparclinux,
linux-am33-list, Russell King, x86, linux-altix, Doug Thompson,
Matt Turner, linux-edac, Fenghua Yu, Jiang Liu,
microblaze-uclinux, Rafael J. Wysocki, Ivan Kokshaysky,
Taku Izumi, linux-arm-kernel, Richard Henderson, Michal Simek,
Tony Luck, Toshi Kani, Greg Kroah-Hartman, linux-alpha,
Koichi Yasutake, linuxppc-dev, David S. Miller
In-Reply-To: <1359314629-18651-1-git-send-email-yinghai@kernel.org>
On Sun, Jan 27, 2013 at 12:23 PM, Yinghai Lu <yinghai@kernel.org> wrote:
> Now we have pci_root_buses list, and there is lots of iteration with
> list_of_each of it, that is not safe after we add pci root bus hotplug
> support after booting stage.
>
> Add pci_get_next_host_bridge and use bus_find_device in driver core to
> iterate host bridge and the same time get root bus.
>
> We replace searching root bus with searching host_bridge,
> as host_bridge->bus is the root bus.
> After those replacing, we even could kill pci_root_buses list.
These are the problems I think you're fixing:
1) pci_find_next_bus() is not safe because even though it holds
pci_bus_sem while walking the pci_root_buses list, it doesn't hold a
reference on the bus it returns. The bus could be removed while the
caller is using it.
2) "list_for_each_entry(bus, &pci_root_buses, node)" is not safe
because hotplug might modify the pci_root_buses list. Replacing that
with for_each_pci_host_bridge() solves that problem by using
bus_find_device(), which is built on klists, which are designed for
that problem.
3) pci_find_next_bus() claims to iterate through all known PCI buses,
but in fact only iterates through root buses.
So far, so good. Those are problems we need to fix.
Your solution is to introduce for_each_pci_host_bridge() as an
iterator through the known host bridges. There are two scenarios
where we use something like this:
1) We want to perform an operation on every known host bridge.
2) We want to initialize something for every host bridge.
In my opinion, the only instance of scenario 1) is bus_rescan_store(),
where we want to rescan all PCI host bridges.
In every other case, we're doing some kind of initialization of all
the host bridges. For these cases, for_each_pci_host_bridge() is the
wrong solution because it doesn't work for hot-added bridges. I think
these cases should be changed to use pcibios_root_bridge_prepare() or
something something else called in the host bridge add path.
Bjorn
^ permalink raw reply
* [PATCH?] Move ACPI device nodes under /sys/firmware/acpi (was: Re: [RFC PATCH v2 01/12] Add sys_hotplug.h for system device hotplug framework)
From: Rafael J. Wysocki @ 2013-02-02 22:18 UTC (permalink / raw)
To: Greg KH
Cc: linux-s390, Toshi Kani, jiang.liu, wency, linux-acpi, yinghai,
linux-kernel, linux-mm, isimatu.yasuaki, srivatsa.bhat, guohanjun,
bhelgaas, akpm, linuxppc-dev, lenb
In-Reply-To: <1810611.i6Sc4oLaux@vostro.rjw.lan>
On Saturday, February 02, 2013 09:15:37 PM Rafael J. Wysocki wrote:
> On Saturday, February 02, 2013 03:58:01 PM Greg KH wrote:
[...]
>
> > I know it's more complicated with these types of devices, and I think we
> > are getting closer to the correct solution, I just don't want to ever
> > see duplicate devices in the driver model for the same physical device.
>
> Do you mean two things based on struct device for the same hardware component?
> That's been happening already pretty much forever for every PCI device known
> to the ACPI layer, for PNP and many others. However, those ACPI things are (or
> rather should be, but we're going to clean that up) only for convenience (to be
> able to see the namespace structure and related things in sysfs). So the stuff
> under /sys/devices/LNXSYSTM\:00/ is not "real". In my view it shouldn't even
> be under /sys/devices/ (/sys/firmware/acpi/ seems to be a better place for it),
> but that may be difficult to change without breaking user space (maybe we can
> just symlink it from /sys/devices/ or something). And the ACPI bus type
> shouldn't even exist in my opinion.
Well, well.
In fact, the appended patch moves the whole ACPI device nodes tree under
/sys/firmware/acpi/ and I'm not seeing any negative consequences of that on my
test box (events work and so on). User space is quite new on it, though, and
the patch is hackish.
Still ...
---
Prototype, no sign-off
---
drivers/acpi/scan.c | 2 ++
1 file changed, 2 insertions(+)
Index: linux-pm/drivers/acpi/scan.c
===================================================================
--- linux-pm.orig/drivers/acpi/scan.c
+++ linux-pm/drivers/acpi/scan.c
@@ -1443,6 +1443,8 @@ void acpi_init_device_object(struct acpi
device->flags.match_driver = false;
device_initialize(&device->dev);
dev_set_uevent_suppress(&device->dev, true);
+ if (handle == ACPI_ROOT_OBJECT)
+ device->dev.kobj.parent = acpi_kobj;
}
void acpi_device_add_finalize(struct acpi_device *device)
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
^ permalink raw reply
* [PATCH v2 1/1] powerpc/85xx: Board support for ppa8548
From: Stef van Os @ 2013-02-03 19:39 UTC (permalink / raw)
To: Kumar Gala, linuxppc-dev
Cc: Scott Wood, Paul Mackerras, Timur Tabi, Stef van Os
Initial board support for the Prodrive PPA8548 AMC module. Board
is an MPC8548 AMC platform used in RapidIO systems. This module is
also used to test/work on mainline linux RapidIO software.
PPA8548 overview:
- 1.3 GHz Freescale PowerQUICC III MPC8548 processor
- 1 GB DDR2 @ 266 MHz
- 8 MB NOR flash
- Serial RapidIO 1.2
- 1 x 10/100/1000 BASE-T front ethernet
- 1 x 1000 BASE-BX ethernet on AMC connector
Signed-off-by: Stef van Os <stef.van.os@prodrive.nl>
---
arch/powerpc/boot/dts/ppa8548.dts | 163 +++++++++++++++++++++++++++
arch/powerpc/configs/85xx/ppa8548_defconfig | 65 +++++++++++
arch/powerpc/platforms/85xx/Kconfig | 7 +
arch/powerpc/platforms/85xx/Makefile | 1 +
arch/powerpc/platforms/85xx/ppa8548.c | 98 ++++++++++++++++
5 files changed, 334 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/boot/dts/ppa8548.dts
create mode 100644 arch/powerpc/configs/85xx/ppa8548_defconfig
create mode 100644 arch/powerpc/platforms/85xx/ppa8548.c
diff --git a/arch/powerpc/boot/dts/ppa8548.dts b/arch/powerpc/boot/dts/ppa8548.dts
new file mode 100644
index 0000000..b5f5220
--- /dev/null
+++ b/arch/powerpc/boot/dts/ppa8548.dts
@@ -0,0 +1,163 @@
+/*
+ * PPA8548 Device Tree Source (36-bit address map)
+ * Copyright 2013 Prodrive B.V.
+ *
+ * Based on:
+ * MPC8548 CDS Device Tree Source (36-bit address map)
+ * Copyright 2012 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/mpc8548si-pre.dtsi"
+
+/ {
+ model = "ppa8548";
+ compatible = "ppa8548";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ interrupt-parent = <&mpic>;
+
+ memory {
+ device_type = "memory";
+ reg = <0 0 0x0 0x40000000>;
+ };
+
+ lbc: localbus@fe0005000 {
+ reg = <0xf 0xe0005000 0 0x1000>;
+ ranges = <0x0 0x0 0xf 0xff800000 0x00800000>;
+ };
+
+ soc: soc8548@fe0000000 {
+ ranges = <0 0xf 0xe0000000 0x100000>;
+ };
+
+ pci0: pci@fe0008000 {
+ status = "disabled";
+ };
+
+ pci1: pci@fe0009000 {
+ status = "disabled";
+ };
+
+ pci2: pcie@fe000a000 {
+ status = "disabled";
+ };
+
+ rio: rapidio@fe00c0000 {
+ reg = <0xf 0xe00c0000 0x0 0x11000>;
+ port1 {
+ ranges = <0x0 0x0 0x0 0x80000000 0x0 0x40000000>;
+ };
+ };
+};
+
+&lbc {
+ nor@0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "cfi-flash";
+ reg = <0x0 0x0 0x00800000>;
+ bank-width = <2>;
+ device-width = <2>;
+
+ partition@0 {
+ reg = <0x0 0x7A0000>;
+ label = "user";
+ };
+
+ partition@7A0000 {
+ reg = <0x7A0000 0x20000>;
+ label = "env";
+ read-only;
+ };
+
+ partition@7C0000 {
+ reg = <0x7C0000 0x40000>;
+ label = "u-boot";
+ read-only;
+ };
+ };
+};
+
+&soc {
+ i2c@3000 {
+ rtc@6f {
+ compatible = "intersil,isl1208";
+ reg = <0x6f>;
+ };
+ };
+
+ i2c@3100 {
+ };
+
+ /*
+ * Only ethernet controller @25000 and @26000 are used.
+ * Use alias enet2 and enet3 for the remainig controllers,
+ * to stay compatible with mpc8548si-pre.dtsi.
+ */
+ enet2: ethernet@24000 {
+ status = "disabled";
+ };
+
+ mdio@24520 {
+ phy0: ethernet-phy@0 {
+ interrupts = <7 1 0 0>;
+ reg = <0x0>;
+ device_type = "ethernet-phy";
+ };
+ phy1: ethernet-phy@1 {
+ interrupts = <8 1 0 0>;
+ reg = <0x1>;
+ device_type = "ethernet-phy";
+ };
+ tbi0: tbi-phy@11 {
+ reg = <0x11>;
+ device_type = "tbi-phy";
+ };
+ };
+
+ enet0: ethernet@25000 {
+ tbi-handle = <&tbi1>;
+ phy-handle = <&phy0>;
+ };
+
+ mdio@25520 {
+ tbi1: tbi-phy@11 {
+ reg = <0x11>;
+ device_type = "tbi-phy";
+ };
+ };
+
+ enet1: ethernet@26000 {
+ tbi-handle = <&tbi2>;
+ phy-handle = <&phy1>;
+ };
+
+ mdio@26520 {
+ tbi2: tbi-phy@11 {
+ reg = <0x11>;
+ device_type = "tbi-phy";
+ };
+ };
+
+ enet3: ethernet@27000 {
+ status = "disabled";
+ };
+
+ mdio@27520 {
+ tbi3: tbi-phy@11 {
+ reg = <0x11>;
+ device_type = "tbi-phy";
+ };
+ };
+
+ crypto@30000 {
+ status = "disabled";
+ };
+};
+
+/include/ "fsl/mpc8548si-post.dtsi"
diff --git a/arch/powerpc/configs/85xx/ppa8548_defconfig b/arch/powerpc/configs/85xx/ppa8548_defconfig
new file mode 100644
index 0000000..a11337d
--- /dev/null
+++ b/arch/powerpc/configs/85xx/ppa8548_defconfig
@@ -0,0 +1,65 @@
+CONFIG_PPC_85xx=y
+CONFIG_PPA8548=y
+CONFIG_DTC=y
+CONFIG_DEFAULT_UIMAGE=y
+CONFIG_IKCONFIG=y
+CONFIG_IKCONFIG_PROC=y
+# CONFIG_PCI is not set
+# CONFIG_USB_SUPPORT is not set
+CONFIG_ADVANCED_OPTIONS=y
+CONFIG_LOWMEM_SIZE_BOOL=y
+CONFIG_LOWMEM_SIZE=0x40000000
+CONFIG_LOWMEM_CAM_NUM_BOOL=y
+CONFIG_LOWMEM_CAM_NUM=4
+CONFIG_PAGE_OFFSET_BOOL=y
+CONFIG_PAGE_OFFSET=0xb0000000
+CONFIG_KERNEL_START_BOOL=y
+CONFIG_KERNEL_START=0xb0000000
+# CONFIG_PHYSICAL_START_BOOL is not set
+CONFIG_PHYSICAL_START=0x00000000
+CONFIG_PHYSICAL_ALIGN=0x04000000
+CONFIG_TASK_SIZE_BOOL=y
+CONFIG_TASK_SIZE=0xb0000000
+
+CONFIG_FSL_LBC=y
+CONFIG_FSL_DMA=y
+CONFIG_FSL_RIO=y
+
+CONFIG_RAPIDIO=y
+CONFIG_RAPIDIO_DMA_ENGINE=y
+CONFIG_RAPIDIO_TSI57X=y
+CONFIG_RAPIDIO_TSI568=y
+CONFIG_RAPIDIO_CPS_XX=y
+CONFIG_RAPIDIO_CPS_GEN2=y
+CONFIG_SERIAL_8250=y
+CONFIG_SERIAL_8250_CONSOLE=y
+CONFIG_PROC_DEVICETREE=y
+
+CONFIG_MTD=y
+CONFIG_MTD_BLKDEVS=y
+CONFIG_MTD_BLOCK=y
+CONFIG_MTD_CFI=y
+CONFIG_MTD_CFI_AMDSTD=y
+CONFIG_MTD_CFI_INTELEXT=y
+CONFIG_MTD_CHAR=y
+CONFIG_MTD_CMDLINE_PARTS=y
+CONFIG_MTD_CONCAT=y
+CONFIG_MTD_PARTITIONS=y
+CONFIG_MTD_PHYSMAP_OF=y
+
+CONFIG_I2C=y
+CONFIG_I2C_MPC=y
+CONFIG_I2C_CHARDEV
+CONFIG_RTC_CLASS=y
+CONFIG_RTC_HCTOSYS=y
+CONFIG_RTC_DRV_ISL1208=y
+
+CONFIG_NET=y
+CONFIG_INET=y
+CONFIG_IP_PNP=y
+CONFIG_NETDEVICES=y
+CONFIG_MII=y
+CONFIG_GIANFAR=y
+CONFIG_MARVELL_PHY=y
+CONFIG_NFS_FS=y
+CONFIG_ROOT_NFS=y
diff --git a/arch/powerpc/platforms/85xx/Kconfig b/arch/powerpc/platforms/85xx/Kconfig
index 02d02a0..803bfed 100644
--- a/arch/powerpc/platforms/85xx/Kconfig
+++ b/arch/powerpc/platforms/85xx/Kconfig
@@ -191,6 +191,13 @@ config SBC8548
help
This option enables support for the Wind River SBC8548 board
+config PPA8548
+ bool "Prodrive PPA8548"
+ help
+ This option enables support for the Prodrive PPA8548 board.
+ select DEFAULT_UIMAGE
+ select HAS_RAPIDIO
+
config GE_IMP3A
bool "GE Intelligent Platforms IMP3A"
select DEFAULT_UIMAGE
diff --git a/arch/powerpc/platforms/85xx/Makefile b/arch/powerpc/platforms/85xx/Makefile
index 76f679c..d5f4195 100644
--- a/arch/powerpc/platforms/85xx/Makefile
+++ b/arch/powerpc/platforms/85xx/Makefile
@@ -25,6 +25,7 @@ obj-$(CONFIG_P5040_DS) += p5040_ds.o corenet_ds.o
obj-$(CONFIG_STX_GP3) += stx_gp3.o
obj-$(CONFIG_TQM85xx) += tqm85xx.o
obj-$(CONFIG_SBC8548) += sbc8548.o
+obj-$(CONFIG_PPA8548) += ppa8548.o
obj-$(CONFIG_SOCRATES) += socrates.o socrates_fpga_pic.o
obj-$(CONFIG_KSI8560) += ksi8560.o
obj-$(CONFIG_XES_MPC85xx) += xes_mpc85xx.o
diff --git a/arch/powerpc/platforms/85xx/ppa8548.c b/arch/powerpc/platforms/85xx/ppa8548.c
new file mode 100644
index 0000000..af7bf1a
--- /dev/null
+++ b/arch/powerpc/platforms/85xx/ppa8548.c
@@ -0,0 +1,98 @@
+/*
+ * ppa8548 setup and early boot code.
+ *
+ * Copyright 2009 Prodrive B.V..
+ *
+ * By Stef van Os (see MAINTAINERS for contact information)
+ *
+ * Based on the SBC8548 support - Copyright 2007 Wind River Systems Inc.
+ * Based on the MPC8548CDS support - Copyright 2005 Freescale 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 <linux/stddef.h>
+#include <linux/kernel.h>
+#include <linux/init.h>
+#include <linux/reboot.h>
+#include <linux/seq_file.h>
+#include <linux/of_platform.h>
+
+#include <asm/machdep.h>
+#include <asm/udbg.h>
+#include <asm/mpic.h>
+
+#include <sysdev/fsl_soc.h>
+
+static void __init ppa8548_pic_init(void)
+{
+ struct mpic *mpic = mpic_alloc(NULL, 0, MPIC_BIG_ENDIAN,
+ 0, 256, " OpenPIC ");
+ BUG_ON(mpic == NULL);
+ mpic_init(mpic);
+}
+
+/*
+ * Setup the architecture
+ */
+static void __init ppa8548_setup_arch(void)
+{
+ if (ppc_md.progress)
+ ppc_md.progress("ppa8548_setup_arch()", 0);
+}
+
+static void ppa8548_show_cpuinfo(struct seq_file *m)
+{
+ uint svid, phid1;
+
+ svid = mfspr(SPRN_SVR);
+
+ seq_printf(m, "Vendor\t\t: Prodrive B.V.\n");
+ seq_printf(m, "SVR\t\t: 0x%x\n", svid);
+
+ /* Display cpu Pll setting */
+ phid1 = mfspr(SPRN_HID1);
+ seq_printf(m, "PLL setting\t: 0x%x\n", ((phid1 >> 24) & 0x3f));
+}
+
+static struct of_device_id __initdata of_bus_ids[] = {
+ { .name = "soc", },
+ { .type = "soc", },
+ { .compatible = "simple-bus", },
+ { .compatible = "gianfar", },
+ { .compatible = "fsl,srio", },
+ {},
+};
+
+static int __init declare_of_platform_devices(void)
+{
+ of_platform_bus_probe(NULL, of_bus_ids, NULL);
+
+ return 0;
+}
+machine_device_initcall(ppa8548, declare_of_platform_devices);
+
+/*
+ * Called very early, device-tree isn't unflattened
+ */
+static int __init ppa8548_probe(void)
+{
+ unsigned long root = of_get_flat_dt_root();
+
+ return of_flat_dt_is_compatible(root, "ppa8548");
+}
+
+define_machine(ppa8548) {
+ .name = "ppa8548",
+ .probe = ppa8548_probe,
+ .setup_arch = ppa8548_setup_arch,
+ .init_IRQ = ppa8548_pic_init,
+ .show_cpuinfo = ppa8548_show_cpuinfo,
+ .get_irq = mpic_get_irq,
+ .restart = fsl_rstcr_restart,
+ .calibrate_decr = generic_calibrate_decr,
+ .progress = udbg_progress,
+};
--
1.7.2.5
^ 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