ACPI: implement acpi_os_get_timer() according the spec

ACPI Timer() opcode should return monotonically increasing clock with 100ns
granularity according the ACPI 5.0 spec.

Testing the current Timer() implementation with following ASL code (and an
additional debug print in acpi_os_sleep() to get the sleep times dumped out
to dmesg):

	// Test: 10ms
	Store(Timer, Local1)
	Sleep(10)
	Divide(Subtract(Timer, Local1), 10000,, Local1)
	Sleep(Local1)

	// Test: 200ms
	Store(Timer, Local1)
	Sleep(200)
	Divide(Subtract(Timer, Local1), 10000,, Local1)
	Sleep(Local1)

	// Test 1300ms
	Store(Timer, Local1)
	Sleep(1300)
	Divide(Subtract(Timer, Local1), 10000,, Local1)
	Sleep(Local1)

The second sleep value is calculated using Timer(). If the implementation
is good enough we should be able to get the second value pretty close to
the first.

However, the current Timer() gives pretty bad sleep times:

	[   11.488100] ACPI: acpi_os_get_timer() TBD
	[   11.492150] ACPI: Sleep(10)
	[   11.502993] ACPI: Sleep(0)
	[   11.506315] ACPI: Sleep(200)
	[   11.706237] ACPI: Sleep(0)
	[   11.709550] ACPI: Sleep(1300)
	[   13.008929] ACPI: Sleep(0)

Fix this with the help of ktime_get(). Once the fix is applied and run
against the same ASL code we get:

	[   11.486786] ACPI: Sleep(10)
	[   11.499029] ACPI: Sleep(12)
	[   11.512350] ACPI: Sleep(200)
	[   11.712282] ACPI: Sleep(200)
	[   11.912170] ACPI: Sleep(1300)
	[   13.211577] ACPI: Sleep(1300)

That is much more closer to the values we expected.

Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
cpufreq: make sure frequency transitions are serialized

Whenever we are changing frequency of a cpu, we are calling PRECHANGE and
POSTCHANGE notifiers. They must be serialized. i.e. PRECHANGE or POSTCHANGE
shouldn't be called twice contiguously.

This can happen due to bugs in users of __cpufreq_driver_target() or actual
cpufreq drivers who are sending these notifiers.

This patch adds some protection against this. Now, we keep track of the last
transaction and see if something went wrong.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
acpi-cpufreq: Add new sysfs attribute freqdomain_cpus

Commits fcf8058 (cpufreq: Simplify cpufreq_add_dev()) and aa77a52
(cpufreq: acpi-cpufreq: Don't set policy->related_cpus from .init())
changed the contents of the "related_cpus" sysfs attribute on systems
where acpi-cpufreq is used and user space can't get the list of CPUs
which are in the same hardware coordination CPU domain (provided by
the ACPI AML method _PSD) via "related_cpus" any more.

To make up for that loss add a new sysfs attribute "freqdomian_cpus"
for the acpi-cpufreq driver which exposes the list of CPUs in the
same domain regardless of whether it is coordinated by hardware or
software.

[rjw: Changelog, documentation]
References: https://bugzilla.kernel.org/show_bug.cgi?id=58761
Reported-by: Jean-Philippe Halimi <jean-philippe.halimi@exascale-computing.eu>
Signed-off-by: Lan Tianyu <tianyu.lan@intel.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Merge branch 'pm-fixes' into pm-cpufreq

A subsequent commit depends on the 'pm-fixes' commits.
cpufreq: don't leave stale policy pointer in cdbs->cur_policy

Clear ->cur_policy when stopping a governor, or the ->cur_policy
pointer may be stale on systems with have_governor_per_policy when a
new policy is allocated due to CPU hotplug offline/online.

[rjw: Changelog]
Suggested-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Jacob Shin <jacob.shin@amd.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Merge branch 'acpi-pm-next' into bleeding-edge

* acpi-pm-next:
  ACPI / PM: Fix possible NULL pointer deref in acpi_pm_device_sleep_state()
Merge branch 'acpi-assorted-next' into bleeding-edge

* acpi-assorted-next:
  ACPI: implement acpi_os_get_timer() according the spec
Merge branch 'pm-assorted-next' into bleeding-edge

* pm-assorted-next:
  PM / Sleep: Warn about system time after resume with pm_trace
Merge branch 'pm-cpufreq-next' into bleeding-edge

* pm-cpufreq-next:
  cpufreq: don't leave stale policy pointer in cdbs->cur_policy
  acpi-cpufreq: Add new sysfs attribute freqdomain_cpus
  cpufreq: make sure frequency transitions are serialized