Re: [PATCH 5/5] kernel handling of CPU DLPAR
On 254, 09 11, 2009 at 04:15:33PM -0500, Nathan Fontenot wrote:
This adds the capability to DLPAR add and remove CPUs from the kernel. The
creates two new files /sys/devices/system/cpu/probe and
/sys/devices/system/cpu/release to handle the DLPAR addition and
removal of
CPUs respectively.
CPU DLPAR add is accomplished by writing the drc-index of the CPU to the
probe file, and removal is done by writing the device-tree path of the cpu
to the release file.
Signed-off-by: Nathan Fontenot nf...@austin.ibm.com
+static ssize_t cpu_probe_store(struct class *class, const char *buf,
+size_t count)
+{
+ struct device_node *dn;
+ u32 drc_index;
+ char *cpu_name;
+ int rc;
+
+ drc_index = simple_strtoull(buf, NULL, 0);
+ if (!drc_index)
+ return -EINVAL;
+
+ rc = acquire_drc(drc_index);
+ if (rc)
+ return rc;
+
+ dn = configure_connector(drc_index);
+ if (!dn) {
+ release_drc(drc_index);
+ return rc;
+ }
+
+ /* fixup dn name */
+ cpu_name = kzalloc(strlen(dn-full_name) + strlen(/cpus/) + 1,
+GFP_KERNEL);
Unchecked memory allocation with immediate crash in case of failure.
+ sprintf(cpu_name, /cpus/%s, dn-full_name);
+ kfree(dn-full_name);
+ dn-full_name = cpu_name;
+
+ rc = add_device_tree_nodes(dn);
+ if (rc)
+ release_drc(drc_index);
+
+ return rc ? rc : count;
+}
+
+static ssize_t cpu_release_store(struct class *class, const char *buf,
+ size_t count)
+{
+ struct device_node *dn;
+ u32 *drc_index;
+ int rc;
+
+ dn = of_find_node_by_path(buf);
+ if (!dn)
+ return -EINVAL;
+
+ drc_index = (u32 *)of_get_property(dn, ibm,my-drc-index, NULL);
+ if (!drc_index) {
+ of_node_put(dn);
+ return -EINVAL;
+ }
+
+ rc = release_drc(*drc_index);
+ if (rc) {
+ of_node_put(dn);
+ return rc;
+ }
+
+ rc = remove_device_tree_nodes(dn);
+ if (rc)
+ acquire_drc(*drc_index);
+
+ of_node_put(dn);
+ return rc? rc : count;
+}
+
static struct class_attribute class_attr_mem_release =
__ATTR(release, S_IWUSR, NULL, memory_release_store);
+static struct class_attribute class_attr_cpu_probe =
+ __ATTR(probe, S_IWUSR, NULL, cpu_probe_store);
+static struct class_attribute class_attr_cpu_release =
+ __ATTR(release, S_IWUSR, NULL, cpu_release_store);
static int pseries_dlpar_init(void)
{
@@ -576,6 +648,18 @@
printk(KERN_INFO DLPAR: Could not create sysfs memory
release file\n);
+ rc = sysfs_create_file(cpu_sysdev_class.kset.kobj,
+class_attr_cpu_probe.attr);
+ if (rc)
+ printk(KERN_INFO DLPAR: Could not create sysfs cpu
+probe file\n);
+
+ rc = sysfs_create_file(cpu_sysdev_class.kset.kobj,
+class_attr_cpu_release.attr);
+ if (rc)
+ printk(KERN_INFO DLPAR: Could not create sysfs cpu
+release file\n);
+
return 0;
}
__initcall(pseries_dlpar_init);
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 4/5] kernel handling of memory DLPAR
On 254, 09 11, 2009 at 04:14:35PM -0500, Nathan Fontenot wrote:
This adds the capability to DLPAR add and remove memory from the kernel. The
patch extends the powerpc handling of memory_add_physaddr_to_nid(), which is
called from the sysfs memory 'probe' file to first ensure that the memory
has been added to the system. This is done by creating a platform specific
callout from the routine. The pseries implementation of this handles the
DLPAR work to add the memory to the system and update the device tree.
The patch also creates a pseries only 'release' sys file,
/sys/devices/system/memory/release. This file handles the DLPAR
release of
memory back to firmware and updating of the device-tree.
Signed-off-by: Nathan Fontenot nf...@austin.ibm.com
+static struct property *clone_property(struct property *old_prop)
+{
+ struct property *new_prop;
+
+ new_prop = kzalloc((sizeof *new_prop), GFP_KERNEL);
+ if (!new_prop)
+ return NULL;
+
+ new_prop-name = kzalloc(strlen(old_prop-name) + 1, GFP_KERNEL);
+ new_prop-value = kzalloc(old_prop-length + 1, GFP_KERNEL);
Memory leak here. What if one kzalloc() succeeded and another failed ?
+ if (!new_prop-name || !new_prop-value) {
+ free_property(new_prop);
+ return NULL;
+ }
+
+ strcpy(new_prop-name, old_prop-name);
+ memcpy(new_prop-value, old_prop-value, old_prop-length);
+ new_prop-length = old_prop-length;
+
+ return new_prop;
+}
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] mpc5200: support for the MAN mpc5200 based board mucmc52
- serial Console on PSC1
- 64MB SDRAM
- MTD CFI Flash
- Ethernet FEC
- I2C with PCF8563 and Temp. Sensor ADM9240
- IDE support
Signed-off-by: Heiko Schocher h...@denx.de
---
- based on:
git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git next
- checked with:
$ ./scripts/checkpatch.pl
0001-mpc5200-support-for-the-MAN-mpc5200-based-board-muc.patch
total: 0 errors, 0 warnings, 1714 lines checked
0001-mpc5200-support-for-the-MAN-mpc5200-based-board-muc.patch has no obvious
style problems and is ready for submission.
$
arch/powerpc/boot/dts/mucmc52.dts| 231
arch/powerpc/configs/52xx/mucmc52_defconfig | 1476 ++
arch/powerpc/platforms/52xx/mpc5200_simple.c |1 +
3 files changed, 1708 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/boot/dts/mucmc52.dts
create mode 100644 arch/powerpc/configs/52xx/mucmc52_defconfig
diff --git a/arch/powerpc/boot/dts/mucmc52.dts
b/arch/powerpc/boot/dts/mucmc52.dts
new file mode 100644
index 000..a4a7a20
--- /dev/null
+++ b/arch/powerpc/boot/dts/mucmc52.dts
@@ -0,0 +1,231 @@
+/*
+ * mucmc52 board Device Tree Source
+ *
+ * Copyright (C) 2009 DENX Software Engineering GmbH
+ * Heiko Schocher h...@denx.de
+ *
+ * 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/;
+
+/ {
+ model = man,mucmc52;
+ compatible = man,mucmc52;
+ #address-cells = 1;
+ #size-cells = 1;
+ interrupt-parent = mpc5200_pic;
+
+ cpus {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ PowerPC,5...@0 {
+ device_type = cpu;
+ reg = 0;
+ d-cache-line-size = 32;
+ i-cache-line-size = 32;
+ d-cache-size = 0x4000;// L1, 16K
+ i-cache-size = 0x4000;// L1, 16K
+ timebase-frequency = 0; // from bootloader
+ bus-frequency = 0;// from bootloader
+ clock-frequency = 0; // from bootloader
+ };
+ };
+
+ memory {
+ device_type = memory;
+ reg = 0x 0x0400; // 64MB
+ };
+
+ soc5...@f000 {
+ #address-cells = 1;
+ #size-cells = 1;
+ compatible = fsl,mpc5200-immr;
+ ranges = 0 0xf000 0xc000;
+ reg = 0xf000 0x0100;
+ bus-frequency = 0;// from bootloader
+ system-frequency = 0; // from bootloader
+
+ c...@200 {
+ compatible = fsl,mpc5200-cdm;
+ reg = 0x200 0x38;
+ };
+
+ mpc5200_pic: interrupt-control...@500 {
+ // 5200 interrupts are encoded into two levels;
+ interrupt-controller;
+ #interrupt-cells = 3;
+ compatible = fsl,mpc5200-pic;
+ reg = 0x500 0x80;
+ };
+
+ ti...@600 { // General Purpose Timer
+ compatible = fsl,mpc5200-gpt;
+ reg = 0x600 0x10;
+ interrupts = 1 9 0;
+ gpio-controller;
+ };
+
+ gpio_simple: g...@b00 {
+ compatible = fsl,mpc5200-gpio;
+ reg = 0xb00 0x40;
+ interrupts = 1 7 0;
+ gpio-controller;
+ #gpio-cells = 2;
+ };
+
+ dma-control...@1200 {
+ device_type = dma-controller;
+ compatible = fsl,mpc5200-bestcomm;
+ reg = 0x1200 0x80;
+ interrupts = 3 0 0 3 1 0 3 2 0 3 3 0
+ 3 4 0 3 5 0 3 6 0 3 7 0
+ 3 8 0 3 9 0 3 10 0 3 11 0
+ 3 12 0 3 13 0 3 14 0 3 15 0;
+ };
+
+ x...@1f00 {
+ compatible = fsl,mpc5200-xlb;
+ reg = 0x1f00 0x100;
+ };
+
+ ser...@2000 { // PSC1
+ compatible = fsl,mpc5200-psc-uart;
+ reg = 0x2000 0x100;
+ interrupts = 2 1 0;
+ };
+
+ ser...@2200 { // PSC2
+ compatible = fsl,mpc5200-psc-uart;
+ reg = 0x2200 0x100;
+ interrupts = 2 2 0;
+ };
+
+ ser...@2c00 { // PSC6
+
[PATCH] mpc5200: support for the MAN mpc5200 based board uc101
- serial Console on PSC1
- 64MB SDRAM
- MTD CFI Flash
- Ethernet FEC
- I2C with PCF8563 and Temp. Sensor ADM9240
- IDE support
Signed-off-by: Heiko Schocher h...@denx.de
---
- based on:
git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git next
- checked with:
$ ./scripts/checkpatch.pl
0001-mpc5200-support-for-the-MAN-mpc5200-based-board-uc1.patch
total: 0 errors, 0 warnings, 1622 lines checked
0001-mpc5200-support-for-the-MAN-mpc5200-based-board-uc1.patch has no obvious
style problems and is ready for submission.
$
arch/powerpc/boot/dts/uc101.dts | 312 ++
arch/powerpc/configs/52xx/uc101_defconfig| 1303 ++
arch/powerpc/platforms/52xx/mpc5200_simple.c |1 +
3 files changed, 1616 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/boot/dts/uc101.dts
create mode 100644 arch/powerpc/configs/52xx/uc101_defconfig
diff --git a/arch/powerpc/boot/dts/uc101.dts b/arch/powerpc/boot/dts/uc101.dts
new file mode 100644
index 000..28e1c90
--- /dev/null
+++ b/arch/powerpc/boot/dts/uc101.dts
@@ -0,0 +1,312 @@
+/*
+ * uc101 board Device Tree Source
+ *
+ * Copyright (C) 2009 DENX Software Engineering GmbH
+ * Heiko Schocher h...@denx.de
+ *
+ * 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/;
+
+/ {
+ model = man,uc101;
+ compatible = man,uc101;
+ #address-cells = 1;
+ #size-cells = 1;
+ interrupt-parent = mpc5200_pic;
+
+ cpus {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ PowerPC,5...@0 {
+ device_type = cpu;
+ reg = 0;
+ d-cache-line-size = 32;
+ i-cache-line-size = 32;
+ d-cache-size = 0x4000;// L1, 16K
+ i-cache-size = 0x4000;// L1, 16K
+ timebase-frequency = 0; // from bootloader
+ bus-frequency = 0;// from bootloader
+ clock-frequency = 0; // from bootloader
+ };
+ };
+
+ memory {
+ device_type = memory;
+ reg = 0x 0x0400; // 64MB
+ };
+
+ soc5...@f000 {
+ #address-cells = 1;
+ #size-cells = 1;
+ compatible = fsl,mpc5200-immr;
+ ranges = 0 0xf000 0xc000;
+ reg = 0xf000 0x0100;
+ bus-frequency = 0;// from bootloader
+ system-frequency = 0; // from bootloader
+
+ c...@200 {
+ compatible = fsl,mpc5200-cdm;
+ reg = 0x200 0x38;
+ };
+
+ mpc5200_pic: interrupt-control...@500 {
+ // 5200 interrupts are encoded into two levels;
+ interrupt-controller;
+ #interrupt-cells = 3;
+ compatible = fsl,mpc5200-pic;
+ reg = 0x500 0x80;
+ interrupts = 0 0 3;
+ };
+
+ gpt1: ti...@610 { // General Purpose Timer 1 in GPIO mode
+ compatible =
fsl,mpc5200b-gpt-gpio,fsl,mpc5200-gpt-gpio;
+ reg = 0x610 0x10;
+ interrupts = 1 10 0;
+ gpio-controller;
+ };
+
+ gpt2: ti...@620 { // General Purpose Timer 2 in GPIO mode
+ compatible =
fsl,mpc5200b-gpt-gpio,fsl,mpc5200-gpt-gpio;
+ reg = 0x620 0x10;
+ interrupts = 1 11 0;
+ gpio-controller;
+ };
+
+ gpt3: ti...@630 { // General Purpose Timer 3 in GPIO mode
+ compatible =
fsl,mpc5200b-gpt-gpio,fsl,mpc5200-gpt-gpio;
+ reg = 0x630 0x10;
+ interrupts = 1 12 0;
+ gpio-controller;
+ #gpio-cells = 2;
+ };
+
+ gpio_simple: g...@b00 {
+ compatible = fsl,mpc5200-gpio;
+ reg = 0xb00 0x40;
+ interrupts = 1 7 0;
+ gpio-controller;
+ #gpio-cells = 2;
+ };
+
+ gpio_wkup: g...@c00 {
+ compatible = fsl,mpc5200-gpio-wkup;
+ reg = 0xc00 0x40;
+ interrupts = 1 8 0 0 3 0;
+ gpio-controller;
+ #gpio-cells = 2;
+ };
+
+ dma-control...@1200 {
+ device_type =
Re: [FTRACE] Enabling function_graph causes OOPS
On Mon, 2009-09-14 at 06:25 +1000, Benjamin Herrenschmidt wrote: .../... Something is totally messed up here. Could it be that we don't handle R_PPC64_ADDR16_* relocs in arch/powerpc/kernel/modules/module_64.c ? Sachin, do you see a bunch of Unknown ADD relocation in your dmesg ? Ben, The thing is, this is kernel proper. This code is in entry_64.S not in the module code. Argh... indeed. Sachin, can you give me more details on how you built that kernel ? (or give them again in case I missed them the first time around :-), ie, what toolchain, options, etc... or even better, give me remote access to the build host ? Ok, got access and had a quick look... seems to be a toolchain problem to me. I'll investigate more tomorrow. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] mpc5200: support for the MAN mpc5200 based board mucmc52
Hi,
+ mpc5200_pic: interrupt-control...@500 {
+ // 5200 interrupts are encoded into two levels;
Grant, maybe this comment could be dropped also for the in-kernel dts-files? I
think it is sufficently described in mpc5200.txt. I could prepare a patch if
you agree.
+ i...@3d40 {
+ #address-cells = 1;
+ #size-cells = 0;
+ compatible = fsl,mpc5200-i2c,fsl-i2c;
+ reg = 0x3d40 0x40;
+ interrupts = 2 16 0;
+ fsl5200-clocking;
Please drop the clocking-line. It became obsolete.
Regards,
Wolfram
--
Pengutronix e.K. | Wolfram Sang|
Industrial Linux Solutions | http://www.pengutronix.de/ |
signature.asc
Description: Digital signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Oops in IDE probing on ppc_440 when PCI is enabled in strapping
Hi, we're working with a PPC440GX on a board that has a.o. a compact flash slot. We had the PCI subsystem of the ppc disabled in strapping for quite a while, until we wanted to start using it. However, when we enabled PCI in the strapping and in the (patched 2.6.10) kernel configuration, we triggered an oops when probing for IDE devices (to read out the first 512 bytes of the CF). I can see that the ioremap64 call in the driver code for our CF returns a different address (compared to PCI disabled in strapping), but using this address later on for accessing the CF goes wrong. Does someone has an idea why this might go wrong? Can I end up with overlapping address ranges due to the PCI subsystem being enabled? Is this easy to check? As far as I know, the HW address of the PCI controller is in a non-overlapping range with the addresses we have setup in the EBC registers to probe for the CF (u-boot can see the IDE device just fine and it also has PCI turned on). TIA, Ludo ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Oops in IDE probing on ppc_440 when PCI is enabled in strapping
On Mon, Sep 14, 2009 at 02:36:15PM +0200, Ludo Van Put wrote: Hi, we're working with a PPC440GX on a board that has a.o. a compact flash slot. We had the PCI subsystem of the ppc disabled in strapping for quite a while, until we wanted to start using it. However, when we enabled PCI in the strapping and in the (patched 2.6.10) 2.6.10? Really? If that is truly the case, you probably aren't going to get a whole lot of help from the list, since that kernel is pretty ancient. kernel configuration, we triggered an oops when probing for IDE devices (to read out the first 512 bytes of the CF). I can see that the ioremap64 call in the driver code for our CF returns a different address (compared to PCI disabled in strapping), but using this address later on for accessing the CF goes wrong. Posting the oops output would perhaps help. Or maybe not. josh ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: How to access DCR registers in powerpc440gx? Got err when use macro def in Linux kernel
On Friday 11 September 2009, David Gibson wrote: On Fri, Sep 11, 2009 at 12:14:55PM +0800, g r1x wrote: Now, I'm writing a DMA driver on powerpc 440gx platform(2.6.26.5), as the only way to set up DMA Controller is to access it's dcr registers with 'mfdcr' and 'mtdcr'. I've found some dma code in Linux kernel 2.6.26.5, so I copy the code u wrote to my driver module directory, and include them, but when I compile my driver, gcc complains following err messages: In current kernels we have some DCR macros that use a big table of pre-generated instructions in order to allow accesses to runtime computed DCR numbers. But either they didn't exist in 2.6.26, or they have a different name, I don't remember. The portable way to access DCRs is the API from asm/dcr.h, using dcr_map(), dcr_read() and dcr_write(). Arnd ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Oops in IDE probing on ppc_440 when PCI is enabled in strapping
2009/9/14 Josh Boyer jwbo...@linux.vnet.ibm.com: On Mon, Sep 14, 2009 at 02:36:15PM +0200, Ludo Van Put wrote: Hi, we're working with a PPC440GX on a board that has a.o. a compact flash slot. We had the PCI subsystem of the ppc disabled in strapping for quite a while, until we wanted to start using it. However, when we enabled PCI in the strapping and in the (patched 2.6.10) 2.6.10? Really? If that is truly the case, you probably aren't going to get a whole lot of help from the list, since that kernel is pretty ancient. I can only acknowledge that, but we're stuck to that kernel for now... kernel configuration, we triggered an oops when probing for IDE devices (to read out the first 512 bytes of the CF). I can see that the ioremap64 call in the driver code for our CF returns a different address (compared to PCI disabled in strapping), but using this address later on for accessing the CF goes wrong. Posting the oops output would perhaps help. Or maybe not. josh Here it goes, you never know: Oops: kernel access of bad area, sig: 11 [#1] PREEMPT NIP: C0148050 LR: C013BC64 SP: C07CFEA0 REGS: c07cfdf0 TRAP: 0300Not tainted MSR: 00021000 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 00 DAR: E3093000, DSISR: TASK = c07cdb70[1] 'swapper' THREAD: c07ce000 Last syscall: 120 GPR00: C07CFEA0 C07CDB70 E3093000 DFE829FE 0100 C01184E8 C021B270 GPR08: C022 C02D0F60 C07CDEF8 C07CDEF8 7000 1FFF6400 0001 GPR16: 0001 1FFF06C0 0001 C022 C028 00029000 GPR24: C02D0F60 C01F C0148040 0080 DFE82A00 C02D0FF0 NIP [c0148050] ide_insw+0x10/0x24 LR [c013bc64] ata_input_data+0x74/0x114 Call backtrace: c013e6a4 try_to_identify+0x2ec/0x5ec c013eaa8 do_probe+0x104/0x304 c013f0c4 probe_hwif+0x358/0x6c4 c0140068 ideprobe_init+0xa8/0x1a0 c02a4ef8 ide_generic_init+0x10/0x28 c0001324 init+0xc4/0x244 c0004254 kernel_thread+0x44/0x60 Kernel panic - not syncing: Attempted to kill init! 0Rebooting in 180 seconds.. ide_insw is a asm routine to read in 16bit words and swap them. Copied from arch/ppc/kernel/misc.S. Works fine when PCI is disabled. KR, Ludo ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
MPC8323 USB Host
Hello, This is regarding the MPC8323 in-built USB controller driver, Environment: LTIB: ltib-mpc832x_rdb-20070507 Linux: linux-2.6.20 In built usb driver is been ported from linux-2.6.30 to linux-2.6.20 (File: drivers/usb/host/fhci-hcd.c is been ported from kernel.org/linux-2.6.30) Problem description: File: drivers/usb/host/fhci-hcd.c In this file probe function: of_fhci_probe(struct of_device *ofdev, const struct of_device_id *ofid) is getting loaded successfully FHCI Host Controller, interrupt and timer are getting registered File:drivers/usb/host/fhci-hub.c In this file function fhci_hub_status_data(struct usb_hcd *hcd, char *buf) is been polled continuosly, which is checking for the port change and port status of the our virtual hub using fhci-vroot_hub-port.wPortChange fhci-vroot_hub-port.wPortStatus The value in this variable are not getting changed even after connecting disconnection the device. We have manual checked the USBRXP pin, this pin is HIGH = when device is connected LOW = when device is not connected. Kindly let us know how should we debug/proceed. Thanks and regards, Krishna kumar M.S Arif -- View this message in context: http://www.nabble.com/MPC8323-USB-Host-tp25435195p25435195.html Sent from the linuxppc-dev mailing list archive at Nabble.com. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] mpc5200: support for the MAN mpc5200 based board uc101
Hi Heiko,
Thanks for the patch. Comments below.
g.
On Mon, Sep 14, 2009 at 2:05 AM, Heiko Schocher h...@denx.de wrote:
- serial Console on PSC1
- 64MB SDRAM
- MTD CFI Flash
- Ethernet FEC
- I2C with PCF8563 and Temp. Sensor ADM9240
- IDE support
Signed-off-by: Heiko Schocher h...@denx.de
---
- based on:
git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git next
- checked with:
$ ./scripts/checkpatch.pl
0001-mpc5200-support-for-the-MAN-mpc5200-based-board-uc1.patch
total: 0 errors, 0 warnings, 1622 lines checked
0001-mpc5200-support-for-the-MAN-mpc5200-based-board-uc1.patch has no obvious
style problems and is ready for submission.
$
arch/powerpc/boot/dts/uc101.dts | 312 ++
arch/powerpc/configs/52xx/uc101_defconfig | 1303
++
I generally don't like board specific defconfigs unless there is a
really compelling reason why it should be in the kernel tree. Please
add the stuff you need (as modules!) to mpc5200_defconfig.
g.
diff --git a/arch/powerpc/boot/dts/uc101.dts b/arch/powerpc/boot/dts/uc101.dts
new file mode 100644
index 000..28e1c90
--- /dev/null
+++ b/arch/powerpc/boot/dts/uc101.dts
@@ -0,0 +1,312 @@
+/*
+ * uc101 board Device Tree Source
+ *
+ * Copyright (C) 2009 DENX Software Engineering GmbH
+ * Heiko Schocher h...@denx.de
+ *
+ * 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/;
+
+/ {
+ model = man,uc101;
+ compatible = man,uc101;
+ #address-cells = 1;
+ #size-cells = 1;
+ interrupt-parent = mpc5200_pic;
+
+ cpus {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ PowerPC,5...@0 {
+ device_type = cpu;
+ reg = 0;
+ d-cache-line-size = 32;
+ i-cache-line-size = 32;
+ d-cache-size = 0x4000; // L1, 16K
+ i-cache-size = 0x4000; // L1, 16K
+ timebase-frequency = 0; // from bootloader
+ bus-frequency = 0; // from bootloader
+ clock-frequency = 0; // from bootloader
+ };
+ };
+
+ memory {
+ device_type = memory;
+ reg = 0x 0x0400; // 64MB
+ };
+
+ soc5...@f000 {
+ #address-cells = 1;
+ #size-cells = 1;
+ compatible = fsl,mpc5200-immr;
+ ranges = 0 0xf000 0xc000;
+ reg = 0xf000 0x0100;
+ bus-frequency = 0; // from bootloader
+ system-frequency = 0; // from bootloader
+
+ c...@200 {
+ compatible = fsl,mpc5200-cdm;
+ reg = 0x200 0x38;
+ };
+
+ mpc5200_pic: interrupt-control...@500 {
+ // 5200 interrupts are encoded into two levels;
+ interrupt-controller;
+ #interrupt-cells = 3;
+ compatible = fsl,mpc5200-pic;
+ reg = 0x500 0x80;
+ interrupts = 0 0 3;
+ };
+
+ gpt1: ti...@610 { // General Purpose Timer 1 in GPIO
mode
+ compatible =
fsl,mpc5200b-gpt-gpio,fsl,mpc5200-gpt-gpio;
+ reg = 0x610 0x10;
+ interrupts = 1 10 0;
+ gpio-controller;
+ };
+
+ gpt2: ti...@620 { // General Purpose Timer 2 in GPIO
mode
+ compatible =
fsl,mpc5200b-gpt-gpio,fsl,mpc5200-gpt-gpio;
+ reg = 0x620 0x10;
+ interrupts = 1 11 0;
+ gpio-controller;
+ };
+
+ gpt3: ti...@630 { // General Purpose Timer 3 in GPIO
mode
+ compatible =
fsl,mpc5200b-gpt-gpio,fsl,mpc5200-gpt-gpio;
+ reg = 0x630 0x10;
+ interrupts = 1 12 0;
+ gpio-controller;
+ #gpio-cells = 2;
+ };
+
+ gpio_simple: g...@b00 {
+ compatible = fsl,mpc5200-gpio;
+ reg = 0xb00 0x40;
+ interrupts = 1 7 0;
+ gpio-controller;
+ #gpio-cells = 2;
+ };
+
+ gpio_wkup: g...@c00 {
+ compatible = fsl,mpc5200-gpio-wkup;
+ reg = 0xc00 0x40;
+
Re: [PATCH] mpc5200: support for the MAN mpc5200 based board mucmc52
Hi Heiko.
Comments below.
On Mon, Sep 14, 2009 at 2:05 AM, Heiko Schocher h...@denx.de wrote:
- serial Console on PSC1
- 64MB SDRAM
- MTD CFI Flash
- Ethernet FEC
- I2C with PCF8563 and Temp. Sensor ADM9240
- IDE support
Signed-off-by: Heiko Schocher h...@denx.de
arch/powerpc/boot/dts/mucmc52.dts | 231
arch/powerpc/configs/52xx/mucmc52_defconfig | 1476
++
Same comment as on your other patch. Drop the defconfig and add the
needed bits to mpc5200_defconfig (in a separate patch, and add drivers
as modules).
diff --git a/arch/powerpc/boot/dts/mucmc52.dts
b/arch/powerpc/boot/dts/mucmc52.dts
new file mode 100644
index 000..a4a7a20
--- /dev/null
+++ b/arch/powerpc/boot/dts/mucmc52.dts
@@ -0,0 +1,231 @@
+/*
+ * mucmc52 board Device Tree Source
+ *
+ * Copyright (C) 2009 DENX Software Engineering GmbH
+ * Heiko Schocher h...@denx.de
+ *
+ * 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/;
+
+/ {
+ model = man,mucmc52;
+ compatible = man,mucmc52;
+ #address-cells = 1;
+ #size-cells = 1;
+ interrupt-parent = mpc5200_pic;
+
+ cpus {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ PowerPC,5...@0 {
+ device_type = cpu;
+ reg = 0;
+ d-cache-line-size = 32;
+ i-cache-line-size = 32;
+ d-cache-size = 0x4000; // L1, 16K
+ i-cache-size = 0x4000; // L1, 16K
+ timebase-frequency = 0; // from bootloader
+ bus-frequency = 0; // from bootloader
+ clock-frequency = 0; // from bootloader
+ };
+ };
+
+ memory {
+ device_type = memory;
+ reg = 0x 0x0400; // 64MB
+ };
+
+ soc5...@f000 {
+ #address-cells = 1;
+ #size-cells = 1;
+ compatible = fsl,mpc5200-immr;
Does this board use the older and rarer non-'B' mpc5200 part? If not,
then fsl,mpc5200b-immr also needs to be in this list.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] mpc5200: support for the MAN mpc5200 based board uc101
Hello Grant,
Grant Likely wrote:
Thanks for the patch. Comments below.
g.
On Mon, Sep 14, 2009 at 2:05 AM, Heiko Schocher h...@denx.de wrote:
- serial Console on PSC1
- 64MB SDRAM
- MTD CFI Flash
- Ethernet FEC
- I2C with PCF8563 and Temp. Sensor ADM9240
- IDE support
Signed-off-by: Heiko Schocher h...@denx.de
---
- based on:
git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git next
- checked with:
$ ./scripts/checkpatch.pl
0001-mpc5200-support-for-the-MAN-mpc5200-based-board-uc1.patch
total: 0 errors, 0 warnings, 1622 lines checked
0001-mpc5200-support-for-the-MAN-mpc5200-based-board-uc1.patch has no
obvious style problems and is ready for submission.
$
arch/powerpc/boot/dts/uc101.dts | 312 ++
arch/powerpc/configs/52xx/uc101_defconfig| 1303
++
I generally don't like board specific defconfigs unless there is a
really compelling reason why it should be in the kernel tree. Please
add the stuff you need (as modules!) to mpc5200_defconfig.
OK, thanks for spotting this. I take a look how this works.
g.
diff --git a/arch/powerpc/boot/dts/uc101.dts
b/arch/powerpc/boot/dts/uc101.dts
new file mode 100644
index 000..28e1c90
--- /dev/null
+++ b/arch/powerpc/boot/dts/uc101.dts
@@ -0,0 +1,312 @@
+/*
+ * uc101 board Device Tree Source
+ *
+ * Copyright (C) 2009 DENX Software Engineering GmbH
+ * Heiko Schocher h...@denx.de
+ *
+ * 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/;
+
+/ {
+ model = man,uc101;
+ compatible = man,uc101;
+ #address-cells = 1;
+ #size-cells = 1;
+ interrupt-parent = mpc5200_pic;
+
+ cpus {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ PowerPC,5...@0 {
+ device_type = cpu;
+ reg = 0;
+ d-cache-line-size = 32;
+ i-cache-line-size = 32;
+ d-cache-size = 0x4000;// L1, 16K
+ i-cache-size = 0x4000;// L1, 16K
+ timebase-frequency = 0; // from bootloader
+ bus-frequency = 0;// from bootloader
+ clock-frequency = 0; // from bootloader
+ };
+ };
+
+ memory {
+ device_type = memory;
+ reg = 0x 0x0400; // 64MB
+ };
+
+ soc5...@f000 {
+ #address-cells = 1;
+ #size-cells = 1;
+ compatible = fsl,mpc5200-immr;
+ ranges = 0 0xf000 0xc000;
+ reg = 0xf000 0x0100;
+ bus-frequency = 0;// from bootloader
+ system-frequency = 0; // from bootloader
+
+ c...@200 {
+ compatible = fsl,mpc5200-cdm;
+ reg = 0x200 0x38;
+ };
+
+ mpc5200_pic: interrupt-control...@500 {
+ // 5200 interrupts are encoded into two levels;
+ interrupt-controller;
+ #interrupt-cells = 3;
+ compatible = fsl,mpc5200-pic;
+ reg = 0x500 0x80;
+ interrupts = 0 0 3;
+ };
+
+ gpt1: ti...@610 { // General Purpose Timer 1 in GPIO
mode
+ compatible =
fsl,mpc5200b-gpt-gpio,fsl,mpc5200-gpt-gpio;
+ reg = 0x610 0x10;
+ interrupts = 1 10 0;
+ gpio-controller;
+ };
+
+ gpt2: ti...@620 { // General Purpose Timer 2 in GPIO
mode
+ compatible =
fsl,mpc5200b-gpt-gpio,fsl,mpc5200-gpt-gpio;
+ reg = 0x620 0x10;
+ interrupts = 1 11 0;
+ gpio-controller;
+ };
+
+ gpt3: ti...@630 { // General Purpose Timer 3 in GPIO
mode
+ compatible =
fsl,mpc5200b-gpt-gpio,fsl,mpc5200-gpt-gpio;
+ reg = 0x630 0x10;
+ interrupts = 1 12 0;
+ gpio-controller;
+ #gpio-cells = 2;
+ };
+
+ gpio_simple: g...@b00 {
+ compatible = fsl,mpc5200-gpio;
+ reg = 0xb00 0x40;
+ interrupts = 1 7 0;
+ gpio-controller;
+ #gpio-cells = 2;
+ };
+
+ gpio_wkup: g...@c00 {
+
Re: MPC8323 USB Host
Hello, On Mon, Sep 14, 2009 at 05:49:01AM -0700, spa_kk wrote: Hello, [...] The value in this variable are not getting changed even after connecting disconnection the device. Could be pins multiplexing or USB clocks misconfiguration. We have manual checked the USBRXP pin, this pin is HIGH = when device is connected LOW = when device is not connected. Kindly let us know how should we debug/proceed. You might find this useful: http://lkml.org/lkml/2009/4/1/481 -- Anton Vorontsov email: cbouatmai...@gmail.com irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] mpc5200: support for the MAN mpc5200 based board mucmc52
Hello Wolfram,
Wolfram Sang wrote:
Hi,
+mpc5200_pic: interrupt-control...@500 {
+// 5200 interrupts are encoded into two levels;
Grant, maybe this comment could be dropped also for the in-kernel dts-files? I
think it is sufficently described in mpc5200.txt. I could prepare a patch if
you agree.
+i...@3d40 {
+#address-cells = 1;
+#size-cells = 0;
+compatible = fsl,mpc5200-i2c,fsl-i2c;
+reg = 0x3d40 0x40;
+interrupts = 2 16 0;
+fsl5200-clocking;
Please drop the clocking-line. It became obsolete.
OK, I fix this.
Thanks for reviewing
bye
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] mpc5200: support for the MAN mpc5200 based board mucmc52
Hello Grant,
Grant Likely wrote:
Comments below.
On Mon, Sep 14, 2009 at 2:05 AM, Heiko Schocher h...@denx.de wrote:
- serial Console on PSC1
- 64MB SDRAM
- MTD CFI Flash
- Ethernet FEC
- I2C with PCF8563 and Temp. Sensor ADM9240
- IDE support
Signed-off-by: Heiko Schocher h...@denx.de
arch/powerpc/boot/dts/mucmc52.dts| 231
arch/powerpc/configs/52xx/mucmc52_defconfig | 1476
++
Same comment as on your other patch. Drop the defconfig and add the
needed bits to mpc5200_defconfig (in a separate patch, and add drivers
as modules).
Yep, thanks. I look, how this works.
diff --git a/arch/powerpc/boot/dts/mucmc52.dts
b/arch/powerpc/boot/dts/mucmc52.dts
new file mode 100644
index 000..a4a7a20
--- /dev/null
+++ b/arch/powerpc/boot/dts/mucmc52.dts
@@ -0,0 +1,231 @@
+/*
+ * mucmc52 board Device Tree Source
+ *
+ * Copyright (C) 2009 DENX Software Engineering GmbH
+ * Heiko Schocher h...@denx.de
+ *
+ * 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/;
+
+/ {
+ model = man,mucmc52;
+ compatible = man,mucmc52;
+ #address-cells = 1;
+ #size-cells = 1;
+ interrupt-parent = mpc5200_pic;
+
+ cpus {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ PowerPC,5...@0 {
+ device_type = cpu;
+ reg = 0;
+ d-cache-line-size = 32;
+ i-cache-line-size = 32;
+ d-cache-size = 0x4000;// L1, 16K
+ i-cache-size = 0x4000;// L1, 16K
+ timebase-frequency = 0; // from bootloader
+ bus-frequency = 0;// from bootloader
+ clock-frequency = 0; // from bootloader
+ };
+ };
+
+ memory {
+ device_type = memory;
+ reg = 0x 0x0400; // 64MB
+ };
+
+ soc5...@f000 {
+ #address-cells = 1;
+ #size-cells = 1;
+ compatible = fsl,mpc5200-immr;
Does this board use the older and rarer non-'B' mpc5200 part? If not,
then fsl,mpc5200b-immr also needs to be in this list.
OK, I add this too
Thanks
bye
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] mpc5200: support for the MAN mpc5200 based board mucmc52
On Mon, Sep 14, 2009 at 2:03 AM, Wolfram Sang w.s...@pengutronix.de wrote:
Hi,
+ mpc5200_pic: interrupt-control...@500 {
+ // 5200 interrupts are encoded into two levels;
Grant, maybe this comment could be dropped also for the in-kernel dts-files? I
think it is sufficently described in mpc5200.txt. I could prepare a patch if
you agree.
Meh. I don't mind it being there. Interrupt encoding is confusing
enough as is for people unfamiliar with the device tree, that any
additional hints are a plus. In fact, if you want to prepare a patch,
instead of removing this comment, replace it with one that tells
readers where to look for the encoding documentation.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] mpc5200: support for the MAN mpc5200 based board mucmc52
On Mon, Sep 14, 2009 at 8:32 AM, Heiko Schocher h...@denx.de wrote:
Grant Likely wrote:
On Mon, Sep 14, 2009 at 2:05 AM, Heiko Schocher h...@denx.de wrote:
+ soc5...@f000 {
+ #address-cells = 1;
+ #size-cells = 1;
+ compatible = fsl,mpc5200-immr;
Does this board use the older and rarer non-'B' mpc5200 part? If not,
then fsl,mpc5200b-immr also needs to be in this list.
OK, I add this too
Okay, then before you resubmit, do a side-by-side comparison between
this file and one of the existing mpc5200b dts files. There are
numerous fsl,mpc5200b-* compatible values that need to be present.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 01/10] Add support for GCC-4.5's __builtin_unreachable() to compiler.h
Geert Uytterhoeven wrote:
On Fri, Sep 11, 2009 at 17:58, David Daneydda...@caviumnetworks.com wrote:
Michael Buesch wrote:
On Friday 11 September 2009 01:56:42 David Daney wrote:
+/* Unreachable code */
+#ifndef unreachable
+# define unreachable() do { for (;;) ; } while (0)
+#endif
# define unreachable() do { } while (1)
? :)
Clearly I was not thinking clearly when I wrote that part. RTH noted the
same thing. I will fix it.
However, people are so used to seeing the `do { } while (0)' idiom,
that they might miss
there's a `1' here, not a `0'.
So perhaps it's better to use plain `for (;;)' for infinite loops?
I don't think so. The only valid token that can follow 'do { } while
(1)' is ';', any statement may follow 'for (;;)', so there is a greater
possibility to silently screw things up with the for(;;) form.
David Daney
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 0/5] Suspend/resume support for some 83xx/85xx/86xx boards
On Sun, Aug 30, 2009 at 11:36:25PM +0400, Anton Vorontsov wrote: On Fri, Aug 28, 2009 at 12:38:51AM -0500, Kumar Gala wrote: This patch adds suspend/resume support for MPC8540-compatible and MPC8569 CPUs. [...] I'd also like to get Scott's Ack on this and the device tree patches before accepting them. Heh, I didn't notice that the PMC bindings for 85xx describe devdisr registers (and thus sleep = properties). So here are updated patches that should comply with the bindings. Plus, - It appears that 86xx PMCs registers-compatible with 85xx, so we can support both. Thus move 85xx/suspend.c to sysdev/fsl_pmc.c; - New patch that adds suspend/resume for MPC8610HPCD; - New patch that adds suspend/resume for 83xx QE boards; - Some fixes in Make qe_reset() code path safe for repeated invocation patch. Kumar, Is there any issues with the patches? Can you merge them for 2.6.32? Thanks! -- Anton Vorontsov email: cbouatmai...@gmail.com irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/5] powerpc/85xx/86xx: Add suspend/resume support
On Sun, Aug 30, 2009 at 11:37:18PM +0400, Anton Vorontsov wrote:
This patch adds suspend/resume support for MPC8540, MPC8569 and
MPC8641D-compatible CPUs.
MPC8540 and MPC8641D-compatible PMCs are trivial: we just write
the SLP bit into the PM control and status register.
MPC8569 is a bit trickier, QE turns off during suspend, thus on
resume we must reload QE microcode and reset QE.
So far we don't support Deep Sleep mode as found in newer MPC85xx
CPUs (i.e. MPC8536). It can be relatively easy implemented though,
and for it we reserve 'mem' suspend type.
We've got some code floating around here for that; it's just been falling
through the cracks as far as getting a chance to clean up and push
upstream. Hopefully it'll happen soon.
Signed-off-by: Anton Vorontsov avoront...@ru.mvista.com
---
arch/powerpc/Kconfig | 11 +++-
arch/powerpc/sysdev/Makefile |1 +
arch/powerpc/sysdev/fsl_pmc.c | 124
+
3 files changed, 135 insertions(+), 1 deletions(-)
create mode 100644 arch/powerpc/sysdev/fsl_pmc.c
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index d00131c..a0743a7 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -212,7 +212,8 @@ config ARCH_HIBERNATION_POSSIBLE
config ARCH_SUSPEND_POSSIBLE
def_bool y
- depends on ADB_PMU || PPC_EFIKA || PPC_LITE5200 || PPC_83xx
+ depends on ADB_PMU || PPC_EFIKA || PPC_LITE5200 || PPC_83xx || \
+PPC_85xx || PPC_86xx
This isn't directed at this patch, but why do we need this list? Can't
each platform figure out for itself whether it can actually register that
suspend_ops struct, just like any other driver?
config PPC_DCR_NATIVE
bool
@@ -642,6 +643,14 @@ config FSL_PCI
select PPC_INDIRECT_PCI
select PCI_QUIRKS
+config FSL_PMC
+ bool
+ default y
+ depends on SUSPEND (PPC_85xx || PPC_86xx)
+ help
+ Freescale MPC85xx/MPC86xx power management controller support
+ (suspend/resume). For MPC83xx see platforms/83xx/suspend.c
I wish we had a better name for 85xx+86xx than FSL. :-(
+static int pmc_suspend_enter(suspend_state_t state)
+{
+ setbits32(pmc_regs-pmcsr, PMCSR_SLP);
+ /* At this point, the CPU is asleep. */
I'm not sure that we're guaranteed that the sleep has taken effect
immediately -- we may need to do a loop waiting for it to clear (on
85xx), probably with some delays to give the bus a chance to become idle.
I'm not sure how much of that is necessary under certain conditions,
versus just paranoia, though. Something like what you have here worked
well enough for us in testing -- but having that clear immediately after
makes me nervous. At least a read-back seems appropriate (which I
suppose the clbits32 does, but I'd prefer something more explicit).
+ /* For 86xx we need to clear the bit on resume, 85xx don't care. */
+ clrbits32(pmc_regs-pmcsr, PMCSR_SLP);
Hmm, how does this work? Does it only enter sleep mode on the rising
edge of that bit?
The 8610 manual says that that bit should only be set as part of a
sequence also involving the use of MSR[POW] (section 23.5.1.4).
+ if (pmc_qefw) {
+ int ret;
+
+ ret = qe_upload_firmware(pmc_qefw);
+ if (ret)
+ dev_err(pmc_dev, could not upload firmware\n);
+
+ qe_reset();
+ }
Does this really belong here, or should the QE subsystem have a device
struct with suspend/resume ops?
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 0/5] Suspend/resume support for some 83xx/85xx/86xx boards
On Mon, Sep 14, 2009 at 07:33:49PM +0400, Anton Vorontsov wrote: On Sun, Aug 30, 2009 at 11:36:25PM +0400, Anton Vorontsov wrote: On Fri, Aug 28, 2009 at 12:38:51AM -0500, Kumar Gala wrote: This patch adds suspend/resume support for MPC8540-compatible and MPC8569 CPUs. [...] I'd also like to get Scott's Ack on this and the device tree patches before accepting them. ACK the device tree stuff. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] Xilinx: SPI: Fix bits_per_word for transfers
The bits_per_word value can be set for each transfer, or can
be set to zero in each transfer in which case it should default
to the value in the driver.
The driver was fixed to properly check the bits_per_word in
the transfer that is passed in.
Signed-off-by: John Linn john.l...@xilinx.com
---
drivers/spi/xilinx_spi.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/spi/xilinx_spi.c b/drivers/spi/xilinx_spi.c
index 46b8c5c..5a143b9 100644
--- a/drivers/spi/xilinx_spi.c
+++ b/drivers/spi/xilinx_spi.c
@@ -148,7 +148,8 @@ static int xilinx_spi_setup_transfer(struct spi_device *spi,
{
u8 bits_per_word;
- bits_per_word = (t) ? t-bits_per_word : spi-bits_per_word;
+ bits_per_word = (t t-bits_per_word)
+? t-bits_per_word : spi-bits_per_word;
if (bits_per_word != 8) {
dev_err(spi-dev, %s, unsupported bits_per_word=%d\n,
__func__, bits_per_word);
--
1.6.2.1
This email and any attachments are intended for the sole use of the named
recipient(s) and contain(s) confidential information that may be proprietary,
privileged or copyrighted under applicable law. If you are not the intended
recipient, do not read, copy, or forward this email message or any attachments.
Delete this email message and any attachments immediately.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 4/5] kernel handling of memory DLPAR
Andrey Panin wrote:
On 254, 09 11, 2009 at 04:14:35PM -0500, Nathan Fontenot wrote:
This adds the capability to DLPAR add and remove memory from the kernel. The
patch extends the powerpc handling of memory_add_physaddr_to_nid(), which is
called from the sysfs memory 'probe' file to first ensure that the memory
has been added to the system. This is done by creating a platform specific
callout from the routine. The pseries implementation of this handles the
DLPAR work to add the memory to the system and update the device tree.
The patch also creates a pseries only 'release' sys file,
/sys/devices/system/memory/release. This file handles the DLPAR
release of
memory back to firmware and updating of the device-tree.
Signed-off-by: Nathan Fontenot nf...@austin.ibm.com
+static struct property *clone_property(struct property *old_prop)
+{
+ struct property *new_prop;
+
+ new_prop = kzalloc((sizeof *new_prop), GFP_KERNEL);
+ if (!new_prop)
+ return NULL;
+
+ new_prop-name = kzalloc(strlen(old_prop-name) + 1, GFP_KERNEL);
+ new_prop-value = kzalloc(old_prop-length + 1, GFP_KERNEL);
Memory leak here. What if one kzalloc() succeeded and another failed ?
This should be fine. The free_property routine will free the name or value
fields if they are allocated.
-Nathan
+ if (!new_prop-name || !new_prop-value) {
+ free_property(new_prop);
+ return NULL;
+ }
+
+ strcpy(new_prop-name, old_prop-name);
+ memcpy(new_prop-value, old_prop-value, old_prop-length);
+ new_prop-length = old_prop-length;
+
+ return new_prop;
+}
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 5/5] kernel handling of CPU DLPAR
Andrey Panin wrote:
On 254, 09 11, 2009 at 04:15:33PM -0500, Nathan Fontenot wrote:
This adds the capability to DLPAR add and remove CPUs from the kernel. The
creates two new files /sys/devices/system/cpu/probe and
/sys/devices/system/cpu/release to handle the DLPAR addition and
removal of
CPUs respectively.
CPU DLPAR add is accomplished by writing the drc-index of the CPU to the
probe file, and removal is done by writing the device-tree path of the cpu
to the release file.
Signed-off-by: Nathan Fontenot nf...@austin.ibm.com
+static ssize_t cpu_probe_store(struct class *class, const char *buf,
+ size_t count)
+{
+ struct device_node *dn;
+ u32 drc_index;
+ char *cpu_name;
+ int rc;
+
+ drc_index = simple_strtoull(buf, NULL, 0);
+ if (!drc_index)
+ return -EINVAL;
+
+ rc = acquire_drc(drc_index);
+ if (rc)
+ return rc;
+
+ dn = configure_connector(drc_index);
+ if (!dn) {
+ release_drc(drc_index);
+ return rc;
+ }
+
+ /* fixup dn name */
+ cpu_name = kzalloc(strlen(dn-full_name) + strlen(/cpus/) + 1,
+ GFP_KERNEL);
Unchecked memory allocation with immediate crash in case of failure.
Yep, thats a bad thing. I'll fix this in an updated patch. thanks.
-Nathan
+ sprintf(cpu_name, /cpus/%s, dn-full_name);
+ kfree(dn-full_name);
+ dn-full_name = cpu_name;
+
+ rc = add_device_tree_nodes(dn);
+ if (rc)
+ release_drc(drc_index);
+
+ return rc ? rc : count;
+}
+
+static ssize_t cpu_release_store(struct class *class, const char *buf,
+size_t count)
+{
+ struct device_node *dn;
+ u32 *drc_index;
+ int rc;
+
+ dn = of_find_node_by_path(buf);
+ if (!dn)
+ return -EINVAL;
+
+ drc_index = (u32 *)of_get_property(dn, ibm,my-drc-index, NULL);
+ if (!drc_index) {
+ of_node_put(dn);
+ return -EINVAL;
+ }
+
+ rc = release_drc(*drc_index);
+ if (rc) {
+ of_node_put(dn);
+ return rc;
+ }
+
+ rc = remove_device_tree_nodes(dn);
+ if (rc)
+ acquire_drc(*drc_index);
+
+ of_node_put(dn);
+ return rc? rc : count;
+}
+
static struct class_attribute class_attr_mem_release =
__ATTR(release, S_IWUSR, NULL, memory_release_store);
+static struct class_attribute class_attr_cpu_probe =
+ __ATTR(probe, S_IWUSR, NULL, cpu_probe_store);
+static struct class_attribute class_attr_cpu_release =
+ __ATTR(release, S_IWUSR, NULL, cpu_release_store);
static int pseries_dlpar_init(void)
{
@@ -576,6 +648,18 @@
printk(KERN_INFO DLPAR: Could not create sysfs memory
release file\n);
+ rc = sysfs_create_file(cpu_sysdev_class.kset.kobj,
+ class_attr_cpu_probe.attr);
+ if (rc)
+ printk(KERN_INFO DLPAR: Could not create sysfs cpu
+ probe file\n);
+
+ rc = sysfs_create_file(cpu_sysdev_class.kset.kobj,
+ class_attr_cpu_release.attr);
+ if (rc)
+ printk(KERN_INFO DLPAR: Could not create sysfs cpu
+ release file\n);
+
return 0;
}
__initcall(pseries_dlpar_init);
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 0/5] kernel handling of dynamic logical partitioning
Daniel Walker wrote: On Fri, 2009-09-11 at 16:08 -0500, Nathan Fontenot wrote: am cc'ing lkml. Patches include in this set: 1/5 - DLPAR infrastructure for powerpc/pseries platform. 2/5 - Move the of_drconf_cell struct to prom.h 3/5 - Export the memory sysdev class 4/5 - Memory DLPAR handling 5/5 - CPU DLPAR handling It looks like a couple of your patches have some checkpatch issues.. Could you run these through scripts/checkpatch.pl and clean up any problems it raises ? Specifically patches 1, 4, and 5 .. thanks for checking this, I obviously forgot. I'll post updated patches (after running checkpatch on them) with fixes. -Nathan ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 0/5] kernel handling of dynamic logical partitioning
On Mon, 2009-09-14 at 13:22 -0500, Nathan Fontenot wrote: Daniel Walker wrote: On Fri, 2009-09-11 at 16:08 -0500, Nathan Fontenot wrote: am cc'ing lkml. Patches include in this set: 1/5 - DLPAR infrastructure for powerpc/pseries platform. 2/5 - Move the of_drconf_cell struct to prom.h 3/5 - Export the memory sysdev class 4/5 - Memory DLPAR handling 5/5 - CPU DLPAR handling It looks like a couple of your patches have some checkpatch issues.. Could you run these through scripts/checkpatch.pl and clean up any problems it raises ? Specifically patches 1, 4, and 5 .. thanks for checking this, I obviously forgot. I'll post updated patches (after running checkpatch on them) with fixes. Ok, thanks.. Daniel ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/5] dynamic logical partitioning infrastructure
Nathan Fontenot wrote:
+#include linux/kernel.h
+#include linux/kref.h
+#include linux/notifier.h
+#include linux/proc_fs.h
+#include linux/spinlock.h
+
+#include asm/prom.h
+#include asm/machdep.h
+#include asm/uaccess.h
+#include asm/rtas.h
+#include asm/pSeries_reconfig.h
+
+#define CFG_CONN_WORK_SIZE4096
+static char workarea[CFG_CONN_WORK_SIZE];
+spinlock_t workarea_lock;
This can be:
static DEFINE_SPINLOCK(workarea_lock);
Then you can get rid of the runtime initializer.
+
+int release_drc(u32 drc_index)
+{
+int dr_status, rc;
+
+rc = rtas_call(rtas_token(get-sensor-state), 2, 2, dr_status,
+ DR_ENTITY_SENSE, drc_index);
+if (rc || dr_status != DR_ENTITY_PRESENT)
+return -1;
+
+rc = rtas_set_indicator(ISOLATION_STATE, drc_index, ISOLATE);
+if (rc)
+return -1;
+
+rc = rtas_set_indicator(ALLOCATION_STATE, drc_index, ALLOC_UNUSABLE);
+if (rc) {
+rtas_set_indicator(ISOLATION_STATE, drc_index, UNISOLATE);
+return -1;
+}
Is there a better return value here that might be more descriptive than -1?
+
+return 0;
+}
+
+static int pseries_dlpar_init(void)
+{
+spin_lock_init(workarea_lock);
+
+if (!machine_is(pseries))
+return 0;
What's the point of this if check if you return 0 either way?
+
+return 0;
+}
+__initcall(pseries_dlpar_init);
Index: powerpc/arch/powerpc/platforms/pseries/reconfig.c
===
--- powerpc.orig/arch/powerpc/platforms/pseries/reconfig.c2009-09-11
12:43:39.0 -0500
+++ powerpc/arch/powerpc/platforms/pseries/reconfig.c2009-09-11
12:51:52.0 -0500
@@ -95,7 +95,7 @@
return parent;
}
-static BLOCKING_NOTIFIER_HEAD(pSeries_reconfig_chain);
+struct blocking_notifier_head pSeries_reconfig_chain =
BLOCKING_NOTIFIER_INIT(pSeries_reconfig_chain);
Can't this just be?
BLOCKING_NOTIFIER_HEAD(pSeries_reconfig_chain);
--
Brian King
Linux on Power Virtualization
IBM Linux Technology Center
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] Xilinx: SPI: Fix bits_per_word for transfers
On Mon, Sep 14, 2009 at 12:17 PM, John Linn john.l...@xilinx.com wrote:
The bits_per_word value can be set for each transfer, or can
be set to zero in each transfer in which case it should default
to the value in the driver.
The driver was fixed to properly check the bits_per_word in
the transfer that is passed in.
Signed-off-by: John Linn john.l...@xilinx.com
Looks good to me.
Acked-by: Grant Likely grant.lik...@secretlab.ca
---
drivers/spi/xilinx_spi.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/spi/xilinx_spi.c b/drivers/spi/xilinx_spi.c
index 46b8c5c..5a143b9 100644
--- a/drivers/spi/xilinx_spi.c
+++ b/drivers/spi/xilinx_spi.c
@@ -148,7 +148,8 @@ static int xilinx_spi_setup_transfer(struct spi_device
*spi,
{
u8 bits_per_word;
- bits_per_word = (t) ? t-bits_per_word : spi-bits_per_word;
+ bits_per_word = (t t-bits_per_word)
+ ? t-bits_per_word : spi-bits_per_word;
if (bits_per_word != 8) {
dev_err(spi-dev, %s, unsupported bits_per_word=%d\n,
__func__, bits_per_word);
--
1.6.2.1
This email and any attachments are intended for the sole use of the named
recipient(s) and contain(s) confidential information that may be proprietary,
privileged or copyrighted under applicable law. If you are not the intended
recipient, do not read, copy, or forward this email message or any
attachments. Delete this email message and any attachments immediately.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] mpc5200: support for the MAN mpc5200 based board uc101
Hello Heiko,
Heiko Schocher wrote:
Hello Grant,
Grant Likely wrote:
Thanks for the patch. Comments below.
g.
On Mon, Sep 14, 2009 at 2:05 AM, Heiko Schocher h...@denx.de wrote:
- serial Console on PSC1
- 64MB SDRAM
- MTD CFI Flash
- Ethernet FEC
- I2C with PCF8563 and Temp. Sensor ADM9240
- IDE support
Signed-off-by: Heiko Schocher h...@denx.de
...snip
+ i...@3d40 {
+ #address-cells = 1;
+ #size-cells = 0;
+ compatible = fsl,mpc5200-i2c,fsl-i2c;
+ reg = 0x3d40 0x40;
+ interrupts = 2 16 0;
+ fsl5200-clocking;
I believe fsl5200-clocking is no longer required. There is a patch
pending which removes this property from the other .dts files.
Right, it obsolete.
Ok, fix this.
Like it is, the I2C controller will use a fixed low speed fdt/dfsr
setting. You have two other options:
fsl,preserve-clocking;
clock-frequency = 40;
See also
http://lxr.linux.no/#linux+v2.6.31/Documentation/powerpc/dts-bindings/fsl/i2c.txt.
+
+ hw...@2c {
+ compatible = ad,adm9240;
+ reg = 0x2c;
+ };
+ r...@51 {
+ compatible = rtc,pcf8563;
rtc is not a proper vendor name. Should be nxp, IIRC.
Wolfgang.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Fix bug where perf_counters breaks oprofile
Maynard Johnson wrote:
Paul Mackerras wrote:
Currently there is a bug where if you use oprofile on a pSeries
machine, then use perf_counters, then use oprofile again, oprofile
will not work correctly; it will lose the PMU configuration the next
time the hypervisor does a partition context switch, and thereafter
won't count anything.
Ben,
Is there any way to get this bug fix into 2.6.31 or is the window closed? Once
the problem occurs, you can't get oprofile to work again without a reboot.
Really would be nice (for many reasons) to get this fixed in .31.
Thanks.
-Maynard
Maynard Johnson identified the sequence causing the problem:
- oprofile setup calls ppc_enable_pmcs(), which calls
pseries_lpar_enable_pmcs, which tells the hypervisor that we want
to use the PMU, and sets the PMU in use flag in the lppaca.
This flag tells the hypervisor whether it needs to save and restore
the PMU config.
- The perf_counter code sets and clears the PMU in use flag directly
as it context-switches the PMU between tasks, and leaves it clear
when it finishes.
- oprofile setup, called for a new oprofile run, calls ppc_enable_pmcs,
which does nothing because it has already been called. In particular
it doesn't set the PMU in use flag.
This fixes the problem by arranging for ppc_enable_pmcs to always set
the PMU in use flag. It makes the perf_counter code call
ppc_enable_pmcs also rather than calling the lower-level function
directly, and removes the setting of the PMU in use flag from
pseries_lpar_enable_pmcs, since that is now done in its caller.
This also removes the declaration of pasemi_enable_pmcs because it
isn't defined anywhere.
Thanks, Paul. I tested the patch, and oprofile and perf now play nicely
together.
-Maynard
Reported-by: Maynard Johnson mpj...@us.ibm.com
Signed-off-by: Paul Mackerras pau...@samba.org
---
arch/powerpc/include/asm/pmc.h | 16 ++--
arch/powerpc/kernel/perf_counter.c | 13 +++--
arch/powerpc/kernel/sysfs.c|3 +++
arch/powerpc/platforms/pseries/setup.c |4
4 files changed, 20 insertions(+), 16 deletions(-)
diff --git a/arch/powerpc/include/asm/pmc.h b/arch/powerpc/include/asm/pmc.h
index d6a616a..ccc68b5 100644
--- a/arch/powerpc/include/asm/pmc.h
+++ b/arch/powerpc/include/asm/pmc.h
@@ -27,10 +27,22 @@ extern perf_irq_t perf_irq;
int reserve_pmc_hardware(perf_irq_t new_perf_irq);
void release_pmc_hardware(void);
+void ppc_enable_pmcs(void);
#ifdef CONFIG_PPC64
-void power4_enable_pmcs(void);
-void pasemi_enable_pmcs(void);
+#include asm/lppaca.h
+
+static inline void ppc_set_pmu_inuse(int inuse)
+{
+get_lppaca()-pmcregs_in_use = inuse;
+}
+
+extern void power4_enable_pmcs(void);
+
+#else /* CONFIG_PPC64 */
+
+static inline void ppc_set_pmu_inuse(int inuse) { }
+
#endif
#endif /* __KERNEL__ */
diff --git a/arch/powerpc/kernel/perf_counter.c
b/arch/powerpc/kernel/perf_counter.c
index 70e1f57..ccd6b21 100644
--- a/arch/powerpc/kernel/perf_counter.c
+++ b/arch/powerpc/kernel/perf_counter.c
@@ -62,7 +62,6 @@ static inline unsigned long perf_ip_adjust(struct pt_regs
*regs)
{
return 0;
}
-static inline void perf_set_pmu_inuse(int inuse) { }
static inline void perf_get_data_addr(struct pt_regs *regs, u64 *addrp) { }
static inline u32 perf_get_misc_flags(struct pt_regs *regs)
{
@@ -93,11 +92,6 @@ static inline unsigned long perf_ip_adjust(struct pt_regs
*regs)
return 0;
}
-static inline void perf_set_pmu_inuse(int inuse)
-{
-get_lppaca()-pmcregs_in_use = inuse;
-}
-
/*
* The user wants a data address recorded.
* If we're not doing instruction sampling, give them the SDAR
@@ -531,8 +525,7 @@ void hw_perf_disable(void)
* Check if we ever enabled the PMU on this cpu.
*/
if (!cpuhw-pmcs_enabled) {
-if (ppc_md.enable_pmcs)
-ppc_md.enable_pmcs();
+ppc_enable_pmcs();
cpuhw-pmcs_enabled = 1;
}
@@ -594,7 +587,7 @@ void hw_perf_enable(void)
mtspr(SPRN_MMCRA, cpuhw-mmcr[2] ~MMCRA_SAMPLE_ENABLE);
mtspr(SPRN_MMCR1, cpuhw-mmcr[1]);
if (cpuhw-n_counters == 0)
-perf_set_pmu_inuse(0);
+ppc_set_pmu_inuse(0);
goto out_enable;
}
@@ -627,7 +620,7 @@ void hw_perf_enable(void)
* bit set and set the hardware counters to their initial values.
* Then unfreeze the counters.
*/
-perf_set_pmu_inuse(1);
+ppc_set_pmu_inuse(1);
mtspr(SPRN_MMCRA, cpuhw-mmcr[2] ~MMCRA_SAMPLE_ENABLE);
mtspr(SPRN_MMCR1, cpuhw-mmcr[1]);
mtspr(SPRN_MMCR0, (cpuhw-mmcr[0] ~(MMCR0_PMC1CE | MMCR0_PMCjCE))
diff --git a/arch/powerpc/kernel/sysfs.c b/arch/powerpc/kernel/sysfs.c
index f41aec8..956ab33 100644
--- a/arch/powerpc/kernel/sysfs.c
[PATCH v3 2/5] powerpc/85xx/86xx: Add suspend/resume support
This patch adds suspend/resume support for MPC8540, MPC8569 and
MPC8641D-compatible CPUs.
MPC8540 and MPC8641D-compatible PMCs are trivial: we just write
the SLP bit into the PM control and status register.
MPC8569 is a bit trickier, QE turns off during suspend, thus on
resume we must reload QE microcode and reset QE.
So far we don't support Deep Sleep mode as found in newer MPC85xx
CPUs (i.e. MPC8536). It can be relatively easy implemented though,
and for it we reserve 'mem' suspend type.
Signed-off-by: Anton Vorontsov avoront...@ru.mvista.com
---
On Mon, Sep 14, 2009 at 12:28:11PM -0500, Scott Wood wrote:
[...]
So far we don't support Deep Sleep mode as found in newer MPC85xx
CPUs (i.e. MPC8536). It can be relatively easy implemented though,
and for it we reserve 'mem' suspend type.
We've got some code floating around here for that; it's just been falling
through the cracks as far as getting a chance to clean up and push
upstream. Hopefully it'll happen soon.
Nice.
[...]
+++ b/arch/powerpc/Kconfig
@@ -212,7 +212,8 @@ config ARCH_HIBERNATION_POSSIBLE
config ARCH_SUSPEND_POSSIBLE
def_bool y
- depends on ADB_PMU || PPC_EFIKA || PPC_LITE5200 || PPC_83xx
+ depends on ADB_PMU || PPC_EFIKA || PPC_LITE5200 || PPC_83xx || \
+ PPC_85xx || PPC_86xx
This isn't directed at this patch, but why do we need this list? Can't
each platform figure out for itself whether it can actually register that
suspend_ops struct, just like any other driver?
Good question. Disabling PM also makes some drivers less
tested, since there are a lot of #ifdef CONFIG_PM in the
drivers.
Though in this patch I'm just following current practice, if
a cleanup patch for all platforms is desired, I can readily
implement it.
[...]
+config FSL_PMC
+ bool
+ default y
+ depends on SUSPEND (PPC_85xx || PPC_86xx)
+ help
+ Freescale MPC85xx/MPC86xx power management controller support
+ (suspend/resume). For MPC83xx see platforms/83xx/suspend.c
I wish we had a better name for 85xx+86xx than FSL. :-(
Ditto. It took me quite some time to pick the name, couldn't find
anything better.
+static int pmc_suspend_enter(suspend_state_t state)
+{
+ setbits32(pmc_regs-pmcsr, PMCSR_SLP);
+ /* At this point, the CPU is asleep. */
I'm not sure that we're guaranteed that the sleep has taken effect
immediately -- we may need to do a loop waiting for it to clear (on
85xx), probably with some delays to give the bus a chance to become idle.
Brilliant idea, thanks!
But it works vice versa: upon write, the code flow stops immediately
(on 85xx and 86xx), so there wouldn't any point in trying to readback
the pmcsr. But upon resume, on 86xx (and most probably on 85xx,
though we don't see it), the SLP bit doesn't clear immediately, we
have to wait for it. This eliminates the need for clearing the bit
for 86xx (i.e. the clearing operation worked as a small delay).
I'm not sure how much of that is necessary under certain conditions,
versus just paranoia, though.
Something like what you have here worked
well enough for us in testing -- but having that clear immediately after
makes me nervous. At least a read-back seems appropriate (which I
suppose the clbits32 does, but I'd prefer something more explicit).
+ /* For 86xx we need to clear the bit on resume, 85xx don't care. */
+ clrbits32(pmc_regs-pmcsr, PMCSR_SLP);
Hmm, how does this work? Does it only enter sleep mode on the rising
edge of that bit?
No, it appears it is the same as in 85xx, the bit clears by itself,
but we must wait for it. So your idea about looping and reading the
register actually eliminates the need for clrbits32(). Without the
clrbit32 (aka delay) or proper looping we would let device drivers
to resume too early, and things, obviously, didn't work.
The 8610 manual says that that bit should only be set as part of a
sequence also involving the use of MSR[POW] (section 23.5.1.4).
Well, 23.4.1.12 says:
| Sleep status
| 0 The device is not attempting to reach sleep mode.
| 1 The device is attempting to enter sleep mode because
| POWMGTCSR[SLP] is set, or HID0[SLEEP] and MSR[POW] in
^^
| the e600 core are set. The core has halted fetching, snooping
| to the L1 and L2 caches is disabled,
The same in 85xx specs.
I can confirm this on real hw, after setting the SLP bit, the 8610
actually goes into sleep mode, no code flow happens until a wakeup
event. So playing with MSR[POW] doesn't seem to be necessary. The
same for 85xx.
+ if (pmc_qefw) {
+ int ret;
+
+ ret = qe_upload_firmware(pmc_qefw);
+ if (ret)
+ dev_err(pmc_dev, could not upload firmware\n);
+
+ qe_reset();
+ }
Does this really belong here, or should the QE subsystem have a device
struct with suspend/resume ops?
This exact snippet could be moved to the qe device driver, yes.
But I didn't bother
Re: [PATCH] powerpc: Fix bug where perf_counters breaks oprofile
On Mon, Sep 14, 2009 at 03:14:02PM -0500, Maynard Johnson wrote: Maynard Johnson wrote: Paul Mackerras wrote: Currently there is a bug where if you use oprofile on a pSeries machine, then use perf_counters, then use oprofile again, oprofile will not work correctly; it will lose the PMU configuration the next time the hypervisor does a partition context switch, and thereafter won't count anything. Ben, Is there any way to get this bug fix into 2.6.31 or is the window closed? Once the problem occurs, you can't get oprofile to work again without a reboot. Really would be nice (for many reasons) to get this fixed in .31. .31 is already released. Could probably get it into a -stable .31 kernel though. josh ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 2/5] powerpc/85xx/86xx: Add suspend/resume support
Anton Vorontsov wrote: This patch adds suspend/resume support for MPC8540, MPC8569 and MPC8641D-compatible CPUs. MPC8540 and MPC8641D-compatible PMCs are trivial: we just write the SLP bit into the PM control and status register. MPC8569 is a bit trickier, QE turns off during suspend, thus on resume we must reload QE microcode and reset QE. So far we don't support Deep Sleep mode as found in newer MPC85xx CPUs (i.e. MPC8536). It can be relatively easy implemented though, and for it we reserve 'mem' suspend type. Signed-off-by: Anton Vorontsov avoront...@ru.mvista.com Acked-by: Scott Wood scottw...@freescale.com I'm not sure that we're guaranteed that the sleep has taken effect immediately -- we may need to do a loop waiting for it to clear (on 85xx), probably with some delays to give the bus a chance to become idle. Brilliant idea, thanks! But it works vice versa: upon write, the code flow stops immediately (on 85xx and 86xx), That's what I've observed as well; the question is whether it's always guaranteed to be immediate. The 8610 manual says that that bit should only be set as part of a sequence also involving the use of MSR[POW] (section 23.5.1.4). Well, 23.4.1.12 says: | Sleep status | 0 The device is not attempting to reach sleep mode. | 1 The device is attempting to enter sleep mode because | POWMGTCSR[SLP] is set, or HID0[SLEEP] and MSR[POW] in ^^ | the e600 core are set. The core has halted fetching, snooping | to the L1 and L2 caches is disabled, The same in 85xx specs. I can confirm this on real hw, after setting the SLP bit, the 8610 actually goes into sleep mode, no code flow happens until a wakeup event. So playing with MSR[POW] doesn't seem to be necessary. The same for 85xx. OK, looks like section 23.5.1.4 is just bogus. This exact snippet could be moved to the qe device driver, yes. But I didn't bother because fsl_pmc have to request the QE firmware. You can't request the firmware in the qe driver's -suspend() routine necause the firmware may be on e.g. NFS filesystem or USB stick (implies having QE Ethernet or QE USB fully functional). Is there any way for software to read out the current firmware from the device, or is it write-only? We can solve that by implementing ppc_md.suspend_prepare() (must be called from userspace context), there we could request the firmware. Then QE device driver would reload it in its resume() callback. Needless to say that it makes things a bit more complicated to follow. The current code vanishes without QE anyway. But if you insist, I can do the suspend_prepare() thing, although I'd prefer it as a cleanup patch for 2.6.33, since it would touch more code, specifically I'm concerned about ppc generic files. I don't insist, it just struck me as odd. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 2/5] powerpc/85xx/86xx: Add suspend/resume support
On Mon, Sep 14, 2009 at 03:45:10PM -0500, Scott Wood wrote: [...] You can't request the firmware in the qe driver's -suspend() routine necause the firmware may be on e.g. NFS filesystem or USB stick (implies having QE Ethernet or QE USB fully functional). Is there any way for software to read out the current firmware from the device, or is it write-only? Hm, I didn't look into iram stuff that much, but seemingly I can read it back and save. In the end, it's just a ram that we access in a weird way... Let me try it. Thanks, -- Anton Vorontsov email: cbouatmai...@gmail.com irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 00/11] Add support for GCC's __builtin_unreachable() and use it in BUG (v2).
When I sent the first version, I had not realized that Roland McGrath had only a day or two earlier submitted a very similar patch (although one that only fixed up the x86 case). I have been working on this quite a while now, starting with adding the required support to GCC, so with an eye towards finishing it up I have this new version. From the announcement of the first version: Starting with version 4.5, GCC has a new built-in function called __builtin_unreachable(). The function tells the compiler that control flow will never reach that point. Currently we trick the compiler by putting in for(;;); but this has the disadvantage that extra code is emitted for an endless loop. For an i386 kernel using __builtin_unreachable() results in an defaultconfig that is nearly 4000 bytes smaller. This patch set adds support to compiler.h creating a new macro usable in the kernel called unreachable(). If the compiler lacks __builtin_unreachable(), it just expands to for(;;). The x86 and MIPS patches I actually tested with a GCC-4.5 snapshot. Lacking the ability to test the rest of the architectures, I just did what seemed right without even trying to compile the kernel. For version 2: I fixed a couple of checkpatch issues, and simplified the unreachable() macro for the pre-GCC-4.5 case (as suggested by Richard Henderson). Also several Acked-by: were added. New in this version (as suggested by Ingo Molnar) I added 11/11 which uses unreachable() in asm-generic/bug.h for !CONFIG_BUG case. This one may be a little controversial as it will end up making code slightly larger when !CONFIG_BUG and you are using a pre-GCC-4.5 compiler. I will reply with the 11 patches. David Daney (11): Add support for GCC-4.5's __builtin_unreachable() to compiler.h (v2) x86: Convert BUG() to use unreachable() MIPS: Convert BUG() to use unreachable() s390: Convert BUG() to use unreachable() mn10300: Convert BUG() to use unreachable() parisc: Convert BUG() to use unreachable() powerpc: Convert BUG() to use unreachable() alpha: Convert BUG() to use unreachable() avr32: Convert BUG() to use unreachable() blackfin: Convert BUG() to use unreachable() Use unreachable() in asm-generic/bug.h for !CONFIG_BUG case. arch/alpha/include/asm/bug.h|3 ++- arch/avr32/include/asm/bug.h|2 +- arch/blackfin/include/asm/bug.h |2 +- arch/mips/include/asm/bug.h |4 +--- arch/mn10300/include/asm/bug.h |3 ++- arch/parisc/include/asm/bug.h |4 ++-- arch/powerpc/include/asm/bug.h |2 +- arch/s390/include/asm/bug.h |2 +- arch/x86/include/asm/bug.h |4 ++-- include/asm-generic/bug.h |4 ++-- include/linux/compiler-gcc4.h | 14 ++ include/linux/compiler.h|5 + 12 files changed, 34 insertions(+), 15 deletions(-) ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 07/11] powerpc: Convert BUG() to use unreachable()
Use the new unreachable() macro instead of for(;;);
Signed-off-by: David Daney dda...@caviumnetworks.com
CC: Benjamin Herrenschmidt b...@kernel.crashing.org
CC: Paul Mackerras pau...@samba.org
CC: linuxppc-...@ozlabs.org
---
arch/powerpc/include/asm/bug.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/include/asm/bug.h b/arch/powerpc/include/asm/bug.h
index 64e1fdc..2c15212 100644
--- a/arch/powerpc/include/asm/bug.h
+++ b/arch/powerpc/include/asm/bug.h
@@ -68,7 +68,7 @@
_EMIT_BUG_ENTRY \
: : i (__FILE__), i (__LINE__), \
i (0), i (sizeof(struct bug_entry))); \
- for(;;) ; \
+ unreachable(); \
} while (0)
#define BUG_ON(x) do { \
--
1.6.2.5
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Oops in IDE probing on ppc_440 when PCI is enabled in strapping
On Mon, 2009-09-14 at 15:08 +0200, Ludo Van Put wrote: 2009/9/14 Josh Boyer jwbo...@linux.vnet.ibm.com: On Mon, Sep 14, 2009 at 02:36:15PM +0200, Ludo Van Put wrote: Hi, we're working with a PPC440GX on a board that has a.o. a compact flash slot. We had the PCI subsystem of the ppc disabled in strapping for quite a while, until we wanted to start using it. However, when we enabled PCI in the strapping and in the (patched 2.6.10) 2.6.10? Really? If that is truly the case, you probably aren't going to get a whole lot of help from the list, since that kernel is pretty ancient. I can only acknowledge that, but we're stuck to that kernel for now... kernel configuration, we triggered an oops when probing for IDE devices (to read out the first 512 bytes of the CF). I can see that the ioremap64 call in the driver code for our CF returns a different address (compared to PCI disabled in strapping), but using this address later on for accessing the CF goes wrong. Posting the oops output would perhaps help. Or maybe not. josh Here it goes, you never know: Oops: kernel access of bad area, sig: 11 [#1] PREEMPT NIP: C0148050 LR: C013BC64 SP: C07CFEA0 REGS: c07cfdf0 TRAP: 0300Not tainted MSR: 00021000 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 00 DAR: E3093000, DSISR: TASK = c07cdb70[1] 'swapper' THREAD: c07ce000 Last syscall: 120 GPR00: C07CFEA0 C07CDB70 E3093000 DFE829FE 0100 C01184E8 C021B270 GPR08: C022 C02D0F60 C07CDEF8 C07CDEF8 7000 1FFF6400 0001 GPR16: 0001 1FFF06C0 0001 C022 C028 00029000 GPR24: C02D0F60 C01F C0148040 0080 DFE82A00 C02D0FF0 NIP [c0148050] ide_insw+0x10/0x24 LR [c013bc64] ata_input_data+0x74/0x114 Call backtrace: c013e6a4 try_to_identify+0x2ec/0x5ec c013eaa8 do_probe+0x104/0x304 c013f0c4 probe_hwif+0x358/0x6c4 c0140068 ideprobe_init+0xa8/0x1a0 c02a4ef8 ide_generic_init+0x10/0x28 c0001324 init+0xc4/0x244 c0004254 kernel_thread+0x44/0x60 Kernel panic - not syncing: Attempted to kill init! 0Rebooting in 180 seconds.. ide_insw is a asm routine to read in 16bit words and swap them. Copied from arch/ppc/kernel/misc.S. Works fine when PCI is disabled. Probably because ide_insw uses isnw which offsets everything from _IO_BASE which changes value when you have a PCI bus with an IO space... If your IDE isn't PCI IO space based you shouldn't use ide_insw but the MMIO variants instead. Ben. KR, Ludo ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Fix bug where perf_counters breaks oprofile
On Mon, 2009-09-14 at 16:43 -0400, Josh Boyer wrote: On Mon, Sep 14, 2009 at 03:14:02PM -0500, Maynard Johnson wrote: Maynard Johnson wrote: Paul Mackerras wrote: Currently there is a bug where if you use oprofile on a pSeries machine, then use perf_counters, then use oprofile again, oprofile will not work correctly; it will lose the PMU configuration the next time the hypervisor does a partition context switch, and thereafter won't count anything. Ben, Is there any way to get this bug fix into 2.6.31 or is the window closed? Once the problem occurs, you can't get oprofile to work again without a reboot. Really would be nice (for many reasons) to get this fixed in .31. .31 is already released. Could probably get it into a -stable .31 kernel though. The fix is already upstream as well no ? Ben. josh ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Fix bug where perf_counters breaks oprofile
On Tue, Sep 15, 2009 at 10:56:47AM +1000, Benjamin Herrenschmidt wrote: On Mon, 2009-09-14 at 16:43 -0400, Josh Boyer wrote: On Mon, Sep 14, 2009 at 03:14:02PM -0500, Maynard Johnson wrote: Maynard Johnson wrote: Paul Mackerras wrote: Currently there is a bug where if you use oprofile on a pSeries machine, then use perf_counters, then use oprofile again, oprofile will not work correctly; it will lose the PMU configuration the next time the hypervisor does a partition context switch, and thereafter won't count anything. Ben, Is there any way to get this bug fix into 2.6.31 or is the window closed? Once the problem occurs, you can't get oprofile to work again without a reboot. Really would be nice (for many reasons) to get this fixed in .31. .31 is already released. Could probably get it into a -stable .31 kernel though. The fix is already upstream as well no ? Sort of. It's in your next branch, but not in Linus' tree. Anyway, some people like to have particular versions work so -stable is good regardless :). josh ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] mpc5200: support for the MAN mpc5200 based board uc101
Hello Wolfgang,
Wolfgang Grandegger wrote:
Heiko Schocher wrote:
Hello Grant,
Grant Likely wrote:
Thanks for the patch. Comments below.
g.
On Mon, Sep 14, 2009 at 2:05 AM, Heiko Schocher h...@denx.de wrote:
- serial Console on PSC1
- 64MB SDRAM
- MTD CFI Flash
- Ethernet FEC
- I2C with PCF8563 and Temp. Sensor ADM9240
- IDE support
Signed-off-by: Heiko Schocher h...@denx.de
...snip
+ i...@3d40 {
+ #address-cells = 1;
+ #size-cells = 0;
+ compatible = fsl,mpc5200-i2c,fsl-i2c;
+ reg = 0x3d40 0x40;
+ interrupts = 2 16 0;
+ fsl5200-clocking;
I believe fsl5200-clocking is no longer required. There is a patch
pending which removes this property from the other .dts files.
Right, it obsolete.
OK, I remove it.
Ok, fix this.
Like it is, the I2C controller will use a fixed low speed fdt/dfsr
setting. You have two other options:
fsl,preserve-clocking;
clock-frequency = 40;
See also
http://lxr.linux.no/#linux+v2.6.31/Documentation/powerpc/dts-bindings/fsl/i2c.txt.
Ah, ok, thanks for this info. I try this ...
+
+ hw...@2c {
+ compatible = ad,adm9240;
+ reg = 0x2c;
+ };
+ r...@51 {
+ compatible = rtc,pcf8563;
rtc is not a proper vendor name. Should be nxp, IIRC.
OK, fix it.
Thanks for reviewing
bye
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: MPC8323 USB Host
Hi,
Thanks for the suggestion,
pins clock configuration seems to be ok,
Need a help in understanding which register of MPC8323 is been mapped to
fhci-vroot_hub-port.wPortChange
fhci-vroot_hub-port.wPortStatus
As this are the variable which is been checked while polling
File: drivers/usb/host/fhci.h
struct virtual_root_hub {
int dev_num;/* USB address of the root hub */
u32 feature;/* indicates what feature has been set */
struct usb_hub_status hub;
struct usb_port_status port;
};
File: drivers/usb/core/hub.h
/*
* Hub Status and Hub Change results
* See USB 2.0 spec Table 11-19 and Table 11-20
*/
struct usb_port_status {
__le16 wPortStatus;
__le16 wPortChange;
} __attribute__ ((packed));
struct usb_hub_status {
__le16 wHubStatus;
__le16 wHubChange;
} __attribute__ ((packed));
Need support in understand where is virtual_root_hub.hub and
virtual_root_hub.port are initialized
Thanks and best regards,
Krishna
Anton Vorontsov-2 wrote:
Hello,
On Mon, Sep 14, 2009 at 05:49:01AM -0700, spa_kk wrote:
Hello,
[...]
The value in this variable are not getting changed even after connecting
disconnection the device.
Could be pins multiplexing or USB clocks misconfiguration.
We have manual checked the USBRXP pin, this pin is
HIGH = when device is connected
LOW = when device is not connected.
Kindly let us know how should we debug/proceed.
You might find this useful:
http://lkml.org/lkml/2009/4/1/481
--
Anton Vorontsov
email: cbouatmai...@gmail.com
irc://irc.freenode.net/bd2
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
--
View this message in context:
http://www.nabble.com/MPC8323-USB-Host-tp25435195p25448161.html
Sent from the linuxppc-dev mailing list archive at Nabble.com.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc: Check for unsupported relocs when using CONFIG_RELOCATABLE
From: Tony Breeds t...@bakeyournoodle.com
When using CONFIG_RELOCATABLE, we build the kernel as a position
independent executable. The kernel then uses a little bit of relocation
code to relocate itself. That code only deals with R_PPC64_RELATIVE
relocations though. If for some reason you use assembly constructs
such as LOAD_REG_IMMEDIATE() to load the address of a symbol, you'll
generate different kinds of relocations that won't be processed properly
and bad things will happen. (We have 2 such bugs today).
The perl script tries to filter out known bad ones. It's possible
that we are missing some in the case of a weak function that nobody
implements, we'll see if we get false positive and fix it.
Signed-off-by: Tony Breeds t...@bakeyournoodle.com
Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
---
diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
index 952a396..0101e0c 100644
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
@@ -166,6 +166,17 @@ PHONY += $(BOOT_TARGETS)
boot := arch/$(ARCH)/boot
+ifeq ($(CONFIG_RELOCATABLE),y)
+quiet_cmd_relocs_check = CALL$
+ cmd_relocs_check = perl $ $(OBJDUMP) $(obj)/vmlinux
+
+PHONY += relocs_check
+relocs_check: arch/powerpc/relocs_check.pl vmlinux
+ $(call cmd,relocs_check)
+
+zImage: relocs_check
+endif
+
$(BOOT_TARGETS): vmlinux
$(Q)$(MAKE) ARCH=ppc64 $(build)=$(boot) $(patsubst %,$(boot)/%,$@)
diff --git a/arch/powerpc/relocs_check.pl b/arch/powerpc/relocs_check.pl
new file mode 100755
index 000..215e966
--- /dev/null
+++ b/arch/powerpc/relocs_check.pl
@@ -0,0 +1,57 @@
+#!/usr/bin/perl
+
+# Copyright © 2009 IBM Corporation
+
+# 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.
+
+# This script checks the relcoations of a vmlinux for suspicious
+# relocations.
+
+use strict;
+use warnings;
+
+if ($#ARGV != 1) {
+ print $#ARGV\n;
+ die $0 [path to objdump] [path to vmlinux]\n;
+}
+
+# Have Kbuild supply the path to objdump so we handle cross compilation.
+my $objdump = shift;
+my $vmlinux = shift;
+my $bad_relocs_count = 0;
+my $bad_relocs = ;
+my $old_binutils = 0;
+
+open(FD, $objdump -R $vmlinux|) or die;
+while (FD) {
+ study $_;
+
+ # Only look at relcoation lines.
+ next if (!/\s+R_/);
+
+ # These relocations are okay
+ next if (/R_PPC64_RELATIVE/ or /R_PPC64_NONE/ or
+/R_PPC64_ADDR64\s+mach_/);
+
+ # If we see this type of relcoation it's an idication that
+ # we /may/ be using an old version of binutils.
+ if (/R_PPC64_UADDR64/) {
+ $old_binutils++;
+ }
+
+ $bad_relocs_count++;
+ $bad_relocs .= $_;
+}
+
+if ($bad_relocs_count) {
+ print WARNING: $bad_relocs_count bad relocations\n;
+ print $bad_relocs;
+}
+
+if ($old_binutils) {
+ print WARNING: You need at binutils = 2.19 to build a .
+ CONFIG_RELCOATABLE kernel\n;
+}
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
