* Re: Help required on MPC82XX USB Host controller Development using m82xx-hcd.
From: Amarendra_Reddy @ 2008-04-04 14:47 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <200803270956.12203.laurentp@cse-semaphore.com>
Hi Laurent,
Thanks for your reply.
Most of the modules of the new product(based on Kernrel 2.6.10) are
completed, except for the USB module. Hence we have to work with the kernre=
l
2.6.10 even for USB module.
We integrated cmp2usb project into Kernel 2.6.10, and with some
modifications and compiled the kernel successfully.
When pendrive is inserted into the USB port we are facing the below
mentioned problems.
(sorry for a lengthy posting)
We would be thankful if you / anyone could suggest us with some solution or
idea or an alternative approach.
Given below is the Console Output=20
CASE 1: When pendrive is inserted "Directly to USB port of the 8272ADS
board".
CASE 2: When pendrive is inserted on an "External hub which is conntected t=
o
USB port of 8272ADS board".
Output from console:
CASE 1: Pendrive Directly connected to uSB port of the 8272ADS board
USB Universal Host Controller Interface driver v2.2
Registering platform device 'mpc82xx-hcd.3'. Parent at platform
=3D> driver mpc82xx-hcd, 2005
mpc82xx-hcd mpc82xx-hcd.3: PQ2 intergrated USB controller v0.1
mpc82xx-hcd mpc82xx-hcd.3: new USB bus registered, assigned bus number 1
usb usb1: Product: PQ2 intergrated USB controller v0.1
usb usb1: Manufacturer: Linux 2.6.10_mvl401-8272ads mpc82xx-hcd
usb usb1: SerialNumber: mpc82xx-hcd.3
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 1 port detected
PQ2USB: debug file creation
........after SANDISK pendrive inserted.........
usb 1-1: new full speed USB device using mpc82xx-hcd and address 2
usb 1-1: Product: U3 Cruzer Micro
usb 1-1: Manufacturer: SanDisk Corporation
Oops: Exception in kernel mode, sig: 4 [#1]
........after unknown/generic manufacturer's pendrive inserted.......
usb 1-1: new full speed USB device using mpc82xx-hcd and address 2
usb 1-1: device descriptor read/64, error -110
usb 1-1: device descriptor read/64, error -110
usb 1-1: new full speed USB device using mpc82xx-hcd and address 3
usb 1-1: device descriptor read/64, error -110
usb 1-1: device descriptor read/64, error -110
usb 1-1: new full speed USB device using mpc82xx-hcd and address 4
usb 1-1: device not accepting address 4, error -110
usb 1-1: new full speed USB device using mpc82xx-hcd and address 5
usb 1-1: device not accepting address 5, error -110
CASE 2: Pendrive is inserted on an "External hub which is conntected to USB
port of 8272ADS board".
USB Universal Host Controller Interface driver v2.2
sl811: driver sl811-hcd, 19 May 2005
Registering platform device 'mpc82xx-hcd.3'. Parent at platform
=3D> driver mpc82xx-hcd, 2005
mpc82xx-hcd mpc82xx-hcd.3: PQ2 intergrated USB controller v0.1
mpc82xx-hcd mpc82xx-hcd.3: new USB bus registered, assigned bus number 1
usb usb1: Product: PQ2 intergrated USB controller v0.1
usb usb1: Manufacturer: Linux 2.6.10_mvl401-8272ads mpc82xx-hcd
usb usb1: SerialNumber: mpc82xx-hcd.3
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 1 port detected
PQ2USB: debug file creation
Initializing USB Mass Storage driver...
usbcore: registered new driver usb-storage
USB Mass Storage support registered.
.......after SANDISK pendrive inserted........
usb 1-1.3: new full speed USB device using mpc82xx-hcd and address 3
usb 1-1.3: Product: U3 Cruzer Micro
usb 1-1.3: Manufacturer: SanDisk Corporation
usb 1-1.3: can't set config #1, error -110
hub 1-1:1.0: cannot disable port 3 (err =3D -110)
hub 1-1:1.0: cannot reset port 3 (err =3D -110)
hub 1-1:1.0: cannot reset port 3 (err =3D -110)
hub 1-1:1.0: cannot reset port 3 (err =3D -110)
hub 1-1:1.0: cannot reset port 3 (err =3D -110)
hub 1-1:1.0: cannot reset port 3 (err =3D -110)
hub 1-1:1.0: Cannot enable port 3. Maybe the USB cable is bad?
hub 1-1:1.0: cannot disable port 3 (err =3D -110)
hub 1-1:1.0: cannot reset port 3 (err =3D -110)
hub 1-1:1.0: cannot reset port 3 (err =3D -110)
hub 1-1:1.0: cannot reset port 3 (err =3D -110)
hub 1-1:1.0: cannot reset port 3 (err =3D -110)
hub 1-1:1.0: cannot reset port 3 (err =3D -110)
hub 1-1:1.0: Cannot enable port 3. Maybe the USB cable is bad?
hub 1-1:1.0: cannot disable port 3 (err =3D -110)
hub 1-1:1.0: cannot reset port 3 (err =3D -110)
hub 1-1:1.0: cannot reset port 3 (err =3D -110)
hub 1-1:1.0: cannot reset port 3 (err =3D -110)
hub 1-1:1.0: cannot reset port 3 (err =3D -110)
hub 1-1:1.0: cannot reset port 3 (err =3D -110)
hub 1-1:1.0: Cannot enable port 3. Maybe the USB cable is bad?
hub 1-1:1.0: cannot disable port 3 (err =3D -110)
hub 1-1:1.0: cannot disable port 3 (err =3D -110)
hub 1-1:1.0: hub_port_status failed (err =3D -110)
........after unknown manufacturer's pendrive inserted...........
usb 1-1.1: new full speed USB device using mpc82xx-hcd and address 7
usb 1-1.1: Product: Mass Storage Device
usb 1-1.1: Manufacturer: Generic
usb 1-1.1: SerialNumber: 6EOG5LAF
scsi0 : SCSI emulation for USB Mass Storage devices
floating point used in kernel (task=3Dc0306050, pc=3Dc022a5f8)
Oops: Exception in kernel mode, sig: 4 [#1]
Thanks & Regards
Amarendra Reddy
--------------------------------------------------------
Laurent Pinchart-4 wrote:
>=20
> Hi Amarendra,
>=20
> On Wednesday 26 March 2008 17:11, Amarendra_Reddy wrote:
>>=20
>> Hi all,
>>=20
>> We are working on implementation of the USB host controller driver for
>> the
>> MPC8272ADS (eval board).=20
>>=20
>> The USB Host controller on MPC8272 chip is neither UHCI nor OHCI
>> compliant.=20
>>=20
>> We downloaded the project cpm2usb and the patches created by Mr.Mike
>> Rapoport from http://cpm2usb.sourceforge.net
>>=20
>> We integrated the 'm82xx-hcd' into the 2.6.10 source with few changes to
>> usb
>> data structures (usb_hcd,usb_device,usb_host_endpoint) and to struct
>> hc_driver. Also updated the function ''tx_err' present in m82xx-hcd.c.
>=20
> The cpm2usb project isn't maintained. If possible you should upgrade to a
> more=20
> recent kernel and switch to the powerpc architecture where a new USB
> driver=20
> called fhci is available.
>=20
> The MPC872ADS is supported in recent kernels so switching shouldn't be to=
o=20
> difficult.
>=20
> Best regards,
>=20
> --=20
> Laurent Pinchart
> CSE Semaphore Belgium
>=20
> Chauss=C3=A9e de Bruxelles, 732A
> B-1410 Waterloo
> Belgium
>=20
> T +32 (2) 387 42 59
> F +32 (2) 387 42 75
>=20
> =20
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>=20
--=20
View this message in context: http://www.nabble.com/Help-on-MPC82XX-USB-Hos=
t-controller-Development-using-m82xx-hcd.-tp16304553p16491756.html
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [kvm-ppc-devel] [PATCH] [v2] Add idle wait support for 44x platforms
From: Jerone Young @ 2008-04-04 15:42 UTC (permalink / raw)
To: Jimi Xenidis; +Cc: kvm-ppc-devel, linuxppc-dev
In-Reply-To: <835D8B13-CF90-4013-A172-8243BF93DE52@pobox.com>
On Fri, 2008-04-04 at 08:36 -0400, Jimi Xenidis wrote:
> On Apr 4, 2008, at 3:06 AM, Jerone Young wrote:
>
> > # HG changeset patch
> > # User Jerone Young <jyoung5@us.ibm.com>
> > # Date 1207292108 18000
> > # Node ID afed3e5de82ab6c0ac8d6ceeb0292b6c41ece1ed
> > # Parent a5b2aebbc6ebd2439c655f1c047ed7e3c1991ec1
> > [v2] Add idle wait support for 44x platforms
> >
> > This patch adds the ability for the CPU to go into wait state while
> > in cpu_idle loop. This helps virtulization solutions know when the
> > guest Linux kernel is in an idle state. There are two ways to do it.
> >
> > 1) Command line
> > idle=spin <-- CPU will spin (this is the default)
> > idle=wait <-- set CPU into wait state when idle
> >
> > 2) The device tree will be checked for the "/hypervisor" node
> > If this node is seen it will use "wait" for idle, so that
> > the hypervisor can know when guest Linux kernel it is in
> > an idle state.
> >
> > This patch, unlike the last, isolates the code to 44x platforms.
> >
> > Signed-off-by: Jerone Young <jyoung5@us.ibm.com>
> >
> > diff --git a/arch/powerpc/platforms/44x/Makefile b/arch/powerpc/
> > platforms/44x/Makefile
> > --- a/arch/powerpc/platforms/44x/Makefile
> > +++ b/arch/powerpc/platforms/44x/Makefile
> > @@ -1,4 +1,4 @@ obj-$(CONFIG_44x) := misc_44x.o
> > -obj-$(CONFIG_44x) := misc_44x.o
> > +obj-$(CONFIG_44x) := misc_44x.o idle.o
> > obj-$(CONFIG_EBONY) += ebony.o
> > obj-$(CONFIG_TAISHAN) += taishan.o
> > obj-$(CONFIG_BAMBOO) += bamboo.o
> > diff --git a/arch/powerpc/platforms/44x/idle.c b/arch/powerpc/
> > platforms/44x/idle.c
> > new file mode 100644
> > --- /dev/null
> > +++ b/arch/powerpc/platforms/44x/idle.c
> > @@ -0,0 +1,84 @@
> > +/*
> > + * Copyright 2008 IBM Corp.
> > + *
> > + * Derived from pasemi/idle.c
> > + * by Olof Johansson <olof@lixom.net>
> > + *
> > + * Added by: Jerone Young <jyoung5@us.ibm.com>
> > + *
> > + * 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.
> > + *
> > + * 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., 59 Temple Place, Suite 330, Boston, MA
> > 02111-1307 USA
> > + *
> > + */
> > +
> > +#include <linux/of.h>
> > +#include <linux/kernel.h>
> > +#include <asm/machdep.h>
> > +
> > +static int current_mode = 0;
>
> Doesn't matter if the 0 is functionally redundant or pleasing to your
> eye, it is the "Linux way" to leave out the " = 0", so just do it
> please.
>
Ok this can be removed.
> > +
> > +struct sleep_mode {
> > + char *name;
> > + void (*entry)(void);
> > +};
> > +
> > +static void ppc44x_idle(void)
> Perhaps "ppc44x_wait" is more appropriate?
> > +{
> > + unsigned long msr_save;
> > +
> > + msr_save = mfmsr();
> > + /* set wait state MSR */
> > + mtmsr(msr_save|MSR_WE|MSR_EE|MSR_CE);
>
> Did we decide to drop MSR_DE?
Hollis argued it down on an earlier email on kvm-ppc-devel. Though I did
have it in one of the earlier patches.
>
> > + /* return to initial state */
> > + mtmsr(msr_save);
>
> It may be my paranoia but I'm pretty sure you need the isync() after
> _both_ mtmsr()s
> Certainly can't hurt.
I could add this back. Though everyone had already agreed on it without
it. So figured it was safer to go witout it. But I can add it back.
>
> > +}
> > +
> > +static struct sleep_mode modes[] = {
> > + { .name = "spin", .entry = NULL },
> > + { .name = "wait", .entry = &ppc44x_idle },
> > +};
> > +
> > +int __init ppc44x_idle_init(void)
> > +{
> > + void *func = modes[current_mode].entry;
> > + struct device_node *node;
> > +
> > + node = of_find_node_by_path("/hypervisor");
> > + if (node) {
> > + /* if we find /hypervisor node is in device tree,
> > + set idle mode to wait */
> > + func = &ppc44x_idle; /* wait */
> > + of_node_put(node);
> > + }
> > +
> > + ppc_md.power_save = func;
> > + return 0;
> > +}
> > +
> > +arch_initcall(ppc44x_idle_init);
>
> IIRC, this would over-ride the idle_param() below, is that the
> intended behavior?
Yes. At the moment if it detects a hypervisor in the kernel tree it
overrides what the command line says.
>
> > +
> > +static int __init idle_param(char *p)
> > +{
> > + int i;
> > +
> > + for (i = 0; i < sizeof(modes)/ARRAY_SIZE(modes); i++) {
>
> It is supposed to be:
> for (i = 0; i < ARRAY_SIZE(modes); i++) {
> What you have will actually eval to 0 and would have never checked
> anything :)
Ouch. My bad. Wasn't thinking when I added that.
>
> > + if (!strcmp(modes[i].name, p)) {
> > + current_mode = i;
> > + break;
> > + }
> > + }
> > +
> > + return 0;
> > +}
> > +
> > +early_param("idle", idle_param);
> >
> > ----------------------------------------------------------------------
> > ---
> > Check out the new SourceForge.net Marketplace.
> > It's the best place to buy or sell services for
> > just about anything Open Source.
> > http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/
> > marketplace
> > _______________________________________________
> > kvm-ppc-devel mailing list
> > kvm-ppc-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/kvm-ppc-devel
>
^ permalink raw reply
* [PATCH] [v3] Add idle wait support for 44x platforms
From: Jerone Young @ 2008-04-04 15:50 UTC (permalink / raw)
To: linuxppc-dev; +Cc: kvm-ppc-devel
2 files changed, 87 insertions(+), 1 deletion(-)
arch/powerpc/platforms/44x/Makefile | 2
arch/powerpc/platforms/44x/idle.c | 86 +++++++++++++++++++++++++++++++++++
This patch adds the ability for the CPU to go into wait state while in cpu_idle loop. This helps virtulization solutions know when the guest Linux kernel is in an idle state. There are two ways to do it.
1) Command line
idle=spin <-- CPU will spin (this is the default)
idle=wait <-- set CPU into wait state when idle
2) The device tree will be checked for the "/hypervisor" node
If this node is seen it will use "wait" for idle, so that
the hypervisor can know when guest Linux kernel it is in
an idle state.
This patch, unlike the last, isolates the code to 44x platforms.
Signed-off-by: Jerone Young <jyoung5@us.ibm.com>
diff --git a/arch/powerpc/platforms/44x/Makefile b/arch/powerpc/platforms/44x/Makefile
--- a/arch/powerpc/platforms/44x/Makefile
+++ b/arch/powerpc/platforms/44x/Makefile
@@ -1,4 +1,4 @@ obj-$(CONFIG_44x) := misc_44x.o
-obj-$(CONFIG_44x) := misc_44x.o
+obj-$(CONFIG_44x) := misc_44x.o idle.o
obj-$(CONFIG_EBONY) += ebony.o
obj-$(CONFIG_TAISHAN) += taishan.o
obj-$(CONFIG_BAMBOO) += bamboo.o
diff --git a/arch/powerpc/platforms/44x/idle.c b/arch/powerpc/platforms/44x/idle.c
new file mode 100644
--- /dev/null
+++ b/arch/powerpc/platforms/44x/idle.c
@@ -0,0 +1,86 @@
+/*
+ * Copyright 2008 IBM Corp.
+ *
+ * Based on arch/powerpc/platforms/pasemi/idle.c:
+ * Copyright (C) 2006-2007 PA Semi, Inc
+ *
+ * Added by: Jerone Young <jyoung5@us.ibm.com>
+ *
+ * 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.
+ *
+ * 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., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ *
+ */
+
+#include <linux/of.h>
+#include <linux/kernel.h>
+#include <asm/machdep.h>
+
+static int current_mode;
+
+struct sleep_mode {
+ char *name;
+ void (*entry)(void);
+};
+
+static void ppc44x_idle(void)
+{
+ unsigned long msr_save;
+
+ msr_save = mfmsr();
+ /* set wait state MSR */
+ mtmsr(msr_save|MSR_WE|MSR_EE|MSR_CE);
+ isync();
+ /* return to initial state */
+ mtmsr(msr_save);
+ isync();
+}
+
+static struct sleep_mode modes[] = {
+ { .name = "spin", .entry = NULL },
+ { .name = "wait", .entry = &ppc44x_idle },
+};
+
+int __init ppc44x_idle_init(void)
+{
+ void *func = modes[current_mode].entry;
+ struct device_node *node;
+
+ node = of_find_node_by_path("/hypervisor");
+ if (node) {
+ /* if we find /hypervisor node is in device tree,
+ set idle mode to wait */
+ func = &ppc44x_idle; /* wait */
+ of_node_put(node);
+ }
+
+ ppc_md.power_save = func;
+ return 0;
+}
+
+arch_initcall(ppc44x_idle_init);
+
+static int __init idle_param(char *p)
+{
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(modes); i++) {
+ if (!strcmp(modes[i].name, p)) {
+ current_mode = i;
+ break;
+ }
+ }
+
+ return 0;
+}
+
+early_param("idle", idle_param);
^ permalink raw reply
* Re: [kvm-ppc-devel] [PATCH] [v2] Add idle wait support for 44x platforms
From: Hollis Blanchard @ 2008-04-04 15:56 UTC (permalink / raw)
To: jyoung5; +Cc: kvm-ppc-devel, linuxppc-dev, Jimi Xenidis
In-Reply-To: <1207323761.6634.6.camel@thinkpadL>
On Friday 04 April 2008 10:42:41 Jerone Young wrote:
> > > +{
> > > +=A0=A0=A0unsigned long msr_save;
> > > +
> > > +=A0=A0=A0msr_save =3D mfmsr();
> > > +=A0=A0=A0/* set wait state MSR */
> > > +=A0=A0=A0mtmsr(msr_save|MSR_WE|MSR_EE|MSR_CE);
> >
> > Did we decide to drop MSR_DE?
>
> Hollis argued it down on an earlier email on kvm-ppc-devel. Though I did
> have it in one of the earlier patches.
I didn't comment either way. However, looking at the 440 user manual now, i=
t=20
seems clear that DE should be set to allow JTAG debugger events.
=2D-=20
Hollis Blanchard
IBM Linux Technology Center
^ permalink raw reply
* Re: Please pull linux-2.6-mpc52xx.git
From: Grant Likely @ 2008-04-04 16:11 UTC (permalink / raw)
To: Bartlomiej Sieka; +Cc: Olof Johansson, linuxppc-dev
In-Reply-To: <47F60D5D.5090402@semihalf.com>
On Fri, Apr 4, 2008 at 5:13 AM, Bartlomiej Sieka <tur@semihalf.com> wrote:
>
> Bartlomiej Sieka wrote:
>
> > Hi Grant,
> >
> > Grant Likely wrote:
> > > I'm thinking 'optimized' defconfigs should go into a subdirectory.
> >
> > This requires a change to the top-level Makefile and shepherding this
> > change upstream. Could we perhaps try to avoid this by having optimized
> > defconfigs in the form of, for example:
I don't think changes are required to put them in a subdir:
$ mkdir arch/powerpc/configs/optimized
$ cp arch/powerpc/configs/mpc5200_defconfig
arch/powerpc/configs/optimized/lite5200_defconfig
$ make optimized/lite5200_defconfig
This works for me.
>
> Grant,
>
> Any thoughts on the above?
Sorry I didn't reply earlier
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: Please pull linux-2.6-mpc52xx.git
From: Grant Likely @ 2008-04-04 16:14 UTC (permalink / raw)
To: Bartlomiej Sieka; +Cc: Olof Johansson, linuxppc-dev
In-Reply-To: <fa686aa40804040911o63e2e3efg2d9a74fff082fb16@mail.gmail.com>
On Fri, Apr 4, 2008 at 10:11 AM, Grant Likely <grant.likely@secretlab.ca> wrote:
> > > > I'm thinking 'optimized' defconfigs should go into a subdirectory.
> > >
> > > This requires a change to the top-level Makefile and shepherding this
> > > change upstream. Could we perhaps try to avoid this by having optimized
> > > defconfigs in the form of, for example:
>
> I don't think changes are required to put them in a subdir:
>
> $ mkdir arch/powerpc/configs/optimized
> $ cp arch/powerpc/configs/mpc5200_defconfig
> arch/powerpc/configs/optimized/lite5200_defconfig
> $ make optimized/lite5200_defconfig
>
> This works for me.
However, I'm not sure what the naming scheme should be for subdirectories.
board vendor?
host processor?
just one big directory for board specific defconfigs?
Olof, Kumar, Josh; any thoughts?
Not that it matters much; files are easy to move around later.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* [PATCH] [v4] Add idle wait support for 44x platforms
From: Jerone Young @ 2008-04-04 16:28 UTC (permalink / raw)
To: linuxppc-dev; +Cc: kvm-ppc-devel
2 files changed, 87 insertions(+), 1 deletion(-)
arch/powerpc/platforms/44x/Makefile | 2
arch/powerpc/platforms/44x/idle.c | 86 +++++++++++++++++++++++++++++++++++
- adds MSR_DE to MSRs to enable while in wait state
This patch adds the ability for the CPU to go into wait state while in cpu_idle loop. This helps virtulization solutions know when the guest Linux kernel is in an idle state. There are two ways to do it.
1) Command line
idle=spin <-- CPU will spin (this is the default)
idle=wait <-- set CPU into wait state when idle
2) The device tree will be checked for the "/hypervisor" node
If this node is seen it will use "wait" for idle, so that
the hypervisor can know when guest Linux kernel it is in
an idle state.
This patch, unlike the last, isolates the code to 44x platforms.
Signed-off-by: Jerone Young <jyoung5@us.ibm.com>
diff --git a/arch/powerpc/platforms/44x/Makefile b/arch/powerpc/platforms/44x/Makefile
--- a/arch/powerpc/platforms/44x/Makefile
+++ b/arch/powerpc/platforms/44x/Makefile
@@ -1,4 +1,4 @@ obj-$(CONFIG_44x) := misc_44x.o
-obj-$(CONFIG_44x) := misc_44x.o
+obj-$(CONFIG_44x) := misc_44x.o idle.o
obj-$(CONFIG_EBONY) += ebony.o
obj-$(CONFIG_TAISHAN) += taishan.o
obj-$(CONFIG_BAMBOO) += bamboo.o
diff --git a/arch/powerpc/platforms/44x/idle.c b/arch/powerpc/platforms/44x/idle.c
new file mode 100644
--- /dev/null
+++ b/arch/powerpc/platforms/44x/idle.c
@@ -0,0 +1,86 @@
+/*
+ * Copyright 2008 IBM Corp.
+ *
+ * Based on arch/powerpc/platforms/pasemi/idle.c:
+ * Copyright (C) 2006-2007 PA Semi, Inc
+ *
+ * Added by: Jerone Young <jyoung5@us.ibm.com>
+ *
+ * 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.
+ *
+ * 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., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ *
+ */
+
+#include <linux/of.h>
+#include <linux/kernel.h>
+#include <asm/machdep.h>
+
+static int current_mode;
+
+struct sleep_mode {
+ char *name;
+ void (*entry)(void);
+};
+
+static void ppc44x_idle(void)
+{
+ unsigned long msr_save;
+
+ msr_save = mfmsr();
+ /* set wait state MSR */
+ mtmsr(msr_save|MSR_WE|MSR_EE|MSR_CE|MSR_DE);
+ isync();
+ /* return to initial state */
+ mtmsr(msr_save);
+ isync();
+}
+
+static struct sleep_mode modes[] = {
+ { .name = "spin", .entry = NULL },
+ { .name = "wait", .entry = &ppc44x_idle },
+};
+
+int __init ppc44x_idle_init(void)
+{
+ void *func = modes[current_mode].entry;
+ struct device_node *node;
+
+ node = of_find_node_by_path("/hypervisor");
+ if (node) {
+ /* if we find /hypervisor node is in device tree,
+ set idle mode to wait */
+ func = &ppc44x_idle; /* wait */
+ of_node_put(node);
+ }
+
+ ppc_md.power_save = func;
+ return 0;
+}
+
+arch_initcall(ppc44x_idle_init);
+
+static int __init idle_param(char *p)
+{
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(modes); i++) {
+ if (!strcmp(modes[i].name, p)) {
+ current_mode = i;
+ break;
+ }
+ }
+
+ return 0;
+}
+
+early_param("idle", idle_param);
^ permalink raw reply
* Re: Please pull linux-2.6-mpc52xx.git
From: Olof Johansson @ 2008-04-04 16:38 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <fa686aa40804040914s3f682e37r16b4cb299e2fc97e@mail.gmail.com>
On Fri, Apr 04, 2008 at 10:14:34AM -0600, Grant Likely wrote:
> On Fri, Apr 4, 2008 at 10:11 AM, Grant Likely <grant.likely@secretlab.ca> wrote:
> > > > > I'm thinking 'optimized' defconfigs should go into a subdirectory.
> > > >
> > > > This requires a change to the top-level Makefile and shepherding this
> > > > change upstream. Could we perhaps try to avoid this by having optimized
> > > > defconfigs in the form of, for example:
> >
> > I don't think changes are required to put them in a subdir:
> >
> > $ mkdir arch/powerpc/configs/optimized
> > $ cp arch/powerpc/configs/mpc5200_defconfig
> > arch/powerpc/configs/optimized/lite5200_defconfig
> > $ make optimized/lite5200_defconfig
> >
> > This works for me.
>
> However, I'm not sure what the naming scheme should be for subdirectories.
>
> board vendor?
> host processor?
> just one big directory for board specific defconfigs?
>
> Olof, Kumar, Josh; any thoughts?
>
> Not that it matters much; files are easy to move around later.
I really like the idea. It would probably make sense to organize it in
the same way as the platforms are done today, i.e. per processor/platform
family. And then have shared/merged configs in the main config directory.
-Olof
^ permalink raw reply
* Re: Please pull linux-2.6-mpc52xx.git
From: Josh Boyer @ 2008-04-04 17:15 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev
In-Reply-To: <20080404163858.GA25717@lixom.net>
On Fri, 2008-04-04 at 11:38 -0500, Olof Johansson wrote:
> On Fri, Apr 04, 2008 at 10:14:34AM -0600, Grant Likely wrote:
> > On Fri, Apr 4, 2008 at 10:11 AM, Grant Likely <grant.likely@secretlab.ca> wrote:
> > > > > > I'm thinking 'optimized' defconfigs should go into a subdirectory.
> > > > >
> > > > > This requires a change to the top-level Makefile and shepherding this
> > > > > change upstream. Could we perhaps try to avoid this by having optimized
> > > > > defconfigs in the form of, for example:
> > >
> > > I don't think changes are required to put them in a subdir:
> > >
> > > $ mkdir arch/powerpc/configs/optimized
> > > $ cp arch/powerpc/configs/mpc5200_defconfig
> > > arch/powerpc/configs/optimized/lite5200_defconfig
> > > $ make optimized/lite5200_defconfig
> > >
> > > This works for me.
> >
> > However, I'm not sure what the naming scheme should be for subdirectories.
> >
> > board vendor?
> > host processor?
> > just one big directory for board specific defconfigs?
> >
> > Olof, Kumar, Josh; any thoughts?
> >
> > Not that it matters much; files are easy to move around later.
>
> I really like the idea. It would probably make sense to organize it in
> the same way as the platforms are done today, i.e. per processor/platform
> family. And then have shared/merged configs in the main config directory.
Yes. I was thinking the same already for 4xx. Essentially:
configs/ppc44x_defconfig
configs/ppc40x_defconfig
configs/44x/<board>_defconfig
configs/40x/<board>_defconfig
josh
^ permalink raw reply
* Re: Please pull linux-2.6-mpc52xx.git
From: Grant Likely @ 2008-04-04 17:25 UTC (permalink / raw)
To: Josh Boyer; +Cc: Olof Johansson, linuxppc-dev
In-Reply-To: <1207329303.6518.16.camel@weaponx>
On Fri, Apr 4, 2008 at 11:15 AM, Josh Boyer > > I really like the
idea. It would probably make sense to organize it in
> > the same way as the platforms are done today, i.e. per processor/platform
> > family. And then have shared/merged configs in the main config directory.
>
> Yes. I was thinking the same already for 4xx. Essentially:
>
> configs/ppc44x_defconfig
> configs/ppc40x_defconfig
> configs/44x/<board>_defconfig
> configs/40x/<board>_defconfig
Sounds logical. I'm cool with this.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH] PowerPC: MPIC ack interrupts at mpic_teardown_this_cpu()
From: Segher Boessenkool @ 2008-04-04 17:38 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev
In-Reply-To: <20080404052955.GC11799@lixom.net>
>>> We really need to ack interrupts at mpic_teardown, since
>>> not all platforms reset mpic at kernel start-up. For example,
>>> kexec'ed kernel hangs on P.A. Semi if mpic_eoi() isn't called.
>>>
>>> Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
>>> ---
>>
>> Would be interesting to find out why it hangs tho... it shouldn't .
>
> I haven't reproduced the problem and looked at hardware state yet, but
> I
> would expect it to be because the openpic won't send another interrupt
> until the previous is EOI'd, and the IPI is never EOI'd as far as I
> can tell.
>
> The XICS code does it explicitly already. I'm surprised it doesn't
> break
> on the 970-based platforms actually...
platforms/maple/setup.c and platforms/powermac/pic.c use
MPIC_WANTS_RESET.
Is there a reason why we don't do that on every MPIC? If there is such
a reason, the default should be to reset, only pseries and chrp and cell
and now pasemi do not use it. It's the only sane way to get an MPIC
into
a sane known state starting from <whatever> state.
Segher
^ permalink raw reply
* Re: [PATCH] PowerPC: MPIC ack interrupts at mpic_teardown_this_cpu()
From: Olof Johansson @ 2008-04-04 18:03 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev
In-Reply-To: <9d19fecb0ef172995b7ce3a317ee3c0d@kernel.crashing.org>
On Fri, Apr 04, 2008 at 07:38:27PM +0200, Segher Boessenkool wrote:
>>>> We really need to ack interrupts at mpic_teardown, since
>>>> not all platforms reset mpic at kernel start-up. For example,
>>>> kexec'ed kernel hangs on P.A. Semi if mpic_eoi() isn't called.
>>>>
>>>> Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
>>>> ---
>>>
>>> Would be interesting to find out why it hangs tho... it shouldn't .
>>
>> I haven't reproduced the problem and looked at hardware state yet, but
>> I
>> would expect it to be because the openpic won't send another interrupt
>> until the previous is EOI'd, and the IPI is never EOI'd as far as I
>> can tell.
>>
>> The XICS code does it explicitly already. I'm surprised it doesn't
>> break
>> on the 970-based platforms actually...
>
> platforms/maple/setup.c and platforms/powermac/pic.c use
> MPIC_WANTS_RESET.
> Is there a reason why we don't do that on every MPIC? If there is such
> a reason, the default should be to reset, only pseries and chrp and cell
> and now pasemi do not use it. It's the only sane way to get an MPIC
> into
> a sane known state starting from <whatever> state.
I used to have the reset there on pasemi but due to some other issues I
ended up taking it out.
It's not like doing a final EOI is a big deal, I really don't see why
there's hassle about this patch.
-Olof
^ permalink raw reply
* [PATCH] [POWERPC] pasemi: Minor cleanups of iommu code
From: Olof Johansson @ 2008-04-04 18:18 UTC (permalink / raw)
To: linuxppc-dev; +Cc: pasemi-linux
Clean up the pwrficient iommu code a bit. It was using u32 *-based offsets
for registers, which can be confusing when comparing to the manual.
Generated binaries from the code is unchanged from before.
---
This will be pushed to for-2.6.26 of pasemi.git, so no signed-off here.
diff --git a/arch/powerpc/platforms/pasemi/iommu.c b/arch/powerpc/platforms/pasemi/iommu.c
index 5803f11..86967bd 100644
--- a/arch/powerpc/platforms/pasemi/iommu.c
+++ b/arch/powerpc/platforms/pasemi/iommu.c
@@ -1,5 +1,5 @@
/*
- * Copyright (C) 2005-2007, PA Semi, Inc
+ * Copyright (C) 2005-2008, PA Semi, Inc
*
* Maintained by: Olof Johansson <olof@lixom.net>
*
@@ -27,7 +27,6 @@
#include <asm/abs_addr.h>
#include <asm/firmware.h>
-
#define IOBMAP_PAGE_SHIFT 12
#define IOBMAP_PAGE_SIZE (1 << IOBMAP_PAGE_SHIFT)
#define IOBMAP_PAGE_MASK (IOBMAP_PAGE_SIZE - 1)
@@ -35,13 +34,13 @@
#define IOB_BASE 0xe0000000
#define IOB_SIZE 0x3000
/* Configuration registers */
-#define IOBCAP_REG 0x10
-#define IOBCOM_REG 0x40
+#define IOBCAP_REG 0x40
+#define IOBCOM_REG 0x100
/* Enable IOB address translation */
#define IOBCOM_ATEN 0x00000100
/* Address decode configuration register */
-#define IOB_AD_REG 0x53
+#define IOB_AD_REG 0x14c
/* IOBCOM_AD_REG fields */
#define IOB_AD_VGPRT 0x00000e00
#define IOB_AD_VGAEN 0x00000100
@@ -56,13 +55,13 @@
#define IOB_AD_TRNG_2G 0x00000001
#define IOB_AD_TRNG_128G 0x00000003
-#define IOB_TABLEBASE_REG 0x55
+#define IOB_TABLEBASE_REG 0x154
/* Base of the 64 4-byte L1 registers */
-#define IOB_XLT_L1_REGBASE 0xac0
+#define IOB_XLT_L1_REGBASE 0x2b00
/* Register to invalidate TLB entries */
-#define IOB_AT_INVAL_TLB_REG 0xb40
+#define IOB_AT_INVAL_TLB_REG 0x2d00
/* The top two bits of the level 1 entry contains valid and type flags */
#define IOBMAP_L1E_V 0x40000000
@@ -76,7 +75,7 @@
#define IOBMAP_L2E_V 0x80000000
#define IOBMAP_L2E_V_CACHED 0xc0000000
-static u32 __iomem *iob;
+static void __iomem *iob;
static u32 iob_l1_emptyval;
static u32 iob_l2_emptyval;
static u32 *iob_l2_base;
@@ -219,7 +218,7 @@ int __init iob_init(struct device_node *dn)
for (i = 0; i < 64; i++) {
/* Each L1 covers 32MB, i.e. 8K entries = 32K of ram */
regword = IOBMAP_L1E_V | (__pa(iob_l2_base + i*0x2000) >> 12);
- out_le32(iob+IOB_XLT_L1_REGBASE+i, regword);
+ out_le32(iob+IOB_XLT_L1_REGBASE+i*4, regword);
}
/* set 2GB translation window, based at 0 */
^ permalink raw reply related
* [PATCH] PowerPC 44x: use machine_device_initcall() instead of device_initcall() for warp_nand
From: Valentine Barshak @ 2008-04-04 18:24 UTC (permalink / raw)
To: linuxppc-dev
With a multiplatform kernel, once built we always have warp_setup_nand_flash() called
and NDFC probed, no matter what machine we actually run on. This potentially can cause
problems (such as kernel crash), since NDFC is probed at a warp-predefined address.
Using machine_device_initcall() NAND devices are registered if we run on a warp only.
Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
---
arch/powerpc/platforms/44x/warp-nand.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletion(-)
--- linux-2.6.orig/arch/powerpc/platforms/44x/warp-nand.c 2008-03-06 14:39:46.000000000 +0300
+++ linux-2.6.bld/arch/powerpc/platforms/44x/warp-nand.c 2008-04-04 22:03:36.000000000 +0400
@@ -11,6 +11,7 @@
#include <linux/mtd/partitions.h>
#include <linux/mtd/nand.h>
#include <linux/mtd/ndfc.h>
+#include <asm/machdep.h>
#ifdef CONFIG_MTD_NAND_NDFC
@@ -100,6 +101,6 @@ static int warp_setup_nand_flash(void)
return 0;
}
-device_initcall(warp_setup_nand_flash);
+machine_device_initcall(warp, warp_setup_nand_flash);
#endif
^ permalink raw reply
* Re: [kvm-ppc-devel] [PATCH] [v2] Add idle wait support for 44x platforms
From: Segher Boessenkool @ 2008-04-04 18:47 UTC (permalink / raw)
To: Jimi Xenidis; +Cc: kvm-ppc-devel, linuxppc-dev
In-Reply-To: <835D8B13-CF90-4013-A172-8243BF93DE52@pobox.com>
>> + msr_save = mfmsr();
>> + /* set wait state MSR */
>> + mtmsr(msr_save|MSR_WE|MSR_EE|MSR_CE);
>
> Did we decide to drop MSR_DE?
>
>> + /* return to initial state */
>> + mtmsr(msr_save);
>
> It may be my paranoia but I'm pretty sure you need the isync() after
> _both_ mtmsr()s
> Certainly can't hurt.
It hurts because it spreads the paranoia. Cargo cult.
Please add a comment that explains _why_ you need a context
synchronising
instruction here. The POWER ISA 2.05 says that the requirements for
changing the WE bit are implementation dependent, both before and after
the mtmsr, so the safe thing to do would be to use the "big hammer"
isync
both before and after each of these mtmsrs. A sync before entering wait
state might be needed as well, dunno. Either way, comment please :-)
Segher
^ permalink raw reply
* Re: [PATCH] PowerPC 44x: use machine_device_initcall() instead of device_initcall() for warp_nand
From: Grant Likely @ 2008-04-04 18:49 UTC (permalink / raw)
To: Valentine Barshak; +Cc: linuxppc-dev
In-Reply-To: <20080404182437.GA18185@ru.mvista.com>
On Fri, Apr 4, 2008 at 12:24 PM, Valentine Barshak
<vbarshak@ru.mvista.com> wrote:
> With a multiplatform kernel, once built we always have warp_setup_nand_flash() called
> and NDFC probed, no matter what machine we actually run on. This potentially can cause
> problems (such as kernel crash), since NDFC is probed at a warp-predefined address.
> Using machine_device_initcall() NAND devices are registered if we run on a warp only.
>
> Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
> ---
> arch/powerpc/platforms/44x/warp-nand.c | 3 ++-
> 1 files changed, 2 insertions(+), 1 deletion(-)
>
> --- linux-2.6.orig/arch/powerpc/platforms/44x/warp-nand.c 2008-03-06 14:39:46.000000000 +0300
> +++ linux-2.6.bld/arch/powerpc/platforms/44x/warp-nand.c 2008-04-04 22:03:36.000000000 +0400
> @@ -11,6 +11,7 @@
> #include <linux/mtd/partitions.h>
> #include <linux/mtd/nand.h>
> #include <linux/mtd/ndfc.h>
> +#include <asm/machdep.h>
>
> #ifdef CONFIG_MTD_NAND_NDFC
>
> @@ -100,6 +101,6 @@ static int warp_setup_nand_flash(void)
>
> return 0;
> }
> -device_initcall(warp_setup_nand_flash);
> +machine_device_initcall(warp, warp_setup_nand_flash);
>
> #endif
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH] PowerPC: MPIC ack interrupts at mpic_teardown_this_cpu()
From: Segher Boessenkool @ 2008-04-04 18:55 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev
In-Reply-To: <20080404180333.GB26693@lixom.net>
>> platforms/maple/setup.c and platforms/powermac/pic.c use
>> MPIC_WANTS_RESET.
>> Is there a reason why we don't do that on every MPIC? If there is
>> such
>> a reason, the default should be to reset, only pseries and chrp and
>> cell
>> and now pasemi do not use it. It's the only sane way to get an MPIC
>> into
>> a sane known state starting from <whatever> state.
>
> I used to have the reset there on pasemi but due to some other issues I
> ended up taking it out.
>
> It's not like doing a final EOI is a big deal, I really don't see why
> there's hassle about this patch.
The patch is fine, don't get me wrong. I'm just saying MPIC_WANTS_RESET
should be the default since pretty much everything wants it. The few
platforms that don't can document why; with the current code, we cannot
see if you just forgot it or not.
Segher
^ permalink raw reply
* Re: [PATCH/RFC] via-pmu: remove mdelays from suspend/resume code
From: Johannes Berg @ 2008-04-04 19:21 UTC (permalink / raw)
To: Brad Boyer; +Cc: linuxppc-dev list
In-Reply-To: <20080404172006.GA13980@cynthia.pants.nu>
[-- Attachment #1: Type: text/plain, Size: 824 bytes --]
On Fri, 2008-04-04 at 10:20 -0700, Brad Boyer wrote:
> On Thu, Apr 03, 2008 at 05:44:44PM +0200, Johannes Berg wrote:
> > I don't see a reason for either of those mdelay()s, is there any? Works
> > fine for me without them...
>
> Which hardware revisions did you test? I suspect the mdelay calls were
> added to work around timing issues in one of the older PMU chips. Some
> of them are very timing sensitive, and sleep in particular is basically
> a pile of steps that got hacked until they worked on older systems.
Mine's a 5,6 powerbook with PMU firmware 0x0c. The mdelay(100) seems
fairly large though for a point where we're out of pmu code already, and
the other one doesn't really seem too pmu related anyway. In any case,
just wanted to float that, don't see a particular need for it.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Re: [PATCH] PowerPC: MPIC ack interrupts at mpic_teardown_this_cpu()
From: Olof Johansson @ 2008-04-04 19:39 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev
In-Reply-To: <63defd942bd57ca87cb17334832b615c@kernel.crashing.org>
On Fri, Apr 04, 2008 at 08:55:01PM +0200, Segher Boessenkool wrote:
>>> platforms/maple/setup.c and platforms/powermac/pic.c use
>>> MPIC_WANTS_RESET.
>>> Is there a reason why we don't do that on every MPIC? If there is
>>> such
>>> a reason, the default should be to reset, only pseries and chrp and
>>> cell
>>> and now pasemi do not use it. It's the only sane way to get an MPIC
>>> into
>>> a sane known state starting from <whatever> state.
>>
>> I used to have the reset there on pasemi but due to some other issues I
>> ended up taking it out.
>>
>> It's not like doing a final EOI is a big deal, I really don't see why
>> there's hassle about this patch.
>
> The patch is fine, don't get me wrong. I'm just saying MPIC_WANTS_RESET
> should be the default since pretty much everything wants it. The few
> platforms that don't can document why; with the current code, we cannot
> see if you just forgot it or not.
It was documented in the changeset, see de0c74e7f98d8a06b784e120103eb388da8194f6.
But yeah, that's hard to tell at some point later in time, a short
comment by the call could be useful. I'll add one next time I touch that
code.
-Olof
^ permalink raw reply
* Re: [RFC/PATCH] powerpc: Add irqtrace support to 32-bit powerpc
From: Johannes Berg @ 2008-04-04 19:33 UTC (permalink / raw)
To: Dale Farnsworth; +Cc: linuxppc-dev, Benjamin Herrenschmidt
In-Reply-To: <1207145738.3957.2.camel@johannes.berg>
[-- Attachment #1: Type: text/plain, Size: 776 bytes --]
On Wed, 2008-04-02 at 16:15 +0200, Johannes Berg wrote:
> On Fri, 2008-02-01 at 12:50 -0700, Dale Farnsworth wrote:
> > This adds the low level irq tracing hooks for 32-bit powerpc.
> > This patch applies on top of Benjamin Herrenschmidt's patch that
> > provides similar support for 64-bit powerpc. See
> > <http://ozlabs.org/pipermail/linuxppc-dev/2007-October/044361.html>
> >
> > It seems to work on my prpmc2800 board with a ppc7447.
>
> At first it appears to work on my powerbook (with Ben's latest version
> of the 64-bit patch), but then it seems to cause random corruption, I've
> had a crash in the ext3 code and one in console_callback(), both of
> which I cannot otherwise explain.
FWIW, same kernel without the patch works fine.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Re: [PATCH/RFC] via-pmu: remove mdelays from suspend/resume code
From: Brad Boyer @ 2008-04-04 17:20 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev list
In-Reply-To: <1207237484.3797.2.camel@johannes.berg>
On Thu, Apr 03, 2008 at 05:44:44PM +0200, Johannes Berg wrote:
> I don't see a reason for either of those mdelay()s, is there any? Works
> fine for me without them...
Which hardware revisions did you test? I suspect the mdelay calls were
added to work around timing issues in one of the older PMU chips. Some
of them are very timing sensitive, and sleep in particular is basically
a pile of steps that got hacked until they worked on older systems.
Brad Boyer
flar@allandria.com
^ permalink raw reply
* Re: [PATCH/RFC] via-pmu: remove mdelays from suspend/resume code
From: Benjamin Herrenschmidt @ 2008-04-04 21:16 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev list
In-Reply-To: <1207336864.19189.74.camel@johannes.berg>
On Fri, 2008-04-04 at 21:21 +0200, Johannes Berg wrote:
> On Fri, 2008-04-04 at 10:20 -0700, Brad Boyer wrote:
> > On Thu, Apr 03, 2008 at 05:44:44PM +0200, Johannes Berg wrote:
> > > I don't see a reason for either of those mdelay()s, is there any? Works
> > > fine for me without them...
> >
> > Which hardware revisions did you test? I suspect the mdelay calls were
> > added to work around timing issues in one of the older PMU chips. Some
> > of them are very timing sensitive, and sleep in particular is basically
> > a pile of steps that got hacked until they worked on older systems.
>
> Mine's a 5,6 powerbook with PMU firmware 0x0c. The mdelay(100) seems
> fairly large though for a point where we're out of pmu code already, and
> the other one doesn't really seem too pmu related anyway. In any case,
> just wanted to float that, don't see a particular need for it.
One of those was meant to let devices settle. The reason is that when
waking from sleep, a lot of HW on the mobo is actually powered up (it
was down during sleep). This delay comes from half paranoia / half
experience, and is meant to ensure all those chips got a chance to
settle and complete their power-on reset sequence before we start
banging all over the place.
Cheers,
Ben.
^ permalink raw reply
* Re: [RFC/PATCH] powerpc: Add irqtrace support to 32-bit powerpc
From: Dale Farnsworth @ 2008-04-04 21:29 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev, Benjamin Herrenschmidt
In-Reply-To: <1207337598.19189.77.camel@johannes.berg>
On Fri, Apr 04, 2008 at 09:33:18PM +0200, Johannes Berg wrote:
> On Wed, 2008-04-02 at 16:15 +0200, Johannes Berg wrote:
> > On Fri, 2008-02-01 at 12:50 -0700, Dale Farnsworth wrote:
> > > This adds the low level irq tracing hooks for 32-bit powerpc.
> > > This patch applies on top of Benjamin Herrenschmidt's patch that
> > > provides similar support for 64-bit powerpc. See
> > > <http://ozlabs.org/pipermail/linuxppc-dev/2007-October/044361.html>
> > >
> > > It seems to work on my prpmc2800 board with a ppc7447.
> >
> > At first it appears to work on my powerbook (with Ben's latest version
> > of the 64-bit patch), but then it seems to cause random corruption, I've
> > had a crash in the ext3 code and one in console_callback(), both of
> > which I cannot otherwise explain.
>
> FWIW, same kernel without the patch works fine.
My apologies, Johannes. I made some unwarranted assumptions about
register usage in the lowest-level exception handlers. While it worked
on my 7447 board, I saw similar random failures on the 85xx (booke) system
I tried.
Thanks for testing this.
I'll follow up with a revised patch.
-Dale
^ permalink raw reply
* Re: [RFC/PATCH] powerpc: Add irqtrace support to 32-bit powerpc
From: Johannes Berg @ 2008-04-04 21:35 UTC (permalink / raw)
To: Dale Farnsworth; +Cc: linuxppc-dev, Benjamin Herrenschmidt
In-Reply-To: <20080404212952.GA15454@farnsworth.org>
[-- Attachment #1: Type: text/plain, Size: 444 bytes --]
> My apologies, Johannes. I made some unwarranted assumptions about
> register usage in the lowest-level exception handlers. While it worked
> on my 7447 board, I saw similar random failures on the 85xx (booke) system
> I tried.
No harm done, just wanted to give it a try and let you know it failed.
> Thanks for testing this.
>
> I'll follow up with a revised patch.
Great, thanks! I'll test that as well then.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* [PATCH v2] powerpc: Add irqtrace support for 32-bit powerpc
From: Dale Farnsworth @ 2008-04-04 21:39 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Johannes Berg
Add the low level irq tracing hooks for 32-bit powerpc needed
to enable full lockdep functionality.
Dale Farnsworth <dale@farnsworth.org>
---
This patch applies on top of Benjamin Herrenschmidt's lockdep patch for
64-bit powerpc. (http://patchwork.ozlabs.org/linuxppc/patch?id=17673)
This version takes care to save and restore *all* the volatile registers
around the call to trace_hardirqs_off in transfer_to_handler, and should
fix the anomalies seen by Johannes Berg. I've tested on 7447- and 8548-
based boards.
arch/powerpc/Kconfig | 1 -
arch/powerpc/kernel/entry_32.S | 90 ++++++++++++++++++++++++++++++++++++++-
arch/powerpc/kernel/setup_32.c | 2 +
include/asm-powerpc/hw_irq.h | 20 ++++----
include/asm-powerpc/system.h | 3 +-
5 files changed, 100 insertions(+), 16 deletions(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 6dbf123..99d8e18 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -55,7 +55,6 @@ config STACKTRACE_SUPPORT
config TRACE_IRQFLAGS_SUPPORT
bool
- depends on PPC64
default y
config LOCKDEP_SUPPORT
diff --git a/arch/powerpc/kernel/entry_32.S b/arch/powerpc/kernel/entry_32.S
index 69a91bd..bd3ce0f 100644
--- a/arch/powerpc/kernel/entry_32.S
+++ b/arch/powerpc/kernel/entry_32.S
@@ -144,6 +144,47 @@ transfer_to_handler:
.globl transfer_to_handler_cont
transfer_to_handler_cont:
3:
+#ifdef CONFIG_TRACE_IRQFLAGS
+ lis r11,reenable_mmu@h
+ ori r11,r11,reenable_mmu@l
+ mtspr SPRN_SRR0,r11
+ mtspr SPRN_SRR1,r10
+ SYNC
+ RFI
+reenable_mmu: /* re-enable mmu so we can */
+ mflr r9 /* call C code, if necessary */
+ mfmsr r10
+ lwz r11,_MSR(r1)
+ xor r10,r10,r11
+ andi. r10,r10,MSR_EE /* Did EE change? */
+ beq 1f
+ stwu r1,-48(r1) /* Yes, it must have been cleared */
+ stw r9,52(r1)
+ stw r0,16(r1)
+ stw r3,20(r1)
+ stw r4,24(r1)
+ stw r5,28(r1)
+ stw r6,32(r1)
+ stw r7,36(r1)
+ stw r8,40(r1)
+ bl trace_hardirqs_off
+ lwz r0,16(r1)
+ lwz r3,20(r1)
+ lwz r4,24(r1)
+ lwz r5,28(r1)
+ lwz r6,32(r1)
+ lwz r7,36(r1)
+ lwz r8,40(r1)
+ lwz r9,52(r1)
+ addi r1,r1,48
+1:
+ tovirt(r9,r9)
+ lwz r11,0(r9) /* virtual address of handler */
+ lwz r9,4(r9) /* where to go when done */
+ mtctr r11
+ mtlr r9
+ bctr /* jump to handler */
+#else /* CONFIG_TRACE_IRQFLAGS */
mflr r9
lwz r11,0(r9) /* virtual address of handler */
lwz r9,4(r9) /* where to go when done */
@@ -152,6 +193,7 @@ transfer_to_handler_cont:
mtlr r9
SYNC
RFI /* jump to handler, enable MMU */
+#endif /* CONFIG_TRACE_IRQFLAGS */
#ifdef CONFIG_6xx
4: rlwinm r12,r12,0,~_TLF_NAPPING
@@ -220,12 +262,20 @@ ret_from_syscall:
#ifdef SHOW_SYSCALLS
bl do_show_syscall_exit
#endif
- mr r6,r3
rlwinm r12,r1,0,0,(31-THREAD_SHIFT) /* current_thread_info() */
/* disable interrupts so current_thread_info()->flags can't change */
LOAD_MSR_KERNEL(r10,MSR_KERNEL) /* doesn't include MSR_EE */
SYNC
MTMSRD(r10)
+#ifdef CONFIG_TRACE_IRQFLAGS
+ stwu r1,-16(r1)
+ stw r3,12(r1)
+ bl trace_hardirqs_off
+ lwz r3,12(r1)
+ addi r1,r1,16
+ LOAD_MSR_KERNEL(r10,MSR_KERNEL)
+#endif
+ mr r6,r3
lwz r9,TI_FLAGS(r12)
li r8,-_LAST_ERRNO
andi. r0,r9,(_TIF_SYSCALL_T_OR_A|_TIF_SINGLESTEP|_TIF_USER_WORK_MASK|_TIF_PERSYSCALL_MASK)
@@ -237,6 +287,13 @@ ret_from_syscall:
oris r11,r11,0x1000 /* Set SO bit in CR */
stw r11,_CCR(r1)
syscall_exit_cont:
+#ifdef CONFIG_TRACE_IRQFLAGS
+ stwu r1,-16(r1)
+ stw r3,12(r1)
+ bl trace_hardirqs_on
+ lwz r3,12(r1)
+ addi r1,r1,16
+#endif
#if defined(CONFIG_4xx) || defined(CONFIG_BOOKE)
/* If the process has its own DBCR0 value, load it up. The single
step bit tells us that dbcr0 should be loaded. */
@@ -337,7 +394,10 @@ syscall_exit_work:
4: /* Anything which requires enabling interrupts? */
andi. r0,r9,(_TIF_SYSCALL_T_OR_A|_TIF_SINGLESTEP)
beq ret_from_except
-
+#ifdef CONFIG_TRACE_IRQFLAGS
+ bl trace_hardirqs_on
+ LOAD_MSR_KERNEL(r10,MSR_KERNEL)
+#endif
/* Re-enable interrupts */
ori r10,r10,MSR_EE
SYNC
@@ -646,13 +706,22 @@ ret_from_except_full:
.globl ret_from_except
ret_from_except:
+#ifdef CONFIG_TRACE_IRQFLAGS
+ mfmsr r3
+#endif
/* Hard-disable interrupts so that current_thread_info()->flags
* can't change between when we test it and when we return
* from the interrupt. */
LOAD_MSR_KERNEL(r10,MSR_KERNEL)
SYNC /* Some chip revs have problems here... */
MTMSRD(r10) /* disable interrupts */
-
+#ifdef CONFIG_TRACE_IRQFLAGS
+ andi. r3,r3,MSR_EE
+ beq 1f /* verified */
+ bl trace_hardirqs_off
+ LOAD_MSR_KERNEL(r10,MSR_KERNEL)
+1:
+#endif
lwz r3,_MSR(r1) /* Returning to user mode? */
andi. r0,r3,MSR_PR
beq resume_kernel
@@ -709,6 +778,9 @@ restore:
stw r6,icache_44x_need_flush@l(r4)
1:
#endif /* CONFIG_44x */
+#ifdef CONFIG_TRACE_IRQFLAGS
+ bl trace_hardirqs_on
+#endif
lwz r0,GPR0(r1)
lwz r2,GPR2(r1)
REST_4GPRS(3, r1)
@@ -900,6 +972,10 @@ do_work: /* r10 contains MSR_KERNEL here */
beq do_user_signal
do_resched: /* r10 contains MSR_KERNEL here */
+#ifdef CONFIG_TRACE_IRQFLAGS
+ bl trace_hardirqs_on
+ LOAD_MSR_KERNEL(r10,MSR_KERNEL)
+#endif
ori r10,r10,MSR_EE
SYNC
MTMSRD(r10) /* hard-enable interrupts */
@@ -908,6 +984,10 @@ recheck:
LOAD_MSR_KERNEL(r10,MSR_KERNEL)
SYNC
MTMSRD(r10) /* disable interrupts */
+#ifdef CONFIG_TRACE_IRQFLAGS
+ bl trace_hardirqs_off
+ LOAD_MSR_KERNEL(r10,MSR_KERNEL)
+#endif
rlwinm r9,r1,0,0,(31-THREAD_SHIFT)
lwz r9,TI_FLAGS(r9)
andi. r0,r9,_TIF_NEED_RESCHED
@@ -915,6 +995,10 @@ recheck:
andi. r0,r9,_TIF_SIGPENDING|_TIF_RESTORE_SIGMASK
beq restore_user
do_user_signal: /* r10 contains MSR_KERNEL here */
+#ifdef CONFIG_TRACE_IRQFLAGS
+ bl trace_hardirqs_on
+ LOAD_MSR_KERNEL(r10,MSR_KERNEL)
+#endif
ori r10,r10,MSR_EE
SYNC
MTMSRD(r10) /* hard-enable interrupts */
diff --git a/arch/powerpc/kernel/setup_32.c b/arch/powerpc/kernel/setup_32.c
index cd870a8..725dd18 100644
--- a/arch/powerpc/kernel/setup_32.c
+++ b/arch/powerpc/kernel/setup_32.c
@@ -120,6 +120,8 @@ unsigned long __init early_init(unsigned long dt_ptr)
*/
void __init machine_init(unsigned long dt_ptr, unsigned long phys)
{
+ lockdep_init();
+
/* Enable early debugging if any specified (see udbg.h) */
udbg_early_init();
diff --git a/include/asm-powerpc/hw_irq.h b/include/asm-powerpc/hw_irq.h
index ad8c9f7..a5f347a 100644
--- a/include/asm-powerpc/hw_irq.h
+++ b/include/asm-powerpc/hw_irq.h
@@ -63,13 +63,13 @@ extern void iseries_handle_interrupts(void);
#if defined(CONFIG_BOOKE)
#define SET_MSR_EE(x) mtmsr(x)
-#define local_irq_restore(flags) __asm__ __volatile__("wrtee %0" : : "r" (flags) : "memory")
+#define raw_local_irq_restore(flags) __asm__ __volatile__("wrtee %0" : : "r" (flags) : "memory")
#else
#define SET_MSR_EE(x) mtmsr(x)
-#define local_irq_restore(flags) mtmsr(flags)
+#define raw_local_irq_restore(flags) mtmsr(flags)
#endif
-static inline void local_irq_disable(void)
+static inline void raw_local_irq_disable(void)
{
#ifdef CONFIG_BOOKE
__asm__ __volatile__("wrteei 0": : :"memory");
@@ -81,7 +81,7 @@ static inline void local_irq_disable(void)
#endif
}
-static inline void local_irq_enable(void)
+static inline void raw_local_irq_enable(void)
{
#ifdef CONFIG_BOOKE
__asm__ __volatile__("wrteei 1": : :"memory");
@@ -93,7 +93,7 @@ static inline void local_irq_enable(void)
#endif
}
-static inline void local_irq_save_ptr(unsigned long *flags)
+static inline void raw_local_irq_save_ptr(unsigned long *flags)
{
unsigned long msr;
msr = mfmsr();
@@ -106,12 +106,12 @@ static inline void local_irq_save_ptr(unsigned long *flags)
__asm__ __volatile__("": : :"memory");
}
-#define local_save_flags(flags) ((flags) = mfmsr())
-#define local_irq_save(flags) local_irq_save_ptr(&flags)
-#define irqs_disabled() ((mfmsr() & MSR_EE) == 0)
+#define raw_local_save_flags(flags) ((flags) = mfmsr())
+#define raw_local_irq_save(flags) raw_local_irq_save_ptr(&flags)
+#define raw_irqs_disabled() ((mfmsr() & MSR_EE) == 0)
+#define raw_irqs_disabled_flags(flags) (((flags) & MSR_EE) == 0)
-#define hard_irq_enable() local_irq_enable()
-#define hard_irq_disable() local_irq_disable()
+#define hard_irq_disable() raw_local_irq_disable()
#endif /* CONFIG_PPC64 */
diff --git a/include/asm-powerpc/system.h b/include/asm-powerpc/system.h
index 29552ff..e040a48 100644
--- a/include/asm-powerpc/system.h
+++ b/include/asm-powerpc/system.h
@@ -5,8 +5,7 @@
#define _ASM_POWERPC_SYSTEM_H
#include <linux/kernel.h>
-
-#include <asm/hw_irq.h>
+#include <linux/irqflags.h>
/*
* Memory barrier.
--
1.5.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox