Skip to content

Commit

Permalink
---
Browse files Browse the repository at this point in the history
yaml
---
r: 222093
b: refs/heads/master
c: 3f25cb0
h: refs/heads/master
i:
  222091: f451d01
v: v3
  • Loading branch information
Tony SIM authored and Paul Mundt committed Nov 8, 2010
1 parent e4098cd commit d607e0e
Show file tree
Hide file tree
Showing 762 changed files with 8,323 additions and 14,882 deletions.
2 changes: 1 addition & 1 deletion [refs]
Original file line number Diff line number Diff line change
@@ -1,2 +1,2 @@
---
refs/heads/master: 6318af900ca7cb2c94b27d3c358762e6ac187e25
refs/heads/master: 3f25cb042ca77ac52546ae9f0039cfd0a243698c
22 changes: 0 additions & 22 deletions trunk/Documentation/ABI/obsolete/proc-pid-oom_adj

This file was deleted.

8 changes: 4 additions & 4 deletions trunk/Documentation/block/switching-sched.txt
Original file line number Diff line number Diff line change
Expand Up @@ -16,7 +16,7 @@ you can do so by typing:
As of the Linux 2.6.10 kernel, it is now possible to change the
IO scheduler for a given block device on the fly (thus making it possible,
for instance, to set the CFQ scheduler for the system default, but
set a specific device to use the deadline or noop schedulers - which
set a specific device to use the anticipatory or noop schedulers - which
can improve that device's throughput).

To set a specific scheduler, simply do this:
Expand All @@ -31,7 +31,7 @@ a "cat /sys/block/DEV/queue/scheduler" - the list of valid names
will be displayed, with the currently selected scheduler in brackets:

# cat /sys/block/hda/queue/scheduler
noop deadline [cfq]
# echo deadline > /sys/block/hda/queue/scheduler
noop anticipatory deadline [cfq]
# echo anticipatory > /sys/block/hda/queue/scheduler
# cat /sys/block/hda/queue/scheduler
noop [deadline] cfq
noop [anticipatory] deadline cfq
2 changes: 2 additions & 0 deletions trunk/Documentation/filesystems/Locking
Original file line number Diff line number Diff line change
Expand Up @@ -322,13 +322,15 @@ fl_release_private: yes yes
prototypes:
int (*fl_compare_owner)(struct file_lock *, struct file_lock *);
void (*fl_notify)(struct file_lock *); /* unblock callback */
void (*fl_copy_lock)(struct file_lock *, struct file_lock *);
void (*fl_release_private)(struct file_lock *);
void (*fl_break)(struct file_lock *); /* break_lease callback */

locking rules:
BKL may block
fl_compare_owner: yes no
fl_notify: yes no
fl_copy_lock: yes no
fl_release_private: yes yes
fl_break: yes no

Expand Down
11 changes: 11 additions & 0 deletions trunk/Documentation/filesystems/xfs-delayed-logging-design.txt
Original file line number Diff line number Diff line change
Expand Up @@ -794,6 +794,17 @@ designed.

Roadmap:

2.6.37 Remove experimental tag from mount option
=> should be roughly 6 months after initial merge
=> enough time to:
=> gain confidence and fix problems reported by early
adopters (a.k.a. guinea pigs)
=> address worst performance regressions and undesired
behaviours
=> start tuning/optimising code for parallelism
=> start tuning/optimising algorithms consuming
excessive CPU time

2.6.39 Switch default mount option to use delayed logging
=> should be roughly 12 months after initial merge
=> enough time to shake out remaining problems before next round of
Expand Down
6 changes: 1 addition & 5 deletions trunk/Documentation/i2c/busses/i2c-i801
Original file line number Diff line number Diff line change
Expand Up @@ -15,14 +15,10 @@ Supported adapters:
* Intel 82801I (ICH9)
* Intel EP80579 (Tolapai)
* Intel 82801JI (ICH10)
* Intel 5/3400 Series (PCH)
* Intel 3400/5 Series (PCH)
* Intel Cougar Point (PCH)
* Intel Patsburg (PCH)
Datasheets: Publicly available at the Intel website

On Intel Patsburg and later chipsets, both the normal host SMBus controller
and the additional 'Integrated Device Function' controllers are supported.

Authors:
Mark Studebaker <mdsxyz123@yahoo.com>
Jean Delvare <khali@linux-fr.org>
Expand Down
2 changes: 1 addition & 1 deletion trunk/Documentation/kernel-parameters.txt
Original file line number Diff line number Diff line change
Expand Up @@ -706,7 +706,7 @@ and is between 256 and 4096 characters. It is defined in the file
arch/x86/kernel/cpu/cpufreq/elanfreq.c.

elevator= [IOSCHED]
Format: {"cfq" | "deadline" | "noop"}
Format: {"anticipatory" | "cfq" | "deadline" | "noop"}
See Documentation/block/as-iosched.txt and
Documentation/block/deadline-iosched.txt for details.

Expand Down
21 changes: 9 additions & 12 deletions trunk/Documentation/leds-class.txt
Original file line number Diff line number Diff line change
Expand Up @@ -60,18 +60,15 @@ Hardware accelerated blink of LEDs

Some LEDs can be programmed to blink without any CPU interaction. To
support this feature, a LED driver can optionally implement the
blink_set() function (see <linux/leds.h>). To set an LED to blinking,
however, it is better to use use the API function led_blink_set(),
as it will check and implement software fallback if necessary.

To turn off blinking again, use the API function led_brightness_set()
as that will not just set the LED brightness but also stop any software
timers that may have been required for blinking.

The blink_set() function should choose a user friendly blinking value
if it is called with *delay_on==0 && *delay_off==0 parameters. In this
case the driver should give back the chosen value through delay_on and
delay_off parameters to the leds subsystem.
blink_set() function (see <linux/leds.h>). If implemented, triggers can
attempt to use it before falling back to software timers. The blink_set()
function should return 0 if the blink setting is supported, or -EINVAL
otherwise, which means that LED blinking will be handled by software.

The blink_set() function should choose a user friendly blinking
value if it is called with *delay_on==0 && *delay_off==0 parameters. In
this case the driver should give back the chosen value through delay_on
and delay_off parameters to the leds subsystem.

Setting the brightness to zero with brightness_set() callback function
should completely turn off the LED and cancel the previously programmed
Expand Down
88 changes: 0 additions & 88 deletions trunk/Documentation/leds/leds-lp5521.txt

This file was deleted.

83 changes: 0 additions & 83 deletions trunk/Documentation/leds/leds-lp5523.txt

This file was deleted.

9 changes: 0 additions & 9 deletions trunk/Documentation/networking/ip-sysctl.txt
Original file line number Diff line number Diff line change
Expand Up @@ -20,15 +20,6 @@ ip_no_pmtu_disc - BOOLEAN
min_pmtu - INTEGER
default 562 - minimum discovered Path MTU

route/max_size - INTEGER
Maximum number of routes allowed in the kernel. Increase
this when using large numbers of interfaces and/or routes.

neigh/default/gc_thresh3 - INTEGER
Maximum number of neighbor entries allowed. Increase this
when using large numbers of interfaces and when communicating
with large numbers of directly-connected peers.

mtu_expires - INTEGER
Time, in seconds, that cached PMTU information is kept.

Expand Down
4 changes: 2 additions & 2 deletions trunk/Documentation/rbtree.txt
Original file line number Diff line number Diff line change
Expand Up @@ -21,8 +21,8 @@ three rotations, respectively, to balance the tree), with slightly slower
To quote Linux Weekly News:

