Re: [linux-pm] Re: [RFC] powermac: proper sleep management
Isn't it true that the freezer _already_ isn't enabled on PPC? So leaving it off wouldn't break anything more than it is broken now. Indeed. johannes signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC] powermac: proper sleep management
Looks good to me, +/- a couple of things: - We _REALLY_ want the freezer to be optional and not enabled by default on PowerPC. Maybe make it a compile option ? Well, Alan is going to tell you that USB will break. If we need confirmation for that I can do the test he suggested to you or Paul a while ago. - Don't remove the pmu_polled_request() debug code. It's very useful for debugging and I don't want to have to re-invent it. Heh, ok. Plus I also need to test it on some exotic hardware :-) Obviously. I don't have any of that. I'd appreciate if somebody could test on a 3400 powerbook to see if that pci config space save/restore stuff is really necessary or even interferes with the regular stuff. johannes signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [linux-pm] Re: [RFC] powermac: proper sleep management
On Mon, 12 Nov 2007, Johannes Berg wrote: Looks good to me, +/- a couple of things: - We _REALLY_ want the freezer to be optional and not enabled by default on PowerPC. Maybe make it a compile option ? Well, Alan is going to tell you that USB will break. If we need confirmation for that I can do the test he suggested to you or Paul a while ago. Isn't it true that the freezer _already_ isn't enabled on PPC? So leaving it off wouldn't break anything more than it is broken now. Alan Stern ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC] powermac: proper sleep management
On Mon, 2007-11-12 at 17:32 +0100, Johannes Berg wrote: Looks good to me, +/- a couple of things: - We _REALLY_ want the freezer to be optional and not enabled by default on PowerPC. Maybe make it a compile option ? Well, Alan is going to tell you that USB will break. If we need confirmation for that I can do the test he suggested to you or Paul a while ago. Then USB is broken today on powermacs and need to be fixed. We had a clear agreement at KS this year that the freezer was at best a band-aid and that drivers -had- to be fixed to cope regardless. Obviously. I don't have any of that. I'd appreciate if somebody could test on a 3400 powerbook to see if that pci config space save/restore stuff is really necessary or even interferes with the regular stuff. Might not be that necessary anymore nowadays, the generic code ought to do it, but I'll give a go, I have one of those (paulus old one) though last I tried, the HD was dead. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [linux-pm] Re: [RFC] powermac: proper sleep management
On Tue, 13 Nov 2007, Benjamin Herrenschmidt wrote: On Mon, 2007-11-12 at 17:32 +0100, Johannes Berg wrote: Looks good to me, +/- a couple of things: - We _REALLY_ want the freezer to be optional and not enabled by default on PowerPC. Maybe make it a compile option ? Well, Alan is going to tell you that USB will break. If we need confirmation for that I can do the test he suggested to you or Paul a while ago. Then USB is broken today on powermacs and need to be fixed. We had a clear agreement at KS this year that the freezer was at best a band-aid and that drivers -had- to be fixed to cope regardless. More accurately, freezing user tasks is at best a band-aid. However some kernel threads do need to be frozen, and keeping the freezer around for their use makes sense. It has less overhead -- I think -- than adding new code to do the freezing in each of these threads. (It's true that USB drivers in general aren't written to operate in a freezerless system-suspend environment. That's a harder problem and it will have to be fixed driver-by-driver, over time. The same may be true for lots of non-USB char device drivers as well. Pick your favorite char device driver: How will it behave if a user task submits an I/O request after the device has been suspended?) Alan Stern ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [linux-pm] Re: [RFC] powermac: proper sleep management
On Mon, 2007-11-12 at 15:40 -0500, Alan Stern wrote: On Tue, 13 Nov 2007, Benjamin Herrenschmidt wrote: On Mon, 2007-11-12 at 17:32 +0100, Johannes Berg wrote: Looks good to me, +/- a couple of things: - We _REALLY_ want the freezer to be optional and not enabled by default on PowerPC. Maybe make it a compile option ? Well, Alan is going to tell you that USB will break. If we need confirmation for that I can do the test he suggested to you or Paul a while ago. Then USB is broken today on powermacs and need to be fixed. We had a clear agreement at KS this year that the freezer was at best a band-aid and that drivers -had- to be fixed to cope regardless. More accurately, freezing user tasks is at best a band-aid. However some kernel threads do need to be frozen, and keeping the freezer around for their use makes sense. It has less overhead -- I think -- than adding new code to do the freezing in each of these threads. I remember fixing various issues so that khubd would be safe when non frozen (among other things) a while ago. Did you guys break it all again ? Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [linux-pm] Re: [RFC] powermac: proper sleep management
On Tue, 13 Nov 2007, Benjamin Herrenschmidt wrote: I remember fixing various issues so that khubd would be safe when non frozen (among other things) a while ago. Did you guys break it all again ? Sorry, I don't know what fixes you're referring to. But come to think of it, some changes I added to the PM core a few months ago (locking every device prior to system sleep) would also make khubd and ksuspend_usbd safe, since they acquire the device lock before trying to resume anything. So I take back what I said. It's no longer true that those two USB kernel threads need to be frozen for system sleep. (I should test and make sure that really works...) But aren't there other kernel threads scattered around that still want to be frozen? For instance, drivers/misc/tifm_core.c calls create_freezeable_workqueue(). And set_freezable() gets called in lots of places. Alan Stern ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC] powermac: proper sleep management
Just thought I'd send out the patch again, it has changed quite a bit since last time because I cleaned up the code, made it depend on CONFIG_SUSPEND, made the ioctl backward compatibility optional and some other bits. The feared freezer vs. fuse sync deadlock is no longer present in 2.6.24 because the sync is done before the freezer so maybe the patch stands a chance now. Scott: FYI, here's the use case for the ppc_md irq suspend/resume hooks. Looks good to me, +/- a couple of things: - We _REALLY_ want the freezer to be optional and not enabled by default on PowerPC. Maybe make it a compile option ? - Don't remove the pmu_polled_request() debug code. It's very useful for debugging and I don't want to have to re-invent it. Plus I also need to test it on some exotic hardware :-) Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC] powermac: proper sleep management
On Thu, 2007-11-08 at 13:15 -0600, Scott Wood wrote:
Johannes Berg wrote:
+/*
+ * overrides the weak arch_suspend_disable_irqs in kernel/power/main.c
+ *
+ * XXX: Once Scott Wood's patch is merged, this needs to use the ppc_md
+ * hooks that patch adds!
+ */
+void arch_suspend_disable_irqs(void)
+{
+#ifdef CONFIG_PMAC_BACKLIGHT
+ /* Tell backlight code not to muck around with the chip anymore */
+ pmu_backlight_set_sleep(1);
+#endif
+
+ /* Call platform functions marked on sleep */
+ pmac_pfunc_i2c_suspend();
+ pmac_pfunc_base_suspend();
Shouldn't these be done from suspend methods of the relevant drivers?
I don't understand why this needs to go in the disable IRQ hook.
The pmac_pfunc thing is low level platform stuff, no driver involved
there, this is the right place to do it.
As for the backlight bits, that could indeed be moved around I suppose,
I'd keep it there for now and look at cleaning the PMU driver
suspend/resume path in a second step.
Ben.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC] powermac: proper sleep management
Johannes Berg wrote:
+/*
+ * overrides the weak arch_suspend_disable_irqs in kernel/power/main.c
+ *
+ * XXX: Once Scott Wood's patch is merged, this needs to use the ppc_md
+ * hooks that patch adds!
+ */
+void arch_suspend_disable_irqs(void)
+{
+#ifdef CONFIG_PMAC_BACKLIGHT
+ /* Tell backlight code not to muck around with the chip anymore */
+ pmu_backlight_set_sleep(1);
+#endif
+
+ /* Call platform functions marked on sleep */
+ pmac_pfunc_i2c_suspend();
+ pmac_pfunc_base_suspend();
Shouldn't these be done from suspend methods of the relevant drivers?
I don't understand why this needs to go in the disable IRQ hook.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
