[PATCH] ppc32: Rework power management take #3

[PATCH] ppc32: Rework power management take #3

[Benjamin Herrenschmidt]

Ok, the patch is now getting "good enough" for wider testing. It applies
on current "git" tree (or 2.6.12-rc6 when/if that is ever released). It
requires one other patch to be applied first:

http://gate.crashing.org/~benh/ppc32-remove-macserial.diff

The PM patch itself can be found at:

http://gate.crashing.org/~benh/ppc32-rework-pm.diff

This patch completely reworks both suspend-to-ram and suspend-to-disk
support on PowerMac:

 - suspend-to-ram code is moved away from the via-pmu.c driver
 - both suspend-to-disk & to-ram consolidated to use the same
infrastructure and code base in a new pmac_pm.c file
 - significants fixes & improvements to suspend-to-disk
 - for now (may change), use the "refrigerator" with suspend-to-ram as
well as suspend-to-disk. This may help make it a bit more robust vs.
userland activity during the sleep process
 - CONFIG_PMAC_PBOOK is gone. CONFIG_PMAC_MEDIABAY is new and controls
wether the powerbook hostwap bay driver is included. The rest of bits
formerly under CONFIG_PMAC_PBOOK control are now either always on
(like /dev/pmu interface on PMU based machines) or dependent on other
config options (like CONFIG_PM, CONFIG_PPC_PMAC, ...)

The patch will not be in 2.6.12 (though will probably apply on top of
it). I aim for a 2.6.13 release, knowing that the patch changes a bunch
of non-ppc-specific power management bits, and thus may need some time
to be fully merged upstream.

Re: ppc32: Rework power management take #3

[Mickael Royer]

Hi Ben

> Ok, the patch is now getting "good enough" for wider testing. It applies
> on current "git" tree (or 2.6.12-rc6 when/if that is ever released).

I have just tested your patch with the 2.5.12-rc5-git5 on the new powerbook=
 12".
And yes, the suspend to disk works very well, even if X is running (I
report my problem with X and the suspend to disk with a 2.6.12-rc4 in
another discussion).
It is really good.=20

Thanks for your good job Ben.=20

Mickael

On 5/30/05, Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> Ok, the patch is now getting "good enough" for wider testing. It applies
> on current "git" tree (or 2.6.12-rc6 when/if that is ever released). It
> requires one other patch to be applied first:
>=20
> http://gate.crashing.org/~benh/ppc32-remove-macserial.diff
>=20
> The PM patch itself can be found at:
>=20
> http://gate.crashing.org/~benh/ppc32-rework-pm.diff
>=20
> This patch completely reworks both suspend-to-ram and suspend-to-disk
> support on PowerMac:
>=20
>  - suspend-to-ram code is moved away from the via-pmu.c driver
>  - both suspend-to-disk & to-ram consolidated to use the same
> infrastructure and code base in a new pmac_pm.c file
>  - significants fixes & improvements to suspend-to-disk
>  - for now (may change), use the "refrigerator" with suspend-to-ram as
> well as suspend-to-disk. This may help make it a bit more robust vs.
> userland activity during the sleep process
>  - CONFIG_PMAC_PBOOK is gone. CONFIG_PMAC_MEDIABAY is new and controls
> wether the powerbook hostwap bay driver is included. The rest of bits
> formerly under CONFIG_PMAC_PBOOK control are now either always on
> (like /dev/pmu interface on PMU based machines) or dependent on other
> config options (like CONFIG_PM, CONFIG_PPC_PMAC, ...)
>=20
> The patch will not be in 2.6.12 (though will probably apply on top of
> it). I aim for a 2.6.13 release, knowing that the patch changes a bunch
> of non-ppc-specific power management bits, and thus may need some time
> to be fully merged upstream.
>=20
>=20
>=20
>=20
> --=20
> To UNSUBSCRIBE, email to debian-powerpc-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmaster@lists.debian.org
>=20
>

