Merge /spare/repo/linux-2.6/
This commit is contained in:
commit
aef7b83c92
23
CREDITS
23
CREDITS
|
@ -882,13 +882,12 @@ S: Blacksburg, Virginia 24061
|
|||
S: USA
|
||||
|
||||
N: Randy Dunlap
|
||||
E: rddunlap@osdl.org
|
||||
E: rdunlap@xenotime.net
|
||||
W: http://www.xenotime.net/linux/linux.html
|
||||
W: http://www.linux-usb.org
|
||||
D: Linux-USB subsystem, USB core/UHCI/printer/storage drivers
|
||||
D: x86 SMP, ACPI, bootflag hacking
|
||||
S: 12725 SW Millikan Way, Suite 400
|
||||
S: Beaverton, Oregon 97005
|
||||
S: (ask for current address)
|
||||
S: USA
|
||||
|
||||
N: Bob Dunlop
|
||||
|
@ -1881,6 +1880,13 @@ S: Schlehenweg 9
|
|||
S: D-91080 Uttenreuth
|
||||
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
|
||||
M: seasons@falcon.sch.bme.hu
|
||||
M: seasons@makosteszta.sote.hu
|
||||
|
@ -2374,9 +2380,10 @@ E: tmolina@cablespeed.com
|
|||
D: bug fixes, documentation, minor hackery
|
||||
|
||||
N: James Morris
|
||||
E: jmorris@intercode.com.au
|
||||
E: jmorris@redhat.com
|
||||
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: Spit Junction NSW 2088
|
||||
S: Australia
|
||||
|
@ -2476,13 +2483,9 @@ S: Potsdam, New York 13676
|
|||
S: USA
|
||||
|
||||
N: Dave Neuer
|
||||
E: dneuer@innovation-charter.com
|
||||
E: mr_fred_smoothie@yahoo.com
|
||||
E: dave.neuer@pobox.com
|
||||
D: Helped implement support for Compaq's H31xx series iPAQs
|
||||
D: Other mostly minor tweaks & bugfixes
|
||||
S: 325 E. Main St., Suite 3
|
||||
S: Carnegie, PA 15105
|
||||
S: USA
|
||||
|
||||
N: Michael Neuffer
|
||||
E: mike@i-Connect.Net
|
||||
|
|
|
@ -138,6 +138,8 @@ java.txt
|
|||
- info on the in-kernel binary support for Java(tm).
|
||||
kbuild/
|
||||
- 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
|
||||
- mini HowTo on generation and location of kernel documentation files.
|
||||
kernel-docs.txt
|
||||
|
|
|
@ -63,7 +63,7 @@ o PPP 2.4.0 # pppd --version
|
|||
o isdn4k-utils 3.1pre1 # isdnctrl 2>&1|grep version
|
||||
o nfs-utils 1.0.5 # showmount --version
|
||||
o procps 3.2.0 # ps --version
|
||||
o oprofile 0.5.3 # oprofiled --version
|
||||
o oprofile 0.9 # oprofiled --version
|
||||
|
||||
Kernel compilation
|
||||
==================
|
||||
|
|
|
@ -8,7 +8,7 @@
|
|||
|
||||
DOCBOOKS := wanbook.xml z8530book.xml mcabook.xml videobook.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 \
|
||||
gadget.xml libata.xml mtdnand.xml librs.xml
|
||||
|
||||
|
@ -49,7 +49,7 @@ installmandocs: mandocs
|
|||
KERNELDOC = scripts/kernel-doc
|
||||
DOCPROC = scripts/basic/docproc
|
||||
|
||||
XMLTOFLAGS = -m Documentation/DocBook/stylesheet.xsl
|
||||
XMLTOFLAGS = -m $(srctree)/Documentation/DocBook/stylesheet.xsl
|
||||
#XMLTOFLAGS += --skip-validation
|
||||
|
||||
###
|
||||
|
|
|
@ -266,7 +266,7 @@ X!Ekernel/module.c
|
|||
<chapter id="hardware">
|
||||
<title>Hardware Interfaces</title>
|
||||
<sect1><title>Interrupt Handling</title>
|
||||
!Iarch/i386/kernel/irq.c
|
||||
!Ikernel/irq/manage.c
|
||||
</sect1>
|
||||
|
||||
<sect1><title>Resources Management</title>
|
||||
|
@ -338,7 +338,6 @@ X!Earch/i386/kernel/mca.c
|
|||
X!Iinclude/linux/device.h
|
||||
-->
|
||||
!Edrivers/base/driver.c
|
||||
!Edrivers/base/class_simple.c
|
||||
!Edrivers/base/core.c
|
||||
!Edrivers/base/firmware_class.c
|
||||
!Edrivers/base/transport_class.c
|
||||
|
|
|
@ -14,7 +14,7 @@
|
|||
</authorgroup>
|
||||
|
||||
<copyright>
|
||||
<year>2003</year>
|
||||
<year>2003-2005</year>
|
||||
<holder>Jeff Garzik</holder>
|
||||
</copyright>
|
||||
|
||||
|
@ -44,30 +44,38 @@
|
|||
|
||||
<toc></toc>
|
||||
|
||||
<chapter id="libataThanks">
|
||||
<title>Thanks</title>
|
||||
<chapter id="libataIntroduction">
|
||||
<title>Introduction</title>
|
||||
<para>
|
||||
The bulk of the ATA knowledge comes thanks to long conversations with
|
||||
Andre Hedrick (www.linux-ide.org).
|
||||
libATA is a library used inside the Linux kernel to support ATA host
|
||||
controllers and devices. libATA provides an ATA driver API, class
|
||||
transports for ATA and ATAPI devices, and SCSI<->ATA translation
|
||||
for ATA devices according to the T10 SAT specification.
|
||||
</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).
|
||||
This Guide documents the libATA driver API, library functions, library
|
||||
internals, and a couple sample ATA low-level drivers.
|
||||
</para>
|
||||
</chapter>
|
||||
|
||||
<chapter id="libataDriverApi">
|
||||
<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>
|
||||
<title>struct ata_port_operations</title>
|
||||
|
||||
<sect2><title>Disable ATA port</title>
|
||||
<programlisting>
|
||||
void (*port_disable) (struct ata_port *);
|
||||
</programlisting>
|
||||
|
@ -78,6 +86,9 @@ void (*port_disable) (struct ata_port *);
|
|||
unplug).
|
||||
</para>
|
||||
|
||||
</sect2>
|
||||
|
||||
<sect2><title>Post-IDENTIFY device configuration</title>
|
||||
<programlisting>
|
||||
void (*dev_config) (struct ata_port *, struct ata_device *);
|
||||
</programlisting>
|
||||
|
@ -88,6 +99,9 @@ void (*dev_config) (struct ata_port *, struct ata_device *);
|
|||
issue of SET FEATURES - XFER MODE, and prior to operation.
|
||||
</para>
|
||||
|
||||
</sect2>
|
||||
|
||||
<sect2><title>Set PIO/DMA mode</title>
|
||||
<programlisting>
|
||||
void (*set_piomode) (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);
|
|||
->set_dma_mode() is only called if DMA is possible.
|
||||
</para>
|
||||
|
||||
</sect2>
|
||||
|
||||
<sect2><title>Taskfile read/write</title>
|
||||
<programlisting>
|
||||
void (*tf_load) (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);
|
|||
taskfile register values.
|
||||
</para>
|
||||
|
||||
</sect2>
|
||||
|
||||
<sect2><title>ATA command execute</title>
|
||||
<programlisting>
|
||||
void (*exec_command)(struct ata_port *ap, struct ata_taskfile *tf);
|
||||
</programlisting>
|
||||
|
@ -129,17 +149,37 @@ void (*exec_command)(struct ata_port *ap, struct ata_taskfile *tf);
|
|||
->tf_load(), to be initiated in hardware.
|
||||
</para>
|
||||
|
||||
</sect2>
|
||||
|
||||
<sect2><title>Per-cmd ATAPI DMA capabilities filter</title>
|
||||
<programlisting>
|
||||
u8 (*check_status)(struct ata_port *ap);
|
||||
void (*dev_select)(struct ata_port *ap, unsigned int device);
|
||||
int (*check_atapi_dma) (struct ata_queued_cmd *qc);
|
||||
</programlisting>
|
||||
|
||||
<para>
|
||||
Reads the Status ATA shadow register from hardware. On some
|
||||
hardware, this has the side effect of clearing the interrupt
|
||||
condition.
|
||||
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>
|
||||
u8 (*check_status)(struct ata_port *ap);
|
||||
u8 (*check_altstatus)(struct ata_port *ap);
|
||||
u8 (*check_err)(struct ata_port *ap);
|
||||
</programlisting>
|
||||
|
||||
<para>
|
||||
Reads the Status/AltStatus/Error ATA shadow register from
|
||||
hardware. On some hardware, reading the Status register has
|
||||
the side effect of clearing the interrupt condition.
|
||||
</para>
|
||||
|
||||
</sect2>
|
||||
|
||||
<sect2><title>Select ATA device on bus</title>
|
||||
<programlisting>
|
||||
void (*dev_select)(struct ata_port *ap, unsigned int device);
|
||||
</programlisting>
|
||||
|
@ -147,9 +187,13 @@ void (*dev_select)(struct ata_port *ap, unsigned int device);
|
|||
<para>
|
||||
Issues the low-level hardware command(s) that causes one of N
|
||||
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>
|
||||
|
||||
</sect2>
|
||||
|
||||
<sect2><title>Reset ATA bus</title>
|
||||
<programlisting>
|
||||
void (*phy_reset) (struct ata_port *ap);
|
||||
</programlisting>
|
||||
|
@ -162,17 +206,31 @@ void (*phy_reset) (struct ata_port *ap);
|
|||
functions ata_bus_reset() or sata_phy_reset() for this hook.
|
||||
</para>
|
||||
|
||||
</sect2>
|
||||
|
||||
<sect2><title>Control PCI IDE BMDMA engine</title>
|
||||
<programlisting>
|
||||
void (*bmdma_setup) (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>
|
||||
|
||||
<para>
|
||||
When setting up an IDE BMDMA transaction, these hooks arm
|
||||
(->bmdma_setup) and fire (->bmdma_start) the hardware's DMA
|
||||
engine.
|
||||
When setting up an IDE BMDMA transaction, these hooks arm
|
||||
(->bmdma_setup), fire (->bmdma_start), and halt (->bmdma_stop)
|
||||
the hardware's DMA engine. ->bmdma_status is used to read the standard
|
||||
PCI IDE DMA Status register.
|
||||
</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>
|
||||
void (*qc_prep) (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);
|
|||
->qc_issue is used to make a command active, once the hardware
|
||||
and S/G tables have been prepared. IDE BMDMA drivers use the
|
||||
helper function ata_qc_issue_prot() for taskfile protocol-based
|
||||
dispatch. More advanced drivers roll their own ->qc_issue
|
||||
implementation, using this as the "issue new ATA command to
|
||||
hardware" hook.
|
||||
dispatch. More advanced drivers implement their own ->qc_issue.
|
||||
</para>
|
||||
|
||||
</sect2>
|
||||
|
||||
<sect2><title>Timeout (error) handling</title>
|
||||
<programlisting>
|
||||
void (*eng_timeout) (struct ata_port *ap);
|
||||
</programlisting>
|
||||
|
||||
<para>
|
||||
This is a high level error handling function, called from the
|
||||
error handling thread, when a command times out.
|
||||
This is a high level error handling function, called from the
|
||||
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>
|
||||
|
||||
</sect2>
|
||||
|
||||
<sect2><title>Hardware interrupt handling</title>
|
||||
<programlisting>
|
||||
irqreturn_t (*irq_handler)(int, void *, struct pt_regs *);
|
||||
void (*irq_clear) (struct ata_port *);
|
||||
|
@ -216,6 +280,9 @@ void (*irq_clear) (struct ata_port *);
|
|||
is quiet.
|
||||
</para>
|
||||
|
||||
</sect2>
|
||||
|
||||
<sect2><title>SATA phy read/write</title>
|
||||
<programlisting>
|
||||
u32 (*scr_read) (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,
|
|||
if ->phy_reset hook called the sata_phy_reset() helper function.
|
||||
</para>
|
||||
|
||||
</sect2>
|
||||
|
||||
<sect2><title>Init and shutdown</title>
|
||||
<programlisting>
|
||||
int (*port_start) (struct ata_port *ap);
|
||||
void (*port_stop) (struct ata_port *ap);
|
||||
|
@ -240,15 +310,17 @@ void (*host_stop) (struct ata_host_set *host_set);
|
|||
tasks.
|
||||
</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
|
||||
is to release DMA/memory resources, now that they are no longer
|
||||
actively being used.
|
||||
</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>
|
||||
</chapter>
|
||||
|
@ -279,4 +351,24 @@ void (*host_stop) (struct ata_host_set *host_set);
|
|||
!Idrivers/scsi/sata_sil.c
|
||||
</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>
|
||||
|
|
|
@ -1,193 +0,0 @@
|
|||
<?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>
|
|
@ -2,4 +2,5 @@
|
|||
<stylesheet xmlns="http://www.w3.org/1999/XSL/Transform" version="1.0">
|
||||
<param name="chunk.quietly">1</param>
|
||||
<param name="funcsynopsis.style">ansi</param>
|
||||
<param name="funcsynopsis.tabular.threshold">80</param>
|
||||
</stylesheet>
|
||||
|
|
|
@ -25,9 +25,10 @@ subject and I can't cover it all here!
|
|||
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
|
||||
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
|
||||
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.
|
||||
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
|
||||
want access through a device driver. Another interface is also
|
||||
available, you may select 'IPMI sockets' in the 'Networking Support'
|
||||
main menu. This provides a socket interface to IPMI. You may select
|
||||
both of these at the same time, they will both work together.
|
||||
want access through a device driver.
|
||||
|
||||
The driver interface depends on your hardware. If you have a board
|
||||
with a standard interface (These will generally be either "KCS",
|
||||
"SMIC", or "BT", consult your hardware manual), choose the 'IPMI SI
|
||||
handler' option. A driver also exists for direct I2C access to the
|
||||
IPMI management controller. Some boards support this, but it is
|
||||
unknown if it will work on every board. For this, choose 'IPMI SMBus
|
||||
handler', but be ready to try to do some figuring to see if it will
|
||||
work.
|
||||
|
||||
There is also a KCS-only driver interface supplied, but it is
|
||||
depracated in favor of the SI interface.
|
||||
The driver interface depends on your hardware. If your system
|
||||
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
|
||||
will generally be either "KCS", "SMIC", or "BT", consult your hardware
|
||||
manual), choose the 'IPMI SI handler' option. A driver also exists
|
||||
for direct I2C access to the IPMI management controller. Some boards
|
||||
support this, but it is unknown if it will work on every board. For
|
||||
this, choose 'IPMI SMBus handler', but be ready to try to do some
|
||||
figuring to see if it will work on your system if the SMBIOS/APCI
|
||||
information is wrong or not present. It is fairly safe to have both
|
||||
these enabled and let the drivers auto-detect what is present.
|
||||
|
||||
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
|
||||
their job correctly, the IPMI controller should be automatically
|
||||
detect (via ACPI or SMBIOS tables) and should just work. Sadly, many
|
||||
boards do not have this information. The driver attempts standard
|
||||
defaults, but they may not work. If you fall into this situation, you
|
||||
need to read the section below named 'The SI Driver' on how to
|
||||
hand-configure your system.
|
||||
detected (via ACPI or SMBIOS tables) and should just work. Sadly,
|
||||
many boards do not have this information. The driver attempts
|
||||
standard defaults, but they may not work. If you fall into this
|
||||
situation, you need to read the section below named 'The SI Driver' or
|
||||
"The SMBus Driver" on how to hand-configure your system.
|
||||
|
||||
IPMI defines a standard watchdog timer. You can enable this with the
|
||||
'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
|
|||
Cards' menu, enable 'Watchdog Timer Support', and enable the option
|
||||
'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
|
||||
------------
|
||||
|
@ -80,7 +90,7 @@ Basic Design
|
|||
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
|
||||
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
|
||||
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
|
|||
driver, each open file for this device ties in to the message handler
|
||||
as an IPMI user.
|
||||
|
||||
ipmi_si - A driver for various system interfaces. This supports
|
||||
KCS, SMIC, and may support BT in the future. Unless you have your own
|
||||
custom interface, you probably need to use this.
|
||||
ipmi_si - A driver for various system interfaces. This supports KCS,
|
||||
SMIC, and BT interfaces. Unless you have an SMBus interface or your
|
||||
own custom interface, you probably need to use this.
|
||||
|
||||
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
|
||||
over the SMBus.
|
||||
|
||||
af_ipmi - A network socket interface to IPMI. This doesn't take up
|
||||
a character device in your system.
|
||||
ipmi_watchdog - IPMI requires systems to have a very capable watchdog
|
||||
timer. This driver implements the standard Linux watchdog timer
|
||||
interface on top of the IPMI message handler.
|
||||
|
||||
Note that the KCS-only interface ahs been removed.
|
||||
ipmi_poweroff - Some systems support the ability to be turned off via
|
||||
IPMI commands.
|
||||
|
||||
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
|
||||
IPMI include files are:
|
||||
|
@ -424,7 +442,7 @@ at module load time (for a module) with:
|
|||
modprobe ipmi_smb.o
|
||||
addr=<adapter1>,<i2caddr1>[,<adapter2>,<i2caddr2>[,...]]
|
||||
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
|
||||
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
|
|||
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
|
||||
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.
|
||||
|
|
|
@ -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
|
||||
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.
|
||||
|
@ -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
|
||||
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:
|
||||
|
||||
|
@ -291,9 +276,15 @@ can certify the below:
|
|||
person who certified (a), (b) or (c) and I have not modified
|
||||
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
|
||||
|
||||
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
|
||||
now, but you can do this to mark internal company procedures or just
|
||||
|
|
|
@ -27,9 +27,13 @@ dump output readprofile -m /boot/System.map > captured_profile
|
|||
|
||||
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-kernel-support
|
||||
make install
|
||||
|
||||
|
@ -46,7 +50,7 @@ start opcontrol --start
|
|||
stop opcontrol --stop
|
||||
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.
|
||||
|
||||
|
|
|
@ -419,6 +419,7 @@ into the file "track01":
|
|||
*/
|
||||
#include <stdio.h>
|
||||
#include <sys/ioctl.h>
|
||||
#include <sys/types.h>
|
||||
#include <linux/cdrom.h>
|
||||
|
||||
static struct cdrom_tochdr hdr;
|
||||
|
@ -429,7 +430,7 @@ static int datafile, drive;
|
|||
static int i, j, limit, track, err;
|
||||
static char filename[32];
|
||||
|
||||
main(int argc, char *argv[])
|
||||
int main(int argc, char *argv[])
|
||||
{
|
||||
/*
|
||||
* open /dev/cdrom
|
||||
|
@ -516,6 +517,7 @@ entry[track+1].cdte_addr.lba=entry[track].cdte_addr.lba+300;
|
|||
}
|
||||
arg.addr.lba++;
|
||||
}
|
||||
return 0;
|
||||
}
|
||||
/*===================== end program ========================================*/
|
||||
|
||||
|
@ -564,15 +566,16 @@ Appendix -- the "cdtester" utility:
|
|||
#include <stdio.h>
|
||||
#include <malloc.h>
|
||||
#include <sys/ioctl.h>
|
||||
#include <sys/types.h>
|
||||
#include <linux/cdrom.h>
|
||||
|
||||
#ifdef AZT_PRIVATE_IOCTLS
|
||||
#include <linux/../../drivers/cdrom/aztcd.h>
|
||||
#endif AZT_PRIVATE_IOCTLS
|
||||
#endif /* AZT_PRIVATE_IOCTLS */
|
||||
#ifdef SBP_PRIVATE_IOCTLS
|
||||
#include <linux/../../drivers/cdrom/sbpcd.h>
|
||||
#include <linux/fs.h>
|
||||
#endif SBP_PRIVATE_IOCTLS
|
||||
#endif /* SBP_PRIVATE_IOCTLS */
|
||||
|
||||
struct cdrom_tochdr hdr;
|
||||
struct cdrom_tochdr tocHdr;
|
||||
|
@ -590,7 +593,7 @@ union
|
|||
struct cdrom_msf msf;
|
||||
unsigned char buf[CD_FRAMESIZE_RAW];
|
||||
} azt;
|
||||
#endif AZT_PRIVATE_IOCTLS
|
||||
#endif /* AZT_PRIVATE_IOCTLS */
|
||||
int i, i1, i2, i3, j, k;
|
||||
unsigned char sequence=0;
|
||||
unsigned char command[80];
|
||||
|
@ -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("(C) 1995 Eberhard Moenkeberg <emoenke@gwdg.de>\n");
|
||||
|
@ -1046,12 +1049,13 @@ main(int argc, char *argv[])
|
|||
rc=ioctl(drive,CDROMAUDIOBUFSIZ,j);
|
||||
printf("%d frames granted.\n",rc);
|
||||
break;
|
||||
#endif SBP_PRIVATE_IOCTLS
|
||||
#endif /* SBP_PRIVATE_IOCTLS */
|
||||
default:
|
||||
printf("unknown command: \"%s\".\n",command);
|
||||
break;
|
||||
}
|
||||
}
|
||||
return 0;
|
||||
}
|
||||
/*==========================================================================*/
|
||||
|
||||
|
|
128
Documentation/cpu-freq/cpufreq-stats.txt
Normal file
128
Documentation/cpu-freq/cpufreq-stats.txt
Normal file
|
@ -0,0 +1,128 @@
|
|||
|
||||
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.
|
||||
|
||||
|
||||
|
||||
|
|
@ -9,6 +9,7 @@
|
|||
|
||||
|
||||
Dominik Brodowski <linux@brodo.de>
|
||||
some additions and corrections by Nico Golde <nico@ngolde.de>
|
||||
|
||||
|
||||
|
||||
|
@ -25,6 +26,7 @@ Contents:
|
|||
2.1 Performance
|
||||
2.2 Powersave
|
||||
2.3 Userspace
|
||||
2.4 Ondemand
|
||||
|
||||
3. The Governor Interface in the CPUfreq Core
|
||||
|
||||
|
@ -86,7 +88,7 @@ highest frequency within the borders of scaling_min_freq and
|
|||
scaling_max_freq.
|
||||
|
||||
|
||||
2.1 Powersave
|
||||
2.2 Powersave
|
||||
-------------
|
||||
|
||||
The CPUfreq governor "powersave" sets the CPU statically to the
|
||||
|
@ -94,7 +96,7 @@ lowest frequency within the borders of scaling_min_freq and
|
|||
scaling_max_freq.
|
||||
|
||||
|
||||
2.2 Userspace
|
||||
2.3 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
|
|||
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
|
||||
=============================================
|
||||
|
|
|
@ -51,6 +51,14 @@ mems_allowed vector.
|
|||
|
||||
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.
|
||||
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
|
||||
virtual file system, manage the attributes and permissions of these
|
||||
|
@ -84,6 +92,9 @@ This can be especially valuable on:
|
|||
and a database), or
|
||||
* NUMA systems running large HPC applications with demanding
|
||||
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
|
||||
adjusted, as the job mix changes, without impacting other concurrently
|
||||
|
@ -125,6 +136,8 @@ Cpusets extends these two mechanisms as follows:
|
|||
- A cpuset may be marked exclusive, which ensures that no other
|
||||
cpuset (except direct ancestors and descendents) may contain
|
||||
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.
|
||||
|
||||
The implementation of cpusets requires a few, simple hooks
|
||||
|
@ -136,6 +149,9 @@ into the rest of the kernel, none in performance critical paths:
|
|||
allowed in that tasks cpuset.
|
||||
- in sched.c migrate_all_tasks(), to keep migrating tasks within
|
||||
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
|
||||
Memory Nodes by what's allowed in that tasks cpuset.
|
||||
- in page_alloc, to restrict memory to allowed nodes.
|
||||
|
@ -252,8 +268,7 @@ in a tasks processor placement.
|
|||
There is an exception to the above. If hotplug funtionality is used
|
||||
to remove all the CPUs that are currently assigned to a cpuset,
|
||||
then the kernel will automatically update the cpus_allowed of all
|
||||
tasks attached to CPUs in that cpuset with the online CPUs of the
|
||||
nearest parent cpuset that still has some CPUs online. When memory
|
||||
tasks attached to CPUs in that cpuset to allow all CPUs. When memory
|
||||
hotplug functionality for removing Memory Nodes is available, a
|
||||
similar exception is expected to apply there as well. In general,
|
||||
the kernel prefers to violate cpuset placement, over starving a task
|
||||
|
|
|
@ -94,6 +94,7 @@ Your cooperation is appreciated.
|
|||
9 = /dev/urandom Faster, less secure random number gen.
|
||||
10 = /dev/aio Asyncronous I/O notification interface
|
||||
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
|
||||
0 = /dev/ram0 First RAM disk
|
||||
1 = /dev/ram1 Second RAM disk
|
||||
|
|
|
@ -111,6 +111,7 @@ mkdep
|
|||
mktables
|
||||
modpost
|
||||
modversions.h*
|
||||
offset.h
|
||||
offsets.h
|
||||
oui.c*
|
||||
parse.c*
|
||||
|
|
|
@ -76,6 +76,14 @@ driver_data: Driver-specific data.
|
|||
|
||||
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.
|
||||
|
||||
saved_state: Pointer to saved state of the device. This is usable by
|
||||
|
|
|
@ -5,21 +5,17 @@ struct device_driver {
|
|||
char * name;
|
||||
struct bus_type * bus;
|
||||
|
||||
rwlock_t lock;
|
||||
atomic_t refcount;
|
||||
|
||||
list_t bus_list;
|
||||
struct completion unloaded;
|
||||
struct kobject kobj;
|
||||
list_t devices;
|
||||
|
||||
struct driver_dir_entry dir;
|
||||
struct module *owner;
|
||||
|
||||
int (*probe) (struct device * dev);
|
||||
int (*remove) (struct device * dev);
|
||||
|
||||
int (*suspend) (struct device * dev, pm_message_t state, 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.
|
|||
static struct device_driver eepro100_driver = {
|
||||
.name = "eepro100",
|
||||
.bus = &pci_bus_type,
|
||||
.devclass = ðernet_devclass, /* when it's implemented */
|
||||
|
||||
.probe = eepro100_probe,
|
||||
.remove = eepro100_remove,
|
||||
|
@ -85,7 +80,6 @@ static struct pci_driver eepro100_driver = {
|
|||
.driver = {
|
||||
.name = "eepro100",
|
||||
.bus = &pci_bus_type,
|
||||
.devclass = ðernet_devclass, /* when it's implemented */
|
||||
.probe = eepro100_probe,
|
||||
.remove = eepro100_remove,
|
||||
.suspend = eepro100_suspend,
|
||||
|
@ -166,27 +160,32 @@ Callbacks
|
|||
|
||||
int (*probe) (struct device * dev);
|
||||
|
||||
probe is called to verify the existence of a certain type of
|
||||
hardware. This is called during the driver binding process, after the
|
||||
bus has verified that the device ID of a device matches one of the
|
||||
device IDs supported by the driver.
|
||||
The probe() entry is called in task context, with the bus's rwsem locked
|
||||
and the driver partially bound to the device. Drivers commonly use
|
||||
container_of() to convert "dev" to a bus-specific type, both in probe()
|
||||
and other routines. That type often provides device resource data, such
|
||||
as pci_dev.resource[] or platform_device.resources, which is used in
|
||||
addition to dev->platform_data to initialize the driver.
|
||||
|
||||
This callback only verifies that there actually is supported hardware
|
||||
present. It may allocate a driver-specific structure, but it should
|
||||
not do any initialization of the hardware itself. The device-specific
|
||||
structure may be stored in the device's driver_data field.
|
||||
This callback holds the driver-specific logic to bind the driver to a
|
||||
given device. That includes verifying that the device is present, that
|
||||
it's a version the driver can handle, that driver data structures can
|
||||
be allocated and initialized, and that any hardware can be initialized.
|
||||
Drivers often store a pointer to their state with dev_set_drvdata().
|
||||
When the driver has successfully bound itself to that device, then probe()
|
||||
returns zero and the driver model code will finish its part of binding
|
||||
the driver to that device.
|
||||
|
||||
int (*init) (struct device * dev);
|
||||
|
||||
init is called during the binding stage. It is called after probe has
|
||||
successfully returned and the device has been registered with its
|
||||
class. It is responsible for initializing the hardware.
|
||||
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);
|
||||
|
||||
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
|
||||
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
|
||||
not. It should free any resources allocated specifically for the
|
||||
|
|
|
@ -1,16 +1,40 @@
|
|||
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
|
||||
modify it under the terms of the GNU General Public License as
|
||||
published by the Free Software Foundation, version 2.
|
||||
The framework provides generic functions (mostly kernel API calls), such as:
|
||||
|
||||
- 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
|
||||
========================
|
||||
|
@ -55,22 +79,34 @@ Others:
|
|||
- Grandtec USB DVB-T
|
||||
http://www.grand.com.tw/
|
||||
|
||||
- Avermedia AverTV DVBT USB (2)
|
||||
- AVerMedia AverTV DVBT USB
|
||||
http://www.avermedia.com/
|
||||
|
||||
- DiBcom USB DVB-T reference device (non-public)
|
||||
|
||||
|
||||
Supported devices USB2.0
|
||||
========================
|
||||
- Twinhan MagicBox II (2)
|
||||
Supported devices USB2.0-only
|
||||
=============================
|
||||
- Twinhan MagicBox II
|
||||
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
|
||||
|
||||
- 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.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)
|
||||
|
||||
|
@ -81,14 +117,24 @@ Supported devices USB2.0
|
|||
|
||||
- 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.
|
||||
|
||||
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-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
|
||||
- first almost working version for HanfTek UMT-010
|
||||
- found out, that Yakumo/HAMA/Typhoon are predessors of the HanfTek UMT-010
|
||||
|
@ -99,7 +145,7 @@ Supported devices USB2.0
|
|||
2004-12-26 - refactored the dibusb-driver, splitted into separate files
|
||||
- i2c-probing enabled
|
||||
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
|
||||
- revised the debugging
|
||||
- possibility to deliver the complete TS for USB2.0
|
||||
|
@ -127,8 +173,8 @@ Supported devices USB2.0
|
|||
CTS Portable (Chinese Television System)
|
||||
2004-07-08 - firmware-extraction-2.422-problem solved, driver is now working
|
||||
properly with firmware extracted from 2.422
|
||||
- #if for 2.6.4 (dvb), compile issue
|
||||
- changed firmware handling, see vp7041.txt sec 1.1
|
||||
- #if for 2.6.4 (dvb), compile issue
|
||||
- changed firmware handling, see vp7041.txt sec 1.1
|
||||
2004-07-02 - some tuner modifications, v0.1, cleanups, first public
|
||||
2004-06-28 - now using the dvb_dmx_swfilter_packets, everything
|
||||
runs fine now
|
||||
|
@ -139,38 +185,27 @@ Supported devices USB2.0
|
|||
2004-05-11 - start writing the driver
|
||||
|
||||
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
|
||||
|
||||
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) you need: dvb-usb-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 (AN2135)
|
||||
http://www.linuxtv.org/downloads/firmware/dvb-dibusb-5.0.0.11.fw
|
||||
The files can be found on http://www.linuxtv.org/download/firmware/ .
|
||||
|
||||
for USB1.1 (AN2235) (a few Artec T1 devices)
|
||||
http://www.linuxtv.org/downloads/firmware/dvb-dibusb-an2235-1.fw
|
||||
We do not have the permission (yet) to publish the following firmware-files.
|
||||
You'll need to extract them from the windows drivers.
|
||||
|
||||
for USB2.0 (FX2) Hauppauge, DiBcom
|
||||
http://www.linuxtv.org/downloads/firmware/dvb-dibusb-6.0.0.5.fw
|
||||
|
||||
for USB2.0 ADSTech/Kworld USB2.0
|
||||
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
|
||||
You should be able to use "get_dvb_firmware dvb-usb" to get the firmware:
|
||||
|
||||
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
|
||||
|
||||
|
@ -178,6 +213,9 @@ Since the driver is in the linux kernel, activating the driver in
|
|||
your favorite config-environment should sufficient. I recommend
|
||||
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
|
||||
|
||||
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.
|
|||
|
||||
first have a look, which debug level are available:
|
||||
|
||||
modinfo dib3000mb
|
||||
modinfo dib3000-common
|
||||
modinfo dib3000mc
|
||||
modinfo dvb-dibusb
|
||||
modinfo dvb-usb
|
||||
modinfo dvb-usb-vp7045
|
||||
etc.
|
||||
|
||||
modprobe dib3000-common debug=<level>
|
||||
modprobe dib3000mb debug=<level>
|
||||
modprobe dib3000mc debug=<level>
|
||||
modprobe dvb-dibusb debug=<level>
|
||||
modprobe dvb-usb debug=<level>
|
||||
modprobe dvb-usb-vp7045 debug=<level>
|
||||
etc.
|
||||
|
||||
should do the trick.
|
||||
|
||||
|
@ -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
|
||||
turned on.
|
||||
|
||||
At this point you should be able to start a dvb-capable application. For myself
|
||||
I used mplayer, dvbscan, tzap and kaxtv, they are working. Using the device
|
||||
in vdr is working now also.
|
||||
At this point you should be able to start a dvb-capable application. I'm use
|
||||
(t|s)zap, mplayer and dvbscan to test the basics. VDR-xine provides the
|
||||
long-term test scenario.
|
||||
|
||||
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
|
||||
|
||||
It is not possible to determine the range of devices based on the DiBcom
|
||||
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.
|
||||
TODO
|
||||
|
||||
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.
|
||||
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),
|
||||
but watching a channel while recording another channel on the same
|
||||
frequency simply does not work very well. This applies to all USB1.1
|
||||
DVB-T devices, not just dibusb)
|
||||
|
||||
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.
|
||||
DVB-T devices, not just the dvb-usb-devices)
|
||||
|
||||
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
|
||||
and watch another one.
|
||||
|
||||
|
@ -258,7 +274,7 @@ and watch another one.
|
|||
Patches, comments and suggestions are very very welcome.
|
||||
|
||||
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
|
||||
dib3000mc are based.
|
||||
|
||||
|
@ -270,9 +286,16 @@ Patches, comments and suggestions are very very welcome.
|
|||
|
||||
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.
|
||||
|
||||
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
|
||||
|
||||
Peter Schildmann >peter.schildmann-nospam-at-web.de< for his
|
||||
|
@ -282,4 +305,4 @@ Patches, comments and suggestions are very very welcome.
|
|||
Ulf Hermenau for helping me out with traditional chinese.
|
||||
|
||||
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.
|
205
Documentation/dvb/README.flexcop
Normal file
205
Documentation/dvb/README.flexcop
Normal file
|
@ -0,0 +1,205 @@
|
|||
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.
|
|
@ -17,74 +17,50 @@ Because of this, you need to enable
|
|||
"Device drivers" => "Multimedia devices"
|
||||
=> "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
|
||||
==================
|
||||
|
||||
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
|
||||
and one frontend 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).
|
||||
i2c communication for us, plus the common dvb-bt8xx device driver.
|
||||
The frontends for Nebula (nxt6000), Pinnacle PCTV (cx24110) and
|
||||
TwinHan (dst) are loaded automatically by the dvb-bt8xx device driver.
|
||||
|
||||
3a) Nebula / Pinnacle PCTV
|
||||
--------------------------
|
||||
|
||||
$ modprobe bttv i2c_hw=1 card=0x68
|
||||
$ modprobe dvb-bt8xx
|
||||
|
||||
For Nebula cards use the "nxt6000" frontend driver:
|
||||
$ modprobe nxt6000
|
||||
$ modprobe bttv (normally bttv is being loaded automatically by kmod)
|
||||
$ modprobe dvb-bt8xx (or just place dvb-bt8xx in /etc/modules for automatic loading)
|
||||
|
||||
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 dvb-bt8xx
|
||||
$ modprobe dst
|
||||
|
||||
The value 0x71 will override the PCI type detection for dvb-bt8xx, which
|
||||
is necessary for TwinHan cards.#
|
||||
The value 0x71 will override the PCI type detection for dvb-bt8xx,
|
||||
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.
|
||||
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
|
||||
mailing list.
|
||||
|
||||
The DST module takes a couple of useful parameters, in case the
|
||||
dst drivers fails to detect your type of card correctly.
|
||||
The DST module takes a couple of useful parameters:
|
||||
|
||||
dst_type takes values 0 (satellite), 1 (terrestial TV), 2 (cable).
|
||||
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_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
|
||||
(e.g. 0). The autodected values are determined bythe cards 'response
|
||||
string' which you can see in your logs e.g.
|
||||
|
||||
dst_check_ci: recognize DST-MOT
|
||||
|
||||
or
|
||||
|
||||
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
|
||||
|
|
219
Documentation/dvb/ci.txt
Normal file
219
Documentation/dvb/ci.txt
Normal file
|
@ -0,0 +1,219 @@
|
|||
* 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.
|
|
@ -107,7 +107,7 @@ sub tda10045 {
|
|||
sub tda10046 {
|
||||
my $sourcefile = "tt_budget_217g.zip";
|
||||
my $url = "http://www.technotrend.de/new/217g/$sourcefile";
|
||||
my $hash = "a25b579e37109af60f4a36c37893957c";
|
||||
my $hash = "6a7e1e2f2644b162ff0502367553c72d";
|
||||
my $outfile = "dvb-fe-tda10046.fw";
|
||||
my $tmpdir = tempdir(DIR => "/tmp", CLEANUP => 1);
|
||||
|
||||
|
@ -115,7 +115,7 @@ sub tda10046 {
|
|||
|
||||
wgetfile($sourcefile, $url);
|
||||
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);
|
||||
copy("$tmpdir/fwtmp", $outfile);
|
||||
|
||||
|
|
135
Documentation/fb/intelfb.txt
Normal file
135
Documentation/fb/intelfb.txt
Normal file
|
@ -0,0 +1,135 @@
|
|||
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
|
|
@ -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()
|
||||
When: April 2005
|
||||
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
|
|||
people, who might be using implementations that I am not aware
|
||||
of, to adjust to this upcoming change.
|
||||
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>
|
||||
|
||||
|
|
|
@ -58,6 +58,8 @@ noacl Don't support POSIX ACLs.
|
|||
|
||||
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.
|
||||
|
||||
|
||||
|
|
|
@ -26,7 +26,11 @@ Mount options unique to the isofs filesystem.
|
|||
mode=xxx Sets the permissions on files to xxx
|
||||
nojoliet Ignore Joliet 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
|
||||
sbsector=xxx Session begins from sector xxx
|
||||
|
||||
|
|
|
@ -7,7 +7,6 @@ that support it. For example, a given bus might look like this:
|
|||
|-- 0000:17:00.0
|
||||
| |-- class
|
||||
| |-- config
|
||||
| |-- detach_state
|
||||
| |-- device
|
||||
| |-- irq
|
||||
| |-- local_cpus
|
||||
|
@ -19,7 +18,7 @@ that support it. For example, a given bus might look like this:
|
|||
| |-- subsystem_device
|
||||
| |-- subsystem_vendor
|
||||
| `-- vendor
|
||||
`-- detach_state
|
||||
`-- ...
|
||||
|
||||
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).
|
||||
|
@ -31,7 +30,6 @@ files, each with their own function.
|
|||
---- --------
|
||||
class PCI class (ascii, ro)
|
||||
config PCI config space (binary, rw)
|
||||
detach_state connection status (bool, rw)
|
||||
device PCI device (ascii, ro)
|
||||
irq IRQ number (ascii, ro)
|
||||
local_cpus nearby CPU mask (cpumask, ro)
|
||||
|
@ -85,4 +83,4 @@ useful return codes should be provided.
|
|||
|
||||
Legacy resources are protected by the HAVE_PCI_LEGACY define. Platforms
|
||||
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.
|
||||
|
|
|
@ -214,7 +214,7 @@ Other notes:
|
|||
|
||||
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);
|
||||
}
|
||||
|
|
|
@ -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:
|
||||
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
|
||||
nor inodes will be limited in that instance. It is generally unwise to
|
||||
If nr_blocks=0 (or size=0), blocks will not be limited in that instance;
|
||||
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
|
||||
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.
|
||||
|
@ -97,4 +97,4 @@ RAM/SWAP in 10240 inodes and it is only accessible by root.
|
|||
Author:
|
||||
Christoph Rohland <cr@sap.com>, 1.12.01
|
||||
Updated:
|
||||
Hugh Dickins <hugh@veritas.com>, 01 September 2004
|
||||
Hugh Dickins <hugh@veritas.com>, 13 March 2005
|
||||
|
|
67
Documentation/filesystems/xip.txt
Normal file
67
Documentation/filesystems/xip.txt
Normal file
|
@ -0,0 +1,67 @@
|
|||
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.
|
|
@ -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
|
||||
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
|
||||
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.
|
||||
|
||||
|
||||
|
|
111
Documentation/i2c/chips/adm1021
Normal file
111
Documentation/i2c/chips/adm1021
Normal file
|
@ -0,0 +1,111 @@
|
|||
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.
|
51
Documentation/i2c/chips/adm1025
Normal file
51
Documentation/i2c/chips/adm1025
Normal file
|
@ -0,0 +1,51 @@
|
|||
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.
|
93
Documentation/i2c/chips/adm1026
Normal file
93
Documentation/i2c/chips/adm1026
Normal file
|
@ -0,0 +1,93 @@
|
|||
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.
|
35
Documentation/i2c/chips/adm1031
Normal file
35
Documentation/i2c/chips/adm1031
Normal file
|
@ -0,0 +1,35 @@
|
|||
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.
|
177
Documentation/i2c/chips/adm9240
Normal file
177
Documentation/i2c/chips/adm9240
Normal file
|
@ -0,0 +1,177 @@
|
|||
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.
|
72
Documentation/i2c/chips/asb100
Normal file
72
Documentation/i2c/chips/asb100
Normal file
|
@ -0,0 +1,72 @@
|
|||
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...
|
||||
|
108
Documentation/i2c/chips/ds1621
Normal file
108
Documentation/i2c/chips/ds1621
Normal file
|
@ -0,0 +1,108 @@
|
|||
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.
|
96
Documentation/i2c/chips/eeprom
Normal file
96
Documentation/i2c/chips/eeprom
Normal file
|
@ -0,0 +1,96 @@
|
|||
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.
|
169
Documentation/i2c/chips/fscher
Normal file
169
Documentation/i2c/chips/fscher
Normal file
|
@ -0,0 +1,169 @@
|
|||
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.
|
74
Documentation/i2c/chips/gl518sm
Normal file
74
Documentation/i2c/chips/gl518sm
Normal file
|
@ -0,0 +1,74 @@
|
|||
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.
|
96
Documentation/i2c/chips/it87
Normal file
96
Documentation/i2c/chips/it87
Normal file
|
@ -0,0 +1,96 @@
|
|||
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.
|
57
Documentation/i2c/chips/lm63
Normal file
57
Documentation/i2c/chips/lm63
Normal file
|
@ -0,0 +1,57 @@
|
|||
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.
|
||||
|
65
Documentation/i2c/chips/lm75
Normal file
65
Documentation/i2c/chips/lm75
Normal file
|
@ -0,0 +1,65 @@
|
|||
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.
|
22
Documentation/i2c/chips/lm77
Normal file
22
Documentation/i2c/chips/lm77
Normal file
|
@ -0,0 +1,22 @@
|
|||
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.
|
82
Documentation/i2c/chips/lm78
Normal file
82
Documentation/i2c/chips/lm78
Normal file
|
@ -0,0 +1,82 @@
|
|||
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.
|
56
Documentation/i2c/chips/lm80
Normal file
56
Documentation/i2c/chips/lm80
Normal file
|
@ -0,0 +1,56 @@
|
|||
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.
|
76
Documentation/i2c/chips/lm83
Normal file
76
Documentation/i2c/chips/lm83
Normal file
|
@ -0,0 +1,76 @@
|
|||
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.
|
221
Documentation/i2c/chips/lm85
Normal file
221
Documentation/i2c/chips/lm85
Normal file
|
@ -0,0 +1,221 @@
|
|||
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.
|
73
Documentation/i2c/chips/lm87
Normal file
73
Documentation/i2c/chips/lm87
Normal file
|
@ -0,0 +1,73 @@
|
|||
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)
|
121
Documentation/i2c/chips/lm90
Normal file
121
Documentation/i2c/chips/lm90
Normal file
|
@ -0,0 +1,121 @@
|
|||
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.
|
||||
|
37
Documentation/i2c/chips/lm92
Normal file
37
Documentation/i2c/chips/lm92
Normal file
|
@ -0,0 +1,37 @@
|
|||
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.
|
29
Documentation/i2c/chips/max1619
Normal file
29
Documentation/i2c/chips/max1619
Normal file
|
@ -0,0 +1,29 @@
|
|||
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.
|
||||
|
54
Documentation/i2c/chips/max6875
Normal file
54
Documentation/i2c/chips/max6875
Normal file
|
@ -0,0 +1,54 @@
|
|||
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.
|
||||
|
189
Documentation/i2c/chips/pc87360
Normal file
189
Documentation/i2c/chips/pc87360
Normal file
|
@ -0,0 +1,189 @@
|
|||
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.
|
47
Documentation/i2c/chips/pca9539
Normal file
47
Documentation/i2c/chips/pca9539
Normal file
|
@ -0,0 +1,47 @@
|
|||
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
|
||||
|
69
Documentation/i2c/chips/pcf8574
Normal file
69
Documentation/i2c/chips/pcf8574
Normal file
|
@ -0,0 +1,69 @@
|
|||
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.
|
90
Documentation/i2c/chips/pcf8591
Normal file
90
Documentation/i2c/chips/pcf8591
Normal file
|
@ -0,0 +1,90 @@
|
|||
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.
|
106
Documentation/i2c/chips/sis5595
Normal file
106
Documentation/i2c/chips/sis5595
Normal file
|
@ -0,0 +1,106 @@
|
|||
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.
|
||||
|
|
@ -1,7 +1,19 @@
|
|||
Kernel driver smsc47b397
|
||||
========================
|
||||
|
||||
Supported chips:
|
||||
* SMSC LPC47B397-NC
|
||||
Prefix: 'smsc47b397'
|
||||
Addresses scanned: none, address read from Super I/O config space
|
||||
Datasheet: In this file
|
||||
|
||||
Authors: Mark M. Hoffman <mhoffman@lightlink.com>
|
||||
Utilitek Systems, Inc.
|
||||
|
||||
November 23, 2004
|
||||
|
||||
The following specification describes the SMSC LPC47B397-NC sensor chip
|
||||
(for which there is no public datasheet available). This document was
|
||||
(for which there is no public datasheet available). This document was
|
||||
provided by Craig Kelly (In-Store Broadcast Network) and edited/corrected
|
||||
by Mark M. Hoffman <mhoffman@lightlink.com>.
|
||||
|
||||
|
@ -10,10 +22,10 @@ by Mark M. Hoffman <mhoffman@lightlink.com>.
|
|||
Methods for detecting the HP SIO and reading the thermal data on a dc7100.
|
||||
|
||||
The thermal information on the dc7100 is contained in the SIO Hardware Monitor
|
||||
(HWM). The information is accessed through an index/data pair. The index/data
|
||||
pair is located at the HWM Base Address + 0 and the HWM Base Address + 1. The
|
||||
(HWM). The information is accessed through an index/data pair. The index/data
|
||||
pair is located at the HWM Base Address + 0 and the HWM Base Address + 1. The
|
||||
HWM Base address can be obtained from Logical Device 8, registers 0x60 (MSB)
|
||||
and 0x61 (LSB). Currently we are using 0x480 for the HWM Base Address and
|
||||
and 0x61 (LSB). Currently we are using 0x480 for the HWM Base Address and
|
||||
0x480 and 0x481 for the index/data pair.
|
||||
|
||||
Reading temperature information.
|
||||
|
@ -50,7 +62,7 @@ Reading the tach LSB locks the tach MSB.
|
|||
The LSB Must be read first.
|
||||
|
||||
How to convert the tach reading to RPM.
|
||||
The tach reading (TCount) is given by: (Tach MSB * 256) + (Tach LSB)
|
||||
The tach reading (TCount) is given by: (Tach MSB * 256) + (Tach LSB)
|
||||
The SIO counts the number of 90kHz (11.111us) pulses per revolution.
|
||||
RPM = 60/(TCount * 11.111us)
|
||||
|
||||
|
@ -72,20 +84,20 @@ To program the configuration registers, the following sequence must be followed:
|
|||
|
||||
Enter Configuration Mode
|
||||
To place the chip into the Configuration State The config key (0x55) is written
|
||||
to the CONFIG PORT (0x2E).
|
||||
to the CONFIG PORT (0x2E).
|
||||
|
||||
Configuration Mode
|
||||
In configuration mode, the INDEX PORT is located at the CONFIG PORT address and
|
||||
the DATA PORT is at INDEX PORT address + 1.
|
||||
|
||||
The desired configuration registers are accessed in two steps:
|
||||
The desired configuration registers are accessed in two steps:
|
||||
a. Write the index of the Logical Device Number Configuration Register
|
||||
(i.e., 0x07) to the INDEX PORT and then write the number of the
|
||||
desired logical device to the DATA PORT.
|
||||
|
||||
b. Write the address of the desired configuration register within the
|
||||
logical device to the INDEX PORT and then write or read the config-
|
||||
uration register through the DATA PORT.
|
||||
uration register through the DATA PORT.
|
||||
|
||||
Note: If accessing the Global Configuration Registers, step (a) is not required.
|
||||
|
||||
|
@ -96,18 +108,18 @@ The chip returns to the RUN State. (This is important).
|
|||
Programming Example
|
||||
The following is an example of how to read the SIO Device ID located at 0x20
|
||||
|
||||
; ENTER CONFIGURATION MODE
|
||||
; ENTER CONFIGURATION MODE
|
||||
MOV DX,02EH
|
||||
MOV AX,055H
|
||||
OUT DX,AL
|
||||
; GLOBAL CONFIGURATION REGISTER
|
||||
; GLOBAL CONFIGURATION REGISTER
|
||||
MOV DX,02EH
|
||||
MOV AL,20H
|
||||
OUT DX,AL
|
||||
OUT DX,AL
|
||||
; READ THE DATA
|
||||
MOV DX,02FH
|
||||
IN AL,DX
|
||||
; EXIT CONFIGURATION MODE
|
||||
; EXIT CONFIGURATION MODE
|
||||
MOV DX,02EH
|
||||
MOV AX,0AAH
|
||||
OUT DX,AL
|
||||
|
@ -122,12 +134,12 @@ Obtaining the HWM Base Address.
|
|||
The following is an example of how to read the HWM Base Address located in
|
||||
Logical Device 8.
|
||||
|
||||
; ENTER CONFIGURATION MODE
|
||||
; ENTER CONFIGURATION MODE
|
||||
MOV DX,02EH
|
||||
MOV AX,055H
|
||||
OUT DX,AL
|
||||
; CONFIGURE REGISTER CRE0,
|
||||
; LOGICAL DEVICE 8
|
||||
; CONFIGURE REGISTER CRE0,
|
||||
; LOGICAL DEVICE 8
|
||||
MOV DX,02EH
|
||||
MOV AL,07H
|
||||
OUT DX,AL ;Point to LD# Config Reg
|
||||
|
@ -135,12 +147,12 @@ MOV DX,02FH
|
|||
MOV AL, 08H
|
||||
OUT DX,AL;Point to Logical Device 8
|
||||
;
|
||||
MOV DX,02EH
|
||||
MOV DX,02EH
|
||||
MOV AL,60H
|
||||
OUT DX,AL ; Point to HWM Base Addr MSB
|
||||
MOV DX,02FH
|
||||
IN AL,DX ; Get MSB of HWM Base Addr
|
||||
; EXIT CONFIGURATION MODE
|
||||
; EXIT CONFIGURATION MODE
|
||||
MOV DX,02EH
|
||||
MOV AX,0AAH
|
||||
OUT DX,AL
|
52
Documentation/i2c/chips/smsc47m1
Normal file
52
Documentation/i2c/chips/smsc47m1
Normal file
|
@ -0,0 +1,52 @@
|
|||
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.
|
65
Documentation/i2c/chips/via686a
Normal file
65
Documentation/i2c/chips/via686a
Normal file
|
@ -0,0 +1,65 @@
|
|||
Kernel driver via686a
|
||||
=====================
|
||||
|
||||
Supported chips:
|
||||
* Via VT82C686A, VT82C686B Southbridge Integrated Hardware Monitor
|
||||
Prefix: 'via686a'
|
||||
Addresses scanned: ISA in PCI-space encoded address
|
||||
Datasheet: On request through web form (http://www.via.com.tw/en/support/datasheets/)
|
||||
|
||||
Authors:
|
||||
Kyösti Mälkki <kmalkki@cc.hut.fi>,
|
||||
Mark D. Studebaker <mdsxyz123@yahoo.com>
|
||||
Bob Dougherty <bobd@stanford.edu>
|
||||
(Some conversion-factor data were contributed by
|
||||
Jonathan Teh Soon Yew <j.teh@iname.com>
|
||||
and Alex van Kaam <darkside@chello.nl>.)
|
||||
|
||||
Module Parameters
|
||||
-----------------
|
||||
|
||||
force_addr=0xaddr Set the I/O base address. Useful for Asus A7V boards
|
||||
that don't set the address in the BIOS. Does not do a
|
||||
PCI force; the via686a must still be present in lspci.
|
||||
Don't use this unless the driver complains that the
|
||||
base address is not set.
|
||||
Example: 'modprobe via686a force_addr=0x6000'
|
||||
|
||||
Description
|
||||
-----------
|
||||
|
||||
The driver does not distinguish between the chips and reports
|
||||
all as a 686A.
|
||||
|
||||
The Via 686a southbridge has integrated hardware monitor functionality.
|
||||
It also has an I2C bus, but this driver only supports the hardware monitor.
|
||||
For the I2C bus driver, see <file:Documentation/i2c/busses/i2c-viapro>
|
||||
|
||||
The Via 686a implements three temperature sensors, two fan rotation speed
|
||||
sensors, five voltage sensors and alarms.
|
||||
|
||||
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.
|
||||
|
||||
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. Voltages are internally scalled, so each voltage channel
|
||||
has a different resolution and range.
|
||||
|
||||
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 driver only updates its values each 1.5 seconds; reading it more often
|
||||
will do no harm, but will return 'old' values.
|
66
Documentation/i2c/chips/w83627hf
Normal file
66
Documentation/i2c/chips/w83627hf
Normal file
|
@ -0,0 +1,66 @@
|
|||
Kernel driver w83627hf
|
||||
======================
|
||||
|
||||
Supported chips:
|
||||
* Winbond W83627HF (ISA accesses ONLY)
|
||||
Prefix: 'w83627hf'
|
||||
Addresses scanned: ISA address retrieved from Super I/O registers
|
||||
Datasheet: http://www.winbond.com/PDF/sheet/w83627hf.pdf
|
||||
* Winbond W83627THF
|
||||
Prefix: 'w83627thf'
|
||||
Addresses scanned: ISA address retrieved from Super I/O registers
|
||||
Datasheet: http://www.winbond.com/PDF/sheet/w83627thf.pdf
|
||||
* Winbond W83697HF
|
||||
Prefix: 'w83697hf'
|
||||
Addresses scanned: ISA address retrieved from Super I/O registers
|
||||
Datasheet: http://www.winbond.com/PDF/sheet/697hf.pdf
|
||||
* Winbond W83637HF
|
||||
Prefix: 'w83637hf'
|
||||
Addresses scanned: ISA address retrieved from Super I/O registers
|
||||
Datasheet: http://www.winbond.com/PDF/sheet/w83637hf.pdf
|
||||
|
||||
Authors:
|
||||
Frodo Looijaard <frodol@dds.nl>,
|
||||
Philip Edelbrock <phil@netroedge.com>,
|
||||
Mark Studebaker <mdsxyz123@yahoo.com>,
|
||||
Bernhard C. Schrenk <clemy@clemy.org>
|
||||
|
||||
Module Parameters
|
||||
-----------------
|
||||
|
||||
* force_addr: int
|
||||
Initialize the ISA address of the sensors
|
||||
* force_i2c: int
|
||||
Initialize the I2C address of the sensors
|
||||
* init: int
|
||||
(default is 1)
|
||||
Use 'init=0' to bypass initializing the chip.
|
||||
Try this if your computer crashes when you load the module.
|
||||
|
||||
Description
|
||||
-----------
|
||||
|
||||
This driver implements support for ISA accesses *only* for
|
||||
the Winbond W83627HF, W83627THF, W83697HF and W83637HF Super I/O chips.
|
||||
We will refer to them collectively as Winbond chips.
|
||||
|
||||
This driver supports ISA accesses, which should be more reliable
|
||||
than i2c accesses. Also, for Tyan boards which contain both a
|
||||
Super I/O chip and a second i2c-only Winbond chip (often a W83782D),
|
||||
using this driver will avoid i2c address conflicts and complex
|
||||
initialization that were required in the w83781d driver.
|
||||
|
||||
If you really want i2c accesses for these Super I/O chips,
|
||||
use the w83781d driver. However this is not the preferred method
|
||||
now that this ISA driver has been developed.
|
||||
|
||||
Technically, the w83627thf does not support a VID reading. However, it's
|
||||
possible or even likely that your mainboard maker has routed these signals
|
||||
to a specific set of general purpose IO pins (the Asus P4C800-E is one such
|
||||
board). The w83627thf driver now interprets these as VID. If the VID on
|
||||
your board doesn't work, first see doc/vid in the lm_sensors package. If
|
||||
that still doesn't help, email us at lm-sensors@lm-sensors.org.
|
||||
|
||||
For further information on this driver see the w83781d driver
|
||||
documentation.
|
||||
|
402
Documentation/i2c/chips/w83781d
Normal file
402
Documentation/i2c/chips/w83781d
Normal file
|
@ -0,0 +1,402 @@
|
|||
Kernel driver w83781d
|
||||
=====================
|
||||
|
||||
Supported chips:
|
||||
* Winbond W83781D
|
||||
Prefix: 'w83781d'
|
||||
Addresses scanned: I2C 0x20 - 0x2f, ISA 0x290 (8 I/O ports)
|
||||
Datasheet: http://www.winbond-usa.com/products/winbond_products/pdfs/PCIC/w83781d.pdf
|
||||
* Winbond W83782D
|
||||
Prefix: 'w83782d'
|
||||
Addresses scanned: I2C 0x20 - 0x2f, ISA 0x290 (8 I/O ports)
|
||||
Datasheet: http://www.winbond.com/PDF/sheet/w83782d.pdf
|
||||
* Winbond W83783S
|
||||
Prefix: 'w83783s'
|
||||
Addresses scanned: I2C 0x2d
|
||||
Datasheet: http://www.winbond-usa.com/products/winbond_products/pdfs/PCIC/w83783s.pdf
|
||||
* Winbond W83627HF
|
||||
Prefix: 'w83627hf'
|
||||
Addresses scanned: I2C 0x20 - 0x2f, ISA 0x290 (8 I/O ports)
|
||||
Datasheet: http://www.winbond.com/PDF/sheet/w83627hf.pdf
|
||||
* Asus AS99127F
|
||||
Prefix: 'as99127f'
|
||||
Addresses scanned: I2C 0x28 - 0x2f
|
||||
Datasheet: Unavailable from Asus
|
||||
|
||||
Authors:
|
||||
Frodo Looijaard <frodol@dds.nl>,
|
||||
Philip Edelbrock <phil@netroedge.com>,
|
||||
Mark Studebaker <mdsxyz123@yahoo.com>
|
||||
|
||||
Module parameters
|
||||
-----------------
|
||||
|
||||
* init int
|
||||
(default 1)
|
||||
Use 'init=0' to bypass initializing the chip.
|
||||
Try this if your computer crashes when you load the module.
|
||||
|
||||
force_subclients=bus,caddr,saddr,saddr
|
||||
This is used to force the i2c addresses for subclients of
|
||||
a certain chip. Typical usage is `force_subclients=0,0x2d,0x4a,0x4b'
|
||||
to force the subclients of chip 0x2d on bus 0 to i2c addresses
|
||||
0x4a and 0x4b. This parameter is useful for certain Tyan boards.
|
||||
|
||||
Description
|
||||
-----------
|
||||
|
||||
This driver implements support for the Winbond W83781D, W83782D, W83783S,
|
||||
W83627HF chips, and the Asus AS99127F chips. We will refer to them
|
||||
collectively as W8378* chips.
|
||||
|
||||
There is quite some difference between these chips, but they are similar
|
||||
enough that it was sensible to put them together in one driver.
|
||||
The W83627HF chip is assumed to be identical to the ISA W83782D.
|
||||
The Asus chips are similar to an I2C-only W83782D.
|
||||
|
||||
Chip #vin #fanin #pwm #temp wchipid vendid i2c ISA
|
||||
as99127f 7 3 0 3 0x31 0x12c3 yes no
|
||||
as99127f rev.2 (type_name = as99127f) 0x31 0x5ca3 yes no
|
||||
w83781d 7 3 0 3 0x10-1 0x5ca3 yes yes
|
||||
w83627hf 9 3 2 3 0x21 0x5ca3 yes yes(LPC)
|
||||
w83782d 9 3 2-4 3 0x30 0x5ca3 yes yes
|
||||
w83783s 5-6 3 2 1-2 0x40 0x5ca3 yes no
|
||||
|
||||
Detection of these chips can sometimes be foiled because they can be in
|
||||
an internal state that allows no clean access. If you know the address
|
||||
of the chip, use a 'force' parameter; this will put them into a more
|
||||
well-behaved state first.
|
||||
|
||||
The W8378* implements temperature sensors (three on the W83781D and W83782D,
|
||||
two on the W83783S), three fan rotation speed sensors, voltage sensors
|
||||
(seven on the W83781D, nine on the W83782D and six on the W83783S), VID
|
||||
lines, alarms with beep warnings, and some miscellaneous stuff.
|
||||
|
||||
Temperatures are measured in degrees Celsius. There is always one main
|
||||
temperature sensor, and one (W83783S) or two (W83781D and W83782D) other
|
||||
sensors. An alarm is triggered for the main sensor 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. The driver sets the
|
||||
hysteresis value for temp1 to 127 at initialization.
|
||||
|
||||
For the other temperature sensor(s), an alarm is triggered when the
|
||||
temperature gets higher then the Overtemperature Shutdown value; it stays
|
||||
on until the temperature falls below the Hysteresis value. But on the
|
||||
W83781D, there is only one alarm that functions for both other sensors!
|
||||
Temperatures are guaranteed within a range of -55 to +125 degrees. The
|
||||
main temperature sensors has a resolution of 1 degree; the other sensor(s)
|
||||
of 0.5 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 for the
|
||||
W83781D; 1, 2, 4, 8, 16, 32, 64 or 128 for the others) 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.
|
||||
|
||||
The W83782D and W83783S temperature conversion machine understands about
|
||||
several kinds of temperature probes. You can program the so-called
|
||||
beta value in the sensor files. '1' is the PII/Celeron diode, '2' is the
|
||||
TN3904 transistor, and 3435 the default thermistor value. Other values
|
||||
are (not yet) supported.
|
||||
|
||||
In addition to the alarms described above, there is a CHAS alarm on the
|
||||
chips which triggers if your computer case is open.
|
||||
|
||||
When an alarm goes off, 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. 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 chips only update values each 1.5 seconds; reading them more often
|
||||
will do no harm, but will return 'old' values.
|
||||
|
||||
AS99127F PROBLEMS
|
||||
-----------------
|
||||
The as99127f support was developed without the benefit of a datasheet.
|
||||
In most cases it is treated as a w83781d (although revision 2 of the
|
||||
AS99127F looks more like a w83782d).
|
||||
This support will be BETA until a datasheet is released.
|
||||
One user has reported problems with fans stopping
|
||||
occasionally.
|
||||
|
||||
Note that the individual beep bits are inverted from the other chips.
|
||||
The driver now takes care of this so that user-space applications
|
||||
don't have to know about it.
|
||||
|
||||
Known problems:
|
||||
- Problems with diode/thermistor settings (supported?)
|
||||
- One user reports fans stopping under high server load.
|
||||
- Revision 2 seems to have 2 PWM registers but we don't know
|
||||
how to handle them. More details below.
|
||||
|
||||
These will not be fixed unless we get a datasheet.
|
||||
If you have problems, please lobby Asus to release a datasheet.
|
||||
Unfortunately several others have without success.
|
||||
Please do not send mail to us asking for better as99127f support.
|
||||
We have done the best we can without a datasheet.
|
||||
Please do not send mail to the author or the sensors group asking for
|
||||
a datasheet or ideas on how to convince Asus. We can't help.
|
||||
|
||||
|
||||
NOTES:
|
||||
-----
|
||||
783s has no in1 so that in[2-6] are compatible with the 781d/782d.
|
||||
|
||||
783s pin is programmable for -5V or temp1; defaults to -5V,
|
||||
no control in driver so temp1 doesn't work.
|
||||
|
||||
782d and 783s datasheets differ on which is pwm1 and which is pwm2.
|
||||
We chose to follow 782d.
|
||||
|
||||
782d and 783s pin is programmable for fan3 input or pwm2 output;
|
||||
defaults to fan3 input.
|
||||
If pwm2 is enabled (with echo 255 1 > pwm2), then
|
||||
fan3 will report 0.
|
||||
|
||||
782d has pwm1-2 for ISA, pwm1-4 for i2c. (pwm3-4 share pins with
|
||||
the ISA pins)
|
||||
|
||||
Data sheet updates:
|
||||
------------------
|
||||
- PWM clock registers:
|
||||
|
||||
000: master / 512
|
||||
001: master / 1024
|
||||
010: master / 2048
|
||||
011: master / 4096
|
||||
100: master / 8192
|
||||
|
||||
|
||||
Answers from Winbond tech support
|
||||
---------------------------------
|
||||
>
|
||||
> 1) In the W83781D data sheet section 7.2 last paragraph, it talks about
|
||||
> reprogramming the R-T table if the Beta of the thermistor is not
|
||||
> 3435K. The R-T table is described briefly in section 8.20.
|
||||
> What formulas do I use to program a new R-T table for a given Beta?
|
||||
>
|
||||
We are sorry that the calculation for R-T table value is
|
||||
confidential. If you have another Beta value of thermistor, we can help
|
||||
to calculate the R-T table for you. But you should give us real R-T
|
||||
Table which can be gotten by thermistor vendor. Therefore we will calculate
|
||||
them and obtain 32-byte data, and you can fill the 32-byte data to the
|
||||
register in Bank0.CR51 of W83781D.
|
||||
|
||||
|
||||
> 2) In the W83782D data sheet, it mentions that pins 38, 39, and 40 are
|
||||
> programmable to be either thermistor or Pentium II diode inputs.
|
||||
> How do I program them for diode inputs? I can't find any register
|
||||
> to program these to be diode inputs.
|
||||
--> You may program Bank0 CR[5Dh] and CR[59h] registers.
|
||||
|
||||
CR[5Dh] bit 1(VTIN1) bit 2(VTIN2) bit 3(VTIN3)
|
||||
|
||||
thermistor 0 0 0
|
||||
diode 1 1 1
|
||||
|
||||
|
||||
(error) CR[59h] bit 4(VTIN1) bit 2(VTIN2) bit 3(VTIN3)
|
||||
(right) CR[59h] bit 4(VTIN1) bit 5(VTIN2) bit 6(VTIN3)
|
||||
|
||||
PII thermal diode 1 1 1
|
||||
2N3904 diode 0 0 0
|
||||
|
||||
|
||||
Asus Clones
|
||||
-----------
|
||||
|
||||
We have no datasheets for the Asus clones (AS99127F and ASB100 Bach).
|
||||
Here are some very useful information that were given to us by Alex Van
|
||||
Kaam about how to detect these chips, and how to read their values. He
|
||||
also gives advice for another Asus chipset, the Mozart-2 (which we
|
||||
don't support yet). Thanks Alex!
|
||||
I reworded some parts and added personal comments.
|
||||
|
||||
# Detection:
|
||||
|
||||
AS99127F rev.1, AS99127F rev.2 and ASB100:
|
||||
- I2C address range: 0x29 - 0x2F
|
||||
- If register 0x58 holds 0x31 then we have an Asus (either ASB100 or
|
||||
AS99127F)
|
||||
- Which one depends on register 0x4F (manufacturer ID):
|
||||
0x06 or 0x94: ASB100
|
||||
0x12 or 0xC3: AS99127F rev.1
|
||||
0x5C or 0xA3: AS99127F rev.2
|
||||
Note that 0x5CA3 is Winbond's ID (WEC), which let us think Asus get their
|
||||
AS99127F rev.2 direct from Winbond. The other codes mean ATT and DVC,
|
||||
respectively. ATT could stand for Asustek something (although it would be
|
||||
very badly chosen IMHO), I don't know what DVC could stand for. Maybe
|
||||
these codes simply aren't meant to be decoded that way.
|
||||
|
||||
Mozart-2:
|
||||
- I2C address: 0x77
|
||||
- If register 0x58 holds 0x56 or 0x10 then we have a Mozart-2
|
||||
- Of the Mozart there are 3 types:
|
||||
0x58=0x56, 0x4E=0x94, 0x4F=0x36: Asus ASM58 Mozart-2
|
||||
0x58=0x56, 0x4E=0x94, 0x4F=0x06: Asus AS2K129R Mozart-2
|
||||
0x58=0x10, 0x4E=0x5C, 0x4F=0xA3: Asus ??? Mozart-2
|
||||
You can handle all 3 the exact same way :)
|
||||
|
||||
# Temperature sensors:
|
||||
|
||||
ASB100:
|
||||
- sensor 1: register 0x27
|
||||
- sensor 2 & 3 are the 2 LM75's on the SMBus
|
||||
- sensor 4: register 0x17
|
||||
Remark: I noticed that on Intel boards sensor 2 is used for the CPU
|
||||
and 4 is ignored/stuck, on AMD boards sensor 4 is the CPU and sensor 2 is
|
||||
either ignored or a socket temperature.
|
||||
|
||||
AS99127F (rev.1 and 2 alike):
|
||||
- sensor 1: register 0x27
|
||||
- sensor 2 & 3 are the 2 LM75's on the SMBus
|
||||
Remark: Register 0x5b is suspected to be temperature type selector. Bit 1
|
||||
would control temp1, bit 3 temp2 and bit 5 temp3.
|
||||
|
||||
Mozart-2:
|
||||
- sensor 1: register 0x27
|
||||
- sensor 2: register 0x13
|
||||
|
||||
# Fan sensors:
|
||||
|
||||
ASB100, AS99127F (rev.1 and 2 alike):
|
||||
- 3 fans, identical to the W83781D
|
||||
|
||||
Mozart-2:
|
||||
- 2 fans only, 1350000/RPM/div
|
||||
- fan 1: register 0x28, divisor on register 0xA1 (bits 4-5)
|
||||
- fan 2: register 0x29, divisor on register 0xA1 (bits 6-7)
|
||||
|
||||
# Voltages:
|
||||
|
||||
This is where there is a difference between AS99127F rev.1 and 2.
|
||||
Remark: The difference is similar to the difference between
|
||||
W83781D and W83782D.
|
||||
|
||||
ASB100:
|
||||
in0=r(0x20)*0.016
|
||||
in1=r(0x21)*0.016
|
||||
in2=r(0x22)*0.016
|
||||
in3=r(0x23)*0.016*1.68
|
||||
in4=r(0x24)*0.016*3.8
|
||||
in5=r(0x25)*(-0.016)*3.97
|
||||
in6=r(0x26)*(-0.016)*1.666
|
||||
|
||||
AS99127F rev.1:
|
||||
in0=r(0x20)*0.016
|
||||
in1=r(0x21)*0.016
|
||||
in2=r(0x22)*0.016
|
||||
in3=r(0x23)*0.016*1.68
|
||||
in4=r(0x24)*0.016*3.8
|
||||
in5=r(0x25)*(-0.016)*3.97
|
||||
in6=r(0x26)*(-0.016)*1.503
|
||||
|
||||
AS99127F rev.2:
|
||||
in0=r(0x20)*0.016
|
||||
in1=r(0x21)*0.016
|
||||
in2=r(0x22)*0.016
|
||||
in3=r(0x23)*0.016*1.68
|
||||
in4=r(0x24)*0.016*3.8
|
||||
in5=(r(0x25)*0.016-3.6)*5.14+3.6
|
||||
in6=(r(0x26)*0.016-3.6)*3.14+3.6
|
||||
|
||||
Mozart-2:
|
||||
in0=r(0x20)*0.016
|
||||
in1=255
|
||||
in2=r(0x22)*0.016
|
||||
in3=r(0x23)*0.016*1.68
|
||||
in4=r(0x24)*0.016*4
|
||||
in5=255
|
||||
in6=255
|
||||
|
||||
|
||||
# PWM
|
||||
|
||||
Additional info about PWM on the AS99127F (may apply to other Asus
|
||||
chips as well) by Jean Delvare as of 2004-04-09:
|
||||
|
||||
AS99127F revision 2 seems to have two PWM registers at 0x59 and 0x5A,
|
||||
and a temperature sensor type selector at 0x5B (which basically means
|
||||
that they swapped registers 0x59 and 0x5B when you compare with Winbond
|
||||
chips).
|
||||
Revision 1 of the chip also has the temperature sensor type selector at
|
||||
0x5B, but PWM registers have no effect.
|
||||
|
||||
We don't know exactly how the temperature sensor type selection works.
|
||||
Looks like bits 1-0 are for temp1, bits 3-2 for temp2 and bits 5-4 for
|
||||
temp3, although it is possible that only the most significant bit matters
|
||||
each time. So far, values other than 0 always broke the readings.
|
||||
|
||||
PWM registers seem to be split in two parts: bit 7 is a mode selector,
|
||||
while the other bits seem to define a value or threshold.
|
||||
|
||||
When bit 7 is clear, bits 6-0 seem to hold a threshold value. If the value
|
||||
is below a given limit, the fan runs at low speed. If the value is above
|
||||
the limit, the fan runs at full speed. We have no clue as to what the limit
|
||||
represents. Note that there seem to be some inertia in this mode, speed
|
||||
changes may need some time to trigger. Also, an hysteresis mechanism is
|
||||
suspected since walking through all the values increasingly and then
|
||||
decreasingly led to slightly different limits.
|
||||
|
||||
When bit 7 is set, bits 3-0 seem to hold a threshold value, while bits 6-4
|
||||
would not be significant. If the value is below a given limit, the fan runs
|
||||
at full speed, while if it is above the limit it runs at low speed (so this
|
||||
is the contrary of the other mode, in a way). Here again, we don't know
|
||||
what the limit is supposed to represent.
|
||||
|
||||
One remarkable thing is that the fans would only have two or three
|
||||
different speeds (transitional states left apart), not a whole range as
|
||||
you usually get with PWM.
|
||||
|
||||
As a conclusion, you can write 0x00 or 0x8F to the PWM registers to make
|
||||
fans run at low speed, and 0x7F or 0x80 to make them run at full speed.
|
||||
|
||||
Please contact us if you can figure out how it is supposed to work. As
|
||||
long as we don't know more, the w83781d driver doesn't handle PWM on
|
||||
AS99127F chips at all.
|
||||
|
||||
Additional info about PWM on the AS99127F rev.1 by Hector Martin:
|
||||
|
||||
I've been fiddling around with the (in)famous 0x59 register and
|
||||
found out the following values do work as a form of coarse pwm:
|
||||
|
||||
0x80 - seems to turn fans off after some time(1-2 minutes)... might be
|
||||
some form of auto-fan-control based on temp? hmm (Qfan? this mobo is an
|
||||
old ASUS, it isn't marketed as Qfan. Maybe some beta pre-attemp at Qfan
|
||||
that was dropped at the BIOS)
|
||||
0x81 - off
|
||||
0x82 - slightly "on-ner" than off, but my fans do not get to move. I can
|
||||
hear the high-pitched PWM sound that motors give off at too-low-pwm.
|
||||
0x83 - now they do move. Estimate about 70% speed or so.
|
||||
0x84-0x8f - full on
|
||||
|
||||
Changing the high nibble doesn't seem to do much except the high bit
|
||||
(0x80) must be set for PWM to work, else the current pwm doesn't seem to
|
||||
change.
|
||||
|
||||
My mobo is an ASUS A7V266-E. This behavior is similar to what I got
|
||||
with speedfan under Windows, where 0-15% would be off, 15-2x% (can't
|
||||
remember the exact value) would be 70% and higher would be full on.
|
39
Documentation/i2c/chips/w83l785ts
Normal file
39
Documentation/i2c/chips/w83l785ts
Normal file
|
@ -0,0 +1,39 @@
|
|||
Kernel driver w83l785ts
|
||||
=======================
|
||||
|
||||
Supported chips:
|
||||
* Winbond W83L785TS-S
|
||||
Prefix: 'w83l785ts'
|
||||
Addresses scanned: I2C 0x2e
|
||||
Datasheet: Publicly available at the Winbond USA website
|
||||
http://www.winbond-usa.com/products/winbond_products/pdfs/PCIC/W83L785TS-S.pdf
|
||||
|
||||
Authors:
|
||||
Jean Delvare <khali@linux-fr.org>
|
||||
|
||||
Description
|
||||
-----------
|
||||
|
||||
The W83L785TS-S is a digital temperature sensor. It senses the
|
||||
temperature of a single external diode. The high limit is
|
||||
theoretically defined as 85 or 100 degrees C through a combination
|
||||
of external resistors, so the user cannot change it. Values seen so
|
||||
far suggest that the two possible limits are actually 95 and 110
|
||||
degrees C. The datasheet is rather poor and obviously inaccurate
|
||||
on several points including this one.
|
||||
|
||||
All temperature values are given in degrees Celsius. Resolution
|
||||
is 1.0 degree. See the datasheet for details.
|
||||
|
||||
The w83l785ts 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.
|
||||
|
||||
Known Issues
|
||||
------------
|
||||
|
||||
On some systems (Asus), the BIOS is known to interfere with the driver
|
||||
and cause read errors. The driver will retry a given number of times
|
||||
(5 by default) and then give up, returning the old value (or 0 if
|
||||
there is no old value). It seems to work well enough so that you should
|
||||
not notice anything. Thanks to James Bolt for helping test this feature.
|
|
@ -57,7 +57,7 @@ Technical changes:
|
|||
Documentation/i2c/sysfs-interface for the individual files. Also
|
||||
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
|
||||
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.
|
||||
|
||||
* [Attach] For I2C drivers, the attach function should make sure
|
||||
|
|
39
Documentation/i2c/userspace-tools
Normal file
39
Documentation/i2c/userspace-tools
Normal file
|
@ -0,0 +1,39 @@
|
|||
Introduction
|
||||
------------
|
||||
|
||||
Most mainboards have sensor chips to monitor system health (like temperatures,
|
||||
voltages, fans speed). They are often connected through an I2C bus, but some
|
||||
are also connected directly through the ISA bus.
|
||||
|
||||
The kernel drivers make the data from the sensor chips available in the /sys
|
||||
virtual filesystem. Userspace tools are then used to display or set or the
|
||||
data in a more friendly manner.
|
||||
|
||||
Lm-sensors
|
||||
----------
|
||||
|
||||
Core set of utilites that will allow you to obtain health information,
|
||||
setup monitoring limits etc. You can get them on their homepage
|
||||
http://www.lm-sensors.nu/ or as a package from your Linux distribution.
|
||||
|
||||
If from website:
|
||||
Get lmsensors from project web site. Please note, you need only userspace
|
||||
part, so compile with "make user_install" target.
|
||||
|
||||
General hints to get things working:
|
||||
|
||||
0) get lm-sensors userspace utils
|
||||
1) compile all drivers in I2C section as modules in your kernel
|
||||
2) run sensors-detect script, it will tell you what modules you need to load.
|
||||
3) load them and run "sensors" command, you should see some results.
|
||||
4) fix sensors.conf, labels, limits, fan divisors
|
||||
5) if any more problems consult FAQ, or documentation
|
||||
|
||||
Other utilites
|
||||
--------------
|
||||
|
||||
If you want some graphical indicators of system health look for applications
|
||||
like: gkrellm, ksensors, xsensors, wmtemp, wmsensors, wmgtemp, ksysguardd,
|
||||
hardware-monitor
|
||||
|
||||
If you are server administrator you can try snmpd or mrtgutils.
|
|
@ -171,45 +171,31 @@ The following lists are used internally:
|
|||
|
||||
normal_i2c: filled in by the module writer.
|
||||
A list of I2C addresses which should normally be examined.
|
||||
normal_i2c_range: filled in by the module writer.
|
||||
A list of pairs of I2C addresses, each pair being an inclusive range of
|
||||
addresses which should normally be examined.
|
||||
probe: insmod parameter.
|
||||
A list of pairs. The first value is a bus number (-1 for any I2C bus),
|
||||
the second is the address. These addresses are also probed, as if they
|
||||
were in the 'normal' list.
|
||||
probe_range: insmod parameter.
|
||||
A list of triples. The first value is a bus number (-1 for any I2C bus),
|
||||
the second and third are addresses. These form an inclusive range of
|
||||
addresses that are also probed, as if they were in the 'normal' list.
|
||||
ignore: insmod parameter.
|
||||
A list of pairs. The first value is a bus number (-1 for any I2C bus),
|
||||
the second is the I2C address. These addresses are never probed.
|
||||
This parameter overrules 'normal' and 'probe', but not the 'force' lists.
|
||||
ignore_range: insmod parameter.
|
||||
A list of triples. The first value is a bus number (-1 for any I2C bus),
|
||||
the second and third are addresses. These form an inclusive range of
|
||||
I2C addresses that are never probed.
|
||||
This parameter overrules 'normal' and 'probe', but not the 'force' lists.
|
||||
force: insmod parameter.
|
||||
A list of pairs. The first value is a bus number (-1 for any I2C bus),
|
||||
the second is the I2C address. A device is blindly assumed to be on
|
||||
the given address, no probing is done.
|
||||
|
||||
Fortunately, as a module writer, you just have to define the `normal'
|
||||
and/or `normal_range' parameters. The complete declaration could look
|
||||
like this:
|
||||
Fortunately, as a module writer, you just have to define the `normal_i2c'
|
||||
parameter. The complete declaration could look like this:
|
||||
|
||||
/* Scan 0x20 to 0x2f, 0x37, and 0x40 to 0x4f */
|
||||
static unsigned short normal_i2c[] = { 0x37,I2C_CLIENT_END };
|
||||
static unsigned short normal_i2c_range[] = { 0x20, 0x2f, 0x40, 0x4f,
|
||||
I2C_CLIENT_END };
|
||||
/* Scan 0x37, and 0x48 to 0x4f */
|
||||
static unsigned short normal_i2c[] = { 0x37, 0x48, 0x49, 0x4a, 0x4b, 0x4c,
|
||||
0x4d, 0x4e, 0x4f, I2C_CLIENT_END };
|
||||
|
||||
/* Magic definition of all other variables and things */
|
||||
I2C_CLIENT_INSMOD;
|
||||
|
||||
Note that you *have* to call the two defined variables `normal_i2c' and
|
||||
`normal_i2c_range', without any prefix!
|
||||
Note that you *have* to call the defined variable `normal_i2c',
|
||||
without any prefix!
|
||||
|
||||
|
||||
Probing classes (sensors)
|
||||
|
@ -223,39 +209,17 @@ The following lists are used internally. They are all lists of integers.
|
|||
|
||||
normal_i2c: filled in by the module writer. Terminated by SENSORS_I2C_END.
|
||||
A list of I2C addresses which should normally be examined.
|
||||
normal_i2c_range: filled in by the module writer. Terminated by
|
||||
SENSORS_I2C_END
|
||||
A list of pairs of I2C addresses, each pair being an inclusive range of
|
||||
addresses which should normally be examined.
|
||||
normal_isa: filled in by the module writer. Terminated by SENSORS_ISA_END.
|
||||
A list of ISA addresses which should normally be examined.
|
||||
normal_isa_range: filled in by the module writer. Terminated by
|
||||
SENSORS_ISA_END
|
||||
A list of triples. The first two elements are ISA addresses, being an
|
||||
range of addresses which should normally be examined. The third is the
|
||||
modulo parameter: only addresses which are 0 module this value relative
|
||||
to the first address of the range are actually considered.
|
||||
probe: insmod parameter. Initialize this list with SENSORS_I2C_END values.
|
||||
A list of pairs. The first value is a bus number (SENSORS_ISA_BUS for
|
||||
the ISA bus, -1 for any I2C bus), the second is the address. These
|
||||
addresses are also probed, as if they were in the 'normal' list.
|
||||
probe_range: insmod parameter. Initialize this list with SENSORS_I2C_END
|
||||
values.
|
||||
A list of triples. The first value is a bus number (SENSORS_ISA_BUS for
|
||||
the ISA bus, -1 for any I2C bus), the second and third are addresses.
|
||||
These form an inclusive range of addresses that are also probed, as
|
||||
if they were in the 'normal' list.
|
||||
ignore: insmod parameter. Initialize this list with SENSORS_I2C_END values.
|
||||
A list of pairs. The first value is a bus number (SENSORS_ISA_BUS for
|
||||
the ISA bus, -1 for any I2C bus), the second is the I2C address. These
|
||||
addresses are never probed. This parameter overrules 'normal' and
|
||||
'probe', but not the 'force' lists.
|
||||
ignore_range: insmod parameter. Initialize this list with SENSORS_I2C_END
|
||||
values.
|
||||
A list of triples. The first value is a bus number (SENSORS_ISA_BUS for
|
||||
the ISA bus, -1 for any I2C bus), the second and third are addresses.
|
||||
These form an inclusive range of I2C addresses that are never probed.
|
||||
This parameter overrules 'normal' and 'probe', but not the 'force' lists.
|
||||
|
||||
Also used is a list of pointers to sensors_force_data structures:
|
||||
force_data: insmod parameters. A list, ending with an element of which
|
||||
|
@ -269,16 +233,14 @@ Also used is a list of pointers to sensors_force_data structures:
|
|||
So we have a generic insmod variabled `force', and chip-specific variables
|
||||
`force_CHIPNAME'.
|
||||
|
||||
Fortunately, as a module writer, you just have to define the `normal'
|
||||
and/or `normal_range' parameters, and define what chip names are used.
|
||||
Fortunately, as a module writer, you just have to define the `normal_i2c'
|
||||
and `normal_isa' parameters, and define what chip names are used.
|
||||
The complete declaration could look like this:
|
||||
/* Scan i2c addresses 0x20 to 0x2f, 0x37, and 0x40 to 0x4f
|
||||
static unsigned short normal_i2c[] = {0x37,SENSORS_I2C_END};
|
||||
static unsigned short normal_i2c_range[] = {0x20,0x2f,0x40,0x4f,
|
||||
SENSORS_I2C_END};
|
||||
/* Scan i2c addresses 0x37, and 0x48 to 0x4f */
|
||||
static unsigned short normal_i2c[] = { 0x37, 0x48, 0x49, 0x4a, 0x4b, 0x4c,
|
||||
0x4d, 0x4e, 0x4f, I2C_CLIENT_END };
|
||||
/* Scan ISA address 0x290 */
|
||||
static unsigned int normal_isa[] = {0x0290,SENSORS_ISA_END};
|
||||
static unsigned int normal_isa_range[] = {SENSORS_ISA_END};
|
||||
|
||||
/* Define chips foo and bar, as well as all module parameters and things */
|
||||
SENSORS_INSMOD_2(foo,bar);
|
||||
|
|
179
Documentation/kdump/gdbmacros.txt
Normal file
179
Documentation/kdump/gdbmacros.txt
Normal file
|
@ -0,0 +1,179 @@
|
|||
#
|
||||
# This file contains a few gdb macros (user defined commands) to extract
|
||||
# useful information from kernel crashdump (kdump) like stack traces of
|
||||
# all the processes or a particular process and trapinfo.
|
||||
#
|
||||
# These macros can be used by copying this file in .gdbinit (put in home
|
||||
# directory or current directory) or by invoking gdb command with
|
||||
# --command=<command-file-name> option
|
||||
#
|
||||
# Credits:
|
||||
# Alexander Nyberg <alexn@telia.com>
|
||||
# V Srivatsa <vatsa@in.ibm.com>
|
||||
# Maneesh Soni <maneesh@in.ibm.com>
|
||||
#
|
||||
|
||||
define bttnobp
|
||||
set $tasks_off=((size_t)&((struct task_struct *)0)->tasks)
|
||||
set $pid_off=((size_t)&((struct task_struct *)0)->pids[1].pid_list.next)
|
||||
set $init_t=&init_task
|
||||
set $next_t=(((char *)($init_t->tasks).next) - $tasks_off)
|
||||
while ($next_t != $init_t)
|
||||
set $next_t=(struct task_struct *)$next_t
|
||||
printf "\npid %d; comm %s:\n", $next_t.pid, $next_t.comm
|
||||
printf "===================\n"
|
||||
set var $stackp = $next_t.thread.esp
|
||||
set var $stack_top = ($stackp & ~4095) + 4096
|
||||
|
||||
while ($stackp < $stack_top)
|
||||
if (*($stackp) > _stext && *($stackp) < _sinittext)
|
||||
info symbol *($stackp)
|
||||
end
|
||||
set $stackp += 4
|
||||
end
|
||||
set $next_th=(((char *)$next_t->pids[1].pid_list.next) - $pid_off)
|
||||
while ($next_th != $next_t)
|
||||
set $next_th=(struct task_struct *)$next_th
|
||||
printf "\npid %d; comm %s:\n", $next_t.pid, $next_t.comm
|
||||
printf "===================\n"
|
||||
set var $stackp = $next_t.thread.esp
|
||||
set var $stack_top = ($stackp & ~4095) + 4096
|
||||
|
||||
while ($stackp < $stack_top)
|
||||
if (*($stackp) > _stext && *($stackp) < _sinittext)
|
||||
info symbol *($stackp)
|
||||
end
|
||||
set $stackp += 4
|
||||
end
|
||||
set $next_th=(((char *)$next_th->pids[1].pid_list.next) - $pid_off)
|
||||
end
|
||||
set $next_t=(char *)($next_t->tasks.next) - $tasks_off
|
||||
end
|
||||
end
|
||||
document bttnobp
|
||||
dump all thread stack traces on a kernel compiled with !CONFIG_FRAME_POINTER
|
||||
end
|
||||
|
||||
define btt
|
||||
set $tasks_off=((size_t)&((struct task_struct *)0)->tasks)
|
||||
set $pid_off=((size_t)&((struct task_struct *)0)->pids[1].pid_list.next)
|
||||
set $init_t=&init_task
|
||||
set $next_t=(((char *)($init_t->tasks).next) - $tasks_off)
|
||||
while ($next_t != $init_t)
|
||||
set $next_t=(struct task_struct *)$next_t
|
||||
printf "\npid %d; comm %s:\n", $next_t.pid, $next_t.comm
|
||||
printf "===================\n"
|
||||
set var $stackp = $next_t.thread.esp
|
||||
set var $stack_top = ($stackp & ~4095) + 4096
|
||||
set var $stack_bot = ($stackp & ~4095)
|
||||
|
||||
set $stackp = *($stackp)
|
||||
while (($stackp < $stack_top) && ($stackp > $stack_bot))
|
||||
set var $addr = *($stackp + 4)
|
||||
info symbol $addr
|
||||
set $stackp = *($stackp)
|
||||
end
|
||||
|
||||
set $next_th=(((char *)$next_t->pids[1].pid_list.next) - $pid_off)
|
||||
while ($next_th != $next_t)
|
||||
set $next_th=(struct task_struct *)$next_th
|
||||
printf "\npid %d; comm %s:\n", $next_t.pid, $next_t.comm
|
||||
printf "===================\n"
|
||||
set var $stackp = $next_t.thread.esp
|
||||
set var $stack_top = ($stackp & ~4095) + 4096
|
||||
set var $stack_bot = ($stackp & ~4095)
|
||||
|
||||
set $stackp = *($stackp)
|
||||
while (($stackp < $stack_top) && ($stackp > $stack_bot))
|
||||
set var $addr = *($stackp + 4)
|
||||
info symbol $addr
|
||||
set $stackp = *($stackp)
|
||||
end
|
||||
set $next_th=(((char *)$next_th->pids[1].pid_list.next) - $pid_off)
|
||||
end
|
||||
set $next_t=(char *)($next_t->tasks.next) - $tasks_off
|
||||
end
|
||||
end
|
||||
document btt
|
||||
dump all thread stack traces on a kernel compiled with CONFIG_FRAME_POINTER
|
||||
end
|
||||
|
||||
define btpid
|
||||
set var $pid = $arg0
|
||||
set $tasks_off=((size_t)&((struct task_struct *)0)->tasks)
|
||||
set $pid_off=((size_t)&((struct task_struct *)0)->pids[1].pid_list.next)
|
||||
set $init_t=&init_task
|
||||
set $next_t=(((char *)($init_t->tasks).next) - $tasks_off)
|
||||
set var $pid_task = 0
|
||||
|
||||
while ($next_t != $init_t)
|
||||
set $next_t=(struct task_struct *)$next_t
|
||||
|
||||
if ($next_t.pid == $pid)
|
||||
set $pid_task = $next_t
|
||||
end
|
||||
|
||||
set $next_th=(((char *)$next_t->pids[1].pid_list.next) - $pid_off)
|
||||
while ($next_th != $next_t)
|
||||
set $next_th=(struct task_struct *)$next_th
|
||||
if ($next_th.pid == $pid)
|
||||
set $pid_task = $next_th
|
||||
end
|
||||
set $next_th=(((char *)$next_th->pids[1].pid_list.next) - $pid_off)
|
||||
end
|
||||
set $next_t=(char *)($next_t->tasks.next) - $tasks_off
|
||||
end
|
||||
|
||||
printf "\npid %d; comm %s:\n", $pid_task.pid, $pid_task.comm
|
||||
printf "===================\n"
|
||||
set var $stackp = $pid_task.thread.esp
|
||||
set var $stack_top = ($stackp & ~4095) + 4096
|
||||
set var $stack_bot = ($stackp & ~4095)
|
||||
|
||||
set $stackp = *($stackp)
|
||||
while (($stackp < $stack_top) && ($stackp > $stack_bot))
|
||||
set var $addr = *($stackp + 4)
|
||||
info symbol $addr
|
||||
set $stackp = *($stackp)
|
||||
end
|
||||
end
|
||||
document btpid
|
||||
backtrace of pid
|
||||
end
|
||||
|
||||
|
||||
define trapinfo
|
||||
set var $pid = $arg0
|
||||
set $tasks_off=((size_t)&((struct task_struct *)0)->tasks)
|
||||
set $pid_off=((size_t)&((struct task_struct *)0)->pids[1].pid_list.next)
|
||||
set $init_t=&init_task
|
||||
set $next_t=(((char *)($init_t->tasks).next) - $tasks_off)
|
||||
set var $pid_task = 0
|
||||
|
||||
while ($next_t != $init_t)
|
||||
set $next_t=(struct task_struct *)$next_t
|
||||
|
||||
if ($next_t.pid == $pid)
|
||||
set $pid_task = $next_t
|
||||
end
|
||||
|
||||
set $next_th=(((char *)$next_t->pids[1].pid_list.next) - $pid_off)
|
||||
while ($next_th != $next_t)
|
||||
set $next_th=(struct task_struct *)$next_th
|
||||
if ($next_th.pid == $pid)
|
||||
set $pid_task = $next_th
|
||||
end
|
||||
set $next_th=(((char *)$next_th->pids[1].pid_list.next) - $pid_off)
|
||||
end
|
||||
set $next_t=(char *)($next_t->tasks.next) - $tasks_off
|
||||
end
|
||||
|
||||
printf "Trapno %ld, cr2 0x%lx, error_code %ld\n", $pid_task.thread.trap_no, \
|
||||
$pid_task.thread.cr2, $pid_task.thread.error_code
|
||||
|
||||
end
|
||||
document trapinfo
|
||||
Run info threads and lookup pid of thread #1
|
||||
'trapinfo <pid>' will tell you by which trap & possibly
|
||||
addresthe kernel paniced.
|
||||
end
|
141
Documentation/kdump/kdump.txt
Normal file
141
Documentation/kdump/kdump.txt
Normal file
|
@ -0,0 +1,141 @@
|
|||
Documentation for kdump - the kexec-based crash dumping solution
|
||||
================================================================
|
||||
|
||||
DESIGN
|
||||
======
|
||||
|
||||
Kdump uses kexec to reboot to a second kernel whenever a dump needs to be taken.
|
||||
This second kernel is booted with very little memory. The first kernel reserves
|
||||
the section of memory that the second kernel uses. This ensures that on-going
|
||||
DMA from the first kernel does not corrupt the second kernel.
|
||||
|
||||
All the necessary information about Core image is encoded in ELF format and
|
||||
stored in reserved area of memory before crash. Physical address of start of
|
||||
ELF header is passed to new kernel through command line parameter elfcorehdr=.
|
||||
|
||||
On i386, the first 640 KB of physical memory is needed to boot, irrespective
|
||||
of where the kernel loads. Hence, this region is backed up by kexec just before
|
||||
rebooting into the new kernel.
|
||||
|
||||
In the second kernel, "old memory" can be accessed in two ways.
|
||||
|
||||
- The first one is through a /dev/oldmem device interface. A capture utility
|
||||
can read the device file and write out the memory in raw format. This is raw
|
||||
dump of memory and analysis/capture tool should be intelligent enough to
|
||||
determine where to look for the right information. ELF headers (elfcorehdr=)
|
||||
can become handy here.
|
||||
|
||||
- The second interface is through /proc/vmcore. This exports the dump as an ELF
|
||||
format file which can be written out using any file copy command
|
||||
(cp, scp, etc). Further, gdb can be used to perform limited debugging on
|
||||
the dump file. This method ensures methods ensure that there is correct
|
||||
ordering of the dump pages (corresponding to the first 640 KB that has been
|
||||
relocated).
|
||||
|
||||
SETUP
|
||||
=====
|
||||
|
||||
1) Download http://www.xmission.com/~ebiederm/files/kexec/kexec-tools-1.101.tar.gz
|
||||
and apply http://lse.sourceforge.net/kdump/patches/kexec-tools-1.101-kdump.patch
|
||||
and after that build the source.
|
||||
|
||||
2) Download and build the appropriate (latest) kexec/kdump (-mm) kernel
|
||||
patchset and apply it to the vanilla kernel tree.
|
||||
|
||||
Two kernels need to be built in order to get this feature working.
|
||||
|
||||
A) First kernel:
|
||||
a) Enable "kexec system call" feature (in Processor type and features).
|
||||
CONFIG_KEXEC=y
|
||||
b) This kernel's physical load address should be the default value of
|
||||
0x100000 (0x100000, 1 MB) (in Processor type and features).
|
||||
CONFIG_PHYSICAL_START=0x100000
|
||||
c) Enable "sysfs file system support" (in Pseudo filesystems).
|
||||
CONFIG_SYSFS=y
|
||||
d) Boot into first kernel with the command line parameter "crashkernel=Y@X".
|
||||
Use appropriate values for X and Y. Y denotes how much memory to reserve
|
||||
for the second kernel, and X denotes at what physical address the reserved
|
||||
memory section starts. For example: "crashkernel=64M@16M".
|
||||
|
||||
B) Second kernel:
|
||||
a) Enable "kernel crash dumps" feature (in Processor type and features).
|
||||
CONFIG_CRASH_DUMP=y
|
||||
b) Specify a suitable value for "Physical address where the kernel is
|
||||
loaded" (in Processor type and features). Typically this value
|
||||
should be same as X (See option d) above, e.g., 16 MB or 0x1000000.
|
||||
CONFIG_PHYSICAL_START=0x1000000
|
||||
c) Enable "/proc/vmcore support" (Optional, in Pseudo filesystems).
|
||||
CONFIG_PROC_VMCORE=y
|
||||
d) Disable SMP support and build a UP kernel (Until it is fixed).
|
||||
CONFIG_SMP=n
|
||||
e) Enable "Local APIC support on uniprocessors".
|
||||
CONFIG_X86_UP_APIC=y
|
||||
f) Enable "IO-APIC support on uniprocessors"
|
||||
CONFIG_X86_UP_IOAPIC=y
|
||||
|
||||
Note: i) Options a) and b) depend upon "Configure standard kernel features
|
||||
(for small systems)" (under General setup).
|
||||
ii) Option a) also depends on CONFIG_HIGHMEM (under Processor
|
||||
type and features).
|
||||
iii) Both option a) and b) are under "Processor type and features".
|
||||
|
||||
3) Boot into the first kernel. You are now ready to try out kexec-based crash
|
||||
dumps.
|
||||
|
||||
4) Load the second kernel to be booted using:
|
||||
|
||||
kexec -p <second-kernel> --crash-dump --args-linux --append="root=<root-dev>
|
||||
init 1 irqpoll"
|
||||
|
||||
Note: i) <second-kernel> has to be a vmlinux image. bzImage will not work,
|
||||
as of now.
|
||||
ii) By default ELF headers are stored in ELF32 format (for i386). This
|
||||
is sufficient to represent the physical memory up to 4GB. To store
|
||||
headers in ELF64 format, specifiy "--elf64-core-headers" on the
|
||||
kexec command line additionally.
|
||||
iii) Specify "irqpoll" as command line parameter. This reduces driver
|
||||
initialization failures in second kernel due to shared interrupts.
|
||||
|
||||
5) System reboots into the second kernel when a panic occurs. A module can be
|
||||
written to force the panic or "ALT-SysRq-c" can be used initiate a crash
|
||||
dump for testing purposes.
|
||||
|
||||
6) Write out the dump file using
|
||||
|
||||
cp /proc/vmcore <dump-file>
|
||||
|
||||
Dump memory can also be accessed as a /dev/oldmem device for a linear/raw
|
||||
view. To create the device, type:
|
||||
|
||||
mknod /dev/oldmem c 1 12
|
||||
|
||||
Use "dd" with suitable options for count, bs and skip to access specific
|
||||
portions of the dump.
|
||||
|
||||
Entire memory: dd if=/dev/oldmem of=oldmem.001
|
||||
|
||||
ANALYSIS
|
||||
========
|
||||
|
||||
Limited analysis can be done using gdb on the dump file copied out of
|
||||
/proc/vmcore. Use vmlinux built with -g and run
|
||||
|
||||
gdb vmlinux <dump-file>
|
||||
|
||||
Stack trace for the task on processor 0, register display, memory display
|
||||
work fine.
|
||||
|
||||
Note: gdb cannot analyse core files generated in ELF64 format for i386.
|
||||
|
||||
TODO
|
||||
====
|
||||
|
||||
1) Provide a kernel pages filtering mechanism so that core file size is not
|
||||
insane on systems having huge memory banks.
|
||||
2) Modify "crash" tool to make it recognize this dump.
|
||||
|
||||
CONTACT
|
||||
=======
|
||||
|
||||
Vivek Goyal (vgoyal@in.ibm.com)
|
||||
Maneesh Soni (maneesh@in.ibm.com)
|
|
@ -358,6 +358,10 @@ running once the system is up.
|
|||
cpia_pp= [HW,PPT]
|
||||
Format: { parport<nr> | auto | none }
|
||||
|
||||
crashkernel=nn[KMG]@ss[KMG]
|
||||
[KNL] Reserve a chunk of physical memory to
|
||||
hold a kernel to switch to with kexec on panic.
|
||||
|
||||
cs4232= [HW,OSS]
|
||||
Format: <io>,<irq>,<dma>,<dma2>,<mpuio>,<mpuirq>
|
||||
|
||||
|
@ -447,6 +451,10 @@ running once the system is up.
|
|||
Format: {"as"|"cfq"|"deadline"|"noop"}
|
||||
See Documentation/block/as-iosched.txt
|
||||
and Documentation/block/deadline-iosched.txt for details.
|
||||
elfcorehdr= [IA-32]
|
||||
Specifies physical address of start of kernel core image
|
||||
elf header.
|
||||
See Documentation/kdump.txt for details.
|
||||
|
||||
enforcing [SELINUX] Set initial enforcing status.
|
||||
Format: {"0" | "1"}
|
||||
|
@ -548,6 +556,9 @@ running once the system is up.
|
|||
|
||||
i810= [HW,DRM]
|
||||
|
||||
i8k.ignore_dmi [HW] Continue probing hardware even if DMI data
|
||||
indicates that the driver is running on unsupported
|
||||
hardware.
|
||||
i8k.force [HW] Activate i8k driver even if SMM BIOS signature
|
||||
does not match list of supported models.
|
||||
i8k.power_status
|
||||
|
|
|
@ -22,6 +22,7 @@ This document has the following sections:
|
|||
- New procfs files
|
||||
- Userspace system call interface
|
||||
- Kernel services
|
||||
- Notes on accessing payload contents
|
||||
- Defining a key type
|
||||
- Request-key callback service
|
||||
- Key access filesystem
|
||||
|
@ -45,27 +46,26 @@ Each key has a number of attributes:
|
|||
- State.
|
||||
|
||||
|
||||
(*) Each key is issued a serial number of type key_serial_t that is unique
|
||||
for the lifetime of that key. All serial numbers are positive non-zero
|
||||
32-bit integers.
|
||||
(*) Each key is issued a serial number of type key_serial_t that is unique for
|
||||
the lifetime of that key. All serial numbers are positive non-zero 32-bit
|
||||
integers.
|
||||
|
||||
Userspace programs can use a key's serial numbers as a way to gain access
|
||||
to it, subject to permission checking.
|
||||
|
||||
(*) Each key is of a defined "type". Types must be registered inside the
|
||||
kernel by a kernel service (such as a filesystem) before keys of that
|
||||
type can be added or used. Userspace programs cannot define new types
|
||||
directly.
|
||||
kernel by a kernel service (such as a filesystem) before keys of that type
|
||||
can be added or used. Userspace programs cannot define new types directly.
|
||||
|
||||
Key types are represented in the kernel by struct key_type. This defines
|
||||
a number of operations that can be performed on a key of that type.
|
||||
Key types are represented in the kernel by struct key_type. This defines a
|
||||
number of operations that can be performed on a key of that type.
|
||||
|
||||
Should a type be removed from the system, all the keys of that type will
|
||||
be invalidated.
|
||||
|
||||
(*) Each key has a description. This should be a printable string. The key
|
||||
type provides an operation to perform a match between the description on
|
||||
a key and a criterion string.
|
||||
type provides an operation to perform a match between the description on a
|
||||
key and a criterion string.
|
||||
|
||||
(*) Each key has an owner user ID, a group ID and a permissions mask. These
|
||||
are used to control what a process may do to a key from userspace, and
|
||||
|
@ -74,10 +74,10 @@ Each key has a number of attributes:
|
|||
(*) Each key can be set to expire at a specific time by the key type's
|
||||
instantiation function. Keys can also be immortal.
|
||||
|
||||
(*) Each key can have a payload. This is a quantity of data that represent
|
||||
the actual "key". In the case of a keyring, this is a list of keys to
|
||||
which the keyring links; in the case of a user-defined key, it's an
|
||||
arbitrary blob of data.
|
||||
(*) Each key can have a payload. This is a quantity of data that represent the
|
||||
actual "key". In the case of a keyring, this is a list of keys to which
|
||||
the keyring links; in the case of a user-defined key, it's an arbitrary
|
||||
blob of data.
|
||||
|
||||
Having a payload is not required; and the payload can, in fact, just be a
|
||||
value stored in the struct key itself.
|
||||
|
@ -92,8 +92,8 @@ Each key has a number of attributes:
|
|||
|
||||
(*) Each key can be in one of a number of basic states:
|
||||
|
||||
(*) Uninstantiated. The key exists, but does not have any data
|
||||
attached. Keys being requested from userspace will be in this state.
|
||||
(*) Uninstantiated. The key exists, but does not have any data attached.
|
||||
Keys being requested from userspace will be in this state.
|
||||
|
||||
(*) Instantiated. This is the normal state. The key is fully formed, and
|
||||
has data attached.
|
||||
|
@ -140,10 +140,10 @@ The key service provides a number of features besides keys:
|
|||
clone, fork, vfork or execve occurs. A new keyring is created only when
|
||||
required.
|
||||
|
||||
The process-specific keyring is replaced with an empty one in the child
|
||||
on clone, fork, vfork unless CLONE_THREAD is supplied, in which case it
|
||||
is shared. execve also discards the process's process keyring and creates
|
||||
a new one.
|
||||
The process-specific keyring is replaced with an empty one in the child on
|
||||
clone, fork, vfork unless CLONE_THREAD is supplied, in which case it is
|
||||
shared. execve also discards the process's process keyring and creates a
|
||||
new one.
|
||||
|
||||
The session-specific keyring is persistent across clone, fork, vfork and
|
||||
execve, even when the latter executes a set-UID or set-GID binary. A
|
||||
|
@ -177,11 +177,11 @@ The key service provides a number of features besides keys:
|
|||
If a system call that modifies a key or keyring in some way would put the
|
||||
user over quota, the operation is refused and error EDQUOT is returned.
|
||||
|
||||
(*) There's a system call interface by which userspace programs can create
|
||||
and manipulate keys and keyrings.
|
||||
(*) There's a system call interface by which userspace programs can create and
|
||||
manipulate keys and keyrings.
|
||||
|
||||
(*) There's a kernel interface by which services can register types and
|
||||
search for keys.
|
||||
(*) There's a kernel interface by which services can register types and search
|
||||
for keys.
|
||||
|
||||
(*) There's a way for the a search done from the kernel to call back to
|
||||
userspace to request a key that can't be found in a process's keyrings.
|
||||
|
@ -194,9 +194,9 @@ The key service provides a number of features besides keys:
|
|||
KEY ACCESS PERMISSIONS
|
||||
======================
|
||||
|
||||
Keys have an owner user ID, a group access ID, and a permissions mask. The
|
||||
mask has up to eight bits each for user, group and other access. Only five of
|
||||
each set of eight bits are defined. These permissions granted are:
|
||||
Keys have an owner user ID, a group access ID, and a permissions mask. The mask
|
||||
has up to eight bits each for user, group and other access. Only five of each
|
||||
set of eight bits are defined. These permissions granted are:
|
||||
|
||||
(*) View
|
||||
|
||||
|
@ -210,8 +210,8 @@ each set of eight bits are defined. These permissions granted are:
|
|||
|
||||
(*) Write
|
||||
|
||||
This permits a key's payload to be instantiated or updated, or it allows
|
||||
a link to be added to or removed from a keyring.
|
||||
This permits a key's payload to be instantiated or updated, or it allows a
|
||||
link to be added to or removed from a keyring.
|
||||
|
||||
(*) Search
|
||||
|
||||
|
@ -238,8 +238,8 @@ about the status of the key service:
|
|||
(*) /proc/keys
|
||||
|
||||
This lists all the keys on the system, giving information about their
|
||||
type, description and permissions. The payload of the key is not
|
||||
available this way:
|
||||
type, description and permissions. The payload of the key is not available
|
||||
this way:
|
||||
|
||||
SERIAL FLAGS USAGE EXPY PERM UID GID TYPE DESCRIPTION: SUMMARY
|
||||
00000001 I----- 39 perm 1f0000 0 0 keyring _uid_ses.0: 1/4
|
||||
|
@ -318,21 +318,21 @@ The main syscalls are:
|
|||
If a key of the same type and description as that proposed already exists
|
||||
in the keyring, this will try to update it with the given payload, or it
|
||||
will return error EEXIST if that function is not supported by the key
|
||||
type. The process must also have permission to write to the key to be
|
||||
able to update it. The new key will have all user permissions granted and
|
||||
no group or third party permissions.
|
||||
type. The process must also have permission to write to the key to be able
|
||||
to update it. The new key will have all user permissions granted and no
|
||||
group or third party permissions.
|
||||
|
||||
Otherwise, this will attempt to create a new key of the specified type
|
||||
and description, and to instantiate it with the supplied payload and
|
||||
attach it to the keyring. In this case, an error will be generated if the
|
||||
process does not have permission to write to the keyring.
|
||||
Otherwise, this will attempt to create a new key of the specified type and
|
||||
description, and to instantiate it with the supplied payload and attach it
|
||||
to the keyring. In this case, an error will be generated if the process
|
||||
does not have permission to write to the keyring.
|
||||
|
||||
The payload is optional, and the pointer can be NULL if not required by
|
||||
the type. The payload is plen in size, and plen can be zero for an empty
|
||||
payload.
|
||||
|
||||
A new keyring can be generated by setting type "keyring", the keyring
|
||||
name as the description (or NULL) and setting the payload to NULL.
|
||||
A new keyring can be generated by setting type "keyring", the keyring name
|
||||
as the description (or NULL) and setting the payload to NULL.
|
||||
|
||||
User defined keys can be created by specifying type "user". It is
|
||||
recommended that a user defined key's description by prefixed with a type
|
||||
|
@ -369,9 +369,9 @@ The keyctl syscall functions are:
|
|||
key_serial_t keyctl(KEYCTL_GET_KEYRING_ID, key_serial_t id,
|
||||
int create);
|
||||
|
||||
The special key specified by "id" is looked up (with the key being
|
||||
created if necessary) and the ID of the key or keyring thus found is
|
||||
returned if it exists.
|
||||
The special key specified by "id" is looked up (with the key being created
|
||||
if necessary) and the ID of the key or keyring thus found is returned if
|
||||
it exists.
|
||||
|
||||
If the key does not yet exist, the key will be created if "create" is
|
||||
non-zero; and the error ENOKEY will be returned if "create" is zero.
|
||||
|
@ -402,8 +402,8 @@ The keyctl syscall functions are:
|
|||
|
||||
This will try to update the specified key with the given payload, or it
|
||||
will return error EOPNOTSUPP if that function is not supported by the key
|
||||
type. The process must also have permission to write to the key to be
|
||||
able to update it.
|
||||
type. The process must also have permission to write to the key to be able
|
||||
to update it.
|
||||
|
||||
The payload is of length plen, and may be absent or empty as for
|
||||
add_key().
|
||||
|
@ -422,8 +422,8 @@ The keyctl syscall functions are:
|
|||
|
||||
long keyctl(KEYCTL_CHOWN, key_serial_t key, uid_t uid, gid_t gid);
|
||||
|
||||
This function permits a key's owner and group ID to be changed. Either
|
||||
one of uid or gid can be set to -1 to suppress that change.
|
||||
This function permits a key's owner and group ID to be changed. Either one
|
||||
of uid or gid can be set to -1 to suppress that change.
|
||||
|
||||
Only the superuser can change a key's owner to something other than the
|
||||
key's current owner. Similarly, only the superuser can change a key's
|
||||
|
@ -484,12 +484,12 @@ The keyctl syscall functions are:
|
|||
|
||||
long keyctl(KEYCTL_LINK, key_serial_t keyring, key_serial_t key);
|
||||
|
||||
This function creates a link from the keyring to the key. The process
|
||||
must have write permission on the keyring and must have link permission
|
||||
on the key.
|
||||
This function creates a link from the keyring to the key. The process must
|
||||
have write permission on the keyring and must have link permission on the
|
||||
key.
|
||||
|
||||
Should the keyring not be a keyring, error ENOTDIR will result; and if
|
||||
the keyring is full, error ENFILE will result.
|
||||
Should the keyring not be a keyring, error ENOTDIR will result; and if the
|
||||
keyring is full, error ENFILE will result.
|
||||
|
||||
The link procedure checks the nesting of the keyrings, returning ELOOP if
|
||||
it appears to deep or EDEADLK if the link would introduce a cycle.
|
||||
|
@ -503,8 +503,8 @@ The keyctl syscall functions are:
|
|||
specified key, and removes it if found. Subsequent links to that key are
|
||||
ignored. The process must have write permission on the keyring.
|
||||
|
||||
If the keyring is not a keyring, error ENOTDIR will result; and if the
|
||||
key is not present, error ENOENT will be the result.
|
||||
If the keyring is not a keyring, error ENOTDIR will result; and if the key
|
||||
is not present, error ENOENT will be the result.
|
||||
|
||||
|
||||
(*) Search a keyring tree for a key:
|
||||
|
@ -513,9 +513,9 @@ The keyctl syscall functions are:
|
|||
const char *type, const char *description,
|
||||
key_serial_t dest_keyring);
|
||||
|
||||
This searches the keyring tree headed by the specified keyring until a
|
||||
key is found that matches the type and description criteria. Each keyring
|
||||
is checked for keys before recursion into its children occurs.
|
||||
This searches the keyring tree headed by the specified keyring until a key
|
||||
is found that matches the type and description criteria. Each keyring is
|
||||
checked for keys before recursion into its children occurs.
|
||||
|
||||
The process must have search permission on the top level keyring, or else
|
||||
error EACCES will result. Only keyrings that the process has search
|
||||
|
@ -549,8 +549,8 @@ The keyctl syscall functions are:
|
|||
As much of the data as can be fitted into the buffer will be copied to
|
||||
userspace if the buffer pointer is not NULL.
|
||||
|
||||
On a successful return, the function will always return the amount of
|
||||
data available rather than the amount copied.
|
||||
On a successful return, the function will always return the amount of data
|
||||
available rather than the amount copied.
|
||||
|
||||
|
||||
(*) Instantiate a partially constructed key.
|
||||
|
@ -568,8 +568,8 @@ The keyctl syscall functions are:
|
|||
it, and the key must be uninstantiated.
|
||||
|
||||
If a keyring is specified (non-zero), the key will also be linked into
|
||||
that keyring, however all the constraints applying in KEYCTL_LINK apply
|
||||
in this case too.
|
||||
that keyring, however all the constraints applying in KEYCTL_LINK apply in
|
||||
this case too.
|
||||
|
||||
The payload and plen arguments describe the payload data as for add_key().
|
||||
|
||||
|
@ -587,8 +587,39 @@ The keyctl syscall functions are:
|
|||
it, and the key must be uninstantiated.
|
||||
|
||||
If a keyring is specified (non-zero), the key will also be linked into
|
||||
that keyring, however all the constraints applying in KEYCTL_LINK apply
|
||||
in this case too.
|
||||
that keyring, however all the constraints applying in KEYCTL_LINK apply in
|
||||
this case too.
|
||||
|
||||
|
||||
(*) Set the default request-key destination keyring.
|
||||
|
||||
long keyctl(KEYCTL_SET_REQKEY_KEYRING, int reqkey_defl);
|
||||
|
||||
This sets the default keyring to which implicitly requested keys will be
|
||||
attached for this thread. reqkey_defl should be one of these constants:
|
||||
|
||||
CONSTANT VALUE NEW DEFAULT KEYRING
|
||||
====================================== ====== =======================
|
||||
KEY_REQKEY_DEFL_NO_CHANGE -1 No change
|
||||
KEY_REQKEY_DEFL_DEFAULT 0 Default[1]
|
||||
KEY_REQKEY_DEFL_THREAD_KEYRING 1 Thread keyring
|
||||
KEY_REQKEY_DEFL_PROCESS_KEYRING 2 Process keyring
|
||||
KEY_REQKEY_DEFL_SESSION_KEYRING 3 Session keyring
|
||||
KEY_REQKEY_DEFL_USER_KEYRING 4 User keyring
|
||||
KEY_REQKEY_DEFL_USER_SESSION_KEYRING 5 User session keyring
|
||||
KEY_REQKEY_DEFL_GROUP_KEYRING 6 Group keyring
|
||||
|
||||
The old default will be returned if successful and error EINVAL will be
|
||||
returned if reqkey_defl is not one of the above values.
|
||||
|
||||
The default keyring can be overridden by the keyring indicated to the
|
||||
request_key() system call.
|
||||
|
||||
Note that this setting is inherited across fork/exec.
|
||||
|
||||
[1] The default default is: the thread keyring if there is one, otherwise
|
||||
the process keyring if there is one, otherwise the session keyring if
|
||||
there is one, otherwise the user default session keyring.
|
||||
|
||||
|
||||
===============
|
||||
|
@ -601,17 +632,14 @@ be broken down into two areas: keys and key types.
|
|||
Dealing with keys is fairly straightforward. Firstly, the kernel service
|
||||
registers its type, then it searches for a key of that type. It should retain
|
||||
the key as long as it has need of it, and then it should release it. For a
|
||||
filesystem or device file, a search would probably be performed during the
|
||||
open call, and the key released upon close. How to deal with conflicting keys
|
||||
due to two different users opening the same file is left to the filesystem
|
||||
author to solve.
|
||||
filesystem or device file, a search would probably be performed during the open
|
||||
call, and the key released upon close. How to deal with conflicting keys due to
|
||||
two different users opening the same file is left to the filesystem author to
|
||||
solve.
|
||||
|
||||
When accessing a key's payload data, key->lock should be at least read locked,
|
||||
or else the data may be changed by an update being performed from userspace
|
||||
whilst the driver or filesystem is trying to access it. If no update method is
|
||||
supplied, then the key's payload may be accessed without holding a lock as
|
||||
there is no way to change it, provided it can be guaranteed that the key's
|
||||
type definition won't go away.
|
||||
When accessing a key's payload contents, certain precautions must be taken to
|
||||
prevent access vs modification races. See the section "Notes on accessing
|
||||
payload contents" for more information.
|
||||
|
||||
(*) To search for a key, call:
|
||||
|
||||
|
@ -629,6 +657,9 @@ type definition won't go away.
|
|||
Should the function fail error ENOKEY, EKEYEXPIRED or EKEYREVOKED will be
|
||||
returned.
|
||||
|
||||
If successful, the key will have been attached to the default keyring for
|
||||
implicitly obtained request-key keys, as set by KEYCTL_SET_REQKEY_KEYRING.
|
||||
|
||||
|
||||
(*) When it is no longer required, the key should be released using:
|
||||
|
||||
|
@ -690,6 +721,54 @@ type definition won't go away.
|
|||
void unregister_key_type(struct key_type *type);
|
||||
|
||||
|
||||
===================================
|
||||
NOTES ON ACCESSING PAYLOAD CONTENTS
|
||||
===================================
|
||||
|
||||
The simplest payload is just a number in key->payload.value. In this case,
|
||||
there's no need to indulge in RCU or locking when accessing the payload.
|
||||
|
||||
More complex payload contents must be allocated and a pointer to them set in
|
||||
key->payload.data. One of the following ways must be selected to access the
|
||||
data:
|
||||
|
||||
(1) Unmodifyable key type.
|
||||
|
||||
If the key type does not have a modify method, then the key's payload can
|
||||
be accessed without any form of locking, provided that it's known to be
|
||||
instantiated (uninstantiated keys cannot be "found").
|
||||
|
||||
(2) The key's semaphore.
|
||||
|
||||
The semaphore could be used to govern access to the payload and to control
|
||||
the payload pointer. It must be write-locked for modifications and would
|
||||
have to be read-locked for general access. The disadvantage of doing this
|
||||
is that the accessor may be required to sleep.
|
||||
|
||||
(3) RCU.
|
||||
|
||||
RCU must be used when the semaphore isn't already held; if the semaphore
|
||||
is held then the contents can't change under you unexpectedly as the
|
||||
semaphore must still be used to serialise modifications to the key. The
|
||||
key management code takes care of this for the key type.
|
||||
|
||||
However, this means using:
|
||||
|
||||
rcu_read_lock() ... rcu_dereference() ... rcu_read_unlock()
|
||||
|
||||
to read the pointer, and:
|
||||
|
||||
rcu_dereference() ... rcu_assign_pointer() ... call_rcu()
|
||||
|
||||
to set the pointer and dispose of the old contents after a grace period.
|
||||
Note that only the key type should ever modify a key's payload.
|
||||
|
||||
Furthermore, an RCU controlled payload must hold a struct rcu_head for the
|
||||
use of call_rcu() and, if the payload is of variable size, the length of
|
||||
the payload. key->datalen cannot be relied upon to be consistent with the
|
||||
payload just dereferenced if the key's semaphore is not held.
|
||||
|
||||
|
||||
===================
|
||||
DEFINING A KEY TYPE
|
||||
===================
|
||||
|
@ -717,15 +796,15 @@ The structure has a number of fields, some of which are mandatory:
|
|||
|
||||
int key_payload_reserve(struct key *key, size_t datalen);
|
||||
|
||||
With the revised data length. Error EDQUOT will be returned if this is
|
||||
not viable.
|
||||
With the revised data length. Error EDQUOT will be returned if this is not
|
||||
viable.
|
||||
|
||||
|
||||
(*) int (*instantiate)(struct key *key, const void *data, size_t datalen);
|
||||
|
||||
This method is called to attach a payload to a key during construction.
|
||||
The payload attached need not bear any relation to the data passed to
|
||||
this function.
|
||||
The payload attached need not bear any relation to the data passed to this
|
||||
function.
|
||||
|
||||
If the amount of data attached to the key differs from the size in
|
||||
keytype->def_datalen, then key_payload_reserve() should be called.
|
||||
|
@ -734,38 +813,47 @@ The structure has a number of fields, some of which are mandatory:
|
|||
The fact that KEY_FLAG_INSTANTIATED is not set in key->flags prevents
|
||||
anything else from gaining access to the key.
|
||||
|
||||
This method may sleep if it wishes.
|
||||
It is safe to sleep in this method.
|
||||
|
||||
|
||||
(*) int (*duplicate)(struct key *key, const struct key *source);
|
||||
|
||||
If this type of key can be duplicated, then this method should be
|
||||
provided. It is called to copy the payload attached to the source into
|
||||
the new key. The data length on the new key will have been updated and
|
||||
the quota adjusted already.
|
||||
provided. It is called to copy the payload attached to the source into the
|
||||
new key. The data length on the new key will have been updated and the
|
||||
quota adjusted already.
|
||||
|
||||
This method will be called with the source key's semaphore read-locked to
|
||||
prevent its payload from being changed. It is safe to sleep here.
|
||||
prevent its payload from being changed, thus RCU constraints need not be
|
||||
applied to the source key.
|
||||
|
||||
This method does not have to lock the destination key in order to attach a
|
||||
payload. The fact that KEY_FLAG_INSTANTIATED is not set in key->flags
|
||||
prevents anything else from gaining access to the key.
|
||||
|
||||
It is safe to sleep in this method.
|
||||
|
||||
|
||||
(*) int (*update)(struct key *key, const void *data, size_t datalen);
|
||||
|
||||
If this type of key can be updated, then this method should be
|
||||
provided. It is called to update a key's payload from the blob of data
|
||||
provided.
|
||||
If this type of key can be updated, then this method should be provided.
|
||||
It is called to update a key's payload from the blob of data provided.
|
||||
|
||||
key_payload_reserve() should be called if the data length might change
|
||||
before any changes are actually made. Note that if this succeeds, the
|
||||
type is committed to changing the key because it's already been altered,
|
||||
so all memory allocation must be done first.
|
||||
before any changes are actually made. Note that if this succeeds, the type
|
||||
is committed to changing the key because it's already been altered, so all
|
||||
memory allocation must be done first.
|
||||
|
||||
key_payload_reserve() should be called with the key->lock write locked,
|
||||
and the changes to the key's attached payload should be made before the
|
||||
key is locked.
|
||||
The key will have its semaphore write-locked before this method is called,
|
||||
but this only deters other writers; any changes to the key's payload must
|
||||
be made under RCU conditions, and call_rcu() must be used to dispose of
|
||||
the old payload.
|
||||
|
||||
The key will have its semaphore write-locked before this method is
|
||||
called. Any changes to the key should be made with the key's rwlock
|
||||
write-locked also. It is safe to sleep here.
|
||||
key_payload_reserve() should be called before the changes are made, but
|
||||
after all allocations and other potentially failing function calls are
|
||||
made.
|
||||
|
||||
It is safe to sleep in this method.
|
||||
|
||||
|
||||
(*) int (*match)(const struct key *key, const void *desc);
|
||||
|
@ -782,12 +870,12 @@ The structure has a number of fields, some of which are mandatory:
|
|||
|
||||
(*) void (*destroy)(struct key *key);
|
||||
|
||||
This method is optional. It is called to discard the payload data on a
|
||||
key when it is being destroyed.
|
||||
This method is optional. It is called to discard the payload data on a key
|
||||
when it is being destroyed.
|
||||
|
||||
This method does not need to lock the key; it can consider the key as
|
||||
being inaccessible. Note that the key's type may have changed before this
|
||||
function is called.
|
||||
This method does not need to lock the key to access the payload; it can
|
||||
consider the key as being inaccessible at this time. Note that the key's
|
||||
type may have been changed before this function is called.
|
||||
|
||||
It is not safe to sleep in this method; the caller may hold spinlocks.
|
||||
|
||||
|
@ -797,26 +885,31 @@ The structure has a number of fields, some of which are mandatory:
|
|||
This method is optional. It is called during /proc/keys reading to
|
||||
summarise a key's description and payload in text form.
|
||||
|
||||
This method will be called with the key's rwlock read-locked. This will
|
||||
prevent the key's payload and state changing; also the description should
|
||||
not change. This also means it is not safe to sleep in this method.
|
||||
This method will be called with the RCU read lock held. rcu_dereference()
|
||||
should be used to read the payload pointer if the payload is to be
|
||||
accessed. key->datalen cannot be trusted to stay consistent with the
|
||||
contents of the payload.
|
||||
|
||||
The description will not change, though the key's state may.
|
||||
|
||||
It is not safe to sleep in this method; the RCU read lock is held by the
|
||||
caller.
|
||||
|
||||
|
||||
(*) long (*read)(const struct key *key, char __user *buffer, size_t buflen);
|
||||
|
||||
This method is optional. It is called by KEYCTL_READ to translate the
|
||||
key's payload into something a blob of data for userspace to deal
|
||||
with. Ideally, the blob should be in the same format as that passed in to
|
||||
the instantiate and update methods.
|
||||
key's payload into something a blob of data for userspace to deal with.
|
||||
Ideally, the blob should be in the same format as that passed in to the
|
||||
instantiate and update methods.
|
||||
|
||||
If successful, the blob size that could be produced should be returned
|
||||
rather than the size copied.
|
||||
|
||||
This method will be called with the key's semaphore read-locked. This
|
||||
will prevent the key's payload changing. It is not necessary to also
|
||||
read-lock key->lock when accessing the key's payload. It is safe to sleep
|
||||
in this method, such as might happen when the userspace buffer is
|
||||
accessed.
|
||||
This method will be called with the key's semaphore read-locked. This will
|
||||
prevent the key's payload changing. It is not necessary to use RCU locking
|
||||
when accessing the key's payload. It is safe to sleep in this method, such
|
||||
as might happen when the userspace buffer is accessed.
|
||||
|
||||
|
||||
============================
|
||||
|
@ -853,8 +946,8 @@ If it returns with the key remaining in the unconstructed state, the key will
|
|||
be marked as being negative, it will be added to the session keyring, and an
|
||||
error will be returned to the key requestor.
|
||||
|
||||
Supplementary information may be provided from whoever or whatever invoked
|
||||
this service. This will be passed as the <callout_info> parameter. If no such
|
||||
Supplementary information may be provided from whoever or whatever invoked this
|
||||
service. This will be passed as the <callout_info> parameter. If no such
|
||||
information was made available, then "-" will be passed as this parameter
|
||||
instead.
|
||||
|
||||
|
|
|
@ -114,9 +114,7 @@ tuntap.txt
|
|||
vortex.txt
|
||||
- info on using 3Com Vortex (3c590, 3c592, 3c595, 3c597) Ethernet cards.
|
||||
wan-router.txt
|
||||
- Wan router documentation
|
||||
wanpipe.txt
|
||||
- WANPIPE(tm) Multiprotocol WAN Driver for Linux WAN Router
|
||||
- WAN router documentation
|
||||
wavelan.txt
|
||||
- AT&T GIS (nee NCR) WaveLAN card: An Ethernet-like radio transceiver
|
||||
x25.txt
|
||||
|
|
|
@ -1,21 +1,21 @@
|
|||
Generic HDLC layer
|
||||
Krzysztof Halasa <khc@pm.waw.pl>
|
||||
January, 2003
|
||||
|
||||
|
||||
Generic HDLC layer currently supports:
|
||||
- Frame Relay (ANSI, CCITT and no LMI), with ARP support (no InARP).
|
||||
Normal (routed) and Ethernet-bridged (Ethernet device emulation)
|
||||
interfaces can share a single PVC.
|
||||
- raw HDLC - either IP (IPv4) interface or Ethernet device emulation.
|
||||
- Cisco HDLC,
|
||||
- PPP (uses syncppp.c),
|
||||
- X.25 (uses X.25 routines).
|
||||
1. Frame Relay (ANSI, CCITT, Cisco and no LMI).
|
||||
- Normal (routed) and Ethernet-bridged (Ethernet device emulation)
|
||||
interfaces can share a single PVC.
|
||||
- ARP support (no InARP support in the kernel - there is an
|
||||
experimental InARP user-space daemon available on:
|
||||
http://www.kernel.org/pub/linux/utils/net/hdlc/).
|
||||
2. raw HDLC - either IP (IPv4) interface or Ethernet device emulation.
|
||||
3. Cisco HDLC.
|
||||
4. PPP (uses syncppp.c).
|
||||
5. X.25 (uses X.25 routines).
|
||||
|
||||
There are hardware drivers for the following cards:
|
||||
- C101 by Moxa Technologies Co., Ltd.
|
||||
- RISCom/N2 by SDL Communications Inc.
|
||||
- and others, some not in the official kernel.
|
||||
Generic HDLC is a protocol driver only - it needs a low-level driver
|
||||
for your particular hardware.
|
||||
|
||||
Ethernet device emulation (using HDLC or Frame-Relay PVC) is compatible
|
||||
with IEEE 802.1Q (VLANs) and 802.1D (Ethernet bridging).
|
||||
|
@ -24,7 +24,7 @@ with IEEE 802.1Q (VLANs) and 802.1D (Ethernet bridging).
|
|||
Make sure the hdlc.o and the hardware driver are loaded. It should
|
||||
create a number of "hdlc" (hdlc0 etc) network devices, one for each
|
||||
WAN port. You'll need the "sethdlc" utility, get it from:
|
||||
http://hq.pm.waw.pl/hdlc/
|
||||
http://www.kernel.org/pub/linux/utils/net/hdlc/
|
||||
|
||||
Compile sethdlc.c utility:
|
||||
gcc -O2 -Wall -o sethdlc sethdlc.c
|
||||
|
@ -52,12 +52,12 @@ Setting interface:
|
|||
* v35 | rs232 | x21 | t1 | e1 - sets physical interface for a given port
|
||||
if the card has software-selectable interfaces
|
||||
loopback - activate hardware loopback (for testing only)
|
||||
* clock ext - external clock (uses DTE RX and TX clock)
|
||||
* clock int - internal clock (provides clock signal on DCE clock output)
|
||||
* clock txint - TX internal, RX external (provides TX clock on DCE output)
|
||||
* clock txfromrx - TX clock derived from RX clock (TX clock on DCE output)
|
||||
* rate - sets clock rate in bps (not required for external clock or
|
||||
for txfromrx)
|
||||
* clock ext - both RX clock and TX clock external
|
||||
* clock int - both RX clock and TX clock internal
|
||||
* clock txint - RX clock external, TX clock internal
|
||||
* clock txfromrx - RX clock external, TX clock derived from RX clock
|
||||
* rate - sets clock rate in bps (for "int" or "txint" clock only)
|
||||
|
||||
|
||||
Setting protocol:
|
||||
|
||||
|
@ -79,7 +79,7 @@ Setting protocol:
|
|||
* x25 - sets X.25 mode
|
||||
|
||||
* fr - Frame Relay mode
|
||||
lmi ansi / ccitt / none - LMI (link management) type
|
||||
lmi ansi / ccitt / cisco / none - LMI (link management) type
|
||||
dce - Frame Relay DCE (network) side LMI instead of default DTE (user).
|
||||
It has nothing to do with clocks!
|
||||
t391 - link integrity verification polling timer (in seconds) - user
|
||||
|
@ -119,13 +119,14 @@ or
|
|||
|
||||
|
||||
|
||||
If you have a problem with N2 or C101 card, you can issue the "private"
|
||||
command to see port's packet descriptor rings (in kernel logs):
|
||||
If you have a problem with N2, C101 or PLX200SYN card, you can issue the
|
||||
"private" command to see port's packet descriptor rings (in kernel logs):
|
||||
|
||||
sethdlc hdlc0 private
|
||||
|
||||
The hardware driver has to be build with CONFIG_HDLC_DEBUG_RINGS.
|
||||
The hardware driver has to be build with #define DEBUG_RINGS.
|
||||
Attaching this info to bug reports would be helpful. Anyway, let me know
|
||||
if you have problems using this.
|
||||
|
||||
For patches and other info look at http://hq.pm.waw.pl/hdlc/
|
||||
For patches and other info look at:
|
||||
<http://www.kernel.org/pub/linux/utils/net/hdlc/>.
|
||||
|
|
|
@ -304,57 +304,6 @@ tcp_low_latency - BOOLEAN
|
|||
changed would be a Beowulf compute cluster.
|
||||
Default: 0
|
||||
|
||||
tcp_westwood - BOOLEAN
|
||||
Enable TCP Westwood+ congestion control algorithm.
|
||||
TCP Westwood+ is a sender-side only modification of the TCP Reno
|
||||
protocol stack that optimizes the performance of TCP congestion
|
||||
control. It is based on end-to-end bandwidth estimation to set
|
||||
congestion window and slow start threshold after a congestion
|
||||
episode. Using this estimation, TCP Westwood+ adaptively sets a
|
||||
slow start threshold and a congestion window which takes into
|
||||
account the bandwidth used at the time congestion is experienced.
|
||||
TCP Westwood+ significantly increases fairness wrt TCP Reno in
|
||||
wired networks and throughput over wireless links.
|
||||
Default: 0
|
||||
|
||||
tcp_vegas_cong_avoid - BOOLEAN
|
||||
Enable TCP Vegas congestion avoidance algorithm.
|
||||
TCP Vegas is a sender-side only change to TCP that anticipates
|
||||
the onset of congestion by estimating the bandwidth. TCP Vegas
|
||||
adjusts the sending rate by modifying the congestion
|
||||
window. TCP Vegas should provide less packet loss, but it is
|
||||
not as aggressive as TCP Reno.
|
||||
Default:0
|
||||
|
||||
tcp_bic - BOOLEAN
|
||||
Enable BIC TCP congestion control algorithm.
|
||||
BIC-TCP is a sender-side only change that ensures a linear RTT
|
||||
fairness under large windows while offering both scalability and
|
||||
bounded TCP-friendliness. The protocol combines two schemes
|
||||
called additive increase and binary search increase. When the
|
||||
congestion window is large, additive increase with a large
|
||||
increment ensures linear RTT fairness as well as good
|
||||
scalability. Under small congestion windows, binary search
|
||||
increase provides TCP friendliness.
|
||||
Default: 0
|
||||
|
||||
tcp_bic_low_window - INTEGER
|
||||
Sets the threshold window (in packets) where BIC TCP starts to
|
||||
adjust the congestion window. Below this threshold BIC TCP behaves
|
||||
the same as the default TCP Reno.
|
||||
Default: 14
|
||||
|
||||
tcp_bic_fast_convergence - BOOLEAN
|
||||
Forces BIC TCP to more quickly respond to changes in congestion
|
||||
window. Allows two flows sharing the same connection to converge
|
||||
more rapidly.
|
||||
Default: 1
|
||||
|
||||
tcp_default_win_scale - INTEGER
|
||||
Sets the minimum window scale TCP will negotiate for on all
|
||||
conections.
|
||||
Default: 7
|
||||
|
||||
tcp_tso_win_divisor - INTEGER
|
||||
This allows control over what percentage of the congestion window
|
||||
can be consumed by a single TSO frame.
|
||||
|
@ -368,6 +317,11 @@ tcp_frto - BOOLEAN
|
|||
where packet loss is typically due to random radio interference
|
||||
rather than intermediate router congestion.
|
||||
|
||||
tcp_congestion_control - STRING
|
||||
Set the congestion control algorithm to be used for new
|
||||
connections. The algorithm "reno" is always available, but
|
||||
additional choices may be available based on kernel configuration.
|
||||
|
||||
somaxconn - INTEGER
|
||||
Limit of socket listen() backlog, known in userspace as SOMAXCONN.
|
||||
Defaults to 128. See also tcp_max_syn_backlog for additional tuning
|
||||
|
|
|
@ -47,7 +47,6 @@ ni52 <------------------ Buggy ------------------>
|
|||
ni65 YES YES YES Software(#)
|
||||
seeq NO NO NO N/A
|
||||
sgiseek <------------------ Buggy ------------------>
|
||||
sk_g16 NO NO YES N/A
|
||||
smc-ultra YES YES YES Hardware
|
||||
sunlance YES YES YES Hardware
|
||||
tulip YES YES YES Hardware
|
||||
|
|
|
@ -284,9 +284,6 @@ ppp.c:
|
|||
seeq8005.c: *Not modularized*
|
||||
(Probes ports: 0x300, 0x320, 0x340, 0x360)
|
||||
|
||||
sk_g16.c: *Not modularized*
|
||||
(Probes ports: 0x100, 0x180, 0x208, 0x220m 0x288, 0x320, 0x328, 0x390)
|
||||
|
||||
skeleton.c: *Skeleton*
|
||||
|
||||
slhc.c:
|
||||
|
|
|
@ -1,5 +1,72 @@
|
|||
How the new TCP output machine [nyi] works.
|
||||
TCP protocol
|
||||
============
|
||||
|
||||
Last updated: 21 June 2005
|
||||
|
||||
Contents
|
||||
========
|
||||
|
||||
- Congestion control
|
||||
- How the new TCP output machine [nyi] works
|
||||
|
||||
Congestion control
|
||||
==================
|
||||
|
||||
The following variables are used in the tcp_sock for congestion control:
|
||||
snd_cwnd The size of the congestion window
|
||||
snd_ssthresh Slow start threshold. We are in slow start if
|
||||
snd_cwnd is less than this.
|
||||
snd_cwnd_cnt A counter used to slow down the rate of increase
|
||||
once we exceed slow start threshold.
|
||||
snd_cwnd_clamp This is the maximum size that snd_cwnd can grow to.
|
||||
snd_cwnd_stamp Timestamp for when congestion window last validated.
|
||||
snd_cwnd_used Used as a highwater mark for how much of the
|
||||
congestion window is in use. It is used to adjust
|
||||
snd_cwnd down when the link is limited by the
|
||||
application rather than the network.
|
||||
|
||||
As of 2.6.13, Linux supports pluggable congestion control algorithms.
|
||||
A congestion control mechanism can be registered through functions in
|
||||
tcp_cong.c. The functions used by the congestion control mechanism are
|
||||
registered via passing a tcp_congestion_ops struct to
|
||||
tcp_register_congestion_control. As a minimum name, ssthresh,
|
||||
cong_avoid, min_cwnd must be valid.
|
||||
|
||||
Private data for a congestion control mechanism is stored in tp->ca_priv.
|
||||
tcp_ca(tp) returns a pointer to this space. This is preallocated space - it
|
||||
is important to check the size of your private data will fit this space, or
|
||||
alternatively space could be allocated elsewhere and a pointer to it could
|
||||
be stored here.
|
||||
|
||||
There are three kinds of congestion control algorithms currently: The
|
||||
simplest ones are derived from TCP reno (highspeed, scalable) and just
|
||||
provide an alternative the congestion window calculation. More complex
|
||||
ones like BIC try to look at other events to provide better
|
||||
heuristics. There are also round trip time based algorithms like
|
||||
Vegas and Westwood+.
|
||||
|
||||
Good TCP congestion control is a complex problem because the algorithm
|
||||
needs to maintain fairness and performance. Please review current
|
||||
research and RFC's before developing new modules.
|
||||
|
||||
The method that is used to determine which congestion control mechanism is
|
||||
determined by the setting of the sysctl net.ipv4.tcp_congestion_control.
|
||||
The default congestion control will be the last one registered (LIFO);
|
||||
so if you built everything as modules. the default will be reno. If you
|
||||
build with the default's from Kconfig, then BIC will be builtin (not a module)
|
||||
and it will end up the default.
|
||||
|
||||
If you really want a particular default value then you will need
|
||||
to set it with the sysctl. If you use a sysctl, the module will be autoloaded
|
||||
if needed and you will get the expected protocol. If you ask for an
|
||||
unknown congestion method, then the sysctl attempt will fail.
|
||||
|
||||
If you remove a tcp congestion control module, then you will get the next
|
||||
available one. Since reno can not be built as a module, and can not be
|
||||
deleted, it will always be available.
|
||||
|
||||
How the new TCP output machine [nyi] works.
|
||||
===========================================
|
||||
|
||||
Data is kept on a single queue. The skb->users flag tells us if the frame is
|
||||
one that has been queued already. To add a frame we throw it on the end. Ack
|
||||
|
|
|
@ -12,7 +12,7 @@ Don is no longer the prime maintainer of this version of the driver.
|
|||
Please report problems to one or more of:
|
||||
|
||||
Andrew Morton <andrewm@uow.edu.au>
|
||||
Netdev mailing list <netdev@oss.sgi.com>
|
||||
Netdev mailing list <netdev@vger.kernel.org>
|
||||
Linux kernel mailing list <linux-kernel@vger.kernel.org>
|
||||
|
||||
Please note the 'Reporting and Diagnosing Problems' section at the end
|
||||
|
|
|
@ -1,622 +0,0 @@
|
|||
------------------------------------------------------------------------------
|
||||
Linux WAN Router Utilities Package
|
||||
------------------------------------------------------------------------------
|
||||
Version 2.2.1
|
||||
Mar 28, 2001
|
||||
Author: Nenad Corbic <ncorbic@sangoma.com>
|
||||
Copyright (c) 1995-2001 Sangoma Technologies Inc.
|
||||
------------------------------------------------------------------------------
|
||||
|
||||
INTRODUCTION
|
||||
|
||||
Wide Area Networks (WANs) are used to interconnect Local Area Networks (LANs)
|
||||
and/or stand-alone hosts over vast distances with data transfer rates
|
||||
significantly higher than those achievable with commonly used dial-up
|
||||
connections.
|
||||
|
||||
Usually an external device called `WAN router' sitting on your local network
|
||||
or connected to your machine's serial port provides physical connection to
|
||||
WAN. Although router's job may be as simple as taking your local network
|
||||
traffic, converting it to WAN format and piping it through the WAN link, these
|
||||
devices are notoriously expensive, with prices as much as 2 - 5 times higher
|
||||
then the price of a typical PC box.
|
||||
|
||||
Alternatively, considering robustness and multitasking capabilities of Linux,
|
||||
an internal router can be built (most routers use some sort of stripped down
|
||||
Unix-like operating system anyway). With a number of relatively inexpensive WAN
|
||||
interface cards available on the market, a perfectly usable router can be
|
||||
built for less than half a price of an external router. Yet a Linux box
|
||||
acting as a router can still be used for other purposes, such as fire-walling,
|
||||
running FTP, WWW or DNS server, etc.
|
||||
|
||||
This kernel module introduces the notion of a WAN Link Driver (WLD) to Linux
|
||||
operating system and provides generic hardware-independent services for such
|
||||
drivers. Why can existing Linux network device interface not be used for
|
||||
this purpose? Well, it can. However, there are a few key differences between
|
||||
a typical network interface (e.g. Ethernet) and a WAN link.
|
||||
|
||||
Many WAN protocols, such as X.25 and frame relay, allow for multiple logical
|
||||
connections (known as `virtual circuits' in X.25 terminology) over a single
|
||||
physical link. Each such virtual circuit may (and almost always does) lead
|
||||
to a different geographical location and, therefore, different network. As a
|
||||
result, it is the virtual circuit, not the physical link, that represents a
|
||||
route and, therefore, a network interface in Linux terms.
|
||||
|
||||
To further complicate things, virtual circuits are usually volatile in nature
|
||||
(excluding so called `permanent' virtual circuits or PVCs). With almost no
|
||||
time required to set up and tear down a virtual circuit, it is highly desirable
|
||||
to implement on-demand connections in order to minimize network charges. So
|
||||
unlike a typical network driver, the WAN driver must be able to handle multiple
|
||||
network interfaces and cope as multiple virtual circuits come into existence
|
||||
and go away dynamically.
|
||||
|
||||
Last, but not least, WAN configuration is much more complex than that of say
|
||||
Ethernet and may well amount to several dozens of parameters. Some of them
|
||||
are "link-wide" while others are virtual circuit-specific. The same holds
|
||||
true for WAN statistics which is by far more extensive and extremely useful
|
||||
when troubleshooting WAN connections. Extending the ifconfig utility to suit
|
||||
these needs may be possible, but does not seem quite reasonable. Therefore, a
|
||||
WAN configuration utility and corresponding application programmer's interface
|
||||
is needed for this purpose.
|
||||
|
||||
Most of these problems are taken care of by this module. Its goal is to
|
||||
provide a user with more-or-less standard look and feel for all WAN devices and
|
||||
assist a WAN device driver writer by providing common services, such as:
|
||||
|
||||
o User-level interface via /proc file system
|
||||
o Centralized configuration
|
||||
o Device management (setup, shutdown, etc.)
|
||||
o Network interface management (dynamic creation/destruction)
|
||||
o Protocol encapsulation/decapsulation
|
||||
|
||||
To ba able to use the Linux WAN Router you will also need a WAN Tools package
|
||||
available from
|
||||
|
||||
ftp.sangoma.com/pub/linux/current_wanpipe/wanpipe-X.Y.Z.tgz
|
||||
|
||||
where vX.Y.Z represent the wanpipe version number.
|
||||
|
||||
For technical questions and/or comments please e-mail to ncorbic@sangoma.com.
|
||||
For general inquiries please contact Sangoma Technologies Inc. by
|
||||
|
||||
Hotline: 1-800-388-2475 (USA and Canada, toll free)
|
||||
Phone: (905) 474-1990 ext: 106
|
||||
Fax: (905) 474-9223
|
||||
E-mail: dm@sangoma.com (David Mandelstam)
|
||||
WWW: http://www.sangoma.com
|
||||
|
||||
|
||||
INSTALLATION
|
||||
|
||||
Please read the WanpipeForLinux.pdf manual on how to
|
||||
install the WANPIPE tools and drivers properly.
|
||||
|
||||
|
||||
After installing wanpipe package: /usr/local/wanrouter/doc.
|
||||
On the ftp.sangoma.com : /linux/current_wanpipe/doc
|
||||
|
||||
|
||||
COPYRIGHT AND LICENSING INFORMATION
|
||||
|
||||
This program 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, or (at your option) any later version.
|
||||
|
||||
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.
|
||||
|
||||
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., 675 Mass
|
||||
Ave, Cambridge, MA 02139, USA.
|
||||
|
||||
|
||||
|
||||
ACKNOWLEDGEMENTS
|
||||
|
||||
This product is based on the WANPIPE(tm) Multiprotocol WAN Router developed
|
||||
by Sangoma Technologies Inc. for Linux 2.0.x and 2.2.x. Success of the WANPIPE
|
||||
together with the next major release of Linux kernel in summer 1996 commanded
|
||||
adequate changes to the WANPIPE code to take full advantage of new Linux
|
||||
features.
|
||||
|
||||
Instead of continuing developing proprietary interface tied to Sangoma WAN
|
||||
cards, we decided to separate all hardware-independent code into a separate
|
||||
module and defined two levels of interfaces - one for user-level applications
|
||||
and another for kernel-level WAN drivers. WANPIPE is now implemented as a
|
||||
WAN driver compliant with the WAN Link Driver interface. Also a general
|
||||
purpose WAN configuration utility and a set of shell scripts was developed to
|
||||
support WAN router at the user level.
|
||||
|
||||
Many useful ideas concerning hardware-independent interface implementation
|
||||
were given by Mike McLagan <mike.mclagan@linux.org> and his implementation
|
||||
of the Frame Relay router and drivers for Sangoma cards (dlci/sdla).
|
||||
|
||||
With the new implementation of the APIs being incorporated into the WANPIPE,
|
||||
a special thank goes to Alan Cox in providing insight into BSD sockets.
|
||||
|
||||
Special thanks to all the WANPIPE users who performed field-testing, reported
|
||||
bugs and made valuable comments and suggestions that help us to improve this
|
||||
product.
|
||||
|
||||
|
||||
|
||||
NEW IN THIS RELEASE
|
||||
|
||||
o Updated the WANCFG utility
|
||||
Calls the pppconfig to configure the PPPD
|
||||
for async connections.
|
||||
|
||||
o Added the PPPCONFIG utility
|
||||
Used to configure the PPPD dameon for the
|
||||
WANPIPE Async PPP and standard serial port.
|
||||
The wancfg calls the pppconfig to configure
|
||||
the pppd.
|
||||
|
||||
o Fixed the PCI autodetect feature.
|
||||
The SLOT 0 was used as an autodetect option
|
||||
however, some high end PC's slot numbers start
|
||||
from 0.
|
||||
|
||||
o This release has been tested with the new backupd
|
||||
daemon release.
|
||||
|
||||
|
||||
PRODUCT COMPONENTS AND RELATED FILES
|
||||
|
||||
/etc: (or user defined)
|
||||
wanpipe1.conf default router configuration file
|
||||
|
||||
/lib/modules/X.Y.Z/misc:
|
||||
wanrouter.o router kernel loadable module
|
||||
af_wanpipe.o wanpipe api socket module
|
||||
|
||||
/lib/modules/X.Y.Z/net:
|
||||
sdladrv.o Sangoma SDLA support module
|
||||
wanpipe.o Sangoma WANPIPE(tm) driver module
|
||||
|
||||
/proc/net/wanrouter
|
||||
Config reads current router configuration
|
||||
Status reads current router status
|
||||
{name} reads WAN driver statistics
|
||||
|
||||
/usr/sbin:
|
||||
wanrouter wanrouter start-up script
|
||||
wanconfig wanrouter configuration utility
|
||||
sdladump WANPIPE adapter memory dump utility
|
||||
fpipemon Monitor for Frame Relay
|
||||
cpipemon Monitor for Cisco HDLC
|
||||
ppipemon Monitor for PPP
|
||||
xpipemon Monitor for X25
|
||||
wpkbdmon WANPIPE keyboard led monitor/debugger
|
||||
|
||||
/usr/local/wanrouter:
|
||||
README this file
|
||||
COPYING GNU General Public License
|
||||
Setup installation script
|
||||
Filelist distribution definition file
|
||||
wanrouter.rc meta-configuration file
|
||||
(used by the Setup and wanrouter script)
|
||||
|
||||
/usr/local/wanrouter/doc:
|
||||
wanpipeForLinux.pdf WAN Router User's Manual
|
||||
|
||||
/usr/local/wanrouter/patches:
|
||||
wanrouter-v2213.gz patch for Linux kernels 2.2.11 up to 2.2.13.
|
||||
wanrouter-v2214.gz patch for Linux kernel 2.2.14.
|
||||
wanrouter-v2215.gz patch for Linux kernels 2.2.15 to 2.2.17.
|
||||
wanrouter-v2218.gz patch for Linux kernels 2.2.18 and up.
|
||||
wanrouter-v240.gz patch for Linux kernel 2.4.0.
|
||||
wanrouter-v242.gz patch for Linux kernel 2.4.2 and up.
|
||||
wanrouter-v2034.gz patch for Linux kernel 2.0.34
|
||||
wanrouter-v2036.gz patch for Linux kernel 2.0.36 and up.
|
||||
|
||||
/usr/local/wanrouter/patches/kdrivers:
|
||||
Sources of the latest WANPIPE device drivers.
|
||||
These are used to UPGRADE the linux kernel to the newest
|
||||
version if the kernel source has already been pathced with
|
||||
WANPIPE drivers.
|
||||
|
||||
/usr/local/wanrouter/samples:
|
||||
interface sample interface configuration file
|
||||
wanpipe1.cpri CHDLC primary port
|
||||
wanpipe2.csec CHDLC secondary port
|
||||
wanpipe1.fr Frame Relay protocol
|
||||
wanpipe1.ppp PPP protocol )
|
||||
wanpipe1.asy CHDLC ASYNC protocol
|
||||
wanpipe1.x25 X25 protocol
|
||||
wanpipe1.stty Sync TTY driver (Used by Kernel PPPD daemon)
|
||||
wanpipe1.atty Async TTY driver (Used by Kernel PPPD daemon)
|
||||
wanrouter.rc sample meta-configuration file
|
||||
|
||||
/usr/local/wanrouter/util:
|
||||
* wan-tools utilities source code
|
||||
|
||||
/usr/local/wanrouter/api/x25:
|
||||
* x25 api sample programs.
|
||||
/usr/local/wanrouter/api/chdlc:
|
||||
* chdlc api sample programs.
|
||||
/usr/local/wanrouter/api/fr:
|
||||
* fr api sample programs.
|
||||
/usr/local/wanrouter/config/wancfg:
|
||||
wancfg WANPIPE GUI configuration program.
|
||||
Creates wanpipe#.conf files.
|
||||
/usr/local/wanrouter/config/cfgft1:
|
||||
cfgft1 GUI CSU/DSU configuration program.
|
||||
|
||||
/usr/include/linux:
|
||||
wanrouter.h router API definitions
|
||||
wanpipe.h WANPIPE API definitions
|
||||
sdladrv.h SDLA support module API definitions
|
||||
sdlasfm.h SDLA firmware module definitions
|
||||
if_wanpipe.h WANPIPE Socket definitions
|
||||
if_wanpipe_common.h WANPIPE Socket/Driver common definitions.
|
||||
sdlapci.h WANPIPE PCI definitions
|
||||
|
||||
|
||||
/usr/src/linux/net/wanrouter:
|
||||
* wanrouter source code
|
||||
|
||||
/var/log:
|
||||
wanrouter wanrouter start-up log (created by the Setup script)
|
||||
|
||||
/var/lock: (or /var/lock/subsys for RedHat)
|
||||
wanrouter wanrouter lock file (created by the Setup script)
|
||||
|
||||
/usr/local/wanrouter/firmware:
|
||||
fr514.sfm Frame relay firmware for Sangoma S508/S514 card
|
||||
cdual514.sfm Dual Port Cisco HDLC firmware for Sangoma S508/S514 card
|
||||
ppp514.sfm PPP Firmware for Sangoma S508 and S514 cards
|
||||
x25_508.sfm X25 Firmware for Sangoma S508 card.
|
||||
|
||||
|
||||
REVISION HISTORY
|
||||
|
||||
1.0.0 December 31, 1996 Initial version
|
||||
|
||||
1.0.1 January 30, 1997 Status and statistics can be read via /proc
|
||||
filesystem entries.
|
||||
|
||||
1.0.2 April 30, 1997 Added UDP management via monitors.
|
||||
|
||||
1.0.3 June 3, 1997 UDP management for multiple boards using Frame
|
||||
Relay and PPP
|
||||
Enabled continuous transmission of Configure
|
||||
Request Packet for PPP (for 508 only)
|
||||
Connection Timeout for PPP changed from 900 to 0
|
||||
Flow Control Problem fixed for Frame Relay
|
||||
|
||||
1.0.4 July 10, 1997 S508/FT1 monitoring capability in fpipemon and
|
||||
ppipemon utilities.
|
||||
Configurable TTL for UDP packets.
|
||||
Multicast and Broadcast IP source addresses are
|
||||
silently discarded.
|
||||
|
||||
1.0.5 July 28, 1997 Configurable T391,T392,N391,N392,N393 for Frame
|
||||
Relay in router.conf.
|
||||
Configurable Memory Address through router.conf
|
||||
for Frame Relay, PPP and X.25. (commenting this
|
||||
out enables auto-detection).
|
||||
Fixed freeing up received buffers using kfree()
|
||||
for Frame Relay and X.25.
|
||||
Protect sdla_peek() by calling save_flags(),
|
||||
cli() and restore_flags().
|
||||
Changed number of Trace elements from 32 to 20
|
||||
Added DLCI specific data monitoring in FPIPEMON.
|
||||
2.0.0 Nov 07, 1997 Implemented protection of RACE conditions by
|
||||
critical flags for FRAME RELAY and PPP.
|
||||
DLCI List interrupt mode implemented.
|
||||
IPX support in FRAME RELAY and PPP.
|
||||
IPX Server Support (MARS)
|
||||
More driver specific stats included in FPIPEMON
|
||||
and PIPEMON.
|
||||
|
||||
2.0.1 Nov 28, 1997 Bug Fixes for version 2.0.0.
|
||||
Protection of "enable_irq()" while
|
||||
"disable_irq()" has been enabled from any other
|
||||
routine (for Frame Relay, PPP and X25).
|
||||
Added additional Stats for Fpipemon and Ppipemon
|
||||
Improved Load Sharing for multiple boards
|
||||
|
||||
2.0.2 Dec 09, 1997 Support for PAP and CHAP for ppp has been
|
||||
implemented.
|
||||
|
||||
2.0.3 Aug 15, 1998 New release supporting Cisco HDLC, CIR for Frame
|
||||
relay, Dynamic IP assignment for PPP and Inverse
|
||||
Arp support for Frame-relay. Man Pages are
|
||||
included for better support and a new utility
|
||||
for configuring FT1 cards.
|
||||
|
||||
2.0.4 Dec 09, 1998 Dual Port support for Cisco HDLC.
|
||||
Support for HDLC (LAPB) API.
|
||||
Supports BiSync Streaming code for S502E
|
||||
and S503 cards.
|
||||
Support for Streaming HDLC API.
|
||||
Provides a BSD socket interface for
|
||||
creating applications using BiSync
|
||||
streaming.
|
||||
|
||||
2.0.5 Aug 04, 1999 CHDLC initializatin bug fix.
|
||||
PPP interrupt driven driver:
|
||||
Fix to the PPP line hangup problem.
|
||||
New PPP firmware
|
||||
Added comments to the startup SYSTEM ERROR messages
|
||||
Xpipemon debugging application for the X25 protocol
|
||||
New USER_MANUAL.txt
|
||||
Fixed the odd boundary 4byte writes to the board.
|
||||
BiSync Streaming code has been taken out.
|
||||
Available as a patch.
|
||||
Streaming HDLC API has been taken out.
|
||||
Available as a patch.
|
||||
|
||||
2.0.6 Aug 17, 1999 Increased debugging in statup scripts
|
||||
Fixed insallation bugs from 2.0.5
|
||||
Kernel patch works for both 2.2.10 and 2.2.11 kernels.
|
||||
There is no functional difference between the two packages
|
||||
|
||||
2.0.7 Aug 26, 1999 o Merged X25API code into WANPIPE.
|
||||
o Fixed a memeory leak for X25API
|
||||
o Updated the X25API code for 2.2.X kernels.
|
||||
o Improved NEM handling.
|
||||
|
||||
2.1.0 Oct 25, 1999 o New code for S514 PCI Card
|
||||
o New CHDLC and Frame Relay drivers
|
||||
o PPP and X25 are not supported in this release
|
||||
|
||||
2.1.1 Nov 30, 1999 o PPP support for S514 PCI Cards
|
||||
|
||||
2.1.3 Apr 06, 2000 o Socket based x25api
|
||||
o Socket based chdlc api
|
||||
o Socket based fr api
|
||||
o Dual Port Receive only CHDLC support.
|
||||
o Asynchronous CHDLC support (Secondary Port)
|
||||
o cfgft1 GUI csu/dsu configurator
|
||||
o wancfg GUI configuration file
|
||||
configurator.
|
||||
o Architectual directory changes.
|
||||
|
||||
beta-2.1.4 Jul 2000 o Dynamic interface configuration:
|
||||
Network interfaces reflect the state
|
||||
of protocol layer. If the protocol becomes
|
||||
disconnected, driver will bring down
|
||||
the interface. Once the protocol reconnects
|
||||
the interface will be brought up.
|
||||
|
||||
Note: This option is turned off by default.
|
||||
|
||||
o Dynamic wanrouter setup using 'wanconfig':
|
||||
wanconfig utility can be used to
|
||||
shutdown,restart,start or reconfigure
|
||||
a virtual circuit dynamically.
|
||||
|
||||
Frame Relay: Each DLCI can be:
|
||||
created,stopped,restarted and reconfigured
|
||||
dynamically using wanconfig.
|
||||
|
||||
ex: wanconfig card wanpipe1 dev wp1_fr16 up
|
||||
|
||||
o Wanrouter startup via command line arguments:
|
||||
wanconfig also supports wanrouter startup via command line
|
||||
arguments. Thus, there is no need to create a wanpipe#.conf
|
||||
configuration file.
|
||||
|
||||
o Socket based x25api update/bug fixes.
|
||||
Added support for LCN numbers greater than 255.
|
||||
Option to pass up modem messages.
|
||||
Provided a PCI IRQ check, so a single S514
|
||||
card is guaranteed to have a non-sharing interrupt.
|
||||
|
||||
o Fixes to the wancfg utility.
|
||||
o New FT1 debugging support via *pipemon utilities.
|
||||
o Frame Relay ARP support Enabled.
|
||||
|
||||
beta3-2.1.4 Jul 2000 o X25 M_BIT Problem fix.
|
||||
o Added the Multi-Port PPP
|
||||
Updated utilites for the Multi-Port PPP.
|
||||
|
||||
2.1.4 Aut 2000
|
||||
o In X25API:
|
||||
Maximum packet an application can send
|
||||
to the driver has been extended to 4096 bytes.
|
||||
|
||||
Fixed the x25 startup bug. Enable
|
||||
communications only after all interfaces
|
||||
come up. HIGH SVC/PVC is used to calculate
|
||||
the number of channels.
|
||||
Enable protocol only after all interfaces
|
||||
are enabled.
|
||||
|
||||
o Added an extra state to the FT1 config, kernel module.
|
||||
o Updated the pipemon debuggers.
|
||||
|
||||
o Blocked the Multi-Port PPP from running on kernels
|
||||
2.2.16 or greater, due to syncppp kernel module
|
||||
change.
|
||||
|
||||
beta1-2.1.5 Nov 15 2000
|
||||
o Fixed the MulitPort PPP Support for kernels 2.2.16 and above.
|
||||
2.2.X kernels only
|
||||
|
||||
o Secured the driver UDP debugging calls
|
||||
- All illegal netowrk debugging calls are reported to
|
||||
the log.
|
||||
- Defined a set of allowed commands, all other denied.
|
||||
|
||||
o Cpipemon
|
||||
- Added set FT1 commands to the cpipemon. Thus CSU/DSU
|
||||
configuraiton can be performed using cpipemon.
|
||||
All systems that cannot run cfgft1 GUI utility should
|
||||
use cpipemon to configure the on board CSU/DSU.
|
||||
|
||||
|
||||
o Keyboard Led Monitor/Debugger
|
||||
- A new utilty /usr/sbin/wpkbdmon uses keyboard leds
|
||||
to convey operatinal statistic information of the
|
||||
Sangoma WANPIPE cards.
|
||||
NUM_LOCK = Line State (On=connected, Off=disconnected)
|
||||
CAPS_LOCK = Tx data (On=transmitting, Off=no tx data)
|
||||
SCROLL_LOCK = Rx data (On=receiving, Off=no rx data
|
||||
|
||||
o Hardware probe on module load and dynamic device allocation
|
||||
- During WANPIPE module load, all Sangoma cards are probed
|
||||
and found information is printed in the /var/log/messages.
|
||||
- If no cards are found, the module load fails.
|
||||
- Appropriate number of devices are dynamically loaded
|
||||
based on the number of Sangoma cards found.
|
||||
|
||||
Note: The kernel configuraiton option
|
||||
CONFIG_WANPIPE_CARDS has been taken out.
|
||||
|
||||
o Fixed the Frame Relay and Chdlc network interfaces so they are
|
||||
compatible with libpcap libraries. Meaning, tcpdump, snort,
|
||||
ethereal, and all other packet sniffers and debuggers work on
|
||||
all WANPIPE netowrk interfaces.
|
||||
- Set the network interface encoding type to ARPHRD_PPP.
|
||||
This tell the sniffers that data obtained from the
|
||||
network interface is in pure IP format.
|
||||
Fix for 2.2.X kernels only.
|
||||
|
||||
o True interface encoding option for Frame Relay and CHDLC
|
||||
- The above fix sets the network interface encoding
|
||||
type to ARPHRD_PPP, however some customers use
|
||||
the encoding interface type to determine the
|
||||
protocol running. Therefore, the TURE ENCODING
|
||||
option will set the interface type back to the
|
||||
original value.
|
||||
|
||||
NOTE: If this option is used with Frame Relay and CHDLC
|
||||
libpcap library support will be broken.
|
||||
i.e. tcpdump will not work.
|
||||
Fix for 2.2.x Kernels only.
|
||||
|
||||
o Ethernet Bridgind over Frame Relay
|
||||
- The Frame Relay bridging has been developed by
|
||||
Kristian Hoffmann and Mark Wells.
|
||||
- The Linux kernel bridge is used to send ethernet
|
||||
data over the frame relay links.
|
||||
For 2.2.X Kernels only.
|
||||
|
||||
o Added extensive 2.0.X support. Most new features of
|
||||
2.1.5 for protocols Frame Relay, PPP and CHDLC are
|
||||
supported under 2.0.X kernels.
|
||||
|
||||
beta1-2.2.0 Dec 30 2000
|
||||
o Updated drivers for 2.4.X kernels.
|
||||
o Updated drivers for SMP support.
|
||||
o X25API is now able to share PCI interrupts.
|
||||
o Took out a general polling routine that was used
|
||||
only by X25API.
|
||||
o Added appropriate locks to the dynamic reconfiguration
|
||||
code.
|
||||
o Fixed a bug in the keyboard debug monitor.
|
||||
|
||||
beta2-2.2.0 Jan 8 2001
|
||||
o Patches for 2.4.0 kernel
|
||||
o Patches for 2.2.18 kernel
|
||||
o Minor updates to PPP and CHLDC drivers.
|
||||
Note: No functinal difference.
|
||||
|
||||
beta3-2.2.9 Jan 10 2001
|
||||
o I missed the 2.2.18 kernel patches in beta2-2.2.0
|
||||
release. They are included in this release.
|
||||
|
||||
Stable Release
|
||||
2.2.0 Feb 01 2001
|
||||
o Bug fix in wancfg GUI configurator.
|
||||
The edit function didn't work properly.
|
||||
|
||||
|
||||
bata1-2.2.1 Feb 09 2001
|
||||
o WANPIPE TTY Driver emulation.
|
||||
Two modes of operation Sync and Async.
|
||||
Sync: Using the PPPD daemon, kernel SyncPPP layer
|
||||
and the Wanpipe sync TTY driver: a PPP protocol
|
||||
connection can be established via Sangoma adapter, over
|
||||
a T1 leased line.
|
||||
|
||||
The 2.4.0 kernel PPP layer supports MULTILINK
|
||||
protocol, that can be used to bundle any number of Sangoma
|
||||
adapters (T1 lines) into one, under a single IP address.
|
||||
Thus, efficiently obtaining multiple T1 throughput.
|
||||
|
||||
NOTE: The remote side must also implement MULTILINK PPP
|
||||
protocol.
|
||||
|
||||
Async:Using the PPPD daemon, kernel AsyncPPP layer
|
||||
and the WANPIPE async TTY driver: a PPP protocol
|
||||
connection can be established via Sangoma adapter and
|
||||
a modem, over a telephone line.
|
||||
|
||||
Thus, the WANPIPE async TTY driver simulates a serial
|
||||
TTY driver that would normally be used to interface the
|
||||
MODEM to the linux kernel.
|
||||
|
||||
o WANPIPE PPP Backup Utility
|
||||
This utility will monitor the state of the PPP T1 line.
|
||||
In case of failure, a dial up connection will be established
|
||||
via pppd daemon, ether via a serial tty driver (serial port),
|
||||
or a WANPIPE async TTY driver (in case serial port is unavailable).
|
||||
|
||||
Furthermore, while in dial up mode, the primary PPP T1 link
|
||||
will be monitored for signs of life.
|
||||
|
||||
If the PPP T1 link comes back to life, the dial up connection
|
||||
will be shutdown and T1 line re-established.
|
||||
|
||||
|
||||
o New Setup installation script.
|
||||
Option to UPGRADE device drivers if the kernel source has
|
||||
already been patched with WANPIPE.
|
||||
|
||||
Option to COMPILE WANPIPE modules against the currently
|
||||
running kernel, thus no need for manual kernel and module
|
||||
re-compilatin.
|
||||
|
||||
o Updates and Bug Fixes to wancfg utility.
|
||||
|
||||
bata2-2.2.1 Feb 20 2001
|
||||
|
||||
o Bug fixes to the CHDLC device drivers.
|
||||
The driver had compilation problems under kernels
|
||||
2.2.14 or lower.
|
||||
|
||||
o Bug fixes to the Setup installation script.
|
||||
The device drivers compilation options didn't work
|
||||
properly.
|
||||
|
||||
o Update to the wpbackupd daemon.
|
||||
Optimized the cross-over times, between the primary
|
||||
link and the backup dialup.
|
||||
|
||||
beta3-2.2.1 Mar 02 2001
|
||||
o Patches for 2.4.2 kernel.
|
||||
|
||||
o Bug fixes to util/ make files.
|
||||
o Bug fixes to the Setup installation script.
|
||||
|
||||
o Took out the backupd support and made it into
|
||||
as separate package.
|
||||
|
||||
beta4-2.2.1 Mar 12 2001
|
||||
|
||||
o Fix to the Frame Relay Device driver.
|
||||
IPSAC sends a packet of zero length
|
||||
header to the frame relay driver. The
|
||||
driver tries to push its own 2 byte header
|
||||
into the packet, which causes the driver to
|
||||
crash.
|
||||
|
||||
o Fix the WANPIPE re-configuration code.
|
||||
Bug was found by trying to run the cfgft1 while the
|
||||
interface was already running.
|
||||
|
||||
o Updates to cfgft1.
|
||||
Writes a wanpipe#.cfgft1 configuration file
|
||||
once the CSU/DSU is configured. This file can
|
||||
holds the current CSU/DSU configuration.
|
||||
|
||||
|
||||
|
||||
>>>>>> END OF README <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
|
||||
|
||||
|
|
@ -207,27 +207,6 @@ SYSTEM_SHUTDOWN, I do not understand this one too much. probably event
|
|||
#READY_AFTER_RESUME
|
||||
#
|
||||
|
||||
Driver Detach Power Management
|
||||
|
||||
The kernel now supports the ability to place a device in a low-power
|
||||
state when it is detached from its driver, which happens when its
|
||||
module is removed.
|
||||
|
||||
Each device contains a 'detach_state' file in its sysfs directory
|
||||
which can be used to control this state. Reading from this file
|
||||
displays what the current detach state is set to. This is 0 (On) by
|
||||
default. A user may write a positive integer value to this file in the
|
||||
range of 1-4 inclusive.
|
||||
|
||||
A value of 1-3 will indicate the device should be placed in that
|
||||
low-power state, which will cause ->suspend() to be called for that
|
||||
device. A value of 4 indicates that the device should be shutdown, so
|
||||
->shutdown() will be called for that device.
|
||||
|
||||
The driver is responsible for reinitializing the device when the
|
||||
module is re-inserted during it's ->probe() (or equivalent) method.
|
||||
The driver core will not call any extra functions when binding the
|
||||
device to the driver.
|
||||
|
||||
pm_message_t meaning
|
||||
|
||||
|
|
|
@ -12,8 +12,7 @@ refrigerator. Code to do this looks like this:
|
|||
do {
|
||||
hub_events();
|
||||
wait_event_interruptible(khubd_wait, !list_empty(&hub_event_list));
|
||||
if (current->flags & PF_FREEZE)
|
||||
refrigerator(PF_FREEZE);
|
||||
try_to_freeze();
|
||||
} while (!signal_pending(current));
|
||||
|
||||
from drivers/usb/core/hub.c::hub_thread()
|
||||
|
|
|
@ -291,6 +291,44 @@ a request to enable wake events from D3, two calls should be made to
|
|||
pci_enable_wake (one for both D3hot and D3cold).
|
||||
|
||||
|
||||
A reference implementation
|
||||
-------------------------
|
||||
.suspend()
|
||||
{
|
||||
/* driver specific operations */
|
||||
|
||||
/* Disable IRQ */
|
||||
free_irq();
|
||||
/* If using MSI */
|
||||
pci_disable_msi();
|
||||
|
||||
pci_save_state();
|
||||
pci_enable_wake();
|
||||
/* Disable IO/bus master/irq router */
|
||||
pci_disable_device();
|
||||
pci_set_power_state(pci_choose_state());
|
||||
}
|
||||
|
||||
.resume()
|
||||
{
|
||||
pci_set_power_state(PCI_D0);
|
||||
pci_restore_state();
|
||||
/* device's irq possibly is changed, driver should take care */
|
||||
pci_enable_device();
|
||||
pci_set_master();
|
||||
|
||||
/* if using MSI, device's vector possibly is changed */
|
||||
pci_enable_msi();
|
||||
|
||||
request_irq();
|
||||
/* driver specific operations; */
|
||||
}
|
||||
|
||||
This is a typical implementation. Drivers can slightly change the order
|
||||
of the operations in the implementation, ignore some operations or add
|
||||
more deriver specific operations in it, but drivers should do something like
|
||||
this on the whole.
|
||||
|
||||
5. Resources
|
||||
~~~~~~~~~~~~
|
||||
|
||||
|
|
|
@ -164,11 +164,11 @@ place where the thread is safe to be frozen (no kernel semaphores
|
|||
should be held at that point and it must be safe to sleep there), and
|
||||
add:
|
||||
|
||||
if (current->flags & PF_FREEZE)
|
||||
refrigerator(PF_FREEZE);
|
||||
try_to_freeze();
|
||||
|
||||
If the thread is needed for writing the image to storage, you should
|
||||
instead set the PF_NOFREEZE process flag when creating the thread.
|
||||
instead set the PF_NOFREEZE process flag when creating the thread (and
|
||||
be very carefull).
|
||||
|
||||
|
||||
Q: What is the difference between between "platform", "shutdown" and
|
||||
|
@ -233,3 +233,81 @@ A: Try running
|
|||
cat `cat /proc/[0-9]*/maps | grep / | sed 's:.* /:/:' | sort -u` > /dev/null
|
||||
|
||||
after resume. swapoff -a; swapon -a may also be usefull.
|
||||
|
||||
Q: What happens to devices during swsusp? They seem to be resumed
|
||||
during system suspend?
|
||||
|
||||
A: That's correct. We need to resume them if we want to write image to
|
||||
disk. Whole sequence goes like
|
||||
|
||||
Suspend part
|
||||
~~~~~~~~~~~~
|
||||
running system, user asks for suspend-to-disk
|
||||
|
||||
user processes are stopped
|
||||
|
||||
suspend(PMSG_FREEZE): devices are frozen so that they don't interfere
|
||||
with state snapshot
|
||||
|
||||
state snapshot: copy of whole used memory is taken with interrupts disabled
|
||||
|
||||
resume(): devices are woken up so that we can write image to swap
|
||||
|
||||
write image to swap
|
||||
|
||||
suspend(PMSG_SUSPEND): suspend devices so that we can power off
|
||||
|
||||
turn the power off
|
||||
|
||||
Resume part
|
||||
~~~~~~~~~~~
|
||||
(is actually pretty similar)
|
||||
|
||||
running system, user asks for suspend-to-disk
|
||||
|
||||
user processes are stopped (in common case there are none, but with resume-from-initrd, noone knows)
|
||||
|
||||
read image from disk
|
||||
|
||||
suspend(PMSG_FREEZE): devices are frozen so that they don't interfere
|
||||
with image restoration
|
||||
|
||||
image restoration: rewrite memory with image
|
||||
|
||||
resume(): devices are woken up so that system can continue
|
||||
|
||||
thaw all user processes
|
||||
|
||||
Q: What is this 'Encrypt suspend image' for?
|
||||
|
||||
A: First of all: it is not a replacement for dm-crypt encrypted swap.
|
||||
It cannot protect your computer while it is suspended. Instead it does
|
||||
protect from leaking sensitive data after resume from suspend.
|
||||
|
||||
Think of the following: you suspend while an application is running
|
||||
that keeps sensitive data in memory. The application itself prevents
|
||||
the data from being swapped out. Suspend, however, must write these
|
||||
data to swap to be able to resume later on. Without suspend encryption
|
||||
your sensitive data are then stored in plaintext on disk. This means
|
||||
that after resume your sensitive data are accessible to all
|
||||
applications having direct access to the swap device which was used
|
||||
for suspend. If you don't need swap after resume these data can remain
|
||||
on disk virtually forever. Thus it can happen that your system gets
|
||||
broken in weeks later and sensitive data which you thought were
|
||||
encrypted and protected are retrieved and stolen from the swap device.
|
||||
To prevent this situation you should use 'Encrypt suspend image'.
|
||||
|
||||
During suspend a temporary key is created and this key is used to
|
||||
encrypt the data written to disk. When, during resume, the data was
|
||||
read back into memory the temporary key is destroyed which simply
|
||||
means that all data written to disk during suspend are then
|
||||
inaccessible so they can't be stolen later on. The only thing that
|
||||
you must then take care of is that you call 'mkswap' for the swap
|
||||
partition used for suspend as early as possible during regular
|
||||
boot. This asserts that any temporary key from an oopsed suspend or
|
||||
from a failed or aborted resume is erased from the swap device.
|
||||
|
||||
As a rule of thumb use encrypted swap to protect your data while your
|
||||
system is shut down or suspended. Additionally use the encrypted
|
||||
suspend image to prevent sensitive data from being stolen after
|
||||
resume.
|
||||
|
|
|
@ -83,8 +83,10 @@ Compaq Armada E500 - P3-700 none (1) (S1 also works OK)
|
|||
Compaq Evo N620c vga=normal, s3_bios (2)
|
||||
Dell 600m, ATI R250 Lf none (1), but needs xorg-x11-6.8.1.902-1
|
||||
Dell D600, ATI RV250 vga=normal and X, or try vbestate (6)
|
||||
Dell D610 vga=normal and X (possibly vbestate (6) too, but not tested)
|
||||
Dell Inspiron 4000 ??? (*)
|
||||
Dell Inspiron 500m ??? (*)
|
||||
Dell Inspiron 510m ???
|
||||
Dell Inspiron 600m ??? (*)
|
||||
Dell Inspiron 8200 ??? (*)
|
||||
Dell Inspiron 8500 ??? (*)
|
||||
|
@ -123,6 +125,7 @@ Toshiba Satellite 4030CDT s3_mode (3)
|
|||
Toshiba Satellite 4080XCDT s3_mode (3)
|
||||
Toshiba Satellite 4090XCDT ??? (*)
|
||||
Toshiba Satellite P10-554 s3_bios,s3_mode (4)(****)
|
||||
Toshiba M30 (2) xor X with nvidia driver using internal AGP
|
||||
Uniwill 244IIO ??? (*)
|
||||
|
||||
|
||||
|
|
|
@ -1,13 +1,16 @@
|
|||
This driver implement the ACPI Extensions For Display Adapters
|
||||
for integrated graphics devices on motherboard, as specified in
|
||||
ACPI 2.0 Specification, Appendix B, allowing to perform some basic
|
||||
control like defining the video POST device, retrieving EDID information
|
||||
or to setup a video output, etc. Note that this is an ref. implementation only.
|
||||
It may or may not work for your integrated video device.
|
||||
ACPI video extensions
|
||||
~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
This driver implement the ACPI Extensions For Display Adapters for
|
||||
integrated graphics devices on motherboard, as specified in ACPI 2.0
|
||||
Specification, Appendix B, allowing to perform some basic control like
|
||||
defining the video POST device, retrieving EDID information or to
|
||||
setup a video output, etc. Note that this is an ref. implementation
|
||||
only. It may or may not work for your integrated video device.
|
||||
|
||||
Interfaces exposed to userland through /proc/acpi/video:
|
||||
|
||||
VGA/info : display the supported video bus device capability like ,Video ROM, CRT/LCD/TV.
|
||||
VGA/info : display the supported video bus device capability like Video ROM, CRT/LCD/TV.
|
||||
VGA/ROM : Used to get a copy of the display devices' ROM data (up to 4k).
|
||||
VGA/POST_info : Used to determine what options are implemented.
|
||||
VGA/POST : Used to get/set POST device.
|
||||
|
@ -15,7 +18,7 @@ VGA/DOS : Used to get/set ownership of output switching:
|
|||
Please refer ACPI spec B.4.1 _DOS
|
||||
VGA/CRT : CRT output
|
||||
VGA/LCD : LCD output
|
||||
VGA/TV : TV output
|
||||
VGA/TVO : TV output
|
||||
VGA/*/brightness : Used to get/set brightness of output device
|
||||
|
||||
Notify event through /proc/acpi/event:
|
||||
|
|
|
@ -347,8 +347,8 @@ address that is created by firmware. An example vty-server sysfs entry
|
|||
looks like the following:
|
||||
|
||||
Pow5:/sys/bus/vio/drivers/hvcs/30000004 # ls
|
||||
. current_vty devspec name partner_vtys
|
||||
.. detach_state index partner_clcs vterm_state
|
||||
. current_vty devspec name partner_vtys
|
||||
.. index partner_clcs vterm_state
|
||||
|
||||
Each entry is provided, by default with a "name" attribute. Reading the
|
||||
"name" attribute will reveal the device type as shown in the following
|
||||
|
|
|
@ -30,7 +30,7 @@ Command line parameters
|
|||
device numbers (0xabcd or abcd, for 2.4 backward compatibility).
|
||||
You can use the 'all' keyword to ignore all devices.
|
||||
The '!' operator will cause the I/O-layer to _not_ ignore a device.
|
||||
The order on the command line is not important.
|
||||
The command line is parsed from left to right.
|
||||
|
||||
For example,
|
||||
cio_ignore=0.0.0023-0.0.0042,0.0.4711
|
||||
|
@ -72,13 +72,14 @@ Command line parameters
|
|||
/proc/cio_ignore; "add <device range>, <device range>, ..." will ignore the
|
||||
specified devices.
|
||||
|
||||
Note: Already known devices cannot be ignored.
|
||||
Note: While already known devices can be added to the list of devices to be
|
||||
ignored, there will be no effect on then. However, if such a device
|
||||
disappears and then reappeares, it will then be ignored.
|
||||
|
||||
For example, if device 0.0.abcd is already known and all other devices
|
||||
0.0.a000-0.0.afff are not known,
|
||||
For example,
|
||||
"echo add 0.0.a000-0.0.accc, 0.0.af00-0.0.afff > /proc/cio_ignore"
|
||||
will add 0.0.a000-0.0.abcc, 0.0.abce-0.0.accc and 0.0.af00-0.0.afff to the
|
||||
list of ignored devices and skip 0.0.abcd.
|
||||
will add 0.0.a000-0.0.accc and 0.0.af00-0.0.afff to the list of ignored
|
||||
devices.
|
||||
|
||||
The devices can be specified either by bus id (0.0.abcd) or, for 2.4 backward
|
||||
compatibilty, by the device number in hexadecimal (0xabcd or abcd).
|
||||
|
@ -98,7 +99,8 @@ Command line parameters
|
|||
|
||||
- /proc/s390dbf/cio_trace/hex_ascii
|
||||
Logs the calling of functions in the common I/O-layer and, if applicable,
|
||||
which subchannel they were called for.
|
||||
which subchannel they were called for, as well as dumps of some data
|
||||
structures (like irb in an error case).
|
||||
|
||||
The level of logging can be changed to be more or less verbose by piping to
|
||||
/proc/s390dbf/cio_*/level a number between 0 and 6; see the documentation on
|
||||
|
|
|
@ -12,8 +12,8 @@ where log records can be stored efficiently in memory, where each component
|
|||
One purpose of this is to inspect the debug logs after a production system crash
|
||||
in order to analyze the reason for the crash.
|
||||
If the system still runs but only a subcomponent which uses dbf failes,
|
||||
it is possible to look at the debug logs on a live system via the Linux proc
|
||||
filesystem.
|
||||
it is possible to look at the debug logs on a live system via the Linux
|
||||
debugfs filesystem.
|
||||
The debug feature may also very useful for kernel and driver development.
|
||||
|
||||
Design:
|
||||
|
@ -52,16 +52,18 @@ Each debug entry contains the following data:
|
|||
- Flag, if entry is an exception or not
|
||||
|
||||
The debug logs can be inspected in a live system through entries in
|
||||
the proc-filesystem. Under the path /proc/s390dbf there is
|
||||
the debugfs-filesystem. Under the toplevel directory "s390dbf" there is
|
||||
a directory for each registered component, which is named like the
|
||||
corresponding component.
|
||||
corresponding component. The debugfs normally should be mounted to
|
||||
/sys/kernel/debug therefore the debug feature can be accessed unter
|
||||
/sys/kernel/debug/s390dbf.
|
||||
|
||||
The content of the directories are files which represent different views
|
||||
to the debug log. Each component can decide which views should be
|
||||
used through registering them with the function debug_register_view().
|
||||
Predefined views for hex/ascii, sprintf and raw binary data are provided.
|
||||
It is also possible to define other views. The content of
|
||||
a view can be inspected simply by reading the corresponding proc file.
|
||||
a view can be inspected simply by reading the corresponding debugfs file.
|
||||
|
||||
All debug logs have an an actual debug level (range from 0 to 6).
|
||||
The default level is 3. Event and Exception functions have a 'level'
|
||||
|
@ -69,14 +71,14 @@ parameter. Only debug entries with a level that is lower or equal
|
|||
than the actual level are written to the log. This means, when
|
||||
writing events, high priority log entries should have a low level
|
||||
value whereas low priority entries should have a high one.
|
||||
The actual debug level can be changed with the help of the proc-filesystem
|
||||
through writing a number string "x" to the 'level' proc file which is
|
||||
The actual debug level can be changed with the help of the debugfs-filesystem
|
||||
through writing a number string "x" to the 'level' debugfs file which is
|
||||
provided for every debug log. Debugging can be switched off completely
|
||||
by using "-" on the 'level' proc file.
|
||||
by using "-" on the 'level' debugfs file.
|
||||
|
||||
Example:
|
||||
|
||||
> echo "-" > /proc/s390dbf/dasd/level
|
||||
> echo "-" > /sys/kernel/debug/s390dbf/dasd/level
|
||||
|
||||
It is also possible to deactivate the debug feature globally for every
|
||||
debug log. You can change the behavior using 2 sysctl parameters in
|
||||
|
@ -99,11 +101,11 @@ Kernel Interfaces:
|
|||
------------------
|
||||
|
||||
----------------------------------------------------------------------------
|
||||
debug_info_t *debug_register(char *name, int pages_index, int nr_areas,
|
||||
debug_info_t *debug_register(char *name, int pages, int nr_areas,
|
||||
int buf_size);
|
||||
|
||||
Parameter: name: Name of debug log (e.g. used for proc entry)
|
||||
pages_index: 2^pages_index pages will be allocated per area
|
||||
Parameter: name: Name of debug log (e.g. used for debugfs entry)
|
||||
pages: number of pages, which will be allocated per area
|
||||
nr_areas: number of debug areas
|
||||
buf_size: size of data area in each debug entry
|
||||
|
||||
|
@ -134,7 +136,7 @@ Return Value: none
|
|||
Description: Sets new actual debug level if new_level is valid.
|
||||
|
||||
---------------------------------------------------------------------------
|
||||
+void debug_stop_all(void);
|
||||
void debug_stop_all(void);
|
||||
|
||||
Parameter: none
|
||||
|
||||
|
@ -270,7 +272,7 @@ Parameter: id: handle for debug log
|
|||
Return Value: 0 : ok
|
||||
< 0: Error
|
||||
|
||||
Description: registers new debug view and creates proc dir entry
|
||||
Description: registers new debug view and creates debugfs dir entry
|
||||
|
||||
---------------------------------------------------------------------------
|
||||
int debug_unregister_view (debug_info_t * id, struct debug_view *view);
|
||||
|
@ -281,7 +283,7 @@ Parameter: id: handle for debug log
|
|||
Return Value: 0 : ok
|
||||
< 0: Error
|
||||
|
||||
Description: unregisters debug view and removes proc dir entry
|
||||
Description: unregisters debug view and removes debugfs dir entry
|
||||
|
||||
|
||||
|
||||
|
@ -308,7 +310,7 @@ static int init(void)
|
|||
{
|
||||
/* register 4 debug areas with one page each and 4 byte data field */
|
||||
|
||||
debug_info = debug_register ("test", 0, 4, 4 );
|
||||
debug_info = debug_register ("test", 1, 4, 4 );
|
||||
debug_register_view(debug_info,&debug_hex_ascii_view);
|
||||
debug_register_view(debug_info,&debug_raw_view);
|
||||
|
||||
|
@ -343,7 +345,7 @@ static int init(void)
|
|||
/* register 4 debug areas with one page each and data field for */
|
||||
/* format string pointer + 2 varargs (= 3 * sizeof(long)) */
|
||||
|
||||
debug_info = debug_register ("test", 0, 4, sizeof(long) * 3);
|
||||
debug_info = debug_register ("test", 1, 4, sizeof(long) * 3);
|
||||
debug_register_view(debug_info,&debug_sprintf_view);
|
||||
|
||||
debug_sprintf_event(debug_info, 2 , "first event in %s:%i\n",__FILE__,__LINE__);
|
||||
|
@ -362,16 +364,16 @@ module_exit(cleanup);
|
|||
|
||||
|
||||
|
||||
ProcFS Interface
|
||||
Debugfs Interface
|
||||
----------------
|
||||
Views to the debug logs can be investigated through reading the corresponding
|
||||
proc-files:
|
||||
debugfs-files:
|
||||
|
||||
Example:
|
||||
|
||||
> ls /proc/s390dbf/dasd
|
||||
flush hex_ascii level raw
|
||||
> cat /proc/s390dbf/dasd/hex_ascii | sort +1
|
||||
> ls /sys/kernel/debug/s390dbf/dasd
|
||||
flush hex_ascii level pages raw
|
||||
> cat /sys/kernel/debug/s390dbf/dasd/hex_ascii | sort +1
|
||||
00 00974733272:680099 2 - 02 0006ad7e 07 ea 4a 90 | ....
|
||||
00 00974733272:682210 2 - 02 0006ade6 46 52 45 45 | FREE
|
||||
00 00974733272:682213 2 - 02 0006adf6 07 ea 4a 90 | ....
|
||||
|
@ -391,25 +393,36 @@ Changing the debug level
|
|||
Example:
|
||||
|
||||
|
||||
> cat /proc/s390dbf/dasd/level
|
||||
> cat /sys/kernel/debug/s390dbf/dasd/level
|
||||
3
|
||||
> echo "5" > /proc/s390dbf/dasd/level
|
||||
> cat /proc/s390dbf/dasd/level
|
||||
> echo "5" > /sys/kernel/debug/s390dbf/dasd/level
|
||||
> cat /sys/kernel/debug/s390dbf/dasd/level
|
||||
5
|
||||
|
||||
Flushing debug areas
|
||||
--------------------
|
||||
Debug areas can be flushed with piping the number of the desired
|
||||
area (0...n) to the proc file "flush". When using "-" all debug areas
|
||||
area (0...n) to the debugfs file "flush". When using "-" all debug areas
|
||||
are flushed.
|
||||
|
||||
Examples:
|
||||
|
||||
1. Flush debug area 0:
|
||||
> echo "0" > /proc/s390dbf/dasd/flush
|
||||
> echo "0" > /sys/kernel/debug/s390dbf/dasd/flush
|
||||
|
||||
2. Flush all debug areas:
|
||||
> echo "-" > /proc/s390dbf/dasd/flush
|
||||
> echo "-" > /sys/kernel/debug/s390dbf/dasd/flush
|
||||
|
||||
Changing the size of debug areas
|
||||
------------------------------------
|
||||
It is possible the change the size of debug areas through piping
|
||||
the number of pages to the debugfs file "pages". The resize request will
|
||||
also flush the debug areas.
|
||||
|
||||
Example:
|
||||
|
||||
Define 4 pages for the debug areas of debug feature "dasd":
|
||||
> echo "4" > /sys/kernel/debug/s390dbf/dasd/pages
|
||||
|
||||
Stooping the debug feature
|
||||
--------------------------
|
||||
|
@ -491,7 +504,7 @@ Defining views
|
|||
--------------
|
||||
|
||||
Views are specified with the 'debug_view' structure. There are defined
|
||||
callback functions which are used for reading and writing the proc files:
|
||||
callback functions which are used for reading and writing the debugfs files:
|
||||
|
||||
struct debug_view {
|
||||
char name[DEBUG_MAX_PROCF_LEN];
|
||||
|
@ -525,7 +538,7 @@ typedef int (debug_input_proc_t) (debug_info_t* id,
|
|||
The "private_data" member can be used as pointer to view specific data.
|
||||
It is not used by the debug feature itself.
|
||||
|
||||
The output when reading a debug-proc file is structured like this:
|
||||
The output when reading a debugfs file is structured like this:
|
||||
|
||||
"prolog_proc output"
|
||||
|
||||
|
@ -534,13 +547,13 @@ The output when reading a debug-proc file is structured like this:
|
|||
"header_proc output 3" "format_proc output 3"
|
||||
...
|
||||
|
||||
When a view is read from the proc fs, the Debug Feature calls the
|
||||
When a view is read from the debugfs, the Debug Feature calls the
|
||||
'prolog_proc' once for writing the prolog.
|
||||
Then 'header_proc' and 'format_proc' are called for each
|
||||
existing debug entry.
|
||||
|
||||
The input_proc can be used to implement functionality when it is written to
|
||||
the view (e.g. like with 'echo "0" > /proc/s390dbf/dasd/level).
|
||||
the view (e.g. like with 'echo "0" > /sys/kernel/debug/s390dbf/dasd/level).
|
||||
|
||||
For header_proc there can be used the default function
|
||||
debug_dflt_header_fn() which is defined in in debug.h.
|
||||
|
@ -602,7 +615,7 @@ debug_info = debug_register ("test", 0, 4, 4 ));
|
|||
debug_register_view(debug_info, &debug_test_view);
|
||||
for(i = 0; i < 10; i ++) debug_int_event(debug_info, 1, i);
|
||||
|
||||
> cat /proc/s390dbf/test/myview
|
||||
> cat /sys/kernel/debug/s390dbf/test/myview
|
||||
00 00964419734:611402 1 - 00 88042ca This error...........
|
||||
00 00964419734:611405 1 - 00 88042ca That error...........
|
||||
00 00964419734:611408 1 - 00 88042ca Problem..............
|
||||
|
|
|
@ -1,3 +1,69 @@
|
|||
Release Date : Mon Mar 07 12:27:22 EST 2005 - Seokmann Ju <sju@lsil.com>
|
||||
Current Version : 2.20.4.6 (scsi module), 2.20.2.6 (cmm module)
|
||||
Older Version : 2.20.4.5 (scsi module), 2.20.2.5 (cmm module)
|
||||
|
||||
1. Added IOCTL backward compatibility.
|
||||
Convert megaraid_mm driver to new compat_ioctl entry points.
|
||||
I don't have easy access to hardware, so only compile tested.
|
||||
- Signed-off-by:Andi Kleen <ak@muc.de>
|
||||
|
||||
2. megaraid_mbox fix: wrong order of arguments in memset()
|
||||
That, BTW, shows why cross-builds are useful-the only indication of
|
||||
problem had been a new warning showing up in sparse output on alpha
|
||||
build (number of exceeding 256 got truncated).
|
||||
- Signed-off-by: Al Viro
|
||||
<viro@parcelfarce.linux.theplanet.co.uk>
|
||||
|
||||
3. Convert pci_module_init to pci_register_driver
|
||||
Convert from pci_module_init to pci_register_driver
|
||||
(from:http://kerneljanitors.org/TODO)
|
||||
- Signed-off-by: Domen Puncer <domen@coderock.org>
|
||||
|
||||
4. Use the pre defined DMA mask constants from dma-mapping.h
|
||||
Use the DMA_{64,32}BIT_MASK constants from dma-mapping.h when calling
|
||||
pci_set_dma_mask() or pci_set_consistend_dma_mask(). See
|
||||
http://marc.theaimsgroup.com/?t=108001993000001&r=1&w=2 for more
|
||||
details.
|
||||
Signed-off-by: Tobias Klauser <tklauser@nuerscht.ch>
|
||||
Signed-off-by: Domen Puncer <domen@coderock.org>
|
||||
|
||||
5. Remove SSID checking for Dobson, Lindsay, and Verde based products.
|
||||
Checking the SSVID/SSID for controllers which have Dobson, Lindsay,
|
||||
and Verde is unnecessary because device ID has been assigned by LSI
|
||||
and it is unique value. So, all controllers with these IOPs have to be
|
||||
supported by the driver regardless SSVID/SSID.
|
||||
|
||||
6. Date Thu, 27 Jan 2005 04:31:09 +0100
|
||||
From Herbert Poetzl <>
|
||||
Subject RFC: assert_spin_locked() for 2.6
|
||||
|
||||
Greetings!
|
||||
|
||||
overcautious programming will kill your kernel ;)
|
||||
ever thought about checking a spin_lock or even
|
||||
asserting that it must be held (maybe just for
|
||||
spinlock debugging?) ...
|
||||
|
||||
there are several checks present in the kernel
|
||||
where somebody does a variation on the following:
|
||||
|
||||
BUG_ON(!spin_is_locked(&some_lock));
|
||||
|
||||
so what's wrong about that? nothing, unless you
|
||||
compile the code with CONFIG_DEBUG_SPINLOCK but
|
||||
without CONFIG_SMP ... in which case the BUG()
|
||||
will kill your kernel ...
|
||||
|
||||
maybe it's not advised to make such assertions,
|
||||
but here is a solution which works for me ...
|
||||
(compile tested for sh, x86_64 and x86, boot/run
|
||||
tested for x86 only)
|
||||
|
||||
best,
|
||||
Herbert
|
||||
|
||||
- Herbert Poetzl <herbert@13thfloor.at>, Thu, 27 Jan 2005
|
||||
|
||||
Release Date : Thu Feb 03 12:27:22 EST 2005 - Seokmann Ju <sju@lsil.com>
|
||||
Current Version : 2.20.4.5 (scsi module), 2.20.2.5 (cmm module)
|
||||
Older Version : 2.20.4.4 (scsi module), 2.20.2.4 (cmm module)
|
||||
|
|
180
Documentation/scsi/scsi-changer.txt
Normal file
180
Documentation/scsi/scsi-changer.txt
Normal file
|
@ -0,0 +1,180 @@
|
|||
|
||||
README for the SCSI media changer driver
|
||||
========================================
|
||||
|
||||
This is a driver for SCSI Medium Changer devices, which are listed
|
||||
with "Type: Medium Changer" in /proc/scsi/scsi.
|
||||
|
||||
This is for *real* Jukeboxes. It is *not* supported to work with
|
||||
common small CD-ROM changers, neither one-lun-per-slot SCSI changers
|
||||
nor IDE drives.
|
||||
|
||||
Userland tools available from here:
|
||||
http://linux.bytesex.org/misc/changer.html
|
||||
|
||||
|
||||
General Information
|
||||
-------------------
|
||||
|
||||
First some words about how changers work: A changer has 2 (possibly
|
||||
more) SCSI ID's. One for the changer device which controls the robot,
|
||||
and one for the device which actually reads and writes the data. The
|
||||
later may be anything, a MOD, a CD-ROM, a tape or whatever. For the
|
||||
changer device this is a "don't care", he *only* shuffles around the
|
||||
media, nothing else.
|
||||
|
||||
|
||||
The SCSI changer model is complex, compared to - for example - IDE-CD
|
||||
changers. But it allows to handle nearly all possible cases. It knows
|
||||
4 different types of changer elements:
|
||||
|
||||
media transport - this one shuffles around the media, i.e. the
|
||||
transport arm. Also known as "picker".
|
||||
storage - a slot which can hold a media.
|
||||
import/export - the same as above, but is accessable from outside,
|
||||
i.e. there the operator (you !) can use this to
|
||||
fill in and remove media from the changer.
|
||||
Sometimes named "mailslot".
|
||||
data transfer - this is the device which reads/writes, i.e. the
|
||||
CD-ROM / Tape / whatever drive.
|
||||
|
||||
None of these is limited to one: A huge Jukebox could have slots for
|
||||
123 CD-ROM's, 5 CD-ROM readers (and therefore 6 SCSI ID's: the changer
|
||||
and each CD-ROM) and 2 transport arms. No problem to handle.
|
||||
|
||||
|
||||
How it is implemented
|
||||
---------------------
|
||||
|
||||
I implemented the driver as character device driver with a NetBSD-like
|
||||
ioctl interface. Just grabbed NetBSD's header file and one of the
|
||||
other linux SCSI device drivers as starting point. The interface
|
||||
should be source code compatible with NetBSD. So if there is any
|
||||
software (anybody knows ???) which supports a BSDish changer driver,
|
||||
it should work with this driver too.
|
||||
|
||||
Over time a few more ioctls where added, volume tag support for example
|
||||
wasn't covered by the NetBSD ioctl API.
|
||||
|
||||
|
||||
Current State
|
||||
-------------
|
||||
|
||||
Support for more than one transport arm is not implemented yet (and
|
||||
nobody asked for it so far...).
|
||||
|
||||
I test and use the driver myself with a 35 slot cdrom jukebox from
|
||||
Grundig. I got some reports telling it works ok with tape autoloaders
|
||||
(Exabyte, HP and DEC). Some People use this driver with amanda. It
|
||||
works fine with small (11 slots) and a huge (4 MOs, 88 slots)
|
||||
magneto-optical Jukebox. Probably with lots of other changers too, most
|
||||
(but not all :-) people mail me only if it does *not* work...
|
||||
|
||||
I don't have any device lists, neither black-list nor white-list. Thus
|
||||
it is quite useless to ask me whenever a specific device is supported or
|
||||
not. In theory every changer device which supports the SCSI-2 media
|
||||
changer command set should work out-of-the-box with this driver. If it
|
||||
doesn't, it is a bug. Either within the driver or within the firmware
|
||||
of the changer device.
|
||||
|
||||
|
||||
Using it
|
||||
--------
|
||||
|
||||
This is a character device with major number is 86, so use
|
||||
"mknod /dev/sch0 c 86 0" to create the special file for the driver.
|
||||
|
||||
If the module finds the changer, it prints some messages about the
|
||||
device [ try "dmesg" if you don't see anything ] and should show up in
|
||||
/proc/devices. If not.... some changers use ID ? / LUN 0 for the
|
||||
device and ID ? / LUN 1 for the robot mechanism. But Linux does *not*
|
||||
look for LUN's other than 0 as default, becauce there are to many
|
||||
broken devices. So you can try:
|
||||
|
||||
1) echo "scsi add-single-device 0 0 ID 1" > /proc/scsi/scsi
|
||||
(replace ID with the SCSI-ID of the device)
|
||||
2) boot the kernel with "max_scsi_luns=1" on the command line
|
||||
(append="max_scsi_luns=1" in lilo.conf should do the trick)
|
||||
|
||||
|
||||
Trouble?
|
||||
--------
|
||||
|
||||
If you insmod the driver with "insmod debug=1", it will be verbose and
|
||||
prints a lot of stuff to the syslog. Compiling the kernel with
|
||||
CONFIG_SCSI_CONSTANTS=y improves the quality of the error messages alot
|
||||
because the kernel will translate the error codes into human-readable
|
||||
strings then.
|
||||
|
||||
You can display these messages with the dmesg command (or check the
|
||||
logfiles). If you email me some question becauce of a problem with the
|
||||
driver, please include these messages.
|
||||
|
||||
|
||||
Insmod options
|
||||
--------------
|
||||
|
||||
debug=0/1
|
||||
Enable debug messages (see above, default: 0).
|
||||
|
||||
verbose=0/1
|
||||
Be verbose (default: 1).
|
||||
|
||||
init=0/1
|
||||
Send INITIALIZE ELEMENT STATUS command to the changer
|
||||
at insmod time (default: 1).
|
||||
|
||||
timeout_init=<seconds>
|
||||
timeout for the INITIALIZE ELEMENT STATUS command
|
||||
(default: 3600).
|
||||
|
||||
timeout_move=<seconds>
|
||||
timeout for all other commands (default: 120).
|
||||
|
||||
dt_id=<id1>,<id2>,...
|
||||
dt_lun=<lun1>,<lun2>,...
|
||||
These two allow to specify the SCSI ID and LUN for the data
|
||||
transfer elements. You likely don't need this as the jukebox
|
||||
should provide this information. But some devices don't ...
|
||||
|
||||
vendor_firsts=
|
||||
vendor_counts=
|
||||
vendor_labels=
|
||||
These insmod options can be used to tell the driver that there
|
||||
are some vendor-specific element types. Grundig for example
|
||||
does this. Some jukeboxes have a printer to label fresh burned
|
||||
CDs, which is addressed as element 0xc000 (type 5). To tell the
|
||||
driver about this vendor-specific element, use this:
|
||||
$ insmod ch \
|
||||
vendor_firsts=0xc000 \
|
||||
vendor_counts=1 \
|
||||
vendor_labels=printer
|
||||
All three insmod options accept up to four comma-separated
|
||||
values, this way you can configure the element types 5-8.
|
||||
You likely need the SCSI specs for the device in question to
|
||||
find the correct values as they are not covered by the SCSI-2
|
||||
standard.
|
||||
|
||||
|
||||
Credits
|
||||
-------
|
||||
|
||||
I wrote this driver using the famous mailing-patches-around-the-world
|
||||
method. With (more or less) help from:
|
||||
|
||||
Daniel Moehwald <moehwald@hdg.de>
|
||||
Dane Jasper <dane@sonic.net>
|
||||
R. Scott Bailey <sbailey@dsddi.eds.com>
|
||||
Jonathan Corbet <corbet@lwn.net>
|
||||
|
||||
Special thanks go to
|
||||
Martin Kuehne <martin.kuehne@bnbt.de>
|
||||
for a old, second-hand (but full functional) cdrom jukebox which I use
|
||||
to develop/test driver and tools now.
|
||||
|
||||
Have fun,
|
||||
|
||||
Gerd
|
||||
|
||||
--
|
||||
Gerd Knorr <kraxel@bytesex.org>
|
|
@ -936,8 +936,7 @@ Details:
|
|||
*
|
||||
* Returns SUCCESS if command aborted else FAILED
|
||||
*
|
||||
* Locks: struct Scsi_Host::host_lock held (with irqsave) on entry
|
||||
* and assumed to be held on return.
|
||||
* Locks: None held
|
||||
*
|
||||
* Calling context: kernel thread
|
||||
*
|
||||
|
@ -955,8 +954,7 @@ Details:
|
|||
*
|
||||
* Returns SUCCESS if command aborted else FAILED
|
||||
*
|
||||
* Locks: struct Scsi_Host::host_lock held (with irqsave) on entry
|
||||
* and assumed to be held on return.
|
||||
* Locks: None held
|
||||
*
|
||||
* Calling context: kernel thread
|
||||
*
|
||||
|
@ -974,8 +972,7 @@ Details:
|
|||
*
|
||||
* Returns SUCCESS if command aborted else FAILED
|
||||
*
|
||||
* Locks: struct Scsi_Host::host_lock held (with irqsave) on entry
|
||||
* and assumed to be held on return.
|
||||
* Locks: None held
|
||||
*
|
||||
* Calling context: kernel thread
|
||||
*
|
||||
|
@ -993,8 +990,7 @@ Details:
|
|||
*
|
||||
* Returns SUCCESS if command aborted else FAILED
|
||||
*
|
||||
* Locks: struct Scsi_Host::host_lock held (with irqsave) on entry
|
||||
* and assumed to be held on return.
|
||||
* Locks: None held
|
||||
*
|
||||
* Calling context: kernel thread
|
||||
*
|
||||
|
|
45
Documentation/sgi-ioc4.txt
Normal file
45
Documentation/sgi-ioc4.txt
Normal file
|
@ -0,0 +1,45 @@
|
|||
The SGI IOC4 PCI device is a bit of a strange beast, so some notes on
|
||||
it are in order.
|
||||
|
||||
First, even though the IOC4 performs multiple functions, such as an
|
||||
IDE controller, a serial controller, a PS/2 keyboard/mouse controller,
|
||||
and an external interrupt mechanism, it's not implemented as a
|
||||
multifunction device. The consequence of this from a software
|
||||
standpoint is that all these functions share a single IRQ, and
|
||||
they can't all register to own the same PCI device ID. To make
|
||||
matters a bit worse, some of the register blocks (and even registers
|
||||
themselves) present in IOC4 are mixed-purpose between these several
|
||||
functions, meaning that there's no clear "owning" device driver.
|
||||
|
||||
The solution is to organize the IOC4 driver into several independent
|
||||
drivers, "ioc4", "sgiioc4", and "ioc4_serial". Note that there is no
|
||||
PS/2 controller driver as this functionality has never been wired up
|
||||
on a shipping IO card.
|
||||
|
||||
ioc4
|
||||
====
|
||||
This is the core (or shim) driver for IOC4. It is responsible for
|
||||
initializing the basic functionality of the chip, and allocating
|
||||
the PCI resources that are shared between the IOC4 functions.
|
||||
|
||||
This driver also provides registration functions that the other
|
||||
IOC4 drivers can call to make their presence known. Each driver
|
||||
needs to provide a probe and remove function, which are invoked
|
||||
by the core driver at appropriate times. The interface of these
|
||||
IOC4 function probe and remove operations isn't precisely the same
|
||||
as PCI device probe and remove operations, but is logically the
|
||||
same operation.
|
||||
|
||||
sgiioc4
|
||||
=======
|
||||
This is the IDE driver for IOC4. Its name isn't very descriptive
|
||||
simply for historical reasons (it used to be the only IOC4 driver
|
||||
component). There's not much to say about it other than it hooks
|
||||
up to the ioc4 driver via the appropriate registration, probe, and
|
||||
remove functions.
|
||||
|
||||
ioc4_serial
|
||||
===========
|
||||
This is the serial driver for IOC4. There's not much to say about it
|
||||
other than it hooks up to the ioc4 driver via the appropriate registration,
|
||||
probe, and remove functions.
|
|
@ -615,9 +615,11 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
|
|||
Module snd-hda-intel
|
||||
--------------------
|
||||
|
||||
Module for Intel HD Audio (ICH6, ICH6M, ICH7)
|
||||
Module for Intel HD Audio (ICH6, ICH6M, ICH7), ATI SB450,
|
||||
VIA VT8251/VT8237A
|
||||
|
||||
model - force the model name
|
||||
position_fix - Fix DMA pointer (0 = FIFO size, 1 = none, 2 = POSBUF)
|
||||
|
||||
Module supports up to 8 cards.
|
||||
|
||||
|
@ -635,6 +637,10 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
|
|||
5stack 5-jack in back, 2-jack in front
|
||||
5stack-digout 5-jack in back, 2-jack in front, a SPDIF out
|
||||
w810 3-jack
|
||||
z71v 3-jack (HP shared SPDIF)
|
||||
asus 3-jack
|
||||
uniwill 3-jack
|
||||
F1734 2-jack
|
||||
|
||||
CMI9880
|
||||
minimal 3-jack in back
|
||||
|
@ -642,6 +648,15 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
|
|||
full 6-jack in back, 2-jack in front
|
||||
full_dig 6-jack in back, 2-jack in front, SPDIF I/O
|
||||
allout 5-jack in back, 2-jack in front, SPDIF out
|
||||
auto auto-config reading BIOS (default)
|
||||
|
||||
Note 2: If you get click noises on output, try the module option
|
||||
position_fix=1 or 2. position_fix=1 will use the SD_LPIB
|
||||
register value without FIFO size correction as the current
|
||||
DMA pointer. position_fix=2 will make the driver to use
|
||||
the position buffer instead of reading SD_LPIB register.
|
||||
(Usually SD_LPLIB register is more accurate than the
|
||||
position buffer.)
|
||||
|
||||
Module snd-hdsp
|
||||
---------------
|
||||
|
@ -660,7 +675,19 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
|
|||
module did formerly. It will allocate the buffers in advance
|
||||
when any HDSP cards are found. To make the buffer
|
||||
allocation sure, load snd-page-alloc module in the early
|
||||
stage of boot sequence.
|
||||
stage of boot sequence. See "Early Buffer Allocation"
|
||||
section.
|
||||
|
||||
Module snd-hdspm
|
||||
----------------
|
||||
|
||||
Module for RME HDSP MADI board.
|
||||
|
||||
precise_ptr - Enable precise pointer, or disable.
|
||||
line_outs_monitor - Send playback streams to analog outs by default.
|
||||
enable_monitor - Enable Analog Out on Channel 63/64 by default.
|
||||
|
||||
See hdspm.txt for details.
|
||||
|
||||
Module snd-ice1712
|
||||
------------------
|
||||
|
@ -677,15 +704,19 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
|
|||
* TerraTec EWS 88D
|
||||
* TerraTec EWX 24/96
|
||||
* TerraTec DMX 6Fire
|
||||
* TerraTec Phase 88
|
||||
* Hoontech SoundTrack DSP 24
|
||||
* Hoontech SoundTrack DSP 24 Value
|
||||
* Hoontech SoundTrack DSP 24 Media 7.1
|
||||
* Event Electronics, EZ8
|
||||
* Digigram VX442
|
||||
* Lionstracs, Mediastaton
|
||||
|
||||
model - Use the given board model, one of the following:
|
||||
delta1010, dio2496, delta66, delta44, audiophile, delta410,
|
||||
delta1010lt, vx442, ewx2496, ews88mt, ews88mt_new, ews88d,
|
||||
dmx6fire, dsp24, dsp24_value, dsp24_71, ez8
|
||||
dmx6fire, dsp24, dsp24_value, dsp24_71, ez8,
|
||||
phase88, mediastation
|
||||
omni - Omni I/O support for MidiMan M-Audio Delta44/66
|
||||
cs8427_timeout - reset timeout for the CS8427 chip (S/PDIF transciever)
|
||||
in msec resolution, default value is 500 (0.5 sec)
|
||||
|
@ -694,20 +725,46 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
|
|||
is not used with all Envy24 based cards (for example in the MidiMan Delta
|
||||
serie).
|
||||
|
||||
Note: The supported board is detected by reading EEPROM or PCI
|
||||
SSID (if EEPROM isn't available). You can override the
|
||||
model by passing "model" module option in case that the
|
||||
driver isn't configured properly or you want to try another
|
||||
type for testing.
|
||||
|
||||
Module snd-ice1724
|
||||
------------------
|
||||
|
||||
Module for Envy24HT (VT/ICE1724) based PCI sound cards.
|
||||
Module for Envy24HT (VT/ICE1724), Envy24PT (VT1720) based PCI sound cards.
|
||||
* MidiMan M Audio Revolution 7.1
|
||||
* AMP Ltd AUDIO2000
|
||||
* TerraTec Aureon Sky-5.1, Space-7.1
|
||||
* TerraTec Aureon 5.1 Sky
|
||||
* TerraTec Aureon 7.1 Space
|
||||
* TerraTec Aureon 7.1 Universe
|
||||
* TerraTec Phase 22
|
||||
* TerraTec Phase 28
|
||||
* AudioTrak Prodigy 7.1
|
||||
* AudioTrak Prodigy 192
|
||||
* Pontis MS300
|
||||
* Albatron K8X800 Pro II
|
||||
* Chaintech ZNF3-150
|
||||
* Chaintech ZNF3-250
|
||||
* Chaintech 9CJS
|
||||
* Chaintech AV-710
|
||||
* Shuttle SN25P
|
||||
|
||||
model - Use the given board model, one of the following:
|
||||
revo71, amp2000, prodigy71, aureon51, aureon71,
|
||||
k8x800
|
||||
revo71, amp2000, prodigy71, prodigy192, aureon51,
|
||||
aureon71, universe, k8x800, phase22, phase28, ms300,
|
||||
av710
|
||||
|
||||
Module supports up to 8 cards and autoprobe.
|
||||
|
||||
Note: The supported board is detected by reading EEPROM or PCI
|
||||
SSID (if EEPROM isn't available). You can override the
|
||||
model by passing "model" module option in case that the
|
||||
driver isn't configured properly or you want to try another
|
||||
type for testing.
|
||||
|
||||
Module snd-intel8x0
|
||||
-------------------
|
||||
|
||||
|
@ -1026,7 +1083,8 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
|
|||
module did formerly. It will allocate the buffers in advance
|
||||
when any RME9652 cards are found. To make the buffer
|
||||
allocation sure, load snd-page-alloc module in the early
|
||||
stage of boot sequence.
|
||||
stage of boot sequence. See "Early Buffer Allocation"
|
||||
section.
|
||||
|
||||
Module snd-sa11xx-uda1341 (on arm only)
|
||||
---------------------------------------
|
||||
|
@ -1211,16 +1269,18 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
|
|||
------------------
|
||||
|
||||
Module for AC'97 motherboards based on VIA 82C686A/686B, 8233,
|
||||
8233A, 8233C, 8235 (south) bridge.
|
||||
8233A, 8233C, 8235, 8237 (south) bridge.
|
||||
|
||||
mpu_port - 0x300,0x310,0x320,0x330, otherwise obtain BIOS setup
|
||||
[VIA686A/686B only]
|
||||
joystick - Enable joystick (default off) [VIA686A/686B only]
|
||||
ac97_clock - AC'97 codec clock base (default 48000Hz)
|
||||
dxs_support - support DXS channels,
|
||||
0 = auto (defalut), 1 = enable, 2 = disable,
|
||||
3 = 48k only, 4 = no VRA
|
||||
[VIA8233/C,8235 only]
|
||||
0 = auto (default), 1 = enable, 2 = disable,
|
||||
3 = 48k only, 4 = no VRA, 5 = enable any sample
|
||||
rate and different sample rates on different
|
||||
channels
|
||||
[VIA8233/C, 8235, 8237 only]
|
||||
ac97_quirk - AC'97 workaround for strange hardware
|
||||
See the description of intel8x0 module for details.
|
||||
|
||||
|
@ -1232,18 +1292,23 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
|
|||
default value 1.4. Then the interrupt number will be
|
||||
assigned under 15. You might also upgrade your BIOS.
|
||||
|
||||
Note: VIA8233/5 (not VIA8233A) can support DXS (direct sound)
|
||||
Note: VIA8233/5/7 (not VIA8233A) can support DXS (direct sound)
|
||||
channels as the first PCM. On these channels, up to 4
|
||||
streams can be played at the same time.
|
||||
streams can be played at the same time, and the controller
|
||||
can perform sample rate conversion with separate rates for
|
||||
each channel.
|
||||
As default (dxs_support = 0), 48k fixed rate is chosen
|
||||
except for the known devices since the output is often
|
||||
noisy except for 48k on some mother boards due to the
|
||||
bug of BIOS.
|
||||
Please try once dxs_support=1 and if it works on other
|
||||
Please try once dxs_support=5 and if it works on other
|
||||
sample rates (e.g. 44.1kHz of mp3 playback), please let us
|
||||
know the PCI subsystem vendor/device id's (output of
|
||||
"lspci -nv").
|
||||
If it doesn't work, try dxs_support=4. If it still doesn't
|
||||
If dxs_support=5 does not work, try dxs_support=4; if it
|
||||
doesn't work too, try dxs_support=1. (dxs_support=1 is
|
||||
usually for old motherboards. The correct implementated
|
||||
board should work with 4 or 5.) If it still doesn't
|
||||
work and the default setting is ok, dxs_support=3 is the
|
||||
right choice. If the default setting doesn't work at all,
|
||||
try dxs_support=2 to disable the DXS channels.
|
||||
|
@ -1497,6 +1562,36 @@ Proc interfaces (/proc/asound)
|
|||
echo "rvplayer 0 0 block" > /proc/asound/card0/pcm0p/oss
|
||||
|
||||
|
||||
Early Buffer Allocation
|
||||
=======================
|
||||
|
||||
Some drivers (e.g. hdsp) require the large contiguous buffers, and
|
||||
sometimes it's too late to find such spaces when the driver module is
|
||||
actually loaded due to memory fragmentation. You can pre-allocate the
|
||||
PCM buffers by loading snd-page-alloc module and write commands to its
|
||||
proc file in prior, for example, in the early boot stage like
|
||||
/etc/init.d/*.local scripts.
|
||||
|
||||
Reading the proc file /proc/drivers/snd-page-alloc shows the current
|
||||
usage of page allocation. In writing, you can send the following
|
||||
commands to the snd-page-alloc driver:
|
||||
|
||||
- add VENDOR DEVICE MASK SIZE BUFFERS
|
||||
|
||||
VENDOR and DEVICE are PCI vendor and device IDs. They take
|
||||
integer numbers (0x prefix is needed for the hex).
|
||||
MASK is the PCI DMA mask. Pass 0 if not restricted.
|
||||
SIZE is the size of each buffer to allocate. You can pass
|
||||
k and m suffix for KB and MB. The max number is 16MB.
|
||||
BUFFERS is the number of buffers to allocate. It must be greater
|
||||
than 0. The max number is 4.
|
||||
|
||||
- erase
|
||||
|
||||
This will erase the all pre-allocated buffers which are not in
|
||||
use.
|
||||
|
||||
|
||||
Links
|
||||
=====
|
||||
|
||||
|
|
|
@ -89,19 +89,22 @@ and use the interleaved 4 channel data.
|
|||
|
||||
There are some control switchs affecting to the speaker connections:
|
||||
|
||||
"Line-In As Rear" - As mentioned above, the line-in jack is used
|
||||
for the rear (3th and 4th channels) output.
|
||||
"Line-In As Bass" - The line-in jack is used for the bass (5th
|
||||
and 6th channels) output.
|
||||
"Mic As Center/LFE" - The mic jack is used for the bass output.
|
||||
If this switch is on, you cannot use a microphone as a capture
|
||||
source, of course.
|
||||
|
||||
"Line-In Mode" - an enum control to change the behavior of line-in
|
||||
jack. Either "Line-In", "Rear Output" or "Bass Output" can
|
||||
be selected. The last item is available only with model 039
|
||||
or newer.
|
||||
When "Rear Output" is chosen, the surround channels 3 and 4
|
||||
are output to line-in jack.
|
||||
"Mic-In Mode" - an enum control to change the behavior of mic-in
|
||||
jack. Either "Mic-In" or "Center/LFE Output" can be
|
||||
selected.
|
||||
When "Center/LFE Output" is chosen, the center and bass
|
||||
channels (channels 5 and 6) are output to mic-in jack.
|
||||
|
||||
Digital I/O
|
||||
-----------
|
||||
|
||||
The CM8x38 provides the excellent SPDIF capability with very chip
|
||||
The CM8x38 provides the excellent SPDIF capability with very cheap
|
||||
price (yes, that's the reason I bought the card :)
|
||||
|
||||
The SPDIF playback and capture are done via the third PCM device
|
||||
|
@ -122,8 +125,9 @@ respectively, so you cannot playback both analog and digital streams
|
|||
simultaneously.
|
||||
|
||||
To enable SPDIF output, you need to turn on "IEC958 Output Switch"
|
||||
control via mixer or alsactl. Then you'll see the red light on from
|
||||
the card so you know that's working obviously :)
|
||||
control via mixer or alsactl ("IEC958" is the official name of
|
||||
so-called S/PDIF). Then you'll see the red light on from the card so
|
||||
you know that's working obviously :)
|
||||
The SPDIF input is always enabled, so you can hear SPDIF input data
|
||||
from line-out with "IEC958 In Monitor" switch at any time (see
|
||||
below).
|
||||
|
@ -205,9 +209,10 @@ In addition to the standard SB mixer, CM8x38 provides more functions.
|
|||
MIDI CONTROLLER
|
||||
---------------
|
||||
|
||||
The MPU401-UART interface is enabled as default only for the first
|
||||
(CMIPCI) card. You need to set module option "midi_port" properly
|
||||
for the 2nd (CMIPCI) card.
|
||||
The MPU401-UART interface is disabled as default. You need to set
|
||||
module option "mpu_port" with a valid I/O port address to enable the
|
||||
MIDI support. The valid I/O ports are 0x300, 0x310, 0x320 and 0x330.
|
||||
Choose the value which doesn't conflict with other cards.
|
||||
|
||||
There is _no_ hardware wavetable function on this chip (except for
|
||||
OPL3 synth below).
|
||||
|
@ -229,9 +234,11 @@ I don't know why..
|
|||
Joystick and Modem
|
||||
------------------
|
||||
|
||||
The joystick and modem should be available by enabling the control
|
||||
switch "Joystick" and "Modem" respectively. But I myself have never
|
||||
tested them yet.
|
||||
The legacy joystick is supported. To enable the joystick support, pass
|
||||
joystick_port=1 module option. The value 1 means the auto-detection.
|
||||
If the auto-detection fails, try to pass the exact I/O address.
|
||||
|
||||
The modem is enabled dynamically via a card control switch "Modem".
|
||||
|
||||
|
||||
Debugging Information
|
||||
|
|
|
@ -371,7 +371,7 @@
|
|||
<listitem><para>create <function>probe()</function> callback.</para></listitem>
|
||||
<listitem><para>create <function>remove()</function> callback.</para></listitem>
|
||||
<listitem><para>create pci_driver table which contains the three pointers above.</para></listitem>
|
||||
<listitem><para>create <function>init()</function> function just calling <function>pci_module_init()</function> to register the pci_driver table defined above.</para></listitem>
|
||||
<listitem><para>create <function>init()</function> function just calling <function>pci_register_driver()</function> to register the pci_driver table defined above.</para></listitem>
|
||||
<listitem><para>create <function>exit()</function> function to call <function>pci_unregister_driver()</function> function.</para></listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
|
@ -1198,7 +1198,7 @@
|
|||
/* initialization of the module */
|
||||
static int __init alsa_card_mychip_init(void)
|
||||
{
|
||||
return pci_module_init(&driver);
|
||||
return pci_register_driver(&driver);
|
||||
}
|
||||
|
||||
/* clean up the module */
|
||||
|
@ -1654,7 +1654,7 @@
|
|||
<![CDATA[
|
||||
static int __init alsa_card_mychip_init(void)
|
||||
{
|
||||
return pci_module_init(&driver);
|
||||
return pci_register_driver(&driver);
|
||||
}
|
||||
|
||||
static void __exit alsa_card_mychip_exit(void)
|
||||
|
|
74
Documentation/sound/alsa/emu10k1-jack.txt
Normal file
74
Documentation/sound/alsa/emu10k1-jack.txt
Normal file
|
@ -0,0 +1,74 @@
|
|||
This document is a guide to using the emu10k1 based devices with JACK for low
|
||||
latency, multichannel recording functionality. All of my recent work to allow
|
||||
Linux users to use the full capabilities of their hardware has been inspired
|
||||
by the kX Project. Without their work I never would have discovered the true
|
||||
power of this hardware.
|
||||
|
||||
http://www.kxproject.com
|
||||
- Lee Revell, 2005.03.30
|
||||
|
||||
Low latency, multichannel audio with JACK and the emu10k1/emu10k2
|
||||
-----------------------------------------------------------------
|
||||
|
||||
Until recently, emu10k1 users on Linux did not have access to the same low
|
||||
latency, multichannel features offered by the "kX ASIO" feature of their
|
||||
Windows driver. As of ALSA 1.0.9 this is no more!
|
||||
|
||||
For those unfamiliar with kX ASIO, this consists of 16 capture and 16 playback
|
||||
channels. With a post 2.6.9 Linux kernel, latencies down to 64 (1.33 ms) or
|
||||
even 32 (0.66ms) frames should work well.
|
||||
|
||||
The configuration is slightly more involved than on Windows, as you have to
|
||||
select the correct device for JACK to use. Actually, for qjackctl users it's
|
||||
fairly self explanatory - select Duplex, then for capture and playback select
|
||||
the multichannel devices, set the in and out channels to 16, and the sample
|
||||
rate to 48000Hz. The command line looks like this:
|
||||
|
||||
/usr/local/bin/jackd -R -dalsa -r48000 -p64 -n2 -D -Chw:0,2 -Phw:0,3 -S
|
||||
|
||||
This will give you 16 input ports and 16 output ports.
|
||||
|
||||
The 16 output ports map onto the 16 FX buses (or the first 16 of 64, for the
|
||||
Audigy). The mapping from FX bus to physical output is described in
|
||||
SB-Live-mixer.txt (or Audigy-mixer.txt).
|
||||
|
||||
The 16 input ports are connected to the 16 physical inputs. Contrary to
|
||||
popular belief, all emu10k1 cards are multichannel cards. Which of these
|
||||
input channels have physical inputs connected to them depends on the card
|
||||
model. Trial and error is highly recommended; the pinout diagrams
|
||||
for the card have been reverse engineered by some enterprising kX users and are
|
||||
available on the internet. Meterbridge is helpful here, and the kX forums are
|
||||
packed with useful information.
|
||||
|
||||
Each input port will either correspond to a digital (SPDIF) input, an analog
|
||||
input, or nothing. The one exception is the SBLive! 5.1. On these devices,
|
||||
the second and third input ports are wired to the center/LFE output. You will
|
||||
still see 16 capture channels, but only 14 are available for recording inputs.
|
||||
|
||||
This chart, borrowed from kxfxlib/da_asio51.cpp, describes the mapping of JACK
|
||||
ports to FXBUS2 (multitrack recording input) and EXTOUT (physical output)
|
||||
channels.
|
||||
|
||||
/*JACK (& ASIO) mappings on 10k1 5.1 SBLive cards:
|
||||
--------------------------------------------
|
||||
JACK Epilog FXBUS2(nr)
|
||||
--------------------------------------------
|
||||
capture_1 asio14 FXBUS2(0xe)
|
||||
capture_2 asio15 FXBUS2(0xf)
|
||||
capture_3 asio0 FXBUS2(0x0)
|
||||
~capture_4 Center EXTOUT(0x11) // mapped to by Center
|
||||
~capture_5 LFE EXTOUT(0x12) // mapped to by LFE
|
||||
capture_6 asio3 FXBUS2(0x3)
|
||||
capture_7 asio4 FXBUS2(0x4)
|
||||
capture_8 asio5 FXBUS2(0x5)
|
||||
capture_9 asio6 FXBUS2(0x6)
|
||||
capture_10 asio7 FXBUS2(0x7)
|
||||
capture_11 asio8 FXBUS2(0x8)
|
||||
capture_12 asio9 FXBUS2(0x9)
|
||||
capture_13 asio10 FXBUS2(0xa)
|
||||
capture_14 asio11 FXBUS2(0xb)
|
||||
capture_15 asio12 FXBUS2(0xc)
|
||||
capture_16 asio13 FXBUS2(0xd)
|
||||
*/
|
||||
|
||||
TODO: describe use of ld10k1/qlo10k1 in conjunction with JACK
|
362
Documentation/sound/alsa/hdspm.txt
Normal file
362
Documentation/sound/alsa/hdspm.txt
Normal file
|
@ -0,0 +1,362 @@
|
|||
Software Interface ALSA-DSP MADI Driver
|
||||
|
||||
(translated from German, so no good English ;-),
|
||||
2004 - winfried ritsch
|
||||
|
||||
|
||||
|
||||
Full functionality has been added to the driver. Since some of
|
||||
the Controls and startup-options are ALSA-Standard and only the
|
||||
special Controls are described and discussed below.
|
||||
|
||||
|
||||
hardware functionality:
|
||||
|
||||
|
||||
Audio transmission:
|
||||
|
||||
number of channels -- depends on transmission mode
|
||||
|
||||
The number of channels chosen is from 1..Nmax. The reason to
|
||||
use for a lower number of channels is only resource allocation,
|
||||
since unused DMA channels are disabled and less memory is
|
||||
allocated. So also the throughput of the PCI system can be
|
||||
scaled. (Only important for low performance boards).
|
||||
|
||||
Single Speed -- 1..64 channels
|
||||
|
||||
(Note: Choosing the 56channel mode for transmission or as
|
||||
receiver, only 56 are transmitted/received over the MADI, but
|
||||
all 64 channels are available for the mixer, so channel count
|
||||
for the driver)
|
||||
|
||||
Double Speed -- 1..32 channels
|
||||
|
||||
Note: Choosing the 56-channel mode for
|
||||
transmission/receive-mode , only 28 are transmitted/received
|
||||
over the MADI, but all 32 channels are available for the mixer,
|
||||
so channel count for the driver
|
||||
|
||||
|
||||
Quad Speed -- 1..16 channels
|
||||
|
||||
Note: Choosing the 56-channel mode for
|
||||
transmission/receive-mode , only 14 are transmitted/received
|
||||
over the MADI, but all 16 channels are available for the mixer,
|
||||
so channel count for the driver
|
||||
|
||||
Format -- signed 32 Bit Little Endian (SNDRV_PCM_FMTBIT_S32_LE)
|
||||
|
||||
Sample Rates --
|
||||
|
||||
Single Speed -- 32000, 44100, 48000
|
||||
|
||||
Double Speed -- 64000, 88200, 96000 (untested)
|
||||
|
||||
Quad Speed -- 128000, 176400, 192000 (untested)
|
||||
|
||||
access-mode -- MMAP (memory mapped), Not interleaved
|
||||
(PCM_NON-INTERLEAVED)
|
||||
|
||||
buffer-sizes -- 64,128,256,512,1024,2048,8192 Samples
|
||||
|
||||
fragments -- 2
|
||||
|
||||
Hardware-pointer -- 2 Modi
|
||||
|
||||
|
||||
The Card supports the readout of the actual Buffer-pointer,
|
||||
where DMA reads/writes. Since of the bulk mode of PCI it is only
|
||||
64 Byte accurate. SO it is not really usable for the
|
||||
ALSA-mid-level functions (here the buffer-ID gives a better
|
||||
result), but if MMAP is used by the application. Therefore it
|
||||
can be configured at load-time with the parameter
|
||||
precise-pointer.
|
||||
|
||||
|
||||
(Hint: Experimenting I found that the pointer is maximum 64 to
|
||||
large never to small. So if you subtract 64 you always have a
|
||||
safe pointer for writing, which is used on this mode inside
|
||||
ALSA. In theory now you can get now a latency as low as 16
|
||||
Samples, which is a quarter of the interrupt possibilities.)
|
||||
|
||||
Precise Pointer -- off
|
||||
interrupt used for pointer-calculation
|
||||
|
||||
Precise Pointer -- on
|
||||
hardware pointer used.
|
||||
|
||||
Controller:
|
||||
|
||||
|
||||
Since DSP-MADI-Mixer has 8152 Fader, it does not make sense to
|
||||
use the standard mixer-controls, since this would break most of
|
||||
(especially graphic) ALSA-Mixer GUIs. So Mixer control has be
|
||||
provided by a 2-dimensional controller using the
|
||||
hwdep-interface.
|
||||
|
||||
Also all 128+256 Peak and RMS-Meter can be accessed via the
|
||||
hwdep-interface. Since it could be a performance problem always
|
||||
copying and converting Peak and RMS-Levels even if you just need
|
||||
one, I decided to export the hardware structure, so that of
|
||||
needed some driver-guru can implement a memory-mapping of mixer
|
||||
or peak-meters over ioctl, or also to do only copying and no
|
||||
conversion. A test-application shows the usage of the controller.
|
||||
|
||||
Latency Controls --- not implemented !!!
|
||||
|
||||
|
||||
Note: Within the windows-driver the latency is accessible of a
|
||||
control-panel, but buffer-sizes are controlled with ALSA from
|
||||
hwparams-calls and should not be changed in run-state, I did not
|
||||
implement it here.
|
||||
|
||||
|
||||
System Clock -- suspended !!!!
|
||||
|
||||
Name -- "System Clock Mode"
|
||||
|
||||
Access -- Read Write
|
||||
|
||||
Values -- "Master" "Slave"
|
||||
|
||||
|
||||
!!!! This is a hardware-function but is in conflict with the
|
||||
Clock-source controller, which is a kind of ALSA-standard. I
|
||||
makes sense to set the card to a special mode (master at some
|
||||
frequency or slave), since even not using an Audio-application
|
||||
a studio should have working synchronisations setup. So use
|
||||
Clock-source-controller instead !!!!
|
||||
|
||||
Clock Source
|
||||
|
||||
Name -- "Sample Clock Source"
|
||||
|
||||
Access -- Read Write
|
||||
|
||||
Values -- "AutoSync", "Internal 32.0 kHz", "Internal 44.1 kHz",
|
||||
"Internal 48.0 kHz", "Internal 64.0 kHz", "Internal 88.2 kHz",
|
||||
"Internal 96.0 kHz"
|
||||
|
||||
Choose between Master at a specific Frequency and so also the
|
||||
Speed-mode or Slave (Autosync). Also see "Preferred Sync Ref"
|
||||
|
||||
|
||||
!!!! This is no pure hardware function but was implemented by
|
||||
ALSA by some ALSA-drivers before, so I use it also. !!!
|
||||
|
||||
|
||||
Preferred Sync Ref
|
||||
|
||||
Name -- "Preferred Sync Reference"
|
||||
|
||||
Access -- Read Write
|
||||
|
||||
Values -- "Word" "MADI"
|
||||
|
||||
|
||||
Within the Auto-sync-Mode the preferred Sync Source can be
|
||||
chosen. If it is not available another is used if possible.
|
||||
|
||||
Note: Since MADI has a much higher bit-rate than word-clock, the
|
||||
card should synchronise better in MADI Mode. But since the
|
||||
RME-PLL is very good, there are almost no problems with
|
||||
word-clock too. I never found a difference.
|
||||
|
||||
|
||||
TX 64 channel ---
|
||||
|
||||
Name -- "TX 64 channels mode"
|
||||
|
||||
Access -- Read Write
|
||||
|
||||
Values -- 0 1
|
||||
|
||||
Using 64-channel-modus (1) or 56-channel-modus for
|
||||
MADI-transmission (0).
|
||||
|
||||
|
||||
Note: This control is for output only. Input-mode is detected
|
||||
automatically from hardware sending MADI.
|
||||
|
||||
|
||||
Clear TMS ---
|
||||
|
||||
Name -- "Clear Track Marker"
|
||||
|
||||
Access -- Read Write
|
||||
|
||||
Values -- 0 1
|
||||
|
||||
|
||||
Don't use to lower 5 Audio-bits on AES as additional Bits.
|
||||
|
||||
|
||||
Safe Mode oder Auto Input ---
|
||||
|
||||
Name -- "Safe Mode"
|
||||
|
||||
Access -- Read Write
|
||||
|
||||
Values -- 0 1
|
||||
|
||||
(default on)
|
||||
|
||||
If on (1), then if either the optical or coaxial connection
|
||||
has a failure, there is a takeover to the working one, with no
|
||||
sample failure. Its only useful if you use the second as a
|
||||
backup connection.
|
||||
|
||||
Input ---
|
||||
|
||||
Name -- "Input Select"
|
||||
|
||||
Access -- Read Write
|
||||
|
||||
Values -- optical coaxial
|
||||
|
||||
|
||||
Choosing the Input, optical or coaxial. If Safe-mode is active,
|
||||
this is the preferred Input.
|
||||
|
||||
-------------- Mixer ----------------------
|
||||
|
||||
Mixer
|
||||
|
||||
Name -- "Mixer"
|
||||
|
||||
Access -- Read Write
|
||||
|
||||
Values - <channel-number 0-127> <Value 0-65535>
|
||||
|
||||
|
||||
Here as a first value the channel-index is taken to get/set the
|
||||
corresponding mixer channel, where 0-63 are the input to output
|
||||
fader and 64-127 the playback to outputs fader. Value 0
|
||||
is channel muted 0 and 32768 an amplification of 1.
|
||||
|
||||
Chn 1-64
|
||||
|
||||
fast mixer for the ALSA-mixer utils. The diagonal of the
|
||||
mixer-matrix is implemented from playback to output.
|
||||
|
||||
|
||||
Line Out
|
||||
|
||||
Name -- "Line Out"
|
||||
|
||||
Access -- Read Write
|
||||
|
||||
Values -- 0 1
|
||||
|
||||
Switching on and off the analog out, which has nothing to do
|
||||
with mixing or routing. the analog outs reflects channel 63,64.
|
||||
|
||||
|
||||
--- information (only read access):
|
||||
|
||||
Sample Rate
|
||||
|
||||
Name -- "System Sample Rate"
|
||||
|
||||
Access -- Read-only
|
||||
|
||||
getting the sample rate.
|
||||
|
||||
|
||||
External Rate measured
|
||||
|
||||
Name -- "External Rate"
|
||||
|
||||
Access -- Read only
|
||||
|
||||
|
||||
Should be "Autosync Rate", but Name used is
|
||||
ALSA-Scheme. External Sample frequency liked used on Autosync is
|
||||
reported.
|
||||
|
||||
|
||||
MADI Sync Status
|
||||
|
||||
Name -- "MADI Sync Lock Status"
|
||||
|
||||
Access -- Read
|
||||
|
||||
Values -- 0,1,2
|
||||
|
||||
MADI-Input is 0=Unlocked, 1=Locked, or 2=Synced.
|
||||
|
||||
|
||||
Word Clock Sync Status
|
||||
|
||||
Name -- "Word Clock Lock Status"
|
||||
|
||||
Access -- Read
|
||||
|
||||
Values -- 0,1,2
|
||||
|
||||
Word Clock Input is 0=Unlocked, 1=Locked, or 2=Synced.
|
||||
|
||||
AutoSync
|
||||
|
||||
Name -- "AutoSync Reference"
|
||||
|
||||
Access -- Read
|
||||
|
||||
Values -- "WordClock", "MADI", "None"
|
||||
|
||||
Sync-Reference is either "WordClock", "MADI" or none.
|
||||
|
||||
RX 64ch --- noch nicht implementiert
|
||||
|
||||
MADI-Receiver is in 64 channel mode oder 56 channel mode.
|
||||
|
||||
|
||||
AB_inp --- not tested
|
||||
|
||||
Used input for Auto-Input.
|
||||
|
||||
|
||||
actual Buffer Position --- not implemented
|
||||
|
||||
!!! this is a ALSA internal function, so no control is used !!!
|
||||
|
||||
|
||||
|
||||
Calling Parameter:
|
||||
|
||||
index int array (min = 1, max = 8),
|
||||
"Index value for RME HDSPM interface." card-index within ALSA
|
||||
|
||||
note: ALSA-standard
|
||||
|
||||
id string array (min = 1, max = 8),
|
||||
"ID string for RME HDSPM interface."
|
||||
|
||||
note: ALSA-standard
|
||||
|
||||
enable int array (min = 1, max = 8),
|
||||
"Enable/disable specific HDSPM sound-cards."
|
||||
|
||||
note: ALSA-standard
|
||||
|
||||
precise_ptr int array (min = 1, max = 8),
|
||||
"Enable precise pointer, or disable."
|
||||
|
||||
note: Use only when the application supports this (which is a special case).
|
||||
|
||||
line_outs_monitor int array (min = 1, max = 8),
|
||||
"Send playback streams to analog outs by default."
|
||||
|
||||
|
||||
note: each playback channel is mixed to the same numbered output
|
||||
channel (routed). This is against the ALSA-convention, where all
|
||||
channels have to be muted on after loading the driver, but was
|
||||
used before on other cards, so i historically use it again)
|
||||
|
||||
|
||||
|
||||
enable_monitor int array (min = 1, max = 8),
|
||||
"Enable Analog Out on Channel 63/64 by default."
|
||||
|
||||
note: here the analog output is enabled (but not routed).
|
Some files were not shown because too many files have changed in this diff Show more
Loading…
Reference in a new issue