On Wednesday 21 March 2007 9:42 pm, Len Brown wrote: > > > 2. The device dependence varies from different systems especially > > > for embedded system. The idea is dpm framework handles device > > > dependence (like, resume a deviceâ??s parent before resume the > > > device itself), The driver model PM framework **ALREADY DOES THAT** so nothing new is required ... > I'm skeptical about an additional framework in the kernel to track > dependencies, The clock framework and driver model tree already handle a big chunk of those dependencies. Of course, they're also not an "additional" framework (except maybe from the x86 perspective, where the clock framework isn't available). > as I don't think we should even try to track embedded system > dependencies in the kernel. That approach seems unlikely to work, unless one wants to make it even harder to use Linux on embedded systems. On the other hand, I'd hate to see a "dependency tracking API" rather than something focussed on solving specific problems. (Solve first, then maybe generalize later.) > This is the "intelligent device driver" model -- the driver actually has a clue > and can do the work internally. Probably we need some combination of this > plus the simple timeout/user-policy-manager for dumber drivers if we are to > cover the whole system. Yes, those two approaches should cover large chunks of the driver space. - Dave _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
