See, NOW it makes sense...

Right, it's absolutely true that the wakelock approach simplifies the userspace implementation,
but we could take a different view of things - at the most aggressive level, you could keep a
userspace wakelock implementation and use the uswsusp interface to fire off the process
freezer when all of them are released. All we'd need then would be a mechanism to provide a
list of PIDs that you don't want frozen.

The drivers side of thing is more interesting, and I think that's something that could potentially
be implemented using Rafael's runtime suspend work. As long as the dependencies are
expressed (and I admit that doing so is problematic right now), a busy driver can do a
pm_runtime_get() and then a pm_runtime_put() when it's idle again. Letting that information flow
up the tree could then allow the platform code to inhibit entry to the deeper states. TI seem to
do this in a more hacky way by simply using the systemwide busmastering flag, which cpuidle will
then use to limit idle to wfi-type states. It's not elegant, but it works.

The next linux pm summit is planned for Boston in August, which is kind of far away. There's the
collab summit in SF in April which isn't generally a highly technical conference but is co-hosted
with CELF this year. I suspect we could probably sort something out for that, if there's interest,
and it's the kind of thing that the Linux Foundation would probably love to make happen.