PM / QoS: Prepare device structure for adding more constraint types

Currently struct dev_pm_info contains only one PM QoS constraints
pointer reserved for latency requirements.  Since one more device
constraints type (i.e. flags) will be necessary, introduce a new
structure, struct dev_pm_qos, that eventually will contain all of
the available device PM QoS constraints and replace the "constraints"
pointer in struct dev_pm_info with a pointer to the new structure
called "qos".

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Jean Pihet <j-pihet@ti.com>
PM / QoS: Introduce request and constraint data types for PM QoS flags

Introduce struct pm_qos_flags_request and struct pm_qos_flags
representing PM QoS flags request type and PM QoS flags constraint
type, respectively.  With these definitions the data structures
will be arranged so that the list member of a struct pm_qos_flags
object will contain the head of a list of struct pm_qos_flags_request
objects representing all of the "flags" requests present for the
given device.  Then, the effective_flags member of a struct
pm_qos_flags object will contain the bitwise OR of the flags members
of all the struct pm_qos_flags_request objects in the list.

Additionally, introduce helper function pm_qos_update_flags()
allowing the caller to manage the list of struct pm_qos_flags_request
pointed to by the list member of struct pm_qos_flags.

The flags are of type s32 so that the request's "value" field
is always of the same type regardless of what kind of request it
is (latency requests already have value fields of type s32).

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Jean Pihet <j-pihet@ti.com>
Acked-by: mark gross <markgross@thegnar.org>
PM / QoS: Prepare struct dev_pm_qos_request for more request types

The subsequent patches will use struct dev_pm_qos_request for
representing both latency requests and flags requests.  To make that
easier, put the node member of struct dev_pm_qos_request (under the
name "pnode") into a union called "data" that will represent the
request's  value and list node depending on its type.

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Jean Pihet <j-pihet@ti.com>
Reviewed-by: mark gross <markgross@thegnar.org>
PM / QoS: Introduce PM QoS device flags support

Modify the device PM QoS core code to support PM QoS flags requests.

First, add a new field of type struct pm_qos_flags called "flags"
to struct dev_pm_qos for representing the list of PM QoS flags
requests for the given device.  Accordingly, add a new "type" field
to struct dev_pm_qos_request (along with an enum for representing
request types) and a new member called "flr" to its data union for
representig flags requests.

Second, modify dev_pm_qos_add_request(), dev_pm_qos_update_request(),
the internal routine apply_constraint() used by them and their
existing callers to cover flags requests as well as latency
requests.  In particular, dev_pm_qos_add_request() gets a new
argument called "type" for specifying the type of a request to be
added.

Finally, introduce two routines, __dev_pm_qos_flags() and
dev_pm_qos_flags(), allowing their callers to check which PM QoS
flags have been requested for the given device (the caller is
supposed to pass the mask of flags to check as the routine's
second argument and examine its return value for the result).

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Jean Pihet <j-pihet@ti.com>
Reviewed-by: mark gross <markgross@thegnar.org>
PM / QoS: Make it possible to expose PM QoS device flags to user space

Define two device PM QoS flags, PM_QOS_FLAG_NO_POWER_OFF
and PM_QOS_FLAG_REMOTE_WAKEUP, and introduce routines
dev_pm_qos_expose_flags() and dev_pm_qos_hide_flags() allowing the
caller to expose those two flags to user space or to hide them
from it, respectively.

After the flags have been exposed, user space will see two
additional sysfs attributes, pm_qos_no_power_off and
pm_qos_remote_wakeup, under the device's /sys/devices/.../power/
directory.  Then, writing 1 to one of them will update the
PM QoS flags request owned by user space so that the corresponding
flag is requested to be set.  In turn, writing 0 to one of them
will cause the corresponding flag in the user space's request to
be cleared (however, the owners of the other PM QoS flags requests
for the same device may still request the flag to be set and it
may be effectively set even if user space doesn't request that).

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Jean Pihet <j-pihet@ti.com>
Acked-by: mark gross <markgross@thegnar.org>
PM / Domains: Check device PM QoS flags in pm_genpd_poweroff()

Make the generic PM domains pm_genpd_poweroff() function take
device PM QoS flags into account when deciding whether or not to
remove power from the domain.

After this change the routine will return -EBUSY without executing
the domain's .power_off() callback if there is at least one PM QoS
flags request for at least one device in the domain and at least of
those request has at least one of the NO_POWER_OFF and REMOTE_WAKEUP
flags set.

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Jean Pihet <j-pihet@ti.com>
Reviewed-by: mark gross <markgross@thegnar.org>
PM / ACPI: Take device PM QoS flags into account

Make ACPI power management routines and PCI power management
routines depending on ACPI take device PM QoS flags into account
when deciding what power state to put the device into.

In particular, after this change acpi_pm_device_sleep_state() will
not return ACPI_STATE_D3_COLD as the deepest available low-power
state if PM_QOS_FLAG_NO_POWER_OFF is requested for the device and it
will not require remote wakeup to work for the device in the returned
low-power state if there is at least one PM QoS flags request for the
device, but PM_QOS_FLAG_REMOTE_WAKEUP is not requested for it.

Accordingly, acpi_pci_set_power_state() will refuse to put the
device into D3cold if PM_QOS_FLAG_NO_POWER_OFF is requested for it.

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Jean Pihet <j-pihet@ti.com>
Reviewed-by: Huang Ying <ying.huang@intel.com>