Skip to content

Commit

Permalink
---
Browse files Browse the repository at this point in the history
yaml
---
r: 45052
b: refs/heads/master
c: 3a960f7
h: refs/heads/master
v: v3
  • Loading branch information
Jeff Garzik committed Dec 26, 2006
1 parent 8f01708 commit 41e6b45
Show file tree
Hide file tree
Showing 473 changed files with 7,666 additions and 4,682 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: 0c234ae655a45ac3ee53a25b2e56e9bb6c27d71d
refs/heads/master: 3a960f7e350de5d087b88a4c06df236e0f4186fd
3 changes: 3 additions & 0 deletions trunk/.gitignore
Original file line number Diff line number Diff line change
Expand Up @@ -42,3 +42,6 @@ patches-*
# quilt's files
patches
series

# cscope files
cscope.*
18 changes: 18 additions & 0 deletions trunk/Documentation/CodingStyle
Original file line number Diff line number Diff line change
Expand Up @@ -682,6 +682,24 @@ result. Typical examples would be functions that return pointers; they use
NULL or the ERR_PTR mechanism to report failure.


Chapter 17: Don't re-invent the kernel macros

The header file include/linux/kernel.h contains a number of macros that
you should use, rather than explicitly coding some variant of them yourself.
For example, if you need to calculate the length of an array, take advantage
of the macro

#define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0]))

Similarly, if you need to calculate the size of some structure member, use

#define FIELD_SIZEOF(t, f) (sizeof(((t*)0)->f))

There are also min() and max() macros that do strict type checking if you
need them. Feel free to peruse that header file to see what else is already
defined that you shouldn't reproduce in your code.



Appendix I: References

Expand Down
7 changes: 7 additions & 0 deletions trunk/Documentation/block/biodoc.txt
Original file line number Diff line number Diff line change
Expand Up @@ -946,6 +946,13 @@ elevator_merged_fn called when a request in the scheduler has been
scheduler for example, to reposition the request
if its sorting order has changed.

elevator_allow_merge_fn called whenever the block layer determines
that a bio can be merged into an existing
request safely. The io scheduler may still
want to stop a merge at this point if it
results in some sort of conflict internally,
this hook allows it to do that.

elevator_dispatch_fn fills the dispatch queue with ready requests.
I/O schedulers are free to postpone requests by
not filling the dispatch queue unless @force
Expand Down
151 changes: 120 additions & 31 deletions trunk/Documentation/ibm-acpi.txt
Original file line number Diff line number Diff line change
Expand Up @@ -398,25 +398,67 @@ Temperature sensors -- /proc/acpi/ibm/thermal

Most ThinkPads include six or more separate temperature sensors but
only expose the CPU temperature through the standard ACPI methods.
This feature shows readings from up to eight different sensors. Some
readings may not be valid, e.g. may show large negative values. For
example, on the X40, a typical output may be:
This feature shows readings from up to eight different sensors on older
ThinkPads, and it has experimental support for up to sixteen different
sensors on newer ThinkPads. Readings from sensors that are not available
return -128.

No commands can be written to this file.

EXPERIMENTAL: The 16-sensors feature is marked EXPERIMENTAL because the
implementation directly accesses hardware registers and may not work as
expected. USE WITH CAUTION! To use this feature, you need to supply the
experimental=1 parameter when loading the module. When EXPERIMENTAL
mode is enabled, reading the first 8 sensors on newer ThinkPads will
also use an new experimental thermal sensor access mode.

For example, on the X40, a typical output may be:
temperatures: 42 42 45 41 36 -128 33 -128

Thomas Gruber took his R51 apart and traced all six active sensors in
his laptop (the location of sensors may vary on other models):
EXPERIMENTAL: On the T43/p, a typical output may be:
temperatures: 48 48 36 52 38 -128 31 -128 48 52 48 -128 -128 -128 -128 -128

The mapping of thermal sensors to physical locations varies depending on
system-board model (and thus, on ThinkPad model).

http://thinkwiki.org/wiki/Thermal_Sensors is a public wiki page that
tries to track down these locations for various models.

Most (newer?) models seem to follow this pattern:

1: CPU
2: Mini PCI Module
3: HDD
2: (depends on model)
3: (depends on model)
4: GPU
5: Battery
6: N/A
7: Battery
8: N/A
5: Main battery: main sensor
6: Bay battery: main sensor
7: Main battery: secondary sensor
8: Bay battery: secondary sensor
9-15: (depends on model)

For the R51 (source: Thomas Gruber):
2: Mini-PCI
3: Internal HDD

