Re: [PATCH] ppc32: Rework power management take #3
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.0 -0700 +++ linux-2.6.12-bhpm/arch/ppc/kernel/swsusp.S 2005-06-02 15:29:56.0 -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 > [EMAIL PROTECTED] > https://ozlabs.org/mailman/listinfo/linuxppc-dev > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [PATCH] ppc32: Rework power management take #3
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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
