From: Alan Stern on
On Thu, 21 Jan 2010, Rafael J. Wysocki wrote:

> From: Rafael J. Wysocki <rjw(a)sisk.pl>
>
> Add new device sysfs attribute, power/control, allowing the user
> space to block the run-time power management of devices. If this
> attribute is set to "on", the driver of the device won't be able to power
> manage it at run time (without breaking the rules) and the device will
> always be in the full power state (except when the entire system goes
> into a sleep state).

....

> --- linux-2.6.orig/drivers/base/power/power.h
> +++ linux-2.6/drivers/base/power/power.h
> @@ -2,11 +2,15 @@
>
> extern void pm_runtime_init(struct device *dev);
> extern void pm_runtime_remove(struct device *dev);
> +extern void pm_runtime_allow(struct device *dev);
> +extern void pm_runtime_forbid(struct device *dev);

Can you write a follow-up patch that moves these declarations to a
public header file like include/linux/pm_runtime.h and EXPORTs the two
new routines? It is sometimes useful for drivers to be able to call
the routines directly.

For example, we disable runtime PM for most USB devices by default.
But a few drivers may know that their devices are able to handle it, so
they want to change the default setting when they are bound.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Alan Stern on
On Fri, 22 Jan 2010, Rafael J. Wysocki wrote:

> > For example, we disable runtime PM for most USB devices by default.
> > But a few drivers may know that their devices are able to handle it, so
> > they want to change the default setting when they are bound.
>
> Runtime PM is disabled for all devices by default unless the driver enables
> it. The setting in power/control is to override the driver's choice, so that
> it can be disabled even if the driver tries to enable it.
>
> IOW, the user space is the owner of the power.runtime_auto flag and I don't
> think we should allow drivers to modify it.

Okay, I understand your point of view. It means I'll have to make some
changes to the USB code. No problem.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Alan Stern on
On Fri, 22 Jan 2010, Rafael J. Wysocki wrote:

> > For example, we disable runtime PM for most USB devices by default.
> > But a few drivers may know that their devices are able to handle it, so
> > they want to change the default setting when they are bound.
>
> Runtime PM is disabled for all devices by default unless the driver enables
> it. The setting in power/control is to override the driver's choice, so that
> it can be disabled even if the driver tries to enable it.
>
> IOW, the user space is the owner of the power.runtime_auto flag and I don't
> think we should allow drivers to modify it.

After more thought, I changed my mind about this. The ability to
override the driver's choice means that the user should be able to
enable runtime PM even if the driver tries to disable it, as well as
the other way 'round.

In other words, it's not productive to say the user is the owner of the
runtime_auto flag. What we _really_ want is to put the user in charge
of whether or not a device is subject to runtime PM.

First of all, note that if the driver doesn't support runtime PM then
it makes no difference what value runtime_auto has. The issue is moot.

So suppose the driver does support runtime PM. In this case, it's
irrelevant that runtime PM starts out disabled by default when the
device structure is initialized. The bus subsystem and driver will
reinitialize the settings in the way they think best.

But if the driver decides to disable runtime PM and pm_runtime_forbid()
isn't EXPORTed, then the driver will be forced to implement its
decision by leaving disable_depth > 0 -- which means there's nothing
the user can do. The power/control attribute won't help. On the other
hand, if the driver decides to disable runtime PM and it can do so by
calling pm_runtime_forbid(), then the user can override the decision.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Alan Stern on
On Sat, 23 Jan 2010, Rafael J. Wysocki wrote:

> Hmm, OK.
>
> Of course, if the driver decides to leave disable_depth > 0, the user still
> won't be able to do anything about that, but if I understand correctly, you
> want drivers to have the option to use pm_runtime_forbid() initially, right
> after pm_runtime_enable(), so that the user space can turn the runtime PM
> on if desired via sysfs.
>
> That makes sense. I have a usage case for that myself. :-)
>
> Updated patch is appended.

It looks good.

Acked-by: Alan Stern <stern(a)rowland.harvard.edu>

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Jesse Barnes on


"Rafael J. Wysocki" <rjw(a)sisk.pl> wrote:

>On Saturday 23 January 2010, Alan Stern wrote:
>> On Sat, 23 Jan 2010, Rafael J. Wysocki wrote:
>>
>> > Hmm, OK.
>> >
>> > Of course, if the driver decides to leave disable_depth > 0, the user still
>> > won't be able to do anything about that, but if I understand correctly, you
>> > want drivers to have the option to use pm_runtime_forbid() initially, right
>> > after pm_runtime_enable(), so that the user space can turn the runtime PM
>> > on if desired via sysfs.
>> >
>> > That makes sense. I have a usage case for that myself. :-)
>> >
>> > Updated patch is appended.
>>
>> It looks good.
>>
>> Acked-by: Alan Stern <stern(a)rowland.harvard.edu>
>
>Thanks!
>
>Rafael
>