Re: ppc32: Rework power management take #3

[Wolfram Quester]

[-- Attachment #1: Type: text/plain, Size: 1517 bytes --]

Hi,


On Mon, May 30, 2005 at 11:59:14PM +0200, Mickael Royer wrote:
> Hi Ben
> 
> > Ok, the patch is now getting "good enough" for wider testing. It applies
> > on current "git" tree (or 2.6.12-rc6 when/if that is ever released).
> 
> I have just tested your patch with the 2.5.12-rc5-git5 on the new powerbook 12".
> And yes, the suspend to disk works very well, even if X is running (I
> report my problem with X and the suspend to disk with a 2.6.12-rc4 in
> another discussion).
> It is really good. 
> 
> Thanks for your good job Ben. 
> 
> Mickael
> 
> On 5/30/05, Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> > Ok, the patch is now getting "good enough" for wider testing. It applies
> > on current "git" tree (or 2.6.12-rc6 when/if that is ever released). It
> > requires one other patch to be applied first:
> > 
> > http://gate.crashing.org/~benh/ppc32-remove-macserial.diff
> > 
> > The PM patch itself can be found at:
> > 
> > http://gate.crashing.org/~benh/ppc32-rework-pm.diff
> > 
> > This patch completely reworks both suspend-to-ram and suspend-to-disk
> > support on PowerMac:
[...snip...]

Today I applied the two mentioned patches to rc5-git6. There were quite
a lot of offsets and one time fuzz 2 (hunk 10 in via-pm.c). But still I
get a freeze on my PowerBook6,2 (12", 1Ghz from Dec. 2004) when I
suspend to disk from X. If I suspend from tty1 the first time, the
following suspends work well even from X.

Thanks for your work,

Wolfi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: ppc32: Rework power management take #3

[Benjamin Herrenschmidt]

> Today I applied the two mentioned patches to rc5-git6. There were quite
> a lot of offsets and one time fuzz 2 (hunk 10 in via-pm.c). But still I
> get a freeze on my PowerBook6,2 (12", 1Ghz from Dec. 2004) when I
> suspend to disk from X. If I suspend from tty1 the first time, the
> following suspends work well even from X.
> 
> Thanks for your work,

Bizarre... The kernel is normally first opens a new tty and switches to
it before suspend. It seems that this opening of a new tty is
conflicting in some way with X "nv" driver and causing that freeze. Are
you also using an fbdev like rivafb or nvidiafb or are you defaulting to
offb ? If you do, Can you try booting with video=ofonly and tell me if
it helps ?

Ben.

Re: ppc32: Rework power management take #3

[Wolfram Quester]

[-- Attachment #1: Type: text/plain, Size: 1326 bytes --]

On Fri, Jun 03, 2005 at 08:15:03AM +1000, Benjamin Herrenschmidt wrote:
> 
> > Today I applied the two mentioned patches to rc5-git6. There were quite
> > a lot of offsets and one time fuzz 2 (hunk 10 in via-pm.c). But still I
> > get a freeze on my PowerBook6,2 (12", 1Ghz from Dec. 2004) when I
> > suspend to disk from X. If I suspend from tty1 the first time, the
> > following suspends work well even from X.
> > 
> > Thanks for your work,
> 
> Bizarre... The kernel is normally first opens a new tty and switches to
> it before suspend. It seems that this opening of a new tty is
> conflicting in some way with X "nv" driver and causing that freeze. Are
> you also using an fbdev like rivafb or nvidiafb or are you defaulting to
> offb ? If you do, Can you try booting with video=ofonly and tell me if
> it helps ?
> 
> Ben.
Normally I use rivafb, but I tried video=ofonly and did not get a
freeze. I tried it three times and I hope that this is good statistics.
With 2.6.12-rc2 and riva fb I got the freeze in about 80% of all initial
suspends, with rc{4,5-git6} and riva fb I had it everytime. But it may
still well be that there is a random component since I learned to
workaround the problem by switching to tty1 and thus don't trigger the
freeze condition that often.


Thanks,

Wolfi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: ppc32: Rework power management take #3

[Benjamin Herrenschmidt]

> Normally I use rivafb, but I tried video=ofonly and did not get a
> freeze. I tried it three times and I hope that this is good statistics.
> With 2.6.12-rc2 and riva fb I got the freeze in about 80% of all initial
> suspends, with rc{4,5-git6} and riva fb I had it everytime. But it may
> still well be that there is a random component since I learned to
> workaround the problem by switching to tty1 and thus don't trigger the
> freeze condition that often.

Ok, what happens if you run rivafb, ssh into the box, and open a new tty
(that is leave the box on X, but do something like echo "toto"
>/dev/tty8) to create a new tty in the background.

Does that trigger the freeze ?

Ben.

Re: ppc32: Rework power management take #3

[Wolfram Quester]

[-- Attachment #1: Type: text/plain, Size: 1589 bytes --]

Hi Ben,

On Sat, Jun 04, 2005 at 08:43:57AM +1000, Benjamin Herrenschmidt wrote:
> 
> > Normally I use rivafb, but I tried video=ofonly and did not get a
> > freeze. I tried it three times and I hope that this is good statistics.
> > With 2.6.12-rc2 and riva fb I got the freeze in about 80% of all initial
> > suspends, with rc{4,5-git6} and riva fb I had it everytime. But it may
> > still well be that there is a random component since I learned to
> > workaround the problem by switching to tty1 and thus don't trigger the
> > freeze condition that often.
> 
> Ok, what happens if you run rivafb, ssh into the box, and open a new tty
> (that is leave the box on X, but do something like echo "toto"
> >/dev/tty8) to create a new tty in the background.
> 
> Does that trigger the freeze ?
> 
> Ben.

OK, I tried that in some variations. If I do as you suggest, nothing
happens, I can login and use X as normal. But as soon as I try to switch
to tty1, the machine freezes. Without this ssh-stuff I can switch to
tty1 and back and be happy.

Then I rebooted, ssh'd into the box and added the line
8:23:respawn:/sbin/getty 38400 tty8
to open getty on tty8. I did telinit q to reload the init config and got
the same thing as described above. After a reboot and leaving the line
intact I could switch to tty8 and be happy. 

Again, I ssh'd into the box and opened tty9 via echo... which lead to
the behaviour already described.

This looks to me as if it fails to switch to a tty which was not
allocated before.

Thanks for looking into this,

Wolfi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: ppc32: Rework power management take #3

[Benjamin Herrenschmidt]

> This looks to me as if it fails to switch to a tty which was not
> allocated before.

There is a known issue with "creating" a new tty vs. X that I though was
fixed, but may be still lurking around with nvidia stuff, I'll be
looking at it. Thanks.

Ben.

Re: [PATCH] ppc32: Rework power management take #3

[Geoff Levand]

I had a problem when building for ppc440 (gcc -m405).  I wonder if we 
need some conditionals on the DSSALL statement as below, or is DSSALL 
intended to be a perprocessor macro that would expand to a blank line
in this case?

-Geoff


dssall-fix.patch:

Index: linux-2.6.12-bhpm/arch/ppc/kernel/swsusp.S
===================================================================
--- linux-2.6.12-bhpm.orig/arch/ppc/kernel/swsusp.S	2005-06-02 15:09:22.000000000 -0700
+++ linux-2.6.12-bhpm/arch/ppc/kernel/swsusp.S	2005-06-02 15:29:56.000000000 -0700
@@ -134,11 +134,13 @@
 /* Resume code */
 _GLOBAL(swsusp_arch_resume)
 
+#ifdef CONFIG_ALTIVEC
 	/* Stop pending alitvec streams and memory accesses */
 BEGIN_FTR_SECTION
 	DSSALL
 END_FTR_SECTION_IFSET(CPU_FTR_ALTIVEC)
- 	sync
+#endif
+	sync
 
 	/* Disable MSR:DR to make sure we don't take a TLB or
 	 * hash miss during the copy, as our hash table will


Benjamin Herrenschmidt wrote:
> Ok, the patch is now getting "good enough" for wider testing. It applies
> on current "git" tree (or 2.6.12-rc6 when/if that is ever released). It
> requires one other patch to be applied first:
> 
> http://gate.crashing.org/~benh/ppc32-remove-macserial.diff
> 
> The PM patch itself can be found at:
> 
> http://gate.crashing.org/~benh/ppc32-rework-pm.diff
> 
> This patch completely reworks both suspend-to-ram and suspend-to-disk
> support on PowerMac:
> 
>  - suspend-to-ram code is moved away from the via-pmu.c driver
>  - both suspend-to-disk & to-ram consolidated to use the same
> infrastructure and code base in a new pmac_pm.c file
>  - significants fixes & improvements to suspend-to-disk
>  - for now (may change), use the "refrigerator" with suspend-to-ram as
> well as suspend-to-disk. This may help make it a bit more robust vs.
> userland activity during the sleep process
>  - CONFIG_PMAC_PBOOK is gone. CONFIG_PMAC_MEDIABAY is new and controls
> wether the powerbook hostwap bay driver is included. The rest of bits
> formerly under CONFIG_PMAC_PBOOK control are now either always on
> (like /dev/pmu interface on PMU based machines) or dependent on other
> config options (like CONFIG_PM, CONFIG_PPC_PMAC, ...)
> 
> The patch will not be in 2.6.12 (though will probably apply on top of
> it). I aim for a 2.6.13 release, knowing that the patch changes a bunch
> of non-ppc-specific power management bits, and thus may need some time
> to be fully merged upstream.
> 
> 
> 
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
> 

Re: [PATCH] ppc32: Rework power management take #3

[Benjamin Herrenschmidt]

On Thu, 2005-06-02 at 15:33 -0700, Geoff Levand wrote:
> I had a problem when building for ppc440 (gcc -m405).  I wonder if we 
> need some conditionals on the DSSALL statement as below, or is DSSALL 
> intended to be a perprocessor macro that would expand to a blank line
> in this case?

No, but the cpu feature bit will make the dssall be nop'ed out on your
CPU. I though we were passing -many to gas in all cases, don't we ?

Ben.

Re: [PATCH] ppc32: Rework power management take #3

[Geoff Levand]

Benjamin Herrenschmidt wrote:
> On Thu, 2005-06-02 at 15:33 -0700, Geoff Levand wrote:
> 
>>I had a problem when building for ppc440 (gcc -m405).  I wonder if we 
>>need some conditionals on the DSSALL statement as below, or is DSSALL 
>>intended to be a perprocessor macro that would expand to a blank line
>>in this case?
> 
> 
> No, but the cpu feature bit will make the dssall be nop'ed out on your
> CPU. I though we were passing -many to gas in all cases, don't we ?
> 

sorry...

egrep -r '\-Wa' arch/ppc
arch/ppc/boot/simple/Makefile:extra-aflags-$(CONFIG_REDWOOD_4)  := -Wa,-m405
arch/ppc/Makefile:cpu-as-$(CONFIG_PPC64BRIDGE)  += -Wa,-mppc64bridge
arch/ppc/Makefile:cpu-as-$(CONFIG_4xx)          += -Wa,-m405
arch/ppc/Makefile:cpu-as-$(CONFIG_6xx)          += -Wa,-maltivec
arch/ppc/Makefile:cpu-as-$(CONFIG_POWER4)               += -Wa,-maltivec
arch/ppc/Makefile:cpu-as-$(CONFIG_E500)         += -Wa,-me500

So I get an invalid instruction error.

-Geoff