For the T43, T43/p (source: Shmidoax/Thinkwiki.org)
http://thinkwiki.org/wiki/Thermal_Sensors#ThinkPad_T43.2C_T43p
2: System board, left side (near PCMCIA slot), reported as HDAPS temp
3: PCMCIA slot
9: MCH (northbridge) to DRAM Bus
10: ICH (southbridge), under Mini-PCI card, under touchpad
11: Power regulator, underside of system board, below F2 key

The A31 has a very atypical layout for the thermal sensors
(source: Milos Popovic, http://thinkwiki.org/wiki/Thermal_Sensors#ThinkPad_A31)
1: CPU
2: Main Battery: main sensor
3: Power Converter
4: Bay Battery: main sensor
5: MCH (northbridge)
6: PCMCIA/ambient
7: Main Battery: secondary sensor
8: Bay Battery: secondary sensor

No commands can be written to this file.

EXPERIMENTAL: Embedded controller register dump -- /proc/acpi/ibm/ecdump
------------------------------------------------------------------------
Expand Down Expand Up @@ -529,27 +571,57 @@ directly accesses hardware registers and may not work as expected. USE
WITH CAUTION! To use this feature, you need to supply the
experimental=1 parameter when loading the module.

This feature attempts to show the current fan speed. The speed is read
directly from the hardware registers of the embedded controller. This
is known to work on later R, T and X series ThinkPads but may show a
bogus value on other models.
This feature attempts to show the current fan speed, control mode and
other fan data that might be available. The speed is read directly
from the hardware registers of the embedded controller. This is known
to work on later R, T and X series ThinkPads but may show a bogus
value on other models.

Most ThinkPad fans work in "levels". Level 0 stops the fan. The higher
the level, the higher the fan speed, although adjacent levels often map
to the same fan speed. 7 is the highest level, where the fan reaches
the maximum recommended speed. Level "auto" means the EC changes the
fan level according to some internal algorithm, usually based on
readings from the thermal sensors. Level "disengaged" means the EC
disables the speed-locked closed-loop fan control, and drives the fan as
fast as it can go, which might exceed hardware limits, so use this level
with caution.

The fan usually ramps up or down slowly from one speed to another,
and it is normal for the EC to take several seconds to react to fan
commands.

The fan may be enabled or disabled with the following commands:

echo enable >/proc/acpi/ibm/fan
echo disable >/proc/acpi/ibm/fan

Placing a fan on level 0 is the same as disabling it. Enabling a fan
will try to place it in a safe level if it is too slow or disabled.

WARNING WARNING WARNING: do not leave the fan disabled unless you are
monitoring the temperature sensor readings and you are ready to enable
it if necessary to avoid overheating.
monitoring all of the temperature sensor readings and you are ready to
enable it if necessary to avoid overheating.

The fan only runs if it's enabled *and* the various temperature
sensors which control it read high enough. On the X40, this seems to
depend on the CPU and HDD temperatures. Specifically, the fan is
turned on when either the CPU temperature climbs to 56 degrees or the
HDD temperature climbs to 46 degrees. The fan is turned off when the
CPU temperature drops to 49 degrees and the HDD temperature drops to
41 degrees. These thresholds cannot currently be controlled.
An enabled fan in level "auto" may stop spinning if the EC decides the
ThinkPad is cool enough and doesn't need the extra airflow. This is
normal, and the EC will spin the fan up if the varios thermal readings
rise too much.

On the X40, this seems to depend on the CPU and HDD temperatures.
Specifically, the fan is turned on when either the CPU temperature
climbs to 56 degrees or the HDD temperature climbs to 46 degrees. The
fan is turned off when the CPU temperature drops to 49 degrees and the
HDD temperature drops to 41 degrees. These thresholds cannot
currently be controlled.

The fan level can be controlled with the command:

echo 'level <level>' > /proc/acpi/ibm/thermal

Where <level> is an integer from 0 to 7, or one of the words "auto"
or "disengaged" (without the quotes). Not all ThinkPads support the
"auto" and "disengaged" levels.

On the X31 and X40 (and ONLY on those models), the fan speed can be
controlled to a certain degree. Once the fan is running, it can be
Expand All @@ -562,12 +634,9 @@ about 3700 to about 7350. Values outside this range either do not have
any effect or the fan speed eventually settles somewhere in that
range. The fan cannot be stopped or started with this command.

On the 570, temperature readings are not available through this
feature and the fan control works a little differently. The fan speed
is reported in levels from 0 (off) to 7 (max) and can be controlled
with the following command:

echo 'level <level>' > /proc/acpi/ibm/thermal
The ThinkPad's ACPI DSDT code will reprogram the fan on its own when
certain conditions are met. It will override any fan programming done
through ibm-acpi.

EXPERIMENTAL: WAN -- /proc/acpi/ibm/wan
---------------------------------------
Expand Down Expand Up @@ -601,6 +670,26 @@ example:

modprobe ibm_acpi hotkey=enable,0xffff video=auto_disable

The ibm-acpi kernel driver can be programmed to revert the fan level
to a safe setting if userspace does not issue one of the fan commands:
"enable", "disable", "level" or "watchdog" within a configurable
ammount of time. To do this, use the "watchdog" command.

echo 'watchdog <interval>' > /proc/acpi/ibm/fan

Interval is the ammount of time in seconds to wait for one of the
above mentioned fan commands before reseting the fan level to a safe
one. If set to zero, the watchdog is disabled (default). When the
watchdog timer runs out, it does the exact equivalent of the "enable"
fan command.

Note that the watchdog timer stops after it enables the fan. It will
be rearmed again automatically (using the same interval) when one of
the above mentioned fan commands is received. The fan watchdog is,
therefore, not suitable to protect against fan mode changes made
through means other than the "enable", "disable", and "level" fan
commands.


Example Configuration
---------------------
Expand Down
8 changes: 8 additions & 0 deletions trunk/Documentation/kernel-parameters.txt
Original file line number Diff line number Diff line change
Expand Up @@ -1714,6 +1714,14 @@ and is between 256 and 4096 characters. It is defined in the file
uart6850= [HW,OSS]
Format: <io>,<irq>

uhci-hcd.ignore_oc=
[USB] Ignore overcurrent events (default N).
Some badly-designed motherboards generate lots of
bogus events, for ports that aren't wired to
anything. Set this parameter to avoid log spamming.
Note that genuine overcurrent events won't be
reported either.

usbhid.mousepoll=
[USBHID] The interval which mice are to be polled at.

Expand Down
19 changes: 11 additions & 8 deletions trunk/Documentation/powerpc/booting-without-of.txt
Original file line number Diff line number Diff line change
Expand Up @@ -1703,29 +1703,32 @@ platforms are moved over to use the flattened-device-tree model.
Required properties:

- device_type : has to be "rom"
- compatible : Should specify what this ROM device is compatible with
(i.e. "onenand"). Currently, this is most likely to be "direct-mapped"
(which corresponds to the MTD physmap mapping driver).
- regs : Offset and length of the register set (or memory mapping) for
- compatible : Should specify what this flash device is compatible with.
Currently, this is most likely to be "direct-mapped" (which
corresponds to the MTD physmap mapping driver).
- reg : Offset and length of the register set (or memory mapping) for
the device.
- bank-width : Width of the flash data bus in bytes. Required
for the NOR flashes (compatible == "direct-mapped" and others) ONLY.

Recommended properties :

- bank-width : Width of the flash data bus in bytes. Required
for the NOR flashes (compatible == "direct-mapped" and others) ONLY.
- partitions : Several pairs of 32-bit values where the first value is
partition's offset from the start of the device and the second one is
partition size in bytes with LSB used to signify a read only
partititon (so, the parition size should always be an even number).
partition (so, the parition size should always be an even number).
- partition-names : The list of concatenated zero terminated strings
representing the partition names.
- probe-type : The type of probe which should be done for the chip
(JEDEC vs CFI actually). Valid ONLY for NOR flashes.

Example:

flash@ff000000 {
device_type = "rom";
compatible = "direct-mapped";
regs = <ff000000 01000000>;
probe-type = "CFI";
reg = <ff000000 01000000>;
bank-width = <4>;
partitions = <00000000 00f80000
00f80000 00080001>;
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -927,7 +927,7 @@
<informalexample>
<programlisting>
<![CDATA[
struct mychip *chip = (struct mychip *)card->private_data;
struct mychip *chip = card->private_data;
]]>
</programlisting>
</informalexample>
Expand Down Expand Up @@ -1095,7 +1095,7 @@

/* release the irq */
if (chip->irq >= 0)
free_irq(chip->irq, (void *)chip);
free_irq(chip->irq, chip);
/* release the i/o ports & memory */
pci_release_regions(chip->pci);
/* disable the PCI entry */
Expand Down Expand Up @@ -1148,7 +1148,7 @@
}
chip->port = pci_resource_start(pci, 0);
if (request_irq(pci->irq, snd_mychip_interrupt,
IRQF_DISABLED|IRQF_SHARED, "My Chip", chip)) {
IRQF_SHARED, "My Chip", chip)) {
printk(KERN_ERR "cannot grab irq %d\n", pci->irq);
snd_mychip_free(chip);
return -EBUSY;
Expand Down Expand Up @@ -1387,7 +1387,7 @@
<programlisting>
<![CDATA[
if (chip->irq >= 0)
free_irq(chip->irq, (void *)chip);
free_irq(chip->irq, chip);
]]>
</programlisting>
</informalexample>
Expand Down
Loading

0 comments on commit 41e6b45

Please sign in to comment.