On 27 August 2014 09:37, Ulf Hansson <ulf.hansson@xxxxxxxxxx> wrote:
> On 27 August 2014 02:20, Rafael J. Wysocki <rjw@xxxxxxxxxxxxx> wrote:
>> On Tuesday, August 26, 2014 02:07:11 PM Ulf Hansson wrote:
>>> To maintain scalability let's add common methods to attach and detach
>>> a power domain for a device, dev_pm_domain_attach|detach().
>>>
>>> Typically dev_pm_domain_attach() shall be invoked from subsystem level
>>> code at the probe phase to try to attach a device to it's power domain.
>>> The reversed actions may be done a the remove phase and then by invoking
>>> dev_pm_domain_detach().
>>>
>>> The supported power domains at this point are the ACPI and the generic
>>> power domains.
>>>
>>> Signed-off-by: Ulf Hansson <ulf.hansson@xxxxxxxxxx>
>>> ---
>>> drivers/base/power/common.c | 58 +++++++++++++++++++++++++++++++++++++++++++++
>>> include/linux/pm.h | 14 +++++++++++
>>> 2 files changed, 72 insertions(+)
>>>
>>> diff --git a/drivers/base/power/common.c b/drivers/base/power/common.c
>>> index df2e5ee..f544128 100644
>>> --- a/drivers/base/power/common.c
>>> +++ b/drivers/base/power/common.c
>>> @@ -11,6 +11,8 @@
>>> #include <linux/export.h>
>>> #include <linux/slab.h>
>>> #include <linux/pm_clock.h>
>>> +#include <linux/acpi.h>
>>> +#include <linux/pm_domain.h>
>>>
>>> /**
>>> * dev_pm_get_subsys_data - Create or refcount power.subsys_data for device.
>>> @@ -82,3 +84,59 @@ int dev_pm_put_subsys_data(struct device *dev)
>>> return ret;
>>> }
>>> EXPORT_SYMBOL_GPL(dev_pm_put_subsys_data);
>>> +
>>> +/**
>>> + * dev_pm_domain_attach - Attach a device to it's power domain.
>>> + * @dev: Device to attach.
>>> + * @power_on: Used to indicate whether we should power on the device.
>>> + *
>>> + * The @dev may only be attached to a single power domain. By iterating through
>>> + * the available alternatives we try to find a valid domain for the device.
>>> + *
>>> + * This function should typically be invoked from subsystem level code during
>>> + * the probe phase. Especially for those that's hold devices which requires
>>> + * power management through power domains.
>>> + *
>>> + * Callers must ensure proper synchronization of this function with power
>>> + * management callbacks.
>>> + *
>>> + * Returns 0 on successfully attached power domain or negative error code.
>>> + */
>>> +int dev_pm_domain_attach(struct device *dev, bool power_on)
>>> +{
>>> + int ret;
>>> +
>>> + ret = acpi_dev_pm_attach(dev, power_on);
>>> + if (ret == -EPROBE_DEFER)
>>
>> This doesn't seem to be possible today. At least I'm not sure how it can
>> happen.
>
> You are right, but I did this intentionally. The reason for having
> this check, was that I didn't want the new API to put the limit on
> handling deferred probe.
>
> I happy the above check, if you think it's better!?
s/happy/happy to change
>
> Kind regards
> Uffe
>
>>
>>> + return ret;
>>> + else
>>> + ret = genpd_dev_pm_attach(dev);
>>> +
>>> + return ret;
>>> +}
>>> +EXPORT_SYMBOL_GPL(dev_pm_domain_attach);
>>
>> On a more general note, are you sure that the place where we call
>> acpi_dev_pm_attach() will always be suitable for calling genpd_dev_pm_attach()?
>>
>
> Currently, I haven't seen any place where it doesn't make sense.
>
> Additionally if such place is found, we may either just ignore it and
> let the caller of the API worry about the returned error or invoke the
> genpd/acpi API immediately instead.
>
>>> +
>>> +/**
>>> + * dev_pm_domain_detach - Detach a device from it's power domain.
>>> + * @dev: Device to attach.
>>> + * @power_off: Used to indicate whether we should power off the device.
>>> + *
>>> + * The @dev may be attached to a power domain. By iterating through the
>>> + * available alternatives we detach it from it's power domain.
>>> + *
>>> + * This functions will reverse the actions from dev_pm_domain_attach() and
>>> + * thus detach the @dev from it's power domain. Typically it should be invoked
>>> + * from subsystem level code during the remove phase.
>>> + *
>>> + * Callers must ensure proper synchronization of this function with power
>>> + * management callbacks.
>>> + *
>>> + * Returns 0 on successfully detached power domain or negative error code.
>>> + */
>>> +int dev_pm_domain_detach(struct device *dev, bool power_off)
>>> +{
>>> + if (acpi_dev_pm_detach(dev, power_off))
>>> + return genpd_dev_pm_detach(dev);
>>> + return 0;
>>> +}
>>> +EXPORT_SYMBOL_GPL(dev_pm_domain_detach);
>>> diff --git a/include/linux/pm.h b/include/linux/pm.h
>>> index 72c0fe0..8176b07 100644
>>> --- a/include/linux/pm.h
>>> +++ b/include/linux/pm.h
>>> @@ -621,6 +621,20 @@ struct dev_pm_domain {
>>> struct dev_pm_ops ops;
>>> };
>>>
>>> +#ifdef CONFIG_PM
>>> +extern int dev_pm_domain_attach(struct device *dev, bool power_on);
>>> +extern int dev_pm_domain_detach(struct device *dev, bool power_off);
>>> +#else
>>> +static inline int dev_pm_domain_attach(struct device *dev, bool power_on)
>>> +{
>>> + return -ENODEV;
>>> +}
>>> +static inline int dev_pm_domain_detach(struct device *dev, bool power_off)
>>> +{
>>> + return -ENODEV;
>>> +}
>>> +#endif
>>> +
>>> /*
>>> * The PM_EVENT_ messages are also used by drivers implementing the legacy
>>> * suspend framework, based on the ->suspend() and ->resume() callbacks common
>>>
>>
>> --
>> I speak only for myself.
>> Rafael J. Wysocki, Intel Open Source Technology Center.
--
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
