linux-toradex.git/drivers/cpufreq, branch v2.6.20.19

[PATCH] CPUFREQ: ondemand: add a check to avoid negative load calculation

2007-08-25T15:24:21+00:00

Due to rounding and inexact jiffy accounting, idle_ticks can sometimes
be higher than total_ticks. Make sure those cases are handled as
zero load case.

Signed-off-by: Venkatesh Pallipadi 
Signed-off-by: Dave Jones 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Willy Tarreau

[PATCH] CPUFREQ: ondemand: fix tickless accounting and software coordination bug

2007-08-25T15:24:21+00:00

With tickless kernel and software coordination os P-states, ondemand
can look at wrong idle statistics. This can happen when ondemand sampling
is happening on CPU 0 and due to software coordination sampling also looks at
utilization of CPU 1. If CPU 1 is in tickless state at that moment, its idle
statistics will not be uptodate and CPU 0 thinks CPU 1 is idle for less
amount of time than it actually is.

This can be resolved by looking at all the busy times of CPUs, which is
accurate, even with tickless, and use that to determine idle time in a
round about way (total time - busy time).

Thanks to Arjan for originally reporting the ondemand bug on
Lenovo T61.

Signed-off-by: Venkatesh Pallipadi 
Signed-off-by: Dave Jones 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Willy Tarreau

[CPUFREQ] check sysfs_create_link return value

2007-01-29T05:06:27+00:00

Trivial patch to check sysfs_create_link return values.
Fail gracefully if needed.

Signed-off-by: Ahmed Darwish 
Signed-off-by: Dave Jones

[CPUFREQ] Bug fix for acpi-cpufreq and cpufreq_stats oops on frequency change notification

2006-12-23T03:45:41+00:00

Fixes the oops in cpufreq_stats with acpi_cpufreq driver.  The issue was
that the frequency was reported as 0 in acpi-cpufreq.c.  The bug is due to
different indicies for freq_table and ACPI perf table.

Also adds a check in cpufreq_stats to check for error return from
freq_table_get_index() and avoid using the error return value.

Patch fixes the issue reported at
http://www.ussg.iu.edu/hypermail/linux/kernel/0611.2/0629.html
and also other similar issue here
http://bugme.osdl.org/show_bug.cgi?id=7383 comment 53

Signed-off-by: Dhaval Giani 
Signed-off-by: Venkatesh Pallipadi 
Signed-off-by: Andrew Morton 
Signed-off-by: Dave Jones

[CPUFREQ] fixes typo in cpufreq.c

2006-12-13T15:11:25+00:00

This patch fixes a typo in cpufreq.c

From: Dhaval Giani 
Signed-off-by: Dave Jones

Merge ../linus

2006-12-12T22:41:41+00:00

Conflicts:

	drivers/cpufreq/cpufreq.c

[PATCH] hotplug CPU: clean up hotcpu_notifier() use

2006-12-07T16:39:39+00:00

There was lots of #ifdef noise in the kernel due to hotcpu_notifier(fn,
prio) not correctly marking 'fn' as used in the !HOTPLUG_CPU case, and thus
generating compiler warnings of unused symbols, hence forcing people to add
#ifdefs.

the compiler can skip truly unused functions just fine:

    text    data     bss     dec     hex filename
 1624412  728710 3674856 6027978  5bfaca vmlinux.before
 1624412  728710 3674856 6027978  5bfaca vmlinux.after

[akpm@osdl.org: topology.c fix]
Signed-off-by: Ingo Molnar 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

WorkStruct: make allyesconfig

2006-11-22T14:57:56+00:00

Fix up for make allyesconfig.

Signed-Off-By: David Howells

WorkStruct: Pass the work_struct pointer instead of context data

2006-11-22T14:55:48+00:00

Pass the work_struct pointer to the work function rather than context data.
The work function can use container_of() to work out the data.

For the cases where the container of the work_struct may go away the moment the
pending bit is cleared, it is made possible to defer the release of the
structure by deferring the clearing of the pending bit.

To make this work, an extra flag is introduced into the management side of the
work_struct.  This governs auto-release of the structure upon execution.

Ordinarily, the work queue executor would release the work_struct for further
scheduling or deallocation by clearing the pending bit prior to jumping to the
work function.  This means that, unless the driver makes some guarantee itself
that the work_struct won't go away, the work function may not access anything
else in the work_struct or its container lest they be deallocated..  This is a
problem if the auxiliary data is taken away (as done by the last patch).

However, if the pending bit is *not* cleared before jumping to the work
function, then the work function *may* access the work_struct and its container
with no problems.  But then the work function must itself release the
work_struct by calling work_release().

In most cases, automatic release is fine, so this is the default.  Special
initiators exist for the non-auto-release case (ending in _NAR).


Signed-Off-By: David Howells

[PATCH] Fix CPU_FREQ_GOV_ONDEMAND=y compile error

2006-11-21T22:07:15+00:00

The ONDEMAND governor needs FREQ_TABLE

Signed-off-by: Mattia Dongili 
Signed-off-by: Dave Jones 
Signed-off-by: Linus Torvalds