Fixes several Embedded Controller issues, including
button failure and battery status AE_TIME failure.
http://bugzilla.kernel.org/show_bug.cgi?id=3851
Based on patch by: Andi Kleen <ak@suse.de>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
Signed-off-by: Luming Yu <luming.yu@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
platform_pci_set_power_state()
and ACPI can answer
http://bugzilla.kernel.org/show_bug.cgi?id=4277
Signed-off-by: David Shaohua Li <shaohua.li@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
pci_choose_state() can now call
platform_pci_choose_state()
and ACPI can answer
http://bugzilla.kernel.org/show_bug.cgi?id=4277
Signed-off-by: David Shaohua Li <shaohua.li@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Implement the framework for binding physical devices
with ACPI devices. A physical bus like PCI bus
should create a 'acpi_bus_type', with:
.find_device:
For device which has parent such as normal PCI devices.
.find_bridge:
It's for special devices, such as PCI root bridge
or IDE controller. Such devices generally haven't a
parent or ->bus. We use the special method
to get an ACPI handle.
Uses new field in struct device: firmware_data
http://bugzilla.kernel.org/show_bug.cgi?id=4277
Signed-off-by: David Shaohua Li <shaohua.li@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
See Documentation/acpi-hotkey.txt
Use cmdline "acpi_specific_hotkey" to enable
legacy platform specific drivers.
http://bugzilla.kernel.org/show_bug.cgi?id=3887
Signed-off-by: Luming Yu <luming.yu@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Drivers should do this:
.suspend()
pci_disable_device()
.resume()
pci_enable_device()
http://bugzilla.kernel.org/show_bug.cgi?id=3469
Signed-off-by: David Shaohua Li <shaohua.li@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Delete PCI Interrupt Link Device .resume method --
it is the device driver's job to request interrupts,
not the Link's job to remember what the devices want.
This addresses the issue of attempting to run
the ACPI interpreter too early in resume, when
interrupts are still disabled.
http://bugzilla.kernel.org/show_bug.cgi?id=3469
Signed-off-by: David Shaohua Li <shaohua.li@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Register an "acpi" system device to be notified of shutdown preparation.
This depends on CONFIG_PM
http://bugzilla.kernel.org/show_bug.cgi?id=4041
Signed-off-by: Alexey Starikovskiy <alexey.y.starikovskiy@intel.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Len Brown <len.brown@intel.com>
Signed-off-by: Keiichiro Tokunaga <tokunaga.keiich@jp.fujitsu.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Len Brown <len.brown@intel.com>
There are many drivers that have been setting the generic driver
model level shutdown callback, and pci thus must not override it.
Without this patch we can have really bad data loss on various
raid controllers.
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
__cfq_get_queue(). __cfq_get_queue() finds an existing queue (struct
cfq_queue) of the current process for the device and returns it. If it's not
found, __cfq_get_queue() creates and returns a new one if __cfq_get_queue() is
called with __GFP_WAIT flag, or __cfq_get_queue() returns NULL (this means that
get_request() fails) if no __GFP_WAIT flag.
On the other hand, in __make_request(), get_request() is called without
__GFP_WAIT flag at the first time. Thus, the get_request() fails when there is
no existing queue, typically when it's called for the first I/O request of the
process to the device.
Though it will be followed by get_request_wait() for general case,
__make_request() will just end the I/O with an error (EWOULDBLOCK) when the
request was for read-ahead.
Signed-off-by: Jens Axboe <axboe@suse.de>
Signed-off-by: Kiyoshi Ueda <k-ueda@ct.jp.nec.com>
Signed-off-by: Jun'ichi Nomura <j-nomura@ce.jp.nec.com>
It looks like logic for enabling hardware tapping in ALPS driver was
inverted and we enable it only if it was already enabled by BIOS or
firmware.
I have a confirmation from one user that the patch below fixes the problem
for him and it might be beneficial if we could get it into 2.6.12.
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
This fixed a problem that showed up in the Fedora development tree a few
weeks before the Fedora Core 4 release, initially as slab corruption, later
as hard crashes on boot up, when slab debugging was disabled for the
release. More details on the history at
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=158424
The problem is caused by sbp2's use of scsi_host->hostdata[0] to hold a
scsi_id, without explicitly requesting space for it. Since hostdata is
declared as a zero-sized array, we don't get any such space by default, so
it must be explicitly requested. The patch below implements just that.
Signed-off-by: Alexandre Oliva <aoliva@redhat.com>
Cc: Jody McIntyre <scjody@modernduck.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
__elv_add_request(). rq.count[READ] + rq.count[WRITE] can increase
more than one if another thread has allocated a request after the
current request is allocated or in_flight could have changed resulting
in larger-than-one change of nrq, thus breaking the threshold
mechanism.
Signed-off-by: Jens Axboe <axboe@suse.de>
Signed-off-by: Tejun Heo <htejun@gmail.com>
Fixed freeing of event memory in i2o_block_event()
Signed-off-by: Markus Lidel <Markus.Lidel@shadowconnect.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
It prints out x,x instead of x,y.
Signed-off-by: Jon Smirl <jonsmirl@gmail.com>
Cc: "Antonino A. Daplas" <adaplas@hotpop.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
On 64-bit machines, PCI_BASE_ADDRESS_MEM_MASK and other mask constants
passed to pci_size() are 64-bit (for example ~0x0fUL). However, pci_size
does comparisons between the u32 arguments and the mask, which will fail
even though any result from pci_size is still just 32-bit.
Changing the mask argument to u32 seems the obvious thing to do, since all
arithmetic in the function is 32-bit and having a larger mask makes no
sense.
This triggered on a PPC64 system here where an adapter (VGA, as it
happened) had a memory region base of 0xfe000000 and a sz of the same,
matching the if (max == maxbase ...) test at the bottom of pci_size but
failing the mask comparison. Quite a corner case which I guess explains
why we haven't seen it until now.
Signed-off-by: Olof Johansson <olof@lixom.net>
Acked-by: Greg KH <greg@kroah.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
From: Ralf Baechle <ralf@linux-mips.org>
There are archives of the old list at http://oss.sgi.com/archives/netdev
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
This makes the EHCI driver spin a bit longer before concluding that the
port reset failed. "Obviously safe."
It allows some devices to enumerate that previously didn't. We've seen
a bunch of these problem reports recently, this will make some go away.
As reported by Michael Zapf <Michael.Zapf@uni-kassel.de>, some EHCI
controllers seem to take forever to finish port resets and produce
"port N reset error -110" type errors. Spinning a bit longer helps.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
The pwc chainsaw session left some setups not working. There is a
sanity check on compression buffers that simply isn't right any more as
we never allocate one.
This doesn't address the email and other changes. I'll do those
tomorrow if I get time, but it is the minimal fix for the code and basic
feature set.
Signed-off-by: Alan Cox <alan@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
The current radeonfb memset's the framebuffer to 0 when loaded. This
removes occasional artifacts but has the nasty side effect that if you
load radeonfb without framebuffer console, you destroy the VGA text
buffer, font, etc... radeon must not touch the framebuffer content when
it doesn't "own" it.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
M68k: Mark Sun-3 NCR5380 SCSI broken until NCR5380_abort() and
NCR5380_bus_reset() are replaced with real new-style EH routines (the old EH
SCSI constants were removed in 2.6.12-rc3).
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
This removes a bogus hack from the radeon IRQ handler.
There is a better fix from myself and benh in DRM CVS but I'll wait
until 2.6.13-rc so it gets more testing.
Signed-off-by: Dave Airlie <airlied@linux.ie>
Despite all the care lately in making the powermac sleep/wakeup as
robust as possible, there is still a nasty related to the use of cpufreq
on PMU based machines. Unfortunately, it affects paulus old powerbook
so I have to fix it :)
We didn't manage to understand what is precisely going on, it leads to
memory corruption and might have to do with RAM not beeing properly
refreshed when a cpufreq transition is done right before the sleep.
The best workaround (and less intrusive at this point) we could come up
with is included in this patch. We basically do _not_ force a switch to
high speed on suspend anymore (that is what is causing the problem) on
those machines. We still force a speed switch on wakeup (since we don't
know what speed we are coming back from sleep at, and that seems to work
fine).
Since, during this short interval, the actual CPU speed might be
incorrect, we also hack around by multiplying loops_per_jiffy by 2 (max
speed factor on those machines) during early wakeup stage to make sure
udelay's during that time aren't too short.
For after 2.6.12, we'll change udelay implementation to use the CPU
timebase (which is always constant) instead like we do on ppc64 and thus
get rid of all those problems.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
My patch from a few weeks back (now in mainline), called "Cleanup skbs to
prevent unregister_netdevice() hanging", can cause our TX timeout code to
fire on machines with lots of VLANs (because it takes > 2 seconds between
when we stop the queues and when we're finished stopping the connections).
When that happens the TX timeout code freaks out and does a WARN_ON()
because as far as it's concerned there shouldn't be a TX timeout happening,
which is fair enough.
I have a "proper" fix for this, which is to a) do refcounting on
connections and b) implement a proper ack timer so we don't keep unacked
skbs lying around for ever. But for 2.6.12 I propose just supressing the
WARN_ON(). Users will still see the "NETDEV WATCHDOG" warning, but that's
not nearly as bad as a WARN_ON() which users interpret as an Oops.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
MSI functionality is broken on the GC_LE x86 chipset that Serverworks
developed and that is being used in various platforms today. Broadcom is
going to push out to the kernel MSI enabled Gigabit drivers (in the very
near future), and we would like to make sure that MSI does not get
enabled on any platforms using the GC_LE chipset (device id 0x17).
Following the AMD 8131 example, I am including a patch to disable MSI
functionality when a GCNB_LE is detected. Please let me know if there
are any issues with this. This is a permanent fix for this chipset, as
the hardware will not be updated.
Signed-off-by: Narendra Sankar <nsankar@broadcom.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
ftdi_sio: Avoid losing bytes at tty-ldisc.
This patch was originally developed by Daniel Smertnig. I
(Ian Abbott) made a few changes. It has been tested by both
Daniel and I, at least for raw, non-canonical receive data
processing.
Here is Daniel's original description of the patch:
===
During a project in which I was using a FTDI 232BM to
transmit data at relative high speeds (625kBit/s), I
noticed a problem where data was lost even if flow
control was enabled: The FTDI-Driver receives 512 Bytes
of data over USB at a time, which consists of 8 64-Byte
packets. Subtracting the 2 bytes of status information
included in each packet this gives 496 "real" data
bytes per read.
This data is passed (indirectly, via the flip buffers)
to the tty line discipline which takes care of
throttling when there the free buffer space reaches
TTY_THRESHOLD_THROTTLE (128). Because the FTDI driver
processes up to 496 bytes at a time, throttling won't
happen in time and the line discipline will discard the
remaining bytes.
To avoid this the patch passes data in 62-byte blocks
to the tty layer and checks the available space in the
ldisc-buffers. If there isn't enough free space,
processing the rest of the data is delayed using a
workqueue.
Note: The original problem should be easily
reproducible with a userspace program which does slow &
small reads.
===
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Signed-off-by: Daniel Smertnig <daniel.smertnig@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This smoothes two imperfections:
- Increase number of LUNs per device from 4 to 9. The best solution
would be to remove this limit altogether, but that has to wait until
the time when more than 26 hosts are allowed.
- Replace mdelay with msleep in a probing routine.
Signed-off-by: Pete Zaitcev <zaitcev@yahoo.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Here's a patch that fixes up the pci_dev refcounting in the CPCI code.
I've done some testing against it and it seems fine here.
Signed-off-by: Scott Murray <scottm@somanetworks.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Problem:
Incorrect md5sum when using ATAPI PIO mode to verify a distro CD.
Root cause: sg traverse problem.
In __atapi_pio_bytes(), if qc->cursg++ is increased and "goto
next_page" is executed, then sg is not updated to the new qc->cursg
and the old sg is overwritten with the new data.
Changes:
- Replace "goto next_page" with "goto next_sg" to make sg updated.
Signed-off-by: Albert Lee <albertcc@tw.ibm.com>
READA errors failing with EWOULDBLOCK/EAGAIN do not constitute a valid
reason for failing the path; this lead to erratic errors on DM multipath
devices. This error can be safely propagated upwards without failing the
path.
Acked-by: Kevin Corry <kevcorry@us.ibm.com>
Acked-by: Jens Axboe <axboe@suse.de>
Signed-off-by: Lars Marowsky-Bree <lmb@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Fix 5700/5701 DMA write corruption on Apple G4 by detecting the Apple
UniNorth PCI 1.5 chipset and adjusting the DMA write boundary to 16. DMA
test fails to detect the problem with this chipset.
Thanks to Manuel Perez Ayala for reporting the problem and helping to
debug it.
Signed-off-by: Michael Chan <mchan@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
At least some VIA chipsets require the fixup even in IO-APIC mode.
This was found and debugged with the patient assistance of Stian
Jordet <liste@jordet.nu> on an Asus CUV266-DLS motherboard.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
This patch disables the scroll feature on AT keyboards by default, because
it causes the numbers of mouse devices to shift, breaking user setups.
Signed-off-by: Vojtech Pavlik <vojtech@suse.cz>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
[AGPGART] Replace check_bridge_mode() with (bridge->mode & AGSTAT_MODE_3_0).
As mentioned earlier, the current check_bridge_mode() code assumes
that AGP bridges are PCI devices. This isn't always true. Definitely
not for HP zx1 chipset and the same seems to be the case for SGI's AGP
bridge.
The patch below fixes the problem by picking up the AGP_MODE_3_0 bit
from bridge->mode. I feel like I may be missing something, since I
can't see any reason why check_bridge_mode() wasn't doing that in the
first place. According to the AGP 3.0 specs, the AGP_MODE_3_0 bit is
determined during the hardware reset and cannot be changed, so it
seems to me it should be safe to pick it up from bridge->mode.
With the patch applied, I can definitely use AGP acceleration both
with AGP 2.0 and AGP 3.0 (one with an Nvidia card, the other with an
ATI FireGL card).
Unless someone spots a problem, please apply this patch so 3d
acceleration can work on zx1 boxes again.
This makes AGP work again on machines with an AGP bridge that isn't a
PCI device.
Signed-off-by: David Mosberger-Tang <davidm@hpl.hp.com>
Signed-off-by: Dave Jones <davej@redhat.com>
When Linux is running on the Xen virtual machine monitor, physical
addresses are virtualised and cannot be directly referenced by the AGP
GART. This patch fixes the GART driver for Xen by adding a layer of
abstraction between physical addresses and 'GART addresses'.
Architecture-specific functions are also defined for allocating and freeing
the GATT. Xen requires this to ensure that table really is contiguous from
the point of view of the GART.
These extra interface functions are defined as 'no-ops' for all existing
architectures that use the GART driver.
Signed-off-by: Keir Fraser <keir@xensource.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Dave Jones <davej@redhat.com>
This patch fixes a problem with accessing GART memory in
sgi_tioca_insert_memory and sgi_tioca_remove_memory.
sgi-agp.c | 12 +++++++++---
1 files changed, 9 insertions(+), 3 deletions(-)
Signed-off-by: Mike Werner <werner@sgi.com>
Signed-off-by: Dave Jones <davej@redhat.com>
Attached is a small patch for i945G support against 2.6.11.11.
From: Alan Hourihane <alanh@fairlite.demon.co.uk>
Signed-off-by: Dave Jones <davej@redhat.com>
On some 5701 devices with older bootcode, the LED configuration bits in
SRAM may be invalid with value zero. The fix is to check for invalid
bits (0) and default to PHY 1 mode. Incorrect LED mode will lead to
error in programming the PHY.
Thanks to Grant Grundler for debugging the problem.
>From Grant:
| In May, 2004, tg3 v3.4 changed how MAC_LED_CTRL (0x40c) was getting
| programmed and how to determine what to program into LED_CTRL. The new
| code trusted NIC_SRAM_DATA_CFG (0x00000b58) to indicate what to write
| to LED_CTRL and MII EXT_CTRL registers. On "IOX Core Lan", SRAM was
| saying MODE_MAC (0x0) and that doesn't work.
Signed-off-by: Michael Chan <mchan@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Stop using tty internal structure in mxser_receive_chars(), use
tty_insert_flip_char(tty, ch flag); instead.
Without this change driver ignores any rx'ed chars.
Run tested.
Cc: Alan Cox <alan@redhat.com>
Cc: Russell King <rmk@arm.linux.org.uk>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
- Changed the return value of unknown type to NULL.
- Deleted the NULL check of dev_id in siu_interrupt().
- Deleted the NULL check of port->membase in siu_shutdown().
- Added the NULL check of port->membase to siu_startup().
- Removed early_uart_ops. Now using vr41xx_siu standerd one.
- Changed KSEG1ADDR() in siu_console_setup() to ioremap().
- When uart_add_one_port() failed, changed to set NULL to port->dev.
Signed-off-by: Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
Cc: Russell King <rmk@arm.linux.org.uk>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
This "obvious" one-liner is needed to recognize Zaurus SL 6000;
it just checks two GUIDs not just one.
OSDL bugids #4512 and #4545 seem to be duplicates of this report.
From: Gerald Skerbitz <gsker@tcfreenet.org>
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Correct incorrect locking order in qla2xxx_eh_abort() handler which
would case a hang during certain code-paths.
With extra pieces to fix the irq state in the locks.
Signed-off-by: Andrew Vasquez <andrew.vasquez@qlogic.com>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
Added support to get/set flow control line levels using TIOCMGET and
TIOCMSET.
Added support for RTSCTS hardware flow control.
cp2101_get_config and cp2101_set_config modified to support long request
strings, required for configuring flow control.
Signed-off-by: Craig Shelley craig@microtron.org.uk
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The original entry of this patch was submitted by Filippo Bardelli
<filibard@libero.it>, with cleanups and patch-ification by me.
This corrects the subclass that the device reports.
Signed-off-by: Phil Dibowitz <phil@ipom.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch makes the code to provide modalias in sysfs for usb devices
56 bytes smaller in i386, while making it clear that the first part of
the modalias string is the same no matter what the device class is.
Signed-Off-By: Paulo Marques <pmarques@grupopie.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch adds a new driver for "Option" cards. This is a GSM data card,
controlled by three "serial ports" which are connected via an OHCI adapter,
all located on an oversized PC-Card. It's sold by several GSM service
providers.
Traditionally, this card has been accessed via the standard serial driver
and appropriate vendor= and product= options. However, testing has
revealed several problems with this approach, including hung data transfers
and lost data blocks when receiving.
Therefore, I've written a separate driver.
Signed-off-by: Matthias Urlichs <smurf@smurf.noris.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
They aren't really HID devices.
Damm microsoft HID driver, that thing has caused more companies to have
to do this kind of hack...
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch adds the DeLorme Earthmate lt-20 productid to the hid
blacklist table. This patch ensures the lt-20 can be claimed by the
appropriate driver (cypress_m8).
Adds the product id 0x200, of the DeLorme Earthmate lt-20, to the hid
blacklist table.
Signed-off-by: Lonnie Mendez <lmendez19@austin.rr.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch removes the outdated ChangeLog file for this driver.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
o use a semaphore instead of an opencoded and racy lock
o move locking out of shaper_kick and into the callers - most just
released the lock before calling shaper_kick
o remove in_interrupt() tests. from ->close we can always block, from
->hard_start_xmit and timer context never
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
The times when tricky goto's produced better codes are long gone.
This patch should express the same in a better way.
(Also fixes the final gcc-4.0 x86 compile error)
Signed-off-by: Adrian Bunk <bunk@stusta.de>
Cc: Jeff Garzik <jgarzik@pobox.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Jesper Juhl <juhl-lkml@dif.dk>
Signed-off-by: Chas Williams <chas@cmf.nrl.navy.mil>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Jan Beulich <jbeulich@novell.com>
Signed-off-by: Chas Williams <chas@cmf.nrl.navy.mil>
Signed-off-by: David S. Miller <davem@davemloft.net>
Changes to the cpufreq stats driver:
* Changes the way P-state transition table looks in /sysfs providing more
clear output
* Changes the time unit in the output from HZ to clock_t
Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
Signed-off-by: Dave Jones <davej@redhat.com>
[PATCH] [5/5] ondemand governor default sampling downfactor as 1
Make default sampling downfactor 1.
This works better with earlier auto downscaling change in ondemand governor.
Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
Signed-off-by: Dave Jones <davej@redhat.com>
[PATCH] [4/5] ondemand governor automatic downscaling
Here is a change of policy for the ondemand governor. The modification
concerns the frequency downscaling. Instead of decreasing to a lower
frequency when the CPU usage is under 20%, this new policy automatically
scales to the optimal frequency. The optimal frequency being the lowest
frequency which provides enough power to not trigger the upscaling policy.
Signed-off-by: Eric Piel <eric.piel@tremplin-utc.net>
Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
Signed-off-by: Dave Jones <davej@redhat.com>
[PATCH] [3/5] ondemand,conservative governor idle_tick clean-up
Ondemand and conservative governor clean-up, it factorises the idle ticks
measurement.
Signed-off-by: Eric Piel <eric.piel@tremplin-utc.net>
Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
Signed-off-by: Dave Jones <davej@redhat.com>
[PATCH] [2/5] ondemand,conservative governor store the idle ticks for all cpus
Ondemand, conservative governor did not store prev_cpu_idle_up into
prev_cpu_idle_down for other CPUs than the current CPU.
Signed-off-by: Eric Piel <eric.piel@tremplin-utc.net>
Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
Signed-off-by: Dave Jones <davej@redhat.com>
[PATCH] [1/5] ondemand,conservative minor bug-fix and cleanup
Attached patch fixes some minor issues with Alexander's patch and related
cleanup in both ondemand and conservative governor.
Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
Signed-off-by: Dave Jones <davej@redhat.com>
Adds support so that the cpufreq change stepping is no longer fixed at 5% and
can be changed dynamically by the user
Signed-off-by: Alexander Clouter <alex-kernel@digriz.org.uk>
Signed-off-by: Dave Jones <davej@redhat.com>