There are a number of red-black trees in use in the kernel.
The deadline and CFQ I/O schedulers employ rbtrees to
track requests; the packet CD/DVD driver does the same.
The anticipatory, deadline, and CFQ I/O schedulers all employ
rbtrees to track requests; the packet CD/DVD driver does the same.
The high-resolution timer code uses an rbtree to organize outstanding
timer requests. The ext3 filesystem tracks directory entries in a
red-black tree. Virtual memory areas (VMAs) are tracked with red-black
Expand Down
47 changes: 0 additions & 47 deletions trunk/Documentation/scsi/ChangeLog.megaraid_sas
Original file line number Diff line number Diff line change
@@ -1,50 +1,3 @@
1 Release Date : Thur. May 03, 2010 09:12:45 PST 2009 -
(emaild-id:megaraidlinux@lsi.com)
Bo Yang

2 Current Version : 00.00.04.31-rc1
3 Older Version : 00.00.04.17.1-rc1

1. Add the Online Controller Reset (OCR) to the Driver.
OCR is the new feature for megaraid_sas driver which
will allow the fw to do the chip reset which will not
affact the OS behavious.

To add the OCR support, driver need to do:
a). reset the controller chips -- Xscale and Gen2 which
will change the function calls and add the reset function
related to this two chips.

b). during the reset, driver will store the pending cmds
which not returned by FW to driver's pending queue. Driver
will re-issue those pending cmds again to FW after the OCR
finished.

c). In driver's timeout routine, driver will report to
OS as reset. Also driver's queue routine will block the
cmds until the OCR finished.

d). in Driver's ISR routine, if driver get the FW state as
state change, FW in Failure status and FW support online controller
reset (OCR), driver will start to do the controller reset.

e). In driver's IOCTL routine, the application cmds will wait for the
OCR to finish, then issue the cmds to FW.

f). Before driver kill adapter, driver will do last chance of
OCR to see if driver can bring back the FW.

2. Add the support update flag to the driver to tell LSI megaraid_sas
application which driver will support the device update. So application
will not need to do the device update after application add/del the device
from the system.
3. In driver's timeout routine, driver will do three time reset if fw is in
failed state. Driver will kill adapter if can't bring back FW after the
this three times reset.
4. Add the input parameter max_sectors to 1MB support to our GEN2 controller.
customer can use the input paramenter max_sectors to add 1MB support to GEN2
controller.

1 Release Date : Thur. Oct 29, 2009 09:12:45 PST 2009 -
(emaild-id:megaraidlinux@lsi.com)
Bo Yang
Expand Down
Loading

0 comments on commit d607e0e

Please sign in to comment.