When enabling KASAN and DEBUG_TEST_DRIVER_REMOVE, I find this KASAN
warning:

[   20.872057] BUG: KASAN: use-after-free in pcc_data_alloc+0x40/0xb8
[   20.878226] Read of size 4 at addr ffff00236cdeb684 by task swapper/0/1
[   20.884826]
[   20.886309] CPU: 19 PID: 1 Comm: swapper/0 Not tainted 5.4.0-rc1-00009-ge7f7df3db5bf-dirty #289
[   20.894994] Hardware name: Huawei D06 /D06, BIOS Hisilicon D06 UEFI RC0 - V1.16.01 03/15/2019
[   20.903505] Call trace:
[   20.905942]  dump_backtrace+0x0/0x200
[   20.909593]  show_stack+0x14/0x20
[   20.912899]  dump_stack+0xd4/0x130
[   20.916291]  print_address_description.isra.9+0x6c/0x3b8
[   20.921592]  __kasan_report+0x12c/0x23c
[   20.925417]  kasan_report+0xc/0x18
[   20.928808]  __asan_load4+0x94/0xb8
[   20.932286]  pcc_data_alloc+0x40/0xb8
[   20.935938]  acpi_cppc_processor_probe+0x4e8/0xb08
[   20.940717]  __acpi_processor_start+0x48/0xb0
[   20.945062]  acpi_processor_start+0x40/0x60
[   20.949235]  really_probe+0x118/0x548
[   20.952887]  driver_probe_device+0x7c/0x148
[   20.957059]  device_driver_attach+0x94/0xa0
[   20.961231]  __driver_attach+0xa4/0x110
[   20.965055]  bus_for_each_dev+0xe8/0x158
[   20.968966]  driver_attach+0x30/0x40
[   20.972531]  bus_add_driver+0x234/0x2f0
[   20.976356]  driver_register+0xbc/0x1d0
[   20.980182]  acpi_processor_driver_init+0x40/0xe4
[   20.984875]  do_one_initcall+0xb4/0x254
[   20.988700]  kernel_init_freeable+0x24c/0x2f8
[   20.993047]  kernel_init+0x10/0x118
[   20.996524]  ret_from_fork+0x10/0x18
[   21.000087]
[   21.001567] Allocated by task 1:
[   21.004785]  save_stack+0x28/0xc8
[   21.008089]  __kasan_kmalloc.isra.9+0xbc/0xd8
[   21.012435]  kasan_kmalloc+0xc/0x18
[   21.015913]  pcc_data_alloc+0x94/0xb8
[   21.019564]  acpi_cppc_processor_probe+0x4e8/0xb08
[   21.024343]  __acpi_processor_start+0x48/0xb0
[   21.028689]  acpi_processor_start+0x40/0x60
[   21.032860]  really_probe+0x118/0x548
[   21.036512]  driver_probe_device+0x7c/0x148
[   21.040684]  device_driver_attach+0x94/0xa0
[   21.044855]  __driver_attach+0xa4/0x110
[   21.048680]  bus_for_each_dev+0xe8/0x158
[   21.052591]  driver_attach+0x30/0x40
[   21.056155]  bus_add_driver+0x234/0x2f0
[   21.059980]  driver_register+0xbc/0x1d0
[   21.063805]  acpi_processor_driver_init+0x40/0xe4
[   21.068497]  do_one_initcall+0xb4/0x254
[   21.072322]  kernel_init_freeable+0x24c/0x2f8
[   21.076667]  kernel_init+0x10/0x118
[   21.080144]  ret_from_fork+0x10/0x18
[   21.083707]
[   21.085186] Freed by task 1:
[   21.088056]  save_stack+0x28/0xc8
[   21.091360]  __kasan_slab_free+0x118/0x180
[   21.095445]  kasan_slab_free+0x10/0x18
[   21.099183]  kfree+0x80/0x268
[   21.102139]  acpi_cppc_processor_exit+0x1a8/0x1b8
[   21.106832]  acpi_processor_stop+0x70/0x80
[   21.110917]  really_probe+0x174/0x548
[   21.114568]  driver_probe_device+0x7c/0x148
[   21.118740]  device_driver_attach+0x94/0xa0
[   21.122912]  __driver_attach+0xa4/0x110
[   21.126736]  bus_for_each_dev+0xe8/0x158
[   21.130648]  driver_attach+0x30/0x40
[   21.134212]  bus_add_driver+0x234/0x2f0
[   21.0x10/0x18
[   21.161764]
[   21.163244] The buggy address belongs to the object at ffff00236cdeb600
[   21.163244]  which belongs to the cache kmalloc-256 of size 256
[   21.175750] The buggy address is located 132 bytes inside of
[   21.175750]  256-byte region [ffff00236cdeb600, ffff00236cdeb700)
[   21.187473] The buggy address belongs to the page:
[   21.192254] page:fffffe008d937a00 refcount:1 mapcount:0 mapping:ffff002370c0fa00 index:0x0 compound_mapcount: 0
[   21.202331] flags: 0x1ffff00000010200(slab|head)
[   21.206940] raw: 1ffff00000010200 dead000000000100 dead000000000122 ffff002370c0fa00
[   21.214671] raw: 0000000000000000 00000000802a002a 00000001ffffffff 0000000000000000
[   21.222400] page dumped because: kasan: bad access detected
[   21.227959]
[   21.229438] Memory state around the buggy address:
[   21.234218]  ffff00236cdeb580: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[   21.241427]  ffff00236cdeb600: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[   21.248637] >ffff00236cdeb680: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[   21.255845]                    ^
[   21.259062]  ffff00236cdeb700: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[   21.266272]  ffff00236cdeb780: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[   21.273480] ==================================================================

It seems that global pcc_data[pcc_ss_id] can be freed in
acpi_cppc_processor_exit(), but we may later reference this value, so
NULLify it when freed.

Also remove the useless setting of data "pcc_channel_acquired", which
we're about to free.

Fixes: 85b1407b ("ACPI / CPPC: Make CPPC ACPI driver aware of PCC subspace IDs")
Signed-off-by: NJohn Garry <john.garry@huawei.com>
Cc: 4.15+ <stable@vger.kernel.org> # 4.15+
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

According to the ACPI 6.3 specification, the _PSD method is optional
when using CPPC.  The underlying assumption is that each CPU can change
frequency independently from all other CPUs; _PSD is provided to tell
the OS that some processors can NOT do that.

However, the acpi_get_psd() function returns ENODEV if there is no _PSD
method present, or an ACPI error status if an error occurs when evaluating
_PSD, if present.  This makes _PSD mandatory when using CPPC, in violation
of the specification, and only on Linux.

This has forced some firmware writers to provide a dummy _PSD, even though
it is irrelevant, but only because Linux requires it; other OSPMs follow
the spec.  We really do not want to have OS specific ACPI tables, though.

So, correct acpi_get_psd() so that it does not return an error if there
is no _PSD method present, but does return a failure when the method can
not be executed properly.  This allows _PSD to be optional as it should
be.
Signed-off-by: NAl Stone <ahs3@redhat.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Based on 1 normalized pattern(s):

  this program is free software you can redistribute it and or modify
  it under the terms of the gnu general public license as published by
  the free software foundation version 2 of the license

extracted by the scancode license scanner the SPDX license identifier

  GPL-2.0-only

has been chosen to replace the boilerplate/reference in 315 file(s).
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Reviewed-by: NAllison Randal <allison@lohutok.net>
Reviewed-by: NArmijn Hemel <armijn@tjaldur.nl>
Cc: linux-spdx@vger.kernel.org
Link: https://lkml.kernel.org/r/20190531190115.503150771@linutronix.deSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Fix some misspellings in comments.  No functional change intended.
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

As per the ACPI specification, "Guaranteed Performance Register" is
a "Buffer" field and it cannot be "Integer", so treat the "Integer"
type for "Guaranteed Performance Register" field as invalid and
ignore its value in that case.

Also save one cpc_read() call when "Guaranteed Performance Register"
is not present, which means a register defined as:
"Register(SystemMemory, 0, 0, 0, 0)".

Fixes: 29523f09 ("ACPI / CPPC: Add support for guaranteed performance")
Suggested-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: NSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Cc: 4.20+ <stable@vger.kernel.org> # 4.20+
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

This patch add a helper to get the value of desired performance
register.
Signed-off-by: NXiongfeng Wang <wangxiongfeng2@huawei.com>
[ rjw: More white space ]
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

The Continuous Performance Control package may contain an optional
guaranteed performance field.

Add support to read guaranteed performance from _CPC.
Signed-off-by: NSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Replace the faulty PCC status register polling code with a iopoll.h
macro to fix incorrect reporting of PCC check errors ("PCC check
channel failed").

There were potential codepaths where we could incorrectly return
PCC channel status as busy even without checking the PCC status
register once or not checking the status register before breaking
out of the polling loop. For example, if the thread polling PCC
status register was preempted and scheduled back after we have
crossed the deadline then we can report that the channel is busy
even without checking the status register.
Signed-off-by: NPrashanth Prakash <pprakash@codeaurora.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Changes the behavior where we return error if there are no valid PCC
subspace for a given performance domain.

The ACPI spec does not mandate the use PCC, so it is possible to have
platforms where a PCC subspace may not be present, so we need to check
for a valid PCC subspace ID only if the register is a PCC register.
Signed-off-by: NPrashanth Prakash <pprakash@codeaurora.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

CPPC V3 introduces two new entries to make it easier to convert between
abstract processor performance and frequency. The two new entries are
lowest frequency and nominal frequency. These are the frequencies
corresponding to lowest and nominal abstract performance.

Add support to read the new entries and populate them as part of the
CPPC performance capabilities which can be used by cpufreq drivers
Signed-off-by: NPrashanth Prakash <pprakash@codeaurora.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

CPPC dirver is aware of multiple PCC subspace IDs. Enhance the debug
and error messages in the driver to print the subspace id. In case of
error it will be helpful to find which particular subspace is failing.
Signed-off-by: NGeorge Cherian <george.cherian@cavium.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Add suffix ULL to constant 500 in order to give the compiler complete
information about the proper arithmetic to use. Notice that this
constant is used in a context that expects an expression of type
u64 (64 bits, unsigned).

The expression NUM_RETRIES * cppc_ss->latency at line 578, which at
preprocessing time translates to 500 * cppc_ss->latency is currently
being evaluated using 32-bit arithmetic.
Signed-off-by: NGustavo A. R. Silva <gustavo@embeddedor.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

The initialization of pcc_ss_data from pcc_data[pcc_ss_id] before
pcc_ss_id is being range checked could lead to an out-of-bounds array
read.  This very same initialization is also being performed after
the range check on pcc_ss_id, so we can just remove this problematic
and also redundant assignment to fix the issue.

Detected by cppcheck:
warning: Value stored to 'pcc_ss_data' during its initialization is never
read

Fixes: 85b1407b (ACPI / CPPC: Make CPPC ACPI driver aware of PCC subspace IDs)
Signed-off-by: NColin Ian King <colin.king@canonical.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Default value of pcc_subspace_idx is -1.
Make sure to check pcc_subspace_idx before using the same as array index.
This will avoid following KASAN warnings too.

[   15.113449] ==================================================================
[   15.116983] BUG: KASAN: global-out-of-bounds in cppc_get_perf_caps+0xf3/0x3b0
[   15.116983] Read of size 8 at addr ffffffffb9a5c0d8 by task swapper/0/1
[   15.116983] CPU: 3 PID: 1 Comm: swapper/0 Not tainted 4.15.0-rc2+ #2
[   15.116983] Hardware name: Dell Inc. OptiPlex 7040/0Y7WYT, BIOS 1.2.8 01/26/2016
[   15.116983] Call Trace:
[   15.116983]  dump_stack+0x7c/0xbb
[   15.116983]  print_address_description+0x1df/0x290
[   15.116983]  kasan_report+0x28a/0x370
[   15.116983]  ? cppc_get_perf_caps+0xf3/0x3b0
[   15.116983]  cppc_get_perf_caps+0xf3/0x3b0
[   15.116983]  ? cpc_read+0x210/0x210
[   15.116983]  ? __rdmsr_on_cpu+0x90/0x90
[   15.116983]  ? rdmsrl_on_cpu+0xa9/0xe0
[   15.116983]  ? rdmsr_on_cpu+0x100/0x100
[   15.116983]  ? wrmsrl_on_cpu+0x9c/0xd0
[   15.116983]  ? wrmsrl_on_cpu+0x9c/0xd0
[   15.116983]  ? wrmsr_on_cpu+0xe0/0xe0
[   15.116983]  __intel_pstate_cpu_init.part.16+0x3a2/0x530
[   15.116983]  ? intel_pstate_init_cpu+0x197/0x390
[   15.116983]  ? show_no_turbo+0xe0/0xe0
[   15.116983]  ? __lockdep_init_map+0xa0/0x290
[   15.116983]  intel_pstate_cpu_init+0x30/0x60
[   15.116983]  cpufreq_online+0x155/0xac0
[   15.116983]  cpufreq_add_dev+0x9b/0xb0
[   15.116983]  subsys_interface_register+0x1ae/0x290
[   15.116983]  ? bus_unregister_notifier+0x40/0x40
[   15.116983]  ? mark_held_locks+0x83/0xb0
[   15.116983]  ? _raw_write_unlock_irqrestore+0x32/0x60
[   15.116983]  ? intel_pstate_setup+0xc/0x104
[   15.116983]  ? intel_pstate_setup+0xc/0x104
[   15.116983]  ? cpufreq_register_driver+0x1ce/0x2b0
[   15.116983]  cpufreq_register_driver+0x1ce/0x2b0
[   15.116983]  ? intel_pstate_setup+0x104/0x104
[   15.116983]  intel_pstate_register_driver+0x3a/0xa0
[   15.116983]  intel_pstate_init+0x3c4/0x434
[   15.116983]  ? intel_pstate_setup+0x104/0x104
[   15.116983]  ? intel_pstate_setup+0x104/0x104
[   15.116983]  do_one_initcall+0x9c/0x206
[   15.116983]  ? parameq+0xa0/0xa0
[   15.116983]  ? initcall_blacklisted+0x150/0x150
[   15.116983]  ? lock_downgrade+0x2c0/0x2c0
[   15.116983]  kernel_init_freeable+0x327/0x3f0
[   15.116983]  ? start_kernel+0x612/0x612
[   15.116983]  ? _raw_spin_unlock_irq+0x29/0x40
[   15.116983]  ? finish_task_switch+0xdd/0x320
[   15.116983]  ? finish_task_switch+0x8e/0x320
[   15.116983]  ? rest_init+0xd0/0xd0
[   15.116983]  kernel_init+0xf/0x11a
[   15.116983]  ? rest_init+0xd0/0xd0
[   15.116983]  ret_from_fork+0x24/0x30

[   15.116983] The buggy address belongs to the variable:
[   15.116983]  __key.36299+0x38/0x40

[   15.116983] Memory state around the buggy address:
[   15.116983]  ffffffffb9a5bf80: fa fa fa fa 00 fa fa fa fa fa fa fa 00 fa fa fa
[   15.116983]  ffffffffb9a5c000: fa fa fa fa 00 fa fa fa fa fa fa fa 00 fa fa fa
[   15.116983] >ffffffffb9a5c080: fa fa fa fa 00 fa fa fa fa fa fa fa 00 00 00 00
[   15.116983]                                                     ^
[   15.116983]  ffffffffb9a5c100: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[   15.116983]  ffffffffb9a5c180: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[   15.116983] ==================================================================

Fixes: 85b1407b (ACPI / CPPC: Make CPPC ACPI driver aware of PCC subspace IDs)
Reported-by: NChangbin Du <changbin.du@intel.com>
Signed-off-by: NGeorge Cherian <george.cherian@cavium.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Based on ACPI 6.2 Section 8.4.7.1.9 If the PCC register space is used,
all PCC registers, for all processors in the same performance domain
(as defined by _PSD), must be defined to be in the same subspace.

Based on Section 14.1 of ACPI specification, it is possible to have a
maximum of 256 PCC subspace IDs. Add support of multiple PCC subspace
ID instead of using a single global pcc_data structure.

While at that, fix the time_delta check in send_pcc_cmd() so that
last_mpar_reset and mpar_count are initialized properly.
Signed-off-by: NGeorge Cherian <george.cherian@cavium.com>
Reviewed-by: NPrashanth Prakash <pprakash@codeaurora.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

This typo is quite common.  Fix it and add it to the spelling file so
that checkpatch catches it earlier.

Link: http://lkml.kernel.org/r/20170317011131.6881-2-sboyd@codeaurora.orgSigned-off-by: NStephen Boyd <sboyd@codeaurora.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Computed delivered performance using CPPC feedback counters are in the
CPPC abstract scale, whereas cppc_cpufreq driver operates in KHz scale.
Exposing the CPPC performance capabilities (highest,lowest, nominal,
lowest non-linear) will allow userspace to figure out the conversion
factor from CPPC abstract scale to KHz.

Also rename ctr_wrap_time to wraparound_time so that show_cppc_data()
macro will work with it.
Signed-off-by: NPrashanth Prakash <pprakash@codeaurora.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Read lowest non linear perf in cppc_get_perf_caps so that it can be exposed
via sysfs to the usespace. Lowest non linear perf is the lowest performance
level at which nonlinear power savings are achieved.
Signed-off-by: NPrashanth Prakash <pprakash@codeaurora.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Fix a possible use-after-free scenario in acpi_cppc_processor_probe()
that can happen if the function returns without cleaning up the
per-CPU pointer set by it previously.
Reported-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

First I had crashed what I bisected down to de966cf4 (sched/x86: Change
CONFIG_SCHED_ITMT to CONFIG_SCHED_MC_PRIO) because it made SCHED_ITMT the
default.

Then I run another bisect round and got here with the same backtrace:

|BUG: unable to handle kernel NULL pointer dereference at           (null)
|IP: [<ffffffff812aab6e>] acpi_cppc_processor_exit+0x40/0x60
|PGD 0 [    0.577616]
|Oops: 0000 [#1] SMP
|Modules linked in:
|CPU: 3 PID: 1 Comm: swapper/0 Not tainted 4.9.0-rc6-00146-g17669006 #51
|task: ffff88003f878000 task.stack: ffffc90000008000
|RIP: 0010:[<ffffffff812aab6e>]  [<ffffffff812aab6e>] acpi_cppc_processor_exit+0x40/0x60
|RSP: 0000:ffffc9000000bd48  EFLAGS: 00010296
|RAX: 00000000000137e0 RBX: 0000000000000000 RCX: 0000000000000001
|RDX: ffff88003fc00000 RSI: 0000000000000000 RDI: ffff88003fbca130
|RBP: ffffc9000000bd60 R08: 0000000000000514 R09: 0000000000000000
|R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000002
|R13: 0000000000000020 R14: ffffffff8167cb00 R15: 0000000000000000
|FS:  0000000000000000(0000) GS:ffff88003fcc0000(0000) knlGS:0000000000000000
|CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|CR2: 0000000000000000 CR3: 0000000001618000 CR4: 00000000000406e0
|Stack:
| ffff88003f939848 ffff88003fbca130 0000000000000001 ffffc9000000bd80
| ffffffff812a4ccb ffff88003fc0cee8 0000000000000000 ffffc9000000bdb8
| ffffffff812dc20d ffff88003fc0cee8 ffffffff8167cb00 ffff88003fc0cf48
|Call Trace:
| [<ffffffff812a4ccb>] acpi_processor_stop+0xb2/0xc5
| [<ffffffff812dc20d>] driver_probe_device+0x14d/0x2f0
| [<ffffffff812dc41e>] __driver_attach+0x6e/0x90
| [<ffffffff812da234>] bus_for_each_dev+0x54/0x90
| [<ffffffff812dbbf9>] driver_attach+0x19/0x20
| [<ffffffff812db6a6>] bus_add_driver+0xe6/0x200
| [<ffffffff812dcb23>] driver_register+0x83/0xc0
| [<ffffffff816f050a>] acpi_processor_driver_init+0x20/0x94
| [<ffffffff81000487>] do_one_initcall+0x97/0x180
| [<ffffffff816ccf5c>] kernel_init_freeable+0x112/0x1a6
| [<ffffffff813a0fc9>] kernel_init+0x9/0xf0
| [<ffffffff813acf35>] ret_from_fork+0x25/0x30
|Code: 02 00 00 00 48 8b 14 d5 e0 c3 55 81 48 8b 1c 02 4c 8d 6b 20 eb 15 49 8b 7d 00 48 85 ff 74 05 e8 39 8c d9 ff 41 ff c4 49 83 c5 20 <44> 3b 23 72 e6 48 8d bb a0 02 00 00 e8 b1 6f f9 ff 48 89 df e8
|RIP  [<ffffffff812aab6e>] acpi_cppc_processor_exit+0x40/0x60
| RSP <ffffc9000000bd48>
|CR2: 0000000000000000
|---[ end trace 917a625107b09711 ]---

Fix it.

Fixes: 17669006 (cpufreq/intel_pstate: Use CPPC to get max performance)
Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
[ rjw: Subject ]
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

We should return -EINVAL (instead of 0) if get_cpu_device() fails.

Fixes: 158c998e (ACPI / CPPC: add sysfs support to compute delivered performance)
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

For PCC mailbox with interrupt flag, CPPC should call mbox_chan_txdone()
function to notify the mailbox framework about TX completion.
Signed-off-by: NHoan Tran <hotran@apm.com>
Reviewed-by: NPrashanth Prakash <pprakash@codeaurora.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Since struct cpudata is defined in a header file, add prefix cppc_ to
make it not a generic name. Otherwise it causes compile issue in locally
define structure with the same name.
Signed-off-by: NSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

The CPPC registers can also be accessed via functional fixed hardware
addresse(FFH) in X86. Add support by modifying cpc_read and cpc_write to
be able to read/write MSRs on x86 platform on per cpu basis.
Also with this change, acpi_cppc_processor_probe doesn't bail out if
address space id is not equal to PCC or memory address space and FFH
is supported on the system.
Signed-off-by: NSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

PCC status field exposes an error bit(2) to indicate any errors during
the execution of last comamnd. This patch checks the error bit before
notifying success/failure to the cpufreq driver.
Signed-off-by: NPrashanth Prakash <pprakash@codeaurora.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

There are several global variables in cppc driver that are related
to PCC channel used for CPPC. This patch collects all such
information into a single consolidated structure(cppc_pcc_data).
Signed-off-by: NPrashanth Prakash <pprakash@codeaurora.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

The CPPC tables contain entries for per CPU feedback counters which
allows us to compute the delivered performance over a given interval
of time.

The math for delivered performance per the CPPCv5.0+ spec is:
  reference perf * delta(delivered perf ctr)/delta(ref perf ctr)

Maintaining deltas of the counters in the kernel is messy, as it
depends on when the reads are triggered. (e.g. via the cpufreq
->get() interface). Also the ->get() interace only returns one
value, so cant return raw values. So instead, leave it to userspace
to keep track of raw values and do its math for CPUs it cares about.

delivered and reference perf counters are exposed via the same
sysfs file to avoid the potential "skid", if these values are read
individually from userspace.
Signed-off-by: NPrashanth Prakash <pprakash@codeaurora.org>
Signed-off-by: NAshwin Chaugule <ashwin.chaugule@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Compute the expected transition latency for frequency transitions
using the values from the PCCT tables when the desired perf
register is in PCC.
Signed-off-by: NPrashanth Prakash <pprakash@codeaurora.org>
Reviewed-by: NAlexey Klimov <alexey.klimov@arm.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

CPPC defined in section 8.4.7 of ACPI 6.0 specification suggests
"To amortize the cost of PCC transactions, OSPM should read or write
all PCC registers via a single read or write command when possible"
This patch enables opportunistic batching of frequency transition
requests whenever the request happen to overlap in time.

Currently the access to pcc is serialized by a spin lock which does
not scale well as we increase the number of cores in the system. This
patch improves the scalability by allowing the differnt CPU cores to
update PCC subspace in parallel and by batching requests which will
reduce the certain types of operation(checking command completion bit,
ringing doorbell) by a significant margin.

Profiling shows significant improvement in the overall effeciency
to service freq. transition requests. With this patch we observe close
to 30% of the frequency transition requests being batched with other
requests while running apache bench on a ARM platform with 6
independent domains(or sets of related cpus).
Signed-off-by: NPrashanth Prakash <pprakash@codeaurora.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

We need to acquire pcc_lock only when we are accessing registers
that are in the PCC subspsace.
Signed-off-by: NPrashanth Prakash <pprakash@codeaurora.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

For cases where sys mapped CPC registers need to be accessed
frequently, it helps immensly to pre-map them rather than map
and unmap for each operation. e.g. case where feedback counters
are sys mem map registers.

Restructure cpc_read/write and the cpc_regs structure to allow
pre-mapping the system addresses and unmap them when the CPU exits.
Signed-off-by: NAshwin Chaugule <ashwin.chaugule@linaro.org>
Signed-off-by: NPrashanth Prakash <pprakash@codeaurora.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

When CPPC fails to request a PCC channel, the CPC data is freed
and cpc_desc_ptr points to the invalid data.

Avoid this issue by moving the cpc_desc_ptr assignment after the PCC
channel request.
Signed-off-by: NHoan Tran <hotran@apm.com>
Acked-by: NAshwin Chaugule <ashwin.chaugule@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Based on 8.4.7.1 section of ACPI 6.1 specification, if the platform
supports CPPC, the _CPC object must exist under all processor objects.
If cpc_desc_ptr pointer is invalid on any CPUs, acpi_get_psd_map()
should return error and CPPC cpufreq driver can not be registered.
Signed-off-by: NHoan Tran <hotran@apm.com>
Reviewed-by: NPrashanth Prakash <pprakash@codeaurora.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

The ACPI spec defines Minimum Request Turnaround Time(MRTT) and
Maximum Periodic Access Rate(MPAR) to prevent the OSPM from sending
too many requests than the platform can handle. For further details
on these parameters please refer to section 14.1.3 of ACPI 6.0 spec.

This patch includes MRTT/MPAR in deciding if or when a CPPC request
can be sent to the platform to make sure CPPC implementation is
compliant to the spec.
Signed-off-by: NPrashanth Prakash <pprakash@codeaurora.org>
Acked-by: NAshwin Chaugule <ashwin.chaugule@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

We do not have a strict read/write order requirement while accessing
PCC subspace. The only requirement is all access should be committed
before triggering the PCC doorbell to transfer the ownership of PCC
to the platform and this requirement is enforced by the PCC driver.

Profiling on a many core system shows improvement of about 1.8us on
average per freq change request(about 10% improvement on average).
Since these operations are executed while holding the pcc_lock,
reducing this time helps the CPPC implementation to scale much
better as the number of cores increases.
Signed-off-by: NPrashanth Prakash <pprakash@codeaurora.org>
Acked-by: NAshwin Chaugule <ashwin.chaugule@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

cpc_read and cpc_write are used while holding the pcc_lock spin_lock,
so they need to be as fast as possible. acpi_os_read/write_memory
APIs linearly search through a list for cached mapping which is
quite expensive. Since the PCC subspace is already mapped into
virtual address space during initialization, we can just add the
offset and access the necessary CPPC registers.

This patch + similar changes to PCC driver reduce the time per freq.
transition from around 200us to about 20us for the CPPC cpufreq
driver.
Signed-off-by: NPrashanth Prakash <pprakash@codeaurora.org>
Acked-by: NAshwin Chaugule <ashwin.chaugule@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Previously the send_pcc_cmd() code checked if the
PCC operation had completed before returning from
the function. This check was performed regardless
of the PCC op type (i.e. Read/Write). Knowing
the type of cmd can be used to optimize the check
and avoid needless waiting. e.g. with Write ops,
the actual Writing is done before calling send_pcc_cmd().
And the subsequent Writes will check if the channel is
free at the entry of send_pcc_cmd() anyway.

However, for Read cmds, we need to wait for the cmd
completion bit to be flipped, since the actual Read
ops follow after returning from the send_pcc_cmd(). So,
only do the looping check at the end for Read ops.

Also, instead of using udelay() calls, use ktime as a
means to check for deadlines. The current deadline
in which the Remote should flip the cmd completion bit
is defined as N * Nominal latency. Where N is arbitrary
and large enough to work on slow emulators and Nominal
latency comes from the ACPI table (PCCT). This helps
in working around the CONFIG_HZ effects on udelay()
and also avoids needing different ACPI tables for Silicon
and Emulation platforms.
Signed-off-by: NAshwin Chaugule <ashwin.chaugule@linaro.org>
Signed-off-by: NPrashanth Prakash <pprakash@codeaurora.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

CPPC is enabled only on platforms which support the h/w reduced
ACPI specification, so use the h/w reduced version of the PCCT
consistently when deferencing PCCT contents.

Fixes: 337aadff (ACPI: Introduce CPU performance controls using CPPC)
Signed-off-by: NAshwin Chaugule <ashwin.chaugule@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Commit 337aadff (ACPI: Introduce CPU performance controls using CPPC)
leads to the following static checker warning:

        drivers/acpi/cppc_acpi.c:527 acpi_cppc_processor_probe()
        warn: overwrite may leak 'cpc_ptr'

Fix the warning by removing the bogus per-CPU pointer dereference.

Fixes: 337aadff (ACPI: Introduce CPU performance controls using CPPC)
Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NAshwin Chaugule <ashwin.chaugule@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

The "pcc_subspace_idx" is -1 if it hasn't been initialized yet.  We need
it to be signed.

Fixes: 337aadff (ACPI: Introduce CPU performance controls using CPPC)
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Acked-by: NAshwin Chaugule <ashwin.chaugule@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>