On Tuesday, December 14, 2010, Alan Stern wrote: > On Tue, 14 Dec 2010, Mark Brown wrote: > > > On Tue, Dec 14, 2010 at 12:44:24PM -0500, Alan Stern wrote: > > > On Tue, 14 Dec 2010, Mark Brown wrote: > > > > On Tue, Dec 14, 2010 at 11:16:45AM -0500, Alan Stern wrote: > > > > > > > I'm not familiar with the details of how the i2c subsystem works. But > > > > > in general, the subsystem code should call pm_runtime_set_active() > > > > > for every device before registering it. Then if a driver doesn't use > > > > > any runtime-PM functions, pm_runtime_suspended() will return false. > > > > > > Hrm, if that's the case then we also need to update at least the > > > > platform and SPI buses. Though looking at the documentation this is > > > > going to get a bit interesting as there's a requirement that the parent > > > > has runtime PM enabled on it... > > > > > The parent can either be set to the active state or set to ignore its > > > children. The parent does not have to be enabled for runtime PM. > > > > Both of those require that the parent is set up to know something about > > runtime PM to some extent - in the case of buses like I2C the parent is > > a largely unrelated thing on a different bus which may or may not have > > runtime PM implemented. > > > > > > It's certainly not terribly apparent > > > > from the documentation. > > > > > What part isn't clear from the documentation? I think the description > > > of pm_runtime_set_active() in Documentation/power/runtime_pm.txt is > > > pretty straightforward. > > > > It's not clear to me that one needs to do this in order to avoid > > breaking the suspend and resume calls of drivers that aren't doing > > anything with runtime PM. It's clear what it does, but it's less clear > > that the bus should do it or that not doing it will have an impact on > > stuff that isn't using runtime PM. > > > > > > It'd be really helpful if it were clearer what noop buses like this were > > > > supposed to do to get runtime PM working. > > > > > I'm a little confused. When you say this is a "noop" bus, do you mean > > > that it can't do any power management? If so, why does it need to get > > > runtime PM working? > > > > The bus as a whole may not be able to do anything useful with runtime PM > > but individual devices on it may be able to do so - for example, a multi > > function device provides a parent device and a bunch of children for > > that device. Runtime PM provides a nice way for the children to > > individually suspend themselves and let the parent implement extra power > > savings if all the children suspend. It also provides a userspace API > > for controlling runtime suspend behaviour which drivers may find useful, > > and stuff like the autosuspend delays might be useful to some. > > I see. It sounds like you're really saying that new devices default to > the wrong runtime state. If pm_runtime_init() would set new devices to > RPM_ACTIVE instead of RPM_SUSPENDED then this problem wouldn't arise. > Children could do whatever they want, and even if the parent's driver > was totally ignorant of runtime PM, it would work out. Actaully, pm_runtime_init() also sets power.disable_depth to 1, which disables runtime PM and (with the pm_runtime_suspended() change I proposed earlier) that should be sufficient, unless someone blindly calls pm_runtime_enable() for the device without changing its status as appropriate beforehand. That, however, is a bug in the code doing this IMnsHO. Thanks, Rafael _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
