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. Alan Stern _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
