Displaying 7 results from an estimated 7 matches for "cpufreq_driv".
Did you mean:
cpufreq_driver
2008 Sep 17
5
c/s 18470
This changeset reverts two previous corrections, for reasons that escape
me.
First, the domain map is again being confined to NR_CPUS, which I had
submitted a patch to fix recently (yes, I realize the code has a TODO in
there, but those really get forgotten about far too often).
Second, the platform hypercall was reverted back to require all
information to be passed to Xen in one chunk, whereas
2011 Oct 20
0
[PATCH 07/12] cpufreq: allocate CPU masks dynamically
...ed int cpu)
goto err0;
}
+ if (!zalloc_cpumask_var(&policy->cpus)) {
+ xfree(policy);
+ ret = -ENOMEM;
+ goto err0;
+ }
+
policy->cpu = cpu;
per_cpu(cpufreq_cpu_policy, cpu) = policy;
ret = cpufreq_driver->init(policy);
if (ret) {
+ free_cpumask_var(policy->cpus);
xfree(policy);
per_cpu(cpufreq_cpu_policy, cpu) = NULL;
goto err0;
@@ -193,7 +205,7 @@ int cpufreq_add_cpu(unsigned int cpu)
if (cpufreq_verbose)
prin...
2011 Oct 14
1
[PATCH] cpufreq: error path fixes
...if (ret) {
xfree(policy);
per_cpu(cpufreq_cpu_policy, cpu) = NULL;
- return ret;
+ goto err0;
}
if (cpufreq_verbose)
printk("CPU %u initialization completed\n", cpu);
@@ -243,7 +245,7 @@ err1:
cpufreq_driver->exit(policy);
xfree(policy);
}
-
+err0:
if (cpus_empty(cpufreq_dom->map)) {
list_del(&cpufreq_dom->node);
xfree(cpufreq_dom);
--- a/xen/drivers/cpufreq/utility.c
+++ b/xen/drivers/cpufreq/utility.c
@@ -458,8 +458,8 @@ int __cpufreq_set_policy(str...
2013 Sep 12
23
More Coverity-reported issues.
Another bundle of issues from Coverity triage.
The first one is in x86/mm, and looks scarier than it is. The others
are all in xen/drivers and AFAICT are pretty minor.
Cheers,
Tim.
2012 Mar 06
4
Is: drivers/cpufreq/cpufreq-xen.c Was:Re: [PATCH 2 of 2] linux-xencommons: Load processor-passthru
.. snip..
>> Both of them (acpi-cpufreq.c and powernow-k8.c) have a symbol
>> dependency on drivers/acpi/processor.c
>
> But them being ''m'' or ''y'' shouldn''t matter in the end.
I thought you were saying it matters - as it should be done around the
same time as cpufreq drivers were loaded?
.. snip..
>> For a), this would mean some
2012 Feb 24
10
[PATCH 0 of 2] [RFC] Patches to work with processor-passthru driver (v1).
These two patches provide the neccessary infrastructure changes
for the processor-passthru driver [www.spinics.net/lists/linux-acpi/msg34655.html]
to properly function.
The first one is quite easy - we just modprobe the processor-passthru driver.
The second allows it to work under AMD machines by exposing the PM RDMSR
to dom0. It has been tested with 2.6.32 kernel as well to make sure it does
2012 Aug 16
5
[PATCH] AMD, powernow: Update P-state directly when _PSD's CoordType is DOMAIN_COORD_TYPE_HW_ALL
...strovsky <boris.ostrovsky@amd.com>
diff -r 6d56e31fe1e1 -r 85190245a94d xen/arch/x86/acpi/cpufreq/powernow.c
--- a/xen/arch/x86/acpi/cpufreq/powernow.c Wed Aug 15 09:41:21 2012 +0100
+++ b/xen/arch/x86/acpi/cpufreq/powernow.c Thu Aug 16 18:38:21 2012 +0200
@@ -56,20 +56,9 @@
static struct cpufreq_driver powernow_cpufreq_driver;
-struct drv_cmd {
- unsigned int type;
- const cpumask_t *mask;
- u32 val;
- int turbo;
-};
-
-static void transition_pstate(void *drvcmd)
+static void transition_pstate(void *pstate)
{
- struct drv_cmd *cmd;
- cmd = (struct drv_cmd *) drvcmd;
-
-
-...