On Tue, 7 Jul 2015, Rafael J. Wysocki wrote: > > > All right, we can make a decision and document it. The following seems > > > reasonable to me: > > > > > > If dev->power.direct_complete is set then the PM core will > > > assume that dev->power.rpm_status is accurate even when > > > dev->power.disable_depth > 0. The core will obey the > > > .direct_complete setting regardless of .disable_depth. > > > > > > As a consequence, devices that support system sleep but don't > > > support runtime PM must _never_ have .direct_complete set. > > > > > > On the other hand, if a device (such as a "virtual" device) > > > requires no callbacks for either system sleep or runtime PM, > > > then there is no harm in setting .direct_complete. Indeed, > > > doing so may help speed up an ancestor device's sleep > > > transition. > > > > > > How does that sound? > > > > It would be workable I think, but I'd prefer the core to be told directly > > about devices whose runtime PM status doesn't matter (because nothing > > changes > > between "suspended" and "active"), so they may be treated in a special way > > safely. > > > > If we had that information, no special rules other than "that is a device > > whose runtime PM status doesn't matter, so treat it accordingly" would be > > necessary. > > That said, a situation to consider is when device X is just a software device, > but it has children that correspond to physical hardware. If that is the > case, > the usual parent-children rules should apply to X and its children (ie. X > should > only be marked as "suspended" if all of its children are suspended) and I see > no reason why the parent-children rules for direct_resume should not apply > here.
Yes, this illustrates that in some ways we must not treat "virtual" or "software" devices specially. Being "virtual" is not the same as having the ignore_children flag set. The change I'm proposing is not related to whether a device is "virtual". I'm just suggesting that the normal direct_complete rules should apply even when devices are runtime-PM-disabled. This doesn't mean that their runtime PM status doesn't matter. Just the opposite, in fact -- it means that the PM core should pay attention to the runtime PM status during a sleep transition even though disabled_depth > 0. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
