Skip to content

K
kernel_linux

OpenHarmony / kernel_linux
上一次同步 大约 4 年

通知 14
Star 8
Fork 2
K
kernel_linux
提交 aef7b83c 编写于 作者: J Jeff Garzik 提交者： Jeff Garzik
浏览文件
操作

Merge /spare/repo/linux-2.6/

上级 b1fc5505 8678887e
展开全部 隐藏空白更改
内联 并排
Showing with 53748 addition and 14816 deletion

要显示的变更太多。

To preserve performance only 1000 of 1000+ files are displayed.
文本差异 电子邮件补丁
CREDITS
浏览文件 @ aef7b83c
...@@ -882,13 +882,12 @@ S: Blacksburg, Virginia 24061 ...@@ -882,13 +882,12 @@ S: Blacksburg, Virginia 24061
S: USA S: USA
N: Randy Dunlap N: Randy Dunlap
E: rddunlap@osdl.org E: rdunlap@xenotime.net
W: http://www.xenotime.net/linux/linux.html W: http://www.xenotime.net/linux/linux.html
W: http://www.linux-usb.org W: http://www.linux-usb.org
D: Linux-USB subsystem, USB core/UHCI/printer/storage drivers D: Linux-USB subsystem, USB core/UHCI/printer/storage drivers
D: x86 SMP, ACPI, bootflag hacking D: x86 SMP, ACPI, bootflag hacking
S: 12725 SW Millikan Way, Suite 400 S: (ask for current address)
S: Beaverton, Oregon 97005
S: USA S: USA
N: Bob Dunlop N: Bob Dunlop
...@@ -1881,6 +1880,13 @@ S: Schlehenweg 9 ...@@ -1881,6 +1880,13 @@ S: Schlehenweg 9
S: D-91080 Uttenreuth S: D-91080 Uttenreuth
S: Germany S: Germany
N: Jaya Kumar
E: jayalk@intworks.biz
W: http://www.intworks.biz
D: Arc monochrome LCD framebuffer driver, x86 reboot fixups
S: Gurgaon, India
S: Kuala Lumpur, Malaysia
N: Gabor Kuti N: Gabor Kuti
M: seasons@falcon.sch.bme.hu M: seasons@falcon.sch.bme.hu
M: seasons@makosteszta.sote.hu M: seasons@makosteszta.sote.hu
...@@ -2374,9 +2380,10 @@ E: tmolina@cablespeed.com ...@@ -2374,9 +2380,10 @@ E: tmolina@cablespeed.com
D: bug fixes, documentation, minor hackery D: bug fixes, documentation, minor hackery
N: James Morris N: James Morris
E: jmorris@intercode.com.au E: jmorris@redhat.com
W: http://www.intercode.com.au/jmorris/ W: http://www.intercode.com.au/jmorris/
D: Netfilter, Linux Security Modules (LSM). D: Netfilter, Linux Security Modules (LSM), SELinux, IPSec,
D: Crypto API, general networking, miscellaneous.
S: PO Box 707 S: PO Box 707
S: Spit Junction NSW 2088 S: Spit Junction NSW 2088
S: Australia S: Australia
...@@ -2476,13 +2483,9 @@ S: Potsdam, New York 13676 ...@@ -2476,13 +2483,9 @@ S: Potsdam, New York 13676
S: USA S: USA
N: Dave Neuer N: Dave Neuer
E: dneuer@innovation-charter.com E: dave.neuer@pobox.com
E: mr_fred_smoothie@yahoo.com
D: Helped implement support for Compaq's H31xx series iPAQs D: Helped implement support for Compaq's H31xx series iPAQs
D: Other mostly minor tweaks & bugfixes D: Other mostly minor tweaks & bugfixes
S: 325 E. Main St., Suite 3
S: Carnegie, PA 15105
S: USA
N: Michael Neuffer N: Michael Neuffer
E: mike@i-Connect.Net E: mike@i-Connect.Net
......
Documentation/00-INDEX
浏览文件 @ aef7b83c
...@@ -138,6 +138,8 @@ java.txt ...@@ -138,6 +138,8 @@ java.txt
- info on the in-kernel binary support for Java(tm). - info on the in-kernel binary support for Java(tm).
kbuild/ kbuild/
- directory with info about the kernel build process. - directory with info about the kernel build process.
kdumpt.txt
- mini HowTo on getting the crash dump code to work.
kernel-doc-nano-HOWTO.txt kernel-doc-nano-HOWTO.txt
- mini HowTo on generation and location of kernel documentation files. - mini HowTo on generation and location of kernel documentation files.
kernel-docs.txt kernel-docs.txt
......
Documentation/Changes
浏览文件 @ aef7b83c
...@@ -63,7 +63,7 @@ o PPP 2.4.0 # pppd --version ...@@ -63,7 +63,7 @@ o PPP 2.4.0 # pppd --version
o isdn4k-utils 3.1pre1 # isdnctrl 2>&1|grep version o isdn4k-utils 3.1pre1 # isdnctrl 2>&1|grep version
o nfs-utils 1.0.5 # showmount --version o nfs-utils 1.0.5 # showmount --version
o procps 3.2.0 # ps --version o procps 3.2.0 # ps --version
o oprofile 0.5.3 # oprofiled --version o oprofile 0.9 # oprofiled --version
Kernel compilation Kernel compilation
================== ==================
......
Documentation/DocBook/Makefile
浏览文件 @ aef7b83c
...@@ -8,7 +8,7 @@ ...@@ -8,7 +8,7 @@
DOCBOOKS := wanbook.xml z8530book.xml mcabook.xml videobook.xml \ DOCBOOKS := wanbook.xml z8530book.xml mcabook.xml videobook.xml \
kernel-hacking.xml kernel-locking.xml deviceiobook.xml \ kernel-hacking.xml kernel-locking.xml deviceiobook.xml \
procfs-guide.xml writing_usb_driver.xml scsidrivers.xml \ procfs-guide.xml writing_usb_driver.xml \
sis900.xml kernel-api.xml journal-api.xml lsm.xml usb.xml \ sis900.xml kernel-api.xml journal-api.xml lsm.xml usb.xml \
gadget.xml libata.xml mtdnand.xml librs.xml gadget.xml libata.xml mtdnand.xml librs.xml
...@@ -49,7 +49,7 @@ installmandocs: mandocs ...@@ -49,7 +49,7 @@ installmandocs: mandocs
KERNELDOC = scripts/kernel-doc KERNELDOC = scripts/kernel-doc
DOCPROC = scripts/basic/docproc DOCPROC = scripts/basic/docproc
XMLTOFLAGS = -m Documentation/DocBook/stylesheet.xsl XMLTOFLAGS = -m $(srctree)/Documentation/DocBook/stylesheet.xsl
#XMLTOFLAGS += --skip-validation #XMLTOFLAGS += --skip-validation
### ###
......
Documentation/DocBook/kernel-api.tmpl
浏览文件 @ aef7b83c
...@@ -266,7 +266,7 @@ X!Ekernel/module.c ...@@ -266,7 +266,7 @@ X!Ekernel/module.c
<chapter id="hardware"> <chapter id="hardware">
<title>Hardware Interfaces</title> <title>Hardware Interfaces</title>
<sect1><title>Interrupt Handling</title> <sect1><title>Interrupt Handling</title>
!Iarch/i386/kernel/irq.c !Ikernel/irq/manage.c
</sect1> </sect1>
<sect1><title>Resources Management</title> <sect1><title>Resources Management</title>
...@@ -338,7 +338,6 @@ X!Earch/i386/kernel/mca.c ...@@ -338,7 +338,6 @@ X!Earch/i386/kernel/mca.c
X!Iinclude/linux/device.h X!Iinclude/linux/device.h
--> -->
!Edrivers/base/driver.c !Edrivers/base/driver.c
!Edrivers/base/class_simple.c
!Edrivers/base/core.c !Edrivers/base/core.c
!Edrivers/base/firmware_class.c !Edrivers/base/firmware_class.c
!Edrivers/base/transport_class.c !Edrivers/base/transport_class.c
......
Documentation/DocBook/libata.tmpl
浏览文件 @ aef7b83c
...@@ -14,7 +14,7 @@ ...@@ -14,7 +14,7 @@
</authorgroup> </authorgroup>
<copyright> <copyright>
<year>2003</year> <year>2003-2005</year>
<holder>Jeff Garzik</holder> <holder>Jeff Garzik</holder>
</copyright> </copyright>
...@@ -44,30 +44,38 @@ ...@@ -44,30 +44,38 @@
<toc></toc> <toc></toc>
<chapter id="libataThanks"> <chapter id="libataIntroduction">
<title>Thanks</title> <title>Introduction</title>
<para> <para>
The bulk of the ATA knowledge comes thanks to long conversations with libATA is a library used inside the Linux kernel to support ATA host
Andre Hedrick (www.linux-ide.org). controllers and devices. libATA provides an ATA driver API, class
transports for ATA and ATAPI devices, and SCSI&lt;-&gt;ATA translation
for ATA devices according to the T10 SAT specification.
</para> </para>
<para> <para>
Thanks to Alan Cox for pointing out similarities This Guide documents the libATA driver API, library functions, library
between SATA and SCSI, and in general for motivation to hack on internals, and a couple sample ATA low-level drivers.
libata.
</para>
<para>
libata's device detection
method, ata_pio_devchk, and in general all the early probing was
based on extensive study of Hale Landis's probe/reset code in his
ATADRVR driver (www.ata-atapi.com).
</para> </para>
</chapter> </chapter>
<chapter id="libataDriverApi"> <chapter id="libataDriverApi">
<title>libata Driver API</title> <title>libata Driver API</title>
<para>
struct ata_port_operations is defined for every low-level libata
hardware driver, and it controls how the low-level driver
interfaces with the ATA and SCSI layers.
</para>
<para>
FIS-based drivers will hook into the system with ->qc_prep() and
->qc_issue() high-level hooks. Hardware which behaves in a manner
similar to PCI IDE hardware may utilize several generic helpers,
defining at a bare minimum the bus I/O addresses of the ATA shadow
register blocks.
</para>
<sect1> <sect1>
<title>struct ata_port_operations</title> <title>struct ata_port_operations</title>
<sect2><title>Disable ATA port</title>
<programlisting> <programlisting>
void (*port_disable) (struct ata_port *); void (*port_disable) (struct ata_port *);
</programlisting> </programlisting>
...@@ -78,6 +86,9 @@ void (*port_disable) (struct ata_port *); ...@@ -78,6 +86,9 @@ void (*port_disable) (struct ata_port *);
unplug). unplug).
</para> </para>
</sect2>
<sect2><title>Post-IDENTIFY device configuration</title>
<programlisting> <programlisting>
void (*dev_config) (struct ata_port *, struct ata_device *); void (*dev_config) (struct ata_port *, struct ata_device *);
</programlisting> </programlisting>
...@@ -88,6 +99,9 @@ void (*dev_config) (struct ata_port *, struct ata_device *); ...@@ -88,6 +99,9 @@ void (*dev_config) (struct ata_port *, struct ata_device *);
issue of SET FEATURES - XFER MODE, and prior to operation. issue of SET FEATURES - XFER MODE, and prior to operation.
</para> </para>
</sect2>
<sect2><title>Set PIO/DMA mode</title>
<programlisting> <programlisting>
void (*set_piomode) (struct ata_port *, struct ata_device *); void (*set_piomode) (struct ata_port *, struct ata_device *);
void (*set_dmamode) (struct ata_port *, struct ata_device *); void (*set_dmamode) (struct ata_port *, struct ata_device *);
...@@ -108,6 +122,9 @@ void (*post_set_mode) (struct ata_port *ap); ...@@ -108,6 +122,9 @@ void (*post_set_mode) (struct ata_port *ap);
->set_dma_mode() is only called if DMA is possible. ->set_dma_mode() is only called if DMA is possible.
</para> </para>
</sect2>
<sect2><title>Taskfile read/write</title>
<programlisting> <programlisting>
void (*tf_load) (struct ata_port *ap, struct ata_taskfile *tf); void (*tf_load) (struct ata_port *ap, struct ata_taskfile *tf);
void (*tf_read) (struct ata_port *ap, struct ata_taskfile *tf); void (*tf_read) (struct ata_port *ap, struct ata_taskfile *tf);
...@@ -120,6 +137,9 @@ void (*tf_read) (struct ata_port *ap, struct ata_taskfile *tf); ...@@ -120,6 +137,9 @@ void (*tf_read) (struct ata_port *ap, struct ata_taskfile *tf);
taskfile register values. taskfile register values.
</para> </para>
</sect2>
<sect2><title>ATA command execute</title>
<programlisting> <programlisting>
void (*exec_command)(struct ata_port *ap, struct ata_taskfile *tf); void (*exec_command)(struct ata_port *ap, struct ata_taskfile *tf);
</programlisting> </programlisting>
...@@ -129,17 +149,37 @@ void (*exec_command)(struct ata_port *ap, struct ata_taskfile *tf); ...@@ -129,17 +149,37 @@ void (*exec_command)(struct ata_port *ap, struct ata_taskfile *tf);
->tf_load(), to be initiated in hardware. ->tf_load(), to be initiated in hardware.
</para> </para>
</sect2>
<sect2><title>Per-cmd ATAPI DMA capabilities filter</title>
<programlisting>
int (*check_atapi_dma) (struct ata_queued_cmd *qc);
</programlisting>
<para>
Allow low-level driver to filter ATA PACKET commands, returning a status
indicating whether or not it is OK to use DMA for the supplied PACKET
command.
</para>
</sect2>
<sect2><title>Read specific ATA shadow registers</title>
<programlisting> <programlisting>
u8 (*check_status)(struct ata_port *ap); u8 (*check_status)(struct ata_port *ap);
void (*dev_select)(struct ata_port *ap, unsigned int device); u8 (*check_altstatus)(struct ata_port *ap);
u8 (*check_err)(struct ata_port *ap);
</programlisting> </programlisting>
<para> <para>
Reads the Status ATA shadow register from hardware. On some Reads the Status/AltStatus/Error ATA shadow register from
hardware, this has the side effect of clearing the interrupt hardware. On some hardware, reading the Status register has
condition. the side effect of clearing the interrupt condition.
</para> </para>
</sect2>
<sect2><title>Select ATA device on bus</title>
<programlisting> <programlisting>
void (*dev_select)(struct ata_port *ap, unsigned int device); void (*dev_select)(struct ata_port *ap, unsigned int device);
</programlisting> </programlisting>
...@@ -147,9 +187,13 @@ void (*dev_select)(struct ata_port *ap, unsigned int device); ...@@ -147,9 +187,13 @@ void (*dev_select)(struct ata_port *ap, unsigned int device);
<para> <para>
Issues the low-level hardware command(s) that causes one of N Issues the low-level hardware command(s) that causes one of N
hardware devices to be considered 'selected' (active and hardware devices to be considered 'selected' (active and
available for use) on the ATA bus. available for use) on the ATA bus. This generally has no
meaning on FIS-based devices.
</para> </para>
</sect2>
<sect2><title>Reset ATA bus</title>
<programlisting> <programlisting>
void (*phy_reset) (struct ata_port *ap); void (*phy_reset) (struct ata_port *ap);
</programlisting> </programlisting>
...@@ -162,17 +206,31 @@ void (*phy_reset) (struct ata_port *ap); ...@@ -162,17 +206,31 @@ void (*phy_reset) (struct ata_port *ap);
functions ata_bus_reset() or sata_phy_reset() for this hook. functions ata_bus_reset() or sata_phy_reset() for this hook.
</para> </para>
</sect2>
<sect2><title>Control PCI IDE BMDMA engine</title>
<programlisting> <programlisting>
void (*bmdma_setup) (struct ata_queued_cmd *qc); void (*bmdma_setup) (struct ata_queued_cmd *qc);
void (*bmdma_start) (struct ata_queued_cmd *qc); void (*bmdma_start) (struct ata_queued_cmd *qc);
void (*bmdma_stop) (struct ata_port *ap);
u8 (*bmdma_status) (struct ata_port *ap);
</programlisting> </programlisting>
<para> <para>
When setting up an IDE BMDMA transaction, these hooks arm When setting up an IDE BMDMA transaction, these hooks arm
(->bmdma_setup) and fire (->bmdma_start) the hardware's DMA (->bmdma_setup), fire (->bmdma_start), and halt (->bmdma_stop)
engine. the hardware's DMA engine. ->bmdma_status is used to read the standard
PCI IDE DMA Status register.
</para> </para>
<para>
These hooks are typically either no-ops, or simply not implemented, in
FIS-based drivers.
</para>
</sect2>
<sect2><title>High-level taskfile hooks</title>
<programlisting> <programlisting>
void (*qc_prep) (struct ata_queued_cmd *qc); void (*qc_prep) (struct ata_queued_cmd *qc);
int (*qc_issue) (struct ata_queued_cmd *qc); int (*qc_issue) (struct ata_queued_cmd *qc);
...@@ -190,20 +248,26 @@ int (*qc_issue) (struct ata_queued_cmd *qc); ...@@ -190,20 +248,26 @@ int (*qc_issue) (struct ata_queued_cmd *qc);
->qc_issue is used to make a command active, once the hardware ->qc_issue is used to make a command active, once the hardware
and S/G tables have been prepared. IDE BMDMA drivers use the and S/G tables have been prepared. IDE BMDMA drivers use the
helper function ata_qc_issue_prot() for taskfile protocol-based helper function ata_qc_issue_prot() for taskfile protocol-based
dispatch. More advanced drivers roll their own ->qc_issue dispatch. More advanced drivers implement their own ->qc_issue.
implementation, using this as the "issue new ATA command to
hardware" hook.
</para> </para>
</sect2>
<sect2><title>Timeout (error) handling</title>
<programlisting> <programlisting>
void (*eng_timeout) (struct ata_port *ap); void (*eng_timeout) (struct ata_port *ap);
</programlisting> </programlisting>
<para> <para>
This is a high level error handling function, called from the This is a high level error handling function, called from the
error handling thread, when a command times out. error handling thread, when a command times out. Most newer
hardware will implement its own error handling code here. IDE BMDMA
drivers may use the helper function ata_eng_timeout().
</para> </para>
</sect2>
<sect2><title>Hardware interrupt handling</title>
<programlisting> <programlisting>
irqreturn_t (*irq_handler)(int, void *, struct pt_regs *); irqreturn_t (*irq_handler)(int, void *, struct pt_regs *);
void (*irq_clear) (struct ata_port *); void (*irq_clear) (struct ata_port *);
...@@ -216,6 +280,9 @@ void (*irq_clear) (struct ata_port *); ...@@ -216,6 +280,9 @@ void (*irq_clear) (struct ata_port *);
is quiet. is quiet.
</para> </para>
</sect2>
<sect2><title>SATA phy read/write</title>
<programlisting> <programlisting>
u32 (*scr_read) (struct ata_port *ap, unsigned int sc_reg); u32 (*scr_read) (struct ata_port *ap, unsigned int sc_reg);
void (*scr_write) (struct ata_port *ap, unsigned int sc_reg, void (*scr_write) (struct ata_port *ap, unsigned int sc_reg,
...@@ -227,6 +294,9 @@ void (*scr_write) (struct ata_port *ap, unsigned int sc_reg, ...@@ -227,6 +294,9 @@ void (*scr_write) (struct ata_port *ap, unsigned int sc_reg,
if ->phy_reset hook called the sata_phy_reset() helper function. if ->phy_reset hook called the sata_phy_reset() helper function.
</para> </para>
</sect2>
<sect2><title>Init and shutdown</title>
<programlisting> <programlisting>
int (*port_start) (struct ata_port *ap); int (*port_start) (struct ata_port *ap);
void (*port_stop) (struct ata_port *ap); void (*port_stop) (struct ata_port *ap);
...@@ -240,15 +310,17 @@ void (*host_stop) (struct ata_host_set *host_set); ...@@ -240,15 +310,17 @@ void (*host_stop) (struct ata_host_set *host_set);
tasks. tasks.
</para> </para>
<para> <para>
->host_stop() is called when the rmmod or hot unplug process
begins. The hook must stop all hardware interrupts, DMA
engines, etc.
</para>
<para>
->port_stop() is called after ->host_stop(). It's sole function ->port_stop() is called after ->host_stop(). It's sole function
is to release DMA/memory resources, now that they are no longer is to release DMA/memory resources, now that they are no longer
actively being used. actively being used.
</para> </para>
<para>
->host_stop() is called after all ->port_stop() calls
have completed. The hook must finalize hardware shutdown, release DMA
and other resources, etc.
</para>
</sect2>
</sect1> </sect1>
</chapter> </chapter>
...@@ -279,4 +351,24 @@ void (*host_stop) (struct ata_host_set *host_set); ...@@ -279,4 +351,24 @@ void (*host_stop) (struct ata_host_set *host_set);
!Idrivers/scsi/sata_sil.c !Idrivers/scsi/sata_sil.c
</chapter> </chapter>
<chapter id="libataThanks">
<title>Thanks</title>
<para>
The bulk of the ATA knowledge comes thanks to long conversations with
Andre Hedrick (www.linux-ide.org), and long hours pondering the ATA
and SCSI specifications.
</para>
<para>
Thanks to Alan Cox for pointing out similarities
between SATA and SCSI, and in general for motivation to hack on
libata.
</para>
<para>
libata's device detection
method, ata_pio_devchk, and in general all the early probing was
based on extensive study of Hale Landis's probe/reset code in his
ATADRVR driver (www.ata-atapi.com).
</para>
</chapter>
</book> </book>
Documentation/DocBook/scsidrivers.tmpl 已删除 100644 → 0
浏览文件 @ b1fc5505
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN"
"http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd" []>
<book id="scsidrivers">
<bookinfo>
<title>SCSI Subsystem Interfaces</title>
<authorgroup>
<author>
<firstname>Douglas</firstname>
<surname>Gilbert</surname>
<affiliation>
<address>
<email>dgilbert@interlog.com</email>
</address>
</affiliation>
</author>
</authorgroup>
<pubdate>2003-08-11</pubdate>
<copyright>
<year>2002</year>
<year>2003</year>
<holder>Douglas Gilbert</holder>
</copyright>
<legalnotice>
<para>
This documentation is free software; you can redistribute
it and/or modify it under the terms of the GNU General Public
License as published by the Free Software Foundation; either
version 2 of the License, or (at your option) any later
version.
</para>
<para>
This program is distributed in the hope that it will be
useful, but WITHOUT ANY WARRANTY; without even the implied
warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
See the GNU General Public License for more details.
</para>
<para>
You should have received a copy of the GNU General Public
License along with this program; if not, write to the Free
Software Foundation, Inc., 59 Temple Place, Suite 330, Boston,
MA 02111-1307 USA
</para>
<para>
For more details see the file COPYING in the source
distribution of Linux.
</para>
</legalnotice>
</bookinfo>
<toc></toc>
<chapter id="intro">
<title>Introduction</title>
<para>
This document outlines the interface between the Linux scsi mid level
and lower level drivers. Lower level drivers are variously called HBA
(host bus adapter) drivers, host drivers (HD) or pseudo adapter drivers.
The latter alludes to the fact that a lower level driver may be a
bridge to another IO subsystem (and the "ide-scsi" driver is an example
of this). There can be many lower level drivers active in a running
system, but only one per hardware type. For example, the aic7xxx driver
controls adaptec controllers based on the 7xxx chip series. Most lower
level drivers can control one or more scsi hosts (a.k.a. scsi initiators).
</para>
<para>
This document can been found in an ASCII text file in the linux kernel
source: <filename>Documentation/scsi/scsi_mid_low_api.txt</filename> .
It currently hold a little more information than this document. The
<filename>drivers/scsi/hosts.h</filename> and <filename>
drivers/scsi/scsi.h</filename> headers contain descriptions of members
of important structures for the scsi subsystem.
</para>
</chapter>
<chapter id="driver-struct">
<title>Driver structure</title>
<para>
Traditionally a lower level driver for the scsi subsystem has been
at least two files in the drivers/scsi directory. For example, a
driver called "xyz" has a header file "xyz.h" and a source file
"xyz.c". [Actually there is no good reason why this couldn't all
be in one file.] Some drivers that have been ported to several operating
systems (e.g. aic7xxx which has separate files for generic and
OS-specific code) have more than two files. Such drivers tend to have
their own directory under the drivers/scsi directory.
</para>
<para>
scsi_module.c is normally included at the end of a lower
level driver. For it to work a declaration like this is needed before
it is included:
<programlisting>
static Scsi_Host_Template driver_template = DRIVER_TEMPLATE;
/* DRIVER_TEMPLATE should contain pointers to supported interface
functions. Scsi_Host_Template is defined hosts.h */
#include "scsi_module.c"
</programlisting>
</para>
<para>
The scsi_module.c assumes the name "driver_template" is appropriately
defined. It contains 2 functions:
<orderedlist>
<listitem><para>
init_this_scsi_driver() called during builtin and module driver
initialization: invokes mid level's scsi_register_host()
</para></listitem>
<listitem><para>
exit_this_scsi_driver() called during closedown: invokes
mid level's scsi_unregister_host()
</para></listitem>
</orderedlist>
</para>
<para>
When a new, lower level driver is being added to Linux, the following
files (all found in the drivers/scsi directory) will need some attention:
Makefile, Config.help and Config.in . It is probably best to look at what
an existing lower level driver does in this regard.
</para>
</chapter>
<chapter id="intfunctions">
<title>Interface Functions</title>
!EDocumentation/scsi/scsi_mid_low_api.txt
</chapter>
<chapter id="locks">
<title>Locks</title>
<para>
Each Scsi_Host instance has a spin_lock called Scsi_Host::default_lock
which is initialized in scsi_register() [found in hosts.c]. Within the
same function the Scsi_Host::host_lock pointer is initialized to point
at default_lock with the scsi_assign_lock() function. Thereafter
lock and unlock operations performed by the mid level use the
Scsi_Host::host_lock pointer.
</para>
<para>
Lower level drivers can override the use of Scsi_Host::default_lock by
using scsi_assign_lock(). The earliest opportunity to do this would
be in the detect() function after it has invoked scsi_register(). It
could be replaced by a coarser grain lock (e.g. per driver) or a
lock of equal granularity (i.e. per host). Using finer grain locks
(e.g. per scsi device) may be possible by juggling locks in
queuecommand().
</para>
</chapter>
<chapter id="changes">
<title>Changes since lk 2.4 series</title>
<para>
io_request_lock has been replaced by several finer grained locks. The lock
relevant to lower level drivers is Scsi_Host::host_lock and there is one
per scsi host.
</para>
<para>
The older error handling mechanism has been removed. This means the
lower level interface functions abort() and reset() have been removed.
</para>
<para>
In the 2.4 series the scsi subsystem configuration descriptions were
aggregated with the configuration descriptions from all other Linux
subsystems in the Documentation/Configure.help file. In the 2.5 series,
the scsi subsystem now has its own (much smaller) drivers/scsi/Config.help
file.
</para>
</chapter>
<chapter id="credits">
<title>Credits</title>
<para>
The following people have contributed to this document:
<orderedlist>
<listitem><para>
Mike Anderson <email>andmike@us.ibm.com</email>
</para></listitem>
<listitem><para>
James Bottomley <email>James.Bottomley@steeleye.com</email>
</para></listitem>
<listitem><para>
Patrick Mansfield <email>patmans@us.ibm.com</email>
</para></listitem>
</orderedlist>
</para>
</chapter>
</book>
Documentation/DocBook/stylesheet.xsl
浏览文件 @ aef7b83c
...@@ -2,4 +2,5 @@ ...@@ -2,4 +2,5 @@
<stylesheet xmlns="http://www.w3.org/1999/XSL/Transform" version="1.0"> <stylesheet xmlns="http://www.w3.org/1999/XSL/Transform" version="1.0">
<param name="chunk.quietly">1</param> <param name="chunk.quietly">1</param>
<param name="funcsynopsis.style">ansi</param> <param name="funcsynopsis.style">ansi</param>
<param name="funcsynopsis.tabular.threshold">80</param>
</stylesheet> </stylesheet>
Documentation/IPMI.txt
浏览文件 @ aef7b83c
...@@ -25,9 +25,10 @@ subject and I can't cover it all here! ...@@ -25,9 +25,10 @@ subject and I can't cover it all here!
Configuration Configuration
------------- -------------
The LinuxIPMI driver is modular, which means you have to pick several The Linux IPMI driver is modular, which means you have to pick several
things to have it work right depending on your hardware. Most of things to have it work right depending on your hardware. Most of
these are available in the 'Character Devices' menu. these are available in the 'Character Devices' menu then the IPMI
menu.
No matter what, you must pick 'IPMI top-level message handler' to use No matter what, you must pick 'IPMI top-level message handler' to use
IPMI. What you do beyond that depends on your needs and hardware. IPMI. What you do beyond that depends on your needs and hardware.
...@@ -35,33 +36,30 @@ IPMI. What you do beyond that depends on your needs and hardware. ...@@ -35,33 +36,30 @@ IPMI. What you do beyond that depends on your needs and hardware.
The message handler does not provide any user-level interfaces. The message handler does not provide any user-level interfaces.
Kernel code (like the watchdog) can still use it. If you need access Kernel code (like the watchdog) can still use it. If you need access
from userland, you need to select 'Device interface for IPMI' if you from userland, you need to select 'Device interface for IPMI' if you
want access through a device driver. Another interface is also want access through a device driver.
available, you may select 'IPMI sockets' in the 'Networking Support'
main menu. This provides a socket interface to IPMI. You may select The driver interface depends on your hardware. If your system
both of these at the same time, they will both work together. properly provides the SMBIOS info for IPMI, the driver will detect it
and just work. If you have a board with a standard interface (These
The driver interface depends on your hardware. If you have a board will generally be either "KCS", "SMIC", or "BT", consult your hardware
with a standard interface (These will generally be either "KCS", manual), choose the 'IPMI SI handler' option. A driver also exists
"SMIC", or "BT", consult your hardware manual), choose the 'IPMI SI for direct I2C access to the IPMI management controller. Some boards
handler' option. A driver also exists for direct I2C access to the support this, but it is unknown if it will work on every board. For
IPMI management controller. Some boards support this, but it is this, choose 'IPMI SMBus handler', but be ready to try to do some
unknown if it will work on every board. For this, choose 'IPMI SMBus figuring to see if it will work on your system if the SMBIOS/APCI
handler', but be ready to try to do some figuring to see if it will information is wrong or not present. It is fairly safe to have both
work. these enabled and let the drivers auto-detect what is present.
There is also a KCS-only driver interface supplied, but it is
depracated in favor of the SI interface.
You should generally enable ACPI on your system, as systems with IPMI You should generally enable ACPI on your system, as systems with IPMI
should have ACPI tables describing them. can have ACPI tables describing them.
If you have a standard interface and the board manufacturer has done If you have a standard interface and the board manufacturer has done
their job correctly, the IPMI controller should be automatically their job correctly, the IPMI controller should be automatically
detect (via ACPI or SMBIOS tables) and should just work. Sadly, many detected (via ACPI or SMBIOS tables) and should just work. Sadly,
boards do not have this information. The driver attempts standard many boards do not have this information. The driver attempts
defaults, but they may not work. If you fall into this situation, you standard defaults, but they may not work. If you fall into this
need to read the section below named 'The SI Driver' on how to situation, you need to read the section below named 'The SI Driver' or
hand-configure your system. "The SMBus Driver" on how to hand-configure your system.
IPMI defines a standard watchdog timer. You can enable this with the IPMI defines a standard watchdog timer. You can enable this with the
'IPMI Watchdog Timer' config option. If you compile the driver into 'IPMI Watchdog Timer' config option. If you compile the driver into
...@@ -73,6 +71,18 @@ closed (by default it is disabled on close). Go into the 'Watchdog ...@@ -73,6 +71,18 @@ closed (by default it is disabled on close). Go into the 'Watchdog
Cards' menu, enable 'Watchdog Timer Support', and enable the option Cards' menu, enable 'Watchdog Timer Support', and enable the option
'Disable watchdog shutdown on close'. 'Disable watchdog shutdown on close'.
IPMI systems can often be powered off using IPMI commands. Select
'IPMI Poweroff' to do this. The driver will auto-detect if the system
can be powered off by IPMI. It is safe to enable this even if your
system doesn't support this option. This works on ATCA systems, the
Radisys CPI1 card, and any IPMI system that supports standard chassis
management commands.
If you want the driver to put an event into the event log on a panic,
enable the 'Generate a panic event to all BMCs on a panic' option. If
you want the whole panic string put into the event log using OEM
events, enable the 'Generate OEM events containing the panic string'
option.
Basic Design Basic Design
------------ ------------
...@@ -80,7 +90,7 @@ Basic Design ...@@ -80,7 +90,7 @@ Basic Design
The Linux IPMI driver is designed to be very modular and flexible, you The Linux IPMI driver is designed to be very modular and flexible, you
only need to take the pieces you need and you can use it in many only need to take the pieces you need and you can use it in many
different ways. Because of that, it's broken into many chunks of different ways. Because of that, it's broken into many chunks of
code. These chunks are: code. These chunks (by module name) are:
ipmi_msghandler - This is the central piece of software for the IPMI ipmi_msghandler - This is the central piece of software for the IPMI
system. It handles all messages, message timing, and responses. The system. It handles all messages, message timing, and responses. The
...@@ -93,18 +103,26 @@ ipmi_devintf - This provides a userland IOCTL interface for the IPMI ...@@ -93,18 +103,26 @@ ipmi_devintf - This provides a userland IOCTL interface for the IPMI
driver, each open file for this device ties in to the message handler driver, each open file for this device ties in to the message handler
as an IPMI user. as an IPMI user.
ipmi_si - A driver for various system interfaces. This supports ipmi_si - A driver for various system interfaces. This supports KCS,
KCS, SMIC, and may support BT in the future. Unless you have your own SMIC, and BT interfaces. Unless you have an SMBus interface or your
custom interface, you probably need to use this. own custom interface, you probably need to use this.
ipmi_smb - A driver for accessing BMCs on the SMBus. It uses the ipmi_smb - A driver for accessing BMCs on the SMBus. It uses the
I2C kernel driver's SMBus interfaces to send and receive IPMI messages I2C kernel driver's SMBus interfaces to send and receive IPMI messages
over the SMBus. over the SMBus.
af_ipmi - A network socket interface to IPMI. This doesn't take up ipmi_watchdog - IPMI requires systems to have a very capable watchdog
a character device in your system. timer. This driver implements the standard Linux watchdog timer
interface on top of the IPMI message handler.
ipmi_poweroff - Some systems support the ability to be turned off via
IPMI commands.
Note that the KCS-only interface ahs been removed. These are all individually selectable via configuration options.
Note that the KCS-only interface has been removed. The af_ipmi driver
is no longer supported and has been removed because it was impossible
to do 32 bit emulation on 64-bit kernels with it.
Much documentation for the interface is in the include files. The Much documentation for the interface is in the include files. The
IPMI include files are: IPMI include files are:
...@@ -424,7 +442,7 @@ at module load time (for a module) with: ...@@ -424,7 +442,7 @@ at module load time (for a module) with:
modprobe ipmi_smb.o modprobe ipmi_smb.o
addr=<adapter1>,<i2caddr1>[,<adapter2>,<i2caddr2>[,...]] addr=<adapter1>,<i2caddr1>[,<adapter2>,<i2caddr2>[,...]]
dbg=<flags1>,<flags2>... dbg=<flags1>,<flags2>...
[defaultprobe=0] [dbg_probe=1] [defaultprobe=1] [dbg_probe=1]
The addresses are specified in pairs, the first is the adapter ID and the The addresses are specified in pairs, the first is the adapter ID and the
second is the I2C address on that adapter. second is the I2C address on that adapter.
...@@ -532,3 +550,67 @@ Once you open the watchdog timer, you must write a 'V' character to the ...@@ -532,3 +550,67 @@ Once you open the watchdog timer, you must write a 'V' character to the
device to close it, or the timer will not stop. This is a new semantic device to close it, or the timer will not stop. This is a new semantic
for the driver, but makes it consistent with the rest of the watchdog for the driver, but makes it consistent with the rest of the watchdog
drivers in Linux. drivers in Linux.
Panic Timeouts
--------------
The OpenIPMI driver supports the ability to put semi-custom and custom
events in the system event log if a panic occurs. if you enable the
'Generate a panic event to all BMCs on a panic' option, you will get
one event on a panic in a standard IPMI event format. If you enable
the 'Generate OEM events containing the panic string' option, you will
also get a bunch of OEM events holding the panic string.
The field settings of the events are:
* Generator ID: 0x21 (kernel)
* EvM Rev: 0x03 (this event is formatting in IPMI 1.0 format)
* Sensor Type: 0x20 (OS critical stop sensor)
* Sensor #: The first byte of the panic string (0 if no panic string)
* Event Dir | Event Type: 0x6f (Assertion, sensor-specific event info)
* Event Data 1: 0xa1 (Runtime stop in OEM bytes 2 and 3)
* Event data 2: second byte of panic string
* Event data 3: third byte of panic string
See the IPMI spec for the details of the event layout. This event is
always sent to the local management controller. It will handle routing
the message to the right place
Other OEM events have the following format:
Record ID (bytes 0-1): Set by the SEL.
Record type (byte 2): 0xf0 (OEM non-timestamped)
byte 3: The slave address of the card saving the panic
byte 4: A sequence number (starting at zero)
The rest of the bytes (11 bytes) are the panic string. If the panic string
is longer than 11 bytes, multiple messages will be sent with increasing
sequence numbers.
Because you cannot send OEM events using the standard interface, this
function will attempt to find an SEL and add the events there. It
will first query the capabilities of the local management controller.
If it has an SEL, then they will be stored in the SEL of the local
management controller. If not, and the local management controller is
an event generator, the event receiver from the local management
controller will be queried and the events sent to the SEL on that
device. Otherwise, the events go nowhere since there is nowhere to
send them.
Poweroff
--------
If the poweroff capability is selected, the IPMI driver will install
a shutdown function into the standard poweroff function pointer. This
is in the ipmi_poweroff module. When the system requests a powerdown,
it will send the proper IPMI commands to do this. This is supported on
several platforms.
There is a module parameter named "poweroff_control" that may either be zero
(do a power down) or 2 (do a power cycle, power the system off, then power
it on in a few seconds). Setting ipmi_poweroff.poweroff_control=x will do
the same thing on the kernel command line. The parameter is also available
via the proc filesystem in /proc/ipmi/poweroff_control. Note that if the
system does not support power cycling, it will always to the power off.
Note that if you have ACPI enabled, the system will prefer using ACPI to
power off.
Documentation/SubmittingPatches
浏览文件 @ aef7b83c
...@@ -132,21 +132,6 @@ which require discussion or do not have a clear advantage should ...@@ -132,21 +132,6 @@ which require discussion or do not have a clear advantage should
usually be sent first to linux-kernel. Only after the patch is usually be sent first to linux-kernel. Only after the patch is
discussed should the patch then be submitted to Linus. discussed should the patch then be submitted to Linus.
For small patches you may want to CC the Trivial Patch Monkey
trivial@rustcorp.com.au set up by Rusty Russell; which collects "trivial"
patches. Trivial patches must qualify for one of the following rules:
Spelling fixes in documentation
Spelling fixes which could break grep(1).
Warning fixes (cluttering with useless warnings is bad)
Compilation fixes (only if they are actually correct)
Runtime fixes (only if they actually fix things)
Removing use of deprecated functions/macros (eg. check_region).
Contact detail and documentation fixes
Non-portable code replaced by portable code (even in arch-specific,
since people copy, as long as it's trivial)
Any fix by the author/maintainer of the file. (ie. patch monkey
in re-transmission mode)
5) Select your CC (e-mail carbon copy) list. 5) Select your CC (e-mail carbon copy) list.
...@@ -271,7 +256,7 @@ patch, which certifies that you wrote it or otherwise have the right to ...@@ -271,7 +256,7 @@ patch, which certifies that you wrote it or otherwise have the right to
pass it on as a open-source patch. The rules are pretty simple: if you pass it on as a open-source patch. The rules are pretty simple: if you
can certify the below: can certify the below:
Developer's Certificate of Origin 1.0 Developer's Certificate of Origin 1.1
By making a contribution to this project, I certify that: By making a contribution to this project, I certify that:
...@@ -291,9 +276,15 @@ can certify the below: ...@@ -291,9 +276,15 @@ can certify the below:
person who certified (a), (b) or (c) and I have not modified person who certified (a), (b) or (c) and I have not modified
it. it.
(d) I understand and agree that this project and the contribution
are public and that a record of the contribution (including all
personal information I submit with it, including my sign-off) is
maintained indefinitely and may be redistributed consistent with
this project or the open source license(s) involved.
then you just add a line saying then you just add a line saying
Signed-off-by: Random J Developer <random@developer.org> Signed-off-by: Random J Developer <random@developer.example.org>
Some people also put extra tags at the end. They'll just be ignored for Some people also put extra tags at the end. They'll just be ignored for
now, but you can do this to mark internal company procedures or just now, but you can do this to mark internal company procedures or just
......
Documentation/basic_profiling.txt
浏览文件 @ aef7b83c
...@@ -27,9 +27,13 @@ dump output readprofile -m /boot/System.map > captured_profile ...@@ -27,9 +27,13 @@ dump output readprofile -m /boot/System.map > captured_profile
Oprofile Oprofile
-------- --------
Get the source (I use 0.8) from http://oprofile.sourceforge.net/
and add "idle=poll" to the kernel command line Get the source (see Changes for required version) from
http://oprofile.sourceforge.net/ and add "idle=poll" to the kernel command
line.
Configure with CONFIG_PROFILING=y and CONFIG_OPROFILE=y & reboot on new kernel Configure with CONFIG_PROFILING=y and CONFIG_OPROFILE=y & reboot on new kernel
./configure --with-kernel-support ./configure --with-kernel-support
make install make install
...@@ -46,7 +50,7 @@ start opcontrol --start ...@@ -46,7 +50,7 @@ start opcontrol --start
stop opcontrol --stop stop opcontrol --stop
dump output opreport > output_file dump output opreport > output_file
To only report on the kernel, run opreport /boot/vmlinux > output_file To only report on the kernel, run opreport -l /boot/vmlinux > output_file
A reset is needed to clear old statistics, which survive a reboot. A reset is needed to clear old statistics, which survive a reboot.
Documentation/cdrom/sbpcd
浏览文件 @ aef7b83c
...@@ -419,6 +419,7 @@ into the file "track01": ...@@ -419,6 +419,7 @@ into the file "track01":
*/ */
#include <stdio.h> #include <stdio.h>
#include <sys/ioctl.h> #include <sys/ioctl.h>
#include <sys/types.h>
#include <linux/cdrom.h> #include <linux/cdrom.h>
static struct cdrom_tochdr hdr; static struct cdrom_tochdr hdr;
...@@ -429,7 +430,7 @@ static int datafile, drive; ...@@ -429,7 +430,7 @@ static int datafile, drive;
static int i, j, limit, track, err; static int i, j, limit, track, err;
static char filename[32]; static char filename[32];
main(int argc, char *argv[]) int main(int argc, char *argv[])
{ {
/* /*
* open /dev/cdrom * open /dev/cdrom
...@@ -516,6 +517,7 @@ entry[track+1].cdte_addr.lba=entry[track].cdte_addr.lba+300; ...@@ -516,6 +517,7 @@ entry[track+1].cdte_addr.lba=entry[track].cdte_addr.lba+300;
} }
arg.addr.lba++; arg.addr.lba++;
} }
return 0;
} }
/*===================== end program ========================================*/ /*===================== end program ========================================*/
...@@ -564,15 +566,16 @@ Appendix -- the "cdtester" utility: ...@@ -564,15 +566,16 @@ Appendix -- the "cdtester" utility:
#include <stdio.h> #include <stdio.h>
#include <malloc.h> #include <malloc.h>
#include <sys/ioctl.h> #include <sys/ioctl.h>
#include <sys/types.h>
#include <linux/cdrom.h> #include <linux/cdrom.h>
#ifdef AZT_PRIVATE_IOCTLS #ifdef AZT_PRIVATE_IOCTLS
#include <linux/../../drivers/cdrom/aztcd.h> #include <linux/../../drivers/cdrom/aztcd.h>
#endif AZT_PRIVATE_IOCTLS #endif /* AZT_PRIVATE_IOCTLS */
#ifdef SBP_PRIVATE_IOCTLS #ifdef SBP_PRIVATE_IOCTLS
#include <linux/../../drivers/cdrom/sbpcd.h> #include <linux/../../drivers/cdrom/sbpcd.h>
#include <linux/fs.h> #include <linux/fs.h>
#endif SBP_PRIVATE_IOCTLS #endif /* SBP_PRIVATE_IOCTLS */
struct cdrom_tochdr hdr; struct cdrom_tochdr hdr;
struct cdrom_tochdr tocHdr; struct cdrom_tochdr tocHdr;
...@@ -590,7 +593,7 @@ union ...@@ -590,7 +593,7 @@ union
struct cdrom_msf msf; struct cdrom_msf msf;
unsigned char buf[CD_FRAMESIZE_RAW]; unsigned char buf[CD_FRAMESIZE_RAW];
} azt; } azt;
#endif AZT_PRIVATE_IOCTLS #endif /* AZT_PRIVATE_IOCTLS */
int i, i1, i2, i3, j, k; int i, i1, i2, i3, j, k;
unsigned char sequence=0; unsigned char sequence=0;
unsigned char command[80]; unsigned char command[80];
...@@ -738,7 +741,7 @@ void display(int size,unsigned char *buffer) ...@@ -738,7 +741,7 @@ void display(int size,unsigned char *buffer)
} }
} }
main(int argc, char *argv[]) int main(int argc, char *argv[])
{ {
printf("\nTesting tool for a CDROM driver's audio functions V0.1\n"); printf("\nTesting tool for a CDROM driver's audio functions V0.1\n");
printf("(C) 1995 Eberhard Moenkeberg <emoenke@gwdg.de>\n"); printf("(C) 1995 Eberhard Moenkeberg <emoenke@gwdg.de>\n");
...@@ -1046,12 +1049,13 @@ main(int argc, char *argv[]) ...@@ -1046,12 +1049,13 @@ main(int argc, char *argv[])
rc=ioctl(drive,CDROMAUDIOBUFSIZ,j); rc=ioctl(drive,CDROMAUDIOBUFSIZ,j);
printf("%d frames granted.\n",rc); printf("%d frames granted.\n",rc);
break; break;
#endif SBP_PRIVATE_IOCTLS #endif /* SBP_PRIVATE_IOCTLS */
default: default:
printf("unknown command: \"%s\".\n",command); printf("unknown command: \"%s\".\n",command);
break; break;
} }
} }
return 0;
} }
/*==========================================================================*/ /*==========================================================================*/
Documentation/cpu-freq/cpufreq-stats.txt 0 → 100644
浏览文件 @ aef7b83c
CPU frequency and voltage scaling statictics in the Linux(TM) kernel
L i n u x c p u f r e q - s t a t s d r i v e r
- information for users -
Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
Contents
1. Introduction
2. Statistics Provided (with example)
3. Configuring cpufreq-stats
1. Introduction
cpufreq-stats is a driver that provices CPU frequency statistics for each CPU.
This statistics is provided in /sysfs as a bunch of read_only interfaces. This
interface (when configured) will appear in a seperate directory under cpufreq
in /sysfs (<sysfs root>/devices/system/cpu/cpuX/cpufreq/stats/) for each CPU.
Various statistics will form read_only files under this directory.
This driver is designed to be independent of any particular cpufreq_driver
that may be running on your CPU. So, it will work with any cpufreq_driver.
2. Statistics Provided (with example)
cpufreq stats provides following statistics (explained in detail below).
- time_in_state
- total_trans
- trans_table
All the statistics will be from the time the stats driver has been inserted
to the time when a read of a particular statistic is done. Obviously, stats
driver will not have any information about the the frequcny transitions before
the stats driver insertion.
--------------------------------------------------------------------------------
<mysystem>:/sys/devices/system/cpu/cpu0/cpufreq/stats # ls -l
total 0
drwxr-xr-x 2 root root 0 May 14 16:06 .
drwxr-xr-x 3 root root 0 May 14 15:58 ..
-r--r--r-- 1 root root 4096 May 14 16:06 time_in_state
-r--r--r-- 1 root root 4096 May 14 16:06 total_trans
-r--r--r-- 1 root root 4096 May 14 16:06 trans_table
--------------------------------------------------------------------------------
- time_in_state
This gives the amount of time spent in each of the frequencies supported by
this CPU. The cat output will have "<frequency> <time>" pair in each line, which
will mean this CPU spent <time> usertime units of time at <frequency>. Output
will have one line for each of the supported freuencies. usertime units here
is 10mS (similar to other time exported in /proc).
--------------------------------------------------------------------------------
<mysystem>:/sys/devices/system/cpu/cpu0/cpufreq/stats # cat time_in_state
3600000 2089
3400000 136
3200000 34
3000000 67
2800000 172488
--------------------------------------------------------------------------------
- total_trans
This gives the total number of frequency transitions on this CPU. The cat
output will have a single count which is the total number of frequency
transitions.
--------------------------------------------------------------------------------
<mysystem>:/sys/devices/system/cpu/cpu0/cpufreq/stats # cat total_trans
20
--------------------------------------------------------------------------------
- trans_table
This will give a fine grained information about all the CPU frequency
transitions. The cat output here is a two dimensional matrix, where an entry
<i,j> (row i, column j) represents the count of number of transitions from
Freq_i to Freq_j. Freq_i is in descending order with increasing rows and
Freq_j is in descending order with increasing columns. The output here also
contains the actual freq values for each row and column for better readability.
--------------------------------------------------------------------------------
<mysystem>:/sys/devices/system/cpu/cpu0/cpufreq/stats # cat trans_table
From : To
: 3600000 3400000 3200000 3000000 2800000
3600000: 0 5 0 0 0
3400000: 4 0 2 0 0
3200000: 0 1 0 2 0
3000000: 0 0 1 0 3
2800000: 0 0 0 2 0
--------------------------------------------------------------------------------
3. Configuring cpufreq-stats
To configure cpufreq-stats in your kernel
Config Main Menu
Power management options (ACPI, APM) --->
CPU Frequency scaling --->
[*] CPU Frequency scaling
<*> CPU frequency translation statistics
[*] CPU frequency translation statistics details
"CPU Frequency scaling" (CONFIG_CPU_FREQ) should be enabled to configure
cpufreq-stats.
"CPU frequency translation statistics" (CONFIG_CPU_FREQ_STAT) provides the
basic statistics which includes time_in_state and total_trans.
"CPU frequency translation statistics details" (CONFIG_CPU_FREQ_STAT_DETAILS)
provides fine grained cpufreq stats by trans_table. The reason for having a
seperate config option for trans_table is:
- trans_table goes against the traditional /sysfs rule of one value per
interface. It provides a whole bunch of value in a 2 dimensional matrix
form.
Once these two options are enabled and your CPU supports cpufrequency, you
will be able to see the CPU frequency statistics in /sysfs.
Documentation/cpu-freq/governors.txt
浏览文件 @ aef7b83c
...@@ -9,6 +9,7 @@ ...@@ -9,6 +9,7 @@
Dominik Brodowski <linux@brodo.de> Dominik Brodowski <linux@brodo.de>
some additions and corrections by Nico Golde <nico@ngolde.de>
...@@ -25,6 +26,7 @@ Contents: ...@@ -25,6 +26,7 @@ Contents:
2.1 Performance 2.1 Performance
2.2 Powersave 2.2 Powersave
2.3 Userspace 2.3 Userspace
2.4 Ondemand
3. The Governor Interface in the CPUfreq Core 3. The Governor Interface in the CPUfreq Core
...@@ -86,7 +88,7 @@ highest frequency within the borders of scaling_min_freq and ...@@ -86,7 +88,7 @@ highest frequency within the borders of scaling_min_freq and
scaling_max_freq. scaling_max_freq.
2.1 Powersave 2.2 Powersave
------------- -------------
The CPUfreq governor "powersave" sets the CPU statically to the The CPUfreq governor "powersave" sets the CPU statically to the
...@@ -94,7 +96,7 @@ lowest frequency within the borders of scaling_min_freq and ...@@ -94,7 +96,7 @@ lowest frequency within the borders of scaling_min_freq and
scaling_max_freq. scaling_max_freq.
2.2 Userspace 2.3 Userspace
------------- -------------
The CPUfreq governor "userspace" allows the user, or any userspace The CPUfreq governor "userspace" allows the user, or any userspace
...@@ -103,6 +105,14 @@ by making a sysfs file "scaling_setspeed" available in the CPU-device ...@@ -103,6 +105,14 @@ by making a sysfs file "scaling_setspeed" available in the CPU-device
directory. directory.
2.4 Ondemand
------------
The CPUfreq govenor "ondemand" sets the CPU depending on the
current usage. To do this the CPU must have the capability to
switch the frequency very fast.
3. The Governor Interface in the CPUfreq Core 3. The Governor Interface in the CPUfreq Core
============================================= =============================================
......
Documentation/cpusets.txt
浏览文件 @ aef7b83c
...@@ -51,6 +51,14 @@ mems_allowed vector. ...@@ -51,6 +51,14 @@ mems_allowed vector.
If a cpuset is cpu or mem exclusive, no other cpuset, other than a direct If a cpuset is cpu or mem exclusive, no other cpuset, other than a direct
ancestor or descendent, may share any of the same CPUs or Memory Nodes. ancestor or descendent, may share any of the same CPUs or Memory Nodes.
A cpuset that is cpu exclusive has a sched domain associated with it.
The sched domain consists of all cpus in the current cpuset that are not
part of any exclusive child cpusets.
This ensures that the scheduler load balacing code only balances
against the cpus that are in the sched domain as defined above and not
all of the cpus in the system. This removes any overhead due to
load balancing code trying to pull tasks outside of the cpu exclusive
cpuset only to be prevented by the tasks' cpus_allowed mask.
User level code may create and destroy cpusets by name in the cpuset User level code may create and destroy cpusets by name in the cpuset
virtual file system, manage the attributes and permissions of these virtual file system, manage the attributes and permissions of these
...@@ -84,6 +92,9 @@ This can be especially valuable on: ...@@ -84,6 +92,9 @@ This can be especially valuable on:
and a database), or and a database), or
* NUMA systems running large HPC applications with demanding * NUMA systems running large HPC applications with demanding
performance characteristics. performance characteristics.
* Also cpu_exclusive cpusets are useful for servers running orthogonal
workloads such as RT applications requiring low latency and HPC
applications that are throughput sensitive
These subsets, or "soft partitions" must be able to be dynamically These subsets, or "soft partitions" must be able to be dynamically
adjusted, as the job mix changes, without impacting other concurrently adjusted, as the job mix changes, without impacting other concurrently
...@@ -125,6 +136,8 @@ Cpusets extends these two mechanisms as follows: ...@@ -125,6 +136,8 @@ Cpusets extends these two mechanisms as follows:
- A cpuset may be marked exclusive, which ensures that no other - A cpuset may be marked exclusive, which ensures that no other
cpuset (except direct ancestors and descendents) may contain cpuset (except direct ancestors and descendents) may contain
any overlapping CPUs or Memory Nodes. any overlapping CPUs or Memory Nodes.
Also a cpu_exclusive cpuset would be associated with a sched
domain.
- You can list all the tasks (by pid) attached to any cpuset. - You can list all the tasks (by pid) attached to any cpuset.
The implementation of cpusets requires a few, simple hooks The implementation of cpusets requires a few, simple hooks
...@@ -136,6 +149,9 @@ into the rest of the kernel, none in performance critical paths: ...@@ -136,6 +149,9 @@ into the rest of the kernel, none in performance critical paths:
allowed in that tasks cpuset. allowed in that tasks cpuset.
- in sched.c migrate_all_tasks(), to keep migrating tasks within - in sched.c migrate_all_tasks(), to keep migrating tasks within
the CPUs allowed by their cpuset, if possible. the CPUs allowed by their cpuset, if possible.
- in sched.c, a new API partition_sched_domains for handling
sched domain changes associated with cpu_exclusive cpusets
and related changes in both sched.c and arch/ia64/kernel/domain.c
- in the mbind and set_mempolicy system calls, to mask the requested - in the mbind and set_mempolicy system calls, to mask the requested
Memory Nodes by what's allowed in that tasks cpuset. Memory Nodes by what's allowed in that tasks cpuset.
- in page_alloc, to restrict memory to allowed nodes. - in page_alloc, to restrict memory to allowed nodes.
...@@ -252,8 +268,7 @@ in a tasks processor placement. ...@@ -252,8 +268,7 @@ in a tasks processor placement.
There is an exception to the above. If hotplug funtionality is used There is an exception to the above. If hotplug funtionality is used
to remove all the CPUs that are currently assigned to a cpuset, to remove all the CPUs that are currently assigned to a cpuset,
then the kernel will automatically update the cpus_allowed of all then the kernel will automatically update the cpus_allowed of all
tasks attached to CPUs in that cpuset with the online CPUs of the tasks attached to CPUs in that cpuset to allow all CPUs. When memory
nearest parent cpuset that still has some CPUs online. When memory
hotplug functionality for removing Memory Nodes is available, a hotplug functionality for removing Memory Nodes is available, a
similar exception is expected to apply there as well. In general, similar exception is expected to apply there as well. In general,
the kernel prefers to violate cpuset placement, over starving a task the kernel prefers to violate cpuset placement, over starving a task
......
Documentation/devices.txt
浏览文件 @ aef7b83c
...@@ -94,6 +94,7 @@ Your cooperation is appreciated. ...@@ -94,6 +94,7 @@ Your cooperation is appreciated.
9 = /dev/urandom Faster, less secure random number gen. 9 = /dev/urandom Faster, less secure random number gen.
10 = /dev/aio Asyncronous I/O notification interface 10 = /dev/aio Asyncronous I/O notification interface
11 = /dev/kmsg Writes to this come out as printk's 11 = /dev/kmsg Writes to this come out as printk's
12 = /dev/oldmem Access to crash dump from kexec kernel
1 block RAM disk 1 block RAM disk
0 = /dev/ram0 First RAM disk 0 = /dev/ram0 First RAM disk
1 = /dev/ram1 Second RAM disk 1 = /dev/ram1 Second RAM disk
......
Documentation/dontdiff
浏览文件 @ aef7b83c
...@@ -111,6 +111,7 @@ mkdep ...@@ -111,6 +111,7 @@ mkdep
mktables mktables
modpost modpost
modversions.h* modversions.h*
offset.h
offsets.h offsets.h
oui.c* oui.c*
parse.c* parse.c*
......
Documentation/driver-model/device.txt
浏览文件 @ aef7b83c
...@@ -76,6 +76,14 @@ driver_data: Driver-specific data. ...@@ -76,6 +76,14 @@ driver_data: Driver-specific data.
platform_data: Platform data specific to the device. platform_data: Platform data specific to the device.
Example: for devices on custom boards, as typical of embedded
and SOC based hardware, Linux often uses platform_data to point
to board-specific structures describing devices and how they
are wired. That can include what ports are available, chip
variants, which GPIO pins act in what additional roles, and so
on. This shrinks the "Board Support Packages" (BSPs) and
minimizes board-specific #ifdefs in drivers.
current_state: Current power state of the device. current_state: Current power state of the device.
saved_state: Pointer to saved state of the device. This is usable by saved_state: Pointer to saved state of the device. This is usable by
......
Documentation/driver-model/driver.txt
浏览文件 @ aef7b83c
...@@ -5,21 +5,17 @@ struct device_driver { ...@@ -5,21 +5,17 @@ struct device_driver {
char * name; char * name;
struct bus_type * bus; struct bus_type * bus;
rwlock_t lock; struct completion unloaded;
atomic_t refcount; struct kobject kobj;
list_t bus_list;
list_t devices; list_t devices;
struct driver_dir_entry dir; struct module *owner;
int (*probe) (struct device * dev); int (*probe) (struct device * dev);
int (*remove) (struct device * dev); int (*remove) (struct device * dev);
int (*suspend) (struct device * dev, pm_message_t state, u32 level); int (*suspend) (struct device * dev, pm_message_t state, u32 level);
int (*resume) (struct device * dev, u32 level); int (*resume) (struct device * dev, u32 level);
void (*release) (struct device_driver * drv);
}; };
...@@ -51,7 +47,6 @@ being converted completely to the new model. ...@@ -51,7 +47,6 @@ being converted completely to the new model.
static struct device_driver eepro100_driver = { static struct device_driver eepro100_driver = {
.name = "eepro100", .name = "eepro100",
.bus = &pci_bus_type, .bus = &pci_bus_type,
.devclass = &ethernet_devclass, /* when it's implemented */
.probe = eepro100_probe, .probe = eepro100_probe,
.remove = eepro100_remove, .remove = eepro100_remove,
...@@ -85,7 +80,6 @@ static struct pci_driver eepro100_driver = { ...@@ -85,7 +80,6 @@ static struct pci_driver eepro100_driver = {
.driver = { .driver = {
.name = "eepro100", .name = "eepro100",
.bus = &pci_bus_type, .bus = &pci_bus_type,
.devclass = &ethernet_devclass, /* when it's implemented */
.probe = eepro100_probe, .probe = eepro100_probe,
.remove = eepro100_remove, .remove = eepro100_remove,
.suspend = eepro100_suspend, .suspend = eepro100_suspend,
...@@ -166,27 +160,32 @@ Callbacks ...@@ -166,27 +160,32 @@ Callbacks
int (*probe) (struct device * dev); int (*probe) (struct device * dev);
probe is called to verify the existence of a certain type of The probe() entry is called in task context, with the bus's rwsem locked
hardware. This is called during the driver binding process, after the and the driver partially bound to the device. Drivers commonly use
bus has verified that the device ID of a device matches one of the container_of() to convert "dev" to a bus-specific type, both in probe()
device IDs supported by the driver. and other routines. That type often provides device resource data, such
as pci_dev.resource[] or platform_device.resources, which is used in
This callback only verifies that there actually is supported hardware addition to dev->platform_data to initialize the driver.
present. It may allocate a driver-specific structure, but it should
not do any initialization of the hardware itself. The device-specific This callback holds the driver-specific logic to bind the driver to a
structure may be stored in the device's driver_data field. given device. That includes verifying that the device is present, that
it's a version the driver can handle, that driver data structures can
int (*init) (struct device * dev); be allocated and initialized, and that any hardware can be initialized.
Drivers often store a pointer to their state with dev_set_drvdata().
init is called during the binding stage. It is called after probe has When the driver has successfully bound itself to that device, then probe()
successfully returned and the device has been registered with its returns zero and the driver model code will finish its part of binding
class. It is responsible for initializing the hardware. the driver to that device.
A driver's probe() may return a negative errno value to indicate that
the driver did not bind to this device, in which case it should have
released all reasources it allocated.
int (*remove) (struct device * dev); int (*remove) (struct device * dev);
remove is called to dissociate a driver with a device. This may be remove is called to unbind a driver from a device. This may be
called if a device is physically removed from the system, if the called if a device is physically removed from the system, if the
driver module is being unloaded, or during a reboot sequence. driver module is being unloaded, during a reboot sequence, or
in other cases.
It is up to the driver to determine if the device is present or It is up to the driver to determine if the device is present or
not. It should free any resources allocated specifically for the not. It should free any resources allocated specifically for the
......
Documentation/dvb/README.dibusb → Documentation/dvb/README.dvb-usb
浏览文件 @ aef7b83c
Documentation for dib3000* frontend drivers and dibusb device driver Documentation for dvb-usb-framework module and its devices
====================================================================
Copyright (C) 2004-5 Patrick Boettcher (patrick.boettcher@desy.de), Idea behind the dvb-usb-framework
=================================
dibusb and dib3000mb/mc drivers based on GPL code, which has In March 2005 I got the new Twinhan USB2.0 DVB-T device. They provided specs and a firmware.
Copyright (C) 2004 Amaury Demol for DiBcom (ademol@dibcom.fr) Quite keen I wanted to put the driver (with some quirks of course) into dibusb.
After reading some specs and doing some USB snooping, it realized, that the
dibusb-driver would be a complete mess afterwards. So I decided to do it in a
different way: With the help of a dvb-usb-framework.
This program is free software; you can redistribute it and/or The framework provides generic functions (mostly kernel API calls), such as:
modify it under the terms of the GNU General Public License as
published by the Free Software Foundation, version 2.
- Transport Stream URB handling in conjunction with dvb-demux-feed-control
(bulk and isoc (TODO) are supported)
- registering the device for the DVB-API
- registering an I2C-adapter if applicable
- remote-control/input-device handling
- firmware requesting and loading (currently just for the Cypress USB
controller)
- other functions/methods which can be shared by several drivers (such as
functions for bulk-control-commands)
The source code of the particular DVB USB devices does just the communication
with the device via the bus. The connection between the DVB-API-functionality
is done via callbacks, assigned in a static device-description (struct
dvb_usb_device) each device-driver has to have.
For an example have a look in drivers/media/dvb/dvb-usb/vp7045*.
Objective is to migrate all the usb-devices (dibusb, cinergyT2, maybe the
ttusb; flexcop-usb already benefits from the generic flexcop-device) to use
the dvb-usb-lib.
TODO: dynamic enabling and disabling of the pid-filter in regard to number of
feeds requested.
Supported devices USB1.1 Supported devices USB1.1
======================== ========================
...@@ -55,22 +79,34 @@ Others: ...@@ -55,22 +79,34 @@ Others:
- Grandtec USB DVB-T - Grandtec USB DVB-T
http://www.grand.com.tw/ http://www.grand.com.tw/
- Avermedia AverTV DVBT USB (2) - AVerMedia AverTV DVBT USB
http://www.avermedia.com/ http://www.avermedia.com/
- DiBcom USB DVB-T reference device (non-public) - DiBcom USB DVB-T reference device (non-public)
Supported devices USB2.0 Supported devices USB2.0-only
======================== =============================
- Twinhan MagicBox II (2) - Twinhan MagicBox II
http://www.twinhan.com/product_terrestrial_7.asp http://www.twinhan.com/product_terrestrial_7.asp
- Hanftek UMT-010 (1) - TwinhanDTV Alpha
http://www.twinhan.com/product_terrestrial_8.asp
- DigitalNow TinyUSB 2 DVB-t Receiver
http://www.digitalnow.com.au/DigitalNow%20tinyUSB2%20Specifications.html
- Hanftek UMT-010
http://www.globalsources.com/si/6008819757082/ProductDetail/Digital-TV/product_id-100046529 http://www.globalsources.com/si/6008819757082/ProductDetail/Digital-TV/product_id-100046529
- Typhoon/Yakumo/HAMA DVB-T mobile USB2.0 (1)
Supported devices USB2.0 and USB1.1
=============================
- Typhoon/Yakumo/HAMA/Yuan DVB-T mobile USB2.0
http://www.yakumo.de/produkte/index.php?pid=1&ag=DVB-T http://www.yakumo.de/produkte/index.php?pid=1&ag=DVB-T
http://www.yuan.com.tw/en/products/vdo_ub300.html
http://www.hama.de/portal/articleId*114663/action*2563
http://www.anubisline.com/english/articlec.asp?id=50502&catid=002
- Artec T1 USB TVBOX (FX2) (2) - Artec T1 USB TVBOX (FX2) (2)
...@@ -81,14 +117,24 @@ Supported devices USB2.0 ...@@ -81,14 +117,24 @@ Supported devices USB2.0
- DiBcom USB2.0 DVB-T reference device (non-public) - DiBcom USB2.0 DVB-T reference device (non-public)
1) It is working almost. - AVerMedia AverTV A800 DVB-T USB2.0
1) It is working almost - work-in-progress.
2) No test reports received yet. 2) No test reports received yet.
0. History & News:
2005-04-17 - all dibusb devices ported to make use of the dvb-usb-framework
2005-04-02 - re-enabled and improved remote control code.
2005-03-31 - ported the Yakumo/Hama/Typhoon DVB-T USB2.0 device to dvb-usb.
2005-03-30 - first commit of the dvb-usb-module based on the dibusb-source. First device is a new driver for the
TwinhanDTV Alpha / MagicBox II USB2.0-only DVB-T device.
0. NEWS: (change from dvb-dibusb to dvb-usb)
2005-03-28 - added support for the AVerMedia AverTV DVB-T USB2.0 device (Thanks to Glen Harris and Jiun-Kuei Jung, AVerMedia)
2005-03-14 - added support for the Typhoon/Yakumo/HAMA DVB-T mobile USB2.0
2005-02-11 - added support for the KWorld/ADSTech Instant DVB-T USB2.0. Thanks a lot to Joachim von Caron 2005-02-11 - added support for the KWorld/ADSTech Instant DVB-T USB2.0. Thanks a lot to Joachim von Caron
2005-02-02 - added support for the Hauppauge Win-TV Nova-T USB2 2005-02-02 - added support for the Hauppauge Win-TV Nova-T USB2
2005-01-31 - distorted streaming is finally gone for USB1.1 devices 2005-01-31 - distorted streaming is gone for USB1.1 devices
2005-01-13 - moved the mirrored pid_filter_table back to dvb-dibusb 2005-01-13 - moved the mirrored pid_filter_table back to dvb-dibusb
- first almost working version for HanfTek UMT-010 - first almost working version for HanfTek UMT-010
- found out, that Yakumo/HAMA/Typhoon are predessors of the HanfTek UMT-010 - found out, that Yakumo/HAMA/Typhoon are predessors of the HanfTek UMT-010
...@@ -99,7 +145,7 @@ Supported devices USB2.0 ...@@ -99,7 +145,7 @@ Supported devices USB2.0
2004-12-26 - refactored the dibusb-driver, splitted into separate files 2004-12-26 - refactored the dibusb-driver, splitted into separate files
- i2c-probing enabled - i2c-probing enabled
2004-12-06 - possibility for demod i2c-address probing 2004-12-06 - possibility for demod i2c-address probing
- new usb IDs (Compro,Artec) - new usb IDs (Compro, Artec)
2004-11-23 - merged changes from DiB3000MC_ver2.1 2004-11-23 - merged changes from DiB3000MC_ver2.1
- revised the debugging - revised the debugging
- possibility to deliver the complete TS for USB2.0 - possibility to deliver the complete TS for USB2.0
...@@ -127,8 +173,8 @@ Supported devices USB2.0 ...@@ -127,8 +173,8 @@ Supported devices USB2.0
CTS Portable (Chinese Television System) CTS Portable (Chinese Television System)
2004-07-08 - firmware-extraction-2.422-problem solved, driver is now working 2004-07-08 - firmware-extraction-2.422-problem solved, driver is now working
properly with firmware extracted from 2.422 properly with firmware extracted from 2.422
- #if for 2.6.4 (dvb), compile issue - #if for 2.6.4 (dvb), compile issue
- changed firmware handling, see vp7041.txt sec 1.1 - changed firmware handling, see vp7041.txt sec 1.1
2004-07-02 - some tuner modifications, v0.1, cleanups, first public 2004-07-02 - some tuner modifications, v0.1, cleanups, first public
2004-06-28 - now using the dvb_dmx_swfilter_packets, everything 2004-06-28 - now using the dvb_dmx_swfilter_packets, everything
runs fine now runs fine now
...@@ -139,38 +185,27 @@ Supported devices USB2.0 ...@@ -139,38 +185,27 @@ Supported devices USB2.0
2004-05-11 - start writing the driver 2004-05-11 - start writing the driver
1. How to use? 1. How to use?
NOTE: This driver was developed using Linux 2.6.6.,
it is working with 2.6.7 and above.
Linux 2.4.x support is not planned, but patches are very welcome.
NOTE: I'm using Debian testing, so the following explaination (especially
the hotplug-path) needn't match your system, but probably it will :).
The driver is included in the kernel since Linux 2.6.10.
1.1. Firmware 1.1. Firmware
The USB driver needs to download a firmware to start working. Most of the USB drivers need to download a firmware to start working.
You can either use "get_dvb_firmware dibusb" to download the firmware or you
can get it directly via
for USB1.1 (AN2135) for USB1.1 (AN2135) you need: dvb-usb-dibusb-5.0.0.11.fw
http://www.linuxtv.org/downloads/firmware/dvb-dibusb-5.0.0.11.fw for USB2.0 HanfTek: dvb-usb-umt-010-02.fw
for USB2.0 DiBcom: dvb-usb-dibusb-6.0.0.8.fw
for USB2.0 AVerMedia AverTV DVB-T USB2: dvb-usb-avertv-a800-01.fw
for USB2.0 TwinhanDTV Alpha/MagicBox II: dvb-usb-vp7045-01.fw
for USB1.1 (AN2235) (a few Artec T1 devices) The files can be found on http://www.linuxtv.org/download/firmware/ .
http://www.linuxtv.org/downloads/firmware/dvb-dibusb-an2235-1.fw
for USB2.0 (FX2) Hauppauge, DiBcom We do not have the permission (yet) to publish the following firmware-files.
http://www.linuxtv.org/downloads/firmware/dvb-dibusb-6.0.0.5.fw You'll need to extract them from the windows drivers.
for USB2.0 ADSTech/Kworld USB2.0 You should be able to use "get_dvb_firmware dvb-usb" to get the firmware:
http://www.linuxtv.org/downloads/firmware/dvb-dibusb-adstech-usb2-1.fw
for USB2.0 HanfTek
http://www.linuxtv.org/downloads/firmware/dvb-dibusb-an2235-1.fw
for USB1.1 (AN2235) (a few Artec T1 devices): dvb-usb-dibusb-an2235-01.fw
for USB2.0 Hauppauge: dvb-usb-nova-t-usb2-01.fw
for USB2.0 ADSTech/Kworld USB2.0: dvb-usb-adstech-usb2-01.fw
for USB2.0 Yakumo/Typhoon/Hama: dvb-usb-dtt200u-01.fw
1.2. Compiling 1.2. Compiling
...@@ -178,6 +213,9 @@ Since the driver is in the linux kernel, activating the driver in ...@@ -178,6 +213,9 @@ Since the driver is in the linux kernel, activating the driver in
your favorite config-environment should sufficient. I recommend your favorite config-environment should sufficient. I recommend
to compile the driver as module. Hotplug does the rest. to compile the driver as module. Hotplug does the rest.
If you use dvb-kernel enter the build-2.6 directory run 'make' and 'insmod.sh
load' afterwards.
1.3. Loading the drivers 1.3. Loading the drivers
Hotplug is able to load the driver, when it is needed (because you plugged Hotplug is able to load the driver, when it is needed (because you plugged
...@@ -188,15 +226,13 @@ from withing the dvb-kernel cvs repository. ...@@ -188,15 +226,13 @@ from withing the dvb-kernel cvs repository.
first have a look, which debug level are available: first have a look, which debug level are available:
modinfo dib3000mb modinfo dvb-usb
modinfo dib3000-common modinfo dvb-usb-vp7045
modinfo dib3000mc etc.
modinfo dvb-dibusb
modprobe dib3000-common debug=<level> modprobe dvb-usb debug=<level>
modprobe dib3000mb debug=<level> modprobe dvb-usb-vp7045 debug=<level>
modprobe dib3000mc debug=<level> etc.
modprobe dvb-dibusb debug=<level>
should do the trick. should do the trick.
...@@ -204,52 +240,32 @@ When the driver is loaded successfully, the firmware file was in ...@@ -204,52 +240,32 @@ When the driver is loaded successfully, the firmware file was in
the right place and the device is connected, the "Power"-LED should be the right place and the device is connected, the "Power"-LED should be
turned on. turned on.
At this point you should be able to start a dvb-capable application. For myself At this point you should be able to start a dvb-capable application. I'm use
I used mplayer, dvbscan, tzap and kaxtv, they are working. Using the device (t|s)zap, mplayer and dvbscan to test the basics. VDR-xine provides the
in vdr is working now also. long-term test scenario.
2. Known problems and bugs 2. Known problems and bugs
- Don't remove the USB device while running an DVB application, your system will die. - Don't remove the USB device while running an DVB application, your system
will go crazy or die most likely.
2.1. Adding support for devices 2.1. Adding support for devices
It is not possible to determine the range of devices based on the DiBcom TODO
reference designs. This is because the reference design of DiBcom can be sold
to thirds, without telling DiBcom (so done with the Twinhan VP7041 and
the HAMA device).
When you think you have a device like this and the driver does not recognizes it,
please send the ****load*.inf and the ****cap*.inf of the Windows driver to me.
Sometimes the Vendor or Product ID is identical to the ones of Twinhan, even
though it is not a Twinhan device (e.g. HAMA), then please send me the name
of the device. I will add it to this list in order to make this clear to
others.
If you are familar with C you can also add the VID and PID of the device to
the dvb-dibusb-core.c-file and create a patch and send it over to me or to
the linux-dvb mailing list, _after_ you have tried compiling and modprobing
it.
2.2. USB1.1 Bandwidth limitation 2.2. USB1.1 Bandwidth limitation
Most of the currently supported devices are USB1.1 and thus they have a A lot of the currently supported devices are USB1.1 and thus they have a
maximum bandwidth of about 5-6 MBit/s when connected to a USB2.0 hub. maximum bandwidth of about 5-6 MBit/s when connected to a USB2.0 hub.
This is not enough for receiving the complete transport stream of a This is not enough for receiving the complete transport stream of a
DVB-T channel (which can be about 16 MBit/s). Normally this is not a DVB-T channel (which is about 16 MBit/s). Normally this is not a
problem, if you only want to watch TV (this does not apply for HDTV), problem, if you only want to watch TV (this does not apply for HDTV),
but watching a channel while recording another channel on the same but watching a channel while recording another channel on the same
frequency simply does not work very well. This applies to all USB1.1 frequency simply does not work very well. This applies to all USB1.1
DVB-T devices, not just dibusb) DVB-T devices, not just the dvb-usb-devices)
Update: For the USB1.1 and VDR some work has been done (patches and comments
are still very welcome). Maybe the problem is solved in the meantime because I
now use the dmx_sw_filter function instead of dmx_sw_filter_packet. I hope the
linux-dvb software filter is able to get the best of the garbled TS.
The bug, where the TS is distorted by a heavy usage of the device is gone The bug, where the TS is distorted by a heavy usage of the device is gone
definitely. All dibusb-devices I was using (Twinhan, Kworld, DiBcom) are definitely. All dvb-usb-devices I was using (Twinhan, Kworld, DiBcom) are
working like charm now with VDR. Sometimes I even was able to record a channel working like charm now with VDR. Sometimes I even was able to record a channel
and watch another one. and watch another one.
...@@ -258,7 +274,7 @@ and watch another one. ...@@ -258,7 +274,7 @@ and watch another one.
Patches, comments and suggestions are very very welcome. Patches, comments and suggestions are very very welcome.
3. Acknowledgements 3. Acknowledgements
Amaury Demol (ademol@dibcom.fr) and Francois Kanounnikoff from DiBcom for Amaury Demol (ademol@dibcom.fr) and Francois Kanounnikoff from DiBcom for
providing specs, code and help, on which the dvb-dibusb, dib3000mb and providing specs, code and help, on which the dvb-dibusb, dib3000mb and
dib3000mc are based. dib3000mc are based.
...@@ -270,9 +286,16 @@ Patches, comments and suggestions are very very welcome. ...@@ -270,9 +286,16 @@ Patches, comments and suggestions are very very welcome.
Bernd Wagner for helping with huge bug reports and discussions. Bernd Wagner for helping with huge bug reports and discussions.
Gunnar Wittich and Joachim von Caron for their trust for giving me Gunnar Wittich and Joachim von Caron for their trust for providing
root-shells on their machines to implement support for new devices. root-shells on their machines to implement support for new devices.
Glen Harris for bringing up, that there is a new dibusb-device and Jiun-Kuei
Jung from AVerMedia who kindly provided a special firmware to get the device
up and running in Linux.
Jennifer Chen, Jeff and Jack from Twinhan for kindly supporting by
writing the vp7045-driver.
Some guys on the linux-dvb mailing list for encouraging me Some guys on the linux-dvb mailing list for encouraging me
Peter Schildmann >peter.schildmann-nospam-at-web.de< for his Peter Schildmann >peter.schildmann-nospam-at-web.de< for his
...@@ -282,4 +305,4 @@ Patches, comments and suggestions are very very welcome. ...@@ -282,4 +305,4 @@ Patches, comments and suggestions are very very welcome.
Ulf Hermenau for helping me out with traditional chinese. Ulf Hermenau for helping me out with traditional chinese.
André Smoktun and Christian Frömmel for supporting me with André Smoktun and Christian Frömmel for supporting me with
hardware and listening to my problems very patient hardware and listening to my problems very patient.
Documentation/dvb/README.flexcop 0 → 100644
浏览文件 @ aef7b83c
This README escorted the skystar2-driver rewriting procedure. It describes the
state of the new flexcop-driver set and some internals are written down here
too.
This document hopefully describes things about the flexcop and its
device-offsprings. Goal was to write an easy-to-write and easy-to-read set of
drivers based on the skystar2.c and other information.
Remark: flexcop-pci.c was a copy of skystar2.c, but every line has been
touched and rewritten.
History & News
==============
2005-04-01 - correct USB ISOC transfers (thanks to Vadim Catana)
General coding processing
=========================
We should proceed as follows (as long as no one complains):
0) Think before start writing code!
1) rewriting the skystar2.c with the help of the flexcop register descriptions
and splitting up the files to a pci-bus-part and a flexcop-part.
The new driver will be called b2c2-flexcop-pci.ko/b2c2-flexcop-usb.ko for the
device-specific part and b2c2-flexcop.ko for the common flexcop-functions.
2) Search for errors in the leftover of flexcop-pci.c (compare with pluto2.c
and other pci drivers)
3) make some beautification (see 'Improvements when rewriting (refactoring) is
done')
4) Testing the new driver and maybe substitute the skystar2.c with it, to reach
a wider tester audience.
5) creating an usb-bus-part using the already written flexcop code for the pci
card.
Idea: create a kernel-object for the flexcop and export all important
functions. This option saves kernel-memory, but maybe a lot of functions have
to be exported to kernel namespace.
Current situation
=================
0) Done :)
1) Done (some minor issues left)
2) Done
3) Not ready yet, more information is necessary
4) next to be done (see the table below)
5) USB driver is working (yes, there are some minor issues)
What seems to be ready?
-----------------------
1) Rewriting
1a) i2c is cut off from the flexcop-pci.c and seems to work
1b) moved tuner and demod stuff from flexcop-pci.c to flexcop-tuner-fe.c
1c) moved lnb and diseqc stuff from flexcop-pci.c to flexcop-tuner-fe.c
1e) eeprom (reading MAC address)
1d) sram (no dynamic sll size detection (commented out) (using default as JJ told me))
1f) misc. register accesses for reading parameters (e.g. resetting, revision)
1g) pid/mac filter (flexcop-hw-filter.c)
1i) dvb-stuff initialization in flexcop.c (done)
1h) dma stuff (now just using the size-irq, instead of all-together, to be done)
1j) remove flexcop initialization from flexcop-pci.c completely (done)
1l) use a well working dma IRQ method (done, see 'Known bugs and problems and TODO')
1k) cleanup flexcop-files (remove unused EXPORT_SYMBOLs, make static from
non-static where possible, moved code to proper places)
2) Search for errors in the leftover of flexcop-pci.c (partially done)
5a) add MAC address reading
5c) feeding of ISOC data to the software demux (format of the isochronous data
and speed optimization, no real error) (thanks to Vadim Catana)
What to do in the near future?
--------------------------------------
(no special order here)
5) USB driver
5b) optimize isoc-transfer (submitting/killing isoc URBs when transfer is starting)
Testing changes
---------------
O = item is working
P = item is partially working
X = item is not working
N = item does not apply here
<empty field> = item need to be examined
| PCI | USB
item | mt352 | nxt2002 | stv0299 | mt312 | mt352 | nxt2002 | stv0299 | mt312
-------+-------+---------+---------+-------+-------+---------+---------+-------
1a) | O | | | | N | N | N | N
1b) | O | | | | | | O |
1c) | N | N | | | N | N | O |
1d) | O | O
1e) | O | O
1f) | P
1g) | O
1h) | P |
1i) | O | N
1j) | O | N
1l) | O | N
2) | O | N
5a) | N | O
5b)* | N |
5c) | N | O
* - not done yet
Known bugs and problems and TODO
--------------------------------
1g/h/l) when pid filtering is enabled on the pci card
DMA usage currently:
The DMA is splitted in 2 equal-sized subbuffers. The Flexcop writes to first
address and triggers an IRQ when it's full and starts writing to the second
address. When the second address is full, the IRQ is triggered again, and
the flexcop writes to first address again, and so on.
The buffersize of each address is currently 640*188 bytes.
Problem is, when using hw-pid-filtering and doing some low-bandwidth
operation (like scanning) the buffers won't be filled enough to trigger
the IRQ. That's why:
When PID filtering is activated, the timer IRQ is used. Every 1.97 ms the IRQ
is triggered. Is the current write address of DMA1 different to the one
during the last IRQ, then the data is passed to the demuxer.
There is an additional DMA-IRQ-method: packet count IRQ. This isn't
implemented correctly yet.
The solution is to disable HW PID filtering, but I don't know how the DVB
API software demux behaves on slow systems with 45MBit/s TS.
Solved bugs :)
--------------
1g) pid-filtering (somehow pid index 4 and 5 (EMM_PID and ECM_PID) aren't
working)
SOLUTION: also index 0 was affected, because net_translation is done for
these indexes by default
5b) isochronous transfer does only work in the first attempt (for the Sky2PC
USB, Air2PC is working) SOLUTION: the flexcop was going asleep and never really
woke up again (don't know if this need fixes, see
flexcop-fe-tuner.c:flexcop_sleep)
NEWS: when the driver is loaded and unloaded and loaded again (w/o doing
anything in the while the driver is loaded the first time), no transfers take
place anymore.
Improvements when rewriting (refactoring) is done
=================================================
- split sleeping of the flexcop (misc_204.ACPI3_sig = 1;) from lnb_control
(enable sleeping for other demods than dvb-s)
- add support for CableStar (stv0297 Microtune 203x/ALPS) (almost done, incompatibilities with the Nexus-CA)
Debugging
---------
- add verbose debugging to skystar2.c (dump the reg_dw_data) and compare it
with this flexcop, this is important, because i2c is now using the
flexcop_ibi_value union from flexcop-reg.h (do you have a better idea for
that, please tell us so).
Everything which is identical in the following table, can be put into a common
flexcop-module.
PCI USB
-------------------------------------------------------------------------------
Different:
Register access: accessing IO memory USB control message
I2C bus: I2C bus of the FC USB control message
Data transfer: DMA isochronous transfer
EEPROM transfer: through i2c bus not clear yet
Identical:
Streaming: accessing registers
PID Filtering: accessing registers
Sram destinations: accessing registers
Tuner/Demod: I2C bus
DVB-stuff: can be written for common use
Acknowledgements (just for the rewriting part)
================
Bjarne Steinsbo thought a lot in the first place of the pci part for this code
sharing idea.
Andreas Oberritter for providing a recent PCI initialization template
(pluto2.c).
Boleslaw Ciesielski for pointing out a problem with firmware loader.
Vadim Catana for correcting the USB transfer.
comments, critics and ideas to linux-dvb@linuxtv.org.
Documentation/dvb/bt8xx.txt
浏览文件 @ aef7b83c
...@@ -17,74 +17,50 @@ Because of this, you need to enable ...@@ -17,74 +17,50 @@ Because of this, you need to enable
"Device drivers" => "Multimedia devices" "Device drivers" => "Multimedia devices"
=> "Video For Linux" => "BT848 Video For Linux" => "Video For Linux" => "BT848 Video For Linux"
Furthermore you need to enable
"Device drivers" => "Multimedia devices" => "Digital Video Broadcasting Devices"
=> "DVB for Linux" "DVB Core Support" "Nebula/Pinnacle PCTV/TwinHan PCI Cards"
2) Loading Modules 2) Loading Modules
================== ==================
In general you need to load the bttv driver, which will handle the gpio and In general you need to load the bttv driver, which will handle the gpio and
i2c communication for us. Next you need the common dvb-bt8xx device driver i2c communication for us, plus the common dvb-bt8xx device driver.
and one frontend driver. The frontends for Nebula (nxt6000), Pinnacle PCTV (cx24110) and
TwinHan (dst) are loaded automatically by the dvb-bt8xx device driver.
The bttv driver will HANG YOUR SYSTEM IF YOU DO NOT SPECIFY THE CORRECT
CARD ID!
(If you don't get your card running and you suspect that the card id you're
using is wrong, have a look at "bttv-cards.c" for a list of possible card
ids.)
Pay attention to failures when you load the frontend drivers
(e.g. dmesg, /var/log/messages).
3a) Nebula / Pinnacle PCTV 3a) Nebula / Pinnacle PCTV
-------------------------- --------------------------
$ modprobe bttv i2c_hw=1 card=0x68 $ modprobe bttv (normally bttv is being loaded automatically by kmod)
$ modprobe dvb-bt8xx $ modprobe dvb-bt8xx (or just place dvb-bt8xx in /etc/modules for automatic loading)
For Nebula cards use the "nxt6000" frontend driver:
$ modprobe nxt6000
For Pinnacle PCTV cards use the "cx24110" frontend driver:
$ modprobe cx24110
3b) TwinHan 3b) TwinHan and Clones
----------- --------------------------
$ modprobe bttv i2c_hw=1 card=0x71 $ modprobe bttv i2c_hw=1 card=0x71
$ modprobe dvb-bt8xx $ modprobe dvb-bt8xx
$ modprobe dst $ modprobe dst
The value 0x71 will override the PCI type detection for dvb-bt8xx, which The value 0x71 will override the PCI type detection for dvb-bt8xx,
is necessary for TwinHan cards.# which is necessary for TwinHan cards.
If you're having an older card (blue color circuit) and card=0x71 locks your
machine, try using 0x68, too. If that does not work, ask on the DVB mailing list.
The DST module takes a couple of useful parameters, in case the
dst drivers fails to detect your type of card correctly.
dst_type takes values 0 (satellite), 1 (terrestial TV), 2 (cable).
dst_type_flags takes bit combined values:
1 = new tuner type packets. You can use this if your card is detected
and you have debug and you continually see the tuner packets not
working (make sure not a basic problem like dish alignment etc.)
2 = TS 204. If your card tunes OK, but the picture is terrible, seemingly
breaking up in one half continually, and crc fails a lot, then
this is worth a try (or trying to turn off)
4 = has symdiv. Some cards, mostly without new tuner packets, require
a symbol division algorithm. Doesn't apply to terrestial TV.
You can also specify a value to have the autodetected values turned off If you're having an older card (blue color circuit) and card=0x71 locks
(e.g. 0). The autodected values are determined bythe cards 'response your machine, try using 0x68, too. If that does not work, ask on the
string' which you can see in your logs e.g. mailing list.
dst_check_ci: recognize DST-MOT The DST module takes a couple of useful parameters:
or a. verbose takes values 0 to 5. These values control the verbosity level.
b. debug takes values 0 and 1. You can either disable or enable debugging.
c. dst_addons takes values 0 and 0x20:
- A value of 0 means it is a FTA card.
- A value of 0x20 means it has a Conditional Access slot.
dst_check_ci: unable to recognize DSTXCI or STXCI The autodetected values are determined by the "response string"
of the card, which you can see in your logs:
e.g.: dst_get_device_id: Recognize [DSTMCI]
-- --
Authors: Richard Walker, Jamie Honan, Michael Hunold Authors: Richard Walker, Jamie Honan, Michael Hunold, Manu Abraham, Uwe Bugla
Documentation/dvb/ci.txt 0 → 100644
浏览文件 @ aef7b83c
* For the user
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
NOTE: This document describes the usage of the high level CI API as
in accordance to the Linux DVB API. This is a not a documentation for the,
existing low level CI API.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
To utilize the High Level CI capabilities,
(1*) This point is valid only for the Twinhan/clones
For the Twinhan/Twinhan clones, the dst_ca module handles the CI
hardware handling.This module is loaded automatically if a CI
(Common Interface, that holds the CAM (Conditional Access Module)
is detected.
(2) one requires a userspace application, ca_zap. This small userland
application is in charge of sending the descrambling related information
to the CAM.
This application requires the following to function properly as of now.
(a) Tune to a valid channel, with szap.
eg: $ szap -c channels.conf -r "TMC" -x
(b) a channels.conf containing a valid PMT PID
eg: TMC:11996:h:0:27500:278:512:650:321
here 278 is a valid PMT PID. the rest of the values are the
same ones that szap uses.
(c) after running a szap, you have to run ca_zap, for the
descrambler to function,
eg: $ ca_zap patched_channels.conf "TMC"
The patched means a patch to apply to scan, such that scan can
generate a channels.conf_with pmt, which has this PMT PID info
(NOTE: szap cannot use this channels.conf with the PMT_PID)
(d) Hopeflly Enjoy your favourite subscribed channel as you do with
a FTA card.
(3) Currently ca_zap, and dst_test, both are meant for demonstration
purposes only, they can become full fledged applications if necessary.
* Cards that fall in this category
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
At present the cards that fall in this category are the Twinhan and it's
clones, these cards are available as VVMER, Tomato, Hercules, Orange and
so on.
* CI modules that are supported
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The CI module support is largely dependant upon the firmware on the cards
Some cards do support almost all of the available CI modules. There is
nothing much that can be done in order to make additional CI modules
working with these cards.
Modules that have been tested by this driver at present are
(1) Irdeto 1 and 2 from SCM
(2) Viaccess from SCM
(3) Dragoncam
* The High level CI API
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
* For the programmer
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
With the High Level CI approach any new card with almost any random
architecture can be implemented with this style, the definitions
insidethe switch statement can be easily adapted for any card, thereby
eliminating the need for any additional ioctls.
The disadvantage is that the driver/hardware has to manage the rest. For
the application programmer it would be as simple as sending/receiving an
array to/from the CI ioctls as defined in the Linux DVB API. No changes
have been made in the API to accomodate this feature.
* Why the need for another CI interface ?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This is one of the most commonly asked question. Well a nice question.
Strictly speaking this is not a new interface.
The CI interface is defined in the DVB API in ca.h as
typedef struct ca_slot_info {
int num; /* slot number */
int type; /* CA interface this slot supports */
#define CA_CI 1 /* CI high level interface */
#define CA_CI_LINK 2 /* CI link layer level interface */
#define CA_CI_PHYS 4 /* CI physical layer level interface */
#define CA_DESCR 8 /* built-in descrambler */
#define CA_SC 128 /* simple smart card interface */
unsigned int flags;
#define CA_CI_MODULE_PRESENT 1 /* module (or card) inserted */
#define CA_CI_MODULE_READY 2
} ca_slot_info_t;
This CI interface follows the CI high level interface, which is not
implemented by most applications. Hence this area is revisited.
This CI interface is quite different in the case that it tries to
accomodate all other CI based devices, that fall into the other categories
This means that this CI interface handles the EN50221 style tags in the
Application layer only and no session management is taken care of by the
application. The driver/hardware will take care of all that.
This interface is purely an EN50221 interface exchanging APDU's. This
means that no session management, link layer or a transport layer do
exist in this case in the application to driver communication. It is
as simple as that. The driver/hardware has to take care of that.
With this High Level CI interface, the interface can be defined with the
regular ioctls.
All these ioctls are also valid for the High level CI interface
#define CA_RESET _IO('o', 128)
#define CA_GET_CAP _IOR('o', 129, ca_caps_t)
#define CA_GET_SLOT_INFO _IOR('o', 130, ca_slot_info_t)
#define CA_GET_DESCR_INFO _IOR('o', 131, ca_descr_info_t)
#define CA_GET_MSG _IOR('o', 132, ca_msg_t)
#define CA_SEND_MSG _IOW('o', 133, ca_msg_t)
#define CA_SET_DESCR _IOW('o', 134, ca_descr_t)
#define CA_SET_PID _IOW('o', 135, ca_pid_t)
On querying the device, the device yields information thus
CA_GET_SLOT_INFO
----------------------------
Command = [info]
APP: Number=[1]
APP: Type=[1]
APP: flags=[1]
APP: CI High level interface
APP: CA/CI Module Present
CA_GET_CAP
----------------------------
Command = [caps]
APP: Slots=[1]
APP: Type=[1]
APP: Descrambler keys=[16]
APP: Type=[1]
CA_SEND_MSG
----------------------------
Descriptors(Program Level)=[ 09 06 06 04 05 50 ff f1]
Found CA descriptor @ program level
(20) ES type=[2] ES pid=[201] ES length =[0 (0x0)]
(25) ES type=[4] ES pid=[301] ES length =[0 (0x0)]
ca_message length is 25 (0x19) bytes
EN50221 CA MSG=[ 9f 80 32 19 03 01 2d d1 f0 08 01 09 06 06 04 05 50 ff f1 02 e0 c9 00 00 04 e1 2d 00 00]
Not all ioctl's are implemented in the driver from the API, the other
features of the hardware that cannot be implemented by the API are achieved
using the CA_GET_MSG and CA_SEND_MSG ioctls. An EN50221 style wrapper is
used to exchange the data to maintain compatibility with other hardware.
/* a message to/from a CI-CAM */
typedef struct ca_msg {
unsigned int index;
unsigned int type;
unsigned int length;
unsigned char msg[256];
} ca_msg_t;
The flow of data can be described thus,
App (User)
-----
parse
|
|
v
en50221 APDU (package)
--------------------------------------
| | | High Level CI driver
| | |
| v |
| en50221 APDU (unpackage) |
| | |
| | |
| v |
| sanity checks |
| | |
| | |
| v |
| do (H/W dep) |
--------------------------------------
| Hardware
|
v
The High Level CI interface uses the EN50221 DVB standard, following a
standard ensures futureproofness.
Documentation/dvb/get_dvb_firmware
浏览文件 @ aef7b83c
...@@ -107,7 +107,7 @@ sub tda10045 { ...@@ -107,7 +107,7 @@ sub tda10045 {
sub tda10046 { sub tda10046 {
my $sourcefile = "tt_budget_217g.zip"; my $sourcefile = "tt_budget_217g.zip";
my $url = "http://www.technotrend.de/new/217g/$sourcefile"; my $url = "http://www.technotrend.de/new/217g/$sourcefile";
my $hash = "a25b579e37109af60f4a36c37893957c"; my $hash = "6a7e1e2f2644b162ff0502367553c72d";
my $outfile = "dvb-fe-tda10046.fw"; my $outfile = "dvb-fe-tda10046.fw";
my $tmpdir = tempdir(DIR => "/tmp", CLEANUP => 1); my $tmpdir = tempdir(DIR => "/tmp", CLEANUP => 1);
...@@ -115,7 +115,7 @@ sub tda10046 { ...@@ -115,7 +115,7 @@ sub tda10046 {
wgetfile($sourcefile, $url); wgetfile($sourcefile, $url);
unzip($sourcefile, $tmpdir); unzip($sourcefile, $tmpdir);
extract("$tmpdir/software/OEM/PCI/App/ttlcdacc.dll", 0x3f731, 24479, "$tmpdir/fwtmp"); extract("$tmpdir/software/OEM/PCI/App/ttlcdacc.dll", 0x3f731, 24478, "$tmpdir/fwtmp");
verify("$tmpdir/fwtmp", $hash); verify("$tmpdir/fwtmp", $hash);
copy("$tmpdir/fwtmp", $outfile); copy("$tmpdir/fwtmp", $outfile);
......
Documentation/fb/intelfb.txt 0 → 100644
浏览文件 @ aef7b83c
Intel 830M/845G/852GM/855GM/865G/915G Framebuffer driver
================================================================
A. Introduction
This is a framebuffer driver for various Intel 810/815 compatible
graphics devices. These would include:
Intel 830M
Intel 810E845G
Intel 852GM
Intel 855GM
Intel 865G
Intel 915G
B. List of available options
a. "video=intelfb"
enables the intelfb driver
Recommendation: required
b. "mode=<xres>x<yres>[-<bpp>][@<refresh>]"
select mode
Recommendation: user preference
(default = 1024x768-32@70)
c. "vram=<value>"
select amount of system RAM in MB to allocate for the video memory
if not enough RAM was already allocated by the BIOS.
Recommendation: 1 - 4 MB.
(default = 4 MB)
d. "voffset=<value>"
select at what offset in MB of the logical memory to allocate the
framebuffer memory. The intent is to avoid the memory blocks
used by standard graphics applications (XFree86). Depending on your
usage, adjust the value up or down, (0 for maximum usage, 63/127 MB
for the least amount). Note, an arbitrary setting may conflict
with XFree86.
Recommendation: do not set
(default = 48 MB)
e. "accel"
enable text acceleration. This can be enabled/reenabled anytime
by using 'fbset -accel true/false'.
Recommendation: enable
(default = set)
f. "hwcursor"
enable cursor acceleration.
Recommendation: enable
(default = set)
g. "mtrr"
enable MTRR. This allows data transfers to the framebuffer memory
to occur in bursts which can significantly increase performance.
Not very helpful with the intel chips because of 'shared memory'.
Recommendation: set
(default = set)
h. "fixed"
disable mode switching.
Recommendation: do not set
(default = not set)
The binary parameters can be unset with a "no" prefix, example "noaccel".
The default parameter (not named) is the mode.
C. Kernel booting
Separate each option/option-pair by commas (,) and the option from its value
with an equals sign (=) as in the following:
video=i810fb:option1,option2=value2
Sample Usage
------------
In /etc/lilo.conf, add the line:
append="video=intelfb:800x600-32@75,accel,hwcursor,vram=8"
This will initialize the framebuffer to 800x600 at 32bpp and 75Hz. The
framebuffer will use 8 MB of System RAM. hw acceleration of text and cursor
will be enabled.
D. Module options
The module parameters are essentially similar to the kernel
parameters. The main difference is that you need to include a Boolean value
(1 for TRUE, and 0 for FALSE) for those options which don't need a value.
Example, to enable MTRR, include "mtrr=1".
Sample Usage
------------
Using the same setup as described above, load the module like this:
modprobe intelfb mode=800x600-32@75 vram=8 accel=1 hwcursor=1
Or just add the following to /etc/modprobe.conf
options intelfb mode=800x600-32@75 vram=8 accel=1 hwcursor=1
and just do a
modprobe intelfb
E. Acknowledgment:
1. Geert Uytterhoeven - his excellent howto and the virtual
framebuffer driver code made this possible.
2. Jeff Hartmann for his agpgart code.
3. David Dawes for his original kernel 2.4 code.
4. The X developers. Insights were provided just by reading the
XFree86 source code.
5. Antonino A. Daplas for his inspiring i810fb driver.
6. Andrew Morton for his kernel patches maintenance.
###########################
Sylvain
Documentation/feature-removal-schedule.txt
浏览文件 @ aef7b83c
...@@ -43,6 +43,14 @@ Who: Randy Dunlap <rddunlap@osdl.org> ...@@ -43,6 +43,14 @@ Who: Randy Dunlap <rddunlap@osdl.org>
--------------------------- ---------------------------
What: RAW driver (CONFIG_RAW_DRIVER)
When: December 2005
Why: declared obsolete since kernel 2.6.3
O_DIRECT can be used instead
Who: Adrian Bunk <bunk@stusta.de>
---------------------------
What: register_ioctl32_conversion() / unregister_ioctl32_conversion() What: register_ioctl32_conversion() / unregister_ioctl32_conversion()
When: April 2005 When: April 2005
Why: Replaced by ->compat_ioctl in file_operations and other method Why: Replaced by ->compat_ioctl in file_operations and other method
...@@ -63,3 +71,51 @@ Why: Outside of Linux, the only implementations of anything even ...@@ -63,3 +71,51 @@ Why: Outside of Linux, the only implementations of anything even
people, who might be using implementations that I am not aware people, who might be using implementations that I am not aware
of, to adjust to this upcoming change. of, to adjust to this upcoming change.
Who: Paul E. McKenney <paulmck@us.ibm.com> Who: Paul E. McKenney <paulmck@us.ibm.com>
---------------------------
What: remove verify_area()
When: July 2006
Files: Various uaccess.h headers.
Why: Deprecated and redundant. access_ok() should be used instead.
Who: Jesper Juhl <juhl-lkml@dif.dk>
---------------------------
What: IEEE1394 Audio and Music Data Transmission Protocol driver,
Connection Management Procedures driver
When: November 2005
Files: drivers/ieee1394/{amdtp,cmp}*
Why: These are incomplete, have never worked, and are better implemented
in userland via raw1394 (see http://freebob.sourceforge.net/ for
example.)
Who: Jody McIntyre <scjody@steamballoon.com>
---------------------------
What: raw1394: requests of type RAW1394_REQ_ISO_SEND, RAW1394_REQ_ISO_LISTEN
When: November 2005
Why: Deprecated in favour of the new ioctl-based rawiso interface, which is
more efficient. You should really be using libraw1394 for raw1394
access anyway.
Who: Jody McIntyre <scjody@steamballoon.com>
---------------------------
What: register_serial/unregister_serial
When: December 2005
Why: This interface does not allow serial ports to be registered against
a struct device, and as such does not allow correct power management
of such ports. 8250-based ports should use serial8250_register_port
and serial8250_unregister_port instead.
Who: Russell King <rmk@arm.linux.org.uk>
---------------------------
What: i2c sysfs name change: in1_ref, vid deprecated in favour of cpu0_vid
When: November 2005
Files: drivers/i2c/chips/adm1025.c, drivers/i2c/chips/adm1026.c
Why: Match the other drivers' name for the same function, duplicate names
will be available until removal of old names.
Who: Grant Coady <gcoady@gmail.com>
Documentation/filesystems/ext2.txt
浏览文件 @ aef7b83c
...@@ -58,6 +58,8 @@ noacl Don't support POSIX ACLs. ...@@ -58,6 +58,8 @@ noacl Don't support POSIX ACLs.
nobh Do not attach buffer_heads to file pagecache. nobh Do not attach buffer_heads to file pagecache.
xip Use execute in place (no caching) if possible
grpquota,noquota,quota,usrquota Quota options are silently ignored by ext2. grpquota,noquota,quota,usrquota Quota options are silently ignored by ext2.
......
Documentation/filesystems/isofs.txt
浏览文件 @ aef7b83c
...@@ -26,7 +26,11 @@ Mount options unique to the isofs filesystem. ...@@ -26,7 +26,11 @@ Mount options unique to the isofs filesystem.
mode=xxx Sets the permissions on files to xxx mode=xxx Sets the permissions on files to xxx
nojoliet Ignore Joliet extensions if they are present. nojoliet Ignore Joliet extensions if they are present.
norock Ignore Rock Ridge extensions if they are present. norock Ignore Rock Ridge extensions if they are present.
unhide Show hidden files. hide Completely strip hidden files from the file system.
showassoc Show files marked with the 'associated' bit
unhide Deprecated; showing hidden files is now default;
If given, it is a synonym for 'showassoc' which will
recreate previous unhide behavior
session=x Select number of session on multisession CD session=x Select number of session on multisession CD
sbsector=xxx Session begins from sector xxx sbsector=xxx Session begins from sector xxx
......
Documentation/filesystems/sysfs-pci.txt
浏览文件 @ aef7b83c
...@@ -7,7 +7,6 @@ that support it. For example, a given bus might look like this: ...@@ -7,7 +7,6 @@ that support it. For example, a given bus might look like this:
|-- 0000:17:00.0 |-- 0000:17:00.0
| |-- class | |-- class
| |-- config | |-- config
| |-- detach_state
| |-- device | |-- device
| |-- irq | |-- irq
| |-- local_cpus | |-- local_cpus
...@@ -19,7 +18,7 @@ that support it. For example, a given bus might look like this: ...@@ -19,7 +18,7 @@ that support it. For example, a given bus might look like this:
| |-- subsystem_device | |-- subsystem_device
| |-- subsystem_vendor | |-- subsystem_vendor
| `-- vendor | `-- vendor
`-- detach_state `-- ...
The topmost element describes the PCI domain and bus number. In this case, The topmost element describes the PCI domain and bus number. In this case,
the domain number is 0000 and the bus number is 17 (both values are in hex). the domain number is 0000 and the bus number is 17 (both values are in hex).
...@@ -31,7 +30,6 @@ files, each with their own function. ...@@ -31,7 +30,6 @@ files, each with their own function.
---- -------- ---- --------
class PCI class (ascii, ro) class PCI class (ascii, ro)
config PCI config space (binary, rw) config PCI config space (binary, rw)
detach_state connection status (bool, rw)
device PCI device (ascii, ro) device PCI device (ascii, ro)
irq IRQ number (ascii, ro) irq IRQ number (ascii, ro)
local_cpus nearby CPU mask (cpumask, ro) local_cpus nearby CPU mask (cpumask, ro)
...@@ -85,4 +83,4 @@ useful return codes should be provided. ...@@ -85,4 +83,4 @@ useful return codes should be provided.
Legacy resources are protected by the HAVE_PCI_LEGACY define. Platforms Legacy resources are protected by the HAVE_PCI_LEGACY define. Platforms
wishing to support legacy functionality should define it and provide wishing to support legacy functionality should define it and provide
pci_legacy_read, pci_legacy_write and pci_mmap_legacy_page_range functions. pci_legacy_read, pci_legacy_write and pci_mmap_legacy_page_range functions.
\ No newline at end of file
Documentation/filesystems/sysfs.txt
浏览文件 @ aef7b83c
...@@ -214,7 +214,7 @@ Other notes: ...@@ -214,7 +214,7 @@ Other notes:
A very simple (and naive) implementation of a device attribute is: A very simple (and naive) implementation of a device attribute is:
static ssize_t show_name(struct device * dev, char * buf) static ssize_t show_name(struct device *dev, struct device_attribute *attr, char *buf)
{ {
return sprintf(buf,"%s\n",dev->name); return sprintf(buf,"%s\n",dev->name);
} }
......
Documentation/filesystems/tmpfs.txt
浏览文件 @ aef7b83c
...@@ -71,8 +71,8 @@ can be changed on remount. The size parameter also accepts a suffix % ...@@ -71,8 +71,8 @@ can be changed on remount. The size parameter also accepts a suffix %
to limit this tmpfs instance to that percentage of your physical RAM: to limit this tmpfs instance to that percentage of your physical RAM:
the default, when neither size nor nr_blocks is specified, is size=50% the default, when neither size nor nr_blocks is specified, is size=50%
If both nr_blocks (or size) and nr_inodes are set to 0, neither blocks If nr_blocks=0 (or size=0), blocks will not be limited in that instance;
nor inodes will be limited in that instance. It is generally unwise to if nr_inodes=0, inodes will not be limited. It is generally unwise to
mount with such options, since it allows any user with write access to mount with such options, since it allows any user with write access to
use up all the memory on the machine; but enhances the scalability of use up all the memory on the machine; but enhances the scalability of
that instance in a system with many cpus making intensive use of it. that instance in a system with many cpus making intensive use of it.
...@@ -97,4 +97,4 @@ RAM/SWAP in 10240 inodes and it is only accessible by root. ...@@ -97,4 +97,4 @@ RAM/SWAP in 10240 inodes and it is only accessible by root.
Author: Author:
Christoph Rohland <cr@sap.com>, 1.12.01 Christoph Rohland <cr@sap.com>, 1.12.01
Updated: Updated:
Hugh Dickins <hugh@veritas.com>, 01 September 2004 Hugh Dickins <hugh@veritas.com>, 13 March 2005
Documentation/filesystems/xip.txt 0 → 100644
浏览文件 @ aef7b83c
Execute-in-place for file mappings
----------------------------------
Motivation
----------
File mappings are performed by mapping page cache pages to userspace. In
addition, read&write type file operations also transfer data from/to the page
cache.
For memory backed storage devices that use the block device interface, the page
cache pages are in fact copies of the original storage. Various approaches
exist to work around the need for an extra copy. The ramdisk driver for example
does read the data into the page cache, keeps a reference, and discards the
original data behind later on.
Execute-in-place solves this issue the other way around: instead of keeping
data in the page cache, the need to have a page cache copy is eliminated
completely. With execute-in-place, read&write type operations are performed
directly from/to the memory backed storage device. For file mappings, the
storage device itself is mapped directly into userspace.
This implementation was initialy written for shared memory segments between
different virtual machines on s390 hardware to allow multiple machines to
share the same binaries and libraries.
Implementation
--------------
Execute-in-place is implemented in three steps: block device operation,
address space operation, and file operations.
A block device operation named direct_access is used to retrieve a
reference (pointer) to a block on-disk. The reference is supposed to be
cpu-addressable, physical address and remain valid until the release operation
is performed. A struct block_device reference is used to address the device,
and a sector_t argument is used to identify the individual block. As an
alternative, memory technology devices can be used for this.
The block device operation is optional, these block devices support it as of
today:
- dcssblk: s390 dcss block device driver
An address space operation named get_xip_page is used to retrieve reference
to a struct page. To address the target page, a reference to an address_space,
and a sector number is provided. A 3rd argument indicates whether the
function should allocate blocks if needed.
This address space operation is mutually exclusive with readpage&writepage that
do page cache read/write operations.
The following filesystems support it as of today:
- ext2: the second extended filesystem, see Documentation/filesystems/ext2.txt
A set of file operations that do utilize get_xip_page can be found in
mm/filemap_xip.c . The following file operation implementations are provided:
- aio_read/aio_write
- readv/writev
- sendfile
The generic file operations do_sync_read/do_sync_write can be used to implement
classic synchronous IO calls.
Shortcomings
------------
This implementation is limited to storage devices that are cpu addressable at
all times (no highmem or such). It works well on rom/ram, but enhancements are
needed to make it work with flash in read+write mode.
Putting the Linux kernel and/or its modules on a xip filesystem does not mean
they are not copied.
Documentation/i2c/busses/i2c-sis69x
浏览文件 @ aef7b83c
...@@ -42,7 +42,7 @@ I suspect that this driver could be made to work for the following SiS ...@@ -42,7 +42,7 @@ I suspect that this driver could be made to work for the following SiS
chipsets as well: 635, and 635T. If anyone owns a board with those chips chipsets as well: 635, and 635T. If anyone owns a board with those chips
AND is willing to risk crashing & burning an otherwise well-behaved kernel AND is willing to risk crashing & burning an otherwise well-behaved kernel
in the name of progress... please contact me at <mhoffman@lightlink.com> or in the name of progress... please contact me at <mhoffman@lightlink.com> or
via the project's mailing list: <sensors@stimpy.netroedge.com>. Please via the project's mailing list: <lm-sensors@lm-sensors.org>. Please
send bug reports and/or success stories as well. send bug reports and/or success stories as well.
......
Documentation/i2c/chips/adm1021 0 → 100644
浏览文件 @ aef7b83c
Kernel driver adm1021
=====================
Supported chips:
* Analog Devices ADM1021
Prefix: 'adm1021'
Addresses scanned: I2C 0x18 - 0x1a, 0x29 - 0x2b, 0x4c - 0x4e
Datasheet: Publicly available at the Analog Devices website
* Analog Devices ADM1021A/ADM1023
Prefix: 'adm1023'
Addresses scanned: I2C 0x18 - 0x1a, 0x29 - 0x2b, 0x4c - 0x4e
Datasheet: Publicly available at the Analog Devices website
* Genesys Logic GL523SM
Prefix: 'gl523sm'
Addresses scanned: I2C 0x18 - 0x1a, 0x29 - 0x2b, 0x4c - 0x4e
Datasheet:
* Intel Xeon Processor
Prefix: - any other - may require 'force_adm1021' parameter
Addresses scanned: none
Datasheet: Publicly available at Intel website
* Maxim MAX1617
Prefix: 'max1617'
Addresses scanned: I2C 0x18 - 0x1a, 0x29 - 0x2b, 0x4c - 0x4e
Datasheet: Publicly available at the Maxim website
* Maxim MAX1617A
Prefix: 'max1617a'
Addresses scanned: I2C 0x18 - 0x1a, 0x29 - 0x2b, 0x4c - 0x4e
Datasheet: Publicly available at the Maxim website
* National Semiconductor LM84
Prefix: 'lm84'
Addresses scanned: I2C 0x18 - 0x1a, 0x29 - 0x2b, 0x4c - 0x4e
Datasheet: Publicly available at the National Semiconductor website
* Philips NE1617
Prefix: 'max1617' (probably detected as a max1617)
Addresses scanned: I2C 0x18 - 0x1a, 0x29 - 0x2b, 0x4c - 0x4e
Datasheet: Publicly available at the Philips website
* Philips NE1617A
Prefix: 'max1617' (probably detected as a max1617)
Addresses scanned: I2C 0x18 - 0x1a, 0x29 - 0x2b, 0x4c - 0x4e
Datasheet: Publicly available at the Philips website
* TI THMC10
Prefix: 'thmc10'
Addresses scanned: I2C 0x18 - 0x1a, 0x29 - 0x2b, 0x4c - 0x4e
Datasheet: Publicly available at the TI website
* Onsemi MC1066
Prefix: 'mc1066'
Addresses scanned: I2C 0x18 - 0x1a, 0x29 - 0x2b, 0x4c - 0x4e
Datasheet: Publicly available at the Onsemi website
Authors:
Frodo Looijaard <frodol@dds.nl>,
Philip Edelbrock <phil@netroedge.com>
Module Parameters
-----------------
* read_only: int
Don't set any values, read only mode
Description
-----------
The chips supported by this driver are very similar. The Maxim MAX1617 is
the oldest; it has the problem that it is not very well detectable. The
MAX1617A solves that. The ADM1021 is a straight clone of the MAX1617A.
Ditto for the THMC10. From here on, we will refer to all these chips as
ADM1021-clones.
The ADM1021 and MAX1617A reports a die code, which is a sort of revision
code. This can help us pinpoint problems; it is not very useful
otherwise.
ADM1021-clones implement two temperature sensors. One of them is internal,
and measures the temperature of the chip itself; the other is external and
is realised in the form of a transistor-like device. A special alarm
indicates whether the remote sensor is connected.
Each sensor has its own low and high limits. When they are crossed, the
corresponding alarm is set and remains on as long as the temperature stays
out of range. Temperatures are measured in degrees Celsius. Measurements
are possible between -65 and +127 degrees, with a resolution of one degree.
If an alarm triggers, it will remain triggered until the hardware register
is read at least once. This means that the cause for the alarm may already
have disappeared!
This driver only updates its values each 1.5 seconds; reading it more often
will do no harm, but will return 'old' values. It is possible to make
ADM1021-clones do faster measurements, but there is really no good reason
for that.
Xeon support
------------
Some Xeon processors have real max1617, adm1021, or compatible chips
within them, with two temperature sensors.
Other Xeons have chips with only one sensor.
If you have a Xeon, and the adm1021 module loads, and both temperatures
appear valid, then things are good.
If the adm1021 module doesn't load, you should try this:
modprobe adm1021 force_adm1021=BUS,ADDRESS
ADDRESS can only be 0x18, 0x1a, 0x29, 0x2b, 0x4c, or 0x4e.
If you have dual Xeons you may have appear to have two separate
adm1021-compatible chips, or two single-temperature sensors, at distinct
addresses.
Documentation/i2c/chips/adm1025 0 → 100644
浏览文件 @ aef7b83c
Kernel driver adm1025
=====================
Supported chips:
* Analog Devices ADM1025, ADM1025A
Prefix: 'adm1025'
Addresses scanned: I2C 0x2c - 0x2e
Datasheet: Publicly available at the Analog Devices website
* Philips NE1619
Prefix: 'ne1619'
Addresses scanned: I2C 0x2c - 0x2d
Datasheet: Publicly available at the Philips website
The NE1619 presents some differences with the original ADM1025:
* Only two possible addresses (0x2c - 0x2d).
* No temperature offset register, but we don't use it anyway.
* No INT mode for pin 16. We don't play with it anyway.
Authors:
Chen-Yuan Wu <gwu@esoft.com>,
Jean Delvare <khali@linux-fr.org>
Description
-----------
(This is from Analog Devices.) The ADM1025 is a complete system hardware
monitor for microprocessor-based systems, providing measurement and limit
comparison of various system parameters. Five voltage measurement inputs
are provided, for monitoring +2.5V, +3.3V, +5V and +12V power supplies and
the processor core voltage. The ADM1025 can monitor a sixth power-supply
voltage by measuring its own VCC. One input (two pins) is dedicated to a
remote temperature-sensing diode and an on-chip temperature sensor allows
ambient temperature to be monitored.
One specificity of this chip is that the pin 11 can be hardwired in two
different manners. It can act as the +12V power-supply voltage analog
input, or as the a fifth digital entry for the VID reading (bit 4). It's
kind of strange since both are useful, and the reason for designing the
chip that way is obscure at least to me. The bit 5 of the configuration
register can be used to define how the chip is hardwired. Please note that
it is not a choice you have to make as the user. The choice was already
made by your motherboard's maker. If the configuration bit isn't set
properly, you'll have a wrong +12V reading or a wrong VID reading. The way
the driver handles that is to preserve this bit through the initialization
process, assuming that the BIOS set it up properly beforehand. If it turns
out not to be true in some cases, we'll provide a module parameter to force
modes.
This driver also supports the ADM1025A, which differs from the ADM1025
only in that it has "open-drain VID inputs while the ADM1025 has on-chip
100k pull-ups on the VID inputs". It doesn't make any difference for us.
Documentation/i2c/chips/adm1026 0 → 100644
浏览文件 @ aef7b83c
Kernel driver adm1026
=====================
Supported chips:
* Analog Devices ADM1026
Prefix: 'adm1026'
Addresses scanned: I2C 0x2c, 0x2d, 0x2e
Datasheet: Publicly available at the Analog Devices website
http://www.analog.com/en/prod/0,,766_825_ADM1026,00.html
Authors:
Philip Pokorny <ppokorny@penguincomputing.com> for Penguin Computing
Justin Thiessen <jthiessen@penguincomputing.com>
Module Parameters
-----------------
* gpio_input: int array (min = 1, max = 17)
List of GPIO pins (0-16) to program as inputs
* gpio_output: int array (min = 1, max = 17)
List of GPIO pins (0-16) to program as outputs
* gpio_inverted: int array (min = 1, max = 17)
List of GPIO pins (0-16) to program as inverted
* gpio_normal: int array (min = 1, max = 17)
List of GPIO pins (0-16) to program as normal/non-inverted
* gpio_fan: int array (min = 1, max = 8)
List of GPIO pins (0-7) to program as fan tachs
Description
-----------
This driver implements support for the Analog Devices ADM1026. Analog
Devices calls it a "complete thermal system management controller."
The ADM1026 implements three (3) temperature sensors, 17 voltage sensors,
16 general purpose digital I/O lines, eight (8) fan speed sensors (8-bit),
an analog output and a PWM output along with limit, alarm and mask bits for
all of the above. There is even 8k bytes of EEPROM memory on chip.
Temperatures are measured in degrees Celsius. There are two external
sensor inputs and one internal sensor. Each sensor has a high and low
limit. If the limit is exceeded, an interrupt (#SMBALERT) can be
generated. The interrupts can be masked. In addition, there are over-temp
limits for each sensor. If this limit is exceeded, the #THERM output will
be asserted. The current temperature and limits have a resolution of 1
degree.
Fan rotation speeds are reported in RPM (rotations per minute) but measured
in counts of a 22.5kHz internal clock. Each fan has a high limit which
corresponds to a minimum fan speed. If the limit is exceeded, an interrupt
can be generated. Each fan can be programmed to divide the reference clock
by 1, 2, 4 or 8. Not all RPM values can accurately be represented, so some
rounding is done. With a divider of 8, the slowest measurable speed of a
two pulse per revolution fan is 661 RPM.
There are 17 voltage sensors. An alarm is triggered if the voltage has
crossed a programmable minimum or maximum limit. Note that minimum in this
case always means 'closest to zero'; this is important for negative voltage
measurements. Several inputs have integrated attenuators so they can measure
higher voltages directly. 3.3V, 5V, 12V, -12V and battery voltage all have
dedicated inputs. There are several inputs scaled to 0-3V full-scale range
for SCSI terminator power. The remaining inputs are not scaled and have
a 0-2.5V full-scale range. A 2.5V or 1.82V reference voltage is provided
for negative voltage measurements.
If an alarm triggers, it will remain triggered until the hardware register
is read at least once. This means that the cause for the alarm may already
have disappeared! Note that in the current implementation, all hardware
registers are read whenever any data is read (unless it is less than 2.0
seconds since the last update). This means that you can easily miss
once-only alarms.
The ADM1026 measures continuously. Analog inputs are measured about 4
times a second. Fan speed measurement time depends on fan speed and
divisor. It can take as long as 1.5 seconds to measure all fan speeds.
The ADM1026 has the ability to automatically control fan speed based on the
temperature sensor inputs. Both the PWM output and the DAC output can be
used to control fan speed. Usually only one of these two outputs will be
used. Write the minimum PWM or DAC value to the appropriate control
register. Then set the low temperature limit in the tmin values for each
temperature sensor. The range of control is fixed at 20 °C, and the
largest difference between current and tmin of the temperature sensors sets
the control output. See the datasheet for several example circuits for
controlling fan speed with the PWM and DAC outputs. The fan speed sensors
do not have PWM compensation, so it is probably best to control the fan
voltage from the power lead rather than on the ground lead.
The datasheet shows an example application with VID signals attached to
GPIO lines. Unfortunately, the chip may not be connected to the VID lines
in this way. The driver assumes that the chips *is* connected this way to
get a VID voltage.
Documentation/i2c/chips/adm1031 0 → 100644
浏览文件 @ aef7b83c
Kernel driver adm1031
=====================
Supported chips:
* Analog Devices ADM1030
Prefix: 'adm1030'
Addresses scanned: I2C 0x2c to 0x2e
Datasheet: Publicly available at the Analog Devices website
http://products.analog.com/products/info.asp?product=ADM1030
* Analog Devices ADM1031
Prefix: 'adm1031'
Addresses scanned: I2C 0x2c to 0x2e
Datasheet: Publicly available at the Analog Devices website
http://products.analog.com/products/info.asp?product=ADM1031
Authors:
Alexandre d'Alton <alex@alexdalton.org>
Jean Delvare <khali@linux-fr.org>
Description
-----------
The ADM1030 and ADM1031 are digital temperature sensors and fan controllers.
They sense their own temperature as well as the temperature of up to one
(ADM1030) or two (ADM1031) external diodes.
All temperature values are given in degrees Celsius. Resolution is 0.5
degree for the local temperature, 0.125 degree for the remote temperatures.
Each temperature channel has its own high and low limits, plus a critical
limit.
The ADM1030 monitors a single fan speed, while the ADM1031 monitors up to
two. Each fan channel has its own low speed limit.
Documentation/i2c/chips/adm9240 0 → 100644
浏览文件 @ aef7b83c
Kernel driver adm9240
=====================
Supported chips:
* Analog Devices ADM9240
Prefix: 'adm9240'
Addresses scanned: I2C 0x2c - 0x2f
Datasheet: Publicly available at the Analog Devices website
http://www.analog.com/UploadedFiles/Data_Sheets/79857778ADM9240_0.pdf
* Dallas Semiconductor DS1780
Prefix: 'ds1780'
Addresses scanned: I2C 0x2c - 0x2f
Datasheet: Publicly available at the Dallas Semiconductor (Maxim) website
http://pdfserv.maxim-ic.com/en/ds/DS1780.pdf
* National Semiconductor LM81
Prefix: 'lm81'
Addresses scanned: I2C 0x2c - 0x2f
Datasheet: Publicly available at the National Semiconductor website
http://www.national.com/ds.cgi/LM/LM81.pdf
Authors:
Frodo Looijaard <frodol@dds.nl>,
Philip Edelbrock <phil@netroedge.com>,
Michiel Rook <michiel@grendelproject.nl>,
Grant Coady <gcoady@gmail.com> with guidance
from Jean Delvare <khali@linux-fr.org>
Interface
---------
The I2C addresses listed above assume BIOS has not changed the
chip MSB 5-bit address. Each chip reports a unique manufacturer
identification code as well as the chip revision/stepping level.
Description
-----------
[From ADM9240] The ADM9240 is a complete system hardware monitor for
microprocessor-based systems, providing measurement and limit comparison
of up to four power supplies and two processor core voltages, plus
temperature, two fan speeds and chassis intrusion. Measured values can
be read out via an I2C-compatible serial System Management Bus, and values
for limit comparisons can be programmed in over the same serial bus. The
high speed successive approximation ADC allows frequent sampling of all
analog channels to ensure a fast interrupt response to any out-of-limit
measurement.
The ADM9240, DS1780 and LM81 are register compatible, the following
details are common to the three chips. Chip differences are described
after this section.
Measurements
------------
The measurement cycle
The adm9240 driver will take a measurement reading no faster than once
each two seconds. User-space may read sysfs interface faster than the
measurement update rate and will receive cached data from the most
recent measurement.
ADM9240 has a very fast 320us temperature and voltage measurement cycle
with independent fan speed measurement cycles counting alternating rising
edges of the fan tacho inputs.
DS1780 measurement cycle is about once per second including fan speed.
LM81 measurement cycle is about once per 400ms including fan speed.
The LM81 12-bit extended temperature measurement mode is not supported.
Temperature
-----------
On chip temperature is reported as degrees Celsius as 9-bit signed data
with resolution of 0.5 degrees Celsius. High and low temperature limits
are 8-bit signed data with resolution of one degree Celsius.
Temperature alarm is asserted once the temperature exceeds the high limit,
and is cleared when the temperature falls below the temp1_max_hyst value.
Fan Speed
---------
Two fan tacho inputs are provided, the ADM9240 gates an internal 22.5kHz
clock via a divider to an 8-bit counter. Fan speed (rpm) is calculated by:
rpm = (22500 * 60) / (count * divider)
Automatic fan clock divider
* User sets 0 to fan_min limit
- low speed alarm is disabled
- fan clock divider not changed
- auto fan clock adjuster enabled for valid fan speed reading
* User sets fan_min limit too low
- low speed alarm is enabled
- fan clock divider set to max
- fan_min set to register value 254 which corresponds
to 664 rpm on adm9240
- low speed alarm will be asserted if fan speed is
less than minimum measurable speed
- auto fan clock adjuster disabled
* User sets reasonable fan speed
- low speed alarm is enabled
- fan clock divider set to suit fan_min
- auto fan clock adjuster enabled: adjusts fan_min
* User sets unreasonably high low fan speed limit
- resolution of the low speed limit may be reduced
- alarm will be asserted
- auto fan clock adjuster enabled: adjusts fan_min
* fan speed may be displayed as zero until the auto fan clock divider
adjuster brings fan speed clock divider back into chip measurement
range, this will occur within a few measurement cycles.
Analog Output
-------------
An analog output provides a 0 to 1.25 volt signal intended for an external
fan speed amplifier circuit. The analog output is set to maximum value on
power up or reset. This doesn't do much on the test Intel SE440BX-2.
Voltage Monitor
Voltage (IN) measurement is internally scaled:
nr label nominal maximum resolution
mV mV mV
0 +2.5V 2500 3320 13.0
1 Vccp1 2700 3600 14.1
2 +3.3V 3300 4380 17.2
3 +5V 5000 6640 26.0
4 +12V 12000 15940 62.5
5 Vccp2 2700 3600 14.1
The reading is an unsigned 8-bit value, nominal voltage measurement is
represented by a reading of 192, being 3/4 of the measurement range.
An alarm is asserted for any voltage going below or above the set limits.
The driver reports and accepts voltage limits scaled to the above table.
VID Monitor
-----------
The chip has five inputs to read the 5-bit VID and reports the mV value
based on detected CPU type.
Chassis Intrusion
-----------------
An alarm is asserted when the CI pin goes active high. The ADM9240
Datasheet has an example of an external temperature sensor driving
this pin. On an Intel SE440BX-2 the Chassis Intrusion header is
connected to a normally open switch.
The ADM9240 provides an internal open drain on this line, and may output
a 20 ms active low pulse to reset an external Chassis Intrusion latch.
Clear the CI latch by writing value 1 to the sysfs chassis_clear file.
Alarm flags reported as 16-bit word
bit label comment
--- ------------- --------------------------
0 +2.5 V_Error high or low limit exceeded
1 VCCP_Error high or low limit exceeded
2 +3.3 V_Error high or low limit exceeded
3 +5 V_Error high or low limit exceeded
4 Temp_Error temperature error
6 FAN1_Error fan low limit exceeded
7 FAN2_Error fan low limit exceeded
8 +12 V_Error high or low limit exceeded
9 VCCP2_Error high or low limit exceeded
12 Chassis_Error CI pin went high
Remaining bits are reserved and thus undefined. It is important to note
that alarm bits may be cleared on read, user-space may latch alarms and
provide the end-user with a method to clear alarm memory.
Documentation/i2c/chips/asb100 0 → 100644
浏览文件 @ aef7b83c
Kernel driver asb100
====================
Supported Chips:
* Asus ASB100 and ASB100-A "Bach"
Prefix: 'asb100'
Addresses scanned: I2C 0x2d
Datasheet: none released
Author: Mark M. Hoffman <mhoffman@lightlink.com>
Description
-----------
This driver implements support for the Asus ASB100 and ASB100-A "Bach".
These are custom ASICs available only on Asus mainboards. Asus refuses to
supply a datasheet for these chips. Thanks go to many people who helped
investigate their hardware, including:
Vitaly V. Bursov
Alexander van Kaam (author of MBM for Windows)
Bertrik Sikken
The ASB100 implements seven voltage sensors, three fan rotation speed
sensors, four temperature sensors, VID lines and alarms. In addition to
these, the ASB100-A also implements a single PWM controller for fans 2 and
3 (i.e. one setting controls both.) If you have a plain ASB100, the PWM
controller will simply not work (or maybe it will for you... it doesn't for
me).
Temperatures are measured and reported in degrees Celsius.
Fan speeds are reported in RPM (rotations per minute). An alarm is
triggered if the rotation speed has dropped below a programmable limit.
Voltage sensors (also known as IN sensors) report values in volts.
The VID lines 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.
Alarms: (TODO question marks indicate may or may not work)
0x0001 => in0 (?)
0x0002 => in1 (?)
0x0004 => in2
0x0008 => in3
0x0010 => temp1 (1)
0x0020 => temp2
0x0040 => fan1
0x0080 => fan2
0x0100 => in4
0x0200 => in5 (?) (2)
0x0400 => in6 (?) (2)
0x0800 => fan3
0x1000 => chassis switch
0x2000 => temp3
Alarm Notes:
(1) This alarm will only trigger if the hysteresis value is 127C.
I.e. it behaves the same as w83781d.
(2) The min and max registers for these values appear to
be read-only or otherwise stuck at 0x00.
TODO:
* Experiment with fan divisors > 8.
* Experiment with temp. sensor types.
* Are there really 13 voltage inputs? Probably not...
* Cleanups, no doubt...
Documentation/i2c/chips/ds1621 0 → 100644
浏览文件 @ aef7b83c
Kernel driver ds1621
====================
Supported chips:
* Dallas Semiconductor DS1621
Prefix: 'ds1621'
Addresses scanned: I2C 0x48 - 0x4f
Datasheet: Publicly available at the Dallas Semiconductor website
http://www.dalsemi.com/
* Dallas Semiconductor DS1625
Prefix: 'ds1621'
Addresses scanned: I2C 0x48 - 0x4f
Datasheet: Publicly available at the Dallas Semiconductor website
http://www.dalsemi.com/
Authors:
Christian W. Zuckschwerdt <zany@triq.net>
valuable contributions by Jan M. Sendler <sendler@sendler.de>
ported to 2.6 by Aurelien Jarno <aurelien@aurel32.net>
with the help of Jean Delvare <khali@linux-fr.org>
Module Parameters
------------------
* polarity int
Output's polarity: 0 = active high, 1 = active low
Description
-----------
The DS1621 is a (one instance) digital thermometer and thermostat. It has
both high and low temperature limits which can be user defined (i.e.
programmed into non-volatile on-chip registers). Temperature range is -55
degree Celsius to +125 in 0.5 increments. You may convert this into a
Fahrenheit range of -67 to +257 degrees with 0.9 steps. If polarity
parameter is not provided, original value is used.
As for the thermostat, behavior can also be programmed using the polarity
toggle. On the one hand ("heater"), the thermostat output of the chip,
Tout, will trigger when the low limit temperature is met or underrun and
stays high until the high limit is met or exceeded. On the other hand
("cooler"), vice versa. That way "heater" equals "active low", whereas
"conditioner" equals "active high". Please note that the DS1621 data sheet
is somewhat misleading in this point since setting the polarity bit does
not simply invert Tout.
A second thing is that, during extensive testing, Tout showed a tolerance
of up to +/- 0.5 degrees even when compared against precise temperature
readings. Be sure to have a high vs. low temperature limit gap of al least
1.0 degree Celsius to avoid Tout "bouncing", though!
As for alarms, you can read the alarm status of the DS1621 via the 'alarms'
/sys file interface. The result consists mainly of bit 6 and 5 of the
configuration register of the chip; bit 6 (0x40 or 64) is the high alarm
bit and bit 5 (0x20 or 32) the low one. These bits are set when the high or
low limits are met or exceeded and are reset by the module as soon as the
respective temperature ranges are left.
The alarm registers are in no way suitable to find out about the actual
status of Tout. They will only tell you about its history, whether or not
any of the limits have ever been met or exceeded since last power-up or
reset. Be aware: When testing, it showed that the status of Tout can change
with neither of the alarms set.
Temperature conversion of the DS1621 takes up to 1000ms; internal access to
non-volatile registers may last for 10ms or below.
High Accuracy Temperature Reading
---------------------------------
As said before, the temperature issued via the 9-bit i2c-bus data is
somewhat arbitrary. Internally, the temperature conversion is of a
different kind that is explained (not so...) well in the DS1621 data sheet.
To cut the long story short: Inside the DS1621 there are two oscillators,
both of them biassed by a temperature coefficient.
Higher resolution of the temperature reading can be achieved using the
internal projection, which means taking account of REG_COUNT and REG_SLOPE
(the driver manages them):
Taken from Dallas Semiconductors App Note 068: 'Increasing Temperature
Resolution on the DS1620' and App Note 105: 'High Resolution Temperature
Measurement with Dallas Direct-to-Digital Temperature Sensors'
- Read the 9-bit temperature and strip the LSB (Truncate the .5 degs)
- The resulting value is TEMP_READ.
- Then, read REG_COUNT.
- And then, REG_SLOPE.
TEMP = TEMP_READ - 0.25 + ((REG_SLOPE - REG_COUNT) / REG_SLOPE)
Note that this is what the DONE bit in the DS1621 configuration register is
good for: Internally, one temperature conversion takes up to 1000ms. Before
that conversion is complete you will not be able to read valid things out
of REG_COUNT and REG_SLOPE. The DONE bit, as you may have guessed by now,
tells you whether the conversion is complete ("done", in plain English) and
thus, whether the values you read are good or not.
The DS1621 has two modes of operation: "Continuous" conversion, which can
be understood as the default stand-alone mode where the chip gets the
temperature and controls external devices via its Tout pin or tells other
i2c's about it if they care. The other mode is called "1SHOT", that means
that it only figures out about the temperature when it is explicitly told
to do so; this can be seen as power saving mode.
Now if you want to read REG_COUNT and REG_SLOPE, you have to either stop
the continuous conversions until the contents of these registers are valid,
or, in 1SHOT mode, you have to have one conversion made.
Documentation/i2c/chips/eeprom 0 → 100644
浏览文件 @ aef7b83c
Kernel driver eeprom
====================
Supported chips:
* Any EEPROM chip in the designated address range
Prefix: 'eeprom'
Addresses scanned: I2C 0x50 - 0x57
Datasheets: Publicly available from:
Atmel (www.atmel.com),
Catalyst (www.catsemi.com),
Fairchild (www.fairchildsemi.com),
Microchip (www.microchip.com),
Philips (www.semiconductor.philips.com),
Rohm (www.rohm.com),
ST (www.st.com),
Xicor (www.xicor.com),
and others.
Chip Size (bits) Address
24C01 1K 0x50 (shadows at 0x51 - 0x57)
24C01A 1K 0x50 - 0x57 (Typical device on DIMMs)
24C02 2K 0x50 - 0x57
24C04 4K 0x50, 0x52, 0x54, 0x56
(additional data at 0x51, 0x53, 0x55, 0x57)
24C08 8K 0x50, 0x54 (additional data at 0x51, 0x52,
0x53, 0x55, 0x56, 0x57)
24C16 16K 0x50 (additional data at 0x51 - 0x57)
Sony 2K 0x57
Atmel 34C02B 2K 0x50 - 0x57, SW write protect at 0x30-37
Catalyst 34FC02 2K 0x50 - 0x57, SW write protect at 0x30-37
Catalyst 34RC02 2K 0x50 - 0x57, SW write protect at 0x30-37
Fairchild 34W02 2K 0x50 - 0x57, SW write protect at 0x30-37
Microchip 24AA52 2K 0x50 - 0x57, SW write protect at 0x30-37
ST M34C02 2K 0x50 - 0x57, SW write protect at 0x30-37
Authors:
Frodo Looijaard <frodol@dds.nl>,
Philip Edelbrock <phil@netroedge.com>,
Jean Delvare <khali@linux-fr.org>,
Greg Kroah-Hartman <greg@kroah.com>,
IBM Corp.
Description
-----------
This is a simple EEPROM module meant to enable reading the first 256 bytes
of an EEPROM (on a SDRAM DIMM for example). However, it will access serial
EEPROMs on any I2C adapter. The supported devices are generically called
24Cxx, and are listed above; however the numbering for these
industry-standard devices may vary by manufacturer.
This module was a programming exercise to get used to the new project
organization laid out by Frodo, but it should be at least completely
effective for decoding the contents of EEPROMs on DIMMs.
DIMMS will typically contain a 24C01A or 24C02, or the 34C02 variants.
The other devices will not be found on a DIMM because they respond to more
than one address.
DDC Monitors may contain any device. Often a 24C01, which responds to all 8
addresses, is found.
Recent Sony Vaio laptops have an EEPROM at 0x57. We couldn't get the
specification, so it is guess work and far from being complete.
The Microchip 24AA52/24LCS52, ST M34C02, and others support an additional
software write protect register at 0x30 - 0x37 (0x20 less than the memory
location). The chip responds to "write quick" detection at this address but
does not respond to byte reads. If this register is present, the lower 128
bytes of the memory array are not write protected. Any byte data write to
this address will write protect the memory array permanently, and the
device will no longer respond at the 0x30-37 address. The eeprom driver
does not support this register.
Lacking functionality:
* Full support for larger devices (24C04, 24C08, 24C16). These are not
typically found on a PC. These devices will appear as separate devices at
multiple addresses.
* Support for really large devices (24C32, 24C64, 24C128, 24C256, 24C512).
These devices require two-byte address fields and are not supported.
* Enable Writing. Again, no technical reason why not, but making it easy
to change the contents of the EEPROMs (on DIMMs anyway) also makes it easy
to disable the DIMMs (potentially preventing the computer from booting)
until the values are restored somehow.
Use:
After inserting the module (and any other required SMBus/i2c modules), you
should have some EEPROM directories in /sys/bus/i2c/devices/* of names such
as "0-0050". Inside each of these is a series of files, the eeprom file
contains the binary data from EEPROM.
Documentation/i2c/chips/fscher 0 → 100644
浏览文件 @ aef7b83c
Kernel driver fscher
====================
Supported chips:
* Fujitsu-Siemens Hermes chip
Prefix: 'fscher'
Addresses scanned: I2C 0x73
Authors:
Reinhard Nissl <rnissl@gmx.de> based on work
from Hermann Jung <hej@odn.de>,
Frodo Looijaard <frodol@dds.nl>,
Philip Edelbrock <phil@netroedge.com>
Description
-----------
This driver implements support for the Fujitsu-Siemens Hermes chip. It is
described in the 'Register Set Specification BMC Hermes based Systemboard'
from Fujitsu-Siemens.
The Hermes chip implements a hardware-based system management, e.g. for
controlling fan speed and core voltage. There is also a watchdog counter on
the chip which can trigger an alarm and even shut the system down.
The chip provides three temperature values (CPU, motherboard and
auxiliary), three voltage values (+12V, +5V and battery) and three fans
(power supply, CPU and auxiliary).
Temperatures are measured in degrees Celsius. The resolution is 1 degree.
Fan rotation speeds are reported in RPM (rotations per minute). The value
can be divided by a programmable divider (1, 2 or 4) which is stored on
the chip.
Voltage sensors (also known as "in" sensors) report their values in volts.
All values are reported as final values from the driver. There is no need
for further calculations.
Detailed description
--------------------
Below you'll find a single line description of all the bit values. With
this information, you're able to decode e. g. alarms, wdog, etc. To make
use of the watchdog, you'll need to set the watchdog time and enable the
watchdog. After that it is necessary to restart the watchdog time within
the specified period of time, or a system reset will occur.
* revision
READING & 0xff = 0x??: HERMES revision identification
* alarms
READING & 0x80 = 0x80: CPU throttling active
READING & 0x80 = 0x00: CPU running at full speed
READING & 0x10 = 0x10: software event (see control:1)
READING & 0x10 = 0x00: no software event
READING & 0x08 = 0x08: watchdog event (see wdog:2)
READING & 0x08 = 0x00: no watchdog event
READING & 0x02 = 0x02: thermal event (see temp*:1)
READING & 0x02 = 0x00: no thermal event
READING & 0x01 = 0x01: fan event (see fan*:1)
READING & 0x01 = 0x00: no fan event
READING & 0x13 ! 0x00: ALERT LED is flashing
* control
READING & 0x01 = 0x01: software event
READING & 0x01 = 0x00: no software event
WRITING & 0x01 = 0x01: set software event
WRITING & 0x01 = 0x00: clear software event
* watchdog_control
READING & 0x80 = 0x80: power off on watchdog event while thermal event
READING & 0x80 = 0x00: watchdog power off disabled (just system reset enabled)
READING & 0x40 = 0x40: watchdog timebase 60 seconds (see also wdog:1)
READING & 0x40 = 0x00: watchdog timebase 2 seconds
READING & 0x10 = 0x10: watchdog enabled
READING & 0x10 = 0x00: watchdog disabled
WRITING & 0x80 = 0x80: enable "power off on watchdog event while thermal event"
WRITING & 0x80 = 0x00: disable "power off on watchdog event while thermal event"
WRITING & 0x40 = 0x40: set watchdog timebase to 60 seconds
WRITING & 0x40 = 0x00: set watchdog timebase to 2 seconds
WRITING & 0x20 = 0x20: disable watchdog
WRITING & 0x10 = 0x10: enable watchdog / restart watchdog time
* watchdog_state
READING & 0x02 = 0x02: watchdog system reset occurred
READING & 0x02 = 0x00: no watchdog system reset occurred
WRITING & 0x02 = 0x02: clear watchdog event
* watchdog_preset
READING & 0xff = 0x??: configured watch dog time in units (see wdog:3 0x40)
WRITING & 0xff = 0x??: configure watch dog time in units
* in* (0: +5V, 1: +12V, 2: onboard 3V battery)
READING: actual voltage value
* temp*_status (1: CPU sensor, 2: onboard sensor, 3: auxiliary sensor)
READING & 0x02 = 0x02: thermal event (overtemperature)
READING & 0x02 = 0x00: no thermal event
READING & 0x01 = 0x01: sensor is working
READING & 0x01 = 0x00: sensor is faulty
WRITING & 0x02 = 0x02: clear thermal event
* temp*_input (1: CPU sensor, 2: onboard sensor, 3: auxiliary sensor)
READING: actual temperature value
* fan*_status (1: power supply fan, 2: CPU fan, 3: auxiliary fan)
READING & 0x04 = 0x04: fan event (fan fault)
READING & 0x04 = 0x00: no fan event
WRITING & 0x04 = 0x04: clear fan event
* fan*_div (1: power supply fan, 2: CPU fan, 3: auxiliary fan)
Divisors 2,4 and 8 are supported, both for reading and writing
* fan*_pwm (1: power supply fan, 2: CPU fan, 3: auxiliary fan)
READING & 0xff = 0x00: fan may be switched off
READING & 0xff = 0x01: fan must run at least at minimum speed (supply: 6V)
READING & 0xff = 0xff: fan must run at maximum speed (supply: 12V)
READING & 0xff = 0x??: fan must run at least at given speed (supply: 6V..12V)
WRITING & 0xff = 0x00: fan may be switched off
WRITING & 0xff = 0x01: fan must run at least at minimum speed (supply: 6V)
WRITING & 0xff = 0xff: fan must run at maximum speed (supply: 12V)
WRITING & 0xff = 0x??: fan must run at least at given speed (supply: 6V..12V)
* fan*_input (1: power supply fan, 2: CPU fan, 3: auxiliary fan)
READING: actual RPM value
Limitations
-----------
* Measuring fan speed
It seems that the chip counts "ripples" (typical fans produce 2 ripples per
rotation while VERAX fans produce 18) in a 9-bit register. This register is
read out every second, then the ripple prescaler (2, 4 or 8) is applied and
the result is stored in the 8 bit output register. Due to the limitation of
the counting register to 9 bits, it is impossible to measure a VERAX fan
properly (even with a prescaler of 8). At its maximum speed of 3500 RPM the
fan produces 1080 ripples per second which causes the counting register to
overflow twice, leading to only 186 RPM.
* Measuring input voltages
in2 ("battery") reports the voltage of the onboard lithium battery and not
+3.3V from the power supply.
* Undocumented features
Fujitsu-Siemens Computers has not documented all features of the chip so
far. Their software, System Guard, shows that there are a still some
features which cannot be controlled by this implementation.
Documentation/i2c/chips/gl518sm 0 → 100644
浏览文件 @ aef7b83c
Kernel driver gl518sm
=====================
Supported chips:
* Genesys Logic GL518SM release 0x00
Prefix: 'gl518sm'
Addresses scanned: I2C 0x2c and 0x2d
Datasheet: http://www.genesyslogic.com/pdf
* Genesys Logic GL518SM release 0x80
Prefix: 'gl518sm'
Addresses scanned: I2C 0x2c and 0x2d
Datasheet: http://www.genesyslogic.com/pdf
Authors:
Frodo Looijaard <frodol@dds.nl>,
Kyösti Mälkki <kmalkki@cc.hut.fi>
Hong-Gunn Chew <hglinux@gunnet.org>
Jean Delvare <khali@linux-fr.org>
Description
-----------
IMPORTANT:
For the revision 0x00 chip, the in0, in1, and in2 values (+5V, +3V,
and +12V) CANNOT be read. This is a limitation of the chip, not the driver.
This driver supports the Genesys Logic GL518SM chip. There are at least
two revision of this chip, which we call revision 0x00 and 0x80. Revision
0x80 chips support the reading of all voltages and revision 0x00 only
for VIN3.
The GL518SM implements one temperature sensor, two fan rotation speed
sensors, and four voltage sensors. It can report alarms through the
computer speakers.
Temperatures are measured in degrees Celsius. An alarm goes off while the
temperature is above the over temperature limit, and has not yet dropped
below the hysteresis limit. The alarm always reflects the current
situation. Measurements are guaranteed between -10 degrees and +110
degrees, with a accuracy of +/-3 degrees.
Rotation speeds are reported in RPM (rotations per minute). An alarm is
triggered if the rotation speed has dropped below a programmable limit. In
case when you have selected to turn fan1 off, no fan1 alarm is triggered.
Fan readings can be divided by a programmable divider (1, 2, 4 or 8) to
give the readings more range or accuracy. Not all RPM values can
accurately be represented, so some rounding is done. With a divider
of 2, the lowest representable value is around 1900 RPM.
Voltage sensors (also known as VIN sensors) report their values in volts.
An alarm is triggered if the voltage has crossed a programmable minimum or
maximum limit. Note that minimum in this case always means 'closest to
zero'; this is important for negative voltage measurements. The VDD input
measures voltages between 0.000 and 5.865 volt, with a resolution of 0.023
volt. The other inputs measure voltages between 0.000 and 4.845 volt, with
a resolution of 0.019 volt. Note that revision 0x00 chips do not support
reading the current voltage of any input except for VIN3; limit setting and
alarms work fine, though.
When an alarm is triggered, you can be warned by a beeping signal through your
computer speaker. It is possible to enable all beeping globally, or only the
beeping for some alarms.
If an alarm triggers, it will remain triggered until the hardware register
is read at least once (except for temperature alarms). This means that the
cause for the alarm may already have disappeared! Note that in the current
implementation, all hardware registers are read whenever any data is read
(unless it is less than 1.5 seconds since the last update). This means that
you can easily miss once-only alarms.
The GL518SM only updates its values each 1.5 seconds; reading it more often
will do no harm, but will return 'old' values.
Documentation/i2c/chips/it87 0 → 100644
浏览文件 @ aef7b83c
Kernel driver it87
==================
Supported chips:
* IT8705F
Prefix: 'it87'
Addresses scanned: from Super I/O config space, or default ISA 0x290 (8 I/O ports)
Datasheet: Publicly available at the ITE website
http://www.ite.com.tw/
* IT8712F
Prefix: 'it8712'
Addresses scanned: I2C 0x28 - 0x2f
from Super I/O config space, or default ISA 0x290 (8 I/O ports)
Datasheet: Publicly available at the ITE website
http://www.ite.com.tw/
* SiS950 [clone of IT8705F]
Prefix: 'sis950'
Addresses scanned: from Super I/O config space, or default ISA 0x290 (8 I/O ports)
Datasheet: No longer be available
Author: Christophe Gauthron <chrisg@0-in.com>
Module Parameters
-----------------
* update_vbat: int
0 if vbat should report power on value, 1 if vbat should be updated after
each read. Default is 0. On some boards the battery voltage is provided
by either the battery or the onboard power supply. Only the first reading
at power on will be the actual battery voltage (which the chip does
automatically). On other boards the battery voltage is always fed to
the chip so can be read at any time. Excessive reading may decrease
battery life but no information is given in the datasheet.
* fix_pwm_polarity int
Force PWM polarity to active high (DANGEROUS). Some chips are
misconfigured by BIOS - PWM values would be inverted. This option tries
to fix this. Please contact your BIOS manufacturer and ask him for fix.
Description
-----------
This driver implements support for the IT8705F, IT8712F and SiS950 chips.
This driver also supports IT8712F, which adds SMBus access, and a VID
input, used to report the Vcore voltage of the Pentium processor.
The IT8712F additionally features VID inputs.
These chips are 'Super I/O chips', supporting floppy disks, infrared ports,
joysticks and other miscellaneous stuff. For hardware monitoring, they
include an 'environment controller' with 3 temperature sensors, 3 fan
rotation speed sensors, 8 voltage sensors, and associated alarms.
Temperatures are measured in degrees Celsius. An alarm is triggered once
when the Overtemperature Shutdown limit is crossed.
Fan rotation speeds are reported in RPM (rotations per minute). An alarm is
triggered if the rotation speed has dropped below a programmable limit. Fan
readings can be divided by a programmable divider (1, 2, 4 or 8) to give the
readings more range or accuracy. Not all RPM values can accurately be
represented, so some rounding is done. With a divider of 2, the lowest
representable value is around 2600 RPM.
Voltage sensors (also known as IN sensors) report their values in volts. An
alarm is triggered if the voltage has crossed a programmable minimum or
maximum limit. Note that minimum in this case always means 'closest to
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 only) 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.
If an alarm triggers, it will remain triggered until the hardware register
is read at least once. This means that the cause for the alarm may already
have disappeared! Note that in the current implementation, all hardware
registers are read whenever any data is read (unless it is less than 1.5
seconds since the last update). This means that you can easily miss
once-only alarms.
The IT87xx only updates its values each 1.5 seconds; reading it more often
will do no harm, but will return 'old' values.
To change sensor N to a thermistor, 'echo 2 > tempN_type' where N is 1, 2,
or 3. To change sensor N to a thermal diode, 'echo 3 > tempN_type'.
Give 0 for unused sensor. Any other value is invalid. To configure this at
startup, consult lm_sensors's /etc/sensors.conf. (2 = thermistor;
3 = thermal diode)
The fan speed control features are limited to manual PWM mode. Automatic
"Smart Guardian" mode control handling is not implemented. However
if you want to go for "manual mode" just write 1 to pwmN_enable.
Documentation/i2c/chips/lm63 0 → 100644
浏览文件 @ aef7b83c
Kernel driver lm63
==================
Supported chips:
* National Semiconductor LM63
Prefix: 'lm63'
Addresses scanned: I2C 0x4c
Datasheet: Publicly available at the National Semiconductor website
http://www.national.com/pf/LM/LM63.html
Author: Jean Delvare <khali@linux-fr.org>
Thanks go to Tyan and especially Alex Buckingham for setting up a remote
access to their S4882 test platform for this driver.
http://www.tyan.com/
Description
-----------
The LM63 is a digital temperature sensor with integrated fan monitoring
and control.
The LM63 is basically an LM86 with fan speed monitoring and control
capabilities added. It misses some of the LM86 features though:
- No low limit for local temperature.
- No critical limit for local temperature.
- Critical limit for remote temperature can be changed only once. We
will consider that the critical limit is read-only.
The datasheet isn't very clear about what the tachometer reading is.
An explanation from National Semiconductor: The two lower bits of the read
value have to be masked out. The value is still 16 bit in width.
All temperature values are given in degrees Celsius. Resolution is 1.0
degree for the local temperature, 0.125 degree for the remote temperature.
The fan speed is measured using a tachometer. Contrary to most chips which
store the value in an 8-bit register and have a selectable clock divider
to make sure that the result will fit in the register, the LM63 uses 16-bit
value for measuring the speed of the fan. It can measure fan speeds down to
83 RPM, at least in theory.
Note that the pin used for fan monitoring is shared with an alert out
function. Depending on how the board designer wanted to use the chip, fan
speed monitoring will or will not be possible. The proper chip configuration
is left to the BIOS, and the driver will blindly trust it.
A PWM output can be used to control the speed of the fan. The LM63 has two
PWM modes: manual and automatic. Automatic mode is not fully implemented yet
(you cannot define your custom PWM/temperature curve), and mode change isn't
supported either.
The lm63 driver will not update its values more frequently than every
second; reading them more often will do no harm, but will return 'old'
values.
Documentation/i2c/chips/lm75 0 → 100644
浏览文件 @ aef7b83c
Kernel driver lm75
==================
Supported chips:
* National Semiconductor LM75
Prefix: 'lm75'
Addresses scanned: I2C 0x48 - 0x4f
Datasheet: Publicly available at the National Semiconductor website
http://www.national.com/
* Dallas Semiconductor DS75
Prefix: 'lm75'
Addresses scanned: I2C 0x48 - 0x4f
Datasheet: Publicly available at the Dallas Semiconductor website
http://www.maxim-ic.com/
* Dallas Semiconductor DS1775
Prefix: 'lm75'
Addresses scanned: I2C 0x48 - 0x4f
Datasheet: Publicly available at the Dallas Semiconductor website
http://www.maxim-ic.com/
* Maxim MAX6625, MAX6626
Prefix: 'lm75'
Addresses scanned: I2C 0x48 - 0x4b
Datasheet: Publicly available at the Maxim website
http://www.maxim-ic.com/
* Microchip (TelCom) TCN75
Prefix: 'lm75'
Addresses scanned: I2C 0x48 - 0x4f
Datasheet: Publicly available at the Microchip website
http://www.microchip.com/
Author: Frodo Looijaard <frodol@dds.nl>
Description
-----------
The LM75 implements one temperature sensor. Limits can be set through the
Overtemperature Shutdown register and Hysteresis register. Each value can be
set and read to half-degree accuracy.
An alarm is issued (usually to a connected LM78) when the temperature
gets higher then the Overtemperature Shutdown value; it stays on until
the temperature falls below the Hysteresis value.
All temperatures are in degrees Celsius, and are guaranteed within a
range of -55 to +125 degrees.
The LM75 only updates its values each 1.5 seconds; reading it more often
will do no harm, but will return 'old' values.
The LM75 is usually used in combination with LM78-like chips, to measure
the temperature of the processor(s).
The DS75, DS1775, MAX6625, and MAX6626 are supported as well.
They are not distinguished from an LM75. While most of these chips
have three additional bits of accuracy (12 vs. 9 for the LM75),
the additional bits are not supported. Not only that, but these chips will
not be detected if not in 9-bit precision mode (use the force parameter if
needed).
The TCN75 is supported as well, and is not distinguished from an LM75.
The LM75 is essentially an industry standard; there may be other
LM75 clones not listed here, with or without various enhancements,
that are supported.
The LM77 is not supported, contrary to what we pretended for a long time.
Both chips are simply not compatible, value encoding differs.
Documentation/i2c/chips/lm77 0 → 100644
浏览文件 @ aef7b83c
Kernel driver lm77
==================
Supported chips:
* National Semiconductor LM77
Prefix: 'lm77'
Addresses scanned: I2C 0x48 - 0x4b
Datasheet: Publicly available at the National Semiconductor website
http://www.national.com/
Author: Andras BALI <drewie@freemail.hu>
Description
-----------
The LM77 implements one temperature sensor. The temperature
sensor incorporates a band-gap type temperature sensor,
10-bit ADC, and a digital comparator with user-programmable upper
and lower limit values.
Limits can be set through the Overtemperature Shutdown register and
Hysteresis register.
Documentation/i2c/chips/lm78 0 → 100644
浏览文件 @ aef7b83c
Kernel driver lm78
==================
Supported chips:
* National Semiconductor LM78
Prefix: 'lm78'
Addresses scanned: I2C 0x20 - 0x2f, ISA 0x290 (8 I/O ports)
Datasheet: Publicly available at the National Semiconductor website
http://www.national.com/
* National Semiconductor LM78-J
Prefix: 'lm78-j'
Addresses scanned: I2C 0x20 - 0x2f, ISA 0x290 (8 I/O ports)
Datasheet: Publicly available at the National Semiconductor website
http://www.national.com/
* National Semiconductor LM79
Prefix: 'lm79'
Addresses scanned: I2C 0x20 - 0x2f, ISA 0x290 (8 I/O ports)
Datasheet: Publicly available at the National Semiconductor website
http://www.national.com/
Author: Frodo Looijaard <frodol@dds.nl>
Description
-----------
This driver implements support for the National Semiconductor LM78, LM78-J
and LM79. They are described as 'Microprocessor System Hardware Monitors'.
There is almost no difference between the three supported chips. Functionally,
the LM78 and LM78-J are exactly identical. The LM79 has one more VID line,
which is used to report the lower voltages newer Pentium processors use.
From here on, LM7* means either of these three types.
The LM7* implements one temperature sensor, three fan rotation speed sensors,
seven voltage sensors, VID lines, alarms, and some miscellaneous stuff.
Temperatures are measured in degrees Celsius. An alarm is triggered once
when the Overtemperature Shutdown limit is crossed; it is triggered again
as soon as it drops below the Hysteresis value. A more useful behavior
can be found by setting the Hysteresis value to +127 degrees Celsius; in
this case, alarms are issued during all the time when the actual temperature
is above the Overtemperature Shutdown value. Measurements are guaranteed
between -55 and +125 degrees, with a resolution of 1 degree.
Fan rotation speeds are reported in RPM (rotations per minute). An alarm is
triggered if the rotation speed has dropped below a programmable limit. Fan
readings can be divided by a programmable divider (1, 2, 4 or 8) to give
the readings more range or accuracy. Not all RPM values can accurately be
represented, so some rounding is done. With a divider of 2, the lowest
representable value is around 2600 RPM.
Voltage sensors (also known as IN sensors) report their values in volts.
An alarm is triggered if the voltage has crossed a programmable minimum
or maximum limit. Note that minimum in this case always means 'closest to
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 VID lines 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. When it is unconnected, you will often find the
value 3.50 V here.
In addition to the alarms described above, there are a couple of additional
ones. There is a BTI alarm, which gets triggered when an external chip has
crossed its limits. Usually, this is connected to all LM75 chips; if at
least one crosses its limits, this bit gets set. The CHAS alarm triggers
if your computer case is open. The FIFO alarms should never trigger; it
indicates an internal error. The SMI_IN alarm indicates some other chip
has triggered an SMI interrupt. As we do not use SMI interrupts at all,
this condition usually indicates there is a problem with some other
device.
If an alarm triggers, it will remain triggered until the hardware register
is read at least once. This means that the cause for the alarm may
already have disappeared! Note that in the current implementation, all
hardware registers are read whenever any data is read (unless it is less
than 1.5 seconds since the last update). This means that you can easily
miss once-only alarms.
The LM7* only updates its values each 1.5 seconds; reading it more often
will do no harm, but will return 'old' values.
Documentation/i2c/chips/lm80 0 → 100644
浏览文件 @ aef7b83c
Kernel driver lm80
==================
Supported chips:
* National Semiconductor LM80
Prefix: 'lm80'
Addresses scanned: I2C 0x28 - 0x2f
Datasheet: Publicly available at the National Semiconductor website
http://www.national.com/
Authors:
Frodo Looijaard <frodol@dds.nl>,
Philip Edelbrock <phil@netroedge.com>
Description
-----------
This driver implements support for the National Semiconductor LM80.
It is described as a 'Serial Interface ACPI-Compatible Microprocessor
System Hardware Monitor'.
The LM80 implements one temperature sensor, two fan rotation speed sensors,
seven voltage sensors, alarms, and some miscellaneous stuff.
Temperatures are measured in degrees Celsius. There are two sets of limits
which operate independently. When the HOT Temperature Limit is crossed,
this will cause an alarm that will be reasserted until the temperature
drops below the HOT Hysteresis. The Overtemperature Shutdown (OS) limits
should work in the same way (but this must be checked; the datasheet
is unclear about this). Measurements are guaranteed between -55 and
+125 degrees. The current temperature measurement has a resolution of
0.0625 degrees; the limits have a resolution of 1 degree.
Fan rotation speeds are reported in RPM (rotations per minute). An alarm is
triggered if the rotation speed has dropped below a programmable limit. Fan
readings can be divided by a programmable divider (1, 2, 4 or 8) to give
the readings more range or accuracy. Not all RPM values can accurately be
represented, so some rounding is done. With a divider of 2, the lowest
representable value is around 2600 RPM.
Voltage sensors (also known as IN sensors) report their values in volts.
An alarm is triggered if the voltage has crossed a programmable minimum
or maximum limit. Note that minimum in this case always means 'closest to
zero'; this is important for negative voltage measurements. All voltage
inputs can measure voltages between 0 and 2.55 volts, with a resolution
of 0.01 volt.
If an alarm triggers, it will remain triggered until the hardware register
is read at least once. This means that the cause for the alarm may
already have disappeared! Note that in the current implementation, all
hardware registers are read whenever any data is read (unless it is less
than 2.0 seconds since the last update). This means that you can easily
miss once-only alarms.
The LM80 only updates its values each 1.5 seconds; reading it more often
will do no harm, but will return 'old' values.
Documentation/i2c/chips/lm83 0 → 100644
浏览文件 @ aef7b83c
Kernel driver lm83
==================
Supported chips:
* National Semiconductor LM83
Prefix: 'lm83'
Addresses scanned: I2C 0x18 - 0x1a, 0x29 - 0x2b, 0x4c - 0x4e
Datasheet: Publicly available at the National Semiconductor website
http://www.national.com/pf/LM/LM83.html
Author: Jean Delvare <khali@linux-fr.org>
Description
-----------
The LM83 is a digital temperature sensor. It senses its own temperature as
well as the temperature of up to three external diodes. It is compatible
with many other devices such as the LM84 and all other ADM1021 clones.
The main difference between the LM83 and the LM84 in that the later can
only sense the temperature of one external diode.
Using the adm1021 driver for a LM83 should work, but only two temperatures
will be reported instead of four.
The LM83 is only found on a handful of motherboards. Both a confirmed
list and an unconfirmed list follow. If you can confirm or infirm the
fact that any of these motherboards do actually have an LM83, please
contact us. Note that the LM90 can easily be misdetected as a LM83.
Confirmed motherboards:
SBS P014
Unconfirmed motherboards:
Gigabyte GA-8IK1100
Iwill MPX2
Soltek SL-75DRV5
The driver has been successfully tested by Magnus Forsström, who I'd
like to thank here. More testers will be of course welcome.
The fact that the LM83 is only scarcely used can be easily explained.
Most motherboards come with more than just temperature sensors for
health monitoring. They also have voltage and fan rotation speed
sensors. This means that temperature-only chips are usually used as
secondary chips coupled with another chip such as an IT8705F or similar
chip, which provides more features. Since systems usually need three
temperature sensors (motherboard, processor, power supply) and primary
chips provide some temperature sensors, the secondary chip, if needed,
won't have to handle more than two temperatures. Thus, ADM1021 clones
are sufficient, and there is no need for a four temperatures sensor
chip such as the LM83. The only case where using an LM83 would make
sense is on SMP systems, such as the above-mentioned Iwill MPX2,
because you want an additional temperature sensor for each additional
CPU.
On the SBS P014, this is different, since the LM83 is the only hardware
monitoring chipset. One temperature sensor is used for the motherboard
(actually measuring the LM83's own temperature), one is used for the
CPU. The two other sensors must be used to measure the temperature of
two other points of the motherboard. We suspect these points to be the
north and south bridges, but this couldn't be confirmed.
All temperature values are given in degrees Celsius. Local temperature
is given within a range of 0 to +85 degrees. Remote temperatures are
given within a range of 0 to +125 degrees. Resolution is 1.0 degree,
accuracy is guaranteed to 3.0 degrees (see the datasheet for more
details).
Each sensor has its own high limit, but the critical limit is common to
all four sensors. There is no hysteresis mechanism as found on most
recent temperature sensors.
The lm83 driver will not update its values more frequently than every
other second; reading them more often will do no harm, but will return
'old' values.
Documentation/i2c/chips/lm85 0 → 100644
浏览文件 @ aef7b83c
Kernel driver lm85
==================
Supported chips:
* National Semiconductor LM85 (B and C versions)
Prefix: 'lm85'
Addresses scanned: I2C 0x2c, 0x2d, 0x2e
Datasheet: http://www.national.com/pf/LM/LM85.html
* Analog Devices ADM1027
Prefix: 'adm1027'
Addresses scanned: I2C 0x2c, 0x2d, 0x2e
Datasheet: http://www.analog.com/en/prod/0,,766_825_ADM1027,00.html
* Analog Devices ADT7463
Prefix: 'adt7463'
Addresses scanned: I2C 0x2c, 0x2d, 0x2e
Datasheet: http://www.analog.com/en/prod/0,,766_825_ADT7463,00.html
* SMSC EMC6D100, SMSC EMC6D101
Prefix: 'emc6d100'
Addresses scanned: I2C 0x2c, 0x2d, 0x2e
Datasheet: http://www.smsc.com/main/tools/discontinued/6d100.pdf
* SMSC EMC6D102
Prefix: 'emc6d102'
Addresses scanned: I2C 0x2c, 0x2d, 0x2e
Datasheet: http://www.smsc.com/main/catalog/emc6d102.html
Authors:
Philip Pokorny <ppokorny@penguincomputing.com>,
Frodo Looijaard <frodol@dds.nl>,
Richard Barrington <rich_b_nz@clear.net.nz>,
Margit Schubert-While <margitsw@t-online.de>,
Justin Thiessen <jthiessen@penguincomputing.com>
Description
-----------
This driver implements support for the National Semiconductor LM85 and
compatible chips including the Analog Devices ADM1027, ADT7463 and
SMSC EMC6D10x chips family.
The LM85 uses the 2-wire interface compatible with the SMBUS 2.0
specification. Using an analog to digital converter it measures three (3)
temperatures and five (5) voltages. It has four (4) 16-bit counters for
measuring fan speed. Five (5) digital inputs are provided for sampling the
VID signals from the processor to the VRM. Lastly, there are three (3) PWM
outputs that can be used to control fan speed.
The voltage inputs have internal scaling resistors so that the following
voltage can be measured without external resistors:
2.5V, 3.3V, 5V, 12V, and CPU core voltage (2.25V)
The temperatures measured are one internal diode, and two remote diodes.
Remote 1 is generally the CPU temperature. These inputs are designed to
measure a thermal diode like the one in a Pentium 4 processor in a socket
423 or socket 478 package. They can also measure temperature using a
transistor like the 2N3904.
A sophisticated control system for the PWM outputs is designed into the
LM85 that allows fan speed to be adjusted automatically based on any of the
three temperature sensors. Each PWM output is individually adjustable and
programmable. Once configured, the LM85 will adjust the PWM outputs in
response to the measured temperatures without further host intervention.
This feature can also be disabled for manual control of the PWM's.
Each of the measured inputs (voltage, temperature, fan speed) has
corresponding high/low limit values. The LM85 will signal an ALARM if any
measured value exceeds either limit.
The LM85 samples all inputs continuously. The lm85 driver will not read
the registers more often than once a second. Further, configuration data is
only read once each 5 minutes. There is twice as much config data as
measurements, so this would seem to be a worthwhile optimization.
Special Features
----------------
The LM85 has four fan speed monitoring modes. The ADM1027 has only two.
Both have special circuitry to compensate for PWM interactions with the
TACH signal from the fans. The ADM1027 can be configured to measure the
speed of a two wire fan, but the input conditioning circuitry is different
for 3-wire and 2-wire mode. For this reason, the 2-wire fan modes are not
exposed to user control. The BIOS should initialize them to the correct
mode. If you've designed your own ADM1027, you'll have to modify the
init_client function and add an insmod parameter to set this up.
To smooth the response of fans to changes in temperature, the LM85 has an
optional filter for smoothing temperatures. The ADM1027 has the same
config option but uses it to rate limit the changes to fan speed instead.
The ADM1027 and ADT7463 have a 10-bit ADC and can therefore measure
temperatures with 0.25 degC resolution. They also provide an offset to the
temperature readings that is automatically applied during measurement.
This offset can be used to zero out any errors due to traces and placement.
The documentation says that the offset is in 0.25 degC steps, but in
initial testing of the ADM1027 it was 1.00 degC steps. Analog Devices has
confirmed this "bug". The ADT7463 is reported to work as described in the
documentation. The current lm85 driver does not show the offset register.
The ADT7463 has a THERM asserted counter. This counter has a 22.76ms
resolution and a range of 5.8 seconds. The driver implements a 32-bit
accumulator of the counter value to extend the range to over a year. The
counter will stay at it's max value until read.
See the vendor datasheets for more information. There is application note
from National (AN-1260) with some additional information about the LM85.
The Analog Devices datasheet is very detailed and describes a procedure for
determining an optimal configuration for the automatic PWM control.
The SMSC EMC6D100 & EMC6D101 monitor external voltages, temperatures, and
fan speeds. They use this monitoring capability to alert the system to out
of limit conditions and can automatically control the speeds of multiple
fans in a PC or embedded system. The EMC6D101, available in a 24-pin SSOP
package, and the EMC6D100, available in a 28-pin SSOP package, are designed
to be register compatible. The EMC6D100 offers all the features of the
EMC6D101 plus additional voltage monitoring and system control features.
Unfortunately it is not possible to distinguish between the package
versions on register level so these additional voltage inputs may read
zero. The EMC6D102 features addtional ADC bits thus extending precision
of voltage and temperature channels.
Hardware Configurations
-----------------------
The LM85 can be jumpered for 3 different SMBus addresses. There are
no other hardware configuration options for the LM85.
The lm85 driver detects both LM85B and LM85C revisions of the chip. See the
datasheet for a complete description of the differences. Other than
identifying the chip, the driver behaves no differently with regard to
these two chips. The LM85B is recommended for new designs.
The ADM1027 and ADT7463 chips have an optional SMBALERT output that can be
used to signal the chipset in case a limit is exceeded or the temperature
sensors fail. Individual sensor interrupts can be masked so they won't
trigger SMBALERT. The SMBALERT output if configured replaces one of the other
functions (PWM2 or IN0). This functionality is not implemented in current
driver.
The ADT7463 also has an optional THERM output/input which can be connected
to the processor PROC_HOT output. If available, the autofan control
dynamic Tmin feature can be enabled to keep the system temperature within
spec (just?!) with the least possible fan noise.
Configuration Notes
-------------------
Besides standard interfaces driver adds following:
* Temperatures and Zones
Each temperature sensor is associated with a Zone. There are three
sensors and therefore three zones (# 1, 2 and 3). Each zone has the following
temperature configuration points:
* temp#_auto_temp_off - temperature below which fans should be off or spinning very low.
* temp#_auto_temp_min - temperature over which fans start to spin.
* temp#_auto_temp_max - temperature when fans spin at full speed.
* temp#_auto_temp_crit - temperature when all fans will run full speed.
* PWM Control
There are three PWM outputs. The LM85 datasheet suggests that the
pwm3 output control both fan3 and fan4. Each PWM can be individually
configured and assigned to a zone for it's control value. Each PWM can be
configured individually according to the following options.
* pwm#_auto_pwm_min - this specifies the PWM value for temp#_auto_temp_off
temperature. (PWM value from 0 to 255)
* pwm#_auto_pwm_freq - select base frequency of PWM output. You can select
in range of 10.0 to 94.0 Hz in .1 Hz units.
(Values 100 to 940).
The pwm#_auto_pwm_freq can be set to one of the following 8 values. Setting the
frequency to a value not on this list, will result in the next higher frequency
being selected. The actual device frequency may vary slightly from this
specification as designed by the manufacturer. Consult the datasheet for more
details. (PWM Frequency values: 100, 150, 230, 300, 380, 470, 620, 940)
* pwm#_auto_pwm_minctl - this flags selects for temp#_auto_temp_off temperature
the bahaviour 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
to be associated with the zones not the PWMs. This contradicts all the
published documentation. Setting pwm#_min_ctl in this case actually affects all
PWMs controlled by zone '#'.
* PWM Controlling Zone selection
* pwm#_auto_channels - controls zone that is associated with PWM
Configuration choices:
Value Meaning
------ ------------------------------------------------
1 Controlled by Zone 1
2 Controlled by Zone 2
3 Controlled by Zone 3
23 Controlled by higher temp of Zone 2 or 3
123 Controlled by highest temp of Zone 1, 2 or 3
0 PWM always 0% (off)
-1 PWM always 100% (full on)
-2 Manual control (write to 'pwm#' to set)
The National LM85's have two vendor specific configuration
features. Tach. mode and Spinup Control. For more details on these,
see the LM85 datasheet or Application Note AN-1260.
The Analog Devices ADM1027 has several vendor specific enhancements.
The number of pulses-per-rev of the fans can be set, Tach monitoring
can be optimized for PWM operation, and an offset can be applied to
the temperatures to compensate for systemic errors in the
measurements.
In addition to the ADM1027 features, the ADT7463 also has Tmin control
and THERM asserted counts. Automatic Tmin control acts to adjust the
Tmin value to maintain the measured temperature sensor at a specified
temperature. There isn't much documentation on this feature in the
ADT7463 data sheet. This is not supported by current driver.
Documentation/i2c/chips/lm87 0 → 100644
浏览文件 @ aef7b83c
Kernel driver lm87
==================
Supported chips:
* National Semiconductor LM87
Prefix: 'lm87'
Addresses scanned: I2C 0x2c - 0x2f
Datasheet: http://www.national.com/pf/LM/LM87.html
Authors:
Frodo Looijaard <frodol@dds.nl>,
Philip Edelbrock <phil@netroedge.com>,
Mark Studebaker <mdsxyz123@yahoo.com>,
Stephen Rousset <stephen.rousset@rocketlogix.com>,
Dan Eaton <dan.eaton@rocketlogix.com>,
Jean Delvare <khali@linux-fr.org>,
Original 2.6 port Jeff Oliver
Description
-----------
This driver implements support for the National Semiconductor LM87.
The LM87 implements up to three temperature sensors, up to two fan
rotation speed sensors, up to seven voltage sensors, alarms, and some
miscellaneous stuff.
Temperatures are measured in degrees Celsius. Each input has a high
and low alarm settings. A high limit produces an alarm when the value
goes above it, and an alarm is also produced when the value goes below
the low limit.
Fan rotation speeds are reported in RPM (rotations per minute). An alarm is
triggered if the rotation speed has dropped below a programmable limit. Fan
readings can be divided by a programmable divider (1, 2, 4 or 8) to give
the readings more range or accuracy. Not all RPM values can accurately be
represented, so some rounding is done. With a divider of 2, the lowest
representable value is around 2600 RPM.
Voltage sensors (also known as IN sensors) report their values in
volts. An alarm is triggered if the voltage has crossed a programmable
minimum or maximum limit. Note that minimum in this case always means
'closest to zero'; this is important for negative voltage measurements.
If an alarm triggers, it will remain triggered until the hardware register
is read at least once. This means that the cause for the alarm may
already have disappeared! Note that in the current implementation, all
hardware registers are read whenever any data is read (unless it is less
than 1.0 seconds since the last update). This means that you can easily
miss once-only alarms.
The lm87 driver only updates its values each 1.0 seconds; reading it more
often will do no harm, but will return 'old' values.
Hardware Configurations
-----------------------
The LM87 has four pins which can serve one of two possible functions,
depending on the hardware configuration.
Some functions share pins, so not all functions are available at the same
time. Which are depends on the hardware setup. This driver assumes that
the BIOS configured the chip correctly. In that respect, it differs from
the original driver (from lm_sensors for Linux 2.4), which would force the
LM87 to an arbitrary, compile-time chosen mode, regardless of the actual
chipset wiring.
For reference, here is the list of exclusive functions:
- in0+in5 (default) or temp3
- fan1 (default) or in6
- fan2 (default) or in7
- VID lines (default) or IRQ lines (not handled by this driver)
Documentation/i2c/chips/lm90 0 → 100644
浏览文件 @ aef7b83c
Kernel driver lm90
==================
Supported chips:
* National Semiconductor LM90
Prefix: 'lm90'
Addresses scanned: I2C 0x4c
Datasheet: Publicly available at the National Semiconductor website
http://www.national.com/pf/LM/LM90.html
* National Semiconductor LM89
Prefix: 'lm99'
Addresses scanned: I2C 0x4c and 0x4d
Datasheet: Publicly available at the National Semiconductor website
http://www.national.com/pf/LM/LM89.html
* National Semiconductor LM99
Prefix: 'lm99'
Addresses scanned: I2C 0x4c and 0x4d
Datasheet: Publicly available at the National Semiconductor website
http://www.national.com/pf/LM/LM99.html
* National Semiconductor LM86
Prefix: 'lm86'
Addresses scanned: I2C 0x4c
Datasheet: Publicly available at the National Semiconductor website
http://www.national.com/pf/LM/LM86.html
* Analog Devices ADM1032
Prefix: 'adm1032'
Addresses scanned: I2C 0x4c
Datasheet: Publicly available at the Analog Devices website
http://products.analog.com/products/info.asp?product=ADM1032
* Analog Devices ADT7461
Prefix: 'adt7461'
Addresses scanned: I2C 0x4c
Datasheet: Publicly available at the Analog Devices website
http://products.analog.com/products/info.asp?product=ADT7461
Note: Only if in ADM1032 compatibility mode
* Maxim MAX6657
Prefix: 'max6657'
Addresses scanned: I2C 0x4c
Datasheet: Publicly available at the Maxim website
http://www.maxim-ic.com/quick_view2.cfm/qv_pk/2578
* Maxim MAX6658
Prefix: 'max6657'
Addresses scanned: I2C 0x4c
Datasheet: Publicly available at the Maxim website
http://www.maxim-ic.com/quick_view2.cfm/qv_pk/2578
* Maxim MAX6659
Prefix: 'max6657'
Addresses scanned: I2C 0x4c, 0x4d (unsupported 0x4e)
Datasheet: Publicly available at the Maxim website
http://www.maxim-ic.com/quick_view2.cfm/qv_pk/2578
Author: Jean Delvare <khali@linux-fr.org>
Description
-----------
The LM90 is a digital temperature sensor. It senses its own temperature as
well as the temperature of up to one external diode. It is compatible
with many other devices such as the LM86, the LM89, the LM99, the ADM1032,
the MAX6657, MAX6658 and the MAX6659 all of which are supported by this driver.
Note that there is no easy way to differentiate between the last three
variants. The extra address and features of the MAX6659 are not supported by
this driver. Additionally, the ADT7461 is supported if found in ADM1032
compatibility mode.
The specificity of this family of chipsets over the ADM1021/LM84
family is that it features critical limits with hysteresis, and an
increased resolution of the remote temperature measurement.
The different chipsets of the family are not strictly identical, although
very similar. This driver doesn't handle any specific feature for now,
but could if there ever was a need for it. For reference, here comes a
non-exhaustive list of specific features:
LM90:
* Filter and alert configuration register at 0xBF.
* ALERT is triggered by temperatures over critical limits.
LM86 and LM89:
* Same as LM90
* Better external channel accuracy
LM99:
* Same as LM89
* External temperature shifted by 16 degrees down
ADM1032:
* Consecutive alert register at 0x22.
* Conversion averaging.
* Up to 64 conversions/s.
* ALERT is triggered by open remote sensor.
ADT7461
* Extended temperature range (breaks compatibility)
* Lower resolution for remote temperature
MAX6657 and MAX6658:
* Remote sensor type selection
MAX6659
* Selectable address
* Second critical temperature limit
* Remote sensor type selection
All temperature values are given in degrees Celsius. Resolution
is 1.0 degree for the local temperature, 0.125 degree for the remote
temperature.
Each sensor has its own high and low limits, plus a critical limit.
Additionally, there is a relative hysteresis value common to both critical
values. To make life easier to user-space applications, two absolute values
are exported, one for each channel, but these values are of course linked.
Only the local hysteresis can be set from user-space, and the same delta
applies to the remote hysteresis.
The lm90 driver will not update its values more frequently than every
other second; reading them more often will do no harm, but will return
'old' values.
Documentation/i2c/chips/lm92 0 → 100644
浏览文件 @ aef7b83c
Kernel driver lm92
==================
Supported chips:
* National Semiconductor LM92
Prefix: 'lm92'
Addresses scanned: I2C 0x48 - 0x4b
Datasheet: http://www.national.com/pf/LM/LM92.html
* National Semiconductor LM76
Prefix: 'lm92'
Addresses scanned: none, force parameter needed
Datasheet: http://www.national.com/pf/LM/LM76.html
* Maxim MAX6633/MAX6634/MAX6635
Prefix: 'lm92'
Addresses scanned: I2C 0x48 - 0x4b
MAX6633 with address in 0x40 - 0x47, 0x4c - 0x4f needs force parameter
and MAX6634 with address in 0x4c - 0x4f needs force parameter
Datasheet: http://www.maxim-ic.com/quick_view2.cfm/qv_pk/3074
Authors:
Abraham van der Merwe <abraham@2d3d.co.za>
Jean Delvare <khali@linux-fr.org>
Description
-----------
This driver implements support for the National Semiconductor LM92
temperature sensor.
Each LM92 temperature sensor supports a single temperature sensor. There are
alarms for high, low, and critical thresholds. There's also an hysteresis to
control the thresholds for resetting alarms.
Support was added later for the LM76 and Maxim MAX6633/MAX6634/MAX6635,
which are mostly compatible. They have not all been tested, so you
may need to use the force parameter.
Documentation/i2c/chips/max1619 0 → 100644
浏览文件 @ aef7b83c
Kernel driver max1619
=====================
Supported chips:
* Maxim MAX1619
Prefix: 'max1619'
Addresses scanned: I2C 0x18-0x1a, 0x29-0x2b, 0x4c-0x4e
Datasheet: Publicly available at the Maxim website
http://pdfserv.maxim-ic.com/en/ds/MAX1619.pdf
Authors:
Alexey Fisher <fishor@mail.ru>,
Jean Delvare <khali@linux-fr.org>
Description
-----------
The MAX1619 is a digital temperature sensor. It senses its own temperature as
well as the temperature of up to one external diode.
All temperature values are given in degrees Celsius. Resolution
is 1.0 degree for the local temperature and for the remote temperature.
Only the external sensor has high and low limits.
The max1619 driver will not update its values more frequently than every
other second; reading them more often will do no harm, but will return
'old' values.
Documentation/i2c/chips/max6875 0 → 100644
浏览文件 @ aef7b83c
Kernel driver max6875
=====================
Supported chips:
* Maxim max6874, max6875
Prefixes: 'max6875'
Addresses scanned: 0x50, 0x52
Datasheets:
http://pdfserv.maxim-ic.com/en/ds/MAX6874-MAX6875.pdf
Author: Ben Gardner <bgardner@wabtec.com>
Module Parameters
-----------------
* allow_write int
Set to non-zero to enable write permission:
*0: Read only
1: Read and write
Description
-----------
The MAXIM max6875 is a EEPROM-programmable power-supply sequencer/supervisor.
It provides timed outputs that can be used as a watchdog, if properly wired.
It also provides 512 bytes of user EEPROM.
At reset, the max6875 reads the configuration eeprom into its configuration
registers. The chip then begins to operate according to the values in the
registers.
See the datasheet for details on how to program the EEPROM.
Sysfs entries
-------------
eeprom_user - 512 bytes of user-defined EEPROM space. Only writable if
allow_write was set and register 0x43 is 0.
eeprom_config - 70 bytes of config EEPROM. Note that changes will not get
loaded into register space until a power cycle or device reset.
reg_config - 70 bytes of register space. Any changes take affect immediately.
General Remarks
---------------
A typical application will require that the EEPROMs be programmed once and
never altered afterwards.
Documentation/i2c/chips/pc87360 0 → 100644
浏览文件 @ aef7b83c
Kernel driver pc87360
=====================
Supported chips:
* National Semiconductor PC87360, PC87363, PC87364, PC87365 and PC87366
Prefixes: 'pc87360', 'pc87363', 'pc87364', 'pc87365', 'pc87366'
Addresses scanned: none, address read from Super I/O config space
Datasheets:
http://www.national.com/pf/PC/PC87360.html
http://www.national.com/pf/PC/PC87363.html
http://www.national.com/pf/PC/PC87364.html
http://www.national.com/pf/PC/PC87365.html
http://www.national.com/pf/PC/PC87366.html
Authors: Jean Delvare <khali@linux-fr.org>
Thanks to Sandeep Mehta, Tonko de Rooy and Daniel Ceregatti for testing.
Thanks to Rudolf Marek for helping me investigate conversion issues.
Module Parameters
-----------------
* init int
Chip initialization level:
0: None
*1: Forcibly enable internal voltage and temperature channels, except in9
2: Forcibly enable all voltage and temperature channels, except in9
3: Forcibly enable all voltage and temperature channels, including in9
Note that this parameter has no effect for the PC87360, PC87363 and PC87364
chips.
Also note that for the PC87366, initialization levels 2 and 3 don't enable
all temperature channels, because some of them share pins with each other,
so they can't be used at the same time.
Description
-----------
The National Semiconductor PC87360 Super I/O chip contains monitoring and
PWM control circuitry for two fans. The PC87363 chip is similar, and the
PC87364 chip has monitoring and PWM control for a third fan.
The National Semiconductor PC87365 and PC87366 Super I/O chips are complete
hardware monitoring chipsets, not only controlling and monitoring three fans,
but also monitoring eleven voltage inputs and two (PC87365) or up to four
(PC87366) temperatures.
Chip #vin #fan #pwm #temp devid
PC87360 - 2 2 - 0xE1
PC87363 - 2 2 - 0xE8
PC87364 - 3 3 - 0xE4
PC87365 11 3 3 2 0xE5
PC87366 11 3 3 3-4 0xE9
The driver assumes that no more than one chip is present, and one of the
standard Super I/O addresses is used (0x2E/0x2F or 0x4E/0x4F)
Fan Monitoring
--------------
Fan rotation speeds are reported in RPM (revolutions per minute). An alarm
is triggered if the rotation speed has dropped below a programmable limit.
A different alarm is triggered if the fan speed is too low to be measured.
Fan readings are affected by a programmable clock divider, giving the
readings more range or accuracy. Usually, users have to learn how it works,
but this driver implements dynamic clock divider selection, so you don't
have to care no more.
For reference, here are a few values about clock dividers:
slowest accuracy highest
measurable around 3000 accurate
divider speed (RPM) RPM (RPM) speed (RPM)
1 1882 18 6928
2 941 37 4898
4 470 74 3464
8 235 150 2449
For the curious, here is how the values above were computed:
* slowest measurable speed: clock/(255*divider)
* accuracy around 3000 RPM: 3000^2/clock
* highest accurate speed: sqrt(clock*100)
The clock speed for the PC87360 family is 480 kHz. I arbitrarily chose 100
RPM as the lowest acceptable accuracy.
As mentioned above, you don't have to care about this no more.
Note that not all RPM values can be represented, even when the best clock
divider is selected. This is not only true for the measured speeds, but
also for the programmable low limits, so don't be surprised if you try to
set, say, fan1_min to 2900 and it finally reads 2909.
Fan Control
-----------
PWM (pulse width modulation) values range from 0 to 255, with 0 meaning
that the fan is stopped, and 255 meaning that the fan goes at full speed.
Be extremely careful when changing PWM values. Low PWM values, even
non-zero, can stop the fan, which may cause irreversible damage to your
hardware if temperature increases too much. When changing PWM values, go
step by step and keep an eye on temperatures.
One user reported problems with PWM. Changing PWM values would break fan
speed readings. No explanation nor fix could be found.
Temperature Monitoring
----------------------
Temperatures are reported in degrees Celsius. Each temperature measured has
associated low, high and overtemperature limits, each of which triggers an
alarm when crossed.
The first two temperature channels are external. The third one (PC87366
only) is internal.
The PC87366 has three additional temperature channels, based on
thermistors (as opposed to thermal diodes for the first three temperature
channels). For technical reasons, these channels are held by the VLM
(voltage level monitor) logical device, not the TMS (temperature
measurement) one. As a consequence, these temperatures are exported as
voltages, and converted into temperatures in user-space.
Note that these three additional channels share their pins with the
external thermal diode channels, so you (physically) can't use them all at
the same time. Although it should be possible to mix the two sensor types,
the documents from National Semiconductor suggest that motherboard
manufacturers should choose one type and stick to it. So you will more
likely have either channels 1 to 3 (thermal diodes) or 3 to 6 (internal
thermal diode, and thermistors).
Voltage Monitoring
------------------
Voltages are reported relatively to a reference voltage, either internal or
external. Some of them (in7:Vsb, in8:Vdd and in10:AVdd) are divided by two
internally, you will have to compensate in sensors.conf. Others (in0 to in6)
are likely to be divided externally. The meaning of each of these inputs as
well as the values of the resistors used for division is left to the
motherboard manufacturers, so you will have to document yourself and edit
sensors.conf accordingly. National Semiconductor has a document with
recommended resistor values for some voltages, but this still leaves much
room for per motherboard specificities, unfortunately. Even worse,
motherboard manufacturers don't seem to care about National Semiconductor's
recommendations.
Each voltage measured has associated low and high limits, each of which
triggers an alarm when crossed.
When available, VID inputs are used to provide the nominal CPU Core voltage.
The driver will default to VRM 9.0, but this can be changed from user-space.
The chipsets can handle two sets of VID inputs (on dual-CPU systems), but
the driver will only export one for now. This may change later if there is
a need.
General Remarks
---------------
If an alarm triggers, it will remain triggered until the hardware register
is read at least once. This means that the cause for the alarm may already
have disappeared! Note that all hardware registers are read whenever any
data is read (unless it is less than 2 seconds since the last update, in
which case cached values are returned instead). As a consequence, when
a once-only alarm triggers, it may take 2 seconds for it to show, and 2
more seconds for it to disappear.
Monitoring of in9 isn't enabled at lower init levels (<3) because that
channel measures the battery voltage (Vbat). It is a known fact that
repeatedly sampling the battery voltage reduces its lifetime. National
Semiconductor smartly designed their chipset so that in9 is sampled only
once every 1024 sampling cycles (that is every 34 minutes at the default
sampling rate), so the effect is attenuated, but still present.
Limitations
-----------
The datasheets suggests that some values (fan mins, fan dividers)
shouldn't be changed once the monitoring has started, but we ignore that
recommendation. We'll reconsider if it actually causes trouble.
Documentation/i2c/chips/pca9539 0 → 100644
浏览文件 @ aef7b83c
Kernel driver pca9539
=====================
Supported chips:
* Philips PCA9539
Prefix: 'pca9539'
Addresses scanned: 0x74 - 0x77
Datasheet:
http://www.semiconductors.philips.com/acrobat/datasheets/PCA9539_2.pdf
Author: Ben Gardner <bgardner@wabtec.com>
Description
-----------
The Philips PCA9539 is a 16 bit low power I/O device.
All 16 lines can be individually configured as an input or output.
The input sense can also be inverted.
The 16 lines are split between two bytes.
Sysfs entries
-------------
Each is a byte that maps to the 8 I/O bits.
A '0' suffix is for bits 0-7, while '1' is for bits 8-15.
input[01] - read the current value
output[01] - sets the output value
direction[01] - direction of each bit: 1=input, 0=output
invert[01] - toggle the input bit sense
input reads the actual state of the line and is always available.
The direction defaults to input for all channels.
General Remarks
---------------
Note that each output, direction, and invert entry controls 8 lines.
You should use the read, modify, write sequence.
For example. to set output bit 0 of 1.
val=$(cat output0)
val=$(( $val | 1 ))
echo $val > output0
Documentation/i2c/chips/pcf8574 0 → 100644
浏览文件 @ aef7b83c
Kernel driver pcf8574
=====================
Supported chips:
* Philips PCF8574
Prefix: 'pcf8574'
Addresses scanned: I2C 0x20 - 0x27
Datasheet: Publicly available at the Philips Semiconductors website
http://www.semiconductors.philips.com/pip/PCF8574P.html
* Philips PCF8574A
Prefix: 'pcf8574a'
Addresses scanned: I2C 0x38 - 0x3f
Datasheet: Publicly available at the Philips Semiconductors website
http://www.semiconductors.philips.com/pip/PCF8574P.html
Authors:
Frodo Looijaard <frodol@dds.nl>,
Philip Edelbrock <phil@netroedge.com>,
Dan Eaton <dan.eaton@rocketlogix.com>,
Aurelien Jarno <aurelien@aurel32.net>,
Jean Delvare <khali@linux-fr.org>,
Description
-----------
The PCF8574(A) is an 8-bit I/O expander for the I2C bus produced by Philips
Semiconductors. It is designed to provide a byte I2C interface to up to 16
separate devices (8 x PCF8574 and 8 x PCF8574A).
This device consists of a quasi-bidirectional port. Each of the eight I/Os
can be independently used as an input or output. To setup an I/O as an
input, you have to write a 1 to the corresponding output.
For more informations see the datasheet.
Accessing PCF8574(A) via /sys interface
-------------------------------------
! Be careful !
The PCF8574(A) is plainly impossible to detect ! Stupid chip.
So every chip with address in the interval [20..27] and [38..3f] are
detected as PCF8574(A). If you have other chips in this address
range, the workaround is to load this module after the one
for your others chips.
On detection (i.e. insmod, modprobe et al.), directories are being
created for each detected PCF8574(A):
/sys/bus/i2c/devices/<0>-<1>/
where <0> is the bus the chip was detected on (e. g. i2c-0)
and <1> the chip address ([20..27] or [38..3f]):
(example: /sys/bus/i2c/devices/1-0020/)
Inside these directories, there are two files each:
read and write (and one file with chip name).
The read file is read-only. Reading gives you the current I/O input
if the corresponding output is set as 1, otherwise the current output
value, that is to say 0.
The write file is read/write. Writing a value outputs it on the I/O
port. Reading returns the last written value.
On module initialization the chip is configured as eight inputs (all
outputs to 1), so you can connect any circuit to the PCF8574(A) without
being afraid of short-circuit.
Documentation/i2c/chips/pcf8591 0 → 100644
浏览文件 @ aef7b83c
Kernel driver pcf8591
=====================
Supported chips:
* Philips PCF8591
Prefix: 'pcf8591'
Addresses scanned: I2C 0x48 - 0x4f
Datasheet: Publicly available at the Philips Semiconductor website
http://www.semiconductors.philips.com/pip/PCF8591P.html
Authors:
Aurelien Jarno <aurelien@aurel32.net>
valuable contributions by Jan M. Sendler <sendler@sendler.de>,
Jean Delvare <khali@linux-fr.org>
Description
-----------
The PCF8591 is an 8-bit A/D and D/A converter (4 analog inputs and one
analog output) for the I2C bus produced by Philips Semiconductors. It
is designed to provide a byte I2C interface to up to 4 separate devices.
The PCF8591 has 4 analog inputs programmable as single-ended or
differential inputs :
- mode 0 : four single ended inputs
Pins AIN0 to AIN3 are single ended inputs for channels 0 to 3
- mode 1 : three differential inputs
Pins AIN3 is the common negative differential input
Pins AIN0 to AIN2 are positive differential inputs for channels 0 to 2
- mode 2 : single ended and differential mixed
Pins AIN0 and AIN1 are single ended inputs for channels 0 and 1
Pins AIN2 is the positive differential input for channel 3
Pins AIN3 is the negative differential input for channel 3
- mode 3 : two differential inputs
Pins AIN0 is the positive differential input for channel 0
Pins AIN1 is the negative differential input for channel 0
Pins AIN2 is the positive differential input for channel 1
Pins AIN3 is the negative differential input for channel 1
See the datasheet for details.
Module parameters
-----------------
* input_mode int
Analog input mode:
0 = four single ended inputs
1 = three differential inputs
2 = single ended and differential mixed
3 = two differential inputs
Accessing PCF8591 via /sys interface
-------------------------------------
! Be careful !
The PCF8591 is plainly impossible to detect ! Stupid chip.
So every chip with address in the interval [48..4f] is
detected as PCF8591. If you have other chips in this address
range, the workaround is to load this module after the one
for your others chips.
On detection (i.e. insmod, modprobe et al.), directories are being
created for each detected PCF8591:
/sys/bus/devices/<0>-<1>/
where <0> is the bus the chip was detected on (e. g. i2c-0)
and <1> the chip address ([48..4f])
Inside these directories, there are such files:
in0, in1, in2, in3, out0_enable, out0_output, name
Name contains chip name.
The in0, in1, in2 and in3 files are RO. Reading gives the value of the
corresponding channel. Depending on the current analog inputs configuration,
files in2 and/or in3 do not exist. Values range are from 0 to 255 for single
ended inputs and -128 to +127 for differential inputs (8-bit ADC).
The out0_enable file is RW. Reading gives "1" for analog output enabled and
"0" for analog output disabled. Writing accepts "0" and "1" accordingly.
The out0_output file is RW. Writing a number between 0 and 255 (8-bit DAC), send
the value to the digital-to-analog converter. Note that a voltage will
only appears on AOUT pin if aout0_enable equals 1. Reading returns the last
value written.
Documentation/i2c/chips/sis5595 0 → 100644
浏览文件 @ aef7b83c
Kernel driver sis5595
=====================
Supported chips:
* Silicon Integrated Systems Corp. SiS5595 Southbridge Hardware Monitor
Prefix: 'sis5595'
Addresses scanned: ISA in PCI-space encoded address
Datasheet: Publicly available at the Silicon Integrated Systems Corp. site.
Authors:
Kyösti Mälkki <kmalkki@cc.hut.fi>,
Mark D. Studebaker <mdsxyz123@yahoo.com>,
Aurelien Jarno <aurelien@aurel32.net> 2.6 port
SiS southbridge has a LM78-like chip integrated on the same IC.
This driver is a customized copy of lm78.c
Supports following revisions:
Version PCI ID PCI Revision
1 1039/0008 AF or less
2 1039/0008 B0 or greater
Note: these chips contain a 0008 device which is incompatible with the
5595. We recognize these by the presence of the listed
"blacklist" PCI ID and refuse to load.
NOT SUPPORTED PCI ID BLACKLIST PCI ID
540 0008 0540
550 0008 0550
5513 0008 5511
5581 0008 5597
5582 0008 5597
5597 0008 5597
630 0008 0630
645 0008 0645
730 0008 0730
735 0008 0735
Module Parameters
-----------------
force_addr=0xaddr Set the I/O base address. Useful for boards
that don't set the address in the BIOS. Does not do a
PCI force; the device must still be present in lspci.
Don't use this unless the driver complains that the
base address is not set.
Example: 'modprobe sis5595 force_addr=0x290'
Description
-----------
The SiS5595 southbridge has integrated hardware monitor functions. It also
has an I2C bus, but this driver only supports the hardware monitor. For the
I2C bus driver see i2c-sis5595.
The SiS5595 implements zero or one temperature sensor, two fan speed
sensors, four or five voltage sensors, and alarms.
On the first version of the chip, there are four voltage sensors and one
temperature sensor.
On the second version of the chip, the temperature sensor (temp) and the
fifth voltage sensor (in4) share a pin which is configurable, but not
through the driver. Sorry. The driver senses the configuration of the pin,
which was hopefully set by the BIOS.
Temperatures are measured in degrees Celsius. An alarm is triggered once
when the max is crossed; it is also triggered when it drops below the min
value. Measurements are guaranteed between -55 and +125 degrees, with a
resolution of 1 degree.
Fan rotation speeds are reported in RPM (rotations per minute). An alarm is
triggered if the rotation speed has dropped below a programmable limit. Fan
readings can be divided by a programmable divider (1, 2, 4 or 8) to give
the readings more range or accuracy. Not all RPM values can accurately be
represented, so some rounding is done. With a divider of 2, the lowest
representable value is around 2600 RPM.
Voltage sensors (also known as IN sensors) report their values in volts. An
alarm is triggered if the voltage has crossed a programmable minimum or
maximum limit. Note that minimum in this case always means 'closest to
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.
In addition to the alarms described above, there is a BTI alarm, which gets
triggered when an external chip has crossed its limits. Usually, this is
connected to some LM75-like chip; if at least one crosses its limits, this
bit gets set.
If an alarm triggers, it will remain triggered until the hardware register
is read at least once. This means that the cause for the alarm may already
have disappeared! Note that in the current implementation, all hardware
registers are read whenever any data is read (unless it is less than 1.5
seconds since the last update). This means that you can easily miss
once-only alarms.
The SiS5595 only updates its values each 1.5 seconds; reading it more often
will do no harm, but will return 'old' values.
Problems
--------
Some chips refuse to be enabled. We don't know why.
The driver will recognize this and print a message in dmesg.
Documentation/i2c/chips/smsc47m1 0 → 100644
浏览文件 @ aef7b83c
Kernel driver smsc47m1
======================
Supported chips:
* SMSC LPC47B27x, LPC47M10x, LPC47M13x, LPC47M14x, LPC47M15x and LPC47M192
Addresses scanned: none, address read from Super I/O config space
Prefix: 'smsc47m1'
Datasheets:
http://www.smsc.com/main/datasheets/47b27x.pdf
http://www.smsc.com/main/datasheets/47m10x.pdf
http://www.smsc.com/main/tools/discontinued/47m13x.pdf
http://www.smsc.com/main/datasheets/47m14x.pdf
http://www.smsc.com/main/tools/discontinued/47m15x.pdf
http://www.smsc.com/main/datasheets/47m192.pdf
Authors:
Mark D. Studebaker <mdsxyz123@yahoo.com>,
With assistance from Bruce Allen <ballen@uwm.edu>, and his
fan.c program: http://www.lsc-group.phys.uwm.edu/%7Eballen/driver/
Gabriele Gorla <gorlik@yahoo.com>,
Jean Delvare <khali@linux-fr.org>
Description
-----------
The Standard Microsystems Corporation (SMSC) 47M1xx Super I/O chips
contain monitoring and PWM control circuitry for two fans.
The 47M15x and 47M192 chips contain a full 'hardware monitoring block'
in addition to the fan monitoring and control. The hardware monitoring
block is not supported by the driver.
Fan rotation speeds are reported in RPM (rotations per minute). An alarm is
triggered if the rotation speed has dropped below a programmable limit. Fan
readings can be divided by a programmable divider (1, 2, 4 or 8) to give
the readings more range or accuracy. Not all RPM values can accurately be
represented, so some rounding is done. With a divider of 2, the lowest
representable value is around 2600 RPM.
PWM values are from 0 to 255.
If an alarm triggers, it will remain triggered until the hardware register
is read at least once. This means that the cause for the alarm may
already have disappeared! Note that in the current implementation, all
hardware registers are read whenever any data is read (unless it is less
than 1.5 seconds since the last update). This means that you can easily
miss once-only alarms.
**********************
The lm_sensors project gratefully acknowledges the support of
Intel in the development of this driver.
Documentation/i2c/chips/via686a 0 → 100644
浏览文件 @ aef7b83c
此差异已折叠。
Documentation/i2c/chips/w83627hf 0 → 100644
浏览文件 @ aef7b83c
此差异已折叠。
Documentation/i2c/chips/w83781d 0 → 100644
浏览文件 @ aef7b83c
此差异已折叠。
Documentation/i2c/chips/w83l785ts 0 → 100644
浏览文件 @ aef7b83c
此差异已折叠。
Documentation/i2c/porting-clients
浏览文件 @ aef7b83c
...@@ -57,7 +57,7 @@ Technical changes: ...@@ -57,7 +57,7 @@ Technical changes:
Documentation/i2c/sysfs-interface for the individual files. Also Documentation/i2c/sysfs-interface for the individual files. Also
convert the units these files read and write to the specified ones. convert the units these files read and write to the specified ones.
If you need to add a new type of file, please discuss it on the If you need to add a new type of file, please discuss it on the
sensors mailing list <sensors@stimpy.netroedge.com> by providing a sensors mailing list <lm-sensors@lm-sensors.org> by providing a
patch to the Documentation/i2c/sysfs-interface file. patch to the Documentation/i2c/sysfs-interface file.
* [Attach] For I2C drivers, the attach function should make sure * [Attach] For I2C drivers, the attach function should make sure
......
Documentation/i2c/userspace-tools 0 → 100644
浏览文件 @ aef7b83c
此差异已折叠。
Documentation/i2c/writing-clients
浏览文件 @ aef7b83c
此差异已折叠。
Documentation/kdump/gdbmacros.txt 0 → 100644
浏览文件 @ aef7b83c
此差异已折叠。
Documentation/kdump/kdump.txt 0 → 100644
浏览文件 @ aef7b83c
此差异已折叠。
Documentation/kernel-parameters.txt
浏览文件 @ aef7b83c
此差异已折叠。
Documentation/keys.txt
浏览文件 @ aef7b83c
此差异已折叠。
Documentation/networking/00-INDEX
浏览文件 @ aef7b83c
...@@ -114,9 +114,7 @@ tuntap.txt ...@@ -114,9 +114,7 @@ tuntap.txt
vortex.txt vortex.txt
- info on using 3Com Vortex (3c590, 3c592, 3c595, 3c597) Ethernet cards. - info on using 3Com Vortex (3c590, 3c592, 3c595, 3c597) Ethernet cards.
wan-router.txt wan-router.txt
- Wan router documentation - WAN router documentation
wanpipe.txt
- WANPIPE(tm) Multiprotocol WAN Driver for Linux WAN Router
wavelan.txt wavelan.txt
- AT&T GIS (nee NCR) WaveLAN card: An Ethernet-like radio transceiver - AT&T GIS (nee NCR) WaveLAN card: An Ethernet-like radio transceiver
x25.txt x25.txt
......
Documentation/networking/multicast.txt
浏览文件 @ aef7b83c
...@@ -47,7 +47,6 @@ ni52 <------------------ Buggy ------------------> ...@@ -47,7 +47,6 @@ ni52 <------------------ Buggy ------------------>
ni65 YES YES YES Software(#) ni65 YES YES YES Software(#)
seeq NO NO NO N/A seeq NO NO NO N/A
sgiseek <------------------ Buggy ------------------> sgiseek <------------------ Buggy ------------------>
sk_g16 NO NO YES N/A
smc-ultra YES YES YES Hardware smc-ultra YES YES YES Hardware
sunlance YES YES YES Hardware sunlance YES YES YES Hardware
tulip YES YES YES Hardware tulip YES YES YES Hardware
......
Documentation/networking/tcp.txt
浏览文件 @ aef7b83c
此差异已折叠。
Documentation/networking/vortex.txt
浏览文件 @ aef7b83c
此差异已折叠。
Documentation/networking/wanpipe.txt 已删除 100644 → 0
浏览文件 @ b1fc5505
此差异已折叠。
Documentation/power/devices.txt
浏览文件 @ aef7b83c
此差异已折叠。
Documentation/power/pci.txt
浏览文件 @ aef7b83c
此差异已折叠。
Documentation/power/swsusp.txt
浏览文件 @ aef7b83c
此差异已折叠。
Documentation/power/video.txt
浏览文件 @ aef7b83c
此差异已折叠。
Documentation/powerpc/hvcs.txt
浏览文件 @ aef7b83c
此差异已折叠。
Documentation/s390/CommonIO
浏览文件 @ aef7b83c
此差异已折叠。
Documentation/s390/s390dbf.txt
浏览文件 @ aef7b83c
此差异已折叠。
Documentation/scsi/scsi-changer.txt 0 → 100644
浏览文件 @ aef7b83c
此差异已折叠。
Documentation/sgi-ioc4.txt 0 → 100644
浏览文件 @ aef7b83c
此差异已折叠。
Documentation/sound/alsa/CMIPCI.txt
浏览文件 @ aef7b83c
此差异已折叠。
Documentation/sound/alsa/emu10k1-jack.txt 0 → 100644
浏览文件 @ aef7b83c
此差异已折叠。
Documentation/sound/alsa/hdspm.txt 0 → 100644
浏览文件 @ aef7b83c
此差异已折叠。
Documentation/sysctl/kernel.txt
浏览文件 @ aef7b83c
此差异已折叠。
Documentation/sysrq.txt
浏览文件 @ aef7b83c
此差异已折叠。
Documentation/tty.txt
浏览文件 @ aef7b83c
此差异已折叠。
Documentation/video4linux/CARDLIST.cx88 0 → 100644
浏览文件 @ aef7b83c
此差异已折叠。
Documentation/video4linux/hauppauge-wintv-cx88-ir.txt 0 → 100644
浏览文件 @ aef7b83c
此差异已折叠。
Documentation/video4linux/lifeview.txt 0 → 100644
浏览文件 @ aef7b83c
此差异已折叠。
Documentation/video4linux/not-in-cx2388x-datasheet.txt 0 → 100644
浏览文件 @ aef7b83c
此差异已折叠。
Documentation/w1/w1.generic
浏览文件 @ aef7b83c
此差异已折叠。
MAINTAINERS
浏览文件 @ aef7b83c
此差异已折叠。
Makefile
浏览文件 @ aef7b83c
此差异已折叠。
arch/alpha/Kconfig
浏览文件 @ aef7b83c
此差异已折叠。
arch/alpha/defconfig
浏览文件 @ aef7b83c
此差异已折叠。
arch/alpha/kernel/osf_sys.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/alpha/mm/numa.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/arm/Kconfig
浏览文件 @ aef7b83c
此差异已折叠。
arch/arm/Makefile
浏览文件 @ aef7b83c
此差异已折叠。
arch/arm/boot/install.sh
浏览文件 @ aef7b83c
此差异已折叠。
arch/arm/common/amba.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/arm/common/dmabounce.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/arm/common/sa1111.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/arm/common/sharpsl_param.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/arm/configs/badge4_defconfig
浏览文件 @ aef7b83c
此差异已折叠。
arch/arm/configs/enp2611_defconfig
浏览文件 @ aef7b83c
此差异已折叠。
arch/arm/configs/h3600_defconfig
浏览文件 @ aef7b83c
此差异已折叠。
arch/arm/configs/hackkit_defconfig
浏览文件 @ aef7b83c
此差异已折叠。
arch/arm/configs/ixdp2400_defconfig
浏览文件 @ aef7b83c
此差异已折叠。
arch/arm/configs/ixdp2401_defconfig
浏览文件 @ aef7b83c
此差异已折叠。
arch/arm/configs/ixdp2800_defconfig
浏览文件 @ aef7b83c
此差异已折叠。
arch/arm/configs/ixdp2801_defconfig
浏览文件 @ aef7b83c
此差异已折叠。
arch/arm/configs/s3c2410_defconfig
浏览文件 @ aef7b83c
此差异已折叠。
arch/arm/kernel/Makefile
浏览文件 @ aef7b83c
此差异已折叠。
arch/arm/kernel/arch.c 已删除 100644 → 0
浏览文件 @ b1fc5505
此差异已折叠。
arch/arm/kernel/ecard.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/arm/kernel/entry-armv.S
浏览文件 @ aef7b83c
此差异已折叠。
arch/arm/kernel/entry-header.S
浏览文件 @ aef7b83c
此差异已折叠。
arch/arm/kernel/head.S
浏览文件 @ aef7b83c
此差异已折叠。
arch/arm/kernel/irq.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/arm/kernel/setup.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/arm/kernel/signal.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/arm/kernel/signal.h 0 → 100644
浏览文件 @ aef7b83c
此差异已折叠。
arch/arm/kernel/smp.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/arm/kernel/time.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/arm/kernel/traps.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/arm/lib/ashldi3.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/arm/lib/ashrdi3.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/arm/lib/gcclib.h
浏览文件 @ aef7b83c
此差异已折叠。
arch/arm/lib/io-writesw-armv4.S
浏览文件 @ aef7b83c
此差异已折叠。
arch/arm/lib/longlong.h
浏览文件 @ aef7b83c
此差异已折叠。
arch/arm/lib/lshrdi3.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/arm/lib/muldi3.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/arm/lib/ucmpdi2.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/arm/lib/udivdi3.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/arm/mach-aaec2000/Kconfig 0 → 100644
浏览文件 @ aef7b83c
此差异已折叠。
arch/arm/mach-aaec2000/Makefile 0 → 100644
浏览文件 @ aef7b83c
此差异已折叠。
arch/arm/mach-aaec2000/aaed2000.c 0 → 100644
浏览文件 @ aef7b83c
此差异已折叠。
arch/arm/mach-aaec2000/core.c 0 → 100644
浏览文件 @ aef7b83c
此差异已折叠。
arch/arm/mach-aaec2000/core.h 0 → 100644
浏览文件 @ aef7b83c
此差异已折叠。
arch/arm/mach-clps711x/Kconfig
浏览文件 @ aef7b83c
此差异已折叠。
arch/arm/mach-clps7500/core.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/arm/mach-integrator/Makefile
浏览文件 @ aef7b83c
此差异已折叠。
arch/arm/mach-integrator/core.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/arm/mach-integrator/headsmp.S 0 → 100644
浏览文件 @ aef7b83c
此差异已折叠。
arch/arm/mach-integrator/leds.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/arm/mach-integrator/platsmp.c 0 → 100644
浏览文件 @ aef7b83c
此差异已折叠。
arch/arm/mach-ixp2000/Kconfig
浏览文件 @ aef7b83c
此差异已折叠。
arch/arm/mach-ixp2000/core.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/arm/mach-ixp2000/enp2611.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/arm/mach-ixp2000/ixdp2x00.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/arm/mach-ixp2000/pci.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/arm/mach-ixp4xx/common.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/arm/mach-pxa/lubbock.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/arm/mach-pxa/mainstone.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/arm/mach-pxa/pm.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/arm/mach-pxa/pxa25x.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/arm/mach-pxa/pxa27x.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/arm/mach-rpc/riscpc.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/arm/mach-s3c2410/clock.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/arm/mach-s3c2410/dma.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/arm/mach-s3c2410/mach-bast.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/arm/mach-s3c2410/mach-vr1000.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/arm/mach-s3c2410/s3c2440.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/arm/mach-sa1100/Kconfig
浏览文件 @ aef7b83c
此差异已折叠。
arch/arm/mach-sa1100/pm.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/arm/mach-versatile/Makefile
浏览文件 @ aef7b83c
此差异已折叠。
arch/arm/mach-versatile/core.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/arm/mach-versatile/pci.c 0 → 100644
浏览文件 @ aef7b83c
此差异已折叠。
arch/arm/mm/Kconfig
浏览文件 @ aef7b83c
此差异已折叠。
arch/arm/mm/Makefile
浏览文件 @ aef7b83c
此差异已折叠。
arch/arm/mm/copypage-v4mc.S 已删除 100644 → 0
浏览文件 @ b1fc5505
此差异已折叠。
arch/arm/mm/copypage-v4mc.c 0 → 100644
浏览文件 @ aef7b83c
此差异已折叠。
arch/arm/mm/copypage-v6.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/arm/mm/copypage-xscale.S 已删除 100644 → 0
浏览文件 @ b1fc5505
此差异已折叠。
arch/arm/mm/copypage-xscale.c 0 → 100644
浏览文件 @ aef7b83c
此差异已折叠。
arch/arm/mm/fault-armv.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/arm/mm/flush.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/arm/mm/init.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/arm/mm/ioremap.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/arm/mm/minicache.c 已删除 100644 → 0
浏览文件 @ b1fc5505
此差异已折叠。
arch/arm/mm/mm-armv.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/arm/mm/mmap.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/arm/mm/proc-v6.S
浏览文件 @ aef7b83c
此差异已折叠。
arch/arm/nwfpe/softfloat-macros
浏览文件 @ aef7b83c
此差异已折叠。
arch/arm/nwfpe/softfloat.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/arm26/Kconfig
浏览文件 @ aef7b83c
此差异已折叠。
arch/arm26/boot/install.sh
浏览文件 @ aef7b83c
此差异已折叠。
arch/arm26/kernel/ecard.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/cris/Kconfig
浏览文件 @ aef7b83c
此差异已折叠。
arch/frv/Kconfig
浏览文件 @ aef7b83c
此差异已折叠。
arch/frv/kernel/setup.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/frv/kernel/signal.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/frv/mm/init.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/h8300/Kconfig.cpu
浏览文件 @ aef7b83c
此差异已折叠。
arch/h8300/kernel/process.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/h8300/kernel/signal.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/i386/Kconfig
浏览文件 @ aef7b83c
此差异已折叠。
arch/i386/Makefile
浏览文件 @ aef7b83c
此差异已折叠。
arch/i386/boot/Makefile
浏览文件 @ aef7b83c
此差异已折叠。
arch/i386/boot/compressed/head.S
浏览文件 @ aef7b83c
此差异已折叠。
arch/i386/boot/compressed/misc.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/i386/boot/edd.S
浏览文件 @ aef7b83c
此差异已折叠。
arch/i386/boot/install.sh
浏览文件 @ aef7b83c
此差异已折叠。
arch/i386/boot/setup.S
浏览文件 @ aef7b83c
此差异已折叠。
arch/i386/boot/tools/build.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/i386/crypto/aes.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/i386/defconfig
浏览文件 @ aef7b83c
此差异已折叠。
arch/i386/kernel/Makefile
浏览文件 @ aef7b83c
此差异已折叠。
arch/i386/kernel/acpi/boot.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/i386/kernel/acpi/sleep.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/i386/kernel/apic.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/i386/kernel/apm.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/i386/kernel/cpu/amd.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/i386/kernel/cpu/common.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/i386/kernel/cpu/cpufreq/sc520_freq.c 0 → 100644
浏览文件 @ aef7b83c
此差异已折叠。
arch/i386/kernel/cpu/intel.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/i386/kernel/cpu/mcheck/k7.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/i386/kernel/cpu/mcheck/mce.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/i386/kernel/cpu/mcheck/p4.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/i386/kernel/cpu/mcheck/p5.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/i386/kernel/cpu/mcheck/p6.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/i386/kernel/cpu/mtrr/generic.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/i386/kernel/cpu/mtrr/main.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/i386/kernel/cpu/proc.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/i386/kernel/cpuid.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/i386/kernel/crash.c 0 → 100644
浏览文件 @ aef7b83c
此差异已折叠。
arch/i386/kernel/dmi_scan.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/i386/kernel/efi.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/i386/kernel/head.S
浏览文件 @ aef7b83c
此差异已折叠。
arch/i386/kernel/i386_ksyms.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/i386/kernel/i387.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/i386/kernel/i8259.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/i386/kernel/io_apic.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/i386/kernel/irq.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/i386/kernel/kprobes.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/i386/kernel/machine_kexec.c 0 → 100644
浏览文件 @ aef7b83c
此差异已折叠。
arch/i386/kernel/mpparse.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/i386/kernel/msr.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/i386/kernel/nmi.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/i386/kernel/pci-dma.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/i386/kernel/process.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/i386/kernel/ptrace.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/i386/kernel/reboot.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/i386/kernel/relocate_kernel.S 0 → 100644
浏览文件 @ aef7b83c
此差异已折叠。
arch/i386/kernel/setup.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/i386/kernel/signal.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/i386/kernel/smp.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/i386/kernel/smpboot.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/i386/kernel/syscall_table.S
浏览文件 @ aef7b83c
此差异已折叠。
arch/i386/kernel/sysenter.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/i386/kernel/time.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/i386/kernel/time_hpet.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/i386/kernel/timers/common.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/i386/kernel/timers/timer.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/i386/kernel/timers/timer_pm.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/i386/kernel/timers/timer_tsc.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/i386/kernel/traps.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/i386/kernel/vmlinux.lds.S
浏览文件 @ aef7b83c
此差异已折叠。
arch/i386/lib/dec_and_lock.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/i386/lib/delay.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/i386/lib/mmx.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/i386/lib/usercopy.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/i386/mach-default/setup.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/i386/mach-default/topology.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/i386/mach-visws/mpparse.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/i386/mm/Makefile
浏览文件 @ aef7b83c
此差异已折叠。
arch/i386/mm/discontig.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/i386/mm/fault.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/i386/mm/highmem.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/i386/mm/hugetlbpage.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/i386/mm/init.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/i386/mm/ioremap.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/i386/mm/pgtable.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/i386/oprofile/backtrace.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/i386/pci/fixup.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/i386/pci/irq.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/i386/pci/pcbios.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/i386/power/cpu.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/ia64/Kconfig
浏览文件 @ aef7b83c
此差异已折叠。
arch/ia64/Kconfig.debug
浏览文件 @ aef7b83c
此差异已折叠。
arch/ia64/configs/sn2_defconfig
浏览文件 @ aef7b83c
此差异已折叠。
arch/ia64/configs/tiger_defconfig
浏览文件 @ aef7b83c
此差异已折叠。
arch/ia64/defconfig
浏览文件 @ aef7b83c
此差异已折叠。
arch/ia64/ia32/ia32_ioctl.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/ia64/ia32/ia32priv.h
浏览文件 @ aef7b83c
此差异已折叠。
arch/ia64/ia32/sys_ia32.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/ia64/kernel/Makefile
浏览文件 @ aef7b83c
此差异已折叠。
arch/ia64/kernel/domain.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/ia64/kernel/efi.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/ia64/kernel/entry.S
浏览文件 @ aef7b83c
此差异已折叠。
arch/ia64/kernel/entry.h
浏览文件 @ aef7b83c
此差异已折叠。
arch/ia64/kernel/fsys.S
浏览文件 @ aef7b83c
此差异已折叠。
arch/ia64/kernel/ivt.S
浏览文件 @ aef7b83c
此差异已折叠。
arch/ia64/kernel/jprobes.S 0 → 100644
浏览文件 @ aef7b83c
此差异已折叠。
arch/ia64/kernel/kprobes.c 0 → 100644
浏览文件 @ aef7b83c
此差异已折叠。
arch/ia64/kernel/mca.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/ia64/kernel/minstate.h
浏览文件 @ aef7b83c
此差异已折叠。
arch/ia64/kernel/module.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/ia64/kernel/perfmon.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/ia64/kernel/ptrace.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/ia64/kernel/setup.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/ia64/kernel/signal.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/ia64/kernel/smp.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/ia64/kernel/smpboot.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/ia64/kernel/sys_ia64.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/ia64/kernel/traps.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/ia64/kernel/uncached.c 0 → 100644
浏览文件 @ aef7b83c
此差异已折叠。
arch/ia64/mm/discontig.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/ia64/mm/fault.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/ia64/mm/hugetlbpage.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/ia64/mm/init.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/ia64/pci/pci.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/ia64/sn/kernel/setup.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/ia64/sn/kernel/tiocx.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/ia64/sn/kernel/xpc.h
浏览文件 @ aef7b83c
此差异已折叠。
arch/ia64/sn/kernel/xpc_channel.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/ia64/sn/kernel/xpc_partition.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/m32r/Kconfig
浏览文件 @ aef7b83c
此差异已折叠。
arch/m32r/defconfig
浏览文件 @ aef7b83c
此差异已折叠。
arch/m32r/kernel/Makefile
浏览文件 @ aef7b83c
此差异已折叠。
arch/m32r/kernel/io_m32700ut.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/m32r/kernel/io_mappi.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/m32r/kernel/io_mappi2.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/m32r/kernel/io_mappi3.c 0 → 100644
浏览文件 @ aef7b83c
此差异已折叠。
arch/m32r/kernel/io_oaks32r.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/m32r/kernel/io_opsput.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/m32r/kernel/io_usrv.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/m32r/kernel/setup.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/m32r/kernel/setup_m32700ut.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/m32r/kernel/setup_mappi.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/m32r/kernel/setup_mappi2.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/m32r/kernel/setup_mappi3.c 0 → 100644
浏览文件 @ aef7b83c
此差异已折叠。
arch/m32r/kernel/setup_oaks32r.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/m32r/kernel/setup_opsput.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/m32r/kernel/setup_usrv.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/m32r/kernel/signal.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/m32r/mappi/defconfig.nommu
浏览文件 @ aef7b83c
此差异已折叠。
arch/m32r/mappi/defconfig.smp
浏览文件 @ aef7b83c
此差异已折叠。
arch/m32r/mappi/defconfig.up
浏览文件 @ aef7b83c
此差异已折叠。
arch/m32r/mappi2/defconfig.vdec2
浏览文件 @ aef7b83c
此差异已折叠。
arch/m32r/mappi3/defconfig.smp 0 → 100644
浏览文件 @ aef7b83c
此差异已折叠。
arch/m32r/mappi3/dot.gdbinit 0 → 100644
浏览文件 @ aef7b83c
此差异已折叠。
arch/m32r/mm/extable.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/m32r/mm/init.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/m32r/oaks32r/defconfig.nommu
浏览文件 @ aef7b83c
此差异已折叠。
arch/m32r/opsput/defconfig.opsput
浏览文件 @ aef7b83c
此差异已折叠。
arch/m68k/Kconfig
浏览文件 @ aef7b83c
此差异已折叠。
arch/m68k/configs/amiga_defconfig
浏览文件 @ aef7b83c
此差异已折叠。
arch/m68k/configs/apollo_defconfig
浏览文件 @ aef7b83c
此差异已折叠。
arch/m68k/configs/atari_defconfig
浏览文件 @ aef7b83c
此差异已折叠。
arch/m68k/configs/hp300_defconfig
浏览文件 @ aef7b83c
此差异已折叠。
arch/m68k/configs/mac_defconfig
浏览文件 @ aef7b83c
此差异已折叠。
arch/m68k/configs/mvme147_defconfig
浏览文件 @ aef7b83c
此差异已折叠。
arch/m68k/configs/mvme16x_defconfig
浏览文件 @ aef7b83c
此差异已折叠。
arch/m68k/configs/q40_defconfig
浏览文件 @ aef7b83c
此差异已折叠。
arch/m68k/configs/sun3_defconfig
浏览文件 @ aef7b83c
此差异已折叠。
arch/m68k/configs/sun3x_defconfig
浏览文件 @ aef7b83c
此差异已折叠。
arch/m68k/defconfig
浏览文件 @ aef7b83c
此差异已折叠。
arch/m68knommu/Kconfig
浏览文件 @ aef7b83c
此差异已折叠。
arch/m68knommu/kernel/process.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/mips/Kconfig
浏览文件 @ aef7b83c
此差异已折叠。
arch/mips/configs/ip27_defconfig
浏览文件 @ aef7b83c
此差异已折叠。
arch/mips/kernel/setup.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/mips/mm/init.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/mips/mm/pgtable.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/mips/sgi-ip27/ip27-memory.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/mips/vr41xx/common/pmu.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/parisc/Kconfig
浏览文件 @ aef7b83c
此差异已折叠。
arch/parisc/kernel/drivers.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/parisc/mm/init.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/ppc/Kconfig
浏览文件 @ aef7b83c
此差异已折叠。
arch/ppc/Kconfig.debug
浏览文件 @ aef7b83c
此差异已折叠。
arch/ppc/Makefile
浏览文件 @ aef7b83c
此差异已折叠。
arch/ppc/boot/images/Makefile
浏览文件 @ aef7b83c
此差异已折叠。
arch/ppc/boot/ld.script
浏览文件 @ aef7b83c
此差异已折叠。
arch/ppc/boot/openfirmware/Makefile
浏览文件 @ aef7b83c
此差异已折叠。
arch/ppc/boot/openfirmware/common.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/ppc/boot/simple/Makefile
浏览文件 @ aef7b83c
此差异已折叠。
arch/ppc/boot/simple/misc.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/ppc/boot/utils/addSystemMap.c 已删除 100644 → 0
浏览文件 @ b1fc5505
此差异已折叠。
arch/ppc/configs/mpc8548_cds_defconfig 0 → 100644
浏览文件 @ aef7b83c
此差异已折叠。
arch/ppc/kernel/Makefile
浏览文件 @ aef7b83c
此差异已折叠。
arch/ppc/kernel/cputable.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/ppc/kernel/entry.S
浏览文件 @ aef7b83c
此差异已折叠。
arch/ppc/kernel/head_44x.S
浏览文件 @ aef7b83c
此差异已折叠。
arch/ppc/kernel/head_4xx.S
浏览文件 @ aef7b83c
此差异已折叠。
arch/ppc/kernel/head_booke.h
浏览文件 @ aef7b83c
此差异已折叠。
arch/ppc/kernel/head_fsl_booke.S
浏览文件 @ aef7b83c
此差异已折叠。
arch/ppc/kernel/machine_kexec.c 0 → 100644
浏览文件 @ aef7b83c
此差异已折叠。
arch/ppc/kernel/misc.S
浏览文件 @ aef7b83c
此差异已折叠。
arch/ppc/kernel/pci.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/ppc/kernel/perfmon.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/ppc/kernel/ppc_ksyms.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/ppc/kernel/ptrace.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/ppc/kernel/relocate_kernel.S 0 → 100644
浏览文件 @ aef7b83c
此差异已折叠。
arch/ppc/kernel/setup.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/ppc/kernel/signal.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/ppc/kernel/traps.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/ppc/lib/locks.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/ppc/lib/string.S
浏览文件 @ aef7b83c
此差异已折叠。
arch/ppc/mm/44x_mmu.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/ppc/mm/4xx_mmu.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/ppc/mm/fsl_booke_mmu.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/ppc/mm/init.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/ppc/mm/mmu_decl.h
浏览文件 @ aef7b83c
此差异已折叠。
arch/ppc/mm/pgtable.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/ppc/platforms/85xx/Kconfig
浏览文件 @ aef7b83c
此差异已折叠。
arch/ppc/platforms/85xx/Makefile
浏览文件 @ aef7b83c
此差异已折叠。
arch/ppc/platforms/85xx/sbc8560.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/ppc/platforms/85xx/sbc85xx.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/ppc/platforms/85xx/stx_gp3.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/ppc/platforms/chrp_pci.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/ppc/platforms/katana.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/ppc/platforms/pmac_cpufreq.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/ppc/platforms/pmac_pci.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/ppc/platforms/pq2ads.h
浏览文件 @ aef7b83c
此差异已折叠。
arch/ppc/platforms/sandpoint.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/ppc/syslib/Makefile
浏览文件 @ aef7b83c
此差异已折叠。
arch/ppc/syslib/cpm2_common.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/ppc/syslib/indirect_pci.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/ppc/syslib/ipic.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/ppc/syslib/m8260_pci.c 已删除 100644 → 0
浏览文件 @ b1fc5505
此差异已折叠。
arch/ppc/syslib/m8260_setup.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/ppc/syslib/m82xx_pci.c 0 → 100644
浏览文件 @ aef7b83c
此差异已折叠。
arch/ppc/syslib/mpc10x_common.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/ppc/syslib/mpc83xx_devices.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/ppc/syslib/mpc85xx_devices.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/ppc/syslib/mpc85xx_sys.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/ppc/syslib/mv64x60.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/ppc/syslib/mv64x60_win.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/ppc/syslib/ocp.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/ppc/syslib/of_device.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/ppc/syslib/open_pic.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/ppc/syslib/open_pic2.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/ppc/syslib/ppc4xx_kgdb.c 已删除 100644 → 0
浏览文件 @ b1fc5505
此差异已折叠。
arch/ppc/syslib/ppc83xx_setup.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/ppc/syslib/ppc85xx_setup.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/ppc/syslib/prom_init.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/ppc/xmon/xmon.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/ppc64/Kconfig
浏览文件 @ aef7b83c
此差异已折叠。
arch/ppc64/Makefile
浏览文件 @ aef7b83c
此差异已折叠。
arch/ppc64/boot/install.sh
浏览文件 @ aef7b83c
此差异已折叠。
arch/ppc64/boot/prom.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/ppc64/configs/g5_defconfig
浏览文件 @ aef7b83c
此差异已折叠。
arch/ppc64/configs/maple_defconfig
浏览文件 @ aef7b83c
此差异已折叠。
arch/ppc64/defconfig
浏览文件 @ aef7b83c
此差异已折叠。
arch/ppc64/kernel/HvLpEvent.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/ppc64/kernel/ItLpQueue.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/ppc64/kernel/Makefile
浏览文件 @ aef7b83c
此差异已折叠。
arch/ppc64/kernel/XmPciLpEvent.c 已删除 100644 → 0
浏览文件 @ b1fc5505
此差异已折叠。
arch/ppc64/kernel/asm-offsets.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/ppc64/kernel/bpa_iic.c 0 → 100644
浏览文件 @ aef7b83c
此差异已折叠。
arch/ppc64/kernel/bpa_iic.h 0 → 100644
浏览文件 @ aef7b83c
此差异已折叠。
arch/ppc64/kernel/bpa_iommu.c 0 → 100644
浏览文件 @ aef7b83c
此差异已折叠。
arch/ppc64/kernel/bpa_iommu.h 0 → 100644
浏览文件 @ aef7b83c
此差异已折叠。
arch/ppc64/kernel/bpa_nvram.c 0 → 100644
浏览文件 @ aef7b83c
此差异已折叠。
arch/ppc64/kernel/bpa_setup.c 0 → 100644
浏览文件 @ aef7b83c
此差异已折叠。
arch/ppc64/kernel/cputable.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/ppc64/kernel/dma.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/ppc64/kernel/eeh.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/ppc64/kernel/entry.S
浏览文件 @ aef7b83c
此差异已折叠。
arch/ppc64/kernel/head.S
浏览文件 @ aef7b83c
此差异已折叠。
arch/ppc64/kernel/iSeries_VpdInfo.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/ppc64/kernel/iSeries_iommu.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/ppc64/kernel/iSeries_irq.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/ppc64/kernel/iSeries_pci.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/ppc64/kernel/iSeries_pci_reset.c 已删除 100644 → 0
浏览文件 @ b1fc5505
此差异已折叠。
arch/ppc64/kernel/iSeries_proc.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/ppc64/kernel/iSeries_setup.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/ppc64/kernel/iSeries_smp.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/ppc64/kernel/idle.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/ppc64/kernel/iommu.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/ppc64/kernel/irq.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/ppc64/kernel/kprobes.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/ppc64/kernel/lparcfg.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/ppc64/kernel/machine_kexec.c 0 → 100644
浏览文件 @ aef7b83c
此差异已折叠。
arch/ppc64/kernel/maple_setup.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/ppc64/kernel/maple_time.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/ppc64/kernel/mf.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/ppc64/kernel/misc.S
浏览文件 @ aef7b83c
此差异已折叠。
arch/ppc64/kernel/mpic.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/ppc64/kernel/mpic.h
浏览文件 @ aef7b83c
此差异已折叠。
arch/ppc64/kernel/of_device.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/ppc64/kernel/pSeries_pci.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/ppc64/kernel/pSeries_setup.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/ppc64/kernel/pSeries_smp.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/ppc64/kernel/pci.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/ppc64/kernel/pci.h
浏览文件 @ aef7b83c
此差异已折叠。
arch/ppc64/kernel/pmac_smp.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/ppc64/kernel/pmac_time.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/ppc64/kernel/proc_ppc64.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/ppc64/kernel/process.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/ppc64/kernel/prom.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/ppc64/kernel/prom_init.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/ppc64/kernel/ptrace.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/ppc64/kernel/ras.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/ppc64/kernel/rtas-proc.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/ppc64/kernel/rtas.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/ppc64/kernel/rtas_pci.c 0 → 100644
浏览文件 @ aef7b83c
此差异已折叠。
arch/ppc64/kernel/rtasd.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/ppc64/kernel/rtc.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/ppc64/kernel/setup.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/ppc64/kernel/smp.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/ppc64/kernel/spider-pic.c 0 → 100644
浏览文件 @ aef7b83c
此差异已折叠。
arch/ppc64/kernel/sys_ppc32.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/ppc64/kernel/syscalls.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/ppc64/kernel/sysfs.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/ppc64/kernel/time.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/ppc64/kernel/traps.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/ppc64/kernel/vio.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/ppc64/kernel/viopath.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/ppc64/kernel/xics.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/ppc64/lib/Makefile
浏览文件 @ aef7b83c
此差异已折叠。
arch/ppc64/mm/Makefile
浏览文件 @ aef7b83c
此差异已折叠。
arch/ppc64/mm/hash_native.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/ppc64/mm/hash_utils.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/ppc64/mm/hugetlbpage.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/ppc64/mm/imalloc.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/ppc64/mm/init.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/ppc64/mm/numa.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/ppc64/xmon/xmon.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/s390/Kconfig
浏览文件 @ aef7b83c
此差异已折叠。
arch/s390/appldata/appldata_base.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/s390/appldata/appldata_mem.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/s390/appldata/appldata_os.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/s390/boot/install.sh
浏览文件 @ aef7b83c
此差异已折叠。
arch/s390/defconfig
浏览文件 @ aef7b83c
此差异已折叠。
arch/s390/kernel/Makefile
浏览文件 @ aef7b83c
此差异已折叠。
arch/s390/kernel/compat_ioctl.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/s390/kernel/compat_linux.h
浏览文件 @ aef7b83c
此差异已折叠。
arch/s390/kernel/compat_wrapper.S
浏览文件 @ aef7b83c
此差异已折叠。
arch/s390/kernel/cpcmd.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/s390/kernel/crash.c 0 → 100644
浏览文件 @ aef7b83c
此差异已折叠。
arch/s390/kernel/debug.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/s390/kernel/entry.S
浏览文件 @ aef7b83c
此差异已折叠。
arch/s390/kernel/entry64.S
浏览文件 @ aef7b83c
此差异已折叠。
arch/s390/kernel/head.S
浏览文件 @ aef7b83c
此差异已折叠。
arch/s390/kernel/head64.S
浏览文件 @ aef7b83c
此差异已折叠。
arch/s390/kernel/machine_kexec.c 0 → 100644
浏览文件 @ aef7b83c
此差异已折叠。
arch/s390/kernel/process.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/s390/kernel/ptrace.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/s390/kernel/relocate_kernel.S 0 → 100644
浏览文件 @ aef7b83c
此差异已折叠。
arch/s390/kernel/relocate_kernel64.S 0 → 100644
浏览文件 @ aef7b83c
此差异已折叠。
arch/s390/kernel/setup.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/s390/kernel/smp.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/s390/kernel/syscalls.S
浏览文件 @ aef7b83c
此差异已折叠。
arch/s390/kernel/traps.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/s390/mm/cmm.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/s390/mm/extmem.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/s390/mm/fault.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/sh/Kconfig
浏览文件 @ aef7b83c
此差异已折叠。
arch/sh/kernel/sys_sh.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/sh/lib/delay.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/sh/mm/hugetlbpage.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/sh64/Kconfig
浏览文件 @ aef7b83c
此差异已折叠。
arch/sh64/mm/hugetlbpage.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/sparc/Kconfig
浏览文件 @ aef7b83c
此差异已折叠。
arch/sparc/mm/init.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/sparc64/Kconfig
浏览文件 @ aef7b83c
此差异已折叠。
arch/sparc64/kernel/kprobes.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/sparc64/kernel/pci_iommu.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/sparc64/kernel/pci_psycho.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/sparc64/kernel/pci_sabre.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/sparc64/kernel/pci_schizo.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/sparc64/kernel/sbus.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/sparc64/kernel/setup.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/sparc64/kernel/signal32.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/sparc64/kernel/smp.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/sparc64/kernel/sys_sparc.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/sparc64/kernel/traps.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/sparc64/lib/delay.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/sparc64/mm/hugetlbpage.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/sparc64/solaris/socket.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/um/Kconfig
浏览文件 @ aef7b83c
此差异已折叠。
arch/um/Kconfig.debug
浏览文件 @ aef7b83c
此差异已折叠。
arch/um/Kconfig_char
浏览文件 @ aef7b83c
此差异已折叠。
arch/um/Kconfig_x86_64
浏览文件 @ aef7b83c
此差异已折叠。
arch/um/Makefile
浏览文件 @ aef7b83c
此差异已折叠。
arch/um/drivers/Makefile
浏览文件 @ aef7b83c
此差异已折叠。
arch/um/drivers/chan_kern.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/um/drivers/chan_user.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/um/drivers/daemon_user.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/um/drivers/line.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/um/drivers/mcast_kern.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/um/drivers/mcast_user.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/um/drivers/mconsole_kern.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/um/drivers/mmapper_kern.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/um/drivers/net_kern.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/um/drivers/net_user.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/um/drivers/port_kern.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/um/drivers/random.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/um/drivers/slip.h
浏览文件 @ aef7b83c
此差异已折叠。
arch/um/drivers/slip_common.c 0 → 100644
浏览文件 @ aef7b83c
此差异已折叠。
arch/um/drivers/slip_kern.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/um/drivers/slip_user.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/um/drivers/slirp.h
浏览文件 @ aef7b83c
此差异已折叠。
arch/um/drivers/slirp_kern.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/um/drivers/slirp_user.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/um/drivers/ssl.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/um/drivers/stderr_console.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/um/drivers/stdio_console.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/um/drivers/ubd_kern.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/um/drivers/xterm_kern.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/um/include/2_5compat.h 已删除 100644 → 0
浏览文件 @ b1fc5505
此差异已折叠。
arch/um/include/line.h
浏览文件 @ aef7b83c
此差异已折叠。
arch/um/include/mconsole.h
浏览文件 @ aef7b83c
此差异已折叠。
arch/um/include/mconsole_kern.h
浏览文件 @ aef7b83c
此差异已折叠。
arch/um/include/net_user.h
浏览文件 @ aef7b83c
此差异已折叠。
arch/um/include/os.h
浏览文件 @ aef7b83c
此差异已折叠。
arch/um/include/sysrq.h
浏览文件 @ aef7b83c
此差异已折叠。
arch/um/include/time_user.h
浏览文件 @ aef7b83c
此差异已折叠。
arch/um/include/user_util.h
浏览文件 @ aef7b83c
此差异已折叠。
arch/um/kernel/Makefile
浏览文件 @ aef7b83c
此差异已折叠。
arch/um/kernel/exec_kern.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/um/kernel/initrd_user.c 已删除 100644 → 0
浏览文件 @ b1fc5505
此差异已折叠。
arch/um/kernel/irq.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/um/kernel/irq_user.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/um/kernel/ksyms.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/um/kernel/main.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/um/kernel/mem.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/um/kernel/process.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/um/kernel/process_kern.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/um/kernel/ptrace.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/um/kernel/reboot.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/um/kernel/skas/Makefile
浏览文件 @ aef7b83c
此差异已折叠。
arch/um/kernel/skas/process_kern.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/um/kernel/skas/time.c 已删除 100644 → 0
浏览文件 @ b1fc5505
此差异已折叠。
arch/um/kernel/syscall_kern.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/um/kernel/sysrq.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/um/kernel/time.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/um/kernel/time_kern.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/um/kernel/trap_kern.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/um/kernel/tt/Makefile
浏览文件 @ aef7b83c
此差异已折叠。
arch/um/kernel/tt/gdb.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/um/kernel/tt/gdb_kern.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/um/kernel/tt/include/debug.h
浏览文件 @ aef7b83c
此差异已折叠。
arch/um/kernel/tt/include/mode-tt.h
浏览文件 @ aef7b83c
此差异已折叠。
arch/um/kernel/tt/ksyms.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/um/kernel/tt/process_kern.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/um/kernel/tt/time.c 已删除 100644 → 0
浏览文件 @ b1fc5505
此差异已折叠。
arch/um/kernel/um_arch.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/um/kernel/uml.lds.S
浏览文件 @ aef7b83c
此差异已折叠。
arch/um/os-Linux/elf_aux.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/um/os-Linux/file.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/um/scripts/Makefile.rules
浏览文件 @ aef7b83c
此差异已折叠。
arch/um/scripts/Makefile.unmap 0 → 100644
浏览文件 @ aef7b83c
此差异已折叠。
arch/um/sys-i386/Makefile
浏览文件 @ aef7b83c
此差异已折叠。
arch/um/sys-i386/delay.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/um/sys-i386/signal.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/um/sys-i386/syscalls.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/um/sys-i386/sysrq.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/um/sys-ppc/sysrq.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/um/sys-x86_64/Makefile
浏览文件 @ aef7b83c
此差异已折叠。
arch/um/sys-x86_64/delay.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/um/sys-x86_64/ksyms.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/um/sys-x86_64/ptrace.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/um/sys-x86_64/syscalls.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/um/sys-x86_64/sysrq.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/um/sys-x86_64/unmap.c 0 → 100644
浏览文件 @ aef7b83c
此差异已折叠。
arch/um/sys-x86_64/user-offsets.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/v850/Kconfig
浏览文件 @ aef7b83c
此差异已折叠。
arch/x86_64/Kconfig
浏览文件 @ aef7b83c
此差异已折叠。
arch/x86_64/Makefile
浏览文件 @ aef7b83c
此差异已折叠。
arch/x86_64/boot/compressed/head.S
浏览文件 @ aef7b83c
此差异已折叠。
arch/x86_64/boot/compressed/misc.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/x86_64/boot/install.sh
浏览文件 @ aef7b83c
此差异已折叠。
arch/x86_64/boot/setup.S
浏览文件 @ aef7b83c
此差异已折叠。
arch/x86_64/boot/tools/build.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/x86_64/defconfig
浏览文件 @ aef7b83c
此差异已折叠。
arch/x86_64/ia32/ia32_aout.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/x86_64/ia32/ia32_binfmt.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/x86_64/ia32/ia32_signal.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/x86_64/ia32/ia32entry.S
浏览文件 @ aef7b83c
此差异已折叠。
arch/x86_64/kernel/Makefile
浏览文件 @ aef7b83c
此差异已折叠。
arch/x86_64/kernel/acpi/wakeup.S
浏览文件 @ aef7b83c
此差异已折叠。
arch/x86_64/kernel/aperture.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/x86_64/kernel/apic.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/x86_64/kernel/crash.c 0 → 100644
浏览文件 @ aef7b83c
此差异已折叠。
arch/x86_64/kernel/e820.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/x86_64/kernel/early_printk.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/x86_64/kernel/entry.S
浏览文件 @ aef7b83c
此差异已折叠。
arch/x86_64/kernel/genapic_flat.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/x86_64/kernel/head.S
浏览文件 @ aef7b83c
此差异已折叠。
arch/x86_64/kernel/head64.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/x86_64/kernel/i387.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/x86_64/kernel/i8259.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/x86_64/kernel/io_apic.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/x86_64/kernel/irq.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/x86_64/kernel/kprobes.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/x86_64/kernel/machine_kexec.c 0 → 100644
浏览文件 @ aef7b83c
此差异已折叠。
arch/x86_64/kernel/mce.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/x86_64/kernel/mce_intel.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/x86_64/kernel/mpparse.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/x86_64/kernel/nmi.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/x86_64/kernel/pmtimer.c 0 → 100644
浏览文件 @ aef7b83c
此差异已折叠。
arch/x86_64/kernel/process.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/x86_64/kernel/ptrace.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/x86_64/kernel/reboot.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/x86_64/kernel/relocate_kernel.S 0 → 100644
浏览文件 @ aef7b83c
此差异已折叠。
arch/x86_64/kernel/setup.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/x86_64/kernel/setup64.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/x86_64/kernel/signal.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/x86_64/kernel/smp.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/x86_64/kernel/smpboot.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/x86_64/kernel/suspend.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/x86_64/kernel/sys_x86_64.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/x86_64/kernel/time.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/x86_64/kernel/traps.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/x86_64/kernel/vmlinux.lds.S
浏览文件 @ aef7b83c
此差异已折叠。
arch/x86_64/kernel/vsyscall.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/x86_64/kernel/x8664_ksyms.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/x86_64/lib/delay.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/x86_64/mm/Makefile
浏览文件 @ aef7b83c
此差异已折叠。
arch/x86_64/mm/fault.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/x86_64/mm/init.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/x86_64/mm/ioremap.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/x86_64/mm/numa.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/x86_64/pci/k8-bus.c
浏览文件 @ aef7b83c
此差异已折叠。
arch/xtensa/Kconfig 0 → 100644
浏览文件 @ aef7b83c
此差异已折叠。
arch/xtensa/Kconfig.debug 0 → 100644
浏览文件 @ aef7b83c
此差异已折叠。
arch/xtensa/Makefile 0 → 100644
浏览文件 @ aef7b83c
此差异已折叠。
arch/xtensa/boot/Makefile 0 → 100644
浏览文件 @ aef7b83c
此差异已折叠。
arch/xtensa/boot/boot-elf/Makefile 0 → 100644
浏览文件 @ aef7b83c
此差异已折叠。
arch/xtensa/boot/boot-elf/boot.ld 0 → 100644
浏览文件 @ aef7b83c
此差异已折叠。
arch/xtensa/boot/boot-elf/bootstrap.S 0 → 100644
浏览文件 @ aef7b83c
此差异已折叠。
arch/xtensa/boot/boot-redboot/Makefile 0 → 100644
浏览文件 @ aef7b83c
此差异已折叠。
arch/xtensa/boot/boot-redboot/boot.ld 0 → 100644
浏览文件 @ aef7b83c
此差异已折叠。
arch/xtensa/boot/boot-redboot/bootstrap.S 0 → 100644
浏览文件 @ aef7b83c
此差异已折叠。
arch/xtensa/boot/include/zlib.h 0 → 100644
浏览文件 @ aef7b83c
此差异已折叠。
arch/xtensa/boot/lib/Makefile 0 → 100644
浏览文件 @ aef7b83c
此差异已折叠。
arch/xtensa/boot/lib/memcpy.S 0 → 100644
浏览文件 @ aef7b83c
此差异已折叠。
arch/xtensa/boot/lib/zlib.c 0 → 100644
浏览文件 @ aef7b83c
此差异已折叠。
arch/xtensa/boot/lib/zmem.c 0 → 100644
浏览文件 @ aef7b83c
此差异已折叠。
arch/xtensa/boot/ramdisk/Makefile 0 → 100644
浏览文件 @ aef7b83c
此差异已折叠。
arch/xtensa/configs/common_defconfig 0 → 100644
浏览文件 @ aef7b83c
此差异已折叠。
arch/xtensa/configs/iss_defconfig 0 → 100644
浏览文件 @ aef7b83c
此差异已折叠。
arch/xtensa/kernel/Makefile 0 → 100644
浏览文件 @ aef7b83c
此差异已折叠。
arch/xtensa/kernel/align.S 0 → 100644
浏览文件 @ aef7b83c
此差异已折叠。
arch/xtensa/kernel/asm-offsets.c 0 → 100644
浏览文件 @ aef7b83c
此差异已折叠。
arch/xtensa/kernel/coprocessor.S 0 → 100644
浏览文件 @ aef7b83c
此差异已折叠。
arch/xtensa/kernel/entry.S 0 → 100644
浏览文件 @ aef7b83c
此差异已折叠。
arch/xtensa/kernel/head.S 0 → 100644
浏览文件 @ aef7b83c
此差异已折叠。
arch/xtensa/kernel/irq.c 0 → 100644
浏览文件 @ aef7b83c
此差异已折叠。
arch/xtensa/kernel/module.c 0 → 100644
浏览文件 @ aef7b83c
此差异已折叠。
arch/xtensa/kernel/pci-dma.c 0 → 100644
浏览文件 @ aef7b83c
此差异已折叠。
arch/xtensa/kernel/pci.c 0 → 100644
浏览文件 @ aef7b83c
此差异已折叠。
arch/xtensa/kernel/platform.c 0 → 100644
浏览文件 @ aef7b83c
此差异已折叠。
arch/xtensa/kernel/process.c 0 → 100644
浏览文件 @ aef7b83c
此差异已折叠。
arch/xtensa/kernel/ptrace.c 0 → 100644
浏览文件 @ aef7b83c
此差异已折叠。
arch/xtensa/kernel/semaphore.c 0 → 100644
浏览文件 @ aef7b83c
此差异已折叠。
arch/xtensa/kernel/setup.c 0 → 100644
浏览文件 @ aef7b83c
此差异已折叠。
arch/xtensa/kernel/signal.c 0 → 100644
浏览文件 @ aef7b83c
此差异已折叠。
arch/xtensa/kernel/syscalls.c 0 → 100644
浏览文件 @ aef7b83c
此差异已折叠。
arch/xtensa/kernel/syscalls.h 0 → 100644
浏览文件 @ aef7b83c
此差异已折叠。
arch/xtensa/kernel/time.c 0 → 100644
浏览文件 @ aef7b83c
此差异已折叠。
arch/xtensa/kernel/traps.c 0 → 100644
浏览文件 @ aef7b83c
此差异已折叠。
arch/xtensa/kernel/vectors.S 0 → 100644
浏览文件 @ aef7b83c
此差异已折叠。
arch/xtensa/kernel/vmlinux.lds.S 0 → 100644
浏览文件 @ aef7b83c
此差异已折叠。
arch/xtensa/kernel/xtensa_ksyms.c 0 → 100644
浏览文件 @ aef7b83c
此差异已折叠。
arch/xtensa/lib/Makefile 0 → 100644
浏览文件 @ aef7b83c
此差异已折叠。
arch/xtensa/lib/checksum.S 0 → 100644
浏览文件 @ aef7b83c
此差异已折叠。
arch/xtensa/lib/memcopy.S 0 → 100644
浏览文件 @ aef7b83c
此差异已折叠。
arch/xtensa/lib/memset.S 0 → 100644
浏览文件 @ aef7b83c
此差异已折叠。
arch/xtensa/lib/pci-auto.c 0 → 100644
浏览文件 @ aef7b83c
此差异已折叠。
arch/xtensa/lib/strcasecmp.c 0 → 100644
浏览文件 @ aef7b83c
此差异已折叠。
arch/xtensa/lib/strncpy_user.S 0 → 100644
浏览文件 @ aef7b83c
此差异已折叠。
arch/xtensa/lib/strnlen_user.S 0 → 100644
浏览文件 @ aef7b83c
此差异已折叠。
arch/xtensa/lib/usercopy.S 0 → 100644
浏览文件 @ aef7b83c
此差异已折叠。
arch/xtensa/mm/Makefile 0 → 100644
浏览文件 @ aef7b83c
此差异已折叠。
arch/xtensa/mm/fault.c 0 → 100644
浏览文件 @ aef7b83c
此差异已折叠。
arch/xtensa/mm/init.c 0 → 100644
浏览文件 @ aef7b83c
此差异已折叠。
arch/xtensa/mm/misc.S 0 → 100644
浏览文件 @ aef7b83c
此差异已折叠。
arch/xtensa/mm/pgtable.c 0 → 100644
浏览文件 @ aef7b83c
此差异已折叠。
arch/xtensa/mm/tlb.c 0 → 100644
浏览文件 @ aef7b83c
此差异已折叠。
arch/xtensa/platform-iss/Makefile 0 → 100644
浏览文件 @ aef7b83c
此差异已折叠。
arch/xtensa/platform-iss/console.c 0 → 100644
浏览文件 @ aef7b83c
此差异已折叠。
arch/xtensa/platform-iss/io.c 0 → 100644
浏览文件 @ aef7b83c
此差异已折叠。
arch/xtensa/platform-iss/network.c 0 → 100644
浏览文件 @ aef7b83c
此差异已折叠。
arch/xtensa/platform-iss/setup.c 0 → 100644
浏览文件 @ aef7b83c
此差异已折叠。
crypto/crypto_null.c
浏览文件 @ aef7b83c
此差异已折叠。
crypto/internal.h
浏览文件 @ aef7b83c
此差异已折叠。
crypto/tcrypt.c
浏览文件 @ aef7b83c
此差异已折叠。
crypto/tcrypt.h
浏览文件 @ aef7b83c
此差异已折叠。
drivers/Kconfig
浏览文件 @ aef7b83c
此差异已折叠。
drivers/Makefile
浏览文件 @ aef7b83c
此差异已折叠。
drivers/acorn/char/pcf8583.c
浏览文件 @ aef7b83c
此差异已折叠。
drivers/acpi/Kconfig
浏览文件 @ aef7b83c
此差异已折叠。
drivers/acpi/pci_irq.c
浏览文件 @ aef7b83c
此差异已折叠。
drivers/acpi/processor_idle.c
浏览文件 @ aef7b83c
此差异已折叠。
drivers/acpi/scan.c
浏览文件 @ aef7b83c
此差异已折叠。
drivers/atm/Makefile
浏览文件 @ aef7b83c
此差异已折叠。
drivers/atm/fore200e.c
浏览文件 @ aef7b83c
此差异已折叠。
drivers/atm/he.c
浏览文件 @ aef7b83c
此差异已折叠。
drivers/atm/nicstar.c
浏览文件 @ aef7b83c
此差异已折叠。
drivers/atm/zatm.c
浏览文件 @ aef7b83c
此差异已折叠。
drivers/base/Makefile
浏览文件 @ aef7b83c
此差异已折叠。
drivers/base/base.h
浏览文件 @ aef7b83c
此差异已折叠。
drivers/base/bus.c
浏览文件 @ aef7b83c
此差异已折叠。
drivers/base/class.c
浏览文件 @ aef7b83c
此差异已折叠。
drivers/base/class_simple.c 已删除 100644 → 0
浏览文件 @ b1fc5505
此差异已折叠。
drivers/base/core.c
浏览文件 @ aef7b83c
此差异已折叠。
drivers/base/cpu.c
浏览文件 @ aef7b83c
此差异已折叠。
drivers/base/dd.c 0 → 100644
浏览文件 @ aef7b83c
此差异已折叠。
drivers/base/dmapool.c
浏览文件 @ aef7b83c
此差异已折叠。
drivers/base/driver.c
浏览文件 @ aef7b83c
此差异已折叠。
drivers/base/interface.c 已删除 100644 → 0
浏览文件 @ b1fc5505
此差异已折叠。
drivers/base/node.c
浏览文件 @ aef7b83c
此差异已折叠。
drivers/base/power/power.h
浏览文件 @ aef7b83c
此差异已折叠。
drivers/base/power/resume.c
浏览文件 @ aef7b83c
此差异已折叠。
drivers/base/power/shutdown.c
浏览文件 @ aef7b83c
此差异已折叠。
drivers/base/power/suspend.c
浏览文件 @ aef7b83c
此差异已折叠。
drivers/base/power/sysfs.c
浏览文件 @ aef7b83c
此差异已折叠。
drivers/base/sys.c
浏览文件 @ aef7b83c
此差异已折叠。
drivers/block/aoe/aoechr.c
浏览文件 @ aef7b83c
此差异已折叠。
drivers/block/as-iosched.c
浏览文件 @ aef7b83c
此差异已折叠。
drivers/block/cciss.c
浏览文件 @ aef7b83c
此差异已折叠。
drivers/block/cfq-iosched.c
浏览文件 @ aef7b83c
此差异已折叠。
drivers/block/deadline-iosched.c
浏览文件 @ aef7b83c
此差异已折叠。
drivers/block/elevator.c
浏览文件 @ aef7b83c
此差异已折叠。
drivers/block/genhd.c
浏览文件 @ aef7b83c
此差异已折叠。
drivers/block/ioctl.c
浏览文件 @ aef7b83c
此差异已折叠。
drivers/block/ll_rw_blk.c
浏览文件 @ aef7b83c
此差异已折叠。
drivers/block/loop.c
浏览文件 @ aef7b83c
此差异已折叠。
drivers/block/paride/pd.c
浏览文件 @ aef7b83c
此差异已折叠。
drivers/block/paride/pg.c
浏览文件 @ aef7b83c
此差异已折叠。
drivers/block/paride/pt.c
浏览文件 @ aef7b83c
此差异已折叠。
drivers/block/pktcdvd.c
浏览文件 @ aef7b83c
此差异已折叠。
drivers/block/sx8.c
浏览文件 @ aef7b83c
此差异已折叠。
drivers/block/ub.c
浏览文件 @ aef7b83c
此差异已折叠。
drivers/bluetooth/hci_ldisc.c
浏览文件 @ aef7b83c
此差异已折叠。
drivers/cdrom/cm206.c
浏览文件 @ aef7b83c
此差异已折叠。
drivers/cdrom/sonycd535.c
浏览文件 @ aef7b83c
此差异已折叠。
drivers/cdrom/viocd.c
浏览文件 @ aef7b83c
此差异已折叠。
drivers/char/Kconfig
浏览文件 @ aef7b83c
此差异已折叠。
drivers/char/Makefile
浏览文件 @ aef7b83c
此差异已折叠。
drivers/char/agp/agp.h
浏览文件 @ aef7b83c
此差异已折叠。
drivers/char/agp/ali-agp.c
浏览文件 @ aef7b83c
此差异已折叠。
drivers/char/agp/amd-k7-agp.c
浏览文件 @ aef7b83c
此差异已折叠。
drivers/char/agp/amd64-agp.c
浏览文件 @ aef7b83c
此差异已折叠。
drivers/char/agp/ati-agp.c
浏览文件 @ aef7b83c
此差异已折叠。
drivers/char/agp/backend.c
浏览文件 @ aef7b83c
此差异已折叠。
drivers/char/agp/efficeon-agp.c
浏览文件 @ aef7b83c
此差异已折叠。
drivers/char/agp/generic.c
浏览文件 @ aef7b83c
此差异已折叠。
drivers/char/agp/hp-agp.c
浏览文件 @ aef7b83c
此差异已折叠。
drivers/char/agp/i460-agp.c
浏览文件 @ aef7b83c
此差异已折叠。
drivers/char/agp/intel-agp.c
浏览文件 @ aef7b83c
此差异已折叠。
drivers/char/agp/sgi-agp.c
浏览文件 @ aef7b83c
此差异已折叠。
drivers/char/agp/sworks-agp.c
浏览文件 @ aef7b83c
此差异已折叠。
drivers/char/agp/uninorth-agp.c
浏览文件 @ aef7b83c
此差异已折叠。
drivers/char/amiserial.c
浏览文件 @ aef7b83c
此差异已折叠。
drivers/char/applicom.c
浏览文件 @ aef7b83c
此差异已折叠。
drivers/char/drm/Kconfig
浏览文件 @ aef7b83c
此差异已折叠。
drivers/char/drm/Makefile
浏览文件 @ aef7b83c
此差异已折叠。
drivers/char/drm/drmP.h
浏览文件 @ aef7b83c
此差异已折叠。
drivers/char/drm/drm_bufs.c
浏览文件 @ aef7b83c
此差异已折叠。
drivers/char/drm/drm_context.c
浏览文件 @ aef7b83c
此差异已折叠。
drivers/char/drm/drm_ioc32.c 0 → 100644
浏览文件 @ aef7b83c
此差异已折叠。
drivers/char/drm/drm_pciids.h
浏览文件 @ aef7b83c
此差异已折叠。
drivers/char/drm/i915_dma.c
浏览文件 @ aef7b83c
此差异已折叠。
drivers/char/drm/i915_drm.h
浏览文件 @ aef7b83c
此差异已折叠。
drivers/char/drm/i915_drv.c
浏览文件 @ aef7b83c
此差异已折叠。
drivers/char/drm/i915_drv.h
浏览文件 @ aef7b83c
此差异已折叠。
drivers/char/drm/i915_irq.c
浏览文件 @ aef7b83c
此差异已折叠。
drivers/char/drm/i915_mem.c
浏览文件 @ aef7b83c
此差异已折叠。
drivers/char/drm/radeon_drv.c
浏览文件 @ aef7b83c
此差异已折叠。
drivers/char/drm/radeon_drv.h
浏览文件 @ aef7b83c
此差异已折叠。
drivers/char/drm/radeon_ioc32.c 0 → 100644
浏览文件 @ aef7b83c
此差异已折叠。
drivers/char/drm/radeon_irq.c
浏览文件 @ aef7b83c
此差异已折叠。
drivers/char/ds1620.c
浏览文件 @ aef7b83c
此差异已折叠。
drivers/char/dsp56k.c
浏览文件 @ aef7b83c
此差异已折叠。
drivers/char/hpet.c
浏览文件 @ aef7b83c
此差异已折叠。
drivers/char/hvcs.c
浏览文件 @ aef7b83c
此差异已折叠。
drivers/char/i8k.c
浏览文件 @ aef7b83c
此差异已折叠。
drivers/char/ip2/i2cmd.c
浏览文件 @ aef7b83c
此差异已折叠。
drivers/char/ip2/i2cmd.h
浏览文件 @ aef7b83c
此差异已折叠。
drivers/char/ip2main.c
浏览文件 @ aef7b83c
此差异已折叠。
drivers/char/ipmi/ipmi_devintf.c
浏览文件 @ aef7b83c
此差异已折叠。
drivers/char/ipmi/ipmi_msghandler.c
浏览文件 @ aef7b83c
此差异已折叠。
drivers/char/ipmi/ipmi_poweroff.c
浏览文件 @ aef7b83c
此差异已折叠。
drivers/char/isicom.c
浏览文件 @ aef7b83c
此差异已折叠。
drivers/char/istallion.c
浏览文件 @ aef7b83c
此差异已折叠。
drivers/char/lp.c
浏览文件 @ aef7b83c
此差异已折叠。
drivers/char/mbcs.c
浏览文件 @ aef7b83c
此差异已折叠。
drivers/char/mem.c
浏览文件 @ aef7b83c
此差异已折叠。
drivers/char/misc.c
浏览文件 @ aef7b83c
此差异已折叠。
drivers/char/mwave/3780i.c
浏览文件 @ aef7b83c
此差异已折叠。
drivers/char/mwave/3780i.h
浏览文件 @ aef7b83c
此差异已折叠。
drivers/char/mwave/mwavedd.c
浏览文件 @ aef7b83c
此差异已折叠。
drivers/char/mwave/tp3780i.c
浏览文件 @ aef7b83c
此差异已折叠。
drivers/char/mxser.c
浏览文件 @ aef7b83c
此差异已折叠。
drivers/char/n_hdlc.c
浏览文件 @ aef7b83c
此差异已折叠。
drivers/char/n_r3964.c
浏览文件 @ aef7b83c
此差异已折叠。
drivers/char/nvram.c
浏览文件 @ aef7b83c
此差异已折叠。
drivers/char/ppdev.c
浏览文件 @ aef7b83c
此差异已折叠。
drivers/char/raw.c
浏览文件 @ aef7b83c
此差异已折叠。
drivers/char/rio/func.h
浏览文件 @ aef7b83c
此差异已折叠。
drivers/char/rio/rio_linux.c
浏览文件 @ aef7b83c
此差异已折叠。
drivers/char/rio/rioinit.c
浏览文件 @ aef7b83c
此差异已折叠。
drivers/char/rio/riotty.c
浏览文件 @ aef7b83c
此差异已折叠。
drivers/char/rocket.c
浏览文件 @ aef7b83c
此差异已折叠。
drivers/char/rocket_int.h
浏览文件 @ aef7b83c
此差异已折叠。
drivers/char/snsc.c
浏览文件 @ aef7b83c
此差异已折叠。
drivers/char/stallion.c
浏览文件 @ aef7b83c
此差异已折叠。
drivers/char/sysrq.c
浏览文件 @ aef7b83c
此差异已折叠。
drivers/char/tipar.c
浏览文件 @ aef7b83c
此差异已折叠。
drivers/char/toshiba.c
浏览文件 @ aef7b83c
此差异已折叠。
drivers/char/tpm/tpm.c
浏览文件 @ aef7b83c
此差异已折叠。
drivers/char/tpm/tpm.h
浏览文件 @ aef7b83c
此差异已折叠。
drivers/char/tpm/tpm_atmel.c
浏览文件 @ aef7b83c
此差异已折叠。
drivers/char/tpm/tpm_nsc.c
浏览文件 @ aef7b83c
此差异已折叠。
drivers/char/tty_io.c
浏览文件 @ aef7b83c
此差异已折叠。
drivers/char/vc_screen.c
浏览文件 @ aef7b83c
此差异已折叠。
drivers/char/viotape.c
浏览文件 @ aef7b83c
此差异已折叠。
drivers/char/vr41xx_giu.c 0 → 100644
浏览文件 @ aef7b83c
此差异已折叠。
drivers/char/vt.c
浏览文件 @ aef7b83c
此差异已折叠。
drivers/char/watchdog/Kconfig
浏览文件 @ aef7b83c
此差异已折叠。
drivers/char/watchdog/Makefile
浏览文件 @ aef7b83c
此差异已折叠。
drivers/char/watchdog/i8xx_tco.c
浏览文件 @ aef7b83c
此差异已折叠。
drivers/char/watchdog/ixp2000_wdt.c
浏览文件 @ aef7b83c
此差异已折叠。
drivers/char/watchdog/wdrtas.c 0 → 100644
浏览文件 @ aef7b83c
此差异已折叠。
drivers/cpufreq/Kconfig
浏览文件 @ aef7b83c
此差异已折叠。
drivers/cpufreq/Makefile
浏览文件 @ aef7b83c
此差异已折叠。
drivers/cpufreq/cpufreq.c
浏览文件 @ aef7b83c
此差异已折叠。
drivers/cpufreq/cpufreq_conservative.c 0 → 100644
浏览文件 @ aef7b83c
此差异已折叠。
drivers/cpufreq/cpufreq_ondemand.c
浏览文件 @ aef7b83c
此差异已折叠。
drivers/cpufreq/cpufreq_stats.c
浏览文件 @ aef7b83c
此差异已折叠。
drivers/dio/dio-sysfs.c
浏览文件 @ aef7b83c
此差异已折叠。
drivers/eisa/eisa-bus.c
浏览文件 @ aef7b83c
此差异已折叠。
drivers/fc4/fc.c
浏览文件 @ aef7b83c
此差异已折叠。
drivers/fc4/fc_syms.c
浏览文件 @ aef7b83c
此差异已折叠。
drivers/fc4/fcp_impl.h
浏览文件 @ aef7b83c
此差异已折叠。
Markdown is supported
0% 或 .
You are about to add 0 people to the discussion. Proceed with caution.
先完成此消息的编辑！
想要评论请 注册 或