On Thu, May 24, 2018 at 06:32:37AM -0700, Tony Lindgren wrote: > * Johan Hovold <johan@xxxxxxxxxx> [180524 09:20]: > > On Mon, May 21, 2018 at 08:48:32AM -0700, Tony Lindgren wrote: > > > Well if you have some better mechanism in mind let's try it out. Short of > > > sprinkling pm_runtime_force_suspend/resume calls all over, I'm out of ideas > > > right now. > > > > Yeah, that would be too much of a hack and likely wouldn't work either > > (and we really should do away with those _force calls altogether). > > > > I've been thinking a bit too much about this already, but it may be > > possible to use the pm QoS framework for this. A resume latency can be > > set through sysfs where "n/a" is defined to mean "no latency accepted" > > (i.e. controller remains always-on while port is open) and "0" means > > "any latency accepted" (i.e. omap aggressive serial RPM is allowed). > > Oh yeah, PM QoS might work here! Actually, after reading a recent QoS related bug report, I realised that a resume latency request of "n/a" is actually a third way of disabling runtime PM, which similarly to the negative autosuspend would prevent also a closed port from suspending. Using a small positive resume latency for this feels like too much of a hack, but defining a new QoS flag might still work. Johan -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
