ppc32: Rework power management take #3

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).

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 [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
=20

Hi Ben

Quoted 2 lines

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

Quoted 12 lines · 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:

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,

Quoted 8 lines

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.

/dev/tty8) to create a new tty in the background.

Quoted 8 lines

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"

Quoted 1 line

/dev/tty8) to create a new tty in the background.

Does that trigger the freeze ?

Ben.

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

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
[email protected]
https://ozlabs.org/mailman/listinfo/linuxppc-dev

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?

Quoted 4 lines · 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?

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 ?