> > autosuspend. It's not supposed to work by the higher level announcing: > > "I want to autosuspend now, so all you lower guys had better get > > ready." > > I see. And there's an appealing simplicity to it. But why insist that > this is the one true way? I was unaware there was another definition of autosuspend; that's how we've always discussed it. It's a bottom-up power management strategy leveraging localized knowledge that isn't knowable by other modules. (Maintainable systems use information hiding/separation all over...) It's a software version of what some smarter hardware does automatically. by automatically gating chunks of the clock tree when they're not needed, leaving the chip in a "retention" mode, to minimize active wastage. Doing that consistently over a whole OS can lead to significant power savings not just by shrinking per-module power consumption, but also by letting various PLLs and oscillators be powered off. Software can of course know about more power-relevant resources than just clocks ... If someone else has directed a module to suspend, it's hardly "automatic" from the perspective of that module. It'd have to decide what to do with activities that the "higher level" code wouldn't have known about. After all, the reason those layers exist is to hide information like that! - Dave - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
