Re: [swsusp/ppc] Re: What's going on here ?

2005-03-14 Thread hugang
On Tue, Mar 15, 2005 at 01:19:46PM +1100, Benjamin Herrenschmidt wrote:
> 
> > rjw and hugang did (pretty neccessary) changes to base swsusp (pagedir
> > table -> pagedir linklist), that unfortunately needed update to all
> > the assembly parts. It was series 1/3 update core, i386 and x86-64,
> > 2/3 update ppc, 3/3 introduce initramfs.
> > 
> > This is the offending patch I believe (but the version that was merged
> > was From: me, without code changes).
> > 
> > I realized that patch does more than changing from table to linklist,
> > but it looked mostly okay, so I forwarded it. Sorry.
> 
> It does more than that ... it _adds_ swsusp to ppc ! swsusp wasn't in
> mainline at all for ppc because I consider it not ready. And even the
> asm change should go through me anyway since i wrote that code and I'm
> not sure they know all the possible "issues" with that code.
> 
> > So, what to do now?
> > 
> > a) just revert it
> > 
> > or
> > 
> > b) revert pmac_setup.c and via-pmu parts and Kconfig part
> > 
> > or
> > 
> > c) just disable Kconfig part and fix it up with incremental patches

I hope that's can merge into, It works fine in my PowerBook G4.

> 
> I'll decide later today. I may well keep it and do the cleanup I had in
> mind on top of this, which means merging the pmac suspend-to-ram with
> the common infrastructure. But that will need some changes & hooks to
> the core swsusp.
> 
> Ben.


-- 
Hu Gang   .-.
  /v\
 // \\ 
Linux User  /(   )\  [204016]
GPG Key ID   ^^-^^   http://soulinfo.com/~hugang/hugang.asc
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [swsusp/ppc] Re: What's going on here ?

2005-03-14 Thread Benjamin Herrenschmidt

> rjw and hugang did (pretty neccessary) changes to base swsusp (pagedir
> table -> pagedir linklist), that unfortunately needed update to all
> the assembly parts. It was series 1/3 update core, i386 and x86-64,
> 2/3 update ppc, 3/3 introduce initramfs.
> 
> This is the offending patch I believe (but the version that was merged
> was From: me, without code changes).
> 
> I realized that patch does more than changing from table to linklist,
> but it looked mostly okay, so I forwarded it. Sorry.

It does more than that ... it _adds_ swsusp to ppc ! swsusp wasn't in
mainline at all for ppc because I consider it not ready. And even the
asm change should go through me anyway since i wrote that code and I'm
not sure they know all the possible "issues" with that code.

> So, what to do now?
> 
> a) just revert it
> 
> or
> 
> b) revert pmac_setup.c and via-pmu parts and Kconfig part
> 
> or
> 
> c) just disable Kconfig part and fix it up with incremental patches

I'll decide later today. I may well keep it and do the cleanup I had in
mind on top of this, which means merging the pmac suspend-to-ram with
the common infrastructure. But that will need some changes & hooks to
the core swsusp.

Ben.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[swsusp/ppc] Re: What's going on here ?

2005-03-14 Thread Pavel Machek
Hi!

> Hi just see that the whole stack of pmac SWSUSP patches went in, without
> any notice nor CC nor anything from any of the PPC maintainers ! That is
> a bit annoying don't you think ?
> 
> Paulus and I wrote most of those patches, granted, and they've been
> hanging around for some time, but I had good reasons not to submit them
> in their current state.
> 
> And regardless, I'm pretty pissed off by the fact that such invasive
> changes to the architecture and the platform support were submitted and
> merged without any notice nor ack from any of the arch or platform
> maintainers (basically paulus and me).

Sorry, that's probably my fault.

rjw and hugang did (pretty neccessary) changes to base swsusp (pagedir
table -> pagedir linklist), that unfortunately needed update to all
the assembly parts. It was series 1/3 update core, i386 and x86-64,
2/3 update ppc, 3/3 introduce initramfs.

This is the offending patch I believe (but the version that was merged
was From: me, without code changes).

I realized that patch does more than changing from table to linklist,
but it looked mostly okay, so I forwarded it. Sorry.

So, what to do now?

a) just revert it

or

b) revert pmac_setup.c and via-pmu parts and Kconfig part

or

c) just disable Kconfig part and fix it up with incremental patches

?
Pavel


From: "Rafael J. Wysocki" <[EMAIL PROTECTED]>
To: Andrew Morton <[EMAIL PROTECTED]>
Subject: [PATCH][3/3] swsusp: use non-contiguous memory
Cc: Hu Gang <[EMAIL PROTECTED]>,
LKML , Pavel Machek <[EMAIL PROTECTED]>
Lines: 686

