Messages in this thread | | | Date | Tue, 10 Aug 2004 19:56:37 +0200 | From | Pavel Machek <> | Subject | Re: [RFC] Fix Device Power Management States |
| |
HI!
> > Can you explain why this class-based quiescing is good idea? It seems > > to me that "quiesce this tree" is pretty much same as "suspend this > > tree", and can be handled in the same way. > > > > Nigel wanted to do class-based quiescing, but if we make quiescing > > fast enough, it should be okay to do whole tree, always. (And I > > believe quiescing *can* be fast enough). > > It has nothing to do with speed and everything to do with domains of > responsibility. Each device belongs to 1 device class. That class and the > assoicated class device represent the functional interface(s) to the > physical device. While the physical device controls physical attributes, > like actual I/O and power states, the class controls the logical > interface.
I still do not see it... swsusp does not care about logical state of device. (Actually manipulating logical state of device might make swsusp less transparent). It cares about device not doing DMA (I also said "no interrupts", but that is not strictly neccessary: we disable interrupts for atomic copy. Device should do no NMIs, through).
Pavel -- People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |