* [PATCH/RFC] via-pmu: remove mdelays from suspend/resume code
From: Johannes Berg @ 2008-04-03 15:44 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list
I don't see a reason for either of those mdelay()s, is there any? Works
fine for me without them...
johannes
---
drivers/macintosh/via-pmu.c | 20 +++-----------------
1 file changed, 3 insertions(+), 17 deletions(-)
--- everything.orig/drivers/macintosh/via-pmu.c 2008-04-03 17:27:29.000000000 +0200
+++ everything/drivers/macintosh/via-pmu.c 2008-04-03 17:28:23.000000000 +0200
@@ -2165,8 +2165,6 @@ static void pmac_suspend_disable_irqs(vo
static int powerbook_sleep(suspend_state_t state)
{
- int error = 0;
-
/* Wait for completion of async requests */
while (!batt_req.complete)
pmu_poll();
@@ -2183,25 +2181,15 @@ static int powerbook_sleep(suspend_state
switch (pmu_kind) {
case PMU_OHARE_BASED:
- error = powerbook_sleep_3400();
- break;
+ return powerbook_sleep_3400();
case PMU_HEATHROW_BASED:
case PMU_PADDINGTON_BASED:
- error = powerbook_sleep_grackle();
- break;
+ return powerbook_sleep_grackle();
case PMU_KEYLARGO_BASED:
- error = powerbook_sleep_Core99();
- break;
+ return powerbook_sleep_Core99();
default:
return -ENOSYS;
}
-
- if (error)
- return error;
-
- mdelay(100);
-
- return 0;
}
static void pmac_suspend_enable_irqs(void)
@@ -2210,8 +2198,6 @@ static void pmac_suspend_enable_irqs(voi
adb_int_pending = 1;
via_pmu_interrupt(0, NULL);
- mdelay(10);
-
/* Call platform functions marked "on wake" */
pmac_pfunc_base_resume();
pmac_pfunc_i2c_resume();
^ permalink raw reply
* Re: [kvm-ppc-devel] [PATCH] Add idle wait support for 44x platforms
From: Hollis Blanchard @ 2008-04-04 14:33 UTC (permalink / raw)
To: jyoung5; +Cc: kvm-ppc-devel, linuxppc-dev
In-Reply-To: <1207288799.6971.11.camel@thinkpadL>
On Friday 04 April 2008 00:59:59 Jerone Young wrote:
> On Thu, 2008-04-03 at 21:00 -0500, Josh Boyer wrote:
> > On Thu, 03 Apr 2008 17:43:02 -0500
> >
> > Jerone Young <jyoung5@us.ibm.com> wrote:
> > > # HG changeset patch
> > > # User Jerone Young <jyoung5@us.ibm.com>
> > > # Date 1207262487 18000
> > > # Node ID 7226bef216680748a50327900572c2fbc3e762b0
> > > # Parent =A0a5b2aebbc6ebd2439c655f1c047ed7e3c1991ec1
> >
> > As a complete and unrelated side note to the actual patch, wtf is this
> > hg stuff? =A0I can't really tell what tree you're even basing this off =
of.
>
> hehe...I primary use hg as it's just much easier to deal with. Yes I do
> go through the conversion. But it is worth it. The patches I send are in
> git format.
By the way, you can use "hg email --plain" to avoid confusing the=20
unenlightened. ;) The Mercurial changeset data won't be useful here=20
anyways...
In reply to an earlier unrelated comment, there is also "hg email --diffsta=
t".
=2D-=20
Hollis Blanchard
IBM Linux Technology Center
^ permalink raw reply
* Re: cpu_clock confusion (was: printk time confusion?)
From: Ingo Molnar @ 2008-04-04 14:46 UTC (permalink / raw)
To: Johannes Berg
Cc: linuxppc-dev list, Arnd Bergmann, Linux Kernel list,
Benjamin Herrenschmidt
In-Reply-To: <1207240450.3797.22.camel@johannes.berg>
* Johannes Berg <johannes@sipsolutions.net> wrote:
> Hi,
>
> > > Not sure whether the lockdep patches or something else is causing this
> > > as I haven't checked w/o the patches yet, but I seem to be having some
> > > confusion of printk timestamps:
> >
> > Tried reverting the patches ?
>
> That didn't help, so it's not the lockdep patches causing it. I'm still
> seeing printk timestamps like this:
>
> [ 2.764009 (3/3)]
> [ 4.272241 (2/2)]
> [ 4.272322 (2/2)]
> [ 4.272375 (2/2)]
> [ 2.948002 (3/3)]
>
> As you can see, I added printk_cpu and smp_processor_id() to the
> printk timestamp output and thus it is obvious that the different
> times come from different CPUs.
the fixes are queued for v2.6.26. You can pick them up from
sched-devel/latest as well:
http://people.redhat.com/mingo/sched-devel.git/README
Ingo
^ permalink raw reply
* 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
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