Hi Rafael,
On 28 September 2015 at 09:36, Rafael J. Wysocki rjw@rjwysocki.net wrote:
On Sunday, September 27, 2015 01:15:20 PM Ashwin Chaugule wrote:
On 25 September 2015 at 20:05, Rafael J. Wysocki rjw@rjwysocki.net wrote:
On Wednesday, September 09, 2015 04:27:04 PM Ashwin Chaugule wrote:
+int cppc_get_perf_ctrs(int cpunum, struct cppc_perf_fb_ctrs *perf_fb_ctrs) +{
struct cpc_desc *cpc_desc = per_cpu(cpc_desc_ptr, cpunum);
struct cpc_register_resource *delivered_reg, *reference_reg;
u64 delivered, reference;
int ret = 0;
if (!cpc_desc) {
pr_debug("No CPC descriptor for CPU:%d\n", cpunum);
return -ENODEV;
}
delivered_reg = &cpc_desc->cpc_regs[DELIVERED_CTR];
reference_reg = &cpc_desc->cpc_regs[REFERENCE_CTR];
spin_lock(&pcc_lock);
I still have the question about this lock.
Why does it have to be a spinlock?
The idea is to let CPUs send in their requests as quickly as possible. The PCC transaction only relays the request. So the CPUs don't really wait for all the clk + voltage toggling etc. I think any other primitive, might cause unnecessary delays in sending requests.
It might if there was contention.
Also FWIW, this is another thing I was influenced by from the pcc-cpufreq.c driver. :)
OK, so this sounds like an optimization, which is fine.
Great. Would you prefer a git pull request with the kernel doc + compiler warning fix, or should I send V10 ?
Regards, Ashwin.