From: Hu Gang <[EMAIL PROTECTED]>

Subject: swsusp: use non-contiguous memory on resume - ppc support

This patch contains the architecture-dependent changes for ppc
required for using a linklist instead of an array of page backup entries
during resume.

Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]>

diff -Nru linux-2.6.11-a/arch/ppc/Kconfig linux-2.6.11-b/arch/ppc/Kconfig
--- linux-2.6.11-a/arch/ppc/Kconfig 2005-03-02 08:38:33.0 +0100
+++ linux-2.6.11-b/arch/ppc/Kconfig 2005-03-04 18:42:16.0 +0100
@@ -1046,6 +1046,8 @@
 
 source "drivers/zorro/Kconfig"
 
+source kernel/power/Kconfig
+
 endmenu
 
 menu "Bus options"
diff -Nru linux-2.6.11-a/arch/ppc/kernel/asm-offsets.c 
linux-2.6.11-b/arch/ppc/kernel/asm-offsets.c
--- linux-2.6.11-a/arch/ppc/kernel/asm-offsets.c2005-03-02 
08:38:09.0 +0100
+++ linux-2.6.11-b/arch/ppc/kernel/asm-offsets.c2005-03-04 
18:42:16.0 +0100
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -136,6 +137,10 @@
DEFINE(TI_CPU, offsetof(struct thread_info, cpu));
DEFINE(TI_PREEMPT, offsetof(struct thread_info, preempt_count));
 
+   DEFINE(pbe_address, offsetof(struct pbe, address));
+   DEFINE(pbe_orig_address, offsetof(struct pbe, orig_address));
+   DEFINE(pbe_next, offsetof(struct pbe, next));
+
DEFINE(NUM_USER_SEGMENTS, TASK_SIZE>>28);
return 0;
 }
diff -Nru linux-2.6.11-a/arch/ppc/kernel/Makefile 
linux-2.6.11-b/arch/ppc/kernel/Makefile
--- linux-2.6.11-a/arch/ppc/kernel/Makefile 2005-03-02 08:38:25.0 
+0100
+++ linux-2.6.11-b/arch/ppc/kernel/Makefile 2005-03-04 18:42:16.0 
+0100
@@ -16,6 +16,7 @@
semaphore.o syscalls.o setup.o \
cputable.o ppc_htab.o perfmon.o
 obj-$(CONFIG_6xx)  += l2cr.o cpu_setup_6xx.o
+obj-$(CONFIG_SOFTWARE_SUSPEND) += swsusp.o
 obj-$(CONFIG_POWER4)   += cpu_setup_power4.o
 obj-$(CONFIG_MODULES)  += module.o ppc_ksyms.o
 obj-$(CONFIG_NOT_COHERENT_CACHE)   += dma-mapping.o
diff -Nru linux-2.6.11-a/arch/ppc/kernel/signal.c 
linux-2.6.11-b/arch/ppc/kernel/signal.c
--- linux-2.6.11-a/arch/ppc/kernel/signal.c 2005-03-02 08:38:33.0 
+0100
+++ linux-2.6.11-b/arch/ppc/kernel/signal.c 2005-03-04 18:42:16.0 
+0100
@@ -28,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -704,6 +705,14 @@
unsigned long frame, newsp;
int signr, ret;
 
+   if (current->flags & PF_FREEZE) {
+   refrigerator(PF_FREEZE);
+   signr = 0;
+   ret = regs->gpr[3];
+   if (!signal_pending(current))
+   goto no_signal;
+   }
+
if (!oldset)
oldset = ¤t->blocked;
 
@@ -726,6 +735,7 @@
regs->gpr[3] = EINTR;
/* note that the cr0.SO bit is already set */
} else {
+no_signal:
regs->nip -= 4; /* Back up & retry system call */
regs->result = 0;
regs->trap = 0;
diff -Nru linux-2.6.11-a/arch/ppc/kernel/swsusp.S 
linux-2.6.11-b/arch/ppc/kernel/swsusp.S
--- linux-2.6.11-a/arch/ppc/kernel/swsusp.S 1970-01-01 01:00:00.

What's going on here ?

2005-03-14 Thread Benjamin Herrenschmidt
Hi just see that the whole stack of pmac SWSUSP patches went in, without
any notice nor CC nor anything from any of the PPC maintainers ! That is
a bit annoying don't you think ?

Paulus and I wrote most of those patches, granted, and they've been
hanging around for some time, but I had good reasons not to submit them
in their current state.

And regardless, I'm pretty pissed off by the fact that such invasive
changes to the architecture and the platform support were submitted and
merged without any notice nor ack from any of the arch or platform
maintainers (basically paulus and me).

Ben.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/