[git pull] Please pull powerpc.git merge branch
Please pull from the 'merge' branch of git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git merge to get some more bug fixes and defconfig updates for powerpc, as listed below. Almost all of the bulk is in the defconfig updates for the Freescale embedded platforms. Thanks, Paul. arch/powerpc/Makefile |4 arch/powerpc/boot/Makefile|2 arch/powerpc/boot/crtsavres.S | 233 +++ arch/powerpc/boot/dts/mpc8377_rdb.dts |8 - arch/powerpc/boot/dts/mpc8378_rdb.dts |8 - arch/powerpc/boot/dts/mpc8379_rdb.dts |8 - arch/powerpc/boot/dts/mpc8548cds.dts |4 arch/powerpc/configs/83xx/mpc8313_rdb_defconfig | 155 +++--- arch/powerpc/configs/83xx/mpc8315_rdb_defconfig | 162 +++ arch/powerpc/configs/83xx/mpc832x_mds_defconfig | 146 ++ arch/powerpc/configs/83xx/mpc832x_rdb_defconfig | 150 +++--- arch/powerpc/configs/83xx/mpc834x_itx_defconfig | 157 +++--- arch/powerpc/configs/83xx/mpc834x_itxgp_defconfig | 150 ++ arch/powerpc/configs/83xx/mpc834x_mds_defconfig | 146 ++ arch/powerpc/configs/83xx/mpc836x_mds_defconfig | 146 ++ arch/powerpc/configs/83xx/mpc837x_mds_defconfig | 146 ++ arch/powerpc/configs/83xx/mpc837x_rdb_defconfig | 224 +++ arch/powerpc/configs/83xx/sbc834x_defconfig | 140 ++--- arch/powerpc/configs/85xx/ksi8560_defconfig | 168 +++ arch/powerpc/configs/85xx/mpc8540_ads_defconfig | 133 ++--- arch/powerpc/configs/85xx/mpc8544_ds_defconfig| 210 +- arch/powerpc/configs/85xx/mpc8560_ads_defconfig | 135 ++--- arch/powerpc/configs/85xx/mpc8568mds_defconfig| 150 ++ arch/powerpc/configs/85xx/mpc8572_ds_defconfig| 210 +- arch/powerpc/configs/85xx/mpc85xx_cds_defconfig | 137 ++--- arch/powerpc/configs/85xx/sbc8548_defconfig | 131 ++--- arch/powerpc/configs/85xx/sbc8560_defconfig | 135 ++--- arch/powerpc/configs/85xx/stx_gp3_defconfig | 152 ++ arch/powerpc/configs/85xx/tqm8540_defconfig | 147 ++ arch/powerpc/configs/85xx/tqm8541_defconfig | 146 ++ arch/powerpc/configs/85xx/tqm8555_defconfig | 146 ++ arch/powerpc/configs/85xx/tqm8560_defconfig | 146 ++ arch/powerpc/configs/adder875_defconfig | 52 ++- arch/powerpc/configs/ep8248e_defconfig| 124 ++-- arch/powerpc/configs/ep88xc_defconfig | 47 ++- arch/powerpc/configs/linkstation_defconfig| 172 +++ arch/powerpc/configs/mpc7448_hpc2_defconfig | 136 ++--- arch/powerpc/configs/mpc8272_ads_defconfig| 126 ++-- arch/powerpc/configs/mpc83xx_defconfig| 151 ++ arch/powerpc/configs/mpc85xx_defconfig| 230 ++- arch/powerpc/configs/mpc8610_hpcd_defconfig | 316 - arch/powerpc/configs/mpc8641_hpcn_defconfig | 210 +- arch/powerpc/configs/mpc866_ads_defconfig | 128 ++--- arch/powerpc/configs/mpc885_ads_defconfig | 47 ++- arch/powerpc/configs/pq2fads_defconfig| 133 ++--- arch/powerpc/configs/prpmc2800_defconfig | 153 +++--- arch/powerpc/configs/sbc8641d_defconfig | 150 ++ arch/powerpc/configs/storcenter_defconfig | 71 +++-- arch/powerpc/kernel/irq.c |2 arch/powerpc/kernel/ppc_ksyms.c |2 arch/powerpc/kernel/prom_init_check.sh| 14 + arch/powerpc/lib/Makefile |2 arch/powerpc/lib/crtsavres.S | 229 +++ arch/powerpc/platforms/85xx/Kconfig |1 arch/powerpc/platforms/cell/spu_base.c| 44 ++- arch/powerpc/platforms/cell/spufs/run.c | 21 + arch/powerpc/platforms/cell/spufs/sched.c | 19 + arch/powerpc/platforms/pseries/eeh_driver.c | 11 - arch/powerpc/platforms/pseries/nvram.c|4 arch/powerpc/xmon/xmon.c |1 drivers/macintosh/mediabay.c |4 drivers/macintosh/smu.c |5 drivers/macintosh/therm_adt746x.c | 13 + include/asm-powerpc/mediabay.h| 12 + include/asm-powerpc/spu.h |1 include/asm-powerpc/spu_csa.h |2 include/asm-powerpc/system.h |2 67 files changed, 4557 insertions(+), 2213 deletions(-) create mode 100644 arch/powerpc/boot/crtsavres.S create mode 100644 arch/powerpc/lib/crtsavres.S Adrian Bunk (1): [POWERPC] Build fix for drivers/macintosh/mediabay.c Andrew Morton (1): [POWERPC] Fix warning in
CPM2 mii-bitbang: Allowing mdio on port pins other than port C
Hello,
I am preparing a board port (from 2.4.18!) for a proprietary board which
has it's mdio on a different port than mdc. The current mii-bitbang
driver in fs_enet assumes both pins are connected to port C. I have
created a fairly simple patch to make this more flexible, but I'm new to
device trees and am unsure how best to describe the situation in the
dts.
The current mdio node for CPM2 looks something like:
[EMAIL PROTECTED] {
device_type = mdio;
compatible = fsl,cpm2-mdio-bitbang;
#address-cells = 1;
#size-cells = 0
reg = 0x10d40 0x14;
fsl,mdio-pin = 12;
fsl,mdc-pin = 15;
}
I have made mdio work on our board by adding a second reg range and
using the first one for mdc and the second one for mdio:
reg = 0x10d40 0x14 0x10d60 0x14; // mdc=port D, mdio=port A
fsl,mdio-pin = 12;// PD12
fsl,mdc-pin = 15; // PC15
The code remains backwards compatible, in that if only one reg range is
present it is used for both.
Is this a valid (and acceptable) way to extend the reg property? Is
their a cleaner way I should look at?
Regards,
Mark Ware
B2010.dts
Description: B2010.dts
B2010.dts
Description: B2010.dts
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: BUG() in current git, __dma_alloc_coherent, Beige G3
Original-Nachricht Datum: Mon, 16 Jun 2008 14:50:38 +1000 Von: Benjamin Herrenschmidt [EMAIL PROTECTED] An: Joseph Fannin [EMAIL PROTECTED] CC: linuxppc-dev@ozlabs.org Betreff: Re: BUG() in current git, __dma_alloc_coherent, Beige G3 This is 100% reproducable. I can't really recall the last kernel I built and booted successfully on this box -- the best I can say is that the 2.6.24-ish kernel Ubuntu ships works. I should probably mention that I've been having a little trouble with the IDE drive in this machine -- but the drive isn't the problem: * This is 100% reproducible with the current git kernel, and doesn't happen w/the Ubuntu kernel * The traceback and dump does not vary between boots * The kernel BUGs out well before the disks are detected (and it's a _drive_ problem) ... etc. :-) I don't want to send anyone on a wild goose chase, but yeah, it's not the hardware. ;-) So, what can I do to help find the problem here? Git says no one's touched that file in a while, and tracing through this problem is above my skill level here. I'll attach my .config, and put the vmlinux up: I discovered this bug some time ago and reported it on the list. See here for more info: http://ozlabs.org/pipermail/linuxppc-dev/2008-May/056128.html Anyway I don't think your machine needs dma-noncoherent. best regards, Gerhard -- Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: BUG() in current git, __dma_alloc_coherent, Beige G3
I discovered this bug some time ago and reported it on the list. See here for more info: http://ozlabs.org/pipermail/linuxppc-dev/2008-May/056128.html Anyway I don't think your machine needs dma-noncoherent. Kumar, do you have a fix for that ? Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [git pull] Please pull powerpc.git merge branch
On Mon, 2008-06-16 at 15:56 +1000, Paul Mackerras wrote: Please pull from the 'merge' branch of git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git merge to get some more bug fixes and defconfig updates for powerpc, as listed below. Almost all of the bulk is in the defconfig updates for the Freescale embedded platforms. Paul, did you have a chance to fix our defconfig's for the loss of SFF support in libata ? Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [82xx] powerpc: Add support for mpc8247 based board MGCOGE from keymile.
On Fri, Jun 13, 2008 at 06:33:08PM +0200, Heiko Schocher wrote:
Hello Scott,
here comes the updated version for the mgcoge port, with your
suggestions:
[powerpc] Added support for the MPC8247 based board MGCOGE
from Keymile.
Signed-off-by: Heiko Schocher [EMAIL PROTECTED]
---
arch/powerpc/boot/dts/mgcoge.dts | 174 +++
arch/powerpc/configs/mgcoge_defconfig | 900
+
arch/powerpc/platforms/82xx/Kconfig |8 +
arch/powerpc/platforms/82xx/Makefile |1 +
arch/powerpc/platforms/82xx/mgcoge.c | 130 +
5 files changed, 1213 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/boot/dts/mgcoge.dts
create mode 100644 arch/powerpc/configs/mgcoge_defconfig
create mode 100644 arch/powerpc/platforms/82xx/mgcoge.c
diff --git a/arch/powerpc/boot/dts/mgcoge.dts
b/arch/powerpc/boot/dts/mgcoge.dts
new file mode 100644
index 000..54d49c5
--- /dev/null
+++ b/arch/powerpc/boot/dts/mgcoge.dts
[snip]
+ [EMAIL PROTECTED] {
+ compatible = fsl,mpc8247-localbus,
+ fsl,pq2-localbus,
+ simple-bus;
+ #address-cells = 2;
+ #size-cells = 1;
+ reg = 0xf0010100 0x40;
+
+ ranges = 0 0 0xfe00 0x0040
+ 1 0 0x5000 0x2000
+ ; /* Filled in by U-Boot */
+
+ [EMAIL PROTECTED],0 {
+ compatible = cfi-flash;
+ reg = 0 0x0 0x40;
+ #address-cells = 1;
+ #size-cells = 1;
+ bank-width = 1;
+ device-width = 1;
+ [EMAIL PROTECTED] {
+ label = u-boot;
+ reg = 0 0x4;
+ };
+ [EMAIL PROTECTED] {
+ label = env;
+ reg = 0x4 0x2;
+ };
+ [EMAIL PROTECTED] {
+ label = kernel;
+ reg = 0x6 0x22;
+ };
+ [EMAIL PROTECTED] {
+ label = dtb;
+ reg = 0x28 0x2;
+ };
+ };
+
+ [EMAIL PROTECTED],0 {
From the 'reg' below and the 'ranges' above, this looks like it should
be [EMAIL PROTECTED],0.
+ compatible = cfi-flash;
+ reg = 1 0x0 0x200;
+ #address-cells = 1;
+ #size-cells = 1;
+ bank-width = 2;
+ device-width = 2;
+ [EMAIL PROTECTED] {
+ label = ramdisk;
+ reg = 0 0x7a;
+ };
+ [EMAIL PROTECTED] {
+ label = user;
+ reg = 0x7a 0x186;
+ };
+ };
+ };
--
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: BUG() in current git, __dma_alloc_coherent, Beige G3
On Mon, Jun 16, 2008 at 02:50:38PM +1000, Benjamin Herrenschmidt wrote: On Sun, 2008-06-15 at 21:46 -0400, Joseph Fannin wrote: Hello! I'm reproducably hitting a BUG() in Linus' git (current as of about noon, Sunday 15, GMT -0500) on my Beige PowerMac G3 (32bit, natch). The line indicted in the (hand-copied) traceback that follows is: BUG_ON(!pte_none(*pte)); ...in __dma_alloc_coherent(). .../... [ 261.043131] [ cut here ] [ 261.044194] kernel BUG at arch/powerpc/lib/dma-noncoherent.c:209! I wonder how you end up hitting code in dma-noncoherent.c in the first place ! PowerMac kernels should not have that code compiled in at all... I think it's because PPC_PRPMC2800 and MPC5121_ADS both live under PPC_MULTIPLATFORM, and end up selecting NOT_COHERENT_CACHE. If the button in Kconfig isn't labeled Do Not Push, heck, I'll build it. -- Joseph Fannin [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Carol Dann is out of the office.
I will be out of the office starting 06/16/2008 and will not return until 07/07/2008. Should you need any assistance on RS6000/AIX/TSM , please contact : Mr. Obaid Farghani at 201-413-8028 ([EMAIL PROTECTED]), Mr. Paul Giglio at 201-413-8280 ([EMAIL PROTECTED]) or Mr. Gary Fatone at 201-413-8955 ([EMAIL PROTECTED] ) Thank you. I will respond to your message when I return. Regards, Carol - This electronic mail message, and any of the accompanying documents, may contain confidential or privileged information. Any unauthorized disclosure or distribution of such information is strictly prohibited. If you are not the intended recipient of this message, please notify the sender immediately and destroy the message. Messages sent through electronic media may be subject to delays or unauthorized alterations. Neither The Bank of Tokyo-Mitsubishi UFJ, Ltd. nor any of its affiliates is responsible for any such delay or alteration. This message may contain a commercial advertisement or promotion of a commercial product or service. If you do not wish to receive messages of this kind from the sender in the future, please reply to this message and type REMOVE MY EMAIL ADDRESS in the subject field, or write to the sender at 1251 Avenue of the Americas, New York, NY 10020-1104. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/2] fs_enet: MDIO on GPIO support
On Monday 26 May 2008 11:53, Laurent Pinchart wrote:
Port the fs_enet driver to support the MDIO on GPIO driver for PHY access
in addition to the mii-bitbang driver.
Now that 1/2 has been applied by Jeff, could this one make it to
powerpc-next ?
Signed-off-by: Laurent Pinchart [EMAIL PROTECTED]
---
drivers/net/fs_enet/fs_enet-main.c | 31 ---
1 files changed, 20 insertions(+), 11 deletions(-)
diff --git a/drivers/net/fs_enet/fs_enet-main.c
b/drivers/net/fs_enet/fs_enet-main.c
index 67b4b07..b0eb1d2 100644
--- a/drivers/net/fs_enet/fs_enet-main.c
+++ b/drivers/net/fs_enet/fs_enet-main.c
@@ -43,6 +43,7 @@
#include asm/uaccess.h
#ifdef CONFIG_PPC_CPM_NEW_BINDING
+#include linux/of_gpio.h
#include asm/of_platform.h
#endif
@@ -1172,8 +1173,7 @@ static int __devinit find_phy(struct device_node *np,
struct fs_platform_info *fpi)
{
struct device_node *phynode, *mdionode;
- struct resource res;
- int ret = 0, len;
+ int ret = 0, len, bus_id;
const u32 *data;
data = of_get_property(np, fixed-link, NULL);
@@ -1190,19 +1190,28 @@ static int __devinit find_phy(struct device_node
*np,
if (!phynode)
return -EINVAL;
- mdionode = of_get_parent(phynode);
- if (!mdionode)
+ data = of_get_property(phynode, reg, len);
+ if (!data || len != 4) {
+ ret = -EINVAL;
goto out_put_phy;
+ }
- ret = of_address_to_resource(mdionode, 0, res);
- if (ret)
- goto out_put_mdio;
+ mdionode = of_get_parent(phynode);
+ if (!mdionode) {
+ ret = -EINVAL;
+ goto out_put_phy;
+ }
- data = of_get_property(phynode, reg, len);
- if (!data || len != 4)
- goto out_put_mdio;
+ bus_id = of_get_gpio(mdionode, 0);
+ if (bus_id 0) {
+ struct resource res;
+ ret = of_address_to_resource(mdionode, 0, res);
+ if (ret)
+ goto out_put_mdio;
+ bus_id = res.start;
+ }
- snprintf(fpi-bus_id, 16, %x:%02x, res.start, *data);
+ snprintf(fpi-bus_id, 16, %x:%02x, bus_id, *data);
out_put_mdio:
of_node_put(mdionode);
--
1.5.0
--
Laurent Pinchart
CSE Semaphore Belgium
Chaussee de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
F +32 (2) 387 42 75
pgpUol02feTbo.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [82xx] powerpc: Add support for mpc8247 based board MGCOGE from keymile.
Hello David,
David Gibson wrote:
On Fri, Jun 13, 2008 at 06:33:08PM +0200, Heiko Schocher wrote:
Hello Scott,
here comes the updated version for the mgcoge port, with your
suggestions:
[powerpc] Added support for the MPC8247 based board MGCOGE
from Keymile.
Signed-off-by: Heiko Schocher [EMAIL PROTECTED]
---
arch/powerpc/boot/dts/mgcoge.dts | 174 +++
arch/powerpc/configs/mgcoge_defconfig | 900
+
arch/powerpc/platforms/82xx/Kconfig |8 +
arch/powerpc/platforms/82xx/Makefile |1 +
arch/powerpc/platforms/82xx/mgcoge.c | 130 +
5 files changed, 1213 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/boot/dts/mgcoge.dts
create mode 100644 arch/powerpc/configs/mgcoge_defconfig
create mode 100644 arch/powerpc/platforms/82xx/mgcoge.c
diff --git a/arch/powerpc/boot/dts/mgcoge.dts
b/arch/powerpc/boot/dts/mgcoge.dts
new file mode 100644
index 000..54d49c5
--- /dev/null
+++ b/arch/powerpc/boot/dts/mgcoge.dts
[snip]
[snip]
+[EMAIL PROTECTED],0 {
From the 'reg' below and the 'ranges' above, this looks like it should
be [EMAIL PROTECTED],0.
+compatible = cfi-flash;
+reg = 1 0x0 0x200;
+#address-cells = 1;
The reg entry is wrong, the Flash is on CS5. Here the updated version of
the patch:
[powerpc] Added support for the MPC8247 based board MGCOGE
from Keymile.
Signed-off-by: Heiko Schocher [EMAIL PROTECTED]
---
arch/powerpc/boot/dts/mgcoge.dts | 174 +++
arch/powerpc/configs/mgcoge_defconfig | 900 +
arch/powerpc/platforms/82xx/Kconfig |8 +
arch/powerpc/platforms/82xx/Makefile |1 +
arch/powerpc/platforms/82xx/mgcoge.c | 130 +
5 files changed, 1213 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/boot/dts/mgcoge.dts
create mode 100644 arch/powerpc/configs/mgcoge_defconfig
create mode 100644 arch/powerpc/platforms/82xx/mgcoge.c
diff --git a/arch/powerpc/boot/dts/mgcoge.dts b/arch/powerpc/boot/dts/mgcoge.dts
new file mode 100644
index 000..ecce20d
--- /dev/null
+++ b/arch/powerpc/boot/dts/mgcoge.dts
@@ -0,0 +1,174 @@
+/*
+ * Device Tree for the MGCOGE plattform from keymile
+ *
+ * Copyright 2008 DENX Software Engineering GmbH
+ * Heiko Schocher [EMAIL PROTECTED]
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+/dts-v1/;
+/ {
+ model = MGCOGE;
+ compatible = keymile,mgcoge;
+ #address-cells = 1;
+ #size-cells = 1;
+
+ aliases {
+ ethernet0 = eth0;
+ serial0 = smc2;
+ };
+
+ cpus {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ PowerPC,[EMAIL PROTECTED] {
+ device_type = cpu;
+ reg = 0;
+ d-cache-line-size = 32;
+ i-cache-line-size = 32;
+ d-cache-size = 16384;
+ i-cache-size = 16384;
+ timebase-frequency = 0; /* Filled in by U-Boot */
+ clock-frequency = 0; /* Filled in by U-Boot */
+ bus-frequency = 0; /* Filled in by U-Boot */
+ };
+ };
+
+ [EMAIL PROTECTED] {
+ compatible = fsl,mpc8247-localbus,
+fsl,pq2-localbus,
+simple-bus;
+ #address-cells = 2;
+ #size-cells = 1;
+ reg = 0xf0010100 0x40;
+
+ ranges = 0 0 0xfe00 0x0040
+ 1 0 0x5000 0x2000
+ ; /* Filled in by U-Boot */
+
+ [EMAIL PROTECTED],0 {
+ compatible = cfi-flash;
+ reg = 0 0x0 0x40;
+ #address-cells = 1;
+ #size-cells = 1;
+ bank-width = 1;
+ device-width = 1;
+ [EMAIL PROTECTED] {
+ label = u-boot;
+ reg = 0 0x4;
+ };
+ [EMAIL PROTECTED] {
+ label = env;
+ reg = 0x4 0x2;
+ };
+ [EMAIL PROTECTED] {
+ label = kernel;
+ reg = 0x6 0x22;
+ };
+ [EMAIL PROTECTED] {
+ label = dtb;
+ reg = 0x28 0x2;
+ };
+ };
+
+ [EMAIL
Re: BUG() in current git, __dma_alloc_coherent, Beige G3
On Mon, 2008-06-16 at 03:30 -0400, Joseph Fannin wrote: I think it's because PPC_PRPMC2800 and MPC5121_ADS both live under PPC_MULTIPLATFORM, and end up selecting NOT_COHERENT_CACHE. If the button in Kconfig isn't labeled Do Not Push, heck, I'll build it. Heh, ok, disable those then. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [git pull] Please pull powerpc.git merge branch
Linus, As Ben pointed out, I had forgotten to re-do a couple of defconfigs where I had inadvertently turned off the SATA driver for the G5 powermacs. So when you do the pull as I requested earlier from git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git merge you'll also get one more commit as listed below. Thanks, Paul. arch/powerpc/configs/g5_defconfig| 62 ++-- arch/powerpc/configs/ppc64_defconfig | 66 -- 2 files changed, 122 insertions(+), 6 deletions(-) Paul Mackerras (1): [POWERPC] Turn on ATA_SFF so we get SATA_SVW back in defconfigs - In case you want the full diffstat and shortlog, here they are: arch/powerpc/Makefile |4 arch/powerpc/boot/Makefile|2 arch/powerpc/boot/crtsavres.S | 233 +++ arch/powerpc/boot/dts/mpc8377_rdb.dts |8 - arch/powerpc/boot/dts/mpc8378_rdb.dts |8 - arch/powerpc/boot/dts/mpc8379_rdb.dts |8 - arch/powerpc/boot/dts/mpc8548cds.dts |4 arch/powerpc/configs/83xx/mpc8313_rdb_defconfig | 155 +++--- arch/powerpc/configs/83xx/mpc8315_rdb_defconfig | 162 +++ arch/powerpc/configs/83xx/mpc832x_mds_defconfig | 146 ++ arch/powerpc/configs/83xx/mpc832x_rdb_defconfig | 150 +++--- arch/powerpc/configs/83xx/mpc834x_itx_defconfig | 157 +++--- arch/powerpc/configs/83xx/mpc834x_itxgp_defconfig | 150 ++ arch/powerpc/configs/83xx/mpc834x_mds_defconfig | 146 ++ arch/powerpc/configs/83xx/mpc836x_mds_defconfig | 146 ++ arch/powerpc/configs/83xx/mpc837x_mds_defconfig | 146 ++ arch/powerpc/configs/83xx/mpc837x_rdb_defconfig | 224 +++ arch/powerpc/configs/83xx/sbc834x_defconfig | 140 ++--- arch/powerpc/configs/85xx/ksi8560_defconfig | 168 +++ arch/powerpc/configs/85xx/mpc8540_ads_defconfig | 133 ++--- arch/powerpc/configs/85xx/mpc8544_ds_defconfig| 210 +- arch/powerpc/configs/85xx/mpc8560_ads_defconfig | 135 ++--- arch/powerpc/configs/85xx/mpc8568mds_defconfig| 150 ++ arch/powerpc/configs/85xx/mpc8572_ds_defconfig| 210 +- arch/powerpc/configs/85xx/mpc85xx_cds_defconfig | 137 ++--- arch/powerpc/configs/85xx/sbc8548_defconfig | 131 ++--- arch/powerpc/configs/85xx/sbc8560_defconfig | 135 ++--- arch/powerpc/configs/85xx/stx_gp3_defconfig | 152 ++ arch/powerpc/configs/85xx/tqm8540_defconfig | 147 ++ arch/powerpc/configs/85xx/tqm8541_defconfig | 146 ++ arch/powerpc/configs/85xx/tqm8555_defconfig | 146 ++ arch/powerpc/configs/85xx/tqm8560_defconfig | 146 ++ arch/powerpc/configs/adder875_defconfig | 52 ++- arch/powerpc/configs/ep8248e_defconfig| 124 ++-- arch/powerpc/configs/ep88xc_defconfig | 47 ++- arch/powerpc/configs/g5_defconfig | 62 arch/powerpc/configs/linkstation_defconfig| 172 +++ arch/powerpc/configs/mpc7448_hpc2_defconfig | 136 ++--- arch/powerpc/configs/mpc8272_ads_defconfig| 126 ++-- arch/powerpc/configs/mpc83xx_defconfig| 151 ++ arch/powerpc/configs/mpc85xx_defconfig| 230 ++- arch/powerpc/configs/mpc8610_hpcd_defconfig | 316 - arch/powerpc/configs/mpc8641_hpcn_defconfig | 210 +- arch/powerpc/configs/mpc866_ads_defconfig | 128 ++--- arch/powerpc/configs/mpc885_ads_defconfig | 47 ++- arch/powerpc/configs/ppc64_defconfig | 66 arch/powerpc/configs/pq2fads_defconfig| 133 ++--- arch/powerpc/configs/prpmc2800_defconfig | 153 +++--- arch/powerpc/configs/sbc8641d_defconfig | 150 ++ arch/powerpc/configs/storcenter_defconfig | 71 +++-- arch/powerpc/kernel/irq.c |2 arch/powerpc/kernel/ppc_ksyms.c |2 arch/powerpc/kernel/prom_init_check.sh| 14 + arch/powerpc/lib/Makefile |2 arch/powerpc/lib/crtsavres.S | 229 +++ arch/powerpc/platforms/85xx/Kconfig |1 arch/powerpc/platforms/cell/spu_base.c| 44 ++- arch/powerpc/platforms/cell/spufs/run.c | 21 + arch/powerpc/platforms/cell/spufs/sched.c | 19 + arch/powerpc/platforms/pseries/eeh_driver.c | 11 - arch/powerpc/platforms/pseries/nvram.c|4 arch/powerpc/xmon/xmon.c |1 drivers/macintosh/mediabay.c |4 drivers/macintosh/smu.c |5 drivers/macintosh/therm_adt746x.c
Re: [git pull] Please pull powerpc.git merge branch
On Mon, Jun 16, 2008 at 09:25:05PM +1000, Paul Mackerras wrote: Linus, As Ben pointed out, I had forgotten to re-do a couple of defconfigs where I had inadvertently turned off the SATA driver for the G5 powermacs. So when you do the pull as I requested earlier from git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git merge you'll also get one more commit as listed below. Thanks, Paul. arch/powerpc/configs/g5_defconfig| 62 ++-- arch/powerpc/configs/ppc64_defconfig | 66 -- 2 files changed, 122 insertions(+), 6 deletions(-) Paul Mackerras (1): [POWERPC] Turn on ATA_SFF so we get SATA_SVW back in defconfigs ... What about my patch [1] to eliminate this new trap in kconfig since we do not have to bother kconfig users with ATA_SFF at all? Besides some orthoginal discussion whether this stuff should actually be called SFF I am not aware of any reactions to my patch from the ATA people. I already sent this patch twice and I can update it to the latest tree if it's considered OK, but I'd like to get some ACK/NAK first. cu Adrian [1] http://lkml.org/lkml/2008/4/21/501 -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Xilinx EDK 10.1 and XUPV2P: A little report
Hello list I have tried to port Linux 2.6 (xilinx git) to a XUPV2P board running a system implemented with EDK10.1 (Linux Version). I have fail, and I think I now why, this is a little report written for saving you some time (and maybe solving my problem if I am doing something wrong) The board is not supported by EDK 10.1, but I have found a Board Support File form https://wiki.ittc.ku.edu that seems to work. To start I have created a design that consists on a ppc, the mpmc, an uartlite, an interrupt manager and some bram. The basic programs: Test memory and peripherals worked ok on it. I have downloaded the kernel form xilinx git and adapted the xparameters file to fit my design. I have created a toolchain using OpenEmbedded and compiled the kernel with it, then I have downloaded the binary to the board and everything works fine until Now booting the kernel Debugging the kernel I have found that the system crashes (Exception 0x700) setting the mmu inside start_here (head_4xx.S)... Because it was a crash in the very beginning of my kernel live I developed some simple apps to tests all my peripherals and they worked ok in real mode: All of them worked OK BUT I have created a small piece of code that tests the peripherals in virtual mode and when the program is linked to the ram the system crashes!! Strangely, it works ok when it runs from bram. The same code works perfectly on a design created with EDK 8.1 and the kernel also works fine. I attach the source code of my test app parameters I have used. Best Regards -- Ricardo Ribalda http://www.eps.uam.es/~rribalda/ ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Using DMA interrupt on MPC8313
Ron Madrid wrote: So are you implying that the request_irq function should work without any other initialization function before it? No, I'm saying that you'll get a more accurate assessment of why it fails if you see where it returns an error code. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [RFC v3] OF: OpenFirmware bindings for the mmc_spi driver
On Sat, Jun 14, 2008 at 9:57 AM, Pierre Ossman [EMAIL PROTECTED] wrote: On Thu, 5 Jun 2008 20:16:24 +0400 Anton Vorontsov [EMAIL PROTECTED] wrote: Here is v3. I'm out of ideas if you won't like it. :-) v3: - Now these bindings are using bus notifiers chain, thus we adhere to the spi bus. Now this was nice and clean. I take it Grant doesn't like this version though. What's the downside of it? No, I don't. I like the v2 approach better as long as it is been changed to address your comments. This approach I think is needlessly complex and non-obvious (relying on the notification chain instead of being part of the probe call). It will break in non-obvious ways if the notifier module is loaded after the mmc_spi driver. Cheers, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: 4xx support in arch/ppc is going away Real Soon Now
On Sunday 08 June 2008 17:54, Jon Loeliger wrote: Grant Likely writes: Oh, and we're going try to create the longest acked-by chain in Linux history. Cool :) Paul. So far, I think it looks like this, sorted: Acked-by: Arnd Bergmann [EMAIL PROTECTED] Acked-by: Becky Bruce [EMAIL PROTECTED] Acked-by: Benjamin Herrenschmidt [EMAIL PROTECTED] Acked-by: Grant Likely [EMAIL PROTECTED] Acked-by: Jochen Friedrich [EMAIL PROTECTED] Acked-by: Jon Loeliger [EMAIL PROTECTED] Acked-by: Josh Boyer [EMAIL PROTECTED] Acked-by: Kumar Gala [EMAIL PROTECTED] Acked-by: Olof Johansson [EMAIL PROTECTED] Acked-by: Peter Korsgaard [EMAIL PROTECTED] Acked-by: Scott Wood [EMAIL PROTECTED] Acked-by: Sean MacLennan [EMAIL PROTECTED] Acked-by: Segher Boessenkool [EMAIL PROTECTED] Acked-by: Stefan Roese [EMAIL PROTECTED] Acked-by: Stephen Neuendorffer [EMAIL PROTECTED] Acked-by: Wolfgang Denk [EMAIL PROTECTED] I'm not sure, but I _think_ there are a few other PowerPC developers out there still... :-) jdl Acked-by: Matthias Fuchs [EMAIL PROTECTED] It seems that I have to post cpci405 patches for arch/powerpc soon. The board is still active! Nobody would believe it :-) Matthias ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Using DMA interrupt on MPC8313
What does your code actually look like. In your driver how are you getting the IRQ value that you pass to request_irq? - k On Jun 13, 2008, at 6:52 PM, Ron Madrid wrote: I don't know why request_irq is succeeding when the fsldma and dmaengine drivers are installed. I'm using the same dts in both cases. Ron --- Kumar Gala [EMAIL PROTECTED] wrote: That's a bit odd. How is your driver getting the IRQ its requesting? Are you using the same .dts in both cases? - k On Jun 13, 2008, at 2:02 PM, Ron Madrid wrote: So after I've built the kernel to include the dmaengine and fsldma drivers, my driver is allowed to register its ISR via request_irq. However, if these drivers are not installed then request_irq fails in my driver. So it seems that there is some other initialization happening before request_irq is being called in fsldma and subsequently my driver. Does anyone know what this is? Ron --- Kumar Gala [EMAIL PROTECTED] wrote: The dmaengine provides a generic set of APIs w/a FSL dma backend. It might be the case that your need of dma doesnt fit into the current set of APIs. - k On Jun 12, 2008, at 3:04 PM, Ron Madrid wrote: Well in that case wouldn't I need to use the fsldma driver? Or is dmaengine a generic dma driver? Ron --- Kumar Gala [EMAIL PROTECTED] wrote: On Jun 12, 2008, at 2:35 PM, Ron Madrid wrote: I'm trying to write a driver that would make use of the DMA on the MPC8313. I'm attempting to register the interrupt with request_irq but it is not passing. Is there something that I need to do before I call request_irq, maybe in the dts or somewhere else? any reason you aren't using the dmaengine driver? - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc/booke: Add support for new e500mc core
The new e500mc core from Freescale is based on the e500v2 but with the
following changes:
* Supports only the Enhanced Debug Architecture (DSRR0/1, etc)
* Floating Point
* No SPE
* Supports lwsync
* Doorbell Exceptions
* Hypervisor
---
In my powerpc-next tree.
arch/powerpc/kernel/cputable.c | 15 +++
arch/powerpc/kernel/head_booke.h |6 +-
arch/powerpc/kernel/head_fsl_booke.S | 10 --
arch/powerpc/platforms/Kconfig.cputype | 10 --
include/asm-powerpc/cache.h|3 +++
include/asm-powerpc/cputable.h |6 --
include/asm-powerpc/synch.h|2 +-
7 files changed, 44 insertions(+), 8 deletions(-)
diff --git a/arch/powerpc/kernel/cputable.c b/arch/powerpc/kernel/cputable.c
index e44d553..36fa061 100644
--- a/arch/powerpc/kernel/cputable.c
+++ b/arch/powerpc/kernel/cputable.c
@@ -1522,6 +1522,21 @@ static struct cpu_spec __initdata cpu_specs[] = {
.machine_check = machine_check_e500,
.platform = ppc8548,
},
+ { /* e500mc */
+ .pvr_mask = 0x,
+ .pvr_value = 0x8023,
+ .cpu_name = e500mc,
+ /* xxx - galak: add CPU_FTR_MAYBE_CAN_DOZE */
+ .cpu_features = CPU_FTRS_E500MC,
+ .cpu_user_features = COMMON_USER_BOOKE |
PPC_FEATURE_HAS_FPU,
+ .icache_bsize = 64,
+ .dcache_bsize = 64,
+ .num_pmcs = 4,
+ .oprofile_cpu_type = ppc/e500, /* xxx - galak, e500mc? */
+ .oprofile_type = PPC_OPROFILE_FSL_EMB,
+ .machine_check = machine_check_e500,
+ .platform = ppc4080,
+ },
{ /* default match */
.pvr_mask = 0x,
.pvr_value = 0x,
diff --git a/arch/powerpc/kernel/head_booke.h b/arch/powerpc/kernel/head_booke.h
index 9501c58..505494f 100644
--- a/arch/powerpc/kernel/head_booke.h
+++ b/arch/powerpc/kernel/head_booke.h
@@ -68,9 +68,13 @@
#define MCHECK_STACK_BASE mcheckirq_ctx
#define CRIT_STACK_BASEcritirq_ctx
-/* only on e200 for now */
+/* only on e500mc/e200 */
#define DEBUG_STACK_BASE dbgirq_ctx
+#ifdef CONFIG_PPC_E500MC
+#define DEBUG_SPRG SPRN_SPRG9
+#else
#define DEBUG_SPRG SPRN_SPRG6W
+#endif
#define EXC_LVL_FRAME_OVERHEAD (THREAD_SIZE - INT_FRAME_SIZE - EXC_LVL_SIZE)
diff --git a/arch/powerpc/kernel/head_fsl_booke.S
b/arch/powerpc/kernel/head_fsl_booke.S
index 503f860..7c2b653 100644
--- a/arch/powerpc/kernel/head_fsl_booke.S
+++ b/arch/powerpc/kernel/head_fsl_booke.S
@@ -304,7 +304,7 @@ skpinv: addir6,r6,1 /*
Increment */
SET_IVOR(13, DataTLBError);
SET_IVOR(14, InstructionTLBError);
SET_IVOR(15, DebugDebug);
-#if defined(CONFIG_E500)
+#if defined(CONFIG_E500) !defined(CONFIG_PPC_E500MC)
SET_IVOR(15, DebugCrit);
#endif
SET_IVOR(32, SPEUnavailable);
@@ -313,6 +313,9 @@ skpinv: addir6,r6,1 /*
Increment */
#ifndef CONFIG_E200
SET_IVOR(35, PerformanceMonitor);
#endif
+#ifdef CONFIG_PPC_E500MC
+ SET_IVOR(36, Doorbell);
+#endif
/* Establish the interrupt vector base */
lis r4,[EMAIL PROTECTED]/* IVPR only uses the high 16-bits */
@@ -750,10 +753,13 @@ interrupt_base:
/* Performance Monitor */
EXCEPTION(0x2060, PerformanceMonitor, performance_monitor_exception,
EXC_XFER_STD)
+#ifdef CONFIG_PPC_E500MC
+ EXCEPTION(0x2070, Doorbell, unknown_exception, EXC_XFER_EE)
+#endif
/* Debug Interrupt */
DEBUG_DEBUG_EXCEPTION
-#if defined(CONFIG_E500)
+#if defined(CONFIG_E500) !defined(CONFIG_PPC_E500MC)
DEBUG_CRIT_EXCEPTION
#endif
diff --git a/arch/powerpc/platforms/Kconfig.cputype
b/arch/powerpc/platforms/Kconfig.cputype
index f7efaa9..9e67cf1 100644
--- a/arch/powerpc/platforms/Kconfig.cputype
+++ b/arch/powerpc/platforms/Kconfig.cputype
@@ -95,6 +95,12 @@ config E500
select FSL_EMB_PERFMON
bool
+config PPC_E500MC
+ bool e500mc Support
+ select PPC_FPU
+ depends on E500
+ default n
+
config PPC_FPU
bool
default y if PPC64
@@ -157,7 +163,7 @@ config ALTIVEC
config SPE
bool SPE Support
- depends on E200 || E500
+ depends on E200 || (E500 !PPC_E500MC)
default y
---help---
This option enables kernel support for the Signal Processing
@@ -201,7 +207,7 @@ config VIRT_CPU_ACCOUNTING
If in doubt, say Y here.
config SMP
- depends on PPC_STD_MMU
+ depends on PPC_STD_MMU || FSL_BOOKE
bool Symmetric multi-processing support
---help---
This enables support for
Re: [PATCH 02/19] powerpc: Split processor entitlement retrieval and gathering to helper routines
Split the retrieval and setting of processor entitlement and weight into
helper routines. This also removes the printing of the raw values
returned from h_get_ppp, the values are already parsed and printed.
Signed-off-by: Nathan Fontenot [EMAIL PROTECTED]
---
arch/powerpc/kernel/lparcfg.c | 163
++
1 file changed, 86 insertions(+), 77 deletions(-)
Index: linux-2.6.git/arch/powerpc/kernel/lparcfg.c
===
--- linux-2.6.git.orig/arch/powerpc/kernel/lparcfg.c 2008-06-16
10:22:42.0 -0500
+++ linux-2.6.git/arch/powerpc/kernel/lparcfg.c 2008-06-16
10:32:29.0 -0500
@@ -167,7 +167,8 @@
return rc;
}
-static void h_pic(unsigned long *pool_idle_time, unsigned long *num_procs)
+static unsigned int h_pic(unsigned long *pool_idle_time,
+ unsigned long *num_procs)
{
unsigned long rc;
unsigned long retbuf[PLPAR_HCALL_BUFSIZE];
@@ -176,6 +177,53 @@
*pool_idle_time = retbuf[0];
*num_procs = retbuf[1];
+
+ return rc;
+}
+
+/*
+ * parse_ppp_data
+ * Parse out the data returned from h_get_ppp and h_pic
+ */
+static void parse_ppp_data(struct seq_file *m)
+{
+ unsigned long h_entitled, h_unallocated;
+ unsigned long h_aggregation, h_resource;
+ int rc;
+
+ rc = h_get_ppp(h_entitled, h_unallocated, h_aggregation,
+ h_resource);
+ if (rc)
+ return;
+
+ seq_printf(m, partition_entitled_capacity=%ld\n, h_entitled);
+ seq_printf(m, group=%ld\n, (h_aggregation 2 * 8) 0x);
+ seq_printf(m, system_active_processors=%ld\n,
+ (h_resource 0 * 8) 0x);
+
+ /* pool related entries are apropriate for shared configs */
+ if (lppaca[0].shared_proc) {
+ unsigned long pool_idle_time, pool_procs;
+
+ seq_printf(m, pool=%ld\n, (h_aggregation 0 * 8) 0x);
+
+ /* report pool_capacity in percentage */
+ seq_printf(m, pool_capacity=%ld\n,
+ ((h_resource 2 * 8) 0x) * 100);
+
+ rc = h_pic(pool_idle_time, pool_procs);
+ if (! rc) {
+ seq_printf(m, pool_idle_time=%ld\n, pool_idle_time);
+ seq_printf(m, pool_num_procs=%ld\n, pool_procs);
+ }
+ }
+
+ seq_printf(m, unallocated_capacity_weight=%ld\n,
+ (h_resource 4 * 8) 0xFF);
+
+ seq_printf(m, capacity_weight=%ld\n, (h_resource 5 * 8) 0xFF);
+ seq_printf(m, capped=%ld\n, (h_resource 6 * 8) 0x01);
+ seq_printf(m, unallocated_capacity=%ld\n, h_unallocated);
}
#define SPLPAR_CHARACTERISTICS_TOKEN 20
@@ -302,59 +350,11 @@
partition_active_processors = lparcfg_count_active_processors();
if (firmware_has_feature(FW_FEATURE_SPLPAR)) {
- unsigned long h_entitled, h_unallocated;
- unsigned long h_aggregation, h_resource;
- unsigned long pool_idle_time, pool_procs;
- unsigned long purr;
-
- h_get_ppp(h_entitled, h_unallocated, h_aggregation,
- h_resource);
-
- seq_printf(m, R4=0x%lx\n, h_entitled);
- seq_printf(m, R5=0x%lx\n, h_unallocated);
- seq_printf(m, R6=0x%lx\n, h_aggregation);
- seq_printf(m, R7=0x%lx\n, h_resource);
-
- purr = get_purr();
-
/* this call handles the ibm,get-system-parameter contents */
parse_system_parameter_string(m);
+ parse_ppp_data(m);
- seq_printf(m, partition_entitled_capacity=%ld\n, h_entitled);
-
- seq_printf(m, group=%ld\n, (h_aggregation 2 * 8) 0x);
-
- seq_printf(m, system_active_processors=%ld\n,
- (h_resource 0 * 8) 0x);
-
- /* pool related entries are apropriate for shared configs */
- if (lppaca[0].shared_proc) {
-
- h_pic(pool_idle_time, pool_procs);
-
- seq_printf(m, pool=%ld\n,
- (h_aggregation 0 * 8) 0x);
-
- /* report pool_capacity in percentage */
- seq_printf(m, pool_capacity=%ld\n,
- ((h_resource 2 * 8) 0x) * 100);
-
- seq_printf(m, pool_idle_time=%ld\n, pool_idle_time);
-
- seq_printf(m, pool_num_procs=%ld\n, pool_procs);
- }
-
- seq_printf(m, unallocated_capacity_weight=%ld\n,
- (h_resource 4 * 8) 0xFF);
-
- seq_printf(m, capacity_weight=%ld\n,
- (h_resource 5 * 8) 0xFF);
-
- seq_printf(m, capped=%ld\n, (h_resource 6 * 8) 0x01);
-
- seq_printf(m,
[PATCH 03/19][v2] powerpc: Add memory entitlement capabilities to /proc/ppc64/lparcfg
This patch has been updated to remove a piece that is now included
in patch 2/19 of this series where it should be.
-Nathan
Update /proc/ppc64/lparcfg to enable displaying of Cooperative Memory
Overcommitment statistics as reported by the H_GET_MPP hcall. This also
updates the lparcfg interface to allow setting memory entitlement and
weight.
Signed-off-by: Nathan Fontenot [EMAIL PROTECTED]
---
arch/powerpc/kernel/lparcfg.c | 139
+++---
include/asm-powerpc/hvcall.h | 18 +
2 files changed, 147 insertions(+), 10 deletions(-)
Index: linux-2.6.git/arch/powerpc/kernel/lparcfg.c
===
--- linux-2.6.git.orig/arch/powerpc/kernel/lparcfg.c 2008-06-16
10:32:29.0 -0500
+++ linux-2.6.git/arch/powerpc/kernel/lparcfg.c 2008-06-16
10:47:55.0 -0500
@@ -129,6 +129,35 @@
/*
* Methods used to fetch LPAR data when running on a pSeries platform.
*/
+/**
+ * h_get_mpp
+ * H_GET_MPP hcall returns info in 7 parms
+ */
+int h_get_mpp(struct hvcall_mpp_data *mpp_data)
+{
+ int rc;
+ unsigned long retbuf[PLPAR_HCALL_BUFSIZE];
+
+ rc = plpar_hcall(H_GET_MPP, retbuf);
+
+ mpp_data-entitled_mem = retbuf[0];
+ mpp_data-mapped_mem = retbuf[1];
+
+ mpp_data-group_num = (retbuf[2] 2 * 8) 0x;
+ mpp_data-pool_num = retbuf[2] 0x;
+
+ mpp_data-mem_weight = (retbuf[3] 7 * 8) 0xff;
+ mpp_data-unallocated_mem_weight = (retbuf[3] 6 * 8) 0xff;
+ mpp_data-unallocated_entitlement = retbuf[3] 0x;
+
+ mpp_data-pool_size = retbuf[4];
+ mpp_data-loan_request = retbuf[5];
+ mpp_data-backing_mem = retbuf[6];
+
+ return rc;
+}
+EXPORT_SYMBOL(h_get_mpp);
+
/*
* H_GET_PPP hcall returns info in 4 parms.
* entitled_capacity,unallocated_capacity,
@@ -226,6 +255,44 @@
seq_printf(m, unallocated_capacity=%ld\n, h_unallocated);
}
+/**
+ * parse_mpp_data
+ * Parse out data returned from h_get_mpp
+ */
+static void parse_mpp_data(struct seq_file *m)
+{
+ struct hvcall_mpp_data mpp_data;
+ int rc;
+
+ rc = h_get_mpp(mpp_data);
+ if (rc)
+ return;
+
+ seq_printf(m, entitled_memory=%ld\n, mpp_data.entitled_mem);
+
+ if (mpp_data.mapped_mem != -1)
+ seq_printf(m, mapped_entitled_memory=%ld\n,
+ mpp_data.mapped_mem);
+
+ seq_printf(m, entitled_memory_group_number=%d\n, mpp_data.group_num);
+ seq_printf(m, entitled_memory_pool_number=%d\n, mpp_data.pool_num);
+
+ seq_printf(m, entitled_memory_weight=%d\n, mpp_data.mem_weight);
+ seq_printf(m, unallocated_entitled_memory_weight=%d\n,
+ mpp_data.unallocated_mem_weight);
+ seq_printf(m, unallocated_io_mapping_entitlement=%ld\n,
+ mpp_data.unallocated_entitlement);
+
+ if (mpp_data.pool_size != -1)
+ seq_printf(m, entitled_memory_pool_size=%ld bytes\n,
+ mpp_data.pool_size);
+
+ seq_printf(m, entitled_memory_loan_request=%ld\n,
+ mpp_data.loan_request);
+
+ seq_printf(m, backing_memory=%ld bytes\n, mpp_data.backing_mem);
+}
+
#define SPLPAR_CHARACTERISTICS_TOKEN 20
#define SPLPAR_MAXLENGTH 1026*(sizeof(char))
@@ -353,6 +420,7 @@
/* this call handles the ibm,get-system-parameter contents */
parse_system_parameter_string(m);
parse_ppp_data(m);
+ parse_mpp_data(m);
seq_printf(m, purr=%ld\n, get_purr());
@@ -417,6 +485,43 @@
return retval;
}
+/**
+ * update_mpp
+ *
+ * Update the memory entitlement and weight for the partition. Caller must
+ * spercify either a new entitlement or weight, not both, to be updated
+ * since the h_set_mpp call takes both entitlement and weight as
parameters.
+ */
+static ssize_t update_mpp(u64 *entitlement, u8 *weight)
+{
+ struct hvcall_mpp_data mpp_data;
+ u64 new_entitled;
+ u8 new_weight;
+ ssize_t rc;
+
+ rc = h_get_mpp(mpp_data);
+ if (rc)
+ return rc;
+
+ if (entitlement) {
+ new_weight = mpp_data.mem_weight;
+ new_entitled = *entitlement;
+ } else if (weight) {
+ new_weight = *weight;
+ new_entitled = mpp_data.entitled_mem;
+ } else
+ return -EINVAL;
+
+ pr_debug(%s: current_entitled = %lu, current_weight = %u\n,
+__FUNCTION__, mpp_data.entitled_mem, mpp_data.mem_weight);
+
+ pr_debug(%s: new_entitled = %lu, new_weight = %u\n,
+__FUNCTION__, new_entitled, new_weight);
+
+ rc = plpar_hcall_norets(H_SET_MPP, new_entitled, new_weight);
+ return rc;
+}
+
/*
* Interface for changing system parameters (variable capacity weight
* and entitled capacity). Format of input is param_name=value;
@@ -470,6 +575,20 @@
[PATCH 4/4] crypto/talitos: add hwrng support
register with the hwrng subsystem to provide entropy to the kernel.
Signed-off-by: Kim Phillips [EMAIL PROTECTED]
---
drivers/crypto/Kconfig |1 +
drivers/crypto/talitos.c | 136 ++
drivers/crypto/talitos.h | 13 -
3 files changed, 126 insertions(+), 24 deletions(-)
diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
index 98d96df..249c135 100644
--- a/drivers/crypto/Kconfig
+++ b/drivers/crypto/Kconfig
@@ -178,6 +178,7 @@ config CRYPTO_DEV_TALITOS
tristate Talitos Freescale Security Engine (SEC)
select CRYPTO_ALGAPI
select CRYPTO_AUTHENC
+ select HW_RANDOM
depends on FSL_SOC
help
Say 'Y' here to use the Freescale Security Engine (SEC)
diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
index 64ddad2..e123312 100644
--- a/drivers/crypto/talitos.c
+++ b/drivers/crypto/talitos.c
@@ -124,6 +124,9 @@ struct talitos_private {
/* list of registered algorithms */
struct list_head alg_list;
+
+ /* hwrng device */
+ struct hwrng rng;
};
/*
@@ -523,8 +526,8 @@ static void talitos_error(unsigned long data)
}
}
}
- if (reset_dev || isr ~TALITOS_ISR_CHERR) {
- dev_err(dev, done overflow or internal time out error:
+ if (reset_dev || isr ~TALITOS_ISR_CHERR || isr_lo) {
+ dev_err(dev, done overflow, internal time out, or rngu error:
ISR 0x%08x_%08x\n, isr, isr_lo);
/* purge request queues */
@@ -549,7 +552,7 @@ static irqreturn_t talitos_interrupt(int irq, void *data)
out_be32(priv-reg + TALITOS_ICR, isr);
out_be32(priv-reg + TALITOS_ICR_LO, isr_lo);
- if (unlikely(isr ~TALITOS_ISR_CHDONE))
+ if (unlikely((isr ~TALITOS_ISR_CHDONE) || isr_lo))
talitos_error((unsigned long)data);
else
if (likely(isr TALITOS_ISR_CHDONE))
@@ -559,6 +562,80 @@ static irqreturn_t talitos_interrupt(int irq, void *data)
}
/*
+ * hwrng
+ */
+static int talitos_rng_data_present(struct hwrng *rng, int wait)
+{
+ struct device *dev = (struct device *)rng-priv;
+ struct talitos_private *priv = dev_get_drvdata(dev);
+ u32 ofl;
+ int i;
+
+ for (i = 0; i 20; i++) {
+ ofl = in_be32(priv-reg + TALITOS_RNGUSR_LO)
+ TALITOS_RNGUSR_LO_OFL;
+ if (ofl || !wait)
+ break;
+ udelay(10);
+ }
+
+ return !!ofl;
+}
+
+static int talitos_rng_data_read(struct hwrng *rng, u32 *data)
+{
+ struct device *dev = (struct device *)rng-priv;
+ struct talitos_private *priv = dev_get_drvdata(dev);
+
+ /* rng fifo requires 64-bit accesses */
+ *data = in_be32(priv-reg + TALITOS_RNGU_FIFO);
+ *data = in_be32(priv-reg + TALITOS_RNGU_FIFO_LO);
+
+ return sizeof(u32);
+}
+
+static int talitos_rng_init(struct hwrng *rng)
+{
+ struct device *dev = (struct device *)rng-priv;
+ struct talitos_private *priv = dev_get_drvdata(dev);
+ unsigned int timeout = TALITOS_TIMEOUT;
+
+ setbits32(priv-reg + TALITOS_RNGURCR_LO, TALITOS_RNGURCR_LO_SR);
+ while (!(in_be32(priv-reg + TALITOS_RNGUSR_LO) TALITOS_RNGUSR_LO_RD)
+ --timeout)
+ cpu_relax();
+ if (timeout == 0) {
+ dev_err(dev, failed to reset rng hw\n);
+ return -ENODEV;
+ }
+
+ /* start generating */
+ setbits32(priv-reg + TALITOS_RNGUDSR_LO, 0);
+
+ return 0;
+}
+
+static int talitos_register_rng(struct device *dev)
+{
+ struct talitos_private *priv = dev_get_drvdata(dev);
+
+ priv-rng.name = dev_driver_string(dev),
+ priv-rng.init = talitos_rng_init,
+ priv-rng.data_present = talitos_rng_data_present,
+ priv-rng.data_read = talitos_rng_data_read,
+ priv-rng.priv = (unsigned long)dev;
+
+ return hwrng_register(priv-rng);
+}
+
+static void talitos_unregister_rng(struct device *dev)
+{
+ struct talitos_private *priv = dev_get_drvdata(dev);
+
+ hwrng_unregister(priv-rng);
+}
+
+/*
* crypto alg
*/
#define TALITOS_CRA_PRIORITY 3000
@@ -1094,6 +1171,26 @@ static int talitos_cra_init(struct crypto_tfm *tfm)
return 0;
}
+/*
+ * given the alg's descriptor header template, determine whether descriptor
+ * type and primary/secondary execution units required match the hw
+ * capabilities description provided in the device tree node.
+ */
+static int hw_supports(struct device *dev, __be32 desc_hdr_template)
+{
+ struct talitos_private *priv = dev_get_drvdata(dev);
+ int ret;
+
+ ret = (1 DESC_TYPE(desc_hdr_template) priv-desc_types)
+ (1 PRIMARY_EU(desc_hdr_template) priv-exec_units);
+
+ if (SECONDARY_EU(desc_hdr_template))
+ ret = ret
[PATCH 2/4] crypto/talitos: unmap h/w generated IV
Signed-off-by: Kim Phillips [EMAIL PROTECTED]
---
drivers/crypto/talitos.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
index f301e95..ce4787e 100644
--- a/drivers/crypto/talitos.c
+++ b/drivers/crypto/talitos.c
@@ -654,6 +654,7 @@ static void ipsec_esp_unmap(struct device *dev,
struct ipsec_esp_edesc *edesc,
struct aead_request *areq)
{
+ unmap_single_talitos_ptr(dev, edesc-desc.ptr[6], DMA_FROM_DEVICE);
unmap_single_talitos_ptr(dev, edesc-desc.ptr[3], DMA_TO_DEVICE);
unmap_single_talitos_ptr(dev, edesc-desc.ptr[2], DMA_TO_DEVICE);
unmap_single_talitos_ptr(dev, edesc-desc.ptr[0], DMA_TO_DEVICE);
--
1.5.6.rc2.26.g8c37
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 3/4] crypto/talitos: fix premature done handling
Since the h/w doesn't support out-of-order processing within a channel, abort channel flush processing in the no-done-bits-and-no-error case so as to not allow premature passthrough to the callback (and thus dropped packets). Signed-off-by: Kim Phillips [EMAIL PROTECTED] --- drivers/crypto/talitos.c |9 +++-- 1 files changed, 7 insertions(+), 2 deletions(-) diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c index ce4787e..64ddad2 100644 --- a/drivers/crypto/talitos.c +++ b/drivers/crypto/talitos.c @@ -307,8 +307,13 @@ static void flush_channel(struct device *dev, int ch, int error, int reset_ch) /* descriptors with their done bits set don't get the error */ rmb(); - status = ((request-desc-hdr DESC_HDR_DONE) - == DESC_HDR_DONE) ? 0 : error; + if ((request-desc-hdr DESC_HDR_DONE) == DESC_HDR_DONE) + status = 0; + else + if (!error) + break; + else + status = error; dma_unmap_single(dev, request-dma_desc, sizeof(struct talitos_desc), DMA_BIDIRECTIONAL); -- 1.5.6.rc2.26.g8c37 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 1/4] crypto/talitos: rm duplicate timeout definition
Signed-off-by: Kim Phillips [EMAIL PROTECTED] --- drivers/crypto/talitos.h |2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git a/drivers/crypto/talitos.h b/drivers/crypto/talitos.h index 989763d..27deb65 100644 --- a/drivers/crypto/talitos.h +++ b/drivers/crypto/talitos.h @@ -28,8 +28,6 @@ * */ -#define TALITOS_TIMEOUT 10 - /* * TALITOS_xxx_LO addresses point to the low data bits (32-63) of the register */ -- 1.5.6.rc2.26.g8c37 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/2] fs_enet: MDIO on GPIO support
On Mon, Jun 16, 2008 at 10:57:02AM +0200, Laurent Pinchart wrote:
On Monday 26 May 2008 11:53, Laurent Pinchart wrote:
Port the fs_enet driver to support the MDIO on GPIO driver for PHY access
in addition to the mii-bitbang driver.
Now that 1/2 has been applied by Jeff, could this one make it to
powerpc-next ?
This patch should probably go through Jeff as well...
Acked-by: Scott Wood [EMAIL PROTECTED]
- data = of_get_property(phynode, reg, len);
- if (!data || len != 4)
- goto out_put_mdio;
+ bus_id = of_get_gpio(mdionode, 0);
+ if (bus_id 0) {
+ struct resource res;
+ ret = of_address_to_resource(mdionode, 0, res);
+ if (ret)
+ goto out_put_mdio;
+ bus_id = res.start;
+ }
- snprintf(fpi-bus_id, 16, %x:%02x, res.start, *data);
+ snprintf(fpi-bus_id, 16, %x:%02x, bus_id, *data);
It'd be nice if this sort of thing could be moved to phylib, so the latter
could simply be passed a device node (in addition to current mechanisms for
the benefit of unfortunate device-tree-less architectures).
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [82xx] powerpc: Add support for mpc8247 based board MGCOGE from keymile.
On Mon, Jun 16, 2008 at 11:40:30AM +0200, Heiko Schocher wrote: The reg entry is wrong, the Flash is on CS5. Here the updated version of the patch: You need to update the ranges property as well. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc/booke: Add support for new e500mc core
On Jun 16, 2008, at 10:46 AM, Kumar Gala wrote:
The new e500mc core from Freescale is based on the e500v2 but with the
following changes:
* Supports only the Enhanced Debug Architecture (DSRR0/1, etc)
* Floating Point
* No SPE
* Supports lwsync
* Doorbell Exceptions
* Hypervisor
---
In my powerpc-next tree.
arch/powerpc/kernel/cputable.c | 15 +++
arch/powerpc/kernel/head_booke.h |6 +-
arch/powerpc/kernel/head_fsl_booke.S | 10 --
arch/powerpc/platforms/Kconfig.cputype | 10 --
include/asm-powerpc/cache.h|3 +++
include/asm-powerpc/cputable.h |6 --
include/asm-powerpc/synch.h|2 +-
7 files changed, 44 insertions(+), 8 deletions(-)
diff --git a/arch/powerpc/kernel/cputable.c b/arch/powerpc/kernel/
cputable.c
index e44d553..36fa061 100644
--- a/arch/powerpc/kernel/cputable.c
+++ b/arch/powerpc/kernel/cputable.c
@@ -1522,6 +1522,21 @@ static struct cpu_spec __initdata cpu_specs
[] = {
.machine_check = machine_check_e500,
.platform = ppc8548,
},
+ { /* e500mc */
+ .pvr_mask = 0x,
+ .pvr_value = 0x8023,
+ .cpu_name = e500mc,
+ /* xxx - galak: add CPU_FTR_MAYBE_CAN_DOZE */
+ .cpu_features = CPU_FTRS_E500MC,
+ .cpu_user_features = COMMON_USER_BOOKE |
PPC_FEATURE_HAS_FPU,
+ .icache_bsize = 64,
+ .dcache_bsize = 64,
+ .num_pmcs = 4,
+ .oprofile_cpu_type = ppc/e500, /* xxx - galak, e500mc? */
+ .oprofile_type = PPC_OPROFILE_FSL_EMB,
+ .machine_check = machine_check_e500,
+ .platform = ppc4080,
+ },
{ /* default match */
.pvr_mask = 0x,
.pvr_value = 0x,
Did you intend to leave your 2 xxx - galak comments in here?
Also, I think you have a problem - you allow CONFIG_SMP to be set
with CONFIG_FSL_BOOKE now, but if you actually turn on CONFIG_SMP, in
pgtable_32.c you're going to have build problems. CONFIG_SMP enables
hash_page_sync(), which we don't have on BookE. You need to add a !
BOOKE to the config protections in pgtable_32.c for hash_page_sync()
declaration and callers.
Cheers,
Becky
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Using DMA interrupt on MPC8313
Here's my code. There are a few other things that happen but they are
inconsequential to this
problem. I'm sure that the request_irq call is right, especially since it
works if the fsldma
drivers are builtin to the kernel. Also, the irq number 71 comes from the
reference manual for
them MPC8313. It is the internal interrupt for the DMA. I'll do some more
testing in a little
while to try to determine the cause of the error in request_irq.
int result = 0;
unsigned int firstminor = 0;
dev_t dev;
printk(KERN_ALERT Hello World Driver! Hi Ron2!\n);
result |= alloc_chrdev_region(dev, firstminor, 1, kModuleName);
if(result 0){
printk(simpc: alloc_chrdev_region failed %u\n, result);
return result;
}
mpc_major = MAJOR(dev);
mpc_minor = MINOR(dev);
printk(KERN_ALERT kModuleName MAJOR NUM = %d\n,mpc_major);
pdx.devno = MKDEV(mpc_major, mpc_minor);
cdev_init(pdx.cdev, mpc_fops);
pdx.cdev.owner = THIS_MODULE;
pdx.cdev.ops = mpc_fops;
result = cdev_add(pdx.cdev, pdx.devno, 1);
if(result)
printk(KERN_ALERT kModuleName -init_module: Error %d adding
pdx.cdev, result);
printk(KERN_ALERT kModuleName -SIMPC_open: Entering\n);
pdx.irq = 71;
printk(KERN_ALERT kModuleName -SIMPC_open: IRQ = %d\n, pdx.irq);
if (pdx.irq == 0){
printk(kModuleName -SIMPC_open: WARNING-cannot get IRQ\n);
return 0;
}
if (request_irq(pdx.irq, SIMPC_isr, IRQF_SHARED, kModuleName, pdx)){
printk(kModuleName -SIMPC_open: ERROR-Interrupt Request
failed.\n
pdx.irq = %d, SIMPC_isr = 0x%x\n,
pdx.irq, (int)SIMPC_isr);
pdx.irq = 0;
}
else
printk(kModuleName -SIMPC_open: found IRQ %d\n, pdx.irq);
--- Kumar Gala [EMAIL PROTECTED] wrote:
What does your code actually look like. In your driver how are you
getting the IRQ value that you pass to request_irq?
- k
On Jun 13, 2008, at 6:52 PM, Ron Madrid wrote:
I don't know why request_irq is succeeding when the fsldma and
dmaengine drivers are installed.
I'm using the same dts in both cases.
Ron
--- Kumar Gala [EMAIL PROTECTED] wrote:
That's a bit odd. How is your driver getting the IRQ its requesting?
Are you using the same .dts in both cases?
- k
On Jun 13, 2008, at 2:02 PM, Ron Madrid wrote:
So after I've built the kernel to include the dmaengine and fsldma
drivers, my driver is allowed
to register its ISR via request_irq. However, if these drivers are
not installed then request_irq
fails in my driver. So it seems that there is some other
initialization happening before
request_irq is being called in fsldma and subsequently my driver.
Does anyone know what this is?
Ron
--- Kumar Gala [EMAIL PROTECTED] wrote:
The dmaengine provides a generic set of APIs w/a FSL dma
backend. It
might be the case that your need of dma doesnt fit into the current
set of APIs.
- k
On Jun 12, 2008, at 3:04 PM, Ron Madrid wrote:
Well in that case wouldn't I need to use the fsldma driver? Or is
dmaengine a generic dma driver?
Ron
--- Kumar Gala [EMAIL PROTECTED] wrote:
On Jun 12, 2008, at 2:35 PM, Ron Madrid wrote:
I'm trying to write a driver that would make use of the DMA on
the
MPC8313. I'm attempting to
register the interrupt with request_irq but it is not
passing. Is
there something that I need to
do before I call request_irq, maybe in the dts or somewhere
else?
any reason you aren't using the dmaengine driver?
- k
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Using DMA interrupt on MPC8313
Ron Madrid wrote: Here's my code. There are a few other things that happen but they are inconsequential to this problem. I'm sure that the request_irq call is right, especially since it works if the fsldma drivers are builtin to the kernel. Also, the irq number 71 comes from the reference manual for them MPC8313. It is the internal interrupt for the DMA. I'll do some more testing in a little while to try to determine the cause of the error in request_irq. You cannot pass hardware IRQ numbers directly to request_irq() -- it has no idea which IRQ controller you're referring to (even if there happens to be only one on your board). You should get the IRQ from the device tree, using irq_of_parse_and_map() on the device node for the DMA channel (see the mpc8377mds device tree for an example DMA node). -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc/booke: Add support for new e500mc core
On Jun 16, 2008, at 11:56 AM, Becky Bruce wrote:
On Jun 16, 2008, at 10:46 AM, Kumar Gala wrote:
The new e500mc core from Freescale is based on the e500v2 but with
the
following changes:
* Supports only the Enhanced Debug Architecture (DSRR0/1, etc)
* Floating Point
* No SPE
* Supports lwsync
* Doorbell Exceptions
* Hypervisor
---
In my powerpc-next tree.
arch/powerpc/kernel/cputable.c | 15 +++
arch/powerpc/kernel/head_booke.h |6 +-
arch/powerpc/kernel/head_fsl_booke.S | 10 --
arch/powerpc/platforms/Kconfig.cputype | 10 --
include/asm-powerpc/cache.h|3 +++
include/asm-powerpc/cputable.h |6 --
include/asm-powerpc/synch.h|2 +-
7 files changed, 44 insertions(+), 8 deletions(-)
diff --git a/arch/powerpc/kernel/cputable.c b/arch/powerpc/kernel/
cputable.c
index e44d553..36fa061 100644
--- a/arch/powerpc/kernel/cputable.c
+++ b/arch/powerpc/kernel/cputable.c
@@ -1522,6 +1522,21 @@ static struct cpu_spec __initdata
cpu_specs[] = {
.machine_check = machine_check_e500,
.platform = ppc8548,
},
+ { /* e500mc */
+ .pvr_mask = 0x,
+ .pvr_value = 0x8023,
+ .cpu_name = e500mc,
+ /* xxx - galak: add CPU_FTR_MAYBE_CAN_DOZE */
+ .cpu_features = CPU_FTRS_E500MC,
+ .cpu_user_features = COMMON_USER_BOOKE |
PPC_FEATURE_HAS_FPU,
+ .icache_bsize = 64,
+ .dcache_bsize = 64,
+ .num_pmcs = 4,
+ .oprofile_cpu_type = ppc/e500, /* xxx - galak, e500mc? */
+ .oprofile_type = PPC_OPROFILE_FSL_EMB,
+ .machine_check = machine_check_e500,
+ .platform = ppc4080,
+ },
{ /* default match */
.pvr_mask = 0x,
.pvr_value = 0x,
Did you intend to leave your 2 xxx - galak comments in here?
Yes, the _CAN_DOZE exists on all e500's right now and will go away
once we resolve the e500 PM patch from Dave Liu. The perf mon comment
I plan on keeping around for now.
Also, I think you have a problem - you allow CONFIG_SMP to be set
with CONFIG_FSL_BOOKE now, but if you actually turn on CONFIG_SMP,
in pgtable_32.c you're going to have build problems. CONFIG_SMP
enables hash_page_sync(), which we don't have on BookE. You need to
add a !BOOKE to the config protections in pgtable_32.c for
hash_page_sync() declaration and callers.
Yeah, I'll drop the CONFIG_SMP bits since the full blown SMP support
for fsl booke isnt in the tree (at which time we will address the
issue you raise).
- k
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Using DMA interrupt on MPC8313
I don't see a dma node in the mpc8377mds.dts (2.6.25). I found one in
mpc8610_hpcd.dts and
modeled it after that.
[EMAIL PROTECTED] {
#address-cells = 1;
#size-cells = 1;
compatible = fsl,elo-dma;
cell-index = 0;
reg = 0x82a8 0x4; /* DMA general status register */
ranges = 0x0 0x8100 0x200;
[EMAIL PROTECTED] {
compatible = fsl,elo-dma-channel;
cell-index = 0;
reg = 0x0 0x80;
interrupt-parent = ipic;
interrupts = 71 0x8;
};
[EMAIL PROTECTED] {
compatible = fsl,elo-dma-channel;
cell-index = 1;
reg = 0x80 0x80;
interrupt-parent = ipic;
interrupts = 71 0x8;
};
[EMAIL PROTECTED] {
compatible = fsl,elo-dma-channel;
cell-index = 2;
reg = 0x100 0x80;
interrupt-parent = ipic;
interrupts = 71 0x8;
};
[EMAIL PROTECTED] {
compatible = fsl,elo-dma-channel;
cell-index = 3;
reg = 0x180 0x80;
interrupt-parent = ipic;
interrupts = 71 0x8;
};
};
--- Scott Wood [EMAIL PROTECTED] wrote:
Ron Madrid wrote:
Here's my code. There are a few other things that happen but they are
inconsequential to this
problem. I'm sure that the request_irq call is right, especially since it
works if the fsldma
drivers are builtin to the kernel. Also, the irq number 71 comes from the
reference manual
for
them MPC8313. It is the internal interrupt for the DMA. I'll do some more
testing in a
little
while to try to determine the cause of the error in request_irq.
You cannot pass hardware IRQ numbers directly to request_irq() -- it has
no idea which IRQ controller you're referring to (even if there happens
to be only one on your board).
You should get the IRQ from the device tree, using
irq_of_parse_and_map() on the device node for the DMA channel (see the
mpc8377mds device tree for an example DMA node).
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: 4xx support in arch/ppc is going away Real Soon Now
On Mon, 16 Jun 2008 16:10:39 +0200 Matthias Fuchs [EMAIL PROTECTED] wrote: Acked-by: Matthias Fuchs [EMAIL PROTECTED] It seems that I have to post cpci405 patches for arch/powerpc soon. The board is still active! Nobody would believe it :-) I believe it. And that's all that matters. Well... that and you actually posting the patches :). josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Using DMA interrupt on MPC8313
Ron Madrid wrote: I don't see a dma node in the mpc8377mds.dts (2.6.25). I found one in mpc8610_hpcd.dts and modeled it after that. The DMA hardware on the 8610 is not the same as the DMA hardware on 83xx chips. You should copy the DMA data from another 83xx DTS. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Using DMA interrupt on MPC8313
Ron Madrid wrote:
I don't see a dma node in the mpc8377mds.dts (2.6.25). I found one in
mpc8610_hpcd.dts and
modeled it after that.
Try head-of-tree.
[EMAIL PROTECTED] {
#address-cells = 1;
#size-cells = 1;
compatible = fsl,elo-dma;
cell-index = 0;
reg = 0x82a8 0x4; /* DMA general status register */
ranges = 0x0 0x8100 0x200;
Should also put the interrupts in the dma node itself, so that the
driver can register it once and use the shared status register (but
don't remove it from the individual channels).
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Using DMA interrupt on MPC8313
Thank you for the help (again). I've got my driver registering the isr on it's
own now. In the
end the problem was the dts and also not using irq_of_parse_and_map.
Ron
--- Scott Wood [EMAIL PROTECTED] wrote:
Ron Madrid wrote:
I don't see a dma node in the mpc8377mds.dts (2.6.25). I found one in
mpc8610_hpcd.dts and
modeled it after that.
Try head-of-tree.
[EMAIL PROTECTED] {
#address-cells = 1;
#size-cells = 1;
compatible = fsl,elo-dma;
cell-index = 0;
reg = 0x82a8 0x4; /* DMA general status register */
ranges = 0x0 0x8100 0x200;
Should also put the interrupts in the dma node itself, so that the
driver can register it once and use the shared status register (but
don't remove it from the individual channels).
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc/booke: Add support for new e500mc core
On Jun 16, 2008, at 10:46 AM, Kumar Gala wrote:
--- a/arch/powerpc/kernel/cputable.c
+++ b/arch/powerpc/kernel/cputable.c
@@ -1522,6 +1522,21 @@ static struct cpu_spec __initdata cpu_specs[]
= {
.machine_check = machine_check_e500,
.platform = ppc8548,
},
+ { /* e500mc */
+ .pvr_mask = 0x,
+ .pvr_value = 0x8023,
+ .cpu_name = e500mc,
+ /* xxx - galak: add CPU_FTR_MAYBE_CAN_DOZE */
+ .cpu_features = CPU_FTRS_E500MC,
+ .cpu_user_features = COMMON_USER_BOOKE |
PPC_FEATURE_HAS_FPU,
+ .icache_bsize = 64,
+ .dcache_bsize = 64,
+ .num_pmcs = 4,
+ .oprofile_cpu_type = ppc/e500, /* xxx - galak, e500mc? */
+ .oprofile_type = PPC_OPROFILE_FSL_EMB,
+ .machine_check = machine_check_e500,
+ .platform = ppc4080,
Do you really want the platform to be this specific?
diff --git a/arch/powerpc/platforms/Kconfig.cputype b/arch/powerpc/
platforms/Kconfig.cputype
index f7efaa9..9e67cf1 100644
--- a/arch/powerpc/platforms/Kconfig.cputype
+++ b/arch/powerpc/platforms/Kconfig.cputype
@@ -95,6 +95,12 @@ config E500
select FSL_EMB_PERFMON
bool
+config PPC_E500MC
+ bool e500mc Support
+ select PPC_FPU
+ depends on E500
+ default n
+
config PPC_FPU
bool
default y if PPC64
@@ -157,7 +163,7 @@ config ALTIVEC
config SPE
bool SPE Support
- depends on E200 || E500
+ depends on E200 || (E500 !PPC_E500MC)
Why make E500MC a config option, if it's so similar? This way you
can't make a kernel with SPE support that can boot on both e500{,v2}
and e500mc...
config SMP
- depends on PPC_STD_MMU
+ depends on PPC_STD_MMU || FSL_BOOKE
Isn't there quite a bit more needed than just enabling this config
option for SMP to work? I.e. why not save this for when the rest is
posted?
-Olof___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 03/19][v3] powerpc: Add memory entitlement capabilities to /proc/ppc64/lparcfg
Version 3 of the patch, small update to use the correct plpar_hcall
for H_GET_MPP.
---
Update /proc/ppc64/lparcfg to enable displaying of Cooperative Memory
Overcommitment statistics as reported by the H_GET_MPP hcall. This also
updates the lparcfg interface to allow setting memory entitlement and
weight.
Signed-off-by: Nathan Fontenot [EMAIL PROTECTED]
---
arch/powerpc/kernel/lparcfg.c | 139
+++---
include/asm-powerpc/hvcall.h | 18 +
2 files changed, 147 insertions(+), 10 deletions(-)
Index: linux-2.6.git/arch/powerpc/kernel/lparcfg.c
===
--- linux-2.6.git.orig/arch/powerpc/kernel/lparcfg.c 2008-06-16
10:32:29.0 -0500
+++ linux-2.6.git/arch/powerpc/kernel/lparcfg.c 2008-06-16
10:47:55.0 -0500
@@ -129,6 +129,35 @@
/*
* Methods used to fetch LPAR data when running on a pSeries platform.
*/
+/**
+ * h_get_mpp
+ * H_GET_MPP hcall returns info in 7 parms
+ */
+int h_get_mpp(struct hvcall_mpp_data *mpp_data)
+{
+ int rc;
+ unsigned long retbuf[PLPAR_HCALL9_BUFSIZE];
+
+ rc = plpar_hcall9(H_GET_MPP, retbuf);
+
+ mpp_data-entitled_mem = retbuf[0];
+ mpp_data-mapped_mem = retbuf[1];
+
+ mpp_data-group_num = (retbuf[2] 2 * 8) 0x;
+ mpp_data-pool_num = retbuf[2] 0x;
+
+ mpp_data-mem_weight = (retbuf[3] 7 * 8) 0xff;
+ mpp_data-unallocated_mem_weight = (retbuf[3] 6 * 8) 0xff;
+ mpp_data-unallocated_entitlement = retbuf[3] 0x;
+
+ mpp_data-pool_size = retbuf[4];
+ mpp_data-loan_request = retbuf[5];
+ mpp_data-backing_mem = retbuf[6];
+
+ return rc;
+}
+EXPORT_SYMBOL(h_get_mpp);
+
/*
* H_GET_PPP hcall returns info in 4 parms.
* entitled_capacity,unallocated_capacity,
@@ -226,6 +255,44 @@
seq_printf(m, unallocated_capacity=%ld\n, h_unallocated);
}
+/**
+ * parse_mpp_data
+ * Parse out data returned from h_get_mpp
+ */
+static void parse_mpp_data(struct seq_file *m)
+{
+ struct hvcall_mpp_data mpp_data;
+ int rc;
+
+ rc = h_get_mpp(mpp_data);
+ if (rc)
+ return;
+
+ seq_printf(m, entitled_memory=%ld\n, mpp_data.entitled_mem);
+
+ if (mpp_data.mapped_mem != -1)
+ seq_printf(m, mapped_entitled_memory=%ld\n,
+ mpp_data.mapped_mem);
+
+ seq_printf(m, entitled_memory_group_number=%d\n, mpp_data.group_num);
+ seq_printf(m, entitled_memory_pool_number=%d\n, mpp_data.pool_num);
+
+ seq_printf(m, entitled_memory_weight=%d\n, mpp_data.mem_weight);
+ seq_printf(m, unallocated_entitled_memory_weight=%d\n,
+ mpp_data.unallocated_mem_weight);
+ seq_printf(m, unallocated_io_mapping_entitlement=%ld\n,
+ mpp_data.unallocated_entitlement);
+
+ if (mpp_data.pool_size != -1)
+ seq_printf(m, entitled_memory_pool_size=%ld bytes\n,
+ mpp_data.pool_size);
+
+ seq_printf(m, entitled_memory_loan_request=%ld\n,
+ mpp_data.loan_request);
+
+ seq_printf(m, backing_memory=%ld bytes\n, mpp_data.backing_mem);
+}
+
#define SPLPAR_CHARACTERISTICS_TOKEN 20
#define SPLPAR_MAXLENGTH 1026*(sizeof(char))
@@ -353,6 +420,7 @@
/* this call handles the ibm,get-system-parameter contents */
parse_system_parameter_string(m);
parse_ppp_data(m);
+ parse_mpp_data(m);
seq_printf(m, purr=%ld\n, get_purr());
@@ -417,6 +485,43 @@
return retval;
}
+/**
+ * update_mpp
+ *
+ * Update the memory entitlement and weight for the partition. Caller must
+ * spercify either a new entitlement or weight, not both, to be updated
+ * since the h_set_mpp call takes both entitlement and weight as
parameters.
+ */
+static ssize_t update_mpp(u64 *entitlement, u8 *weight)
+{
+ struct hvcall_mpp_data mpp_data;
+ u64 new_entitled;
+ u8 new_weight;
+ ssize_t rc;
+
+ rc = h_get_mpp(mpp_data);
+ if (rc)
+ return rc;
+
+ if (entitlement) {
+ new_weight = mpp_data.mem_weight;
+ new_entitled = *entitlement;
+ } else if (weight) {
+ new_weight = *weight;
+ new_entitled = mpp_data.entitled_mem;
+ } else
+ return -EINVAL;
+
+ pr_debug(%s: current_entitled = %lu, current_weight = %u\n,
+__FUNCTION__, mpp_data.entitled_mem, mpp_data.mem_weight);
+
+ pr_debug(%s: new_entitled = %lu, new_weight = %u\n,
+__FUNCTION__, new_entitled, new_weight);
+
+ rc = plpar_hcall_norets(H_SET_MPP, new_entitled, new_weight);
+ return rc;
+}
+
/*
* Interface for changing system parameters (variable capacity weight
* and entitled capacity). Format of input is param_name=value;
@@ -470,6 +575,20 @@
goto out;
[PATCH] 85xx: publish of device for cds platforms
Publish the devices listed in dts under SOC as of_device for 85xx_cds
platform. The devices are needed by the 85xx EDAC driver.
Signed-off-by: Dave Jiang [EMAIL PROTECTED]
---
arch/powerpc/platforms/85xx/mpc85xx_cds.c | 14 ++
1 file changed, 14 insertions(+)
Index: 2.6.26-rc5-mm3/arch/powerpc/platforms/85xx/mpc85xx_cds.c
===
--- 2.6.26-rc5-mm3.orig/arch/powerpc/platforms/85xx/mpc85xx_cds.c
+++ 2.6.26-rc5-mm3/arch/powerpc/platforms/85xx/mpc85xx_cds.c
@@ -26,6 +26,7 @@
#include linux/module.h
#include linux/interrupt.h
#include linux/fsl_devices.h
+#include linux/of_platform.h
#include asm/system.h
#include asm/pgtable.h
@@ -335,6 +336,19 @@ static int __init mpc85xx_cds_probe(void
return of_flat_dt_is_compatible(root, MPC85xxCDS);
}
+static struct of_device_id __initdata of_bus_ids[] = {
+ { .type = soc, },
+ { .compatible = soc, },
+ {},
+};
+
+static int __init declare_of_platform_devices(void)
+{
+ return of_platform_bus_probe(NULL, of_bus_ids, NULL);
+}
+machine_device_initcall(mpc85xx_cds, declare_of_platform_devices);
+
+
define_machine(mpc85xx_cds) {
.name = MPC85xx CDS,
.probe = mpc85xx_cds_probe,
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] 85xx: publish of device for cds platforms
Dave Jiang wrote:
+static struct of_device_id __initdata of_bus_ids[] = {
+ { .type = soc, },
+ { .compatible = soc, },
+ {},
+};
Also add .compatible = simple-bus.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v2] 85xx: publish of device for cds platforms
Publish the devices listed in dts under SOC as of_device for 85xx_cds
platform. The devices are needed by the 85xx EDAC driver.
Signed-off-by: Dave Jiang [EMAIL PROTECTED]
---
Added simple bus per Scott Wood
mrch/powerpc/platforms/85xx/pc85xx_cds.c | 15 +++
1 file changed, 15 insertions(+)
Index: 2.6.26-rc5-mm3/arch/powerpc/platforms/85xx/mpc85xx_cds.c
===
--- 2.6.26-rc5-mm3.orig/arch/powerpc/platforms/85xx/mpc85xx_cds.c
+++ 2.6.26-rc5-mm3/arch/powerpc/platforms/85xx/mpc85xx_cds.c
@@ -26,6 +26,7 @@
#include linux/module.h
#include linux/interrupt.h
#include linux/fsl_devices.h
+#include linux/of_platform.h
#include asm/system.h
#include asm/pgtable.h
@@ -335,6 +336,20 @@ static int __init mpc85xx_cds_probe(void
return of_flat_dt_is_compatible(root, MPC85xxCDS);
}
+static struct of_device_id __initdata of_bus_ids[] = {
+ { .type = soc, },
+ { .compatible = soc, },
+ { .compatible = simple-bus, },
+ {},
+};
+
+static int __init declare_of_platform_devices(void)
+{
+ return of_platform_bus_probe(NULL, of_bus_ids, NULL);
+}
+machine_device_initcall(mpc85xx_cds, declare_of_platform_devices);
+
+
define_machine(mpc85xx_cds) {
.name = MPC85xx CDS,
.probe = mpc85xx_cds_probe,
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Problems with NFS root on arch/ppc after pulling 2.6.26-rc6, on PPC405
I'm not seeing any issue with arch/powerpc. But with arch/ppc I'm seeing problems with NFS root after I pulled in 2.6.26-rc6. Has anyone else seen anything like this? It's consistent in that it typically happens on boot after freeing unused kernel memory, but the actual task that running seems to vary. We were running on 2.6.25 without the issue. Thanks, John 11.660218] Looking up port of RPC 13/2 on 172.16.40.76 [ 11.740956] Looking up port of RPC 15/1 on 172.16.40.76 [ 11.859230] VFS: Mounted root (nfs filesystem). [ 11.914236] Freeing unused kernel memory: 108k init [ 12.175480] Oops: kernel access of bad area, sig: 11 [#1] [ 12.240202] NIP: c01b74a8 LR: c01b7424 CTR: c0014664 [ 12.299677] REGS: c34b9ec0 TRAP: 0300 Not tainted (2.6.26-rc6) [ 12.372670] MSR: 00021030 ME,IR,DR CR: 9533 XER: c025 [ 12.446306] DEAR: 002c, ESR: [ 12.494326] TASK = c3c580a0[178] 'rpciod/0' THREAD: c34b8000 [ 12.560037] GPR00: 002c c34b9f70 c3c580a0 c3c450c0 c025d078 0032 0001 0032 [ 12.661061] GPR08: 10682916 0037 058f c025d028 625a [ 12.762088] GPR16: [ 12.863113] GPR24: c0027b74 c34b8000 c3c581f4 c3c450c0 c3c580a0 [ 12.966324] NIP [c01b74a8] schedule+0x1ec/0x348 [ 13.020693] LR [c01b7424] schedule+0x168/0x348 [ 13.074016] Call Trace: [ 13.103285] [c34b9f70] [c01b7424] schedule+0x168/0x348 (unreliable) [ 13.178688] [c34b9fa0] [c0027b74] worker_thread+0x7c/0xb8 [ 13.243573] [c34b9fd0] [c002b264] kthread+0x50/0x8c [ 13.302209] [c34b9ff0] [c00048d8] kernel_thread+0x44/0x60 [ 13.367090] Instruction dump: [ 13.402714] 7d290194 912b0028 914b002c 813b 39290001 913b 83bc00b4 83fe00b8 [ 13.496342] 2f9d 40be0024 93fc00b8 381f002c 7d28 31080001 7c00022c 7d00012d [ 13.594651] [ cut here ] [ 13.649976] kernel BUG at kernel/exit.c:1098! [ 13.702155] XXX: Exception [ 13.702170] Signal: 5 [ 13.702182] Code: 30001 [ 13.702195] Addr: 0 [ 13.826503] Oops: Exception in kernel mode, sig: 5 [#2] [ 13.889100] NIP: c0019b78 LR: c0019b78 CTR: c0014664 [ 13.948580] REGS: c34b9d90 TRAP: 0700 Tainted: G D (2.6.26-rc6) [ 14.029904] MSR: 00029030 EE,ME,IR,DR CR: 39005093 XER: e025 [ 14.106772] TASK = c3c580a0[178] 'rpciod/0' THREAD: c34b8000 [ 14.172485] GPR00: c0019b78 c34b9e40 c3c580a0 c3c450c0 c025d078 c025d078 0001 0002 [ 14.273509] GPR08: 54fcebe2 1a8fe938 [ 14.374534] GPR16: [ 14.475560] GPR24: c0027b74 0001 c3c58098 c3c178a0 c3c58188 c3c580a0 0020 [ 14.578771] NIP [c0019b78] do_exit+0x5d8/0x5e0 [ 14.632097] LR [c0019b78] do_exit+0x5d8/0x5e0 [ 14.684379] Call Trace: [ 14.713649] [c34b9e40] [c0019b78] do_exit+0x5d8/0x5e0 (unreliable) [ 14.788011] [c34b9e80] [c00035bc] nonrecoverable_exception+0x0/0x4c [ 14.863310] [c34b9e90] [c0009a18] bad_page_fault+0x48/0x5c [ 14.929236] [c34b9eb0] [c0002d28] handle_page_fault+0x7c/0x80 [ 14.998287] [c34b9f70] [c01b7424] schedule+0x168/0x348 [ 15.060049] [c34b9fa0] [c0027b74] worker_thread+0x7c/0xb8 [ 15.124934] [c34b9fd0] [c002b264] kthread+0x50/0x8c [ 15.183570] [c34b9ff0] [c00048d8] kernel_thread+0x44/0x60 [ 15.248454] Instruction dump: [ 15.284076] 2f80 61290008 913e000c 419e0008 480c4315 807e03fc 2f83 419e0008 [ 15.377703] 4804939d 3840 901e 4819d749 0fe0 4800 7c0802a6 9421fff0 [ 15.475780] Fixing recursive fault but reboot is needed! [ 15.539679] Oops: kernel access of bad area, sig: 11 [#3] [ 15.604344] NIP: c01b74a8 LR: c01b7424 CTR: c0014664 [ 15.663821] REGS: c34b9bb0 TRAP: 0300 Tainted: G D (2.6.26-rc6) [ 15.745146] MSR: 00021030 ME,IR,DR CR: 99005053 XER: c025 [ 15.818782] DEAR: 002c, ESR: [ 15.866801] TASK = c3c580a0[178] 'rpciod/0' THREAD: c34b8000 [ 15.932513] GPR00: 002c c34b9c60 c3c580a0 c3c44490 c025d078 c3c444b8 [ 16.033537] GPR08: 26098f63 0001 0590 c025d028 feced300 [ 16.134563] GPR16: [ 16.235589] GPR24: c0019660 c34b8000 c3c45218 c3c44490 c3c450c0 [ 16.338799] NIP [c01b74a8] schedule+0x1ec/0x348 [ 16.393167] LR [c01b7424] schedule+0x168/0x348 [ 16.446490] Call Trace: [ 16.475760] [c34b9c60] [c01b7424] schedule+0x168/0x348 (unreliable) [ 16.551163] [c34b9c90] [c0019660] do_exit+0xc0/0x5e0 [ 16.610840] [c34b9cd0] [c00035bc] nonrecoverable_exception+0x0/0x4c [ 16.686140] [c34b9ce0] [c0003658] _exception+0x50/0xdc [ 16.747901] [c34b9d80] [c0002e70]
Re: [PATCH] powerpc/booke: Add support for new e500mc core
On Mon, 2008-06-16 at 10:46 -0500, Kumar Gala wrote: The new e500mc core from Freescale is based on the e500v2 but with the following changes: * Supports only the Enhanced Debug Architecture (DSRR0/1, etc) * Floating Point * No SPE * Supports lwsync ^^ It supports SMP ? Is tlbivax broadcast ? Is there a local form ? Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
