On Tuesday, August 02, 2011, Kevin Hilman wrote: > "Rafael J. Wysocki" <rjw@xxxxxxx> writes: > > > Hi, > > > > On Thursday, June 30, 2011, jean.pihet@xxxxxxxxxxxxxx wrote: > >> From: Jean Pihet <j-pihet@xxxxxx> > >> > >> - add a new PM QoS class PM_QOS_DEV_WAKEUP_LATENCY for device wake-up > >> constraints. Due to the per-device nature of the new class the constraints > >> list is stored inside the device dev_pm_info struct instead of the internal > >> per-class constraints lists. > > > > I think PM_QOS_DEV_LATENCY might be a better name. > > > >> The new class is only available from kernel drivers and so is not exported > >> to user space. > > > > It should be available to user space, however, because in many cases drivers > > simply have no idea what values to use (after all, the use decides if he > > wants to trade worse video playback quality for better battery life, for > > example). > > > > FWIW, I think it's wrong to expose the raw per-device constraints > directly to userspace. > > I think it's the responsibility of the subsystems (video, audio, input, > etc.) to expose QoS knobs to userspace as they see fit and now allow > userspace to tinker directly with QoS constraints. This assumes that those "subsystems" or rather "frameworks" (a bus type or a device class is a subsystem in the terminology used throughout the PM documentation) will (a) know about PM QoS and (b) will care to handle it. Both (a) and (b) seem to be unrealistic IMHO. We already export wakeup and runtime PM knobs per device via sysfs and I'm not so sure why PM QoS is different in that respect. Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
