mirror of
https://github.com/suyu-emu/horinux.git
synced 2026-09-21 14:15:21 -07:00
Merge branch 'master' of master.kernel.org:/pub/scm/linux/kernel/git/torvalds/linux-2.6
This commit is contained in:
David S. Miller
@@ -32,6 +32,7 @@ Christoph Hellwig <hch@lst.de>
|
||||
Corey Minyard <minyard@acm.org>
|
||||
David Brownell <david-b@pacbell.net>
|
||||
David Woodhouse <dwmw2@shinybook.infradead.org>
|
||||
Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
|
||||
Domen Puncer <domen@coderock.org>
|
||||
Douglas Gilbert <dougg@torque.net>
|
||||
Ed L. Cashin <ecashin@coraid.com>
|
||||
|
||||
@@ -464,6 +464,11 @@ S: 1200 Goldenrod Dr.
|
||||
S: Nampa, Idaho 83686
|
||||
S: USA
|
||||
|
||||
N: Dirk J. Brandewie
|
||||
E: dirk.j.brandewie@intel.com
|
||||
E: linux-wimax@intel.com
|
||||
D: Intel Wireless WiMAX Connection 2400 SDIO driver
|
||||
|
||||
N: Derrick J. Brashear
|
||||
E: shadow@dementia.org
|
||||
W: http://www.dementia.org/~shadow
|
||||
@@ -1681,7 +1686,7 @@ E: ajoshi@shell.unixbox.com
|
||||
D: fbdev hacking
|
||||
|
||||
N: Jesper Juhl
|
||||
E: jesper.juhl@gmail.com
|
||||
E: jj@chaosbits.net
|
||||
D: Various fixes, cleanups and minor features all over the tree.
|
||||
D: Wrote initial version of the hdaps driver (since passed on to others).
|
||||
S: Lemnosvej 1, 3.tv
|
||||
@@ -2119,6 +2124,11 @@ N: H.J. Lu
|
||||
E: hjl@gnu.ai.mit.edu
|
||||
D: GCC + libraries hacker
|
||||
|
||||
N: Yanir Lubetkin
|
||||
E: yanirx.lubatkin@intel.com
|
||||
E: linux-wimax@intel.com
|
||||
D: Intel Wireless WiMAX Connection 2400 driver
|
||||
|
||||
N: Michal Ludvig
|
||||
E: michal@logix.cz
|
||||
E: michal.ludvig@asterisk.co.nz
|
||||
@@ -2693,6 +2703,13 @@ S: RR #5, 497 Pole Line Road
|
||||
S: Thunder Bay, Ontario
|
||||
S: CANADA P7C 5M9
|
||||
|
||||
N: Inaky Perez-Gonzalez
|
||||
E: inaky.perez-gonzalez@intel.com
|
||||
E: linux-wimax@intel.com
|
||||
E: inakypg@yahoo.com
|
||||
D: WiMAX stack
|
||||
D: Intel Wireless WiMAX Connection 2400 driver
|
||||
|
||||
N: Yuri Per
|
||||
E: yuri@pts.mipt.ru
|
||||
D: Some smbfs fixes
|
||||
|
||||
@@ -6,7 +6,6 @@ Description:
|
||||
internal state of the kernel memory blocks. Files could be
|
||||
added or removed dynamically to represent hot-add/remove
|
||||
operations.
|
||||
|
||||
Users: hotplug memory add/remove tools
|
||||
https://w3.opensource.ibm.com/projects/powerpc-utils/
|
||||
|
||||
@@ -19,6 +18,56 @@ Description:
|
||||
This is useful for a user-level agent to determine
|
||||
identify removable sections of the memory before attempting
|
||||
potentially expensive hot-remove memory operation
|
||||
|
||||
Users: hotplug memory remove tools
|
||||
https://w3.opensource.ibm.com/projects/powerpc-utils/
|
||||
|
||||
What: /sys/devices/system/memory/memoryX/phys_device
|
||||
Date: September 2008
|
||||
Contact: Badari Pulavarty <pbadari@us.ibm.com>
|
||||
Description:
|
||||
The file /sys/devices/system/memory/memoryX/phys_device
|
||||
is read-only and is designed to show the name of physical
|
||||
memory device. Implementation is currently incomplete.
|
||||
|
||||
What: /sys/devices/system/memory/memoryX/phys_index
|
||||
Date: September 2008
|
||||
Contact: Badari Pulavarty <pbadari@us.ibm.com>
|
||||
Description:
|
||||
The file /sys/devices/system/memory/memoryX/phys_index
|
||||
is read-only and contains the section ID in hexadecimal
|
||||
which is equivalent to decimal X contained in the
|
||||
memory section directory name.
|
||||
|
||||
What: /sys/devices/system/memory/memoryX/state
|
||||
Date: September 2008
|
||||
Contact: Badari Pulavarty <pbadari@us.ibm.com>
|
||||
Description:
|
||||
The file /sys/devices/system/memory/memoryX/state
|
||||
is read-write. When read, it's contents show the
|
||||
online/offline state of the memory section. When written,
|
||||
root can toggle the the online/offline state of a removable
|
||||
memory section (see removable file description above)
|
||||
using the following commands.
|
||||
# echo online > /sys/devices/system/memory/memoryX/state
|
||||
# echo offline > /sys/devices/system/memory/memoryX/state
|
||||
|
||||
For example, if /sys/devices/system/memory/memory22/removable
|
||||
contains a value of 1 and
|
||||
/sys/devices/system/memory/memory22/state contains the
|
||||
string "online" the following command can be executed by
|
||||
by root to offline that section.
|
||||
# echo offline > /sys/devices/system/memory/memory22/state
|
||||
Users: hotplug memory remove tools
|
||||
https://w3.opensource.ibm.com/projects/powerpc-utils/
|
||||
|
||||
What: /sys/devices/system/node/nodeX/memoryY
|
||||
Date: September 2008
|
||||
Contact: Gary Hade <garyhade@us.ibm.com>
|
||||
Description:
|
||||
When CONFIG_NUMA is enabled
|
||||
/sys/devices/system/node/nodeX/memoryY is a symbolic link that
|
||||
points to the corresponding /sys/devices/system/memory/memoryY
|
||||
memory section directory. For example, the following symbolic
|
||||
link is created for memory section 9 on node0.
|
||||
/sys/devices/system/node/node0/memory9 -> ../../memory/memory9
|
||||
|
||||
|
||||
@@ -26,7 +26,7 @@ mapped only for the time they are actually used and unmapped after the DMA
|
||||
transfer.
|
||||
|
||||
The following API will work of course even on platforms where no such
|
||||
hardware exists, see e.g. include/asm-i386/pci.h for how it is implemented on
|
||||
hardware exists, see e.g. arch/x86/include/asm/pci.h for how it is implemented on
|
||||
top of the virt_to_bus interface.
|
||||
|
||||
First of all, you should make sure
|
||||
|
||||
@@ -74,6 +74,14 @@
|
||||
!Enet/sunrpc/rpcb_clnt.c
|
||||
!Enet/sunrpc/clnt.c
|
||||
</sect1>
|
||||
<sect1><title>WiMAX</title>
|
||||
!Enet/wimax/op-msg.c
|
||||
!Enet/wimax/op-reset.c
|
||||
!Enet/wimax/op-rfkill.c
|
||||
!Enet/wimax/stack.c
|
||||
!Iinclude/net/wimax.h
|
||||
!Iinclude/linux/wimax.h
|
||||
</sect1>
|
||||
</chapter>
|
||||
|
||||
<chapter id="netdev">
|
||||
|
||||
@@ -41,6 +41,12 @@ GPL version 2.
|
||||
</abstract>
|
||||
|
||||
<revhistory>
|
||||
<revision>
|
||||
<revnumber>0.6</revnumber>
|
||||
<date>2008-12-05</date>
|
||||
<authorinitials>hjk</authorinitials>
|
||||
<revremark>Added description of portio sysfs attributes.</revremark>
|
||||
</revision>
|
||||
<revision>
|
||||
<revnumber>0.5</revnumber>
|
||||
<date>2008-05-22</date>
|
||||
@@ -318,6 +324,54 @@ interested in translating it, please email me
|
||||
offset = N * getpagesize();
|
||||
</programlisting>
|
||||
|
||||
<para>
|
||||
Sometimes there is hardware with memory-like regions that can not be
|
||||
mapped with the technique described here, but there are still ways to
|
||||
access them from userspace. The most common example are x86 ioports.
|
||||
On x86 systems, userspace can access these ioports using
|
||||
<function>ioperm()</function>, <function>iopl()</function>,
|
||||
<function>inb()</function>, <function>outb()</function>, and similar
|
||||
functions.
|
||||
</para>
|
||||
<para>
|
||||
Since these ioport regions can not be mapped, they will not appear under
|
||||
<filename>/sys/class/uio/uioX/maps/</filename> like the normal memory
|
||||
described above. Without information about the port regions a hardware
|
||||
has to offer, it becomes difficult for the userspace part of the
|
||||
driver to find out which ports belong to which UIO device.
|
||||
</para>
|
||||
<para>
|
||||
To address this situation, the new directory
|
||||
<filename>/sys/class/uio/uioX/portio/</filename> was added. It only
|
||||
exists if the driver wants to pass information about one or more port
|
||||
regions to userspace. If that is the case, subdirectories named
|
||||
<filename>port0</filename>, <filename>port1</filename>, and so on,
|
||||
will appear underneath
|
||||
<filename>/sys/class/uio/uioX/portio/</filename>.
|
||||
</para>
|
||||
<para>
|
||||
Each <filename>portX/</filename> directory contains three read-only
|
||||
files that show start, size, and type of the port region:
|
||||
</para>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
<filename>start</filename>: The first port of this region.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
<filename>size</filename>: The number of ports in this region.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
<filename>porttype</filename>: A string describing the type of port.
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
|
||||
</sect1>
|
||||
</chapter>
|
||||
|
||||
@@ -339,12 +393,12 @@ offset = N * getpagesize();
|
||||
|
||||
<itemizedlist>
|
||||
<listitem><para>
|
||||
<varname>char *name</varname>: Required. The name of your driver as
|
||||
<varname>const char *name</varname>: Required. The name of your driver as
|
||||
it will appear in sysfs. I recommend using the name of your module for this.
|
||||
</para></listitem>
|
||||
|
||||
<listitem><para>
|
||||
<varname>char *version</varname>: Required. This string appears in
|
||||
<varname>const char *version</varname>: Required. This string appears in
|
||||
<filename>/sys/class/uio/uioX/version</filename>.
|
||||
</para></listitem>
|
||||
|
||||
@@ -355,6 +409,13 @@ mapping you need to fill one of the <varname>uio_mem</varname> structures.
|
||||
See the description below for details.
|
||||
</para></listitem>
|
||||
|
||||
<listitem><para>
|
||||
<varname>struct uio_port port[ MAX_UIO_PORTS_REGIONS ]</varname>: Required
|
||||
if you want to pass information about ioports to userspace. For each port
|
||||
region you need to fill one of the <varname>uio_port</varname> structures.
|
||||
See the description below for details.
|
||||
</para></listitem>
|
||||
|
||||
<listitem><para>
|
||||
<varname>long irq</varname>: Required. If your hardware generates an
|
||||
interrupt, it's your modules task to determine the irq number during
|
||||
@@ -448,6 +509,42 @@ Please do not touch the <varname>kobj</varname> element of
|
||||
<varname>struct uio_mem</varname>! It is used by the UIO framework
|
||||
to set up sysfs files for this mapping. Simply leave it alone.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Sometimes, your device can have one or more port regions which can not be
|
||||
mapped to userspace. But if there are other possibilities for userspace to
|
||||
access these ports, it makes sense to make information about the ports
|
||||
available in sysfs. For each region, you have to set up a
|
||||
<varname>struct uio_port</varname> in the <varname>port[]</varname> array.
|
||||
Here's a description of the fields of <varname>struct uio_port</varname>:
|
||||
</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem><para>
|
||||
<varname>char *porttype</varname>: Required. Set this to one of the predefined
|
||||
constants. Use <varname>UIO_PORT_X86</varname> for the ioports found in x86
|
||||
architectures.
|
||||
</para></listitem>
|
||||
|
||||
<listitem><para>
|
||||
<varname>unsigned long start</varname>: Required if the port region is used.
|
||||
Fill in the number of the first port of this region.
|
||||
</para></listitem>
|
||||
|
||||
<listitem><para>
|
||||
<varname>unsigned long size</varname>: Fill in the number of ports in this
|
||||
region. If <varname>size</varname> is zero, the region is considered unused.
|
||||
Note that you <emphasis>must</emphasis> initialize <varname>size</varname>
|
||||
with zero for all unused regions.
|
||||
</para></listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<para>
|
||||
Please do not touch the <varname>portio</varname> element of
|
||||
<varname>struct uio_port</varname>! It is used internally by the UIO
|
||||
framework to set up sysfs files for this region. Simply leave it alone.
|
||||
</para>
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1 id="adding_irq_handler">
|
||||
|
||||
@@ -294,7 +294,8 @@ NOTE: pci_enable_device() can fail! Check the return value.
|
||||
|
||||
pci_set_master() will enable DMA by setting the bus master bit
|
||||
in the PCI_COMMAND register. It also fixes the latency timer value if
|
||||
it's set to something bogus by the BIOS.
|
||||
it's set to something bogus by the BIOS. pci_clear_master() will
|
||||
disable DMA by clearing the bus master bit.
|
||||
|
||||
If the PCI device can use the PCI Memory-Write-Invalidate transaction,
|
||||
call pci_set_mwi(). This enables the PCI_COMMAND bit for Mem-Wr-Inval
|
||||
|
||||
@@ -9,3 +9,6 @@ cachefeatures.txt
|
||||
|
||||
Filesystems
|
||||
- Requirements for mounting the root file system.
|
||||
|
||||
bfin-gpio-note.txt
|
||||
- Notes in developing/using bfin-gpio driver.
|
||||
|
||||
@@ -0,0 +1,71 @@
|
||||
/*
|
||||
* File: Documentation/blackfin/bfin-gpio-note.txt
|
||||
* Based on:
|
||||
* Author:
|
||||
*
|
||||
* Created: $Id: bfin-gpio-note.txt 2008-11-24 16:42 grafyang $
|
||||
* Description: This file contains the notes in developing/using bfin-gpio.
|
||||
*
|
||||
*
|
||||
* Rev:
|
||||
*
|
||||
* Modified:
|
||||
* Copyright 2004-2008 Analog Devices Inc.
|
||||
*
|
||||
* Bugs: Enter bugs at http://blackfin.uclinux.org/
|
||||
*
|
||||
*/
|
||||
|
||||
|
||||
1. Blackfin GPIO introduction
|
||||
|
||||
There are many GPIO pins on Blackfin. Most of these pins are muxed to
|
||||
multi-functions. They can be configured as peripheral, or just as GPIO,
|
||||
configured to input with interrupt enabled, or output.
|
||||
|
||||
For detailed information, please see "arch/blackfin/kernel/bfin_gpio.c",
|
||||
or the relevant HRM.
|
||||
|
||||
|
||||
2. Avoiding resource conflict
|
||||
|
||||
Followed function groups are used to avoiding resource conflict,
|
||||
- Use the pin as peripheral,
|
||||
int peripheral_request(unsigned short per, const char *label);
|
||||
int peripheral_request_list(const unsigned short per[], const char *label);
|
||||
void peripheral_free(unsigned short per);
|
||||
void peripheral_free_list(const unsigned short per[]);
|
||||
- Use the pin as GPIO,
|
||||
int bfin_gpio_request(unsigned gpio, const char *label);
|
||||
void bfin_gpio_free(unsigned gpio);
|
||||
- Use the pin as GPIO interrupt,
|
||||
int bfin_gpio_irq_request(unsigned gpio, const char *label);
|
||||
void bfin_gpio_irq_free(unsigned gpio);
|
||||
|
||||
The request functions will record the function state for a certain pin,
|
||||
the free functions will clear it's function state.
|
||||
Once a pin is requested, it can't be requested again before it is freed by
|
||||
previous caller, otherwise kernel will dump stacks, and the request
|
||||
function fail.
|
||||
These functions are wrapped by other functions, most of the users need not
|
||||
care.
|
||||
|
||||
|
||||
3. But there are some exceptions
|
||||
- Kernel permit the identical GPIO be requested both as GPIO and GPIO
|
||||
interrut.
|
||||
Some drivers, like gpio-keys, need this behavior. Kernel only print out
|
||||
warning messages like,
|
||||
bfin-gpio: GPIO 24 is already reserved by gpio-keys: BTN0, and you are
|
||||
configuring it as IRQ!
|
||||
|
||||
Note: Consider the case that, if there are two drivers need the
|
||||
identical GPIO, one of them use it as GPIO, the other use it as
|
||||
GPIO interrupt. This will really cause resource conflict. So if
|
||||
there is any abnormal driver behavior, please check the bfin-gpio
|
||||
warning messages.
|
||||
|
||||
- Kernel permit the identical GPIO be requested from the same driver twice.
|
||||
|
||||
|
||||
|
||||
@@ -81,8 +81,8 @@ Until this step is completed the driver cannot be unloaded.
|
||||
Also echoing either mono ,packet or init in to image_type will free up the
|
||||
memory allocated by the driver.
|
||||
|
||||
If an user by accident executes steps 1 and 3 above without executing step 2;
|
||||
it will make the /sys/class/firmware/dell_rbu/ entries to disappear.
|
||||
If a user by accident executes steps 1 and 3 above without executing step 2;
|
||||
it will make the /sys/class/firmware/dell_rbu/ entries disappear.
|
||||
The entries can be recreated by doing the following
|
||||
echo init > /sys/devices/platform/dell_rbu/image_type
|
||||
NOTE: echoing init in image_type does not change it original value.
|
||||
|
||||
@@ -315,3 +315,23 @@ When: 2.6.29 (ideally) or 2.6.30 (more likely)
|
||||
Why: Deprecated by the new (standard) device driver binding model. Use
|
||||
i2c_driver->probe() and ->remove() instead.
|
||||
Who: Jean Delvare <khali@linux-fr.org>
|
||||
|
||||
---------------------------
|
||||
|
||||
What: fscher and fscpos drivers
|
||||
When: June 2009
|
||||
Why: Deprecated by the new fschmd driver.
|
||||
Who: Hans de Goede <hdegoede@redhat.com>
|
||||
Jean Delvare <khali@linux-fr.org>
|
||||
|
||||
---------------------------
|
||||
|
||||
What: SELinux "compat_net" functionality
|
||||
When: 2.6.30 at the earliest
|
||||
Why: In 2.6.18 the Secmark concept was introduced to replace the "compat_net"
|
||||
network access control functionality of SELinux. Secmark offers both
|
||||
better performance and greater flexibility than the "compat_net"
|
||||
mechanism. Now that the major Linux distributions have moved to
|
||||
Secmark, it is time to deprecate the older mechanism and start the
|
||||
process of removing the old code.
|
||||
Who: Paul Moore <paul.moore@hp.com>
|
||||
|
||||
@@ -397,7 +397,7 @@ prototypes:
|
||||
};
|
||||
|
||||
locking rules:
|
||||
All except ->poll() may block.
|
||||
All may block.
|
||||
BKL
|
||||
llseek: no (see below)
|
||||
read: no
|
||||
|
||||
@@ -140,6 +140,7 @@ Table 1-1: Process specific entries in /proc
|
||||
statm Process memory status information
|
||||
status Process status in human readable form
|
||||
wchan If CONFIG_KALLSYMS is set, a pre-decoded wchan
|
||||
stack Report full stack trace, enable via CONFIG_STACKTRACE
|
||||
smaps Extension based on maps, the rss size for each mapped file
|
||||
..............................................................................
|
||||
|
||||
@@ -1385,6 +1386,15 @@ swapcache reclaim. Decreasing vfs_cache_pressure causes the kernel to prefer
|
||||
to retain dentry and inode caches. Increasing vfs_cache_pressure beyond 100
|
||||
causes the kernel to prefer to reclaim dentries and inodes.
|
||||
|
||||
dirty_background_bytes
|
||||
----------------------
|
||||
|
||||
Contains the amount of dirty memory at which the pdflush background writeback
|
||||
daemon will start writeback.
|
||||
|
||||
If dirty_background_bytes is written, dirty_background_ratio becomes a function
|
||||
of its value (dirty_background_bytes / the amount of dirtyable system memory).
|
||||
|
||||
dirty_background_ratio
|
||||
----------------------
|
||||
|
||||
@@ -1393,14 +1403,29 @@ pages + file cache, not including locked pages and HugePages), the number of
|
||||
pages at which the pdflush background writeback daemon will start writing out
|
||||
dirty data.
|
||||
|
||||
If dirty_background_ratio is written, dirty_background_bytes becomes a function
|
||||
of its value (dirty_background_ratio * the amount of dirtyable system memory).
|
||||
|
||||
dirty_bytes
|
||||
-----------
|
||||
|
||||
Contains the amount of dirty memory at which a process generating disk writes
|
||||
will itself start writeback.
|
||||
|
||||
If dirty_bytes is written, dirty_ratio becomes a function of its value
|
||||
(dirty_bytes / the amount of dirtyable system memory).
|
||||
|
||||
dirty_ratio
|
||||
-----------------
|
||||
-----------
|
||||
|
||||
Contains, as a percentage of the dirtyable system memory (free pages + mapped
|
||||
pages + file cache, not including locked pages and HugePages), the number of
|
||||
pages at which a process which is generating disk writes will itself start
|
||||
writing out dirty data.
|
||||
|
||||
If dirty_ratio is written, dirty_bytes becomes a function of its value
|
||||
(dirty_ratio * the amount of dirtyable system memory).
|
||||
|
||||
dirty_writeback_centisecs
|
||||
-------------------------
|
||||
|
||||
|
||||
@@ -74,7 +74,7 @@ a sensor.
|
||||
Notice that some banks have both a read and a write address this is how the
|
||||
uGuru determines if a read from or a write to the bank is taking place, thus
|
||||
when reading you should always use the read address and when writing the
|
||||
write address. The write address is always one (1) more then the read address.
|
||||
write address. The write address is always one (1) more than the read address.
|
||||
|
||||
|
||||
uGuru ready
|
||||
@@ -224,7 +224,7 @@ Bit 3: Beep if alarm (RW)
|
||||
Bit 4: 1 if alarm cause measured temp is over the warning threshold (R)
|
||||
Bit 5: 1 if alarm cause measured volt is over the max threshold (R)
|
||||
Bit 6: 1 if alarm cause measured volt is under the min threshold (R)
|
||||
Bit 7: Volt sensor: Shutdown if alarm persist for more then 4 seconds (RW)
|
||||
Bit 7: Volt sensor: Shutdown if alarm persist for more than 4 seconds (RW)
|
||||
Temp sensor: Shutdown if temp is over the shutdown threshold (RW)
|
||||
|
||||
* This bit is only honored/used by the uGuru if a temp sensor is connected
|
||||
@@ -293,7 +293,7 @@ Byte 0:
|
||||
Alarm behaviour for the selected sensor. A 1 enables the described behaviour.
|
||||
Bit 0: Give an alarm if measured rpm is under the min threshold (RW)
|
||||
Bit 3: Beep if alarm (RW)
|
||||
Bit 7: Shutdown if alarm persist for more then 4 seconds (RW)
|
||||
Bit 7: Shutdown if alarm persist for more than 4 seconds (RW)
|
||||
|
||||
Byte 1:
|
||||
min threshold (scale as bank 0x26)
|
||||
|
||||
@@ -31,15 +31,11 @@ Each of the measured inputs (temperature, fan speed) has corresponding high/low
|
||||
limit values. The ADT7470 will signal an ALARM if any measured value exceeds
|
||||
either limit.
|
||||
|
||||
The ADT7470 DOES NOT sample all inputs continuously. A single pin on the
|
||||
ADT7470 is connected to a multitude of thermal diodes, but the chip must be
|
||||
instructed explicitly to read the multitude of diodes. If you want to use
|
||||
automatic fan control mode, you must manually read any of the temperature
|
||||
sensors or the fan control algorithm will not run. The chip WILL NOT DO THIS
|
||||
AUTOMATICALLY; this must be done from userspace. This may be a bug in the chip
|
||||
design, given that many other AD chips take care of this. The driver will not
|
||||
read the registers more often than once every 5 seconds. Further,
|
||||
configuration data is only read once per minute.
|
||||
The ADT7470 samples all inputs continuously. A kernel thread is started up for
|
||||
the purpose of periodically querying the temperature sensors, thus allowing the
|
||||
automatic fan pwm control to set the fan speed. The driver will not read the
|
||||
registers more often than once every 5 seconds. Further, configuration data is
|
||||
only read once per minute.
|
||||
|
||||
Special Features
|
||||
----------------
|
||||
@@ -72,5 +68,6 @@ pwm#_auto_point2_temp.
|
||||
Notes
|
||||
-----
|
||||
|
||||
As stated above, the temperature inputs must be read periodically from
|
||||
userspace in order for the automatic pwm algorithm to run.
|
||||
The temperature inputs no longer need to be read periodically from userspace in
|
||||
order for the automatic pwm algorithm to run. This was the case for earlier
|
||||
versions of the driver.
|
||||
|
||||
@@ -0,0 +1,89 @@
|
||||
Kernel driver f71882fg
|
||||
======================
|
||||
|
||||
Supported chips:
|
||||
* Fintek F71882FG and F71883FG
|
||||
Prefix: 'f71882fg'
|
||||
Addresses scanned: none, address read from Super I/O config space
|
||||
Datasheet: Available from the Fintek website
|
||||
* Fintek F71862FG and F71863FG
|
||||
Prefix: 'f71862fg'
|
||||
Addresses scanned: none, address read from Super I/O config space
|
||||
Datasheet: Available from the Fintek website
|
||||
* Fintek F8000
|
||||
Prefix: 'f8000'
|
||||
Addresses scanned: none, address read from Super I/O config space
|
||||
Datasheet: Not public
|
||||
|
||||
Author: Hans de Goede <hdegoede@redhat.com>
|
||||
|
||||
|
||||
Description
|
||||
-----------
|
||||
|
||||
Fintek F718xxFG/F8000 Super I/O chips include complete hardware monitoring
|
||||
capabilities. They can monitor up to 9 voltages (3 for the F8000), 4 fans and
|
||||
3 temperature sensors.
|
||||
|
||||
These chips also have fan controlling features, using either DC or PWM, in
|
||||
three different modes (one manual, two automatic).
|
||||
|
||||
The driver assumes that no more than one chip is present, which seems
|
||||
reasonable.
|
||||
|
||||
|
||||
Monitoring
|
||||
----------
|
||||
|
||||
The Voltage, Fan and Temperature Monitoring uses the standard sysfs
|
||||
interface as documented in sysfs-interface, without any exceptions.
|
||||
|
||||
|
||||
Fan Control
|
||||
-----------
|
||||
|
||||
Both PWM (pulse-width modulation) and DC fan speed control methods are
|
||||
supported. The right one to use depends on external circuitry on the
|
||||
motherboard, so the driver assumes that the BIOS set the method
|
||||
properly.
|
||||
|
||||
There are 2 modes to specify the speed of the fan, PWM duty cycle (or DC
|
||||
voltage) mode, where 0-100% duty cycle (0-100% of 12V) is specified. And RPM
|
||||
mode where the actual RPM of the fan (as measured) is controlled and the speed
|
||||
gets specified as 0-100% of the fan#_full_speed file.
|
||||
|
||||
Since both modes work in a 0-100% (mapped to 0-255) scale, there isn't a
|
||||
whole lot of a difference when modifying fan control settings. The only
|
||||
important difference is that in RPM mode the 0-100% controls the fan speed
|
||||
between 0-100% of fan#_full_speed. It is assumed that if the BIOS programs
|
||||
RPM mode, it will also set fan#_full_speed properly, if it does not then
|
||||
fan control will not work properly, unless you set a sane fan#_full_speed
|
||||
value yourself.
|
||||
|
||||
Switching between these modes requires re-initializing a whole bunch of
|
||||
registers, so the mode which the BIOS has set is kept. The mode is
|
||||
printed when loading the driver.
|
||||
|
||||
Three different fan control modes are supported; the mode number is written
|
||||
to the pwm#_enable file. Note that not all modes are supported on all
|
||||
chips, and some modes may only be available in RPM / PWM mode on the F8000.
|
||||
Writing an unsupported mode will result in an invalid parameter error.
|
||||
|
||||
* 1: Manual mode
|
||||
You ask for a specific PWM duty cycle / DC voltage or a specific % of
|
||||
fan#_full_speed by writing to the pwm# file. This mode is only
|
||||
available on the F8000 if the fan channel is in RPM mode.
|
||||
|
||||
* 2: Normal auto mode
|
||||
You can define a number of temperature/fan speed trip points, which % the
|
||||
fan should run at at this temp and which temp a fan should follow using the
|
||||
standard sysfs interface. The number and type of trip points is chip
|
||||
depended, see which files are available in sysfs.
|
||||
Fan/PWM channel 3 of the F8000 is always in this mode!
|
||||
|
||||
* 3: Thermostat mode (Only available on the F8000 when in duty cycle mode)
|
||||
The fan speed is regulated to keep the temp the fan is mapped to between
|
||||
temp#_auto_point2_temp and temp#_auto_point3_temp.
|
||||
|
||||
Both of the automatic modes require that pwm1 corresponds to fan1, pwm2 to
|
||||
fan2 and pwm3 to fan3.
|
||||
@@ -26,6 +26,10 @@ Supported chips:
|
||||
Datasheet: Publicly available at the ITE website
|
||||
http://www.ite.com.tw/product_info/file/pc/IT8718F_V0.2.zip
|
||||
http://www.ite.com.tw/product_info/file/pc/IT8718F_V0%203_(for%20C%20version).zip
|
||||
* IT8720F
|
||||
Prefix: 'it8720'
|
||||
Addresses scanned: from Super I/O config space (8 I/O ports)
|
||||
Datasheet: Not yet publicly available.
|
||||
* SiS950 [clone of IT8705F]
|
||||
Prefix: 'it87'
|
||||
Addresses scanned: from Super I/O config space (8 I/O ports)
|
||||
@@ -71,7 +75,7 @@ Description
|
||||
-----------
|
||||
|
||||
This driver implements support for the IT8705F, IT8712F, IT8716F,
|
||||
IT8718F, IT8726F and SiS950 chips.
|
||||
IT8718F, IT8720F, IT8726F and SiS950 chips.
|
||||
|
||||
These chips are 'Super I/O chips', supporting floppy disks, infrared ports,
|
||||
joysticks and other miscellaneous stuff. For hardware monitoring, they
|
||||
@@ -84,19 +88,19 @@ the IT8716F and late IT8712F have 6. They are shared with other functions
|
||||
though, so the functionality may not be available on a given system.
|
||||
The driver dumbly assume it is there.
|
||||
|
||||
The IT8718F also features VID inputs (up to 8 pins) but the value is
|
||||
stored in the Super-I/O configuration space. Due to technical limitations,
|
||||
The IT8718F and IT8720F also features VID inputs (up to 8 pins) but the value
|
||||
is stored in the Super-I/O configuration space. Due to technical limitations,
|
||||
this value can currently only be read once at initialization time, so
|
||||
the driver won't notice and report changes in the VID value. The two
|
||||
upper VID bits share their pins with voltage inputs (in5 and in6) so you
|
||||
can't have both on a given board.
|
||||
|
||||
The IT8716F, IT8718F and later IT8712F revisions have support for
|
||||
The IT8716F, IT8718F, IT8720F and later IT8712F revisions have support for
|
||||
2 additional fans. The additional fans are supported by the driver.
|
||||
|
||||
The IT8716F and IT8718F, and late IT8712F and IT8705F also have optional
|
||||
16-bit tachometer counters for fans 1 to 3. This is better (no more fan
|
||||
clock divider mess) but not compatible with the older chips and
|
||||
The IT8716F, IT8718F and IT8720F, and late IT8712F and IT8705F also have
|
||||
optional 16-bit tachometer counters for fans 1 to 3. This is better (no more
|
||||
fan clock divider mess) but not compatible with the older chips and
|
||||
revisions. The 16-bit tachometer mode is enabled by the driver when one
|
||||
of the above chips is detected.
|
||||
|
||||
@@ -122,7 +126,7 @@ zero'; this is important for negative voltage measurements. All voltage
|
||||
inputs can measure voltages between 0 and 4.08 volts, with a resolution of
|
||||
0.016 volt. The battery voltage in8 does not have limit registers.
|
||||
|
||||
The VID lines (IT8712F/IT8716F/IT8718F) encode the core voltage value:
|
||||
The VID lines (IT8712F/IT8716F/IT8718F/IT8720F) encode the core voltage value:
|
||||
the voltage level your processor should work with. This is hardcoded by
|
||||
the mainboard and/or processor itself. It is a value in volts.
|
||||
|
||||
|
||||
@@ -1,9 +1,11 @@
|
||||
Kernel driver lm70
|
||||
==================
|
||||
|
||||
Supported chip:
|
||||
Supported chips:
|
||||
* National Semiconductor LM70
|
||||
Datasheet: http://www.national.com/pf/LM/LM70.html
|
||||
* Texas Instruments TMP121/TMP123
|
||||
Information: http://focus.ti.com/docs/prod/folders/print/tmp121.html
|
||||
|
||||
Author:
|
||||
Kaiwan N Billimoria <kaiwan@designergraphix.com>
|
||||
@@ -25,6 +27,14 @@ complement digital temperature (sent via the SIO line), is available in the
|
||||
driver for interpretation. This driver makes use of the kernel's in-core
|
||||
SPI support.
|
||||
|
||||
As a real (in-tree) example of this "SPI protocol driver" interfacing
|
||||
with a "SPI master controller driver", see drivers/spi/spi_lm70llp.c
|
||||
and its associated documentation.
|
||||
|
||||
The TMP121/TMP123 are very similar; main differences are 4 wire SPI inter-
|
||||
face (read only) and 13-bit temperature data (0.0625 degrees celsius reso-
|
||||
lution).
|
||||
|
||||
Thanks to
|
||||
---------
|
||||
Jean Delvare <khali@linux-fr.org> for mentoring the hwmon-side driver
|
||||
|
||||
@@ -164,7 +164,7 @@ configured individually according to the following options.
|
||||
temperature. (PWM value from 0 to 255)
|
||||
|
||||
* pwm#_auto_pwm_minctl - this flags selects for temp#_auto_temp_off temperature
|
||||
the bahaviour of fans. Write 1 to let fans spinning at
|
||||
the behaviour of fans. Write 1 to let fans spinning at
|
||||
pwm#_auto_pwm_min or write 0 to let them off.
|
||||
|
||||
NOTE: It has been reported that there is a bug in the LM85 that causes the flag
|
||||
|
||||
@@ -0,0 +1,81 @@
|
||||
Kernel driver ltc4245
|
||||
=====================
|
||||
|
||||
Supported chips:
|
||||
* Linear Technology LTC4245
|
||||
Prefix: 'ltc4245'
|
||||
Addresses scanned: 0x20-0x3f
|
||||
Datasheet:
|
||||
http://www.linear.com/pc/downloadDocument.do?navId=H0,C1,C1003,C1006,C1140,P19392,D13517
|
||||
|
||||
Author: Ira W. Snyder <iws@ovro.caltech.edu>
|
||||
|
||||
|
||||
Description
|
||||
-----------
|
||||
|
||||
The LTC4245 controller allows a board to be safely inserted and removed
|
||||
from a live backplane in multiple supply systems such as CompactPCI and
|
||||
PCI Express.
|
||||
|
||||
|
||||
Usage Notes
|
||||
-----------
|
||||
|
||||
This driver does not probe for LTC4245 devices, due to the fact that some
|
||||
of the possible addresses are unfriendly to probing. You will need to use
|
||||
the "force" parameter to tell the driver where to find the device.
|
||||
|
||||
Example: the following will load the driver for an LTC4245 at address 0x23
|
||||
on I2C bus #1:
|
||||
$ modprobe ltc4245 force=1,0x23
|
||||
|
||||
|
||||
Sysfs entries
|
||||
-------------
|
||||
|
||||
The LTC4245 has built-in limits for over and under current warnings. This
|
||||
makes it very likely that the reference circuit will be used.
|
||||
|
||||
This driver uses the values in the datasheet to change the register values
|
||||
into the values specified in the sysfs-interface document. The current readings
|
||||
rely on the sense resistors listed in Table 2: "Sense Resistor Values".
|
||||
|
||||
in1_input 12v input voltage (mV)
|
||||
in2_input 5v input voltage (mV)
|
||||
in3_input 3v input voltage (mV)
|
||||
in4_input Vee (-12v) input voltage (mV)
|
||||
|
||||
in1_min_alarm 12v input undervoltage alarm
|
||||
in2_min_alarm 5v input undervoltage alarm
|
||||
in3_min_alarm 3v input undervoltage alarm
|
||||
in4_min_alarm Vee (-12v) input undervoltage alarm
|
||||
|
||||
curr1_input 12v current (mA)
|
||||
curr2_input 5v current (mA)
|
||||
curr3_input 3v current (mA)
|
||||
curr4_input Vee (-12v) current (mA)
|
||||
|
||||
curr1_max_alarm 12v overcurrent alarm
|
||||
curr2_max_alarm 5v overcurrent alarm
|
||||
curr3_max_alarm 3v overcurrent alarm
|
||||
curr4_max_alarm Vee (-12v) overcurrent alarm
|
||||
|
||||
in5_input 12v output voltage (mV)
|
||||
in6_input 5v output voltage (mV)
|
||||
in7_input 3v output voltage (mV)
|
||||
in8_input Vee (-12v) output voltage (mV)
|
||||
|
||||
in5_min_alarm 12v output undervoltage alarm
|
||||
in6_min_alarm 5v output undervoltage alarm
|
||||
in7_min_alarm 3v output undervoltage alarm
|
||||
in8_min_alarm Vee (-12v) output undervoltage alarm
|
||||
|
||||
in9_input GPIO #1 voltage data
|
||||
in10_input GPIO #2 voltage data
|
||||
in11_input GPIO #3 voltage data
|
||||
|
||||
power1_input 12v power usage (mW)
|
||||
power2_input 5v power usage (mW)
|
||||
power3_input 3v power usage (mW)
|
||||
power4_input Vee (-12v) power usage (mW)
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user