Hang in inflate_dynamic for mpc8321
Hi All, Iam working on the new board bringup of linux ppc image on 2.6.24 using the powerpc mpc832x. I used the file system image (based on the initrd ram disk image), dtb file(generated by the dtc compiler for our mpc832x_rdb.dts) and the kernel powepc compiled. Iam facing a hang up in the booting in the call inflate_dynamic() from the gunzip() function. Initially I suspected it could be RAM issues, and I performed the simple RAM test (mtest) from the bootloader and it went through succesfully. Below is the log message observed in the system booting stuck at "checking if image is initramfs..." Log messages : - Booting image at 0020 ... Image Name: Linux-2.6.24 Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size: 808788 Bytes = 789.8 kB Load Address: Entry Point: Verifying Checksum ... OK Uncompressing Kernel Image ... OK ## Loading RAMDisk Image at 0100 ... Image Name: TESTIMAGE Image Type: PowerPC Linux RAMDisk Image (gzip compressed) Data Size: 1066209 Bytes = 1 MB Load Address: Entry Point: Verifying Checksum ... OK Booting using the fdt at 0x40 Loading Ramdisk to 03ea, end 03fa44e1 ... OK Using MPC832x RDB machine description Linux version 2.6.24 (t...@test-desktop) (gcc version 4.2.1 (Sourcery G++ Lite 4.2-82)) #39 Fri Sep 4 13:04:50 IST 2009 Found initrd at 0xc3ea:0xc3fa44e1 console [udbg0] enabled setup_arch: bootmem mpc832x_rdb_setup_arch() arch: exit Zone PFN ranges: DMA 0 -> 16384 Normal 16384 -> 16384 Movable zone start PFN for each node early_node_map[1] active PFN ranges 0: 0 -> 16384 Built 1 zonelists in Zone order, mobility grouping on. Total pages: 16256 Kernel command line: root=/dev/ram ramdisk_size=20 rw ip=10.0.0.2:10 .0.0.1:10.0.0.1:255.0.0.0:Test:eth1:off console=t tyS0,115200 IPIC (128 IRQ sources) at fdefd700 PID hash table entries: 256 (order: 8, 1024 bytes) clocksource: timebase mult[781] shift[22] registered Dentry cache hash table entries: 8192 (order: 3, 32768 bytes) Inode-cache hash table entries: 4096 (order: 2, 16384 bytes) Memory: 62068k/65536k available (1592k kernel code, 3400k reserved, 88k data, 60k bss, 112k init) Mount-cache hash table entries: 512 SCSI subsystem initialized checking if image is initramfs... Please let me know what could be the problem. Thanks in advance. Regards, kumar ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Driver for using MPC8572's eTSEC1&2 in 16b encoded FIFO Mode?
On Sep 15, 2009, at 1:37 PM, Christopher Best wrote: On the MPC8572, eTSEC1 and eTSEC2 can be configured to jointly operate in 16-bit encoded FIFO mode. Is there currently a Linux driver for interfacing with this FIFO mode? Not that I'm aware of. You should be able to modify drivers/net/ gianfar.c for this purpose. - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/5] dynamic logical partitioning infrastructure
On Fri, 2009-09-11 at 16:10 -0500, Nathan Fontenot wrote:
> This patch provides the kernel DLPAR infrastructure in a new filed named
> dlpar.c. The functionality provided is for acquiring and releasing a
> resource from firmware and the parsing of information returned from the
> ibm,configure-connector rtas call. Additionally this exports the
> pSeries reconfiguration notifier chain so that it can be invoked when
> device tree updates are made.
>
> Signed-off-by: Nathan Fontenot
> ---
>
> Index: powerpc/arch/powerpc/platforms/pseries/dlpar.c
> ===
> --- /dev/null 1970-01-01 00:00:00.0 +
> +++ powerpc/arch/powerpc/platforms/pseries/dlpar.c2009-09-11
> 12:51:52.0 -0500
> @@ -0,0 +1,416 @@
> +/*
> + * dlpar.c - support for dynamic reconfiguration (including PCI
> + * Hotplug and Dynamic Logical Partitioning on RPA platforms).
> + *
> + * Copyright (C) 2009 Nathan Fontenot
> + * Copyright (C) 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 version
> + * 2 as published by the Free Software Foundation.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define CFG_CONN_WORK_SIZE 4096
> +static char workarea[CFG_CONN_WORK_SIZE];
> +spinlock_t workarea_lock;
> +
> +static struct property *parse_cc_property(char *workarea)
> +{
> + struct property *prop;
> + u32 *work_ints;
> + char *name;
> + char *value;
> +
> + prop = kzalloc(sizeof(*prop), GFP_KERNEL);
> + if (!prop)
> + return NULL;
> +
> + work_ints = (u32 *)workarea;
> + name = workarea + work_ints[2];
> + prop->name = kzalloc(strlen(name) + 1, GFP_KERNEL);
> + if (!prop->name) {
> + kfree(prop);
> + return NULL;
> + }
> +
> + strcpy(prop->name, name);
> +
> + prop->length = work_ints[3];
> + value = workarea + work_ints[4];
> + prop->value = kzalloc(prop->length, GFP_KERNEL);
The use of work_ints is a bit opaque, it might be clearer if you define
a struct, something like:
struct cc_prop {
u32 ?;
u32 ?;
u32 name_offset;
u32 length;
u32 value_offset;
};
cc = (struct cc_prop *)workarea;
name = workarea + cc->name_offset;
..
prop->length = cc->length;
value = workarea + cc->value_offset;
etc.
Also I don't see any checking of the offsets into workarea (for name &
value), vs the size of workarea.
cheers
signature.asc
Description: This is a digitally signed message part
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [git pull] Please pull powerpc.git next branch
On Tue, 2009-09-15 at 14:09 -0700, Geoff Levand wrote: > Hi Ben, > > On 09/11/2009 12:17 AM, Benjamin Herrenschmidt wrote: > > This is the powerpc batch for 2.6.32. > > Will we ever get this one in... > > http://lists.ozlabs.org/pipermail/linuxppc-dev/2009-June/073567.html I thought it was in. It's marked as "Not Applicable" in patchwork, possibly because Ben thought you were going to take it. I've marked it as new, so it should get picked up or NAK'ed by Ben. cheers signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] USB: Add support for Xilinx USB host controller
Add bus glue driver for Xilinx USB host controller. The controller can be
configured as HS only or HS/FS hybrid. The driver uses the device tree file
to configure the driver according to the setting in the hardware system.
This driver has been tested with usbtest using the NET2280 PCI card.
Signed-off-by: Julie Zhu
---
drivers/usb/host/Kconfig | 15 ++-
drivers/usb/host/ehci-hcd.c |5 +
drivers/usb/host/ehci-xilinx-of.c | 303 +
3 files changed, 321 insertions(+), 2 deletions(-)
create mode 100644 drivers/usb/host/ehci-xilinx-of.c
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 1a920c7..95e4689 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -90,14 +90,25 @@ config USB_EHCI_TT_NEWSCHED
config USB_EHCI_BIG_ENDIAN_MMIO
bool
- depends on USB_EHCI_HCD && (PPC_CELLEB || PPC_PS3 || 440EPX ||
ARCH_IXP4XX)
+ depends on USB_EHCI_HCD && (PPC_CELLEB || PPC_PS3 || 440EPX ||
ARCH_IXP4XX || XPS_USB_HCD_XILINX)
default y
config USB_EHCI_BIG_ENDIAN_DESC
bool
- depends on USB_EHCI_HCD && (440EPX || ARCH_IXP4XX)
+ depends on USB_EHCI_HCD && (440EPX || ARCH_IXP4XX || XPS_USB_HCD_XILINX)
default y
+config XPS_USB_HCD_XILINX
+ bool "Use Xilinx usb host EHCI controller core"
+ depends on USB_EHCI_HCD && (PPC32 || MICROBLAZE)
+ select USB_EHCI_BIG_ENDIAN_DESC
+ select USB_EHCI_BIG_ENDIAN_MMIO
+ ---help---
+ Xilinx xps USB host controller core is EHCI compilant and has
+ transaction translator built-in. It can be configured to either
+ support both high speed and full speed devices, or high speed
+ devices only.
+
config USB_EHCI_FSL
bool "Support for Freescale on-chip EHCI USB controller"
depends on USB_EHCI_HCD && FSL_SOC
diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
index 11c627c..7672624 100644
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
@@ -1107,6 +1107,11 @@ MODULE_LICENSE ("GPL");
#define OF_PLATFORM_DRIVER ehci_hcd_ppc_of_driver
#endif
+#ifdef CONFIG_XPS_USB_HCD_XILINX
+#include "ehci-xilinx-of.c"
+#define OF_PLATFORM_DRIVER ehci_hcd_xilinx_of_driver
+#endif
+
#ifdef CONFIG_PLAT_ORION
#include "ehci-orion.c"
#definePLATFORM_DRIVER ehci_orion_driver
diff --git a/drivers/usb/host/ehci-xilinx-of.c
b/drivers/usb/host/ehci-xilinx-of.c
new file mode 100644
index 000..58e1f14
--- /dev/null
+++ b/drivers/usb/host/ehci-xilinx-of.c
@@ -0,0 +1,303 @@
+/*
+ * EHCI HCD (Host Controller Driver) for USB.
+ *
+ * Bus Glue for Xilinx EHCI core on the of_platform bus
+ *
+ * Copyright (c) 2009 Xilinx, Inc.
+ *
+ * Based on "ehci-ppc-of.c" by Valentine Barshak
+ * and "ehci-ppc-soc.c" by Stefan Roese
+ * and "ohci-ppc-of.c" by Sylvain Munaut
+ *
+ * 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 program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
+ * or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
+ * for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software Foundation,
+ * Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ *
+ */
+
+#include
+
+#include
+#include
+
+/**
+ * ehci_xilinx_of_setup - Initialize the device for ehci_reset()
+ * @hcd: Pointer to the usb_hcd device to which the host controller bound
+ *
+ * called during probe() after chip reset completes.
+ */
+static int ehci_xilinx_of_setup(struct usb_hcd *hcd)
+{
+ struct ehci_hcd *ehci = hcd_to_ehci(hcd);
+ int retval;
+
+ retval = ehci_halt(ehci);
+ if (retval)
+ return retval;
+
+ retval = ehci_init(hcd);
+ if (retval)
+ return retval;
+
+ ehci->sbrn = 0x20;
+
+ return ehci_reset(ehci);
+}
+
+/**
+ * ehci_xilinx_port_handed_over - hand the port out if failed to enable it
+ * @hcd: Pointer to the usb_hcd device to which the host controller bound
+ * @portnum:Port number to which the device is attached.
+ *
+ * This function is used as a place to tell the user that the Xilinx USB host
+ * controller does support LS devices. And in an HS only configuration, it
+ * does not support FS devices neither. It is hoped that this can help a
+ * confused user.
+ *
+ * There are cases when the host controller fails to enable the port due to,
+ * for example, insufficient power that can be supplied to the device from
+ * the USB bus. In those cases, the messages printed here are not helpful.
+ */
+static i
Hang in inflate_dynamic() mpc8321
Hi All, Iam working on the new board bringup of linux ppc image on 2.6.24 using the powerpc mpc832x. I used the file system image (based on the initrd ram disk image), dtb file(generated by the dtc compiler for our mpc832x_rdb.dts) and the kernel powepc compiled. Iam facing a hang up in the booting in the call inflate_dynamic() from the gunzip() function. Initially I suspected it could be RAM issues, and I performed the simple RAM test (mtest) from the bootloader and it went through succesfully. Below is the log message observed in the system booting stuck at "checking if image is initramfs..." Log messages : - Booting image at 0020 ... Image Name: Linux-2.6.24 Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size: 808788 Bytes = 789.8 kB Load Address: Entry Point: Verifying Checksum ... OK Uncompressing Kernel Image ... OK ## Loading RAMDisk Image at 0100 ... Image Name: TESTIMAGE Image Type: PowerPC Linux RAMDisk Image (gzip compressed) Data Size: 1066209 Bytes = 1 MB Load Address: Entry Point: Verifying Checksum ... OK Booting using the fdt at 0x40 Loading Ramdisk to 03ea, end 03fa44e1 ... OK Using MPC832x RDB machine description Linux version 2.6.24 (t...@test-desktop) (gcc version 4.2.1 (Sourcery G++ Lite 4.2-82)) #39 Fri Sep 4 13:04:50 IST 2009 Found initrd at 0xc3ea:0xc3fa44e1 console [udbg0] enabled setup_arch: bootmem mpc832x_rdb_setup_arch() arch: exit Zone PFN ranges: DMA 0 -> 16384 Normal 16384 -> 16384 Movable zone start PFN for each node early_node_map[1] active PFN ranges 0: 0 -> 16384 Built 1 zonelists in Zone order, mobility grouping on. Total pages: 16256 Kernel command line: root=/dev/ram ramdisk_size=20 rw ip=10.0.0.2:10 .0.0.1:10.0.0.1:255.0.0.0:Test:eth1:off console=t tyS0,115200 IPIC (128 IRQ sources) at fdefd700 PID hash table entries: 256 (order: 8, 1024 bytes) clocksource: timebase mult[781] shift[22] registered Dentry cache hash table entries: 8192 (order: 3, 32768 bytes) Inode-cache hash table entries: 4096 (order: 2, 16384 bytes) Memory: 62068k/65536k available (1592k kernel code, 3400k reserved, 88k data, 60k bss, 112k init) Mount-cache hash table entries: 512 SCSI subsystem initialized checking if image is initramfs... Please let me know what could be the problem. Thanks in advance. Regards, kumar ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [git pull] Please pull powerpc.git next branch
On Wed, 2009-09-16 at 07:51 +1000, Benjamin Herrenschmidt wrote: > On Tue, 2009-09-15 at 09:53 -0700, Linus Torvalds wrote: > > It got a conflict with the AGP merge, but I fixed it up in what _seemed_ > > to be the obvious manner. But somebody should check out the resulting > > drivers/char/agp/uninorth-agp.c file. > > Thanks. > > Michel, can you dbl check it ? Looks good to me, thanks. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] [SCSI] mpt fusion: Fix 32 bit platforms with 64 bit resources.
From: Pravin Bathija
Powerpc 44x uses 36 bit real address while the real address defined
in MPT Fusion driver is of type 32 bit. This causes ioremap to fail and driver
fails to initialize. This fix changes the data types representing the real
address from unsigned long 32-bit types to "phys_addr_t" which is 64-bit. The
driver has been tested, the disks get discovered correctly and can do IO. Also,
replaced phys_addr_t with resource_size_t as suggested by Ben.
Signed-off-by: Pravin Bathija
Acked-by: Feng Kan
Acked-by: Prodyut Hazarika
Acked-by: Loc Ho
Acked-by: Tirumala Reddy Marri
Acked-by: Victor Gallardo
---
drivers/message/fusion/mptbase.c | 34 +-
drivers/message/fusion/mptbase.h |5 +++--
2 files changed, 28 insertions(+), 11 deletions(-)
diff --git a/drivers/message/fusion/mptbase.c b/drivers/message/fusion/mptbase.c
index 5d496a9..e296f2e 100644
--- a/drivers/message/fusion/mptbase.c
+++ b/drivers/message/fusion/mptbase.c
@@ -1510,11 +1510,12 @@ static int
mpt_mapresources(MPT_ADAPTER *ioc)
{
u8 __iomem *mem;
+ u8 __iomem *port;
int ii;
- unsigned longmem_phys;
- unsigned longport;
- u32 msize;
- u32 psize;
+ resource_size_t mem_phys;
+ resource_size_t port_phys;
+ resource_size_t msize;
+ resource_size_t psize;
u8 revision;
int r = -ENODEV;
struct pci_dev *pdev;
@@ -1552,13 +1553,13 @@ mpt_mapresources(MPT_ADAPTER *ioc)
}
mem_phys = msize = 0;
- port = psize = 0;
+ port_phys = psize = 0;
for (ii = 0; ii < DEVICE_COUNT_RESOURCE; ii++) {
if (pci_resource_flags(pdev, ii) & PCI_BASE_ADDRESS_SPACE_IO) {
if (psize)
continue;
/* Get I/O space! */
- port = pci_resource_start(pdev, ii);
+ port_phys = pci_resource_start(pdev, ii);
psize = pci_resource_len(pdev, ii);
} else {
if (msize)
@@ -1580,14 +1581,23 @@ mpt_mapresources(MPT_ADAPTER *ioc)
return -EINVAL;
}
ioc->memmap = mem;
- dinitprintk(ioc, printk(MYIOC_s_INFO_FMT "mem = %p, mem_phys = %lx\n",
- ioc->name, mem, mem_phys));
+ dinitprintk(ioc, printk(MYIOC_s_INFO_FMT "mem = %p, mem_phys = %llx\n",
+ ioc->name, mem, (u64)mem_phys));
ioc->mem_phys = mem_phys;
ioc->chip = (SYSIF_REGS __iomem *)mem;
/* Save Port IO values in case we need to do downloadboot */
- ioc->pio_mem_phys = port;
+ port = ioremap(port_phys, psize);
+ if (port == NULL) {
+ printk(MYIOC_s_ERR_FMT " : ERROR - Unable to map adapter"
+ " port !\n", ioc->name);
+ return -EINVAL;
+ }
+ ioc->portmap = port;
+ dinitprintk(ioc, printk(MYIOC_s_INFO_FMT "port=%p, port_phys=%llx\n",
+ ioc->name, port, (u64)port_phys));
+ ioc->pio_mem_phys = port_phys;
ioc->pio_chip = (SYSIF_REGS __iomem *)port;
return 0;
@@ -1822,6 +1832,7 @@ mpt_attach(struct pci_dev *pdev, const struct
pci_device_id *id)
if (ioc->alt_ioc)
ioc->alt_ioc->alt_ioc = NULL;
iounmap(ioc->memmap);
+ iounmap(ioc->portmap);
if (r != -5)
pci_release_selected_regions(pdev, ioc->bars);
@@ -2583,6 +2594,11 @@ mpt_adapter_dispose(MPT_ADAPTER *ioc)
ioc->memmap = NULL;
}
+ if (ioc->portmap != NULL) {
+ iounmap(ioc->portmap);
+ ioc->portmap = NULL;
+ }
+
pci_disable_device(ioc->pcidev);
pci_release_selected_regions(ioc->pcidev, ioc->bars);
diff --git a/drivers/message/fusion/mptbase.h b/drivers/message/fusion/mptbase.h
index b3e981d..7091f13 100644
--- a/drivers/message/fusion/mptbase.h
+++ b/drivers/message/fusion/mptbase.h
@@ -584,8 +584,8 @@ typedef struct _MPT_ADAPTER
SYSIF_REGS __iomem *chip; /* == c8817000 (mmap) */
SYSIF_REGS __iomem *pio_chip; /* Programmed IO (downloadboot)
*/
u8 bus_type;
- u32 mem_phys; /* == f402 (mmap) */
- u32 pio_mem_phys; /* Programmed IO (downloadboot)
*/
+ resource_size_t mem_phys; /* == f402 (mmap) */
+ resource_size_t pio_mem_phys; /* Programmed IO (downloadboot)
*/
int mem_size; /* mmap memory size */
int number_of_buses;
int devices_per_bus;
@@ -635,6 +635,7 @@ typedef struct _MPT_ADAPTER
int bars; /* bitmask
Re: [git pull] Please pull powerpc.git next branch
On Tue, 2009-09-15 at 09:53 -0700, Linus Torvalds wrote: > It got a conflict with the AGP merge, but I fixed it up in what _seemed_ > to be the obvious manner. But somebody should check out the resulting > drivers/char/agp/uninorth-agp.c file. Thanks. Michel, can you dbl check it ? Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: RFC: delete UART current-speed from 4xx DTS?
On Tue, 2009-09-15 at 11:32 -0400, Josh Boyer wrote: > On Tue, Sep 15, 2009 at 10:31:36AM -0400, Paul Gortmaker wrote: > >One of the guys here was getting a messed up console on a bamboo board > >(on linux boot), which he traced to the fact that the default dts has a > >9600 baudrate coded into it (board was running 115k2, not 9600). Either > >deleting the line, or replacing the 9600 with zero fixed the problem. > > Once booted, was there a valid current-speed property in /proc/device-tree > for the serial node? I'm curious if U-Boot created it, or if the kernel > just used whatever baud was present already. > > When I did the bamboo port a while ago, I recall having issues with either > a missing clock-frequency or current-speed (or both perhaps) and the > bootloader > on the board was the original PIBS. It might have been an issue with PIBS > but I'm guessing the rest of the 4xx boards copied from either Ebony or > Bamboo in their ports and hence contain that property. I think I recently added code to legacy_serial probe the speed from the HW if the property is absent, which should help. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 7/7] powerpc/83xx: Add power management support for MPC83xx QE boards
Simply add power management controller nodes and sleep properties.
Signed-off-by: Anton Vorontsov
Acked-by: Scott Wood
---
arch/powerpc/boot/dts/kmeter1.dts |7 +++
arch/powerpc/boot/dts/mpc832x_mds.dts |9 +
arch/powerpc/boot/dts/mpc832x_rdb.dts |9 +
arch/powerpc/boot/dts/mpc836x_mds.dts |9 +
arch/powerpc/boot/dts/mpc836x_rdk.dts |9 +
5 files changed, 43 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/dts/kmeter1.dts
b/arch/powerpc/boot/dts/kmeter1.dts
index 167044f..65b8b4f 100644
--- a/arch/powerpc/boot/dts/kmeter1.dts
+++ b/arch/powerpc/boot/dts/kmeter1.dts
@@ -59,6 +59,13 @@
reg = <0xe000 0x0200>;
bus-frequency = <0>;/* Filled in by U-Boot */
+ pmc: po...@b00 {
+ compatible = "fsl,mpc8360-pmc", "fsl,mpc8349-pmc";
+ reg = <0xb00 0x100 0xa00 0x100>;
+ interrupts = <80 0x8>;
+ interrupt-parent = <&ipic>;
+ };
+
i...@3000 {
#address-cells = <1>;
#size-cells = <0>;
diff --git a/arch/powerpc/boot/dts/mpc832x_mds.dts
b/arch/powerpc/boot/dts/mpc832x_mds.dts
index 436c9c6..05ad8c9 100644
--- a/arch/powerpc/boot/dts/mpc832x_mds.dts
+++ b/arch/powerpc/boot/dts/mpc832x_mds.dts
@@ -79,6 +79,13 @@
reg = <0x200 0x100>;
};
+ pmc: po...@b00 {
+ compatible = "fsl,mpc8323-pmc", "fsl,mpc8349-pmc";
+ reg = <0xb00 0x100 0xa00 0x100>;
+ interrupts = <80 0x8>;
+ interrupt-parent = <&ipic>;
+ };
+
i...@3000 {
#address-cells = <1>;
#size-cells = <0>;
@@ -163,6 +170,7 @@
fsl,channel-fifo-len = <24>;
fsl,exec-units-mask = <0x4c>;
fsl,descriptor-types-mask = <0x0122003f>;
+ sleep = <&pmc 0x0300>;
};
ipic: p...@700 {
@@ -428,5 +436,6 @@
0xe0008300 0x8>; /* config space access
registers */
compatible = "fsl,mpc8349-pci";
device_type = "pci";
+ sleep = <&pmc 0x0001>;
};
};
diff --git a/arch/powerpc/boot/dts/mpc832x_rdb.dts
b/arch/powerpc/boot/dts/mpc832x_rdb.dts
index 9a0952f..f4fadb2 100644
--- a/arch/powerpc/boot/dts/mpc832x_rdb.dts
+++ b/arch/powerpc/boot/dts/mpc832x_rdb.dts
@@ -62,6 +62,13 @@
reg = <0x200 0x100>;
};
+ pmc: po...@b00 {
+ compatible = "fsl,mpc8323-pmc", "fsl,mpc8349-pmc";
+ reg = <0xb00 0x100 0xa00 0x100>;
+ interrupts = <80 0x8>;
+ interrupt-parent = <&ipic>;
+ };
+
i...@3000 {
#address-cells = <1>;
#size-cells = <0>;
@@ -141,6 +148,7 @@
fsl,channel-fifo-len = <24>;
fsl,exec-units-mask = <0x4c>;
fsl,descriptor-types-mask = <0x0122003f>;
+ sleep = <&pmc 0x0300>;
};
ipic:p...@700 {
@@ -360,5 +368,6 @@
0xe0008300 0x8>; /* config space access
registers */
compatible = "fsl,mpc8349-pci";
device_type = "pci";
+ sleep = <&pmc 0x0001>;
};
};
diff --git a/arch/powerpc/boot/dts/mpc836x_mds.dts
b/arch/powerpc/boot/dts/mpc836x_mds.dts
index 39ff4c8..45cfa1c 100644
--- a/arch/powerpc/boot/dts/mpc836x_mds.dts
+++ b/arch/powerpc/boot/dts/mpc836x_mds.dts
@@ -99,6 +99,13 @@
reg = <0x200 0x100>;
};
+ pmc: po...@b00 {
+ compatible = "fsl,mpc8360-pmc", "fsl,mpc8349-pmc";
+ reg = <0xb00 0x100 0xa00 0x100>;
+ interrupts = <80 0x8>;
+ interrupt-parent = <&ipic>;
+ };
+
i...@3000 {
#address-cells = <1>;
#size-cells = <0>;
@@ -194,6 +201,7 @@
fsl,channel-fifo-len = <24>;
fsl,exec-units-mask = <0x7e>;
fsl,descriptor-types-mask = <0x01010ebf>;
+ sleep = <&pmc 0x0300>;
};
ipic: p...@700 {
@@ -470,5 +478,6 @@
0xe0008300 0x8>; /* config space access
registers */
compatible = "fsl,mpc8349-pci";
device_type = "pci";
+ sleep = <&pmc 0x0001>;
};
};
diff --git a/arch/powerpc/boot/dts/mpc836x_rdk.dts
b/arch/powerpc/boot/dts/mpc836x_r
[PATCH 6/7] powerpc/86xx: Add power management support for MPC8610HPCD boards
This patch adds needed nodes and properties to support suspend/resume
on the MPC8610HPCD boards.
There is a dedicated switch (SW9) that is used to wake up the boards.
By default the SW9 button is routed to IRQ8, but could be re-routed
(via PIXIS) to sreset.
With 'no_console_suspend' kernel command line argument specified, the
board is also able to wakeup upon serial port input.
Signed-off-by: Anton Vorontsov
Acked-by: Scott Wood [dts]
---
Documentation/powerpc/dts-bindings/fsl/board.txt |4 ++
arch/powerpc/boot/dts/mpc8610_hpcd.dts | 26
arch/powerpc/platforms/86xx/mpc8610_hpcd.c | 48 --
3 files changed, 74 insertions(+), 4 deletions(-)
diff --git a/Documentation/powerpc/dts-bindings/fsl/board.txt
b/Documentation/powerpc/dts-bindings/fsl/board.txt
index e8b5bc2..39e9415 100644
--- a/Documentation/powerpc/dts-bindings/fsl/board.txt
+++ b/Documentation/powerpc/dts-bindings/fsl/board.txt
@@ -20,12 +20,16 @@ Required properities:
- compatible : should be "fsl,fpga-pixis".
- reg : should contain the address and the length of the FPPGA register
set.
+- interrupt-parent: should specify phandle for the interrupt controller.
+- interrupts : should specify event (wakeup) IRQ.
Example (MPC8610HPCD):
board-cont...@e800 {
compatible = "fsl,fpga-pixis";
reg = <0xe800 32>;
+ interrupt-parent = <&mpic>;
+ interrupts = <8 8>;
};
* Freescale BCSR GPIO banks
diff --git a/arch/powerpc/boot/dts/mpc8610_hpcd.dts
b/arch/powerpc/boot/dts/mpc8610_hpcd.dts
index f468d21..9535ce6 100644
--- a/arch/powerpc/boot/dts/mpc8610_hpcd.dts
+++ b/arch/powerpc/boot/dts/mpc8610_hpcd.dts
@@ -35,6 +35,8 @@
i-cache-line-size = <32>;
d-cache-size = <32768>; // L1
i-cache-size = <32768>; // L1
+ sleep = <&pmc 0x8000 0 // core
+&pmc 0x4000 0>;// timebase
timebase-frequency = <0>; // From uboot
bus-frequency = <0>;// From uboot
clock-frequency = <0>; // From uboot
@@ -60,6 +62,7 @@
5 0 0xe848 0x8000
6 0 0xe84c 0x8000
3 0 0xe800 0x0020>;
+ sleep = <&pmc 0x0800 0>;
fl...@0,0 {
compatible = "cfi-flash";
@@ -105,6 +108,8 @@
compatible = "fsl,fpga-pixis";
reg = <3 0 0x20>;
ranges = <0 3 0 0x20>;
+ interrupt-parent = <&mpic>;
+ interrupts = <8 8>;
sdcsr_pio: gpio-control...@a {
#gpio-cells = <2>;
@@ -163,6 +168,7 @@
reg = <0x3100 0x100>;
interrupts = <43 2>;
interrupt-parent = <&mpic>;
+ sleep = <&pmc 0x0004 0>;
dfsrr;
};
@@ -174,6 +180,7 @@
clock-frequency = <0>;
interrupts = <42 2>;
interrupt-parent = <&mpic>;
+ sleep = <&pmc 0x0002 0>;
};
serial1: ser...@4600 {
@@ -184,6 +191,7 @@
clock-frequency = <0>;
interrupts = <42 2>;
interrupt-parent = <&mpic>;
+ sleep = <&pmc 0x0008 0>;
};
s...@7000 {
@@ -196,6 +204,7 @@
interrupt-parent = <&mpic>;
mode = "cpu";
gpios = <&sdcsr_pio 7 0>;
+ sleep = <&pmc 0x0800 0>;
mmc-s...@0 {
compatible = "fsl,mpc8610hpcd-mmc-slot",
@@ -213,6 +222,7 @@
reg = <0x2c000 100>;
interrupts = <72 2>;
interrupt-parent = <&mpic>;
+ sleep = <&pmc 0x0400 0>;
};
mpic: interrupt-control...@4 {
@@ -241,9 +251,18 @@
};
global-utilit...@e {
+ #address-cells = <1>;
+ #size-cells = <1>;
compatible = "fsl,mpc8610-guts";
reg = <0xe 0x1000>;
+ ranges = <0 0xe 0x1000>;
fsl,has-rstcr;
+
+ pmc: po...@70 {
+ compatible = "fsl,mpc8610-pmc",
+"fsl,mpc8641d-pmc";
+ reg = <0x70 0x20>;
+ };
[PATCH 5/7] powerpc/85xx: Add power management support for MPC85xxMDS boards
- Add power management controller nodes;
- Add interrupts for RTC nodes, the RTC interrupt may be used as a
wakeup source;
- Add sleep properties and sleep-nexus nodes.
Signed-off-by: Anton Vorontsov
Acked-by: Scott Wood
---
arch/powerpc/boot/dts/mpc8568mds.dts | 119 +++--
arch/powerpc/boot/dts/mpc8569mds.dts | 111 ++-
arch/powerpc/platforms/85xx/mpc85xx_mds.c |1 +
3 files changed, 153 insertions(+), 78 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc8568mds.dts
b/arch/powerpc/boot/dts/mpc8568mds.dts
index 00c2bbd..6d892ba 100644
--- a/arch/powerpc/boot/dts/mpc8568mds.dts
+++ b/arch/powerpc/boot/dts/mpc8568mds.dts
@@ -40,6 +40,8 @@
i-cache-line-size = <32>; // 32 bytes
d-cache-size = <0x8000>;// L1, 32K
i-cache-size = <0x8000>;// L1, 32K
+ sleep = <&pmc 0x8000// core
+&pmc 0x4000>; // timebase
timebase-frequency = <0>;
bus-frequency = <0>;
clock-frequency = <0>;
@@ -94,31 +96,41 @@
interrupts = <16 2>;
};
- i...@3000 {
+ i2c-sleep-nexus {
#address-cells = <1>;
- #size-cells = <0>;
- cell-index = <0>;
- compatible = "fsl-i2c";
- reg = <0x3000 0x100>;
- interrupts = <43 2>;
- interrupt-parent = <&mpic>;
- dfsrr;
+ #size-cells = <1>;
+ compatible = "simple-bus";
+ sleep = <&pmc 0x0004>;
+ ranges;
- r...@68 {
- compatible = "dallas,ds1374";
- reg = <0x68>;
+ i...@3000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ cell-index = <0>;
+ compatible = "fsl-i2c";
+ reg = <0x3000 0x100>;
+ interrupts = <43 2>;
+ interrupt-parent = <&mpic>;
+ dfsrr;
+
+ r...@68 {
+ compatible = "dallas,ds1374";
+ reg = <0x68>;
+ interrupts = <3 1>;
+ interrupt-parent = <&mpic>;
+ };
};
- };
- i...@3100 {
- #address-cells = <1>;
- #size-cells = <0>;
- cell-index = <1>;
- compatible = "fsl-i2c";
- reg = <0x3100 0x100>;
- interrupts = <43 2>;
- interrupt-parent = <&mpic>;
- dfsrr;
+ i...@3100 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ cell-index = <1>;
+ compatible = "fsl-i2c";
+ reg = <0x3100 0x100>;
+ interrupts = <43 2>;
+ interrupt-parent = <&mpic>;
+ dfsrr;
+ };
};
d...@21300 {
@@ -128,6 +140,8 @@
reg = <0x21300 0x4>;
ranges = <0x0 0x21100 0x200>;
cell-index = <0>;
+ sleep = <&pmc 0x0400>;
+
dma-chan...@0 {
compatible = "fsl,mpc8568-dma-channel",
"fsl,eloplus-dma-channel";
@@ -176,6 +190,7 @@
interrupt-parent = <&mpic>;
tbi-handle = <&tbi0>;
phy-handle = <&phy2>;
+ sleep = <&pmc 0x0080>;
m...@520 {
#address-cells = <1>;
@@ -228,6 +243,7 @@
interrupt-parent = <&mpic>;
tbi-handle = <&tbi1>;
phy-handle = <&phy3>;
+ sleep = <&pmc 0x0040>;
m...@520 {
#address-cells = <1>;
@@ -242,30 +258,47 @@
};
};
- serial0: ser...@4500 {
- cell-index = <0>;
- device_type = "serial";
-
[PATCH 4/7] powerpc/85xx/86xx: Add suspend/resume support
This patch adds suspend/resume support for MPC8540 and MPC8641D-
compatible CPUs. To reach sleep state, we just write the SLP bit
into the PM control and status register.
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
Acked-by: Scott Wood
---
arch/powerpc/Kconfig | 11 +-
arch/powerpc/sysdev/Makefile |1 +
arch/powerpc/sysdev/fsl_pmc.c | 88 +
3 files changed, 99 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
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
+
config 4xx_SOC
bool
diff --git a/arch/powerpc/sysdev/Makefile b/arch/powerpc/sysdev/Makefile
index 9d4b174..5642924 100644
--- a/arch/powerpc/sysdev/Makefile
+++ b/arch/powerpc/sysdev/Makefile
@@ -16,6 +16,7 @@ obj-$(CONFIG_U3_DART) += dart_iommu.o
obj-$(CONFIG_MMIO_NVRAM) += mmio_nvram.o
obj-$(CONFIG_FSL_SOC) += fsl_soc.o
obj-$(CONFIG_FSL_PCI) += fsl_pci.o $(fsl-msi-obj-y)
+obj-$(CONFIG_FSL_PMC) += fsl_pmc.o
obj-$(CONFIG_FSL_LBC) += fsl_lbc.o
obj-$(CONFIG_FSL_GTM) += fsl_gtm.o
obj-$(CONFIG_MPC8xxx_GPIO) += mpc8xxx_gpio.o
diff --git a/arch/powerpc/sysdev/fsl_pmc.c b/arch/powerpc/sysdev/fsl_pmc.c
new file mode 100644
index 000..a7635a9
--- /dev/null
+++ b/arch/powerpc/sysdev/fsl_pmc.c
@@ -0,0 +1,88 @@
+/*
+ * Suspend/resume support
+ *
+ * Copyright 2009 MontaVista Software, Inc.
+ *
+ * Author: Anton Vorontsov
+ *
+ * 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
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct pmc_regs {
+ __be32 devdisr;
+ __be32 devdisr2;
+ __be32 :32;
+ __be32 :32;
+ __be32 pmcsr;
+#define PMCSR_SLP (1 << 17)
+};
+
+static struct device *pmc_dev;
+static struct pmc_regs __iomem *pmc_regs;
+
+static int pmc_suspend_enter(suspend_state_t state)
+{
+ int ret;
+
+ setbits32(&pmc_regs->pmcsr, PMCSR_SLP);
+ /* At this point, the CPU is asleep. */
+
+ /* Upon resume, wait for SLP bit to be clear. */
+ ret = spin_event_timeout((in_be32(&pmc_regs->pmcsr) & PMCSR_SLP) == 0,
+1, 10) ? 0 : -ETIMEDOUT;
+ if (ret)
+ dev_err(pmc_dev, "tired waiting for SLP bit to clear\n");
+ return ret;
+}
+
+static int pmc_suspend_valid(suspend_state_t state)
+{
+ if (state != PM_SUSPEND_STANDBY)
+ return 0;
+ return 1;
+}
+
+static struct platform_suspend_ops pmc_suspend_ops = {
+ .valid = pmc_suspend_valid,
+ .enter = pmc_suspend_enter,
+};
+
+static int pmc_probe(struct of_device *ofdev, const struct of_device_id *id)
+{
+ pmc_regs = of_iomap(ofdev->node, 0);
+ if (!pmc_regs)
+ return -ENOMEM;
+
+ pmc_dev = &ofdev->dev;
+ suspend_set_ops(&pmc_suspend_ops);
+ return 0;
+}
+
+static const struct of_device_id pmc_ids[] = {
+ { .compatible = "fsl,mpc8548-pmc", },
+ { .compatible = "fsl,mpc8641d-pmc", },
+ { },
+};
+
+static struct of_platform_driver pmc_driver = {
+ .driver.name = "fsl-pmc",
+ .match_table = pmc_ids,
+ .probe = pmc_probe,
+};
+
+static int __init pmc_init(void)
+{
+ return of_register_platform_driver(&pmc_driver);
+}
+device_initcall(pmc_init);
--
1.6.3.3
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 3/7] powerpc/qe: Implement QE driver for handling resume on MPC85xx
So far the driver is used to reset QE upon resume, which is needed on
85xx. Later we can move some QE initialization steps into probe().
Signed-off-by: Anton Vorontsov
---
arch/powerpc/sysdev/qe_lib/qe.c | 34 ++
1 files changed, 34 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/sysdev/qe_lib/qe.c b/arch/powerpc/sysdev/qe_lib/qe.c
index 4eaf2a9..149393c 100644
--- a/arch/powerpc/sysdev/qe_lib/qe.c
+++ b/arch/powerpc/sysdev/qe_lib/qe.c
@@ -27,6 +27,8 @@
#include
#include
#include
+#include
+#include
#include
#include
#include
@@ -647,3 +649,35 @@ unsigned int qe_get_num_of_snums(void)
return num_of_snums;
}
EXPORT_SYMBOL(qe_get_num_of_snums);
+
+#if defined(CONFIG_SUSPEND) && defined(CONFIG_PPC_85xx)
+static int qe_resume(struct of_device *ofdev)
+{
+ if (!qe_alive_during_sleep())
+ qe_reset();
+ return 0;
+}
+
+static int qe_probe(struct of_device *ofdev, const struct of_device_id *id)
+{
+ return 0;
+}
+
+static const struct of_device_id qe_ids[] = {
+ { .compatible = "fsl,qe", },
+ { },
+};
+
+static struct of_platform_driver qe_driver = {
+ .driver.name = "fsl-qe",
+ .match_table = qe_ids,
+ .probe = qe_probe,
+ .resume = qe_resume,
+};
+
+static int __init qe_drv_init(void)
+{
+ return of_register_platform_driver(&qe_driver);
+}
+device_initcall(qe_drv_init);
+#endif /* defined(CONFIG_SUSPEND) && defined(CONFIG_PPC_85xx) */
--
1.6.3.3
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 2/7] powerpc/qe: QE also shuts down on MPC8568
It appears that QE shuts down on all MPC85xx CPUs (i.e. MPC8568 and
MPC8569) and thus needs reset upon resume.
So modify qe_alive_during_sleep() to account that.
Signed-off-by: Anton Vorontsov
---
arch/powerpc/include/asm/qe.h | 23 ++-
arch/powerpc/sysdev/qe_lib/qe.c | 13 -
2 files changed, 22 insertions(+), 14 deletions(-)
diff --git a/arch/powerpc/include/asm/qe.h b/arch/powerpc/include/asm/qe.h
index fe507ff..0947b36 100644
--- a/arch/powerpc/include/asm/qe.h
+++ b/arch/powerpc/include/asm/qe.h
@@ -163,7 +163,28 @@ int qe_get_snum(void);
void qe_put_snum(u8 snum);
unsigned int qe_get_num_of_risc(void);
unsigned int qe_get_num_of_snums(void);
-int qe_alive_during_sleep(void);
+
+static inline int qe_alive_during_sleep(void)
+{
+ /*
+* MPC8568E reference manual says:
+*
+* "...power down sequence waits for all I/O interfaces to become idle.
+* In some applications this may happen eventually without actively
+* shutting down interfaces, but most likely, software will have to
+* take steps to shut down the eTSEC, QUICC Engine Block, and PCI
+* interfaces before issuing the command (either the write to the core
+* MSR[WE] as described above or writing to POWMGTCSR) to put the
+* device into sleep state."
+*
+* MPC8569E reference manual has a similar paragraph.
+*/
+#ifdef CONFIG_PPC_85xx
+ return 0;
+#else
+ return 1;
+#endif
+}
/* we actually use cpm_muram implementation, define this for convenience */
#define qe_muram_init cpm_muram_init
diff --git a/arch/powerpc/sysdev/qe_lib/qe.c b/arch/powerpc/sysdev/qe_lib/qe.c
index 1ed1a9f..4eaf2a9 100644
--- a/arch/powerpc/sysdev/qe_lib/qe.c
+++ b/arch/powerpc/sysdev/qe_lib/qe.c
@@ -65,19 +65,6 @@ static unsigned int qe_num_of_snum;
static phys_addr_t qebase = -1;
-int qe_alive_during_sleep(void)
-{
- static int ret = -1;
-
- if (ret != -1)
- return ret;
-
- ret = !of_find_compatible_node(NULL, NULL, "fsl,mpc8569-pmc");
-
- return ret;
-}
-EXPORT_SYMBOL(qe_alive_during_sleep);
-
phys_addr_t get_qe_base(void)
{
struct device_node *qe;
--
1.6.3.3
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/7] powerpc/qe: Make qe_reset() code path safe for repeated invocation
For MPC8569 CPUs we'll need to reset QE after each suspend, so make
qe_reset() code path suitable for repeated invocation, that is:
- Don't initialize rheap structures if already initialized;
- Don't allocate muram for SDMA if already allocated, just reinitialize
registers with previously allocated muram offset;
- Remove __init attributes from qe_reset() and cpm_muram_init();
Signed-off-by: Anton Vorontsov
---
arch/powerpc/include/asm/qe.h|2 +-
arch/powerpc/sysdev/cpm_common.c |5 -
arch/powerpc/sysdev/qe_lib/qe.c | 12 +++-
3 files changed, 12 insertions(+), 7 deletions(-)
diff --git a/arch/powerpc/include/asm/qe.h b/arch/powerpc/include/asm/qe.h
index 20c0b07..fe507ff 100644
--- a/arch/powerpc/include/asm/qe.h
+++ b/arch/powerpc/include/asm/qe.h
@@ -87,7 +87,7 @@ extern spinlock_t cmxgcr_lock;
/* Export QE common operations */
#ifdef CONFIG_QUICC_ENGINE
-extern void __init qe_reset(void);
+extern void qe_reset(void);
#else
static inline void qe_reset(void) {}
#endif
diff --git a/arch/powerpc/sysdev/cpm_common.c b/arch/powerpc/sysdev/cpm_common.c
index e4b6d66..9de72c9 100644
--- a/arch/powerpc/sysdev/cpm_common.c
+++ b/arch/powerpc/sysdev/cpm_common.c
@@ -72,7 +72,7 @@ static phys_addr_t muram_pbase;
/* Max address size we deal with */
#define OF_MAX_ADDR_CELLS 4
-int __init cpm_muram_init(void)
+int cpm_muram_init(void)
{
struct device_node *np;
struct resource r;
@@ -81,6 +81,9 @@ int __init cpm_muram_init(void)
int i = 0;
int ret = 0;
+ if (muram_pbase)
+ return 0;
+
spin_lock_init(&cpm_muram_lock);
/* initialize the info header */
rh_init(&cpm_muram_info, 1,
diff --git a/arch/powerpc/sysdev/qe_lib/qe.c b/arch/powerpc/sysdev/qe_lib/qe.c
index fff2701..1ed1a9f 100644
--- a/arch/powerpc/sysdev/qe_lib/qe.c
+++ b/arch/powerpc/sysdev/qe_lib/qe.c
@@ -104,7 +104,7 @@ phys_addr_t get_qe_base(void)
EXPORT_SYMBOL(get_qe_base);
-void __init qe_reset(void)
+void qe_reset(void)
{
if (qe_immr == NULL)
qe_immr = ioremap(get_qe_base(), QE_IMMAP_SIZE);
@@ -330,16 +330,18 @@ EXPORT_SYMBOL(qe_put_snum);
static int qe_sdma_init(void)
{
struct sdma __iomem *sdma = &qe_immr->sdma;
- unsigned long sdma_buf_offset;
+ static unsigned long sdma_buf_offset = (unsigned long)-ENOMEM;
if (!sdma)
return -ENODEV;
/* allocate 2 internal temporary buffers (512 bytes size each) for
* the SDMA */
- sdma_buf_offset = qe_muram_alloc(512 * 2, 4096);
- if (IS_ERR_VALUE(sdma_buf_offset))
- return -ENOMEM;
+ if (IS_ERR_VALUE(sdma_buf_offset)) {
+ sdma_buf_offset = qe_muram_alloc(512 * 2, 4096);
+ if (IS_ERR_VALUE(sdma_buf_offset))
+ return -ENOMEM;
+ }
out_be32(&sdma->sdebcr, (u32) sdma_buf_offset & QE_SDEBCR_BA_MASK);
out_be32(&sdma->sdmr, (QE_SDMR_GLB_1_MSK |
--
1.6.3.3
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v4 0/7] Suspend/resume support for some 83xx/85xx/86xx boards
On Tue, Sep 15, 2009 at 01:47:36AM +0400, Anton Vorontsov wrote: > 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. Okay... that might sound silly, but the microcode stuff isn't needed at all. While the QE really shuts down, its iram is preserved. I'm not sure why it didn't work for me before, but now it does work. Heh. Note that QE reset is still needed, it's QE microcode reload that we don't need. I was also curious if MPC8568 QE needs reset after sleep, so I unpacked the board and tested it. It needs the reset just as MPC8569. I also found a paragraph in reference manual that somewhat proves "QE turns off during sleep" behaviour. So here is a new patch set. Changes: - Removed QE stuff from fsl_pmc; - New patches added: powerpc/qe: QE also shuts down on MPC8568 powerpc/qe: Implement QE driver for handling resume on MPC85xx 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: [git pull] Please pull powerpc.git next branch
Hi Ben, On 09/11/2009 12:17 AM, Benjamin Herrenschmidt wrote: > This is the powerpc batch for 2.6.32. Will we ever get this one in... http://lists.ozlabs.org/pipermail/linuxppc-dev/2009-June/073567.html -Geoff ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: RFC: delete UART current-speed from 4xx DTS?
[Re: RFC: delete UART current-speed from 4xx DTS?] On 15/09/2009 (Tue 16:02) Josh Boyer wrote: > On Tue, Sep 15, 2009 at 03:32:05PM -0400, Paul Gortmaker wrote: > >[Re: RFC: delete UART current-speed from 4xx DTS?] On 15/09/2009 (Tue 11:32) > >Josh Boyer wrote: > > > >> On Tue, Sep 15, 2009 at 10:31:36AM -0400, Paul Gortmaker wrote: > >> >One of the guys here was getting a messed up console on a bamboo board > > > >I meant to say Yosemite board (and hence u-boot), sorry for that. It > >gives garbage up until the udbg -> ttyS0 handover, at which point the > >console=ttyS0,115200 fixes things. > > Ok. > > >> >(on linux boot), which he traced to the fact that the default dts has a > >> >9600 baudrate coded into it (board was running 115k2, not 9600). Either > >> >deleting the line, or replacing the 9600 with zero fixed the problem. > >> > >> Once booted, was there a valid current-speed property in /proc/device-tree > >> for the serial node? I'm curious if U-Boot created it, or if the kernel > >> just used whatever baud was present already. > > > >Had to go back to get this info; it turns out there is a valid prop in > >all the serial nodes (2.6.31-rc7), and hexdumping it gives 0x2580 (9600). > > Sorry, that was after you removed the property in the DTS entirely, or setting > it to 0, or just using the existing DTS as-is? I should have phrased my > question better, but I think I answered it myself already. > > In my brief test with Sequoia and Bamboo, I removed the current-speed property > entirely and once booted there was no property in the serial node, which is > what I would expect for the old version of U-Boot on these boards. The good > news is that it seems to work fine :). Yep - and if there is a node with a current-speed that differs from what u-boot (1.3.3) is actively using, that current-speed setting will take precedence for early printk and also that baud will appear in the /proc/device-tree (just to clarify on what I'd tried to convey earlier). [...] > >> It's easy enough for me to whip up a patch, and since I'll be testing > >> either > >> way I'd be happy to do that if you'd like. > > > >Sure -- the testing effort will be greater than the time to make the > >patch, so you doing coverage on all those would be great. I think I've > >probably only got easy immediate access to a PIBS/bamboo at the moment. > >We already know the yosemite is OK with the change, so that is one less > >to test. > > OK, sounds good. I'll do some more testing over the next few days and post > a patch. Thanks for bringing this to my attention. No problem; thanks for the quick response and volunteering to test on the boards you have. Paul. > > josh ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: RFC: delete UART current-speed from 4xx DTS?
On Tue, Sep 15, 2009 at 03:32:05PM -0400, Paul Gortmaker wrote: >[Re: RFC: delete UART current-speed from 4xx DTS?] On 15/09/2009 (Tue 11:32) >Josh Boyer wrote: > >> On Tue, Sep 15, 2009 at 10:31:36AM -0400, Paul Gortmaker wrote: >> >One of the guys here was getting a messed up console on a bamboo board > >I meant to say Yosemite board (and hence u-boot), sorry for that. It >gives garbage up until the udbg -> ttyS0 handover, at which point the >console=ttyS0,115200 fixes things. Ok. >> >(on linux boot), which he traced to the fact that the default dts has a >> >9600 baudrate coded into it (board was running 115k2, not 9600). Either >> >deleting the line, or replacing the 9600 with zero fixed the problem. >> >> Once booted, was there a valid current-speed property in /proc/device-tree >> for the serial node? I'm curious if U-Boot created it, or if the kernel >> just used whatever baud was present already. > >Had to go back to get this info; it turns out there is a valid prop in >all the serial nodes (2.6.31-rc7), and hexdumping it gives 0x2580 (9600). Sorry, that was after you removed the property in the DTS entirely, or setting it to 0, or just using the existing DTS as-is? I should have phrased my question better, but I think I answered it myself already. In my brief test with Sequoia and Bamboo, I removed the current-speed property entirely and once booted there was no property in the serial node, which is what I would expect for the old version of U-Boot on these boards. The good news is that it seems to work fine :). >> When I did the bamboo port a while ago, I recall having issues with either >> a missing clock-frequency or current-speed (or both perhaps) and the >> bootloader >> on the board was the original PIBS. It might have been an issue with PIBS >> but I'm guessing the rest of the 4xx boards copied from either Ebony or >> Bamboo in their ports and hence contain that property. > >Right - so there could still perhaps be the same issue with PIBS/bamboo >present that you saw earlier (given my inability to keep board names >straight) OK. I'll be sure to test PIBS. > >> >> >Looking at the Fsl boards, it seems that 99% of them don't list any >> >current-speed at all. I'm willing to whip up a patch to delete them >> >> I think 99% of them use U-Boot, which should fix things up either way. > >This is the interesting part -- being a yosemite (u-boot), I would have >thought so as well. I've not looked at the u-boot code, but it may only >add a current-speed if there isn't one yet. At least that is what the >behaviour tends to indicate. Board is running u-boot 1.3.3 so what we >are seeing here may not reflect what current u-boot code is doing >anyway... Yeah, 1.3.3 is pretty old. However, I _think_ the kernel will just leave the baud rate alone entirely without a current-speed property and without console=ttyS0,. Example: linux:/proc/device-tree/plb/opb/ser...@ef600300 # ls clock-frequency device_type interrupts reg compatible interrupt-parent namevirtual-reg linux:/proc/device-tree/plb/opb/ser...@ef600300 # cat /proc/cmdline rootdelay=15 root=/dev/sda1 rw ip=off linux:/proc/device-tree/plb/opb/ser...@ef600300 # uname -a Linux linux 2.6.31 #4 Tue Sep 15 16:57:49 UTC 2009 ppc ppc ppc GNU/Linux linux:/proc/device-tree/plb/opb/ser...@ef600300 # cat /proc/cpuinfo processor : 0 cpu : 440EP Rev. B clock : 399.96MHz revision: 24.211 (pvr 4222 18d3) bogomips: 799.99 timebase: 39996 platform: PowerPC 44x Platform model : amcc,bamboo Memory : 191 MB linux:/proc/device-tree/plb/opb/ser...@ef600300 # >> I can test bamboo with PIBS, ebony, holly (which isn't 4xx even though it's >> a tree name) with PIBS, sequoia, taishan, yosemite, and walnut. Perhaps a >> few >> of the 405 boards I have as well. >> >> It's easy enough for me to whip up a patch, and since I'll be testing either >> way I'd be happy to do that if you'd like. > >Sure -- the testing effort will be greater than the time to make the >patch, so you doing coverage on all those would be great. I think I've >probably only got easy immediate access to a PIBS/bamboo at the moment. >We already know the yosemite is OK with the change, so that is one less >to test. OK, sounds good. I'll do some more
Re: RFC: delete UART current-speed from 4xx DTS?
[Re: RFC: delete UART current-speed from 4xx DTS?] On 15/09/2009 (Tue 11:32) Josh Boyer wrote: > On Tue, Sep 15, 2009 at 10:31:36AM -0400, Paul Gortmaker wrote: > >One of the guys here was getting a messed up console on a bamboo board I meant to say Yosemite board (and hence u-boot), sorry for that. It gives garbage up until the udbg -> ttyS0 handover, at which point the console=ttyS0,115200 fixes things. > >(on linux boot), which he traced to the fact that the default dts has a > >9600 baudrate coded into it (board was running 115k2, not 9600). Either > >deleting the line, or replacing the 9600 with zero fixed the problem. > > Once booted, was there a valid current-speed property in /proc/device-tree > for the serial node? I'm curious if U-Boot created it, or if the kernel > just used whatever baud was present already. Had to go back to get this info; it turns out there is a valid prop in all the serial nodes (2.6.31-rc7), and hexdumping it gives 0x2580 (9600). > > When I did the bamboo port a while ago, I recall having issues with either > a missing clock-frequency or current-speed (or both perhaps) and the > bootloader > on the board was the original PIBS. It might have been an issue with PIBS > but I'm guessing the rest of the 4xx boards copied from either Ebony or > Bamboo in their ports and hence contain that property. Right - so there could still perhaps be the same issue with PIBS/bamboo present that you saw earlier (given my inability to keep board names straight) > > >Looking at the Fsl boards, it seems that 99% of them don't list any > >current-speed at all. I'm willing to whip up a patch to delete them > > I think 99% of them use U-Boot, which should fix things up either way. This is the interesting part -- being a yosemite (u-boot), I would have thought so as well. I've not looked at the u-boot code, but it may only add a current-speed if there isn't one yet. At least that is what the behaviour tends to indicate. Board is running u-boot 1.3.3 so what we are seeing here may not reflect what current u-boot code is doing anyway... > > >from the various boards, but I thought I'd check 1st to see if there was > >some other reasoning/input. I suppose one could argue that u-boot > >should be replacing the 9600 with 115k2 on the fly, but if the explicit > >specification isn't helping anyone, then it probably just makes sense to > >delete them anyway, I figured. > > Yeah, that's probably valid. I'd be happy to test on the set of boards I > have. > > >Here is the subset of boards I was considering deleting the lines from: > > > > bamboo.dts ebony.dts hcu4.dts holly.dts katmai.dts sam440ep.dts > > sequoia.dts taishan.dts walnut.dts yosemite.dts > > I can test bamboo with PIBS, ebony, holly (which isn't 4xx even though it's > a tree name) with PIBS, sequoia, taishan, yosemite, and walnut. Perhaps a few > of the 405 boards I have as well. > > It's easy enough for me to whip up a patch, and since I'll be testing either > way I'd be happy to do that if you'd like. Sure -- the testing effort will be greater than the time to make the patch, so you doing coverage on all those would be great. I think I've probably only got easy immediate access to a PIBS/bamboo at the moment. We already know the yosemite is OK with the change, so that is one less to test. Thanks, Paul. > > josh ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Driver for using MPC8572's eTSEC1&2 in 16b encoded FIFO Mode?
On the MPC8572, eTSEC1 and eTSEC2 can be configured to jointly operate in 16-bit encoded FIFO mode. Is there currently a Linux driver for interfacing with this FIFO mode? Thanks, Christopher ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [git pull] Please pull powerpc.git next branch
On Tue, 15 Sep 2009, Benjamin Herrenschmidt wrote: > > So I don't know at this stage how to generate a "clean" pull request ... It's rare, for but future reference, what you can do is to just do a merge in a temporary branch, and get it that way. 'git shortlog' should have worked, though. It's only the 'diff' that is based on the direct difference between two end-points, rather than based on working with intersections of sets of commits. Maybe the scripts use 'origin...master' or something for the shortlog, and then the merge-base thing will confuse it? Haven't looked. > In any case, the tree is still there waiting for you to pull. It seems > to merge cleanly tonight though I haven't yet got a chance to test the > result much. It got a conflict with the AGP merge, but I fixed it up in what _seemed_ to be the obvious manner. But somebody should check out the resulting drivers/char/agp/uninorth-agp.c file. Linus ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: RFC: delete UART current-speed from 4xx DTS?
On Tue, Sep 15, 2009 at 10:31:36AM -0400, Paul Gortmaker wrote: >One of the guys here was getting a messed up console on a bamboo board >(on linux boot), which he traced to the fact that the default dts has a >9600 baudrate coded into it (board was running 115k2, not 9600). Either >deleting the line, or replacing the 9600 with zero fixed the problem. Once booted, was there a valid current-speed property in /proc/device-tree for the serial node? I'm curious if U-Boot created it, or if the kernel just used whatever baud was present already. When I did the bamboo port a while ago, I recall having issues with either a missing clock-frequency or current-speed (or both perhaps) and the bootloader on the board was the original PIBS. It might have been an issue with PIBS but I'm guessing the rest of the 4xx boards copied from either Ebony or Bamboo in their ports and hence contain that property. >Looking at the Fsl boards, it seems that 99% of them don't list any >current-speed at all. I'm willing to whip up a patch to delete them I think 99% of them use U-Boot, which should fix things up either way. >from the various boards, but I thought I'd check 1st to see if there was >some other reasoning/input. I suppose one could argue that u-boot >should be replacing the 9600 with 115k2 on the fly, but if the explicit >specification isn't helping anyone, then it probably just makes sense to >delete them anyway, I figured. Yeah, that's probably valid. I'd be happy to test on the set of boards I have. >Here is the subset of boards I was considering deleting the lines from: > > bamboo.dts ebony.dts hcu4.dts holly.dts katmai.dts sam440ep.dts > sequoia.dts taishan.dts walnut.dts yosemite.dts I can test bamboo with PIBS, ebony, holly (which isn't 4xx even though it's a tree name) with PIBS, sequoia, taishan, yosemite, and walnut. Perhaps a few of the 405 boards I have as well. It's easy enough for me to whip up a patch, and since I'll be testing either way I'd be happy to do that if you'd like. josh ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 0/3] cpu: pseries: Cpu offline states framework
* Peter Zijlstra [2009-09-15 14:11:41]: > On Tue, 2009-09-15 at 17:36 +0530, Gautham R Shenoy wrote: > > This patchset contains the offline state driver implemented for > > pSeries. For pSeries, we define three available_hotplug_states. They are: > > > > online: The processor is online. > > > > offline: This is the the default behaviour when the cpu is offlined > > even in the absense of this driver. The CPU would call make an > > rtas_stop_self() call and hand over the CPU back to the resource > > pool, > > thereby effectively deallocating that vCPU from the LPAR. > > NOTE: This would result in a configuration change to the LPAR > > which is visible to the outside world. > > > > inactive: This cedes the vCPU to the hypervisor with a cede latency > > specifier value 2. > > NOTE: This option does not result in a configuration change > > and the vCPU would be still entitled to the LPAR to which it earlier > > belong to. > > > > Any feedback on the patchset will be immensely valuable. > > I still think its a layering violation... its the hypervisor manager > that should be bothered in what state an off-lined cpu is in. > >From a design standpoint where we stand today is 1. A cede indicates that the CPU is no longer needed and can be reassigned (remember we do dedicated CPU partitions in power) 2. What this patch is trying to do is to say "We don't need the CPU, but please don't reassign, put it to sleep" We work the same way with the hypervisor, that applications work with the OS today, by providing madvise and other hints. -- Balbir ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 1/3] pSeries: cede latency specifier helper function.
On Tue, 2009-09-15 at 17:37 +0530, Gautham R Shenoy wrote:
> // Used to pass parms from the OS to PLIC for SetAsrAndRfid
> u64 saved_gpr3; // Saved GPR3
> x20-x27
> u64 saved_gpr4; // Saved GPR4
> x28-x2F
> - u64 saved_gpr5; // Saved GPR5
> x30-x37
> + union {
> + u64 saved_gpr5; // Saved GPR5
> x30-x37
> + struct {
> + u8 cede_latency_hint; // x30
> + u8 reserved[7];//
> x31-x36
> + } fields;
> + } gpr5_dword;
> +
>
> u8 dtl_enable_mask;// Dispatch Trace Log mask
> x38-x38
> u8 donate_dedicated_cpu; // Donate dedicated CPU cycles
> x39-x39
Could you drop the C99 style comments (use /* */ instead)? If you run
checkpatch on this it will error on these lines..
Daniel
___
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
Nathan Fontenot wrote:
> +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);
Can just use simple_strtoul here instead.
> +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);
> +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;
> +}
> +
--
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 2/5] move of_drconf_cell definition to prom.h
Nathan Fontenot wrote:
> Move the definition of the of_drconf_cell struct from numa.c to prom.h.
> This
> is needed so that we can parse the ibm,dynamic-memory device-tree property
> when DLPAR adding and removing memory.
>
> Signed-off-by: Nathan Fontenot
> ---
>
> Index: powerpc/arch/powerpc/include/asm/prom.h
> ===
> --- powerpc.orig/arch/powerpc/include/asm/prom.h2009-09-11
> 12:43:39.0 -0500
> +++ powerpc/arch/powerpc/include/asm/prom.h2009-09-11
> 12:52:11.0 -0500
> @@ -349,6 +349,18 @@
> */
> extern void __iomem *of_iomap(struct device_node *device, int index);
>
> +struct of_drconf_cell {
> +u64base_addr;
> +u32drc_index;
> +u32reserved;
> +u32aa_index;
> +u32flags;
> +};
Might as well fix this up to use a tab instead of spaces for the indentation
if you are moving it.
> +
> +#define DRCONF_MEM_ASSIGNED0x0008
> +#define DRCONF_MEM_AI_INVALID0x0040
> +#define DRCONF_MEM_RESERVED0x0080
> +
> /*
> * NB: This is here while we transition from using asm/prom.h
> * to linux/of.h
> Index: powerpc/arch/powerpc/mm/numa.c
> ===
> --- powerpc.orig/arch/powerpc/mm/numa.c2009-09-11 12:43:39.0
> -0500
> +++ powerpc/arch/powerpc/mm/numa.c2009-09-11 12:52:11.0 -0500
> @@ -296,18 +296,6 @@
> return result;
> }
>
> -struct of_drconf_cell {
> -u64base_addr;
> -u32drc_index;
> -u32reserved;
> -u32aa_index;
> -u32flags;
> -};
> -
> -#define DRCONF_MEM_ASSIGNED0x0008
> -#define DRCONF_MEM_AI_INVALID0x0040
> -#define DRCONF_MEM_RESERVED0x0080
> -
> /*
> * Read the next lmb list entry from the ibm,dynamic-memory property
> * and return the information in the provided of_drconf_cell structure.
> ___
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
--
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
RFC: delete UART current-speed from 4xx DTS?
One of the guys here was getting a messed up console on a bamboo board (on linux boot), which he traced to the fact that the default dts has a 9600 baudrate coded into it (board was running 115k2, not 9600). Either deleting the line, or replacing the 9600 with zero fixed the problem. Looking at the Fsl boards, it seems that 99% of them don't list any current-speed at all. I'm willing to whip up a patch to delete them from the various boards, but I thought I'd check 1st to see if there was some other reasoning/input. I suppose one could argue that u-boot should be replacing the 9600 with 115k2 on the fly, but if the explicit specification isn't helping anyone, then it probably just makes sense to delete them anyway, I figured. Here is the subset of boards I was considering deleting the lines from: bamboo.dts ebony.dts hcu4.dts holly.dts katmai.dts sam440ep.dts sequoia.dts taishan.dts walnut.dts yosemite.dts Thanks, Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/5] dynamic logical partitioning infrastructure
Brian King wrote:
Nathan Fontenot wrote:
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+
+#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.
Good catch, I will fix it in the updated patches.
+
+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?
Yes, I could return the rtas error code to the user to allow the caller to
evaluate it if they wanted to. For what I am doing I am only concerned with
success/failure so I did not deal with returning anything other than -1.
I'll update the next patch to return the rtas error for failures and 0
for success.
+
+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?
Yes, it seems a bit odd here, but in patches later in this series I
add additional initialization steps after the machine_is() check
such that it makes sense to bail out here if the check fails.
+
+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);
I think I tried this and was having issues, I don't remember what they
were though. I will try to fix this in the updated patch.
-Nathan Fontenot
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 0/3] cpu: pseries: Cpu offline states framework
On Tue, 2009-09-15 at 14:11 +0200, Peter Zijlstra wrote: > On Tue, 2009-09-15 at 17:36 +0530, Gautham R Shenoy wrote: > > This patchset contains the offline state driver implemented for > > pSeries. For pSeries, we define three available_hotplug_states. They are: > > > > online: The processor is online. > > > > offline: This is the the default behaviour when the cpu is offlined > > even in the absense of this driver. The CPU would call make an > > rtas_stop_self() call and hand over the CPU back to the resource > > pool, > > thereby effectively deallocating that vCPU from the LPAR. > > NOTE: This would result in a configuration change to the LPAR > > which is visible to the outside world. > > > > inactive: This cedes the vCPU to the hypervisor with a cede latency > > specifier value 2. > > NOTE: This option does not result in a configuration change > > and the vCPU would be still entitled to the LPAR to which it earlier > > belong to. > > > > Any feedback on the patchset will be immensely valuable. > > I still think its a layering violation... its the hypervisor manager > that should be bothered in what state an off-lined cpu is in. Yeah it probably is a layering violation, but when has that stopped us before :) Is it anticipated that this will be useful on platforms other than pseries? cheers signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 0/3] cpu: pseries: Cpu offline states framework
On Tue, 2009-09-15 at 17:36 +0530, Gautham R Shenoy wrote: > This patchset contains the offline state driver implemented for > pSeries. For pSeries, we define three available_hotplug_states. They are: > > online: The processor is online. > > offline: This is the the default behaviour when the cpu is offlined > even in the absense of this driver. The CPU would call make an > rtas_stop_self() call and hand over the CPU back to the resource pool, > thereby effectively deallocating that vCPU from the LPAR. > NOTE: This would result in a configuration change to the LPAR > which is visible to the outside world. > > inactive: This cedes the vCPU to the hypervisor with a cede latency > specifier value 2. > NOTE: This option does not result in a configuration change > and the vCPU would be still entitled to the LPAR to which it earlier > belong to. > > Any feedback on the patchset will be immensely valuable. I still think its a layering violation... its the hypervisor manager that should be bothered in what state an off-lined cpu is in. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v3 3/3] cpu: Implement cpu-offline-state callbacks for pSeries.
This patch implements the callbacks to handle the reads/writes into the sysfs
interfaces
/sys/devices/system/cpu/cpu/available_hotplug_states
and
/sys/devices/system/cpu/cpu/current_hotplug_state
Currently, the patch defines two states which the processor can go to when it
is offlined. They are
- offline: The current behaviour when the cpu is offlined.
The CPU would call make an rtas_stop_self() call and hand over the
CPU back to the resource pool, thereby effectively deallocating
that vCPU from the LPAR.
- inactive: This is expected to cede the processor to the hypervisor with a
latency hint specifier value. Hypervisor may use this hint to provide
better energy savings. In this state, the control of the vCPU will continue
to be with the LPAR.
Signed-off-by: Gautham R Shenoy
---
arch/powerpc/platforms/pseries/Makefile |2
arch/powerpc/platforms/pseries/hotplug-cpu.c| 88 +-
arch/powerpc/platforms/pseries/offline_driver.c | 148 +++
arch/powerpc/platforms/pseries/offline_driver.h | 20 +++
arch/powerpc/platforms/pseries/smp.c| 17 +++
5 files changed, 267 insertions(+), 8 deletions(-)
create mode 100644 arch/powerpc/platforms/pseries/offline_driver.c
create mode 100644 arch/powerpc/platforms/pseries/offline_driver.h
diff --git a/arch/powerpc/platforms/pseries/Makefile
b/arch/powerpc/platforms/pseries/Makefile
index 790c0b8..3a569c7 100644
--- a/arch/powerpc/platforms/pseries/Makefile
+++ b/arch/powerpc/platforms/pseries/Makefile
@@ -17,7 +17,7 @@ obj-$(CONFIG_KEXEC) += kexec.o
obj-$(CONFIG_PCI) += pci.o pci_dlpar.o
obj-$(CONFIG_PSERIES_MSI) += msi.o
-obj-$(CONFIG_HOTPLUG_CPU) += hotplug-cpu.o
+obj-$(CONFIG_HOTPLUG_CPU) += hotplug-cpu.o offline_driver.o
obj-$(CONFIG_MEMORY_HOTPLUG) += hotplug-memory.o
obj-$(CONFIG_HVC_CONSOLE) += hvconsole.o
diff --git a/arch/powerpc/platforms/pseries/hotplug-cpu.c
b/arch/powerpc/platforms/pseries/hotplug-cpu.c
index a20ead8..1e06bb1 100644
--- a/arch/powerpc/platforms/pseries/hotplug-cpu.c
+++ b/arch/powerpc/platforms/pseries/hotplug-cpu.c
@@ -30,6 +30,7 @@
#include
#include "xics.h"
#include "plpar_wrappers.h"
+#include "offline_driver.h"
/* This version can't take the spinlock, because it never returns */
static struct rtas_args rtas_stop_self_args = {
@@ -54,13 +55,74 @@ static void rtas_stop_self(void)
panic("Alas, I survived.\n");
}
+static void cede_on_offline(u8 cede_latency_hint)
+{
+ unsigned int cpu = smp_processor_id();
+ unsigned int hwcpu = hard_smp_processor_id();
+ u8 old_cede_latency_hint;
+
+ old_cede_latency_hint = get_cede_latency_hint();
+ get_lppaca()->idle = 1;
+ if (!get_lppaca()->shared_proc)
+ get_lppaca()->donate_dedicated_cpu = 1;
+
+ printk(KERN_INFO "cpu %u (hwid %u) ceding for offline with hint %d\n",
+ cpu, hwcpu, cede_latency_hint);
+ while (get_preferred_offline_state(cpu) != CPU_STATE_ONLINE) {
+ extended_cede_processor(cede_latency_hint);
+ printk(KERN_INFO "cpu %u (hwid %u) returned from cede.\n",
+ cpu, hwcpu);
+ printk(KERN_INFO
+ "Decrementer value = %x Timebase value = %llx\n",
+ get_dec(), get_tb());
+ }
+
+ printk(KERN_INFO "cpu %u (hwid %u) got prodded to go online\n",
+ cpu, hwcpu);
+
+ if (!get_lppaca()->shared_proc)
+ get_lppaca()->donate_dedicated_cpu = 0;
+ get_lppaca()->idle = 0;
+
+ /* Reset the cede_latency specifier value */
+ set_cede_latency_hint(old_cede_latency_hint);
+
+ unregister_slb_shadow(hwcpu, __pa(get_slb_shadow()));
+
+ /*
+* NOTE: Calling start_secondary() here for now to start
+* a new context.
+*
+* However, need to do it cleanly by resetting the stack
+* pointer.
+*/
+ start_secondary();
+}
+
static void pseries_mach_cpu_die(void)
{
+ unsigned int cpu = smp_processor_id();
+ u8 cede_latency_hint = 0;
+
local_irq_disable();
idle_task_exit();
xics_teardown_cpu();
- unregister_slb_shadow(hard_smp_processor_id(), __pa(get_slb_shadow()));
- rtas_stop_self();
+
+ if (get_preferred_offline_state(cpu) == CPU_STATE_OFFLINE) {
+
+ set_cpu_current_state(cpu, CPU_STATE_OFFLINE);
+ unregister_slb_shadow(hard_smp_processor_id(),
+ __pa(get_slb_shadow()));
+ rtas_stop_self();
+ goto out_bug;
+ } else if (get_preferred_offline_state(cpu) == CPU_STATE_INACTIVE) {
+ set_cpu_current_state(cpu, CPU_STATE_INACTIVE);
+ cede_latency_hint = 2;
+ cede_on_offline(cede_latency_hint);
+
+ }
+
+out_bug:
/* Should never get here... */
BUG();
for(;;);
[PATCH v3 2/3] cpu: Offline state Framework.
Provide an interface by which the system administrator can decide what state
should the CPU go to when it is offlined.
To query the hotplug states, on needs to perform a read on:
/sys/devices/system/cpu/cpu/available_hotplug_states
To query or set the current state for a particular CPU, one needs to
use the sysfs interface
/sys/devices/system/cpu/cpu/current_hotplug_state
This patch implements the architecture independent bits of the
cpu-offline-state framework.
The architecture specific bits are expected to register the actual code which
implements the callbacks when the above mentioned sysfs interfaces are read or
written into. Thus the values provided by reading available_offline_states vary
with the architecture.
The patch provides serialization for writes to the "current_hotplug_state"
with respect to with the writes to the "online" sysfs tunable.
Signed-off-by: Gautham R Shenoy
---
Documentation/cpu-hotplug.txt | 22 +
drivers/base/cpu.c| 181 +++--
include/linux/cpu.h | 10 ++
3 files changed, 204 insertions(+), 9 deletions(-)
diff --git a/Documentation/cpu-hotplug.txt b/Documentation/cpu-hotplug.txt
index 9d620c1..dcec06d 100644
--- a/Documentation/cpu-hotplug.txt
+++ b/Documentation/cpu-hotplug.txt
@@ -115,6 +115,28 @@ Just remember the critical section cannot call any
function that can sleep or schedule this process away. The preempt_disable()
will work as long as stop_machine_run() is used to take a cpu down.
+CPU-offline states
+--
+On architectures which allow the more than one valid state when
+the CPU goes offline, the system administrator can decide
+the state the CPU needs to go to when it is offlined.
+
+If the architecture has implemented a cpu-offline driver exposing these
+multiple offline states, the system administrator can use the following sysfs
+interfaces to query the available hotplug states and also query and set the
+current hotplug state for a given cpu:
+
+To query the hotplug states, on needs to perform a read on:
+/sys/devices/system/cpu/cpu/available_hotplug_states
+
+To query or set the current state for a particular CPU,
+one needs to use the sysfs interface
+
+/sys/devices/system/cpu/cpu/current_hotplug_state
+
+Writes to the "online" sysfs files are serialized against the writes to the
+"current_hotplug_state" file.
+
CPU Hotplug - Frequently Asked Questions.
Q: How to enable my kernel to support CPU hotplug?
diff --git a/drivers/base/cpu.c b/drivers/base/cpu.c
index e62a4cc..00c38be 100644
--- a/drivers/base/cpu.c
+++ b/drivers/base/cpu.c
@@ -20,7 +20,166 @@ EXPORT_SYMBOL(cpu_sysdev_class);
static DEFINE_PER_CPU(struct sys_device *, cpu_sys_devices);
+struct sys_device *get_cpu_sysdev(unsigned cpu)
+{
+ if (cpu < nr_cpu_ids && cpu_possible(cpu))
+ return per_cpu(cpu_sys_devices, cpu);
+ else
+ return NULL;
+}
+EXPORT_SYMBOL_GPL(get_cpu_sysdev);
+
+
#ifdef CONFIG_HOTPLUG_CPU
+
+struct cpu_offline_driver *cpu_offline_driver;
+static DEFINE_MUTEX(cpu_offline_driver_lock);
+
+ssize_t show_available_hotplug_states(struct sys_device *dev,
+ struct sysdev_attribute *attr, char *buf)
+{
+ struct cpu *cpu = container_of(dev, struct cpu, sysdev);
+ int cpu_num = cpu->sysdev.id;
+ ssize_t ret;
+
+ mutex_lock(&cpu_offline_driver_lock);
+ if (!cpu_offline_driver) {
+ ret = -EEXIST;
+ goto out_unlock;
+ }
+
+ ret = cpu_offline_driver->read_available_states(cpu_num, buf);
+
+out_unlock:
+ mutex_unlock(&cpu_offline_driver_lock);
+
+ return ret;
+
+}
+
+ssize_t show_current_hotplug_state(struct sys_device *dev,
+ struct sysdev_attribute *attr, char *buf)
+{
+ struct cpu *cpu = container_of(dev, struct cpu, sysdev);
+ int cpu_num = cpu->sysdev.id;
+ ssize_t ret = 0;
+
+ mutex_lock(&cpu_offline_driver_lock);
+ if (!cpu_offline_driver) {
+ ret = -EEXIST;
+ goto out_unlock;
+ }
+
+ ret = cpu_offline_driver->read_current_state(cpu_num, buf);
+
+out_unlock:
+ mutex_unlock(&cpu_offline_driver_lock);
+
+ return ret;
+}
+
+ssize_t store_current_hotplug_state(struct sys_device *dev,
+ struct sysdev_attribute *attr,
+ const char *buf, size_t count)
+{
+ struct cpu *cpu = container_of(dev, struct cpu, sysdev);
+ int cpu_num = cpu->sysdev.id;
+ ssize_t ret = count;
+
+ mutex_lock(&cpu_offline_driver_lock);
+ if (!cpu_offline_driver) {
+ ret = -EEXIST;
+ goto out_unlock;
+ }
+
+ ret = cpu_offline_driver->write_current_state(cpu_num, buf);
+
+out_unlock:
+ mutex_unlock(&cpu_offline_driver_lock);
+
+ if (ret >= 0)
+ ret = count;
+ return ret;
+}
+
+static SYSDEV_ATTR(available_hotplug_sta
[PATCH v3 1/3] pSeries: cede latency specifier helper function.
From: Arun R Bharadwaj
This patch provides helper functions to set the cede latency specifier
value in the VPA indicating the latency expectation of the guest OS to
inform the hypervisor's choice of the platform dependent energy saving
mode chosen for the processor when unused during the subsequent
H_CEDE hypercall.
Signed-off-by: Arun R Bharadwaj
Signed-off-by: Gautham R Shenoy
---
arch/powerpc/include/asm/lppaca.h |9 -
arch/powerpc/platforms/pseries/plpar_wrappers.h | 17 +
arch/powerpc/xmon/xmon.c|3 ++-
3 files changed, 27 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/include/asm/lppaca.h
b/arch/powerpc/include/asm/lppaca.h
index f78f65c..aaa0066 100644
--- a/arch/powerpc/include/asm/lppaca.h
+++ b/arch/powerpc/include/asm/lppaca.h
@@ -100,7 +100,14 @@ struct lppaca {
// Used to pass parms from the OS to PLIC for SetAsrAndRfid
u64 saved_gpr3; // Saved GPR3 x20-x27
u64 saved_gpr4; // Saved GPR4 x28-x2F
- u64 saved_gpr5; // Saved GPR5 x30-x37
+ union {
+ u64 saved_gpr5; // Saved GPR5 x30-x37
+ struct {
+ u8 cede_latency_hint; // x30
+ u8 reserved[7];// x31-x36
+ } fields;
+ } gpr5_dword;
+
u8 dtl_enable_mask;// Dispatch Trace Log mask x38-x38
u8 donate_dedicated_cpu; // Donate dedicated CPU cycles x39-x39
diff --git a/arch/powerpc/platforms/pseries/plpar_wrappers.h
b/arch/powerpc/platforms/pseries/plpar_wrappers.h
index a24a6b2..1174d4b 100644
--- a/arch/powerpc/platforms/pseries/plpar_wrappers.h
+++ b/arch/powerpc/platforms/pseries/plpar_wrappers.h
@@ -9,11 +9,28 @@ static inline long poll_pending(void)
return plpar_hcall_norets(H_POLL_PENDING);
}
+static inline u8 get_cede_latency_hint(void)
+{
+ return get_lppaca()->gpr5_dword.fields.cede_latency_hint;
+}
+
+static inline void set_cede_latency_hint(u8 latency_hint)
+{
+ get_lppaca()->gpr5_dword.fields.cede_latency_hint = latency_hint;
+}
+
static inline long cede_processor(void)
{
return plpar_hcall_norets(H_CEDE);
}
+static inline long extended_cede_processor(u8 latency_hint)
+{
+ set_cede_latency_hint(latency_hint);
+ cede_processor();
+
+}
+
static inline long vpa_call(unsigned long flags, unsigned long cpu,
unsigned long vpa)
{
diff --git a/arch/powerpc/xmon/xmon.c b/arch/powerpc/xmon/xmon.c
index e1f33a8..a2089cd 100644
--- a/arch/powerpc/xmon/xmon.c
+++ b/arch/powerpc/xmon/xmon.c
@@ -1613,7 +1613,8 @@ static void super_regs(void)
ptrLpPaca->saved_srr0, ptrLpPaca->saved_srr1);
printf("Saved Gpr3=%.16lx Saved Gpr4=%.16lx \n",
ptrLpPaca->saved_gpr3, ptrLpPaca->saved_gpr4);
- printf("Saved Gpr5=%.16lx \n",
ptrLpPaca->saved_gpr5);
+ printf("Saved Gpr5=%.16lx \n",
+ ptrLpPaca->gpr5_dword.saved_gpr5);
}
#endif
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v3 0/3] cpu: pseries: Cpu offline states framework
Hi, RFC not for inclusion This is the version 3 of the patch series to provide a cpu-offline framework that enables the administrators choose the state of a CPU when it is offlined, when multiple such states are exposed by the underlying architecture. Changes from Version 2:(can be found here: http://lkml.org/lkml/2009/8/28/102) - Addressed Andrew Morton's review comments regarding names of global variables, handling of error conditions and documentation of the interfaces. - Implemented a patch to provide helper functions to set the cede latency specifier value in the VPA indicating latency expectation of the guest OS when the vcpu is ceded from a subsequent H_CEDE hypercall. Hypervisor may use this for better energy savings. - Renamed of the cpu-hotplug states. "deallocate" is renamed as "offline" and "deactivate" is renamed as "inactive". The patch-series exposes the following sysfs tunables to allow the system-adminstrator to choose the state of a CPU: To query the available hotplug states, one needs to read the sysfs tunable: /sys/devices/system/cpu/cpu/available_hotplug_states To query or set the current state, on needs to read/write the sysfs tunable: /sys/devices/system/cpu/cpu/current_hotplug_state The patchset ensures that the writes to the "current_hotplug_state" sysfs file are serialized against the writes to the "online" file. This patchset contains the offline state driver implemented for pSeries. For pSeries, we define three available_hotplug_states. They are: online: The processor is online. offline: This is the the default behaviour when the cpu is offlined even in the absense of this driver. The CPU would call make an rtas_stop_self() call and hand over the CPU back to the resource pool, thereby effectively deallocating that vCPU from the LPAR. NOTE: This would result in a configuration change to the LPAR which is visible to the outside world. inactive: This cedes the vCPU to the hypervisor with a cede latency specifier value 2. NOTE: This option does not result in a configuration change and the vCPU would be still entitled to the LPAR to which it earlier belong to. Any feedback on the patchset will be immensely valuable. --- Arun R Bharadwaj (1): pSeries: cede latency specifier helper function. Gautham R Shenoy (2): cpu: Implement cpu-offline-state callbacks for pSeries. cpu: Offline state Framework. Documentation/cpu-hotplug.txt | 22 +++ arch/powerpc/include/asm/lppaca.h |9 + arch/powerpc/platforms/pseries/Makefile |2 arch/powerpc/platforms/pseries/hotplug-cpu.c| 88 ++- arch/powerpc/platforms/pseries/offline_driver.c | 148 +++ arch/powerpc/platforms/pseries/offline_driver.h | 20 +++ arch/powerpc/platforms/pseries/plpar_wrappers.h | 17 ++ arch/powerpc/platforms/pseries/smp.c| 17 ++ arch/powerpc/xmon/xmon.c|3 drivers/base/cpu.c | 181 ++- include/linux/cpu.h | 10 + 11 files changed, 498 insertions(+), 19 deletions(-) create mode 100644 arch/powerpc/platforms/pseries/offline_driver.c create mode 100644 arch/powerpc/platforms/pseries/offline_driver.h -- Thanks and Regards gautham. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC] powerpc/irq: Add generic API for setting up cascaded IRQs
On Tue, 2009-09-15 at 20:02 +1000, Benjamin Herrenschmidt wrote: > > I'm a reverse polish kind of guy. I preferring 'subject'_'action' > > over 'action'_'subject' just because it groups like subjects together. > > But it doesn't matter much, especially in this case where 'subject' > > is in a group of exactly 1. :-) > > > > I'll do whichever you prefer. > > I just caught myself calling something relocs_check instead of > check_relocs so I suppose it's fair game :-) Yeah but that sounds stupid :) > Whatever you want. I want a pony. And setup_cascade() is definitely better IMHO. cheers signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] [SCSI] mpt fusion: Fix 32 bit platforms with 64 bit resources
> diff --git a/drivers/message/fusion/mptbase.c
> b/drivers/message/fusion/mptbase.c
> index 5d496a9..d5b0f15 100644
> --- a/drivers/message/fusion/mptbase.c
> +++ b/drivers/message/fusion/mptbase.c
> @@ -1510,11 +1510,12 @@ static int
> mpt_mapresources(MPT_ADAPTER *ioc)
> {
> u8 __iomem *mem;
> + u8 __iomem *port;
> int ii;
> - unsigned longmem_phys;
> - unsigned longport;
> - u32 msize;
> - u32 psize;
> + phys_addr_t mem_phys;
> + phys_addr_t port_phys;
> + resource_size_t msize;
> + resource_size_t psize;
Is phys_addr_t defined for all archs nowadays ? Why not use
resource_size_t for everything ? resource_size_t is a bit of a misnomer,
it's not a type supposed to reference a "size" but really a physical
address (or a size)... it's been called resource_size_t I believe
because it's "sized" appropriately for holding a physical address.
Cheers,
Ben.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC] powerpc/irq: Add generic API for setting up cascaded IRQs
> I'm a reverse polish kind of guy. I preferring 'subject'_'action' > over 'action'_'subject' just because it groups like subjects together. > But it doesn't matter much, especially in this case where 'subject' > is in a group of exactly 1. :-) > > I'll do whichever you prefer. I just caught myself calling something relocs_check instead of check_relocs so I suppose it's fair game :-) Whatever you want. Cheers, Ben. ___ 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 Tue, 2009-09-15 at 10:57 +0200, Ludo Van Put wrote: > Thnx for the suggestion, but the ide_insw is in fact of copy of the > _insw assembly routine, and it gets passed > the effective address, without the _IO_BASE offset. > > I was thinking about TLB stuff. I'm not a u-boot expert, but could it > be that I need to tweak/reconfigure u-boot so I can access the address > returned from ioremap64? No. If you pass the right physical address to ioremap64, the result should be useable as-is. The TLB entries will be faulted in automatically by the kernel when doing accesses. At this stage, I can't say what's wrong, it looks like you may be accessing the wrong virtual address or something like that. Hard to tell. It's a data access exception, not a machine check, so that means that in some ways, the virtual address accessed by ide_insw is not mapped by the kernel page tables, which is what the kernel TLB miss handler uses to populate the TLB. 2.6.10 is so old, that I really have little memories of what is going on in that area and I'm afraid am of little help here. If you have a HW debugger such as a BDI, you may want to trace through the access, what kind of TLB faults it generates and why the TLB miss handler doesn't handle it. Cheers, Ben. ___ 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/15 Benjamin Herrenschmidt : > On Mon, 2009-09-14 at 15:08 +0200, Ludo Van Put wrote: >> 2009/9/14 Josh Boyer : >> > 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: 0300 Not >> 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! >> <0>Rebooting 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. Thnx for the suggestion, but the ide_insw is in fact of copy of the _insw assembly routine, and it gets passed the effective address, without the _IO_BASE offset. I was thinking about TLB stuff. I'm not a u-boot expert, but could it be that I need to tweak/reconfigure u-boot so I can access the address returned from ioremap64? KR, Ludo ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [git pull] Please pull powerpc.git next branch
On Fri, 2009-09-11 at 17:18 +1000, Benjamin Herrenschmidt wrote: > Hi Linus ! > > This is the powerpc batch for 2.6.32. > > You will notice a bunch of generic swiotlb changes along with > corresponding changes to arch/sparc and arch/x86 from Fujita Tomonori. > > There are due to my tree having pulled Ingo's iommu tree do sort out > various dependencies. If you pull Ingo's first, you'll already have > all these. > > I'm happy for you to defer the pulling of my tree until you have those > bits via Ingo if you prefer, and I'll then send a pull request cleared > of that noise. So you pulled from Ingo, gitk or git log origin/master..powerpc/next only shows my new stuff but git shortlog and git diff --stat still get everything from the merge base including Fujita stuff... So I don't know at this stage how to generate a "clean" pull request ... In any case, the tree is still there waiting for you to pull. It seems to merge cleanly tonight though I haven't yet got a chance to test the result much. Cheers, Ben. > Among other non-arch/powerpc patches: Some PS3 and PowerMac specific > driver changes (yes, I think we are still the only users of > generic_nvram), some changes to HVC console and that should be it. > > Cheers, > Ben. > > The following changes since commit e07cccf4046978df10f2e13fe2b99b2f9b3a65db: > Linus Torvalds (1): > Linux 2.6.31-rc9 > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git next > > Anton Blanchard (3): > powerpc: Move 64bit VDSO to improve context switch performance > powerpc: Rearrange SLB preload code > powerpc: Preload application text segment instead of TASK_UNMAPPED_BASE > > Anton Vorontsov (7): > powerpc/83xx: Add support for MPC8377E-WLAN boards > powerpc/85xx: Add support for I2C EEPROMs on MPC8548CDS boards > powerpc/83xx: Add eSDHC support for MPC837xE-RDB/WLAN boards > powerpc/85xx: Add eSDHC support for MPC8536DS boards > powerpc/82xx: Fix BCSR bits for MPC8272ADS boards > powerpc/82xx: Add CPM USB Gadget support for MPC8272ADS boards > powerpc/85xx: Add QE USB support for MPC8569E-MDS boards > > Arnd Bergmann (1): > dma-ops: Remove flush_write_buffers() in dma-mapping-common.h > > Bastian Blank (1): > powerpc: Remove SMP warning from PowerMac cpufreq > > Becky Bruce (1): > powerpc: Name xpn & x fields in HW Hash PTE format > > Benjamin Herrenschmidt (37): > powerpc: Rename exception.h to exception-64s.h > powerpc: Use names rather than numbers for SPRGs (v2) > powerpc: Remove use of a second scratch SPRG in STAB code > powerpc/mm: Fix definitions of FORCE_MAX_ZONEORDER in Kconfig > powerpc/pmac: Fix PowerSurge SMP IPI allocation > powerpc: Change PACA from SPRG3 to SPRG1 > powerpc: Add compat_sys_truncate > powerpc/mm: Fix misplaced #endif in pgtable-ppc64-64k.h > powerpc/of: Remove useless register save/restore when calling OF back > powerpc/mm: Add HW threads support to no_hash TLB management > powerpc/mm: Add opcode definitions for tlbivax and tlbsrx. > powerpc/mm: Add more bit definitions for Book3E MMU registers > powerpc/mm: Add support for early ioremap on non-hash 64-bit processors > powerpc: Modify some ppc_asm.h macros to accomodate 64-bits Book3E > powerpc/mm: Make low level TLB flush ops on BookE take additional args > powerpc/mm: Call mmu_context_init() from ppc64 > powerpc: Clean ifdef usage in copy_thread() > powerpc: Move definitions of secondary CPU spinloop to header file > powerpc/mm: Rework & cleanup page table freeing code path > powerpc: Add SPR definitions for new 64-bit BookE > powerpc: Add memory management headers for new 64-bit BookE > powerpc: Add definitions used by exception handling on 64-bit Book3E > powerpc: Add PACA fields specific to 64-bit Book3E processors > powerpc/mm: Move around mmu_gathers definition on 64-bit > powerpc: Add TLB management code for 64-bit Book3E > powerpc/mm: Add support for SPARSEMEM_VMEMMAP on 64-bit Book3E > powerpc: Remaining 64-bit Book3E support > powerpc/mm: Fix encoding of page table cache numbers > Merge commit 'paulus-perf/master' into next > Merge commit 'origin/master' into next > powerpc/mm: Cleanup handling of execute permission > Merge commit 'kumar/next' into next > Merge commit 'tip/iommu-for-powerpc' into next > powerpc: Properly start decrementer on BookE secondary CPUs > powerpc: Fix some late PowerMac G5 with PCIe ATI graphics > powerpc/booke: Don't set DABR on 64-bit BookE, use DAC1 instead > powerpc/iseries: Fix oops reading from /proc/iSeries/mf/*/cmdline > > Benjamin Krill (1): > powerpc/prom_init: Evaluate mem kernel parameter for early allocation > > Brian King (1): > powerpc/pseries: Fix to handle
