aboutsummaryrefslogtreecommitdiffstats
path: root/Documentation
diff options
context:
space:
mode:
Diffstat (limited to 'Documentation')
-rw-r--r--Documentation/00-INDEX2
-rw-r--r--Documentation/Changes2
-rw-r--r--Documentation/DocBook/Makefile4
-rw-r--r--Documentation/DocBook/kernel-api.tmpl3
-rw-r--r--Documentation/DocBook/libata.tmpl156
-rw-r--r--Documentation/DocBook/scsidrivers.tmpl193
-rw-r--r--Documentation/DocBook/stylesheet.xsl1
-rw-r--r--Documentation/IPMI.txt146
-rw-r--r--Documentation/SubmittingPatches25
-rw-r--r--Documentation/basic_profiling.txt10
-rw-r--r--Documentation/cdrom/sbpcd16
-rw-r--r--Documentation/cpu-freq/cpufreq-stats.txt128
-rw-r--r--Documentation/cpu-freq/governors.txt14
-rw-r--r--Documentation/cpusets.txt16
-rw-r--r--Documentation/devices.txt1
-rw-r--r--Documentation/dontdiff1
-rw-r--r--Documentation/driver-model/device.txt8
-rw-r--r--Documentation/driver-model/driver.txt51
-rw-r--r--Documentation/dvb/README.dvb-usb (renamed from Documentation/dvb/README.dibusb)195
-rw-r--r--Documentation/dvb/bt8xx.txt25
-rw-r--r--Documentation/fb/intelfb.txt135
-rw-r--r--Documentation/feature-removal-schedule.txt36
-rw-r--r--Documentation/filesystems/ext2.txt2
-rw-r--r--Documentation/filesystems/isofs.txt6
-rw-r--r--Documentation/filesystems/sysfs.txt2
-rw-r--r--Documentation/filesystems/tmpfs.txt6
-rw-r--r--Documentation/filesystems/xip.txt67
-rw-r--r--Documentation/i2c/busses/i2c-sis69x2
-rw-r--r--Documentation/i2c/chips/adm1021111
-rw-r--r--Documentation/i2c/chips/adm102551
-rw-r--r--Documentation/i2c/chips/adm102693
-rw-r--r--Documentation/i2c/chips/adm103135
-rw-r--r--Documentation/i2c/chips/adm9240177
-rw-r--r--Documentation/i2c/chips/asb10072
-rw-r--r--Documentation/i2c/chips/ds1621108
-rw-r--r--Documentation/i2c/chips/eeprom96
-rw-r--r--Documentation/i2c/chips/fscher169
-rw-r--r--Documentation/i2c/chips/gl518sm74
-rw-r--r--Documentation/i2c/chips/it8796
-rw-r--r--Documentation/i2c/chips/lm6357
-rw-r--r--Documentation/i2c/chips/lm7565
-rw-r--r--Documentation/i2c/chips/lm7722
-rw-r--r--Documentation/i2c/chips/lm7882
-rw-r--r--Documentation/i2c/chips/lm8056
-rw-r--r--Documentation/i2c/chips/lm8376
-rw-r--r--Documentation/i2c/chips/lm85221
-rw-r--r--Documentation/i2c/chips/lm8773
-rw-r--r--Documentation/i2c/chips/lm90121
-rw-r--r--Documentation/i2c/chips/lm9237
-rw-r--r--Documentation/i2c/chips/max161929
-rw-r--r--Documentation/i2c/chips/max687554
-rw-r--r--Documentation/i2c/chips/pc87360189
-rw-r--r--Documentation/i2c/chips/pca953947
-rw-r--r--Documentation/i2c/chips/pcf857469
-rw-r--r--Documentation/i2c/chips/pcf859190
-rw-r--r--Documentation/i2c/chips/sis5595106
-rw-r--r--Documentation/i2c/chips/smsc47b397 (renamed from Documentation/i2c/chips/smsc47b397.txt)46
-rw-r--r--Documentation/i2c/chips/smsc47m152
-rw-r--r--Documentation/i2c/chips/via686a65
-rw-r--r--Documentation/i2c/chips/w83627hf66
-rw-r--r--Documentation/i2c/chips/w83781d402
-rw-r--r--Documentation/i2c/chips/w83l785ts39
-rw-r--r--Documentation/i2c/porting-clients2
-rw-r--r--Documentation/i2c/userspace-tools39
-rw-r--r--Documentation/i2c/writing-clients62
-rw-r--r--Documentation/kdump/gdbmacros.txt179
-rw-r--r--Documentation/kdump/kdump.txt141
-rw-r--r--Documentation/kernel-parameters.txt11
-rw-r--r--Documentation/keys.txt319
-rw-r--r--Documentation/networking/00-INDEX4
-rw-r--r--Documentation/networking/dmfe.txt82
-rw-r--r--Documentation/networking/generic-hdlc.txt51
-rw-r--r--Documentation/networking/ip-sysctl.txt56
-rw-r--r--Documentation/networking/multicast.txt1
-rw-r--r--Documentation/networking/net-modules.txt3
-rw-r--r--Documentation/networking/tcp.txt69
-rw-r--r--Documentation/networking/vortex.txt2
-rw-r--r--Documentation/networking/wanpipe.txt622
-rw-r--r--Documentation/power/kernel_threads.txt3
-rw-r--r--Documentation/power/pci.txt38
-rw-r--r--Documentation/power/swsusp.txt84
-rw-r--r--Documentation/power/video.txt3
-rw-r--r--Documentation/power/video_extension.txt19
-rw-r--r--Documentation/s390/CommonIO16
-rw-r--r--Documentation/s390/s390dbf.txt79
-rw-r--r--Documentation/scsi/ChangeLog.megaraid66
-rw-r--r--Documentation/scsi/scsi-changer.txt180
-rw-r--r--Documentation/scsi/scsi_mid_low_api.txt12
-rw-r--r--Documentation/sgi-ioc4.txt45
-rw-r--r--Documentation/sound/alsa/ALSA-Configuration.txt127
-rw-r--r--Documentation/sound/alsa/CMIPCI.txt41
-rw-r--r--Documentation/sound/alsa/DocBook/writing-an-alsa-driver.tmpl6
-rw-r--r--Documentation/sound/alsa/emu10k1-jack.txt74
-rw-r--r--Documentation/sound/alsa/hdspm.txt362
-rw-r--r--Documentation/sysctl/kernel.txt20
-rw-r--r--Documentation/sysrq.txt5
-rw-r--r--Documentation/tty.txt2
-rw-r--r--Documentation/video4linux/CARDLIST.bttv14
-rw-r--r--Documentation/video4linux/CARDLIST.cx8829
-rw-r--r--Documentation/video4linux/CARDLIST.saa713429
-rw-r--r--Documentation/video4linux/CARDLIST.tuner15
-rw-r--r--Documentation/video4linux/hauppauge-wintv-cx88-ir.txt54
-rw-r--r--Documentation/video4linux/lifeview.txt42
-rw-r--r--Documentation/video4linux/not-in-cx2388x-datasheet.txt37
-rw-r--r--Documentation/w1/w1.generic107
105 files changed, 6084 insertions, 1467 deletions
diff --git a/Documentation/00-INDEX b/Documentation/00-INDEX
index 8de8a01a2474..f28a24e0279b 100644
--- a/Documentation/00-INDEX
+++ b/Documentation/00-INDEX
@@ -138,6 +138,8 @@ java.txt
138 - info on the in-kernel binary support for Java(tm). 138 - info on the in-kernel binary support for Java(tm).
139kbuild/ 139kbuild/
140 - directory with info about the kernel build process. 140 - directory with info about the kernel build process.
141kdumpt.txt
142 - mini HowTo on getting the crash dump code to work.
141kernel-doc-nano-HOWTO.txt 143kernel-doc-nano-HOWTO.txt
142 - mini HowTo on generation and location of kernel documentation files. 144 - mini HowTo on generation and location of kernel documentation files.
143kernel-docs.txt 145kernel-docs.txt
diff --git a/Documentation/Changes b/Documentation/Changes
index 57542bc25edd..b37600754762 100644
--- a/Documentation/Changes
+++ b/Documentation/Changes
@@ -63,7 +63,7 @@ o PPP 2.4.0 # pppd --version
63o isdn4k-utils 3.1pre1 # isdnctrl 2>&1|grep version 63o isdn4k-utils 3.1pre1 # isdnctrl 2>&1|grep version
64o nfs-utils 1.0.5 # showmount --version 64o nfs-utils 1.0.5 # showmount --version
65o procps 3.2.0 # ps --version 65o procps 3.2.0 # ps --version
66o oprofile 0.5.3 # oprofiled --version 66o oprofile 0.9 # oprofiled --version
67 67
68Kernel compilation 68Kernel compilation
69================== 69==================
diff --git a/Documentation/DocBook/Makefile b/Documentation/DocBook/Makefile
index e69b3d2e7884..fa3e29ad8a46 100644
--- a/Documentation/DocBook/Makefile
+++ b/Documentation/DocBook/Makefile
@@ -8,7 +8,7 @@
8 8
9DOCBOOKS := wanbook.xml z8530book.xml mcabook.xml videobook.xml \ 9DOCBOOKS := wanbook.xml z8530book.xml mcabook.xml videobook.xml \
10 kernel-hacking.xml kernel-locking.xml deviceiobook.xml \ 10 kernel-hacking.xml kernel-locking.xml deviceiobook.xml \
11 procfs-guide.xml writing_usb_driver.xml scsidrivers.xml \ 11 procfs-guide.xml writing_usb_driver.xml \
12 sis900.xml kernel-api.xml journal-api.xml lsm.xml usb.xml \ 12 sis900.xml kernel-api.xml journal-api.xml lsm.xml usb.xml \
13 gadget.xml libata.xml mtdnand.xml librs.xml 13 gadget.xml libata.xml mtdnand.xml librs.xml
14 14
@@ -49,7 +49,7 @@ installmandocs: mandocs
49KERNELDOC = scripts/kernel-doc 49KERNELDOC = scripts/kernel-doc
50DOCPROC = scripts/basic/docproc 50DOCPROC = scripts/basic/docproc
51 51
52XMLTOFLAGS = -m Documentation/DocBook/stylesheet.xsl 52XMLTOFLAGS = -m $(srctree)/Documentation/DocBook/stylesheet.xsl
53#XMLTOFLAGS += --skip-validation 53#XMLTOFLAGS += --skip-validation
54 54
55### 55###
diff --git a/Documentation/DocBook/kernel-api.tmpl b/Documentation/DocBook/kernel-api.tmpl
index 757cef8f8491..d650ce36485f 100644
--- a/Documentation/DocBook/kernel-api.tmpl
+++ b/Documentation/DocBook/kernel-api.tmpl
@@ -266,7 +266,7 @@ X!Ekernel/module.c
266 <chapter id="hardware"> 266 <chapter id="hardware">
267 <title>Hardware Interfaces</title> 267 <title>Hardware Interfaces</title>
268 <sect1><title>Interrupt Handling</title> 268 <sect1><title>Interrupt Handling</title>
269!Iarch/i386/kernel/irq.c 269!Ikernel/irq/manage.c
270 </sect1> 270 </sect1>
271 271
272 <sect1><title>Resources Management</title> 272 <sect1><title>Resources Management</title>
@@ -338,7 +338,6 @@ X!Earch/i386/kernel/mca.c
338X!Iinclude/linux/device.h 338X!Iinclude/linux/device.h
339--> 339-->
340!Edrivers/base/driver.c 340!Edrivers/base/driver.c
341!Edrivers/base/class_simple.c
342!Edrivers/base/core.c 341!Edrivers/base/core.c
343!Edrivers/base/firmware_class.c 342!Edrivers/base/firmware_class.c
344!Edrivers/base/transport_class.c 343!Edrivers/base/transport_class.c
diff --git a/Documentation/DocBook/libata.tmpl b/Documentation/DocBook/libata.tmpl
index cf2fce7707da..6df1dfd18b65 100644
--- a/Documentation/DocBook/libata.tmpl
+++ b/Documentation/DocBook/libata.tmpl
@@ -14,7 +14,7 @@
14 </authorgroup> 14 </authorgroup>
15 15
16 <copyright> 16 <copyright>
17 <year>2003</year> 17 <year>2003-2005</year>
18 <holder>Jeff Garzik</holder> 18 <holder>Jeff Garzik</holder>
19 </copyright> 19 </copyright>
20 20
@@ -44,30 +44,38 @@
44 44
45<toc></toc> 45<toc></toc>
46 46
47 <chapter id="libataThanks"> 47 <chapter id="libataIntroduction">
48 <title>Thanks</title> 48 <title>Introduction</title>
49 <para> 49 <para>
50 The bulk of the ATA knowledge comes thanks to long conversations with 50 libATA is a library used inside the Linux kernel to support ATA host
51 Andre Hedrick (www.linux-ide.org). 51 controllers and devices. libATA provides an ATA driver API, class
52 transports for ATA and ATAPI devices, and SCSI&lt;-&gt;ATA translation
53 for ATA devices according to the T10 SAT specification.
52 </para> 54 </para>
53 <para> 55 <para>
54 Thanks to Alan Cox for pointing out similarities 56 This Guide documents the libATA driver API, library functions, library
55 between SATA and SCSI, and in general for motivation to hack on 57 internals, and a couple sample ATA low-level drivers.
56 libata.
57 </para>
58 <para>
59 libata's device detection
60 method, ata_pio_devchk, and in general all the early probing was
61 based on extensive study of Hale Landis's probe/reset code in his
62 ATADRVR driver (www.ata-atapi.com).
63 </para> 58 </para>
64 </chapter> 59 </chapter>
65 60
66 <chapter id="libataDriverApi"> 61 <chapter id="libataDriverApi">
67 <title>libata Driver API</title> 62 <title>libata Driver API</title>
63 <para>
64 struct ata_port_operations is defined for every low-level libata
65 hardware driver, and it controls how the low-level driver
66 interfaces with the ATA and SCSI layers.
67 </para>
68 <para>
69 FIS-based drivers will hook into the system with ->qc_prep() and
70 ->qc_issue() high-level hooks. Hardware which behaves in a manner
71 similar to PCI IDE hardware may utilize several generic helpers,
72 defining at a bare minimum the bus I/O addresses of the ATA shadow
73 register blocks.
74 </para>
68 <sect1> 75 <sect1>
69 <title>struct ata_port_operations</title> 76 <title>struct ata_port_operations</title>
70 77
78 <sect2><title>Disable ATA port</title>
71 <programlisting> 79 <programlisting>
72void (*port_disable) (struct ata_port *); 80void (*port_disable) (struct ata_port *);
73 </programlisting> 81 </programlisting>
@@ -78,6 +86,9 @@ void (*port_disable) (struct ata_port *);
78 unplug). 86 unplug).
79 </para> 87 </para>
80 88
89 </sect2>
90
91 <sect2><title>Post-IDENTIFY device configuration</title>
81 <programlisting> 92 <programlisting>
82void (*dev_config) (struct ata_port *, struct ata_device *); 93void (*dev_config) (struct ata_port *, struct ata_device *);
83 </programlisting> 94 </programlisting>
@@ -88,6 +99,9 @@ void (*dev_config) (struct ata_port *, struct ata_device *);
88 issue of SET FEATURES - XFER MODE, and prior to operation. 99 issue of SET FEATURES - XFER MODE, and prior to operation.
89 </para> 100 </para>
90 101
102 </sect2>
103
104 <sect2><title>Set PIO/DMA mode</title>
91 <programlisting> 105 <programlisting>
92void (*set_piomode) (struct ata_port *, struct ata_device *); 106void (*set_piomode) (struct ata_port *, struct ata_device *);
93void (*set_dmamode) (struct ata_port *, struct ata_device *); 107void (*set_dmamode) (struct ata_port *, struct ata_device *);
@@ -108,6 +122,9 @@ void (*post_set_mode) (struct ata_port *ap);
108 ->set_dma_mode() is only called if DMA is possible. 122 ->set_dma_mode() is only called if DMA is possible.
109 </para> 123 </para>
110 124
125 </sect2>
126
127 <sect2><title>Taskfile read/write</title>
111 <programlisting> 128 <programlisting>
112void (*tf_load) (struct ata_port *ap, struct ata_taskfile *tf); 129void (*tf_load) (struct ata_port *ap, struct ata_taskfile *tf);
113void (*tf_read) (struct ata_port *ap, struct ata_taskfile *tf); 130void (*tf_read) (struct ata_port *ap, struct ata_taskfile *tf);
@@ -120,6 +137,9 @@ void (*tf_read) (struct ata_port *ap, struct ata_taskfile *tf);
120 taskfile register values. 137 taskfile register values.
121 </para> 138 </para>
122 139
140 </sect2>
141
142 <sect2><title>ATA command execute</title>
123 <programlisting> 143 <programlisting>
124void (*exec_command)(struct ata_port *ap, struct ata_taskfile *tf); 144void (*exec_command)(struct ata_port *ap, struct ata_taskfile *tf);
125 </programlisting> 145 </programlisting>
@@ -129,17 +149,37 @@ void (*exec_command)(struct ata_port *ap, struct ata_taskfile *tf);
129 ->tf_load(), to be initiated in hardware. 149 ->tf_load(), to be initiated in hardware.
130 </para> 150 </para>
131 151
152 </sect2>
153
154 <sect2><title>Per-cmd ATAPI DMA capabilities filter</title>
155 <programlisting>
156int (*check_atapi_dma) (struct ata_queued_cmd *qc);
157 </programlisting>
158
159 <para>
160Allow low-level driver to filter ATA PACKET commands, returning a status
161indicating whether or not it is OK to use DMA for the supplied PACKET
162command.
163 </para>
164
165 </sect2>
166
167 <sect2><title>Read specific ATA shadow registers</title>
132 <programlisting> 168 <programlisting>
133u8 (*check_status)(struct ata_port *ap); 169u8 (*check_status)(struct ata_port *ap);
134void (*dev_select)(struct ata_port *ap, unsigned int device); 170u8 (*check_altstatus)(struct ata_port *ap);
171u8 (*check_err)(struct ata_port *ap);
135 </programlisting> 172 </programlisting>
136 173
137 <para> 174 <para>
138 Reads the Status ATA shadow register from hardware. On some 175 Reads the Status/AltStatus/Error ATA shadow register from
139 hardware, this has the side effect of clearing the interrupt 176 hardware. On some hardware, reading the Status register has
140 condition. 177 the side effect of clearing the interrupt condition.
141 </para> 178 </para>
142 179
180 </sect2>
181
182 <sect2><title>Select ATA device on bus</title>
143 <programlisting> 183 <programlisting>
144void (*dev_select)(struct ata_port *ap, unsigned int device); 184void (*dev_select)(struct ata_port *ap, unsigned int device);
145 </programlisting> 185 </programlisting>
@@ -147,9 +187,13 @@ void (*dev_select)(struct ata_port *ap, unsigned int device);
147 <para> 187 <para>
148 Issues the low-level hardware command(s) that causes one of N 188 Issues the low-level hardware command(s) that causes one of N
149 hardware devices to be considered 'selected' (active and 189 hardware devices to be considered 'selected' (active and
150 available for use) on the ATA bus. 190 available for use) on the ATA bus. This generally has no
191meaning on FIS-based devices.
151 </para> 192 </para>
152 193
194 </sect2>
195
196 <sect2><title>Reset ATA bus</title>
153 <programlisting> 197 <programlisting>
154void (*phy_reset) (struct ata_port *ap); 198void (*phy_reset) (struct ata_port *ap);
155 </programlisting> 199 </programlisting>
@@ -162,17 +206,31 @@ void (*phy_reset) (struct ata_port *ap);
162 functions ata_bus_reset() or sata_phy_reset() for this hook. 206 functions ata_bus_reset() or sata_phy_reset() for this hook.
163 </para> 207 </para>
164 208
209 </sect2>
210
211 <sect2><title>Control PCI IDE BMDMA engine</title>
165 <programlisting> 212 <programlisting>
166void (*bmdma_setup) (struct ata_queued_cmd *qc); 213void (*bmdma_setup) (struct ata_queued_cmd *qc);
167void (*bmdma_start) (struct ata_queued_cmd *qc); 214void (*bmdma_start) (struct ata_queued_cmd *qc);
215void (*bmdma_stop) (struct ata_port *ap);
216u8 (*bmdma_status) (struct ata_port *ap);
168 </programlisting> 217 </programlisting>
169 218
170 <para> 219 <para>
171 When setting up an IDE BMDMA transaction, these hooks arm 220When setting up an IDE BMDMA transaction, these hooks arm
172 (->bmdma_setup) and fire (->bmdma_start) the hardware's DMA 221(->bmdma_setup), fire (->bmdma_start), and halt (->bmdma_stop)
173 engine. 222the hardware's DMA engine. ->bmdma_status is used to read the standard
223PCI IDE DMA Status register.
174 </para> 224 </para>
175 225
226 <para>
227These hooks are typically either no-ops, or simply not implemented, in
228FIS-based drivers.
229 </para>
230
231 </sect2>
232
233 <sect2><title>High-level taskfile hooks</title>
176 <programlisting> 234 <programlisting>
177void (*qc_prep) (struct ata_queued_cmd *qc); 235void (*qc_prep) (struct ata_queued_cmd *qc);
178int (*qc_issue) (struct ata_queued_cmd *qc); 236int (*qc_issue) (struct ata_queued_cmd *qc);
@@ -190,20 +248,26 @@ int (*qc_issue) (struct ata_queued_cmd *qc);
190 ->qc_issue is used to make a command active, once the hardware 248 ->qc_issue is used to make a command active, once the hardware
191 and S/G tables have been prepared. IDE BMDMA drivers use the 249 and S/G tables have been prepared. IDE BMDMA drivers use the
192 helper function ata_qc_issue_prot() for taskfile protocol-based 250 helper function ata_qc_issue_prot() for taskfile protocol-based
193 dispatch. More advanced drivers roll their own ->qc_issue 251 dispatch. More advanced drivers implement their own ->qc_issue.
194 implementation, using this as the "issue new ATA command to
195 hardware" hook.
196 </para> 252 </para>
197 253
254 </sect2>
255
256 <sect2><title>Timeout (error) handling</title>
198 <programlisting> 257 <programlisting>
199void (*eng_timeout) (struct ata_port *ap); 258void (*eng_timeout) (struct ata_port *ap);
200 </programlisting> 259 </programlisting>
201 260
202 <para> 261 <para>
203 This is a high level error handling function, called from the 262This is a high level error handling function, called from the
204 error handling thread, when a command times out. 263error handling thread, when a command times out. Most newer
264hardware will implement its own error handling code here. IDE BMDMA
265drivers may use the helper function ata_eng_timeout().
205 </para> 266 </para>
206 267
268 </sect2>
269
270 <sect2><title>Hardware interrupt handling</title>
207 <programlisting> 271 <programlisting>
208irqreturn_t (*irq_handler)(int, void *, struct pt_regs *); 272irqreturn_t (*irq_handler)(int, void *, struct pt_regs *);
209void (*irq_clear) (struct ata_port *); 273void (*irq_clear) (struct ata_port *);
@@ -216,6 +280,9 @@ void (*irq_clear) (struct ata_port *);
216 is quiet. 280 is quiet.
217 </para> 281 </para>
218 282
283 </sect2>
284
285 <sect2><title>SATA phy read/write</title>
219 <programlisting> 286 <programlisting>
220u32 (*scr_read) (struct ata_port *ap, unsigned int sc_reg); 287u32 (*scr_read) (struct ata_port *ap, unsigned int sc_reg);
221void (*scr_write) (struct ata_port *ap, unsigned int sc_reg, 288void (*scr_write) (struct ata_port *ap, unsigned int sc_reg,
@@ -227,6 +294,9 @@ void (*scr_write) (struct ata_port *ap, unsigned int sc_reg,
227 if ->phy_reset hook called the sata_phy_reset() helper function. 294 if ->phy_reset hook called the sata_phy_reset() helper function.
228 </para> 295 </para>
229 296
297 </sect2>
298
299 <sect2><title>Init and shutdown</title>
230 <programlisting> 300 <programlisting>
231int (*port_start) (struct ata_port *ap); 301int (*port_start) (struct ata_port *ap);
232void (*port_stop) (struct ata_port *ap); 302void (*port_stop) (struct ata_port *ap);
@@ -240,15 +310,17 @@ void (*host_stop) (struct ata_host_set *host_set);
240 tasks. 310 tasks.
241 </para> 311 </para>
242 <para> 312 <para>
243 ->host_stop() is called when the rmmod or hot unplug process
244 begins. The hook must stop all hardware interrupts, DMA
245 engines, etc.
246 </para>
247 <para>
248 ->port_stop() is called after ->host_stop(). It's sole function 313 ->port_stop() is called after ->host_stop(). It's sole function
249 is to release DMA/memory resources, now that they are no longer 314 is to release DMA/memory resources, now that they are no longer
250 actively being used. 315 actively being used.
251 </para> 316 </para>
317 <para>
318 ->host_stop() is called after all ->port_stop() calls
319have completed. The hook must finalize hardware shutdown, release DMA
320and other resources, etc.
321 </para>
322
323 </sect2>
252 324
253 </sect1> 325 </sect1>
254 </chapter> 326 </chapter>
@@ -279,4 +351,24 @@ void (*host_stop) (struct ata_host_set *host_set);
279!Idrivers/scsi/sata_sil.c 351!Idrivers/scsi/sata_sil.c
280 </chapter> 352 </chapter>
281 353
354 <chapter id="libataThanks">
355 <title>Thanks</title>
356 <para>
357 The bulk of the ATA knowledge comes thanks to long conversations with
358 Andre Hedrick (www.linux-ide.org), and long hours pondering the ATA
359 and SCSI specifications.
360 </para>
361 <para>
362 Thanks to Alan Cox for pointing out similarities
363 between SATA and SCSI, and in general for motivation to hack on
364 libata.
365 </para>
366 <para>
367 libata's device detection
368 method, ata_pio_devchk, and in general all the early probing was
369 based on extensive study of Hale Landis's probe/reset code in his
370 ATADRVR driver (www.ata-atapi.com).
371 </para>
372 </chapter>
373
282</book> 374</book>
diff --git a/Documentation/DocBook/scsidrivers.tmpl b/Documentation/DocBook/scsidrivers.tmpl
deleted file mode 100644
index d058e65daf19..000000000000
--- a/Documentation/DocBook/scsidrivers.tmpl
+++ /dev/null
@@ -1,193 +0,0 @@
1<?xml version="1.0" encoding="UTF-8"?>
2<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN"
3 "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd" []>
4
5<book id="scsidrivers">
6 <bookinfo>
7 <title>SCSI Subsystem Interfaces</title>
8
9 <authorgroup>
10 <author>
11 <firstname>Douglas</firstname>
12 <surname>Gilbert</surname>
13 <affiliation>
14 <address>
15 <email>dgilbert@interlog.com</email>
16 </address>
17 </affiliation>
18 </author>
19 </authorgroup>
20 <pubdate>2003-08-11</pubdate>
21
22 <copyright>
23 <year>2002</year>
24 <year>2003</year>
25 <holder>Douglas Gilbert</holder>
26 </copyright>
27
28 <legalnotice>
29 <para>
30 This documentation is free software; you can redistribute
31 it and/or modify it under the terms of the GNU General Public
32 License as published by the Free Software Foundation; either
33 version 2 of the License, or (at your option) any later
34 version.
35 </para>
36
37 <para>
38 This program is distributed in the hope that it will be
39 useful, but WITHOUT ANY WARRANTY; without even the implied
40 warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
41 See the GNU General Public License for more details.
42 </para>
43
44 <para>
45 You should have received a copy of the GNU General Public
46 License along with this program; if not, write to the Free
47 Software Foundation, Inc., 59 Temple Place, Suite 330, Boston,
48 MA 02111-1307 USA
49 </para>
50
51 <para>
52 For more details see the file COPYING in the source
53 distribution of Linux.
54 </para>
55 </legalnotice>
56
57 </bookinfo>
58
59<toc></toc>
60
61 <chapter id="intro">
62 <title>Introduction</title>
63 <para>
64This document outlines the interface between the Linux scsi mid level
65and lower level drivers. Lower level drivers are variously called HBA
66(host bus adapter) drivers, host drivers (HD) or pseudo adapter drivers.
67The latter alludes to the fact that a lower level driver may be a
68bridge to another IO subsystem (and the "ide-scsi" driver is an example
69of this). There can be many lower level drivers active in a running
70system, but only one per hardware type. For example, the aic7xxx driver
71controls adaptec controllers based on the 7xxx chip series. Most lower
72level drivers can control one or more scsi hosts (a.k.a. scsi initiators).
73 </para>
74<para>
75This document can been found in an ASCII text file in the linux kernel
76source: <filename>Documentation/scsi/scsi_mid_low_api.txt</filename> .
77It currently hold a little more information than this document. The
78<filename>drivers/scsi/hosts.h</filename> and <filename>
79drivers/scsi/scsi.h</filename> headers contain descriptions of members
80of important structures for the scsi subsystem.
81</para>
82 </chapter>
83
84 <chapter id="driver-struct">
85 <title>Driver structure</title>
86 <para>
87Traditionally a lower level driver for the scsi subsystem has been
88at least two files in the drivers/scsi directory. For example, a
89driver called "xyz" has a header file "xyz.h" and a source file
90"xyz.c". [Actually there is no good reason why this couldn't all
91be in one file.] Some drivers that have been ported to several operating
92systems (e.g. aic7xxx which has separate files for generic and
93OS-specific code) have more than two files. Such drivers tend to have
94their own directory under the drivers/scsi directory.
95 </para>
96 <para>
97scsi_module.c is normally included at the end of a lower
98level driver. For it to work a declaration like this is needed before
99it is included:
100<programlisting>
101 static Scsi_Host_Template driver_template = DRIVER_TEMPLATE;
102 /* DRIVER_TEMPLATE should contain pointers to supported interface
103 functions. Scsi_Host_Template is defined hosts.h */
104 #include "scsi_module.c"
105</programlisting>
106 </para>
107 <para>
108The scsi_module.c assumes the name "driver_template" is appropriately
109defined. It contains 2 functions:
110<orderedlist>
111<listitem><para>
112 init_this_scsi_driver() called during builtin and module driver
113 initialization: invokes mid level's scsi_register_host()
114</para></listitem>
115<listitem><para>
116 exit_this_scsi_driver() called during closedown: invokes
117 mid level's scsi_unregister_host()
118</para></listitem>
119</orderedlist>
120 </para>
121<para>
122When a new, lower level driver is being added to Linux, the following
123files (all found in the drivers/scsi directory) will need some attention:
124Makefile, Config.help and Config.in . It is probably best to look at what
125an existing lower level driver does in this regard.
126</para>
127 </chapter>
128
129 <chapter id="intfunctions">
130 <title>Interface Functions</title>
131!EDocumentation/scsi/scsi_mid_low_api.txt
132 </chapter>
133
134 <chapter id="locks">
135 <title>Locks</title>
136<para>
137Each Scsi_Host instance has a spin_lock called Scsi_Host::default_lock
138which is initialized in scsi_register() [found in hosts.c]. Within the
139same function the Scsi_Host::host_lock pointer is initialized to point
140at default_lock with the scsi_assign_lock() function. Thereafter
141lock and unlock operations performed by the mid level use the
142Scsi_Host::host_lock pointer.
143</para>
144<para>
145Lower level drivers can override the use of Scsi_Host::default_lock by
146using scsi_assign_lock(). The earliest opportunity to do this would
147be in the detect() function after it has invoked scsi_register(). It
148could be replaced by a coarser grain lock (e.g. per driver) or a
149lock of equal granularity (i.e. per host). Using finer grain locks
150(e.g. per scsi device) may be possible by juggling locks in
151queuecommand().
152</para>
153 </chapter>
154
155 <chapter id="changes">
156 <title>Changes since lk 2.4 series</title>
157<para>
158io_request_lock has been replaced by several finer grained locks. The lock
159relevant to lower level drivers is Scsi_Host::host_lock and there is one
160per scsi host.
161</para>
162<para>
163The older error handling mechanism has been removed. This means the
164lower level interface functions abort() and reset() have been removed.
165</para>
166<para>
167In the 2.4 series the scsi subsystem configuration descriptions were
168aggregated with the configuration descriptions from all other Linux
169subsystems in the Documentation/Configure.help file. In the 2.5 series,
170the scsi subsystem now has its own (much smaller) drivers/scsi/Config.help
171file.
172</para>
173 </chapter>
174
175 <chapter id="credits">
176 <title>Credits</title>
177<para>
178The following people have contributed to this document:
179<orderedlist>
180<listitem><para>
181Mike Anderson <email>andmike@us.ibm.com</email>
182</para></listitem>
183<listitem><para>
184James Bottomley <email>James.Bottomley@steeleye.com</email>
185</para></listitem>
186<listitem><para>
187Patrick Mansfield <email>patmans@us.ibm.com</email>
188</para></listitem>
189</orderedlist>
190</para>
191 </chapter>
192
193</book>
diff --git a/Documentation/DocBook/stylesheet.xsl b/Documentation/DocBook/stylesheet.xsl
index e14c21dda403..64be9f7ee3bb 100644
--- a/Documentation/DocBook/stylesheet.xsl
+++ b/Documentation/DocBook/stylesheet.xsl
@@ -2,4 +2,5 @@
2<stylesheet xmlns="http://www.w3.org/1999/XSL/Transform" version="1.0"> 2<stylesheet xmlns="http://www.w3.org/1999/XSL/Transform" version="1.0">
3<param name="chunk.quietly">1</param> 3<param name="chunk.quietly">1</param>
4<param name="funcsynopsis.style">ansi</param> 4<param name="funcsynopsis.style">ansi</param>
5<param name="funcsynopsis.tabular.threshold">80</param>
5</stylesheet> 6</stylesheet>
diff --git a/Documentation/IPMI.txt b/Documentation/IPMI.txt
index 90d10e708ca3..84d3d4d10c17 100644
--- a/Documentation/IPMI.txt
+++ b/Documentation/IPMI.txt
@@ -25,9 +25,10 @@ subject and I can't cover it all here!
25Configuration 25Configuration
26------------- 26-------------
27 27
28The LinuxIPMI driver is modular, which means you have to pick several 28The Linux IPMI driver is modular, which means you have to pick several
29things to have it work right depending on your hardware. Most of 29things to have it work right depending on your hardware. Most of
30these are available in the 'Character Devices' menu. 30these are available in the 'Character Devices' menu then the IPMI
31menu.
31 32
32No matter what, you must pick 'IPMI top-level message handler' to use 33No matter what, you must pick 'IPMI top-level message handler' to use
33IPMI. What you do beyond that depends on your needs and hardware. 34IPMI. 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.
35The message handler does not provide any user-level interfaces. 36The message handler does not provide any user-level interfaces.
36Kernel code (like the watchdog) can still use it. If you need access 37Kernel code (like the watchdog) can still use it. If you need access
37from userland, you need to select 'Device interface for IPMI' if you 38from userland, you need to select 'Device interface for IPMI' if you
38want access through a device driver. Another interface is also 39want access through a device driver.
39available, you may select 'IPMI sockets' in the 'Networking Support' 40
40main menu. This provides a socket interface to IPMI. You may select 41The driver interface depends on your hardware. If your system
41both of these at the same time, they will both work together. 42properly provides the SMBIOS info for IPMI, the driver will detect it
42 43and just work. If you have a board with a standard interface (These
43The driver interface depends on your hardware. If you have a board 44will generally be either "KCS", "SMIC", or "BT", consult your hardware
44with a standard interface (These will generally be either "KCS", 45manual), choose the 'IPMI SI handler' option. A driver also exists
45"SMIC", or "BT", consult your hardware manual), choose the 'IPMI SI 46for direct I2C access to the IPMI management controller. Some boards
46handler' option. A driver also exists for direct I2C access to the 47support this, but it is unknown if it will work on every board. For
47IPMI management controller. Some boards support this, but it is 48this, choose 'IPMI SMBus handler', but be ready to try to do some
48unknown if it will work on every board. For this, choose 'IPMI SMBus 49figuring to see if it will work on your system if the SMBIOS/APCI
49handler', but be ready to try to do some figuring to see if it will 50information is wrong or not present. It is fairly safe to have both
50work. 51these enabled and let the drivers auto-detect what is present.
51
52There is also a KCS-only driver interface supplied, but it is
53depracated in favor of the SI interface.
54 52
55You should generally enable ACPI on your system, as systems with IPMI 53You should generally enable ACPI on your system, as systems with IPMI
56should have ACPI tables describing them. 54can have ACPI tables describing them.
57 55
58If you have a standard interface and the board manufacturer has done 56If you have a standard interface and the board manufacturer has done
59their job correctly, the IPMI controller should be automatically 57their job correctly, the IPMI controller should be automatically
60detect (via ACPI or SMBIOS tables) and should just work. Sadly, many 58detected (via ACPI or SMBIOS tables) and should just work. Sadly,
61boards do not have this information. The driver attempts standard 59many boards do not have this information. The driver attempts
62defaults, but they may not work. If you fall into this situation, you 60standard defaults, but they may not work. If you fall into this
63need to read the section below named 'The SI Driver' on how to 61situation, you need to read the section below named 'The SI Driver' or
64hand-configure your system. 62"The SMBus Driver" on how to hand-configure your system.
65 63
66IPMI defines a standard watchdog timer. You can enable this with the 64IPMI defines a standard watchdog timer. You can enable this with the
67'IPMI Watchdog Timer' config option. If you compile the driver into 65'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
73Cards' menu, enable 'Watchdog Timer Support', and enable the option 71Cards' menu, enable 'Watchdog Timer Support', and enable the option
74'Disable watchdog shutdown on close'. 72'Disable watchdog shutdown on close'.
75 73
74IPMI systems can often be powered off using IPMI commands. Select
75'IPMI Poweroff' to do this. The driver will auto-detect if the system
76can be powered off by IPMI. It is safe to enable this even if your
77system doesn't support this option. This works on ATCA systems, the
78Radisys CPI1 card, and any IPMI system that supports standard chassis
79management commands.
80
81If you want the driver to put an event into the event log on a panic,
82enable the 'Generate a panic event to all BMCs on a panic' option. If
83you want the whole panic string put into the event log using OEM
84events, enable the 'Generate OEM events containing the panic string'
85option.
76 86
77Basic Design 87Basic Design
78------------ 88------------
@@ -80,7 +90,7 @@ Basic Design
80The Linux IPMI driver is designed to be very modular and flexible, you 90The Linux IPMI driver is designed to be very modular and flexible, you
81only need to take the pieces you need and you can use it in many 91only need to take the pieces you need and you can use it in many
82different ways. Because of that, it's broken into many chunks of 92different ways. Because of that, it's broken into many chunks of
83code. These chunks are: 93code. These chunks (by module name) are:
84 94
85ipmi_msghandler - This is the central piece of software for the IPMI 95ipmi_msghandler - This is the central piece of software for the IPMI
86system. It handles all messages, message timing, and responses. The 96system. It handles all messages, message timing, and responses. The
@@ -93,18 +103,26 @@ ipmi_devintf - This provides a userland IOCTL interface for the IPMI
93driver, each open file for this device ties in to the message handler 103driver, each open file for this device ties in to the message handler
94as an IPMI user. 104as an IPMI user.
95 105
96ipmi_si - A driver for various system interfaces. This supports 106ipmi_si - A driver for various system interfaces. This supports KCS,
97KCS, SMIC, and may support BT in the future. Unless you have your own 107SMIC, and BT interfaces. Unless you have an SMBus interface or your
98custom interface, you probably need to use this. 108own custom interface, you probably need to use this.
99 109
100ipmi_smb - A driver for accessing BMCs on the SMBus. It uses the 110ipmi_smb - A driver for accessing BMCs on the SMBus. It uses the
101I2C kernel driver's SMBus interfaces to send and receive IPMI messages 111I2C kernel driver's SMBus interfaces to send and receive IPMI messages
102over the SMBus. 112over the SMBus.
103 113
104af_ipmi - A network socket interface to IPMI. This doesn't take up 114ipmi_watchdog - IPMI requires systems to have a very capable watchdog
105a character device in your system. 115timer. This driver implements the standard Linux watchdog timer
116interface on top of the IPMI message handler.
117
118ipmi_poweroff - Some systems support the ability to be turned off via
119IPMI commands.
106 120
107Note that the KCS-only interface ahs been removed. 121These are all individually selectable via configuration options.
122
123Note that the KCS-only interface has been removed. The af_ipmi driver
124is no longer supported and has been removed because it was impossible
125to do 32 bit emulation on 64-bit kernels with it.
108 126
109Much documentation for the interface is in the include files. The 127Much documentation for the interface is in the include files. The
110IPMI include files are: 128IPMI include files are:
@@ -424,7 +442,7 @@ at module load time (for a module) with:
424 modprobe ipmi_smb.o 442 modprobe ipmi_smb.o
425 addr=<adapter1>,<i2caddr1>[,<adapter2>,<i2caddr2>[,...]] 443 addr=<adapter1>,<i2caddr1>[,<adapter2>,<i2caddr2>[,...]]
426 dbg=<flags1>,<flags2>... 444 dbg=<flags1>,<flags2>...
427 [defaultprobe=0] [dbg_probe=1] 445 [defaultprobe=1] [dbg_probe=1]
428 446
429The addresses are specified in pairs, the first is the adapter ID and the 447The addresses are specified in pairs, the first is the adapter ID and the
430second is the I2C address on that adapter. 448second 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
532device to close it, or the timer will not stop. This is a new semantic 550device to close it, or the timer will not stop. This is a new semantic
533for the driver, but makes it consistent with the rest of the watchdog 551for the driver, but makes it consistent with the rest of the watchdog
534drivers in Linux. 552drivers in Linux.
553
554
555Panic Timeouts
556--------------
557
558The OpenIPMI driver supports the ability to put semi-custom and custom
559events in the system event log if a panic occurs. if you enable the
560'Generate a panic event to all BMCs on a panic' option, you will get
561one event on a panic in a standard IPMI event format. If you enable
562the 'Generate OEM events containing the panic string' option, you will
563also get a bunch of OEM events holding the panic string.
564
565
566The field settings of the events are:
567* Generator ID: 0x21 (kernel)
568* EvM Rev: 0x03 (this event is formatting in IPMI 1.0 format)
569* Sensor Type: 0x20 (OS critical stop sensor)
570* Sensor #: The first byte of the panic string (0 if no panic string)
571* Event Dir | Event Type: 0x6f (Assertion, sensor-specific event info)
572* Event Data 1: 0xa1 (Runtime stop in OEM bytes 2 and 3)
573* Event data 2: second byte of panic string
574* Event data 3: third byte of panic string
575See the IPMI spec for the details of the event layout. This event is
576always sent to the local management controller. It will handle routing
577the message to the right place
578
579Other OEM events have the following format:
580Record ID (bytes 0-1): Set by the SEL.
581Record type (byte 2): 0xf0 (OEM non-timestamped)
582byte 3: The slave address of the card saving the panic
583byte 4: A sequence number (starting at zero)
584The rest of the bytes (11 bytes) are the panic string. If the panic string
585is longer than 11 bytes, multiple messages will be sent with increasing
586sequence numbers.
587
588Because you cannot send OEM events using the standard interface, this
589function will attempt to find an SEL and add the events there. It
590will first query the capabilities of the local management controller.
591If it has an SEL, then they will be stored in the SEL of the local
592management controller. If not, and the local management controller is
593an event generator, the event receiver from the local management
594controller will be queried and the events sent to the SEL on that
595device. Otherwise, the events go nowhere since there is nowhere to
596send them.
597
598
599Poweroff
600--------
601
602If the poweroff capability is selected, the IPMI driver will install
603a shutdown function into the standard poweroff function pointer. This
604is in the ipmi_poweroff module. When the system requests a powerdown,
605it will send the proper IPMI commands to do this. This is supported on
606several platforms.
607
608There is a module parameter named "poweroff_control" that may either be zero
609(do a power down) or 2 (do a power cycle, power the system off, then power
610it on in a few seconds). Setting ipmi_poweroff.poweroff_control=x will do
611the same thing on the kernel command line. The parameter is also available
612via the proc filesystem in /proc/ipmi/poweroff_control. Note that if the
613system does not support power cycling, it will always to the power off.
614
615Note that if you have ACPI enabled, the system will prefer using ACPI to
616power off.
diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
index 9838d32b2fe7..4d1f41b84ebc 100644
--- a/Documentation/SubmittingPatches
+++ b/Documentation/SubmittingPatches
@@ -132,21 +132,6 @@ which require discussion or do not have a clear advantage should
132usually be sent first to linux-kernel. Only after the patch is 132usually be sent first to linux-kernel. Only after the patch is
133discussed should the patch then be submitted to Linus. 133discussed should the patch then be submitted to Linus.
134 134
135For small patches you may want to CC the Trivial Patch Monkey
136trivial@rustcorp.com.au set up by Rusty Russell; which collects "trivial"
137patches. Trivial patches must qualify for one of the following rules:
138 Spelling fixes in documentation
139 Spelling fixes which could break grep(1).
140 Warning fixes (cluttering with useless warnings is bad)
141 Compilation fixes (only if they are actually correct)
142 Runtime fixes (only if they actually fix things)
143 Removing use of deprecated functions/macros (eg. check_region).
144 Contact detail and documentation fixes
145 Non-portable code replaced by portable code (even in arch-specific,
146 since people copy, as long as it's trivial)
147 Any fix by the author/maintainer of the file. (ie. patch monkey
148 in re-transmission mode)
149
150 135
151 136
1525) Select your CC (e-mail carbon copy) list. 1375) 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
271pass it on as a open-source patch. The rules are pretty simple: if you 256pass it on as a open-source patch. The rules are pretty simple: if you
272can certify the below: 257can certify the below:
273 258
274 Developer's Certificate of Origin 1.0 259 Developer's Certificate of Origin 1.1
275 260
276 By making a contribution to this project, I certify that: 261 By making a contribution to this project, I certify that:
277 262
@@ -291,9 +276,15 @@ can certify the below:
291 person who certified (a), (b) or (c) and I have not modified 276 person who certified (a), (b) or (c) and I have not modified
292 it. 277 it.
293 278
279 (d) I understand and agree that this project and the contribution
280 are public and that a record of the contribution (including all
281 personal information I submit with it, including my sign-off) is
282 maintained indefinitely and may be redistributed consistent with
283 this project or the open source license(s) involved.
284
294then you just add a line saying 285then you just add a line saying
295 286
296 Signed-off-by: Random J Developer <random@developer.org> 287 Signed-off-by: Random J Developer <random@developer.example.org>
297 288
298Some people also put extra tags at the end. They'll just be ignored for 289Some people also put extra tags at the end. They'll just be ignored for
299now, but you can do this to mark internal company procedures or just 290now, but you can do this to mark internal company procedures or just
diff --git a/Documentation/basic_profiling.txt b/Documentation/basic_profiling.txt
index 65e3dc2d4437..8764e9f70821 100644
--- a/Documentation/basic_profiling.txt
+++ b/Documentation/basic_profiling.txt
@@ -27,9 +27,13 @@ dump output readprofile -m /boot/System.map > captured_profile
27 27
28Oprofile 28Oprofile
29-------- 29--------
30Get the source (I use 0.8) from http://oprofile.sourceforge.net/ 30
31and add "idle=poll" to the kernel command line 31Get the source (see Changes for required version) from
32http://oprofile.sourceforge.net/ and add "idle=poll" to the kernel command
33line.
34
32Configure with CONFIG_PROFILING=y and CONFIG_OPROFILE=y & reboot on new kernel 35Configure with CONFIG_PROFILING=y and CONFIG_OPROFILE=y & reboot on new kernel
36
33./configure --with-kernel-support 37./configure --with-kernel-support
34make install 38make install
35 39
@@ -46,7 +50,7 @@ start opcontrol --start
46stop opcontrol --stop 50stop opcontrol --stop
47dump output opreport > output_file 51dump output opreport > output_file
48 52
49To only report on the kernel, run opreport /boot/vmlinux > output_file 53To only report on the kernel, run opreport -l /boot/vmlinux > output_file
50 54
51A reset is needed to clear old statistics, which survive a reboot. 55A reset is needed to clear old statistics, which survive a reboot.
52 56
diff --git a/Documentation/cdrom/sbpcd b/Documentation/cdrom/sbpcd
index d1825dffca34..b3ba63f4ce3e 100644
--- a/Documentation/cdrom/sbpcd
+++ b/Documentation/cdrom/sbpcd
@@ -419,6 +419,7 @@ into the file "track01":
419 */ 419 */
420#include <stdio.h> 420#include <stdio.h>
421#include <sys/ioctl.h> 421#include <sys/ioctl.h>
422#include <sys/types.h>
422#include <linux/cdrom.h> 423#include <linux/cdrom.h>
423 424
424static struct cdrom_tochdr hdr; 425static struct cdrom_tochdr hdr;
@@ -429,7 +430,7 @@ static int datafile, drive;
429static int i, j, limit, track, err; 430static int i, j, limit, track, err;
430static char filename[32]; 431static char filename[32];
431 432
432main(int argc, char *argv[]) 433int main(int argc, char *argv[])
433{ 434{
434/* 435/*
435 * open /dev/cdrom 436 * open /dev/cdrom
@@ -516,6 +517,7 @@ entry[track+1].cdte_addr.lba=entry[track].cdte_addr.lba+300;
516 } 517 }
517 arg.addr.lba++; 518 arg.addr.lba++;
518 } 519 }
520 return 0;
519} 521}
520/*===================== end program ========================================*/ 522/*===================== end program ========================================*/
521 523
@@ -564,15 +566,16 @@ Appendix -- the "cdtester" utility:
564#include <stdio.h> 566#include <stdio.h>
565#include <malloc.h> 567#include <malloc.h>
566#include <sys/ioctl.h> 568#include <sys/ioctl.h>
569#include <sys/types.h>
567#include <linux/cdrom.h> 570#include <linux/cdrom.h>
568 571
569#ifdef AZT_PRIVATE_IOCTLS 572#ifdef AZT_PRIVATE_IOCTLS
570#include <linux/../../drivers/cdrom/aztcd.h> 573#include <linux/../../drivers/cdrom/aztcd.h>
571#endif AZT_PRIVATE_IOCTLS 574#endif /* AZT_PRIVATE_IOCTLS */
572#ifdef SBP_PRIVATE_IOCTLS 575#ifdef SBP_PRIVATE_IOCTLS
573#include <linux/../../drivers/cdrom/sbpcd.h> 576#include <linux/../../drivers/cdrom/sbpcd.h>
574#include <linux/fs.h> 577#include <linux/fs.h>
575#endif SBP_PRIVATE_IOCTLS 578#endif /* SBP_PRIVATE_IOCTLS */
576 579
577struct cdrom_tochdr hdr; 580struct cdrom_tochdr hdr;
578struct cdrom_tochdr tocHdr; 581struct cdrom_tochdr tocHdr;
@@ -590,7 +593,7 @@ union
590 struct cdrom_msf msf; 593 struct cdrom_msf msf;
591 unsigned char buf[CD_FRAMESIZE_RAW]; 594 unsigned char buf[CD_FRAMESIZE_RAW];
592} azt; 595} azt;
593#endif AZT_PRIVATE_IOCTLS 596#endif /* AZT_PRIVATE_IOCTLS */
594int i, i1, i2, i3, j, k; 597int i, i1, i2, i3, j, k;
595unsigned char sequence=0; 598unsigned char sequence=0;
596unsigned char command[80]; 599unsigned char command[80];
@@ -738,7 +741,7 @@ void display(int size,unsigned char *buffer)
738 } 741 }
739} 742}
740 743
741main(int argc, char *argv[]) 744int main(int argc, char *argv[])
742{ 745{
743 printf("\nTesting tool for a CDROM driver's audio functions V0.1\n"); 746 printf("\nTesting tool for a CDROM driver's audio functions V0.1\n");
744 printf("(C) 1995 Eberhard Moenkeberg <emoenke@gwdg.de>\n"); 747 printf("(C) 1995 Eberhard Moenkeberg <emoenke@gwdg.de>\n");
@@ -1046,12 +1049,13 @@ main(int argc, char *argv[])
1046 rc=ioctl(drive,CDROMAUDIOBUFSIZ,j); 1049 rc=ioctl(drive,CDROMAUDIOBUFSIZ,j);
1047 printf("%d frames granted.\n",rc); 1050 printf("%d frames granted.\n",rc);
1048 break; 1051 break;
1049#endif SBP_PRIVATE_IOCTLS 1052#endif /* SBP_PRIVATE_IOCTLS */
1050 default: 1053 default:
1051 printf("unknown command: \"%s\".\n",command); 1054 printf("unknown command: \"%s\".\n",command);
1052 break; 1055 break;
1053 } 1056 }
1054 } 1057 }
1058 return 0;
1055} 1059}
1056/*==========================================================================*/ 1060/*==========================================================================*/
1057 1061
diff --git a/Documentation/cpu-freq/cpufreq-stats.txt b/Documentation/cpu-freq/cpufreq-stats.txt
new file mode 100644
index 000000000000..e2d1e760b4ba
--- /dev/null
+++ b/Documentation/cpu-freq/cpufreq-stats.txt
@@ -0,0 +1,128 @@
1
2 CPU frequency and voltage scaling statictics in the Linux(TM) kernel
3
4
5 L i n u x c p u f r e q - s t a t s d r i v e r
6
7 - information for users -
8
9
10 Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
11
12Contents
131. Introduction
142. Statistics Provided (with example)
153. Configuring cpufreq-stats
16
17
181. Introduction
19
20cpufreq-stats is a driver that provices CPU frequency statistics for each CPU.
21This statistics is provided in /sysfs as a bunch of read_only interfaces. This
22interface (when configured) will appear in a seperate directory under cpufreq
23in /sysfs (<sysfs root>/devices/system/cpu/cpuX/cpufreq/stats/) for each CPU.
24Various statistics will form read_only files under this directory.
25
26This driver is designed to be independent of any particular cpufreq_driver
27that may be running on your CPU. So, it will work with any cpufreq_driver.
28
29
302. Statistics Provided (with example)
31
32cpufreq stats provides following statistics (explained in detail below).
33- time_in_state
34- total_trans
35- trans_table
36
37All the statistics will be from the time the stats driver has been inserted
38to the time when a read of a particular statistic is done. Obviously, stats
39driver will not have any information about the the frequcny transitions before
40the stats driver insertion.
41
42--------------------------------------------------------------------------------
43<mysystem>:/sys/devices/system/cpu/cpu0/cpufreq/stats # ls -l
44total 0
45drwxr-xr-x 2 root root 0 May 14 16:06 .
46drwxr-xr-x 3 root root 0 May 14 15:58 ..
47-r--r--r-- 1 root root 4096 May 14 16:06 time_in_state
48-r--r--r-- 1 root root 4096 May 14 16:06 total_trans
49-r--r--r-- 1 root root 4096 May 14 16:06 trans_table
50--------------------------------------------------------------------------------
51
52- time_in_state
53This gives the amount of time spent in each of the frequencies supported by
54this CPU. The cat output will have "<frequency> <time>" pair in each line, which
55will mean this CPU spent <time> usertime units of time at <frequency>. Output
56will have one line for each of the supported freuencies. usertime units here
57is 10mS (similar to other time exported in /proc).
58
59--------------------------------------------------------------------------------
60<mysystem>:/sys/devices/system/cpu/cpu0/cpufreq/stats # cat time_in_state
613600000 2089
623400000 136
633200000 34
643000000 67
652800000 172488
66--------------------------------------------------------------------------------
67
68
69- total_trans
70This gives the total number of frequency transitions on this CPU. The cat
71output will have a single count which is the total number of frequency
72transitions.
73
74--------------------------------------------------------------------------------
75<mysystem>:/sys/devices/system/cpu/cpu0/cpufreq/stats # cat total_trans
7620
77--------------------------------------------------------------------------------
78
79- trans_table
80This will give a fine grained information about all the CPU frequency
81transitions. The cat output here is a two dimensional matrix, where an entry
82<i,j> (row i, column j) represents the count of number of transitions from
83Freq_i to Freq_j. Freq_i is in descending order with increasing rows and
84Freq_j is in descending order with increasing columns. The output here also
85contains the actual freq values for each row and column for better readability.
86
87--------------------------------------------------------------------------------
88<mysystem>:/sys/devices/system/cpu/cpu0/cpufreq/stats # cat trans_table
89 From : To
90 : 3600000 3400000 3200000 3000000 2800000
91 3600000: 0 5 0 0 0
92 3400000: 4 0 2 0 0
93 3200000: 0 1 0 2 0
94 3000000: 0 0 1 0 3
95 2800000: 0 0 0 2 0
96--------------------------------------------------------------------------------
97
98
993. Configuring cpufreq-stats
100
101To configure cpufreq-stats in your kernel
102Config Main Menu
103 Power management options (ACPI, APM) --->
104 CPU Frequency scaling --->
105 [*] CPU Frequency scaling
106 <*> CPU frequency translation statistics
107 [*] CPU frequency translation statistics details
108
109
110"CPU Frequency scaling" (CONFIG_CPU_FREQ) should be enabled to configure
111cpufreq-stats.
112
113"CPU frequency translation statistics" (CONFIG_CPU_FREQ_STAT) provides the
114basic statistics which includes time_in_state and total_trans.
115
116"CPU frequency translation statistics details" (CONFIG_CPU_FREQ_STAT_DETAILS)
117provides fine grained cpufreq stats by trans_table. The reason for having a
118seperate config option for trans_table is:
119- trans_table goes against the traditional /sysfs rule of one value per
120 interface. It provides a whole bunch of value in a 2 dimensional matrix
121 form.
122
123Once these two options are enabled and your CPU supports cpufrequency, you
124will be able to see the CPU frequency statistics in /sysfs.
125
126
127
128
diff --git a/Documentation/cpu-freq/governors.txt b/Documentation/cpu-freq/governors.txt
index b85481acd0ca..933fae74c337 100644
--- a/Documentation/cpu-freq/governors.txt
+++ b/Documentation/cpu-freq/governors.txt
@@ -9,6 +9,7 @@
9 9
10 10
11 Dominik Brodowski <linux@brodo.de> 11 Dominik Brodowski <linux@brodo.de>
12 some additions and corrections by Nico Golde <nico@ngolde.de>
12 13
13 14
14 15
@@ -25,6 +26,7 @@ Contents:
252.1 Performance 262.1 Performance
262.2 Powersave 272.2 Powersave
272.3 Userspace 282.3 Userspace
292.4 Ondemand
28 30
293. The Governor Interface in the CPUfreq Core 313. The Governor Interface in the CPUfreq Core
30 32
@@ -86,7 +88,7 @@ highest frequency within the borders of scaling_min_freq and
86scaling_max_freq. 88scaling_max_freq.
87 89
88 90
892.1 Powersave 912.2 Powersave
90------------- 92-------------
91 93
92The CPUfreq governor "powersave" sets the CPU statically to the 94The CPUfreq governor "powersave" sets the CPU statically to the
@@ -94,7 +96,7 @@ lowest frequency within the borders of scaling_min_freq and
94scaling_max_freq. 96scaling_max_freq.
95 97
96 98
972.2 Userspace 992.3 Userspace
98------------- 100-------------
99 101
100The CPUfreq governor "userspace" allows the user, or any userspace 102The 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
103directory. 105directory.
104 106
105 107
1082.4 Ondemand
109------------
110
111The CPUfreq govenor "ondemand" sets the CPU depending on the
112current usage. To do this the CPU must have the capability to
113switch the frequency very fast.
114
115
106 116
1073. The Governor Interface in the CPUfreq Core 1173. The Governor Interface in the CPUfreq Core
108============================================= 118=============================================
diff --git a/Documentation/cpusets.txt b/Documentation/cpusets.txt
index 2f8f24eaefd9..ad944c060312 100644
--- a/Documentation/cpusets.txt
+++ b/Documentation/cpusets.txt
@@ -51,6 +51,14 @@ mems_allowed vector.
51 51
52If a cpuset is cpu or mem exclusive, no other cpuset, other than a direct 52If a cpuset is cpu or mem exclusive, no other cpuset, other than a direct
53ancestor or descendent, may share any of the same CPUs or Memory Nodes. 53ancestor or descendent, may share any of the same CPUs or Memory Nodes.
54A cpuset that is cpu exclusive has a sched domain associated with it.
55The sched domain consists of all cpus in the current cpuset that are not
56part of any exclusive child cpusets.
57This ensures that the scheduler load balacing code only balances
58against the cpus that are in the sched domain as defined above and not
59all of the cpus in the system. This removes any overhead due to
60load balancing code trying to pull tasks outside of the cpu exclusive
61cpuset only to be prevented by the tasks' cpus_allowed mask.
54 62
55User level code may create and destroy cpusets by name in the cpuset 63User level code may create and destroy cpusets by name in the cpuset
56virtual file system, manage the attributes and permissions of these 64virtual file system, manage the attributes and permissions of these
@@ -84,6 +92,9 @@ This can be especially valuable on:
84 and a database), or 92 and a database), or
85 * NUMA systems running large HPC applications with demanding 93 * NUMA systems running large HPC applications with demanding
86 performance characteristics. 94 performance characteristics.
95 * Also cpu_exclusive cpusets are useful for servers running orthogonal
96 workloads such as RT applications requiring low latency and HPC
97 applications that are throughput sensitive
87 98
88These subsets, or "soft partitions" must be able to be dynamically 99These subsets, or "soft partitions" must be able to be dynamically
89adjusted, as the job mix changes, without impacting other concurrently 100adjusted, as the job mix changes, without impacting other concurrently
@@ -125,6 +136,8 @@ Cpusets extends these two mechanisms as follows:
125 - A cpuset may be marked exclusive, which ensures that no other 136 - A cpuset may be marked exclusive, which ensures that no other
126 cpuset (except direct ancestors and descendents) may contain 137 cpuset (except direct ancestors and descendents) may contain
127 any overlapping CPUs or Memory Nodes. 138 any overlapping CPUs or Memory Nodes.
139 Also a cpu_exclusive cpuset would be associated with a sched
140 domain.
128 - You can list all the tasks (by pid) attached to any cpuset. 141 - You can list all the tasks (by pid) attached to any cpuset.
129 142
130The implementation of cpusets requires a few, simple hooks 143The implementation of cpusets requires a few, simple hooks
@@ -136,6 +149,9 @@ into the rest of the kernel, none in performance critical paths:
136 allowed in that tasks cpuset. 149 allowed in that tasks cpuset.
137 - in sched.c migrate_all_tasks(), to keep migrating tasks within 150 - in sched.c migrate_all_tasks(), to keep migrating tasks within
138 the CPUs allowed by their cpuset, if possible. 151 the CPUs allowed by their cpuset, if possible.
152 - in sched.c, a new API partition_sched_domains for handling
153 sched domain changes associated with cpu_exclusive cpusets
154 and related changes in both sched.c and arch/ia64/kernel/domain.c
139 - in the mbind and set_mempolicy system calls, to mask the requested 155 - in the mbind and set_mempolicy system calls, to mask the requested
140 Memory Nodes by what's allowed in that tasks cpuset. 156 Memory Nodes by what's allowed in that tasks cpuset.
141 - in page_alloc, to restrict memory to allowed nodes. 157 - in page_alloc, to restrict memory to allowed nodes.
diff --git a/Documentation/devices.txt b/Documentation/devices.txt
index bb67cf25010e..0f515175c72a 100644
--- a/Documentation/devices.txt
+++ b/Documentation/devices.txt
@@ -94,6 +94,7 @@ Your cooperation is appreciated.
94 9 = /dev/urandom Faster, less secure random number gen. 94 9 = /dev/urandom Faster, less secure random number gen.
95 10 = /dev/aio Asyncronous I/O notification interface 95 10 = /dev/aio Asyncronous I/O notification interface
96 11 = /dev/kmsg Writes to this come out as printk's 96 11 = /dev/kmsg Writes to this come out as printk's
97 12 = /dev/oldmem Access to crash dump from kexec kernel
97 1 block RAM disk 98 1 block RAM disk
98 0 = /dev/ram0 First RAM disk 99 0 = /dev/ram0 First RAM disk
99 1 = /dev/ram1 Second RAM disk 100 1 = /dev/ram1 Second RAM disk
diff --git a/Documentation/dontdiff b/Documentation/dontdiff
index 9a33bb94f74f..d4fda25db868 100644
--- a/Documentation/dontdiff
+++ b/Documentation/dontdiff
@@ -111,6 +111,7 @@ mkdep
111mktables 111mktables
112modpost 112modpost
113modversions.h* 113modversions.h*
114offset.h
114offsets.h 115offsets.h
115oui.c* 116oui.c*
116parse.c* 117parse.c*
diff --git a/Documentation/driver-model/device.txt b/Documentation/driver-model/device.txt
index 58cc5dc8fd3e..a05ec50f8004 100644
--- a/Documentation/driver-model/device.txt
+++ b/Documentation/driver-model/device.txt
@@ -76,6 +76,14 @@ driver_data: Driver-specific data.
76 76
77platform_data: Platform data specific to the device. 77platform_data: Platform data specific to the device.
78 78
79 Example: for devices on custom boards, as typical of embedded
80 and SOC based hardware, Linux often uses platform_data to point
81 to board-specific structures describing devices and how they
82 are wired. That can include what ports are available, chip
83 variants, which GPIO pins act in what additional roles, and so
84 on. This shrinks the "Board Support Packages" (BSPs) and
85 minimizes board-specific #ifdefs in drivers.
86
79current_state: Current power state of the device. 87current_state: Current power state of the device.
80 88
81saved_state: Pointer to saved state of the device. This is usable by 89saved_state: Pointer to saved state of the device. This is usable by
diff --git a/Documentation/driver-model/driver.txt b/Documentation/driver-model/driver.txt
index 6031a68dd3f5..fabaca1ab1b0 100644
--- a/Documentation/driver-model/driver.txt
+++ b/Documentation/driver-model/driver.txt
@@ -5,21 +5,17 @@ struct device_driver {
5 char * name; 5 char * name;
6 struct bus_type * bus; 6 struct bus_type * bus;
7 7
8 rwlock_t lock; 8 struct completion unloaded;
9 atomic_t refcount; 9 struct kobject kobj;
10
11 list_t bus_list;
12 list_t devices; 10 list_t devices;
13 11
14 struct driver_dir_entry dir; 12 struct module *owner;
15 13
16 int (*probe) (struct device * dev); 14 int (*probe) (struct device * dev);
17 int (*remove) (struct device * dev); 15 int (*remove) (struct device * dev);
18 16
19 int (*suspend) (struct device * dev, pm_message_t state, u32 level); 17 int (*suspend) (struct device * dev, pm_message_t state, u32 level);
20 int (*resume) (struct device * dev, u32 level); 18 int (*resume) (struct device * dev, u32 level);
21
22 void (*release) (struct device_driver * drv);
23}; 19};
24 20
25 21
@@ -51,7 +47,6 @@ being converted completely to the new model.
51static struct device_driver eepro100_driver = { 47static struct device_driver eepro100_driver = {
52 .name = "eepro100", 48 .name = "eepro100",
53 .bus = &pci_bus_type, 49 .bus = &pci_bus_type,
54 .devclass = &ethernet_devclass, /* when it's implemented */
55 50
56 .probe = eepro100_probe, 51 .probe = eepro100_probe,
57 .remove = eepro100_remove, 52 .remove = eepro100_remove,
@@ -85,7 +80,6 @@ static struct pci_driver eepro100_driver = {
85 .driver = { 80 .driver = {
86 .name = "eepro100", 81 .name = "eepro100",
87 .bus = &pci_bus_type, 82 .bus = &pci_bus_type,
88 .devclass = &ethernet_devclass, /* when it's implemented */
89 .probe = eepro100_probe, 83 .probe = eepro100_probe,
90 .remove = eepro100_remove, 84 .remove = eepro100_remove,
91 .suspend = eepro100_suspend, 85 .suspend = eepro100_suspend,
@@ -166,27 +160,32 @@ Callbacks
166 160
167 int (*probe) (struct device * dev); 161 int (*probe) (struct device * dev);
168 162
169probe is called to verify the existence of a certain type of 163The probe() entry is called in task context, with the bus's rwsem locked
170hardware. This is called during the driver binding process, after the 164and the driver partially bound to the device. Drivers commonly use
171bus has verified that the device ID of a device matches one of the 165container_of() to convert "dev" to a bus-specific type, both in probe()
172device IDs supported by the driver. 166and other routines. That type often provides device resource data, such
173 167as pci_dev.resource[] or platform_device.resources, which is used in
174This callback only verifies that there actually is supported hardware 168addition to dev->platform_data to initialize the driver.
175present. It may allocate a driver-specific structure, but it should 169
176not do any initialization of the hardware itself. The device-specific 170This callback holds the driver-specific logic to bind the driver to a
177structure may be stored in the device's driver_data field. 171given device. That includes verifying that the device is present, that
178 172it's a version the driver can handle, that driver data structures can
179 int (*init) (struct device * dev); 173be allocated and initialized, and that any hardware can be initialized.
180 174Drivers often store a pointer to their state with dev_set_drvdata().
181init is called during the binding stage. It is called after probe has 175When the driver has successfully bound itself to that device, then probe()
182successfully returned and the device has been registered with its 176returns zero and the driver model code will finish its part of binding
183class. It is responsible for initializing the hardware. 177the driver to that device.
178
179A driver's probe() may return a negative errno value to indicate that
180the driver did not bind to this device, in which case it should have
181released all reasources it allocated.
184 182
185 int (*remove) (struct device * dev); 183 int (*remove) (struct device * dev);
186 184
187remove is called to dissociate a driver with a device. This may be 185remove is called to unbind a driver from a device. This may be
188called if a device is physically removed from the system, if the 186called if a device is physically removed from the system, if the
189driver module is being unloaded, or during a reboot sequence. 187driver module is being unloaded, during a reboot sequence, or
188in other cases.
190 189
191It is up to the driver to determine if the device is present or 190It is up to the driver to determine if the device is present or
192not. It should free any resources allocated specifically for the 191not. It should free any resources allocated specifically for the
diff --git a/Documentation/dvb/README.dibusb b/Documentation/dvb/README.dvb-usb
index 7a9e958513f3..c7ed01b9f8f4 100644
--- a/Documentation/dvb/README.dibusb
+++ b/Documentation/dvb/README.dvb-usb
@@ -1,16 +1,40 @@
1Documentation for dib3000* frontend drivers and dibusb device driver 1Documentation for dvb-usb-framework module and its devices
2====================================================================
3 2
4Copyright (C) 2004-5 Patrick Boettcher (patrick.boettcher@desy.de), 3Idea behind the dvb-usb-framework
4=================================
5 5
6dibusb and dib3000mb/mc drivers based on GPL code, which has 6In March 2005 I got the new Twinhan USB2.0 DVB-T device. They provided specs and a firmware.
7 7
8Copyright (C) 2004 Amaury Demol for DiBcom (ademol@dibcom.fr) 8Quite keen I wanted to put the driver (with some quirks of course) into dibusb.
9After reading some specs and doing some USB snooping, it realized, that the
10dibusb-driver would be a complete mess afterwards. So I decided to do it in a
11different way: With the help of a dvb-usb-framework.
9 12
10This program is free software; you can redistribute it and/or 13The framework provides generic functions (mostly kernel API calls), such as:
11modify it under the terms of the GNU General Public License as
12published by the Free Software Foundation, version 2.
13 14
15- Transport Stream URB handling in conjunction with dvb-demux-feed-control
16 (bulk and isoc (TODO) are supported)
17- registering the device for the DVB-API
18- registering an I2C-adapter if applicable
19- remote-control/input-device handling
20- firmware requesting and loading (currently just for the Cypress USB
21 controller)
22- other functions/methods which can be shared by several drivers (such as
23 functions for bulk-control-commands)
24
25The source code of the particular DVB USB devices does just the communication
26with the device via the bus. The connection between the DVB-API-functionality
27is done via callbacks, assigned in a static device-description (struct
28dvb_usb_device) each device-driver has to have.
29
30For an example have a look in drivers/media/dvb/dvb-usb/vp7045*.
31
32Objective is to migrate all the usb-devices (dibusb, cinergyT2, maybe the
33ttusb; flexcop-usb already benefits from the generic flexcop-device) to use
34the dvb-usb-lib.
35
36TODO: dynamic enabling and disabling of the pid-filter in regard to number of
37feeds requested.
14 38
15Supported devices USB1.1 39Supported devices USB1.1
16======================== 40========================
@@ -55,22 +79,34 @@ Others:
55- Grandtec USB DVB-T 79- Grandtec USB DVB-T
56 http://www.grand.com.tw/ 80 http://www.grand.com.tw/
57 81
58- Avermedia AverTV DVBT USB (2) 82- AVerMedia AverTV DVBT USB
59 http://www.avermedia.com/ 83 http://www.avermedia.com/
60 84
61- DiBcom USB DVB-T reference device (non-public) 85- DiBcom USB DVB-T reference device (non-public)
62 86
63 87
64Supported devices USB2.0 88Supported devices USB2.0-only
65======================== 89=============================
66- Twinhan MagicBox II (2) 90- Twinhan MagicBox II
67 http://www.twinhan.com/product_terrestrial_7.asp 91 http://www.twinhan.com/product_terrestrial_7.asp
68 92
69- Hanftek UMT-010 (1) 93- TwinhanDTV Alpha
94 http://www.twinhan.com/product_terrestrial_8.asp
95
96- DigitalNow TinyUSB 2 DVB-t Receiver
97 http://www.digitalnow.com.au/DigitalNow%20tinyUSB2%20Specifications.html
98
99- Hanftek UMT-010
70 http://www.globalsources.com/si/6008819757082/ProductDetail/Digital-TV/product_id-100046529 100 http://www.globalsources.com/si/6008819757082/ProductDetail/Digital-TV/product_id-100046529
71 101
72- Typhoon/Yakumo/HAMA DVB-T mobile USB2.0 (1) 102
103Supported devices USB2.0 and USB1.1
104=============================
105- Typhoon/Yakumo/HAMA/Yuan DVB-T mobile USB2.0
73 http://www.yakumo.de/produkte/index.php?pid=1&ag=DVB-T 106 http://www.yakumo.de/produkte/index.php?pid=1&ag=DVB-T
107 http://www.yuan.com.tw/en/products/vdo_ub300.html
108 http://www.hama.de/portal/articleId*114663/action*2563
109 http://www.anubisline.com/english/articlec.asp?id=50502&catid=002
74 110
75- Artec T1 USB TVBOX (FX2) (2) 111- Artec T1 USB TVBOX (FX2) (2)
76 112
@@ -81,14 +117,24 @@ Supported devices USB2.0
81 117
82- DiBcom USB2.0 DVB-T reference device (non-public) 118- DiBcom USB2.0 DVB-T reference device (non-public)
83 119
841) It is working almost. 120- AVerMedia AverTV A800 DVB-T USB2.0
121
1221) It is working almost - work-in-progress.
852) No test reports received yet. 1232) No test reports received yet.
86 124
1250. History & News:
126 2005-04-17 - all dibusb devices ported to make use of the dvb-usb-framework
127 2005-04-02 - re-enabled and improved remote control code.
128 2005-03-31 - ported the Yakumo/Hama/Typhoon DVB-T USB2.0 device to dvb-usb.
129 2005-03-30 - first commit of the dvb-usb-module based on the dibusb-source. First device is a new driver for the
130 TwinhanDTV Alpha / MagicBox II USB2.0-only DVB-T device.
87 131
880. NEWS: 132 (change from dvb-dibusb to dvb-usb)
133 2005-03-28 - added support for the AVerMedia AverTV DVB-T USB2.0 device (Thanks to Glen Harris and Jiun-Kuei Jung, AVerMedia)
134 2005-03-14 - added support for the Typhoon/Yakumo/HAMA DVB-T mobile USB2.0
89 2005-02-11 - added support for the KWorld/ADSTech Instant DVB-T USB2.0. Thanks a lot to Joachim von Caron 135 2005-02-11 - added support for the KWorld/ADSTech Instant DVB-T USB2.0. Thanks a lot to Joachim von Caron
90 2005-02-02 - added support for the Hauppauge Win-TV Nova-T USB2 136 2005-02-02 - added support for the Hauppauge Win-TV Nova-T USB2
91 2005-01-31 - distorted streaming is finally gone for USB1.1 devices 137 2005-01-31 - distorted streaming is gone for USB1.1 devices
92 2005-01-13 - moved the mirrored pid_filter_table back to dvb-dibusb 138 2005-01-13 - moved the mirrored pid_filter_table back to dvb-dibusb
93 - first almost working version for HanfTek UMT-010 139 - first almost working version for HanfTek UMT-010
94 - found out, that Yakumo/HAMA/Typhoon are predessors of the HanfTek UMT-010 140 - found out, that Yakumo/HAMA/Typhoon are predessors of the HanfTek UMT-010
@@ -99,7 +145,7 @@ Supported devices USB2.0
99 2004-12-26 - refactored the dibusb-driver, splitted into separate files 145 2004-12-26 - refactored the dibusb-driver, splitted into separate files
100 - i2c-probing enabled 146 - i2c-probing enabled
101 2004-12-06 - possibility for demod i2c-address probing 147 2004-12-06 - possibility for demod i2c-address probing
102 - new usb IDs (Compro,Artec) 148 - new usb IDs (Compro, Artec)
103 2004-11-23 - merged changes from DiB3000MC_ver2.1 149 2004-11-23 - merged changes from DiB3000MC_ver2.1
104 - revised the debugging 150 - revised the debugging
105 - possibility to deliver the complete TS for USB2.0 151 - possibility to deliver the complete TS for USB2.0
@@ -127,8 +173,8 @@ Supported devices USB2.0
127 CTS Portable (Chinese Television System) 173 CTS Portable (Chinese Television System)
128 2004-07-08 - firmware-extraction-2.422-problem solved, driver is now working 174 2004-07-08 - firmware-extraction-2.422-problem solved, driver is now working
129 properly with firmware extracted from 2.422 175 properly with firmware extracted from 2.422
130 - #if for 2.6.4 (dvb), compile issue 176 - #if for 2.6.4 (dvb), compile issue
131 - changed firmware handling, see vp7041.txt sec 1.1 177 - changed firmware handling, see vp7041.txt sec 1.1
132 2004-07-02 - some tuner modifications, v0.1, cleanups, first public 178 2004-07-02 - some tuner modifications, v0.1, cleanups, first public
133 2004-06-28 - now using the dvb_dmx_swfilter_packets, everything 179 2004-06-28 - now using the dvb_dmx_swfilter_packets, everything
134 runs fine now 180 runs fine now
@@ -139,38 +185,27 @@ Supported devices USB2.0
139 2004-05-11 - start writing the driver 185 2004-05-11 - start writing the driver
140 186
1411. How to use? 1871. How to use?
142NOTE: This driver was developed using Linux 2.6.6.,
143it is working with 2.6.7 and above.
144
145Linux 2.4.x support is not planned, but patches are very welcome.
146
147NOTE: I'm using Debian testing, so the following explaination (especially
148the hotplug-path) needn't match your system, but probably it will :).
149
150The driver is included in the kernel since Linux 2.6.10.
151
1521.1. Firmware 1881.1. Firmware
153 189
154The USB driver needs to download a firmware to start working. 190Most of the USB drivers need to download a firmware to start working.
155
156You can either use "get_dvb_firmware dibusb" to download the firmware or you
157can get it directly via
158 191
159for USB1.1 (AN2135) 192for USB1.1 (AN2135) you need: dvb-usb-dibusb-5.0.0.11.fw
160http://www.linuxtv.org/downloads/firmware/dvb-dibusb-5.0.0.11.fw 193for USB2.0 HanfTek: dvb-usb-umt-010-02.fw
194for USB2.0 DiBcom: dvb-usb-dibusb-6.0.0.8.fw
195for USB2.0 AVerMedia AverTV DVB-T USB2: dvb-usb-avertv-a800-01.fw
196for USB2.0 TwinhanDTV Alpha/MagicBox II: dvb-usb-vp7045-01.fw
161 197
162for USB1.1 (AN2235) (a few Artec T1 devices) 198The files can be found on http://www.linuxtv.org/download/firmware/ .
163http://www.linuxtv.org/downloads/firmware/dvb-dibusb-an2235-1.fw
164 199
165for USB2.0 (FX2) Hauppauge, DiBcom 200We do not have the permission (yet) to publish the following firmware-files.
166http://www.linuxtv.org/downloads/firmware/dvb-dibusb-6.0.0.5.fw 201You'll need to extract them from the windows drivers.
167 202
168for USB2.0 ADSTech/Kworld USB2.0 203You should be able to use "get_dvb_firmware dvb-usb" to get the firmware:
169http://www.linuxtv.org/downloads/firmware/dvb-dibusb-adstech-usb2-1.fw
170
171for USB2.0 HanfTek
172http://www.linuxtv.org/downloads/firmware/dvb-dibusb-an2235-1.fw
173 204
205for USB1.1 (AN2235) (a few Artec T1 devices): dvb-usb-dibusb-an2235-01.fw
206for USB2.0 Hauppauge: dvb-usb-nova-t-usb2-01.fw
207for USB2.0 ADSTech/Kworld USB2.0: dvb-usb-adstech-usb2-01.fw
208for USB2.0 Yakumo/Typhoon/Hama: dvb-usb-dtt200u-01.fw
174 209
1751.2. Compiling 2101.2. Compiling
176 211
@@ -178,6 +213,9 @@ Since the driver is in the linux kernel, activating the driver in
178your favorite config-environment should sufficient. I recommend 213your favorite config-environment should sufficient. I recommend
179to compile the driver as module. Hotplug does the rest. 214to compile the driver as module. Hotplug does the rest.
180 215
216If you use dvb-kernel enter the build-2.6 directory run 'make' and 'insmod.sh
217load' afterwards.
218
1811.3. Loading the drivers 2191.3. Loading the drivers
182 220
183Hotplug is able to load the driver, when it is needed (because you plugged 221Hotplug is able to load the driver, when it is needed (because you plugged
@@ -188,15 +226,13 @@ from withing the dvb-kernel cvs repository.
188 226
189first have a look, which debug level are available: 227first have a look, which debug level are available:
190 228
191modinfo dib3000mb 229modinfo dvb-usb
192modinfo dib3000-common 230modinfo dvb-usb-vp7045
193modinfo dib3000mc 231etc.
194modinfo dvb-dibusb
195 232
196modprobe dib3000-common debug=<level> 233modprobe dvb-usb debug=<level>
197modprobe dib3000mb debug=<level> 234modprobe dvb-usb-vp7045 debug=<level>
198modprobe dib3000mc debug=<level> 235etc.
199modprobe dvb-dibusb debug=<level>
200 236
201should do the trick. 237should do the trick.
202 238
@@ -204,52 +240,32 @@ When the driver is loaded successfully, the firmware file was in
204the right place and the device is connected, the "Power"-LED should be 240the right place and the device is connected, the "Power"-LED should be
205turned on. 241turned on.
206 242
207At this point you should be able to start a dvb-capable application. For myself 243At this point you should be able to start a dvb-capable application. I'm use
208I used mplayer, dvbscan, tzap and kaxtv, they are working. Using the device 244(t|s)zap, mplayer and dvbscan to test the basics. VDR-xine provides the
209in vdr is working now also. 245long-term test scenario.
210 246
2112. Known problems and bugs 2472. Known problems and bugs
212 248
213- Don't remove the USB device while running an DVB application, your system will die. 249- Don't remove the USB device while running an DVB application, your system
250 will go crazy or die most likely.
214 251
2152.1. Adding support for devices 2522.1. Adding support for devices
216 253
217It is not possible to determine the range of devices based on the DiBcom 254TODO
218reference designs. This is because the reference design of DiBcom can be sold
219to thirds, without telling DiBcom (so done with the Twinhan VP7041 and
220the HAMA device).
221
222When you think you have a device like this and the driver does not recognizes it,
223please send the ****load*.inf and the ****cap*.inf of the Windows driver to me.
224
225Sometimes the Vendor or Product ID is identical to the ones of Twinhan, even
226though it is not a Twinhan device (e.g. HAMA), then please send me the name
227of the device. I will add it to this list in order to make this clear to
228others.
229
230If you are familar with C you can also add the VID and PID of the device to
231the dvb-dibusb-core.c-file and create a patch and send it over to me or to
232the linux-dvb mailing list, _after_ you have tried compiling and modprobing
233it.
234 255
2352.2. USB1.1 Bandwidth limitation 2562.2. USB1.1 Bandwidth limitation
236 257
237Most of the currently supported devices are USB1.1 and thus they have a 258A lot of the currently supported devices are USB1.1 and thus they have a
238maximum bandwidth of about 5-6 MBit/s when connected to a USB2.0 hub. 259maximum bandwidth of about 5-6 MBit/s when connected to a USB2.0 hub.
239This is not enough for receiving the complete transport stream of a 260This is not enough for receiving the complete transport stream of a
240DVB-T channel (which can be about 16 MBit/s). Normally this is not a 261DVB-T channel (which is about 16 MBit/s). Normally this is not a
241problem, if you only want to watch TV (this does not apply for HDTV), 262problem, if you only want to watch TV (this does not apply for HDTV),
242but watching a channel while recording another channel on the same 263but watching a channel while recording another channel on the same
243frequency simply does not work very well. This applies to all USB1.1 264frequency simply does not work very well. This applies to all USB1.1
244DVB-T devices, not just dibusb) 265DVB-T devices, not just the dvb-usb-devices)
245
246Update: For the USB1.1 and VDR some work has been done (patches and comments
247are still very welcome). Maybe the problem is solved in the meantime because I
248now use the dmx_sw_filter function instead of dmx_sw_filter_packet. I hope the
249linux-dvb software filter is able to get the best of the garbled TS.
250 266
251The bug, where the TS is distorted by a heavy usage of the device is gone 267The bug, where the TS is distorted by a heavy usage of the device is gone
252definitely. All dibusb-devices I was using (Twinhan, Kworld, DiBcom) are 268definitely. All dvb-usb-devices I was using (Twinhan, Kworld, DiBcom) are
253working like charm now with VDR. Sometimes I even was able to record a channel 269working like charm now with VDR. Sometimes I even was able to record a channel
254and watch another one. 270and watch another one.
255 271
@@ -258,7 +274,7 @@ and watch another one.
258Patches, comments and suggestions are very very welcome. 274Patches, comments and suggestions are very very welcome.
259 275
2603. Acknowledgements 2763. Acknowledgements
261 Amaury Demol (ademol@dibcom.fr) and Francois Kanounnikoff from DiBcom for 277 Amaury Demol (ademol@dibcom.fr) and Francois Kanounnikoff from DiBcom for
262 providing specs, code and help, on which the dvb-dibusb, dib3000mb and 278 providing specs, code and help, on which the dvb-dibusb, dib3000mb and
263 dib3000mc are based. 279 dib3000mc are based.
264 280
@@ -270,9 +286,16 @@ Patches, comments and suggestions are very very welcome.
270 286
271 Bernd Wagner for helping with huge bug reports and discussions. 287 Bernd Wagner for helping with huge bug reports and discussions.
272 288
273 Gunnar Wittich and Joachim von Caron for their trust for giving me 289 Gunnar Wittich and Joachim von Caron for their trust for providing
274 root-shells on their machines to implement support for new devices. 290 root-shells on their machines to implement support for new devices.
275 291
292 Glen Harris for bringing up, that there is a new dibusb-device and Jiun-Kuei
293 Jung from AVerMedia who kindly provided a special firmware to get the device
294 up and running in Linux.
295
296 Jennifer Chen, Jeff and Jack from Twinhan for kindly supporting by
297 writing the vp7045-driver.
298
276 Some guys on the linux-dvb mailing list for encouraging me 299 Some guys on the linux-dvb mailing list for encouraging me
277 300
278 Peter Schildmann >peter.schildmann-nospam-at-web.de< for his 301 Peter Schildmann >peter.schildmann-nospam-at-web.de< for his
@@ -282,4 +305,4 @@ Patches, comments and suggestions are very very welcome.
282 Ulf Hermenau for helping me out with traditional chinese. 305 Ulf Hermenau for helping me out with traditional chinese.
283 306
284 André Smoktun and Christian Frömmel for supporting me with 307 André Smoktun and Christian Frömmel for supporting me with
285 hardware and listening to my problems very patient 308 hardware and listening to my problems very patient.
diff --git a/Documentation/dvb/bt8xx.txt b/Documentation/dvb/bt8xx.txt
index d64430bf4bb6..3a3260794758 100644
--- a/Documentation/dvb/bt8xx.txt
+++ b/Documentation/dvb/bt8xx.txt
@@ -44,26 +44,23 @@ TwinHan (dst) are loaded automatically by the dvb-bt8xx device driver.
44 $ modprobe dst 44 $ modprobe dst
45 45
46The value 0x71 will override the PCI type detection for dvb-bt8xx, 46The value 0x71 will override the PCI type detection for dvb-bt8xx,
47which is necessary for TwinHan cards. 47which is necessary for TwinHan cards.
48 48
49If you're having an older card (blue color circuit) and card=0x71 locks 49If you're having an older card (blue color circuit) and card=0x71 locks
50your machine, try using 0x68, too. If that does not work, ask on the 50your machine, try using 0x68, too. If that does not work, ask on the
51mailing list. 51mailing list.
52 52
53The DST module takes a couple of useful parameters. 53The DST module takes a couple of useful parameters:
54 54
55verbose takes values 0 to 5. These values control the verbosity level. 55a. verbose takes values 0 to 5. These values control the verbosity level.
56 56b. debug takes values 0 and 1. You can either disable or enable debugging.
57debug takes values 0 and 1. You can either disable or enable debugging. 57c. dst_addons takes values 0 and 0x20:
58 58- A value of 0 means it is a FTA card.
59dst_addons takes values 0 and 0x20. A value of 0 means it is a FTA card. 59- A value of 0x20 means it has a Conditional Access slot.
600x20 means it has a Conditional Access slot.
61
62The autodected values are determined bythe cards 'response
63string' which you can see in your logs e.g.
64
65dst_get_device_id: Recognise [DSTMCI]
66 60
61The autodetected values are determined by the "response string"
62of the card, which you can see in your logs:
63e.g.: dst_get_device_id: Recognize [DSTMCI]
67 64
68-- 65--
69Authors: Richard Walker, Jamie Honan, Michael Hunold, Manu Abraham 66Authors: Richard Walker, Jamie Honan, Michael Hunold, Manu Abraham, Uwe Bugla
diff --git a/Documentation/fb/intelfb.txt b/Documentation/fb/intelfb.txt
new file mode 100644
index 000000000000..c12d39a23c3d
--- /dev/null
+++ b/Documentation/fb/intelfb.txt
@@ -0,0 +1,135 @@
1Intel 830M/845G/852GM/855GM/865G/915G Framebuffer driver
2================================================================
3
4A. Introduction
5 This is a framebuffer driver for various Intel 810/815 compatible
6graphics devices. These would include:
7
8 Intel 830M
9 Intel 810E845G
10 Intel 852GM
11 Intel 855GM
12 Intel 865G
13 Intel 915G
14
15B. List of available options
16
17 a. "video=intelfb"
18 enables the intelfb driver
19
20 Recommendation: required
21
22 b. "mode=<xres>x<yres>[-<bpp>][@<refresh>]"
23 select mode
24
25 Recommendation: user preference
26 (default = 1024x768-32@70)
27
28 c. "vram=<value>"
29 select amount of system RAM in MB to allocate for the video memory
30 if not enough RAM was already allocated by the BIOS.
31
32 Recommendation: 1 - 4 MB.
33 (default = 4 MB)
34
35 d. "voffset=<value>"
36 select at what offset in MB of the logical memory to allocate the
37 framebuffer memory. The intent is to avoid the memory blocks
38 used by standard graphics applications (XFree86). Depending on your
39 usage, adjust the value up or down, (0 for maximum usage, 63/127 MB
40 for the least amount). Note, an arbitrary setting may conflict
41 with XFree86.
42
43 Recommendation: do not set
44 (default = 48 MB)
45
46 e. "accel"
47 enable text acceleration. This can be enabled/reenabled anytime
48 by using 'fbset -accel true/false'.
49
50 Recommendation: enable
51 (default = set)
52
53 f. "hwcursor"
54 enable cursor acceleration.
55
56 Recommendation: enable
57 (default = set)
58
59 g. "mtrr"
60 enable MTRR. This allows data transfers to the framebuffer memory
61 to occur in bursts which can significantly increase performance.
62 Not very helpful with the intel chips because of 'shared memory'.
63
64 Recommendation: set
65 (default = set)
66
67 h. "fixed"
68 disable mode switching.
69
70 Recommendation: do not set
71 (default = not set)
72
73 The binary parameters can be unset with a "no" prefix, example "noaccel".
74 The default parameter (not named) is the mode.
75
76C. Kernel booting
77
78Separate each option/option-pair by commas (,) and the option from its value
79with an equals sign (=) as in the following:
80
81video=i810fb:option1,option2=value2
82
83Sample Usage
84------------
85
86In /etc/lilo.conf, add the line:
87
88append="video=intelfb:800x600-32@75,accel,hwcursor,vram=8"
89
90This will initialize the framebuffer to 800x600 at 32bpp and 75Hz. The
91framebuffer will use 8 MB of System RAM. hw acceleration of text and cursor
92will be enabled.
93
94D. Module options
95
96 The module parameters are essentially similar to the kernel
97parameters. The main difference is that you need to include a Boolean value
98(1 for TRUE, and 0 for FALSE) for those options which don't need a value.
99
100Example, to enable MTRR, include "mtrr=1".
101
102Sample Usage
103------------
104
105Using the same setup as described above, load the module like this:
106
107 modprobe intelfb mode=800x600-32@75 vram=8 accel=1 hwcursor=1
108
109Or just add the following to /etc/modprobe.conf
110
111 options intelfb mode=800x600-32@75 vram=8 accel=1 hwcursor=1
112
113and just do a
114
115 modprobe intelfb
116
117
118E. Acknowledgment:
119
120 1. Geert Uytterhoeven - his excellent howto and the virtual
121 framebuffer driver code made this possible.
122
123 2. Jeff Hartmann for his agpgart code.
124
125 3. David Dawes for his original kernel 2.4 code.
126
127 4. The X developers. Insights were provided just by reading the
128 XFree86 source code.
129
130 5. Antonino A. Daplas for his inspiring i810fb driver.
131
132 6. Andrew Morton for his kernel patches maintenance.
133
134###########################
135Sylvain
diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt
index b9eb209318ab..1d227ee3792a 100644
--- a/Documentation/feature-removal-schedule.txt
+++ b/Documentation/feature-removal-schedule.txt
@@ -43,6 +43,14 @@ Who: Randy Dunlap <rddunlap@osdl.org>
43 43
44--------------------------- 44---------------------------
45 45
46What: RAW driver (CONFIG_RAW_DRIVER)
47When: December 2005
48Why: declared obsolete since kernel 2.6.3
49 O_DIRECT can be used instead
50Who: Adrian Bunk <bunk@stusta.de>
51
52---------------------------
53
46What: register_ioctl32_conversion() / unregister_ioctl32_conversion() 54What: register_ioctl32_conversion() / unregister_ioctl32_conversion()
47When: April 2005 55When: April 2005
48Why: Replaced by ->compat_ioctl in file_operations and other method 56Why: Replaced by ->compat_ioctl in file_operations and other method
@@ -66,6 +74,14 @@ Who: Paul E. McKenney <paulmck@us.ibm.com>
66 74
67--------------------------- 75---------------------------
68 76
77What: remove verify_area()
78When: July 2006
79Files: Various uaccess.h headers.
80Why: Deprecated and redundant. access_ok() should be used instead.
81Who: Jesper Juhl <juhl-lkml@dif.dk>
82
83---------------------------
84
69What: IEEE1394 Audio and Music Data Transmission Protocol driver, 85What: IEEE1394 Audio and Music Data Transmission Protocol driver,
70 Connection Management Procedures driver 86 Connection Management Procedures driver
71When: November 2005 87When: November 2005
@@ -83,3 +99,23 @@ Why: Deprecated in favour of the new ioctl-based rawiso interface, which is
83 more efficient. You should really be using libraw1394 for raw1394 99 more efficient. You should really be using libraw1394 for raw1394
84 access anyway. 100 access anyway.
85Who: Jody McIntyre <scjody@steamballoon.com> 101Who: Jody McIntyre <scjody@steamballoon.com>
102
103---------------------------
104
105What: register_serial/unregister_serial
106When: December 2005
107Why: This interface does not allow serial ports to be registered against
108 a struct device, and as such does not allow correct power management
109 of such ports. 8250-based ports should use serial8250_register_port
110 and serial8250_unregister_port instead.
111Who: Russell King <rmk@arm.linux.org.uk>
112
113---------------------------
114
115What: i2c sysfs name change: in1_ref, vid deprecated in favour of cpu0_vid
116When: November 2005
117Files: drivers/i2c/chips/adm1025.c, drivers/i2c/chips/adm1026.c
118Why: Match the other drivers' name for the same function, duplicate names
119 will be available until removal of old names.
120Who: Grant Coady <gcoady@gmail.com>
121
diff --git a/Documentation/filesystems/ext2.txt b/Documentation/filesystems/ext2.txt
index b5cb9110cc6b..d16334ec48ba 100644
--- a/Documentation/filesystems/ext2.txt
+++ b/Documentation/filesystems/ext2.txt
@@ -58,6 +58,8 @@ noacl Don't support POSIX ACLs.
58 58
59nobh Do not attach buffer_heads to file pagecache. 59nobh Do not attach buffer_heads to file pagecache.
60 60
61xip Use execute in place (no caching) if possible
62
61grpquota,noquota,quota,usrquota Quota options are silently ignored by ext2. 63grpquota,noquota,quota,usrquota Quota options are silently ignored by ext2.
62 64
63 65
diff --git a/Documentation/filesystems/isofs.txt b/Documentation/filesystems/isofs.txt
index f64a10506689..424585ff6ea1 100644
--- a/Documentation/filesystems/isofs.txt
+++ b/Documentation/filesystems/isofs.txt
@@ -26,7 +26,11 @@ Mount options unique to the isofs filesystem.
26 mode=xxx Sets the permissions on files to xxx 26 mode=xxx Sets the permissions on files to xxx
27 nojoliet Ignore Joliet extensions if they are present. 27 nojoliet Ignore Joliet extensions if they are present.
28 norock Ignore Rock Ridge extensions if they are present. 28 norock Ignore Rock Ridge extensions if they are present.
29 unhide Show hidden files. 29 hide Completely strip hidden files from the file system.
30 showassoc Show files marked with the 'associated' bit
31 unhide Deprecated; showing hidden files is now default;
32 If given, it is a synonym for 'showassoc' which will
33 recreate previous unhide behavior
30 session=x Select number of session on multisession CD 34 session=x Select number of session on multisession CD
31 sbsector=xxx Session begins from sector xxx 35 sbsector=xxx Session begins from sector xxx
32 36
diff --git a/Documentation/filesystems/sysfs.txt b/Documentation/filesystems/sysfs.txt
index 60f6c2c4d477..dc276598a65a 100644
--- a/Documentation/filesystems/sysfs.txt
+++ b/Documentation/filesystems/sysfs.txt
@@ -214,7 +214,7 @@ Other notes:
214 214
215A very simple (and naive) implementation of a device attribute is: 215A very simple (and naive) implementation of a device attribute is:
216 216
217static ssize_t show_name(struct device * dev, char * buf) 217static ssize_t show_name(struct device *dev, struct device_attribute *attr, char *buf)
218{ 218{
219 return sprintf(buf,"%s\n",dev->name); 219 return sprintf(buf,"%s\n",dev->name);
220} 220}
diff --git a/Documentation/filesystems/tmpfs.txt b/Documentation/filesystems/tmpfs.txt
index 417e3095fe39..0d783c504ead 100644
--- a/Documentation/filesystems/tmpfs.txt
+++ b/Documentation/filesystems/tmpfs.txt
@@ -71,8 +71,8 @@ can be changed on remount. The size parameter also accepts a suffix %
71to limit this tmpfs instance to that percentage of your physical RAM: 71to limit this tmpfs instance to that percentage of your physical RAM:
72the default, when neither size nor nr_blocks is specified, is size=50% 72the default, when neither size nor nr_blocks is specified, is size=50%
73 73
74If both nr_blocks (or size) and nr_inodes are set to 0, neither blocks 74If nr_blocks=0 (or size=0), blocks will not be limited in that instance;
75nor inodes will be limited in that instance. It is generally unwise to 75if nr_inodes=0, inodes will not be limited. It is generally unwise to
76mount with such options, since it allows any user with write access to 76mount with such options, since it allows any user with write access to
77use up all the memory on the machine; but enhances the scalability of 77use up all the memory on the machine; but enhances the scalability of
78that instance in a system with many cpus making intensive use of it. 78that 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.
97Author: 97Author:
98 Christoph Rohland <cr@sap.com>, 1.12.01 98 Christoph Rohland <cr@sap.com>, 1.12.01
99Updated: 99Updated:
100 Hugh Dickins <hugh@veritas.com>, 01 September 2004 100 Hugh Dickins <hugh@veritas.com>, 13 March 2005
diff --git a/Documentation/filesystems/xip.txt b/Documentation/filesystems/xip.txt
new file mode 100644
index 000000000000..6c0cef10eb4d
--- /dev/null
+++ b/Documentation/filesystems/xip.txt
@@ -0,0 +1,67 @@
1Execute-in-place for file mappings
2----------------------------------
3
4Motivation
5----------
6File mappings are performed by mapping page cache pages to userspace. In
7addition, read&write type file operations also transfer data from/to the page
8cache.
9
10For memory backed storage devices that use the block device interface, the page
11cache pages are in fact copies of the original storage. Various approaches
12exist to work around the need for an extra copy. The ramdisk driver for example
13does read the data into the page cache, keeps a reference, and discards the
14original data behind later on.
15
16Execute-in-place solves this issue the other way around: instead of keeping
17data in the page cache, the need to have a page cache copy is eliminated
18completely. With execute-in-place, read&write type operations are performed
19directly from/to the memory backed storage device. For file mappings, the
20storage device itself is mapped directly into userspace.
21
22This implementation was initialy written for shared memory segments between
23different virtual machines on s390 hardware to allow multiple machines to
24share the same binaries and libraries.
25
26Implementation
27--------------
28Execute-in-place is implemented in three steps: block device operation,
29address space operation, and file operations.
30
31A block device operation named direct_access is used to retrieve a
32reference (pointer) to a block on-disk. The reference is supposed to be
33cpu-addressable, physical address and remain valid until the release operation
34is performed. A struct block_device reference is used to address the device,
35and a sector_t argument is used to identify the individual block. As an
36alternative, memory technology devices can be used for this.
37
38The block device operation is optional, these block devices support it as of
39today:
40- dcssblk: s390 dcss block device driver
41
42An address space operation named get_xip_page is used to retrieve reference
43to a struct page. To address the target page, a reference to an address_space,
44and a sector number is provided. A 3rd argument indicates whether the
45function should allocate blocks if needed.
46
47This address space operation is mutually exclusive with readpage&writepage that
48do page cache read/write operations.
49The following filesystems support it as of today:
50- ext2: the second extended filesystem, see Documentation/filesystems/ext2.txt
51
52A set of file operations that do utilize get_xip_page can be found in
53mm/filemap_xip.c . The following file operation implementations are provided:
54- aio_read/aio_write
55- readv/writev
56- sendfile
57
58The generic file operations do_sync_read/do_sync_write can be used to implement
59classic synchronous IO calls.
60
61Shortcomings
62------------
63This implementation is limited to storage devices that are cpu addressable at
64all times (no highmem or such). It works well on rom/ram, but enhancements are
65needed to make it work with flash in read+write mode.
66Putting the Linux kernel and/or its modules on a xip filesystem does not mean
67they are not copied.
diff --git a/Documentation/i2c/busses/i2c-sis69x b/Documentation/i2c/busses/i2c-sis69x
index 5be48769f65b..b88953dfd580 100644
--- a/Documentation/i2c/busses/i2c-sis69x
+++ b/Documentation/i2c/busses/i2c-sis69x
@@ -42,7 +42,7 @@ I suspect that this driver could be made to work for the following SiS
42chipsets as well: 635, and 635T. If anyone owns a board with those chips 42chipsets as well: 635, and 635T. If anyone owns a board with those chips
43AND is willing to risk crashing & burning an otherwise well-behaved kernel 43AND is willing to risk crashing & burning an otherwise well-behaved kernel
44in the name of progress... please contact me at <mhoffman@lightlink.com> or 44in the name of progress... please contact me at <mhoffman@lightlink.com> or
45via the project's mailing list: <sensors@stimpy.netroedge.com>. Please 45via the project's mailing list: <lm-sensors@lm-sensors.org>. Please
46send bug reports and/or success stories as well. 46send bug reports and/or success stories as well.
47 47
48 48
diff --git a/Documentation/i2c/chips/adm1021 b/Documentation/i2c/chips/adm1021
new file mode 100644
index 000000000000..03d02bfb3df1
--- /dev/null
+++ b/Documentation/i2c/chips/adm1021
@@ -0,0 +1,111 @@
1Kernel driver adm1021
2=====================
3
4Supported chips:
5 * Analog Devices ADM1021
6 Prefix: 'adm1021'
7 Addresses scanned: I2C 0x18 - 0x1a, 0x29 - 0x2b, 0x4c - 0x4e
8 Datasheet: Publicly available at the Analog Devices website
9 * Analog Devices ADM1021A/ADM1023
10 Prefix: 'adm1023'
11 Addresses scanned: I2C 0x18 - 0x1a, 0x29 - 0x2b, 0x4c - 0x4e
12 Datasheet: Publicly available at the Analog Devices website
13 * Genesys Logic GL523SM
14 Prefix: 'gl523sm'
15 Addresses scanned: I2C 0x18 - 0x1a, 0x29 - 0x2b, 0x4c - 0x4e
16 Datasheet:
17 * Intel Xeon Processor
18 Prefix: - any other - may require 'force_adm1021' parameter
19 Addresses scanned: none
20 Datasheet: Publicly available at Intel website
21 * Maxim MAX1617
22 Prefix: 'max1617'
23 Addresses scanned: I2C 0x18 - 0x1a, 0x29 - 0x2b, 0x4c - 0x4e
24 Datasheet: Publicly available at the Maxim website
25 * Maxim MAX1617A
26 Prefix: 'max1617a'
27 Addresses scanned: I2C 0x18 - 0x1a, 0x29 - 0x2b, 0x4c - 0x4e
28 Datasheet: Publicly available at the Maxim website
29 * National Semiconductor LM84
30 Prefix: 'lm84'
31 Addresses scanned: I2C 0x18 - 0x1a, 0x29 - 0x2b, 0x4c - 0x4e
32 Datasheet: Publicly available at the National Semiconductor website
33 * Philips NE1617
34 Prefix: 'max1617' (probably detected as a max1617)
35 Addresses scanned: I2C 0x18 - 0x1a, 0x29 - 0x2b, 0x4c - 0x4e
36 Datasheet: Publicly available at the Philips website
37 * Philips NE1617A
38 Prefix: 'max1617' (probably detected as a max1617)
39 Addresses scanned: I2C 0x18 - 0x1a, 0x29 - 0x2b, 0x4c - 0x4e
40 Datasheet: Publicly available at the Philips website
41 * TI THMC10
42 Prefix: 'thmc10'
43 Addresses scanned: I2C 0x18 - 0x1a, 0x29 - 0x2b, 0x4c - 0x4e
44 Datasheet: Publicly available at the TI website
45 * Onsemi MC1066
46 Prefix: 'mc1066'
47 Addresses scanned: I2C 0x18 - 0x1a, 0x29 - 0x2b, 0x4c - 0x4e
48 Datasheet: Publicly available at the Onsemi website
49
50
51Authors:
52 Frodo Looijaard <frodol@dds.nl>,
53 Philip Edelbrock <phil@netroedge.com>
54
55Module Parameters
56-----------------
57
58* read_only: int
59 Don't set any values, read only mode
60
61
62Description
63-----------
64
65The chips supported by this driver are very similar. The Maxim MAX1617 is
66the oldest; it has the problem that it is not very well detectable. The
67MAX1617A solves that. The ADM1021 is a straight clone of the MAX1617A.
68Ditto for the THMC10. From here on, we will refer to all these chips as
69ADM1021-clones.
70
71The ADM1021 and MAX1617A reports a die code, which is a sort of revision
72code. This can help us pinpoint problems; it is not very useful
73otherwise.
74
75ADM1021-clones implement two temperature sensors. One of them is internal,
76and measures the temperature of the chip itself; the other is external and
77is realised in the form of a transistor-like device. A special alarm
78indicates whether the remote sensor is connected.
79
80Each sensor has its own low and high limits. When they are crossed, the
81corresponding alarm is set and remains on as long as the temperature stays
82out of range. Temperatures are measured in degrees Celsius. Measurements
83are possible between -65 and +127 degrees, with a resolution of one degree.
84
85If an alarm triggers, it will remain triggered until the hardware register
86is read at least once. This means that the cause for the alarm may already
87have disappeared!
88
89This driver only updates its values each 1.5 seconds; reading it more often
90will do no harm, but will return 'old' values. It is possible to make
91ADM1021-clones do faster measurements, but there is really no good reason
92for that.
93
94Xeon support
95------------
96
97Some Xeon processors have real max1617, adm1021, or compatible chips
98within them, with two temperature sensors.
99
100Other Xeons have chips with only one sensor.
101
102If you have a Xeon, and the adm1021 module loads, and both temperatures
103appear valid, then things are good.
104
105If the adm1021 module doesn't load, you should try this:
106 modprobe adm1021 force_adm1021=BUS,ADDRESS
107 ADDRESS can only be 0x18, 0x1a, 0x29, 0x2b, 0x4c, or 0x4e.
108
109If you have dual Xeons you may have appear to have two separate
110adm1021-compatible chips, or two single-temperature sensors, at distinct
111addresses.
diff --git a/Documentation/i2c/chips/adm1025 b/Documentation/i2c/chips/adm1025
new file mode 100644
index 000000000000..39d2b781b5d6
--- /dev/null
+++ b/Documentation/i2c/chips/adm1025
@@ -0,0 +1,51 @@
1Kernel driver adm1025
2=====================
3
4Supported chips:
5 * Analog Devices ADM1025, ADM1025A
6 Prefix: 'adm1025'
7 Addresses scanned: I2C 0x2c - 0x2e
8 Datasheet: Publicly available at the Analog Devices website
9 * Philips NE1619
10 Prefix: 'ne1619'
11 Addresses scanned: I2C 0x2c - 0x2d
12 Datasheet: Publicly available at the Philips website
13
14The NE1619 presents some differences with the original ADM1025:
15 * Only two possible addresses (0x2c - 0x2d).
16 * No temperature offset register, but we don't use it anyway.
17 * No INT mode for pin 16. We don't play with it anyway.
18
19Authors:
20 Chen-Yuan Wu <gwu@esoft.com>,
21 Jean Delvare <khali@linux-fr.org>
22
23Description
24-----------
25
26(This is from Analog Devices.) The ADM1025 is a complete system hardware
27monitor for microprocessor-based systems, providing measurement and limit
28comparison of various system parameters. Five voltage measurement inputs
29are provided, for monitoring +2.5V, +3.3V, +5V and +12V power supplies and
30the processor core voltage. The ADM1025 can monitor a sixth power-supply
31voltage by measuring its own VCC. One input (two pins) is dedicated to a
32remote temperature-sensing diode and an on-chip temperature sensor allows
33ambient temperature to be monitored.
34
35One specificity of this chip is that the pin 11 can be hardwired in two
36different manners. It can act as the +12V power-supply voltage analog
37input, or as the a fifth digital entry for the VID reading (bit 4). It's
38kind of strange since both are useful, and the reason for designing the
39chip that way is obscure at least to me. The bit 5 of the configuration
40register can be used to define how the chip is hardwired. Please note that
41it is not a choice you have to make as the user. The choice was already
42made by your motherboard's maker. If the configuration bit isn't set
43properly, you'll have a wrong +12V reading or a wrong VID reading. The way
44the driver handles that is to preserve this bit through the initialization
45process, assuming that the BIOS set it up properly beforehand. If it turns
46out not to be true in some cases, we'll provide a module parameter to force
47modes.
48
49This driver also supports the ADM1025A, which differs from the ADM1025
50only in that it has "open-drain VID inputs while the ADM1025 has on-chip
51100k pull-ups on the VID inputs". It doesn't make any difference for us.
diff --git a/Documentation/i2c/chips/adm1026 b/Documentation/i2c/chips/adm1026
new file mode 100644
index 000000000000..473c689d7924
--- /dev/null
+++ b/Documentation/i2c/chips/adm1026
@@ -0,0 +1,93 @@
1Kernel driver adm1026
2=====================
3
4Supported chips:
5 * Analog Devices ADM1026
6 Prefix: 'adm1026'
7 Addresses scanned: I2C 0x2c, 0x2d, 0x2e
8 Datasheet: Publicly available at the Analog Devices website
9 http://www.analog.com/en/prod/0,,766_825_ADM1026,00.html
10
11Authors:
12 Philip Pokorny <ppokorny@penguincomputing.com> for Penguin Computing
13 Justin Thiessen <jthiessen@penguincomputing.com>
14
15Module Parameters
16-----------------
17
18* gpio_input: int array (min = 1, max = 17)
19 List of GPIO pins (0-16) to program as inputs
20* gpio_output: int array (min = 1, max = 17)
21 List of GPIO pins (0-16) to program as outputs
22* gpio_inverted: int array (min = 1, max = 17)
23 List of GPIO pins (0-16) to program as inverted
24* gpio_normal: int array (min = 1, max = 17)
25 List of GPIO pins (0-16) to program as normal/non-inverted
26* gpio_fan: int array (min = 1, max = 8)
27 List of GPIO pins (0-7) to program as fan tachs
28
29
30Description
31-----------
32
33This driver implements support for the Analog Devices ADM1026. Analog
34Devices calls it a "complete thermal system management controller."
35
36The ADM1026 implements three (3) temperature sensors, 17 voltage sensors,
3716 general purpose digital I/O lines, eight (8) fan speed sensors (8-bit),
38an analog output and a PWM output along with limit, alarm and mask bits for
39all of the above. There is even 8k bytes of EEPROM memory on chip.
40
41Temperatures are measured in degrees Celsius. There are two external
42sensor inputs and one internal sensor. Each sensor has a high and low
43limit. If the limit is exceeded, an interrupt (#SMBALERT) can be
44generated. The interrupts can be masked. In addition, there are over-temp
45limits for each sensor. If this limit is exceeded, the #THERM output will
46be asserted. The current temperature and limits have a resolution of 1
47degree.
48
49Fan rotation speeds are reported in RPM (rotations per minute) but measured
50in counts of a 22.5kHz internal clock. Each fan has a high limit which
51corresponds to a minimum fan speed. If the limit is exceeded, an interrupt
52can be generated. Each fan can be programmed to divide the reference clock
53by 1, 2, 4 or 8. Not all RPM values can accurately be represented, so some
54rounding is done. With a divider of 8, the slowest measurable speed of a
55two pulse per revolution fan is 661 RPM.
56
57There are 17 voltage sensors. An alarm is triggered if the voltage has
58crossed a programmable minimum or maximum limit. Note that minimum in this
59case always means 'closest to zero'; this is important for negative voltage
60measurements. Several inputs have integrated attenuators so they can measure
61higher voltages directly. 3.3V, 5V, 12V, -12V and battery voltage all have
62dedicated inputs. There are several inputs scaled to 0-3V full-scale range
63for SCSI terminator power. The remaining inputs are not scaled and have
64a 0-2.5V full-scale range. A 2.5V or 1.82V reference voltage is provided
65for negative voltage measurements.
66
67If an alarm triggers, it will remain triggered until the hardware register
68is read at least once. This means that the cause for the alarm may already
69have disappeared! Note that in the current implementation, all hardware
70registers are read whenever any data is read (unless it is less than 2.0
71seconds since the last update). This means that you can easily miss
72once-only alarms.
73
74The ADM1026 measures continuously. Analog inputs are measured about 4
75times a second. Fan speed measurement time depends on fan speed and
76divisor. It can take as long as 1.5 seconds to measure all fan speeds.
77
78The ADM1026 has the ability to automatically control fan speed based on the
79temperature sensor inputs. Both the PWM output and the DAC output can be
80used to control fan speed. Usually only one of these two outputs will be
81used. Write the minimum PWM or DAC value to the appropriate control
82register. Then set the low temperature limit in the tmin values for each
83temperature sensor. The range of control is fixed at 20 °C, and the
84largest difference between current and tmin of the temperature sensors sets
85the control output. See the datasheet for several example circuits for
86controlling fan speed with the PWM and DAC outputs. The fan speed sensors
87do not have PWM compensation, so it is probably best to control the fan
88voltage from the power lead rather than on the ground lead.
89
90The datasheet shows an example application with VID signals attached to
91GPIO lines. Unfortunately, the chip may not be connected to the VID lines
92in this way. The driver assumes that the chips *is* connected this way to
93get a VID voltage.
diff --git a/Documentation/i2c/chips/adm1031 b/Documentation/i2c/chips/adm1031
new file mode 100644
index 000000000000..130a38382b98
--- /dev/null
+++ b/Documentation/i2c/chips/adm1031
@@ -0,0 +1,35 @@
1Kernel driver adm1031
2=====================
3
4Supported chips:
5 * Analog Devices ADM1030
6 Prefix: 'adm1030'
7 Addresses scanned: I2C 0x2c to 0x2e
8 Datasheet: Publicly available at the Analog Devices website
9 http://products.analog.com/products/info.asp?product=ADM1030
10
11 * Analog Devices ADM1031
12 Prefix: 'adm1031'
13 Addresses scanned: I2C 0x2c to 0x2e
14 Datasheet: Publicly available at the Analog Devices website
15 http://products.analog.com/products/info.asp?product=ADM1031
16
17Authors:
18 Alexandre d'Alton <alex@alexdalton.org>
19 Jean Delvare <khali@linux-fr.org>
20
21Description
22-----------
23
24The ADM1030 and ADM1031 are digital temperature sensors and fan controllers.
25They sense their own temperature as well as the temperature of up to one
26(ADM1030) or two (ADM1031) external diodes.
27
28All temperature values are given in degrees Celsius. Resolution is 0.5
29degree for the local temperature, 0.125 degree for the remote temperatures.
30
31Each temperature channel has its own high and low limits, plus a critical
32limit.
33
34The ADM1030 monitors a single fan speed, while the ADM1031 monitors up to
35two. Each fan channel has its own low speed limit.
diff --git a/Documentation/i2c/chips/adm9240 b/Documentation/i2c/chips/adm9240
new file mode 100644
index 000000000000..35f618f32896
--- /dev/null
+++ b/Documentation/i2c/chips/adm9240
@@ -0,0 +1,177 @@
1Kernel driver adm9240
2=====================
3
4Supported chips:
5 * Analog Devices ADM9240
6 Prefix: 'adm9240'
7 Addresses scanned: I2C 0x2c - 0x2f
8 Datasheet: Publicly available at the Analog Devices website
9 http://www.analog.com/UploadedFiles/Data_Sheets/79857778ADM9240_0.pdf
10
11 * Dallas Semiconductor DS1780
12 Prefix: 'ds1780'
13 Addresses scanned: I2C 0x2c - 0x2f
14 Datasheet: Publicly available at the Dallas Semiconductor (Maxim) website
15 http://pdfserv.maxim-ic.com/en/ds/DS1780.pdf
16
17 * National Semiconductor LM81
18 Prefix: 'lm81'
19 Addresses scanned: I2C 0x2c - 0x2f
20 Datasheet: Publicly available at the National Semiconductor website
21 http://www.national.com/ds.cgi/LM/LM81.pdf
22
23Authors:
24 Frodo Looijaard <frodol@dds.nl>,
25 Philip Edelbrock <phil@netroedge.com>,
26 Michiel Rook <michiel@grendelproject.nl>,
27 Grant Coady <gcoady@gmail.com> with guidance
28 from Jean Delvare <khali@linux-fr.org>
29
30Interface
31---------
32The I2C addresses listed above assume BIOS has not changed the
33chip MSB 5-bit address. Each chip reports a unique manufacturer
34identification code as well as the chip revision/stepping level.
35
36Description
37-----------
38[From ADM9240] The ADM9240 is a complete system hardware monitor for
39microprocessor-based systems, providing measurement and limit comparison
40of up to four power supplies and two processor core voltages, plus
41temperature, two fan speeds and chassis intrusion. Measured values can
42be read out via an I2C-compatible serial System Management Bus, and values
43for limit comparisons can be programmed in over the same serial bus. The
44high speed successive approximation ADC allows frequent sampling of all
45analog channels to ensure a fast interrupt response to any out-of-limit
46measurement.
47
48The ADM9240, DS1780 and LM81 are register compatible, the following
49details are common to the three chips. Chip differences are described
50after this section.
51
52
53Measurements
54------------
55The measurement cycle
56
57The adm9240 driver will take a measurement reading no faster than once
58each two seconds. User-space may read sysfs interface faster than the
59measurement update rate and will receive cached data from the most
60recent measurement.
61
62ADM9240 has a very fast 320us temperature and voltage measurement cycle
63with independent fan speed measurement cycles counting alternating rising
64edges of the fan tacho inputs.
65
66DS1780 measurement cycle is about once per second including fan speed.
67
68LM81 measurement cycle is about once per 400ms including fan speed.
69The LM81 12-bit extended temperature measurement mode is not supported.
70
71Temperature
72-----------
73On chip temperature is reported as degrees Celsius as 9-bit signed data
74with resolution of 0.5 degrees Celsius. High and low temperature limits
75are 8-bit signed data with resolution of one degree Celsius.
76
77Temperature alarm is asserted once the temperature exceeds the high limit,
78and is cleared when the temperature falls below the temp1_max_hyst value.
79
80Fan Speed
81---------
82Two fan tacho inputs are provided, the ADM9240 gates an internal 22.5kHz
83clock via a divider to an 8-bit counter. Fan speed (rpm) is calculated by:
84
85rpm = (22500 * 60) / (count * divider)
86
87Automatic fan clock divider
88
89 * User sets 0 to fan_min limit
90 - low speed alarm is disabled
91 - fan clock divider not changed
92 - auto fan clock adjuster enabled for valid fan speed reading
93
94 * User sets fan_min limit too low
95 - low speed alarm is enabled
96 - fan clock divider set to max
97 - fan_min set to register value 254 which corresponds
98 to 664 rpm on adm9240
99 - low speed alarm will be asserted if fan speed is
100 less than minimum measurable speed
101 - auto fan clock adjuster disabled
102
103 * User sets reasonable fan speed
104 - low speed alarm is enabled
105 - fan clock divider set to suit fan_min
106 - auto fan clock adjuster enabled: adjusts fan_min
107
108 * User sets unreasonably high low fan speed limit
109 - resolution of the low speed limit may be reduced
110 - alarm will be asserted
111 - auto fan clock adjuster enabled: adjusts fan_min
112
113 * fan speed may be displayed as zero until the auto fan clock divider
114 adjuster brings fan speed clock divider back into chip measurement
115 range, this will occur within a few measurement cycles.
116
117Analog Output
118-------------
119An analog output provides a 0 to 1.25 volt signal intended for an external
120fan speed amplifier circuit. The analog output is set to maximum value on
121power up or reset. This doesn't do much on the test Intel SE440BX-2.
122
123Voltage Monitor
124
125Voltage (IN) measurement is internally scaled:
126
127 nr label nominal maximum resolution
128 mV mV mV
129 0 +2.5V 2500 3320 13.0
130 1 Vccp1 2700 3600 14.1
131 2 +3.3V 3300 4380 17.2
132 3 +5V 5000 6640 26.0
133 4 +12V 12000 15940 62.5
134 5 Vccp2 2700 3600 14.1
135
136The reading is an unsigned 8-bit value, nominal voltage measurement is
137represented by a reading of 192, being 3/4 of the measurement range.
138
139An alarm is asserted for any voltage going below or above the set limits.
140
141The driver reports and accepts voltage limits scaled to the above table.
142
143VID Monitor
144-----------
145The chip has five inputs to read the 5-bit VID and reports the mV value
146based on detected CPU type.
147
148Chassis Intrusion
149-----------------
150An alarm is asserted when the CI pin goes active high. The ADM9240
151Datasheet has an example of an external temperature sensor driving
152this pin. On an Intel SE440BX-2 the Chassis Intrusion header is
153connected to a normally open switch.
154
155The ADM9240 provides an internal open drain on this line, and may output
156a 20 ms active low pulse to reset an external Chassis Intrusion latch.
157
158Clear the CI latch by writing value 1 to the sysfs chassis_clear file.
159
160Alarm flags reported as 16-bit word
161
162 bit label comment
163 --- ------------- --------------------------
164 0 +2.5 V_Error high or low limit exceeded
165 1 VCCP_Error high or low limit exceeded
166 2 +3.3 V_Error high or low limit exceeded
167 3 +5 V_Error high or low limit exceeded
168 4 Temp_Error temperature error
169 6 FAN1_Error fan low limit exceeded
170 7 FAN2_Error fan low limit exceeded
171 8 +12 V_Error high or low limit exceeded
172 9 VCCP2_Error high or low limit exceeded
173 12 Chassis_Error CI pin went high
174
175Remaining bits are reserved and thus undefined. It is important to note
176that alarm bits may be cleared on read, user-space may latch alarms and
177provide the end-user with a method to clear alarm memory.
diff --git a/Documentation/i2c/chips/asb100 b/Documentation/i2c/chips/asb100
new file mode 100644
index 000000000000..ab7365e139be
--- /dev/null
+++ b/Documentation/i2c/chips/asb100
@@ -0,0 +1,72 @@
1Kernel driver asb100
2====================
3
4Supported Chips:
5 * Asus ASB100 and ASB100-A "Bach"
6 Prefix: 'asb100'
7 Addresses scanned: I2C 0x2d
8 Datasheet: none released
9
10Author: Mark M. Hoffman <mhoffman@lightlink.com>
11
12Description
13-----------
14
15This driver implements support for the Asus ASB100 and ASB100-A "Bach".
16These are custom ASICs available only on Asus mainboards. Asus refuses to
17supply a datasheet for these chips. Thanks go to many people who helped
18investigate their hardware, including:
19
20Vitaly V. Bursov
21Alexander van Kaam (author of MBM for Windows)
22Bertrik Sikken
23
24The ASB100 implements seven voltage sensors, three fan rotation speed
25sensors, four temperature sensors, VID lines and alarms. In addition to
26these, the ASB100-A also implements a single PWM controller for fans 2 and
273 (i.e. one setting controls both.) If you have a plain ASB100, the PWM
28controller will simply not work (or maybe it will for you... it doesn't for
29me).
30
31Temperatures are measured and reported in degrees Celsius.
32
33Fan speeds are reported in RPM (rotations per minute). An alarm is
34triggered if the rotation speed has dropped below a programmable limit.
35
36Voltage sensors (also known as IN sensors) report values in volts.
37
38The VID lines encode the core voltage value: the voltage level your
39processor should work with. This is hardcoded by the mainboard and/or
40processor itself. It is a value in volts.
41
42Alarms: (TODO question marks indicate may or may not work)
43
440x0001 => in0 (?)
450x0002 => in1 (?)
460x0004 => in2
470x0008 => in3
480x0010 => temp1 (1)
490x0020 => temp2
500x0040 => fan1
510x0080 => fan2
520x0100 => in4
530x0200 => in5 (?) (2)
540x0400 => in6 (?) (2)
550x0800 => fan3
560x1000 => chassis switch
570x2000 => temp3
58
59Alarm Notes:
60
61(1) This alarm will only trigger if the hysteresis value is 127C.
62I.e. it behaves the same as w83781d.
63
64(2) The min and max registers for these values appear to
65be read-only or otherwise stuck at 0x00.
66
67TODO:
68* Experiment with fan divisors > 8.
69* Experiment with temp. sensor types.
70* Are there really 13 voltage inputs? Probably not...
71* Cleanups, no doubt...
72
diff --git a/Documentation/i2c/chips/ds1621 b/Documentation/i2c/chips/ds1621
new file mode 100644
index 000000000000..1fee6f1e6bc5
--- /dev/null
+++ b/Documentation/i2c/chips/ds1621
@@ -0,0 +1,108 @@
1Kernel driver ds1621
2====================
3
4Supported chips:
5 * Dallas Semiconductor DS1621
6 Prefix: 'ds1621'
7 Addresses scanned: I2C 0x48 - 0x4f
8 Datasheet: Publicly available at the Dallas Semiconductor website
9 http://www.dalsemi.com/
10 * Dallas Semiconductor DS1625
11 Prefix: 'ds1621'
12 Addresses scanned: I2C 0x48 - 0x4f
13 Datasheet: Publicly available at the Dallas Semiconductor website
14 http://www.dalsemi.com/
15
16Authors:
17 Christian W. Zuckschwerdt <zany@triq.net>
18 valuable contributions by Jan M. Sendler <sendler@sendler.de>
19 ported to 2.6 by Aurelien Jarno <aurelien@aurel32.net>
20 with the help of Jean Delvare <khali@linux-fr.org>
21
22Module Parameters
23------------------
24
25* polarity int
26 Output's polarity: 0 = active high, 1 = active low
27
28Description
29-----------
30
31The DS1621 is a (one instance) digital thermometer and thermostat. It has
32both high and low temperature limits which can be user defined (i.e.
33programmed into non-volatile on-chip registers). Temperature range is -55
34degree Celsius to +125 in 0.5 increments. You may convert this into a
35Fahrenheit range of -67 to +257 degrees with 0.9 steps. If polarity
36parameter is not provided, original value is used.
37
38As for the thermostat, behavior can also be programmed using the polarity
39toggle. On the one hand ("heater"), the thermostat output of the chip,
40Tout, will trigger when the low limit temperature is met or underrun and
41stays high until the high limit is met or exceeded. On the other hand
42("cooler"), vice versa. That way "heater" equals "active low", whereas
43"conditioner" equals "active high". Please note that the DS1621 data sheet
44is somewhat misleading in this point since setting the polarity bit does
45not simply invert Tout.
46
47A second thing is that, during extensive testing, Tout showed a tolerance
48of up to +/- 0.5 degrees even when compared against precise temperature
49readings. Be sure to have a high vs. low temperature limit gap of al least
501.0 degree Celsius to avoid Tout "bouncing", though!
51
52As for alarms, you can read the alarm status of the DS1621 via the 'alarms'
53/sys file interface. The result consists mainly of bit 6 and 5 of the
54configuration register of the chip; bit 6 (0x40 or 64) is the high alarm
55bit and bit 5 (0x20 or 32) the low one. These bits are set when the high or
56low limits are met or exceeded and are reset by the module as soon as the
57respective temperature ranges are left.
58
59The alarm registers are in no way suitable to find out about the actual
60status of Tout. They will only tell you about its history, whether or not
61any of the limits have ever been met or exceeded since last power-up or
62reset. Be aware: When testing, it showed that the status of Tout can change
63with neither of the alarms set.
64
65Temperature conversion of the DS1621 takes up to 1000ms; internal access to
66non-volatile registers may last for 10ms or below.
67
68High Accuracy Temperature Reading
69---------------------------------
70
71As said before, the temperature issued via the 9-bit i2c-bus data is
72somewhat arbitrary. Internally, the temperature conversion is of a
73different kind that is explained (not so...) well in the DS1621 data sheet.
74To cut the long story short: Inside the DS1621 there are two oscillators,
75both of them biassed by a temperature coefficient.
76
77Higher resolution of the temperature reading can be achieved using the
78internal projection, which means taking account of REG_COUNT and REG_SLOPE
79(the driver manages them):
80
81Taken from Dallas Semiconductors App Note 068: 'Increasing Temperature
82Resolution on the DS1620' and App Note 105: 'High Resolution Temperature
83Measurement with Dallas Direct-to-Digital Temperature Sensors'
84
85- Read the 9-bit temperature and strip the LSB (Truncate the .5 degs)
86- The resulting value is TEMP_READ.
87- Then, read REG_COUNT.
88- And then, REG_SLOPE.
89
90 TEMP = TEMP_READ - 0.25 + ((REG_SLOPE - REG_COUNT) / REG_SLOPE)
91
92Note that this is what the DONE bit in the DS1621 configuration register is
93good for: Internally, one temperature conversion takes up to 1000ms. Before
94that conversion is complete you will not be able to read valid things out
95of REG_COUNT and REG_SLOPE. The DONE bit, as you may have guessed by now,
96tells you whether the conversion is complete ("done", in plain English) and
97thus, whether the values you read are good or not.
98
99The DS1621 has two modes of operation: "Continuous" conversion, which can
100be understood as the default stand-alone mode where the chip gets the
101temperature and controls external devices via its Tout pin or tells other
102i2c's about it if they care. The other mode is called "1SHOT", that means
103that it only figures out about the temperature when it is explicitly told
104to do so; this can be seen as power saving mode.
105
106Now if you want to read REG_COUNT and REG_SLOPE, you have to either stop
107the continuous conversions until the contents of these registers are valid,
108or, in 1SHOT mode, you have to have one conversion made.
diff --git a/Documentation/i2c/chips/eeprom b/Documentation/i2c/chips/eeprom
new file mode 100644
index 000000000000..f7e8104b5764
--- /dev/null
+++ b/Documentation/i2c/chips/eeprom
@@ -0,0 +1,96 @@
1Kernel driver eeprom
2====================
3
4Supported chips:
5 * Any EEPROM chip in the designated address range
6 Prefix: 'eeprom'
7 Addresses scanned: I2C 0x50 - 0x57
8 Datasheets: Publicly available from:
9 Atmel (www.atmel.com),
10 Catalyst (www.catsemi.com),
11 Fairchild (www.fairchildsemi.com),
12 Microchip (www.microchip.com),
13 Philips (www.semiconductor.philips.com),
14 Rohm (www.rohm.com),
15 ST (www.st.com),
16 Xicor (www.xicor.com),
17 and others.
18
19 Chip Size (bits) Address
20 24C01 1K 0x50 (shadows at 0x51 - 0x57)
21 24C01A 1K 0x50 - 0x57 (Typical device on DIMMs)
22 24C02 2K 0x50 - 0x57
23 24C04 4K 0x50, 0x52, 0x54, 0x56
24 (additional data at 0x51, 0x53, 0x55, 0x57)
25 24C08 8K 0x50, 0x54 (additional data at 0x51, 0x52,
26 0x53, 0x55, 0x56, 0x57)
27 24C16 16K 0x50 (additional data at 0x51 - 0x57)
28 Sony 2K 0x57
29
30 Atmel 34C02B 2K 0x50 - 0x57, SW write protect at 0x30-37
31 Catalyst 34FC02 2K 0x50 - 0x57, SW write protect at 0x30-37
32 Catalyst 34RC02 2K 0x50 - 0x57, SW write protect at 0x30-37
33 Fairchild 34W02 2K 0x50 - 0x57, SW write protect at 0x30-37
34 Microchip 24AA52 2K 0x50 - 0x57, SW write protect at 0x30-37
35 ST M34C02 2K 0x50 - 0x57, SW write protect at 0x30-37
36
37
38Authors:
39 Frodo Looijaard <frodol@dds.nl>,
40 Philip Edelbrock <phil@netroedge.com>,
41 Jean Delvare <khali@linux-fr.org>,
42 Greg Kroah-Hartman <greg@kroah.com>,
43 IBM Corp.
44
45Description
46-----------
47
48This is a simple EEPROM module meant to enable reading the first 256 bytes
49of an EEPROM (on a SDRAM DIMM for example). However, it will access serial
50EEPROMs on any I2C adapter. The supported devices are generically called
5124Cxx, and are listed above; however the numbering for these
52industry-standard devices may vary by manufacturer.
53
54This module was a programming exercise to get used to the new project
55organization laid out by Frodo, but it should be at least completely
56effective for decoding the contents of EEPROMs on DIMMs.
57
58DIMMS will typically contain a 24C01A or 24C02, or the 34C02 variants.
59The other devices will not be found on a DIMM because they respond to more
60than one address.
61
62DDC Monitors may contain any device. Often a 24C01, which responds to all 8
63addresses, is found.
64
65Recent Sony Vaio laptops have an EEPROM at 0x57. We couldn't get the
66specification, so it is guess work and far from being complete.
67
68The Microchip 24AA52/24LCS52, ST M34C02, and others support an additional
69software write protect register at 0x30 - 0x37 (0x20 less than the memory
70location). The chip responds to "write quick" detection at this address but
71does not respond to byte reads. If this register is present, the lower 128
72bytes of the memory array are not write protected. Any byte data write to
73this address will write protect the memory array permanently, and the
74device will no longer respond at the 0x30-37 address. The eeprom driver
75does not support this register.
76
77Lacking functionality:
78
79* Full support for larger devices (24C04, 24C08, 24C16). These are not
80typically found on a PC. These devices will appear as separate devices at
81multiple addresses.
82
83* Support for really large devices (24C32, 24C64, 24C128, 24C256, 24C512).
84These devices require two-byte address fields and are not supported.
85
86* Enable Writing. Again, no technical reason why not, but making it easy
87to change the contents of the EEPROMs (on DIMMs anyway) also makes it easy
88to disable the DIMMs (potentially preventing the computer from booting)
89until the values are restored somehow.
90
91Use:
92
93After inserting the module (and any other required SMBus/i2c modules), you
94should have some EEPROM directories in /sys/bus/i2c/devices/* of names such
95as "0-0050". Inside each of these is a series of files, the eeprom file
96contains the binary data from EEPROM.
diff --git a/Documentation/i2c/chips/fscher b/Documentation/i2c/chips/fscher
new file mode 100644
index 000000000000..64031659aff3
--- /dev/null
+++ b/Documentation/i2c/chips/fscher
@@ -0,0 +1,169 @@
1Kernel driver fscher
2====================
3
4Supported chips:
5 * Fujitsu-Siemens Hermes chip
6 Prefix: 'fscher'
7 Addresses scanned: I2C 0x73
8
9Authors:
10 Reinhard Nissl <rnissl@gmx.de> based on work
11 from Hermann Jung <hej@odn.de>,
12 Frodo Looijaard <frodol@dds.nl>,
13 Philip Edelbrock <phil@netroedge.com>
14
15Description
16-----------
17
18This driver implements support for the Fujitsu-Siemens Hermes chip. It is
19described in the 'Register Set Specification BMC Hermes based Systemboard'
20from Fujitsu-Siemens.
21
22The Hermes chip implements a hardware-based system management, e.g. for
23controlling fan speed and core voltage. There is also a watchdog counter on
24the chip which can trigger an alarm and even shut the system down.
25
26The chip provides three temperature values (CPU, motherboard and
27auxiliary), three voltage values (+12V, +5V and battery) and three fans
28(power supply, CPU and auxiliary).
29
30Temperatures are measured in degrees Celsius. The resolution is 1 degree.
31
32Fan rotation speeds are reported in RPM (rotations per minute). The value
33can be divided by a programmable divider (1, 2 or 4) which is stored on
34the chip.
35
36Voltage sensors (also known as "in" sensors) report their values in volts.
37
38All values are reported as final values from the driver. There is no need
39for further calculations.
40
41
42Detailed description
43--------------------
44
45Below you'll find a single line description of all the bit values. With
46this information, you're able to decode e. g. alarms, wdog, etc. To make
47use of the watchdog, you'll need to set the watchdog time and enable the
48watchdog. After that it is necessary to restart the watchdog time within
49the specified period of time, or a system reset will occur.
50
51* revision
52 READING & 0xff = 0x??: HERMES revision identification
53
54* alarms
55 READING & 0x80 = 0x80: CPU throttling active
56 READING & 0x80 = 0x00: CPU running at full speed
57
58 READING & 0x10 = 0x10: software event (see control:1)
59 READING & 0x10 = 0x00: no software event
60
61 READING & 0x08 = 0x08: watchdog event (see wdog:2)
62 READING & 0x08 = 0x00: no watchdog event
63
64 READING & 0x02 = 0x02: thermal event (see temp*:1)
65 READING & 0x02 = 0x00: no thermal event
66
67 READING & 0x01 = 0x01: fan event (see fan*:1)
68 READING & 0x01 = 0x00: no fan event
69
70 READING & 0x13 ! 0x00: ALERT LED is flashing
71
72* control
73 READING & 0x01 = 0x01: software event
74 READING & 0x01 = 0x00: no software event
75
76 WRITING & 0x01 = 0x01: set software event
77 WRITING & 0x01 = 0x00: clear software event
78
79* watchdog_control
80 READING & 0x80 = 0x80: power off on watchdog event while thermal event
81 READING & 0x80 = 0x00: watchdog power off disabled (just system reset enabled)
82
83 READING & 0x40 = 0x40: watchdog timebase 60 seconds (see also wdog:1)
84 READING & 0x40 = 0x00: watchdog timebase 2 seconds
85
86 READING & 0x10 = 0x10: watchdog enabled
87 READING & 0x10 = 0x00: watchdog disabled
88
89 WRITING & 0x80 = 0x80: enable "power off on watchdog event while thermal event"
90 WRITING & 0x80 = 0x00: disable "power off on watchdog event while thermal event"
91
92 WRITING & 0x40 = 0x40: set watchdog timebase to 60 seconds
93 WRITING & 0x40 = 0x00: set watchdog timebase to 2 seconds
94
95 WRITING & 0x20 = 0x20: disable watchdog
96
97 WRITING & 0x10 = 0x10: enable watchdog / restart watchdog time
98
99* watchdog_state
100 READING & 0x02 = 0x02: watchdog system reset occurred
101 READING & 0x02 = 0x00: no watchdog system reset occurred
102
103 WRITING & 0x02 = 0x02: clear watchdog event
104
105* watchdog_preset
106 READING & 0xff = 0x??: configured watch dog time in units (see wdog:3 0x40)
107
108 WRITING & 0xff = 0x??: configure watch dog time in units
109
110* in* (0: +5V, 1: +12V, 2: onboard 3V battery)
111 READING: actual voltage value
112
113* temp*_status (1: CPU sensor, 2: onboard sensor, 3: auxiliary sensor)
114 READING & 0x02 = 0x02: thermal event (overtemperature)
115 READING & 0x02 = 0x00: no thermal event
116
117 READING & 0x01 = 0x01: sensor is working
118 READING & 0x01 = 0x00: sensor is faulty
119
120 WRITING & 0x02 = 0x02: clear thermal event
121
122* temp*_input (1: CPU sensor, 2: onboard sensor, 3: auxiliary sensor)
123 READING: actual temperature value
124
125* fan*_status (1: power supply fan, 2: CPU fan, 3: auxiliary fan)
126 READING & 0x04 = 0x04: fan event (fan fault)
127 READING & 0x04 = 0x00: no fan event
128
129 WRITING & 0x04 = 0x04: clear fan event
130
131* fan*_div (1: power supply fan, 2: CPU fan, 3: auxiliary fan)
132 Divisors 2,4 and 8 are supported, both for reading and writing
133
134* fan*_pwm (1: power supply fan, 2: CPU fan, 3: auxiliary fan)
135 READING & 0xff = 0x00: fan may be switched off
136 READING & 0xff = 0x01: fan must run at least at minimum speed (supply: 6V)
137 READING & 0xff = 0xff: fan must run at maximum speed (supply: 12V)
138 READING & 0xff = 0x??: fan must run at least at given speed (supply: 6V..12V)
139
140 WRITING & 0xff = 0x00: fan may be switched off
141 WRITING & 0xff = 0x01: fan must run at least at minimum speed (supply: 6V)
142 WRITING & 0xff = 0xff: fan must run at maximum speed (supply: 12V)
143 WRITING & 0xff = 0x??: fan must run at least at given speed (supply: 6V..12V)
144
145* fan*_input (1: power supply fan, 2: CPU fan, 3: auxiliary fan)
146 READING: actual RPM value
147
148
149Limitations
150-----------
151
152* Measuring fan speed
153It seems that the chip counts "ripples" (typical fans produce 2 ripples per
154rotation while VERAX fans produce 18) in a 9-bit register. This register is
155read out every second, then the ripple prescaler (2, 4 or 8) is applied and
156the result is stored in the 8 bit output register. Due to the limitation of
157the counting register to 9 bits, it is impossible to measure a VERAX fan
158properly (even with a prescaler of 8). At its maximum speed of 3500 RPM the
159fan produces 1080 ripples per second which causes the counting register to
160overflow twice, leading to only 186 RPM.
161
162* Measuring input voltages
163in2 ("battery") reports the voltage of the onboard lithium battery and not
164+3.3V from the power supply.
165
166* Undocumented features
167Fujitsu-Siemens Computers has not documented all features of the chip so
168far. Their software, System Guard, shows that there are a still some
169features which cannot be controlled by this implementation.
diff --git a/Documentation/i2c/chips/gl518sm b/Documentation/i2c/chips/gl518sm
new file mode 100644
index 000000000000..ce0881883bca
--- /dev/null
+++ b/Documentation/i2c/chips/gl518sm
@@ -0,0 +1,74 @@
1Kernel driver gl518sm
2=====================
3
4Supported chips:
5 * Genesys Logic GL518SM release 0x00
6 Prefix: 'gl518sm'
7 Addresses scanned: I2C 0x2c and 0x2d
8 Datasheet: http://www.genesyslogic.com/pdf
9 * Genesys Logic GL518SM release 0x80
10 Prefix: 'gl518sm'
11 Addresses scanned: I2C 0x2c and 0x2d
12 Datasheet: http://www.genesyslogic.com/pdf
13
14Authors:
15 Frodo Looijaard <frodol@dds.nl>,
16 Kyösti Mälkki <kmalkki@cc.hut.fi>
17 Hong-Gunn Chew <hglinux@gunnet.org>
18 Jean Delvare <khali@linux-fr.org>
19
20Description
21-----------
22
23IMPORTANT:
24
25For the revision 0x00 chip, the in0, in1, and in2 values (+5V, +3V,
26and +12V) CANNOT be read. This is a limitation of the chip, not the driver.
27
28This driver supports the Genesys Logic GL518SM chip. There are at least
29two revision of this chip, which we call revision 0x00 and 0x80. Revision
300x80 chips support the reading of all voltages and revision 0x00 only
31for VIN3.
32
33The GL518SM implements one temperature sensor, two fan rotation speed
34sensors, and four voltage sensors. It can report alarms through the
35computer speakers.
36
37Temperatures are measured in degrees Celsius. An alarm goes off while the
38temperature is above the over temperature limit, and has not yet dropped
39below the hysteresis limit. The alarm always reflects the current
40situation. Measurements are guaranteed between -10 degrees and +110
41degrees, with a accuracy of +/-3 degrees.
42
43Rotation speeds are reported in RPM (rotations per minute). An alarm is
44triggered if the rotation speed has dropped below a programmable limit. In
45case when you have selected to turn fan1 off, no fan1 alarm is triggered.
46
47Fan readings can be divided by a programmable divider (1, 2, 4 or 8) to
48give the readings more range or accuracy. Not all RPM values can
49accurately be represented, so some rounding is done. With a divider
50of 2, the lowest representable value is around 1900 RPM.
51
52Voltage sensors (also known as VIN sensors) report their values in volts.
53An alarm is triggered if the voltage has crossed a programmable minimum or
54maximum limit. Note that minimum in this case always means 'closest to
55zero'; this is important for negative voltage measurements. The VDD input
56measures voltages between 0.000 and 5.865 volt, with a resolution of 0.023
57volt. The other inputs measure voltages between 0.000 and 4.845 volt, with
58a resolution of 0.019 volt. Note that revision 0x00 chips do not support
59reading the current voltage of any input except for VIN3; limit setting and
60alarms work fine, though.
61
62When an alarm is triggered, you can be warned by a beeping signal through your
63computer speaker. It is possible to enable all beeping globally, or only the
64beeping for some alarms.
65
66If an alarm triggers, it will remain triggered until the hardware register
67is read at least once (except for temperature alarms). This means that the
68cause for the alarm may already have disappeared! Note that in the current
69implementation, all hardware registers are read whenever any data is read
70(unless it is less than 1.5 seconds since the last update). This means that
71you can easily miss once-only alarms.
72
73The GL518SM only updates its values each 1.5 seconds; reading it more often
74will do no harm, but will return 'old' values.
diff --git a/Documentation/i2c/chips/it87 b/Documentation/i2c/chips/it87
new file mode 100644
index 000000000000..0d0195040d88
--- /dev/null
+++ b/Documentation/i2c/chips/it87
@@ -0,0 +1,96 @@
1Kernel driver it87
2==================
3
4Supported chips:
5 * IT8705F
6 Prefix: 'it87'
7 Addresses scanned: from Super I/O config space, or default ISA 0x290 (8 I/O ports)
8 Datasheet: Publicly available at the ITE website
9 http://www.ite.com.tw/
10 * IT8712F
11 Prefix: 'it8712'
12 Addresses scanned: I2C 0x28 - 0x2f
13 from Super I/O config space, or default ISA 0x290 (8 I/O ports)
14 Datasheet: Publicly available at the ITE website
15 http://www.ite.com.tw/
16 * SiS950 [clone of IT8705F]
17 Prefix: 'sis950'
18 Addresses scanned: from Super I/O config space, or default ISA 0x290 (8 I/O ports)
19 Datasheet: No longer be available
20
21Author: Christophe Gauthron <chrisg@0-in.com>
22
23
24Module Parameters
25-----------------
26
27* update_vbat: int
28
29 0 if vbat should report power on value, 1 if vbat should be updated after
30 each read. Default is 0. On some boards the battery voltage is provided
31 by either the battery or the onboard power supply. Only the first reading
32 at power on will be the actual battery voltage (which the chip does
33 automatically). On other boards the battery voltage is always fed to
34 the chip so can be read at any time. Excessive reading may decrease
35 battery life but no information is given in the datasheet.
36
37* fix_pwm_polarity int
38
39 Force PWM polarity to active high (DANGEROUS). Some chips are
40 misconfigured by BIOS - PWM values would be inverted. This option tries
41 to fix this. Please contact your BIOS manufacturer and ask him for fix.
42
43Description
44-----------
45
46This driver implements support for the IT8705F, IT8712F and SiS950 chips.
47
48This driver also supports IT8712F, which adds SMBus access, and a VID
49input, used to report the Vcore voltage of the Pentium processor.
50The IT8712F additionally features VID inputs.
51
52These chips are 'Super I/O chips', supporting floppy disks, infrared ports,
53joysticks and other miscellaneous stuff. For hardware monitoring, they
54include an 'environment controller' with 3 temperature sensors, 3 fan
55rotation speed sensors, 8 voltage sensors, and associated alarms.
56
57Temperatures are measured in degrees Celsius. An alarm is triggered once
58when the Overtemperature Shutdown limit is crossed.
59
60Fan rotation speeds are reported in RPM (rotations per minute). An alarm is
61triggered if the rotation speed has dropped below a programmable limit. Fan
62readings can be divided by a programmable divider (1, 2, 4 or 8) to give the
63readings more range or accuracy. Not all RPM values can accurately be
64represented, so some rounding is done. With a divider of 2, the lowest
65representable value is around 2600 RPM.
66
67Voltage sensors (also known as IN sensors) report their values in volts. An
68alarm is triggered if the voltage has crossed a programmable minimum or
69maximum limit. Note that minimum in this case always means 'closest to
70zero'; this is important for negative voltage measurements. All voltage
71inputs can measure voltages between 0 and 4.08 volts, with a resolution of
720.016 volt. The battery voltage in8 does not have limit registers.
73
74The VID lines (IT8712F only) encode the core voltage value: the voltage
75level your processor should work with. This is hardcoded by the mainboard
76and/or processor itself. It is a value in volts.
77
78If an alarm triggers, it will remain triggered until the hardware register
79is read at least once. This means that the cause for the alarm may already
80have disappeared! Note that in the current implementation, all hardware
81registers are read whenever any data is read (unless it is less than 1.5
82seconds since the last update). This means that you can easily miss
83once-only alarms.
84
85The IT87xx only updates its values each 1.5 seconds; reading it more often
86will do no harm, but will return 'old' values.
87
88To change sensor N to a thermistor, 'echo 2 > tempN_type' where N is 1, 2,
89or 3. To change sensor N to a thermal diode, 'echo 3 > tempN_type'.
90Give 0 for unused sensor. Any other value is invalid. To configure this at
91startup, consult lm_sensors's /etc/sensors.conf. (2 = thermistor;
923 = thermal diode)
93
94The fan speed control features are limited to manual PWM mode. Automatic
95"Smart Guardian" mode control handling is not implemented. However
96if you want to go for "manual mode" just write 1 to pwmN_enable.
diff --git a/Documentation/i2c/chips/lm63 b/Documentation/i2c/chips/lm63
new file mode 100644
index 000000000000..31660bf97979
--- /dev/null
+++ b/Documentation/i2c/chips/lm63
@@ -0,0 +1,57 @@
1Kernel driver lm63
2==================
3
4Supported chips:
5 * National Semiconductor LM63
6 Prefix: 'lm63'
7 Addresses scanned: I2C 0x4c
8 Datasheet: Publicly available at the National Semiconductor website
9 http://www.national.com/pf/LM/LM63.html
10
11Author: Jean Delvare <khali@linux-fr.org>
12
13Thanks go to Tyan and especially Alex Buckingham for setting up a remote
14access to their S4882 test platform for this driver.
15 http://www.tyan.com/
16
17Description
18-----------
19
20The LM63 is a digital temperature sensor with integrated fan monitoring
21and control.
22
23The LM63 is basically an LM86 with fan speed monitoring and control
24capabilities added. It misses some of the LM86 features though:
25 - No low limit for local temperature.
26 - No critical limit for local temperature.
27 - Critical limit for remote temperature can be changed only once. We
28 will consider that the critical limit is read-only.
29
30The datasheet isn't very clear about what the tachometer reading is.
31
32An explanation from National Semiconductor: The two lower bits of the read
33value have to be masked out. The value is still 16 bit in width.
34
35All temperature values are given in degrees Celsius. Resolution is 1.0
36degree for the local temperature, 0.125 degree for the remote temperature.
37
38The fan speed is measured using a tachometer. Contrary to most chips which
39store the value in an 8-bit register and have a selectable clock divider
40to make sure that the result will fit in the register, the LM63 uses 16-bit
41value for measuring the speed of the fan. It can measure fan speeds down to
4283 RPM, at least in theory.
43
44Note that the pin used for fan monitoring is shared with an alert out
45function. Depending on how the board designer wanted to use the chip, fan
46speed monitoring will or will not be possible. The proper chip configuration
47is left to the BIOS, and the driver will blindly trust it.
48
49A PWM output can be used to control the speed of the fan. The LM63 has two
50PWM modes: manual and automatic. Automatic mode is not fully implemented yet
51(you cannot define your custom PWM/temperature curve), and mode change isn't
52supported either.
53
54The lm63 driver will not update its values more frequently than every
55second; reading them more often will do no harm, but will return 'old'
56values.
57
diff --git a/Documentation/i2c/chips/lm75 b/Documentation/i2c/chips/lm75
new file mode 100644
index 000000000000..8e6356fe05d7
--- /dev/null
+++ b/Documentation/i2c/chips/lm75
@@ -0,0 +1,65 @@
1Kernel driver lm75
2==================
3
4Supported chips:
5 * National Semiconductor LM75
6 Prefix: 'lm75'
7 Addresses scanned: I2C 0x48 - 0x4f
8 Datasheet: Publicly available at the National Semiconductor website
9 http://www.national.com/
10 * Dallas Semiconductor DS75
11 Prefix: 'lm75'
12 Addresses scanned: I2C 0x48 - 0x4f
13 Datasheet: Publicly available at the Dallas Semiconductor website
14 http://www.maxim-ic.com/
15 * Dallas Semiconductor DS1775
16 Prefix: 'lm75'
17 Addresses scanned: I2C 0x48 - 0x4f
18 Datasheet: Publicly available at the Dallas Semiconductor website
19 http://www.maxim-ic.com/
20 * Maxim MAX6625, MAX6626
21 Prefix: 'lm75'
22 Addresses scanned: I2C 0x48 - 0x4b
23 Datasheet: Publicly available at the Maxim website
24 http://www.maxim-ic.com/
25 * Microchip (TelCom) TCN75
26 Prefix: 'lm75'
27 Addresses scanned: I2C 0x48 - 0x4f
28 Datasheet: Publicly available at the Microchip website
29 http://www.microchip.com/
30
31Author: Frodo Looijaard <frodol@dds.nl>
32
33Description
34-----------
35
36The LM75 implements one temperature sensor. Limits can be set through the
37Overtemperature Shutdown register and Hysteresis register. Each value can be
38set and read to half-degree accuracy.
39An alarm is issued (usually to a connected LM78) when the temperature
40gets higher then the Overtemperature Shutdown value; it stays on until
41the temperature falls below the Hysteresis value.
42All temperatures are in degrees Celsius, and are guaranteed within a
43range of -55 to +125 degrees.
44
45The LM75 only updates its values each 1.5 seconds; reading it more often
46will do no harm, but will return 'old' values.
47
48The LM75 is usually used in combination with LM78-like chips, to measure
49the temperature of the processor(s).
50
51The DS75, DS1775, MAX6625, and MAX6626 are supported as well.
52They are not distinguished from an LM75. While most of these chips
53have three additional bits of accuracy (12 vs. 9 for the LM75),
54the additional bits are not supported. Not only that, but these chips will
55not be detected if not in 9-bit precision mode (use the force parameter if
56needed).
57
58The TCN75 is supported as well, and is not distinguished from an LM75.
59
60The LM75 is essentially an industry standard; there may be other
61LM75 clones not listed here, with or without various enhancements,
62that are supported.
63
64The LM77 is not supported, contrary to what we pretended for a long time.
65Both chips are simply not compatible, value encoding differs.
diff --git a/Documentation/i2c/chips/lm77 b/Documentation/i2c/chips/lm77
new file mode 100644
index 000000000000..57c3a46d6370
--- /dev/null
+++ b/Documentation/i2c/chips/lm77
@@ -0,0 +1,22 @@
1Kernel driver lm77
2==================
3
4Supported chips:
5 * National Semiconductor LM77
6 Prefix: 'lm77'
7 Addresses scanned: I2C 0x48 - 0x4b
8 Datasheet: Publicly available at the National Semiconductor website
9 http://www.national.com/
10
11Author: Andras BALI <drewie@freemail.hu>
12
13Description
14-----------
15
16The LM77 implements one temperature sensor. The temperature
17sensor incorporates a band-gap type temperature sensor,
1810-bit ADC, and a digital comparator with user-programmable upper
19and lower limit values.
20
21Limits can be set through the Overtemperature Shutdown register and
22Hysteresis register.
diff --git a/Documentation/i2c/chips/lm78 b/Documentation/i2c/chips/lm78
new file mode 100644
index 000000000000..357086ed7f64
--- /dev/null
+++ b/Documentation/i2c/chips/lm78
@@ -0,0 +1,82 @@
1Kernel driver lm78
2==================
3
4Supported chips:
5 * National Semiconductor LM78
6 Prefix: 'lm78'
7 Addresses scanned: I2C 0x20 - 0x2f, ISA 0x290 (8 I/O ports)
8 Datasheet: Publicly available at the National Semiconductor website
9 http://www.national.com/
10 * National Semiconductor LM78-J
11 Prefix: 'lm78-j'
12 Addresses scanned: I2C 0x20 - 0x2f, ISA 0x290 (8 I/O ports)
13 Datasheet: Publicly available at the National Semiconductor website
14 http://www.national.com/
15 * National Semiconductor LM79
16 Prefix: 'lm79'
17 Addresses scanned: I2C 0x20 - 0x2f, ISA 0x290 (8 I/O ports)
18 Datasheet: Publicly available at the National Semiconductor website
19 http://www.national.com/
20
21Author: Frodo Looijaard <frodol@dds.nl>
22
23Description
24-----------
25
26This driver implements support for the National Semiconductor LM78, LM78-J
27and LM79. They are described as 'Microprocessor System Hardware Monitors'.
28
29There is almost no difference between the three supported chips. Functionally,
30the LM78 and LM78-J are exactly identical. The LM79 has one more VID line,
31which is used to report the lower voltages newer Pentium processors use.
32From here on, LM7* means either of these three types.
33
34The LM7* implements one temperature sensor, three fan rotation speed sensors,
35seven voltage sensors, VID lines, alarms, and some miscellaneous stuff.
36
37Temperatures are measured in degrees Celsius. An alarm is triggered once
38when the Overtemperature Shutdown limit is crossed; it is triggered again
39as soon as it drops below the Hysteresis value. A more useful behavior
40can be found by setting the Hysteresis value to +127 degrees Celsius; in
41this case, alarms are issued during all the time when the actual temperature
42is above the Overtemperature Shutdown value. Measurements are guaranteed
43between -55 and +125 degrees, with a resolution of 1 degree.
44
45Fan rotation speeds are reported in RPM (rotations per minute). An alarm is
46triggered if the rotation speed has dropped below a programmable limit. Fan
47readings can be divided by a programmable divider (1, 2, 4 or 8) to give
48the readings more range or accuracy. Not all RPM values can accurately be
49represented, so some rounding is done. With a divider of 2, the lowest
50representable value is around 2600 RPM.
51
52Voltage sensors (also known as IN sensors) report their values in volts.
53An alarm is triggered if the voltage has crossed a programmable minimum
54or maximum limit. Note that minimum in this case always means 'closest to
55zero'; this is important for negative voltage measurements. All voltage
56inputs can measure voltages between 0 and 4.08 volts, with a resolution
57of 0.016 volt.
58
59The VID lines encode the core voltage value: the voltage level your processor
60should work with. This is hardcoded by the mainboard and/or processor itself.
61It is a value in volts. When it is unconnected, you will often find the
62value 3.50 V here.
63
64In addition to the alarms described above, there are a couple of additional
65ones. There is a BTI alarm, which gets triggered when an external chip has
66crossed its limits. Usually, this is connected to all LM75 chips; if at
67least one crosses its limits, this bit gets set. The CHAS alarm triggers
68if your computer case is open. The FIFO alarms should never trigger; it
69indicates an internal error. The SMI_IN alarm indicates some other chip
70has triggered an SMI interrupt. As we do not use SMI interrupts at all,
71this condition usually indicates there is a problem with some other
72device.
73
74If an alarm triggers, it will remain triggered until the hardware register
75is read at least once. This means that the cause for the alarm may
76already have disappeared! Note that in the current implementation, all
77hardware registers are read whenever any data is read (unless it is less
78than 1.5 seconds since the last update). This means that you can easily
79miss once-only alarms.
80
81The LM7* only updates its values each 1.5 seconds; reading it more often
82will do no harm, but will return 'old' values.
diff --git a/Documentation/i2c/chips/lm80 b/Documentation/i2c/chips/lm80
new file mode 100644
index 000000000000..cb5b407ba3e6
--- /dev/null
+++ b/Documentation/i2c/chips/lm80
@@ -0,0 +1,56 @@
1Kernel driver lm80
2==================
3
4Supported chips:
5 * National Semiconductor LM80
6 Prefix: 'lm80'
7 Addresses scanned: I2C 0x28 - 0x2f
8 Datasheet: Publicly available at the National Semiconductor website
9 http://www.national.com/
10
11Authors:
12 Frodo Looijaard <frodol@dds.nl>,
13 Philip Edelbrock <phil@netroedge.com>
14
15Description
16-----------
17
18This driver implements support for the National Semiconductor LM80.
19It is described as a 'Serial Interface ACPI-Compatible Microprocessor
20System Hardware Monitor'.
21
22The LM80 implements one temperature sensor, two fan rotation speed sensors,
23seven voltage sensors, alarms, and some miscellaneous stuff.
24
25Temperatures are measured in degrees Celsius. There are two sets of limits
26which operate independently. When the HOT Temperature Limit is crossed,
27this will cause an alarm that will be reasserted until the temperature
28drops below the HOT Hysteresis. The Overtemperature Shutdown (OS) limits
29should work in the same way (but this must be checked; the datasheet
30is unclear about this). Measurements are guaranteed between -55 and
31+125 degrees. The current temperature measurement has a resolution of
320.0625 degrees; the limits have a resolution of 1 degree.
33
34Fan rotation speeds are reported in RPM (rotations per minute). An alarm is
35triggered if the rotation speed has dropped below a programmable limit. Fan
36readings can be divided by a programmable divider (1, 2, 4 or 8) to give
37the readings more range or accuracy. Not all RPM values can accurately be
38represented, so some rounding is done. With a divider of 2, the lowest
39representable value is around 2600 RPM.
40
41Voltage sensors (also known as IN sensors) report their values in volts.
42An alarm is triggered if the voltage has crossed a programmable minimum
43or maximum limit. Note that minimum in this case always means 'closest to
44zero'; this is important for negative voltage measurements. All voltage
45inputs can measure voltages between 0 and 2.55 volts, with a resolution
46of 0.01 volt.
47
48If an alarm triggers, it will remain triggered until the hardware register
49is read at least once. This means that the cause for the alarm may
50already have disappeared! Note that in the current implementation, all
51hardware registers are read whenever any data is read (unless it is less
52than 2.0 seconds since the last update). This means that you can easily
53miss once-only alarms.
54
55The LM80 only updates its values each 1.5 seconds; reading it more often
56will do no harm, but will return 'old' values.
diff --git a/Documentation/i2c/chips/lm83 b/Documentation/i2c/chips/lm83
new file mode 100644
index 000000000000..061d9ed8ff43
--- /dev/null
+++ b/Documentation/i2c/chips/lm83
@@ -0,0 +1,76 @@
1Kernel driver lm83
2==================
3
4Supported chips:
5 * National Semiconductor LM83
6 Prefix: 'lm83'
7 Addresses scanned: I2C 0x18 - 0x1a, 0x29 - 0x2b, 0x4c - 0x4e
8 Datasheet: Publicly available at the National Semiconductor website
9 http://www.national.com/pf/LM/LM83.html
10
11
12Author: Jean Delvare <khali@linux-fr.org>
13
14Description
15-----------
16
17The LM83 is a digital temperature sensor. It senses its own temperature as
18well as the temperature of up to three external diodes. It is compatible
19with many other devices such as the LM84 and all other ADM1021 clones.
20The main difference between the LM83 and the LM84 in that the later can
21only sense the temperature of one external diode.
22
23Using the adm1021 driver for a LM83 should work, but only two temperatures
24will be reported instead of four.
25
26The LM83 is only found on a handful of motherboards. Both a confirmed
27list and an unconfirmed list follow. If you can confirm or infirm the
28fact that any of these motherboards do actually have an LM83, please
29contact us. Note that the LM90 can easily be misdetected as a LM83.
30
31Confirmed motherboards:
32 SBS P014
33
34Unconfirmed motherboards:
35 Gigabyte GA-8IK1100
36 Iwill MPX2
37 Soltek SL-75DRV5
38
39The driver has been successfully tested by Magnus Forsström, who I'd
40like to thank here. More testers will be of course welcome.
41
42The fact that the LM83 is only scarcely used can be easily explained.
43Most motherboards come with more than just temperature sensors for
44health monitoring. They also have voltage and fan rotation speed
45sensors. This means that temperature-only chips are usually used as
46secondary chips coupled with another chip such as an IT8705F or similar
47chip, which provides more features. Since systems usually need three
48temperature sensors (motherboard, processor, power supply) and primary
49chips provide some temperature sensors, the secondary chip, if needed,
50won't have to handle more than two temperatures. Thus, ADM1021 clones
51are sufficient, and there is no need for a four temperatures sensor
52chip such as the LM83. The only case where using an LM83 would make
53sense is on SMP systems, such as the above-mentioned Iwill MPX2,
54because you want an additional temperature sensor for each additional
55CPU.
56
57On the SBS P014, this is different, since the LM83 is the only hardware
58monitoring chipset. One temperature sensor is used for the motherboard
59(actually measuring the LM83's own temperature), one is used for the
60CPU. The two other sensors must be used to measure the temperature of
61two other points of the motherboard. We suspect these points to be the
62north and south bridges, but this couldn't be confirmed.
63
64All temperature values are given in degrees Celsius. Local temperature
65is given within a range of 0 to +85 degrees. Remote temperatures are
66given within a range of 0 to +125 degrees. Resolution is 1.0 degree,
67accuracy is guaranteed to 3.0 degrees (see the datasheet for more
68details).
69
70Each sensor has its own high limit, but the critical limit is common to
71all four sensors. There is no hysteresis mechanism as found on most
72recent temperature sensors.
73
74The lm83 driver will not update its values more frequently than every
75other second; reading them more often will do no harm, but will return
76'old' values.
diff --git a/Documentation/i2c/chips/lm85 b/Documentation/i2c/chips/lm85
new file mode 100644
index 000000000000..9549237530cf
--- /dev/null
+++ b/Documentation/i2c/chips/lm85
@@ -0,0 +1,221 @@
1Kernel driver lm85
2==================
3
4Supported chips:
5 * National Semiconductor LM85 (B and C versions)
6 Prefix: 'lm85'
7 Addresses scanned: I2C 0x2c, 0x2d, 0x2e
8 Datasheet: http://www.national.com/pf/LM/LM85.html
9 * Analog Devices ADM1027
10 Prefix: 'adm1027'
11 Addresses scanned: I2C 0x2c, 0x2d, 0x2e
12 Datasheet: http://www.analog.com/en/prod/0,,766_825_ADM1027,00.html
13 * Analog Devices ADT7463
14 Prefix: 'adt7463'
15 Addresses scanned: I2C 0x2c, 0x2d, 0x2e
16 Datasheet: http://www.analog.com/en/prod/0,,766_825_ADT7463,00.html
17 * SMSC EMC6D100, SMSC EMC6D101
18 Prefix: 'emc6d100'
19 Addresses scanned: I2C 0x2c, 0x2d, 0x2e
20 Datasheet: http://www.smsc.com/main/tools/discontinued/6d100.pdf
21 * SMSC EMC6D102
22 Prefix: 'emc6d102'
23 Addresses scanned: I2C 0x2c, 0x2d, 0x2e
24 Datasheet: http://www.smsc.com/main/catalog/emc6d102.html
25
26Authors:
27 Philip Pokorny <ppokorny@penguincomputing.com>,
28 Frodo Looijaard <frodol@dds.nl>,
29 Richard Barrington <rich_b_nz@clear.net.nz>,
30 Margit Schubert-While <margitsw@t-online.de>,
31 Justin Thiessen <jthiessen@penguincomputing.com>
32
33Description
34-----------
35
36This driver implements support for the National Semiconductor LM85 and
37compatible chips including the Analog Devices ADM1027, ADT7463 and
38SMSC EMC6D10x chips family.
39
40The LM85 uses the 2-wire interface compatible with the SMBUS 2.0
41specification. Using an analog to digital converter it measures three (3)
42temperatures and five (5) voltages. It has four (4) 16-bit counters for
43measuring fan speed. Five (5) digital inputs are provided for sampling the
44VID signals from the processor to the VRM. Lastly, there are three (3) PWM
45outputs that can be used to control fan speed.
46
47The voltage inputs have internal scaling resistors so that the following
48voltage can be measured without external resistors:
49
50 2.5V, 3.3V, 5V, 12V, and CPU core voltage (2.25V)
51
52The temperatures measured are one internal diode, and two remote diodes.
53Remote 1 is generally the CPU temperature. These inputs are designed to
54measure a thermal diode like the one in a Pentium 4 processor in a socket
55423 or socket 478 package. They can also measure temperature using a
56transistor like the 2N3904.
57
58A sophisticated control system for the PWM outputs is designed into the
59LM85 that allows fan speed to be adjusted automatically based on any of the
60three temperature sensors. Each PWM output is individually adjustable and
61programmable. Once configured, the LM85 will adjust the PWM outputs in
62response to the measured temperatures without further host intervention.
63This feature can also be disabled for manual control of the PWM's.
64
65Each of the measured inputs (voltage, temperature, fan speed) has
66corresponding high/low limit values. The LM85 will signal an ALARM if any
67measured value exceeds either limit.
68
69The LM85 samples all inputs continuously. The lm85 driver will not read
70the registers more often than once a second. Further, configuration data is
71only read once each 5 minutes. There is twice as much config data as
72measurements, so this would seem to be a worthwhile optimization.
73
74Special Features
75----------------
76
77The LM85 has four fan speed monitoring modes. The ADM1027 has only two.
78Both have special circuitry to compensate for PWM interactions with the
79TACH signal from the fans. The ADM1027 can be configured to measure the
80speed of a two wire fan, but the input conditioning circuitry is different
81for 3-wire and 2-wire mode. For this reason, the 2-wire fan modes are not
82exposed to user control. The BIOS should initialize them to the correct
83mode. If you've designed your own ADM1027, you'll have to modify the
84init_client function and add an insmod parameter to set this up.
85
86To smooth the response of fans to changes in temperature, the LM85 has an
87optional filter for smoothing temperatures. The ADM1027 has the same
88config option but uses it to rate limit the changes to fan speed instead.
89
90The ADM1027 and ADT7463 have a 10-bit ADC and can therefore measure
91temperatures with 0.25 degC resolution. They also provide an offset to the
92temperature readings that is automatically applied during measurement.
93This offset can be used to zero out any errors due to traces and placement.
94The documentation says that the offset is in 0.25 degC steps, but in
95initial testing of the ADM1027 it was 1.00 degC steps. Analog Devices has
96confirmed this "bug". The ADT7463 is reported to work as described in the
97documentation. The current lm85 driver does not show the offset register.
98
99The ADT7463 has a THERM asserted counter. This counter has a 22.76ms
100resolution and a range of 5.8 seconds. The driver implements a 32-bit
101accumulator of the counter value to extend the range to over a year. The
102counter will stay at it's max value until read.
103
104See the vendor datasheets for more information. There is application note
105from National (AN-1260) with some additional information about the LM85.
106The Analog Devices datasheet is very detailed and describes a procedure for
107determining an optimal configuration for the automatic PWM control.
108
109The SMSC EMC6D100 & EMC6D101 monitor external voltages, temperatures, and
110fan speeds. They use this monitoring capability to alert the system to out
111of limit conditions and can automatically control the speeds of multiple
112fans in a PC or embedded system. The EMC6D101, available in a 24-pin SSOP
113package, and the EMC6D100, available in a 28-pin SSOP package, are designed
114to be register compatible. The EMC6D100 offers all the features of the
115EMC6D101 plus additional voltage monitoring and system control features.
116Unfortunately it is not possible to distinguish between the package
117versions on register level so these additional voltage inputs may read
118zero. The EMC6D102 features addtional ADC bits thus extending precision
119of voltage and temperature channels.
120
121
122Hardware Configurations
123-----------------------
124
125The LM85 can be jumpered for 3 different SMBus addresses. There are
126no other hardware configuration options for the LM85.
127
128The lm85 driver detects both LM85B and LM85C revisions of the chip. See the
129datasheet for a complete description of the differences. Other than
130identifying the chip, the driver behaves no differently with regard to
131these two chips. The LM85B is recommended for new designs.
132
133The ADM1027 and ADT7463 chips have an optional SMBALERT output that can be
134used to signal the chipset in case a limit is exceeded or the temperature
135sensors fail. Individual sensor interrupts can be masked so they won't
136trigger SMBALERT. The SMBALERT output if configured replaces one of the other
137functions (PWM2 or IN0). This functionality is not implemented in current
138driver.
139
140The ADT7463 also has an optional THERM output/input which can be connected
141to the processor PROC_HOT output. If available, the autofan control
142dynamic Tmin feature can be enabled to keep the system temperature within
143spec (just?!) with the least possible fan noise.
144
145Configuration Notes
146-------------------
147
148Besides standard interfaces driver adds following:
149
150* Temperatures and Zones
151
152Each temperature sensor is associated with a Zone. There are three
153sensors and therefore three zones (# 1, 2 and 3). Each zone has the following
154temperature configuration points:
155
156* temp#_auto_temp_off - temperature below which fans should be off or spinning very low.
157* temp#_auto_temp_min - temperature over which fans start to spin.
158* temp#_auto_temp_max - temperature when fans spin at full speed.
159* temp#_auto_temp_crit - temperature when all fans will run full speed.
160
161* PWM Control
162
163There are three PWM outputs. The LM85 datasheet suggests that the
164pwm3 output control both fan3 and fan4. Each PWM can be individually
165configured and assigned to a zone for it's control value. Each PWM can be
166configured individually according to the following options.
167
168* pwm#_auto_pwm_min - this specifies the PWM value for temp#_auto_temp_off
169 temperature. (PWM value from 0 to 255)
170
171* pwm#_auto_pwm_freq - select base frequency of PWM output. You can select
172 in range of 10.0 to 94.0 Hz in .1 Hz units.
173 (Values 100 to 940).
174
175The pwm#_auto_pwm_freq can be set to one of the following 8 values. Setting the
176frequency to a value not on this list, will result in the next higher frequency
177being selected. The actual device frequency may vary slightly from this
178specification as designed by the manufacturer. Consult the datasheet for more
179details. (PWM Frequency values: 100, 150, 230, 300, 380, 470, 620, 940)
180
181* pwm#_auto_pwm_minctl - this flags selects for temp#_auto_temp_off temperature
182 the bahaviour of fans. Write 1 to let fans spinning at
183 pwm#_auto_pwm_min or write 0 to let them off.
184
185NOTE: It has been reported that there is a bug in the LM85 that causes the flag
186to be associated with the zones not the PWMs. This contradicts all the
187published documentation. Setting pwm#_min_ctl in this case actually affects all
188PWMs controlled by zone '#'.
189
190* PWM Controlling Zone selection
191
192* pwm#_auto_channels - controls zone that is associated with PWM
193
194Configuration choices:
195
196 Value Meaning
197 ------ ------------------------------------------------
198 1 Controlled by Zone 1
199 2 Controlled by Zone 2
200 3 Controlled by Zone 3
201 23 Controlled by higher temp of Zone 2 or 3
202 123 Controlled by highest temp of Zone 1, 2 or 3
203 0 PWM always 0% (off)
204 -1 PWM always 100% (full on)
205 -2 Manual control (write to 'pwm#' to set)
206
207The National LM85's have two vendor specific configuration
208features. Tach. mode and Spinup Control. For more details on these,
209see the LM85 datasheet or Application Note AN-1260.
210
211The Analog Devices ADM1027 has several vendor specific enhancements.
212The number of pulses-per-rev of the fans can be set, Tach monitoring
213can be optimized for PWM operation, and an offset can be applied to
214the temperatures to compensate for systemic errors in the
215measurements.
216
217In addition to the ADM1027 features, the ADT7463 also has Tmin control
218and THERM asserted counts. Automatic Tmin control acts to adjust the
219Tmin value to maintain the measured temperature sensor at a specified
220temperature. There isn't much documentation on this feature in the
221ADT7463 data sheet. This is not supported by current driver.
diff --git a/Documentation/i2c/chips/lm87 b/Documentation/i2c/chips/lm87
new file mode 100644
index 000000000000..c952c57f0e11
--- /dev/null
+++ b/Documentation/i2c/chips/lm87
@@ -0,0 +1,73 @@
1Kernel driver lm87
2==================
3
4Supported chips:
5 * National Semiconductor LM87
6 Prefix: 'lm87'
7 Addresses scanned: I2C 0x2c - 0x2f
8 Datasheet: http://www.national.com/pf/LM/LM87.html
9
10Authors:
11 Frodo Looijaard <frodol@dds.nl>,
12 Philip Edelbrock <phil@netroedge.com>,
13 Mark Studebaker <mdsxyz123@yahoo.com>,
14 Stephen Rousset <stephen.rousset@rocketlogix.com>,
15 Dan Eaton <dan.eaton@rocketlogix.com>,
16 Jean Delvare <khali@linux-fr.org>,
17 Original 2.6 port Jeff Oliver
18
19Description
20-----------
21
22This driver implements support for the National Semiconductor LM87.
23
24The LM87 implements up to three temperature sensors, up to two fan
25rotation speed sensors, up to seven voltage sensors, alarms, and some
26miscellaneous stuff.
27
28Temperatures are measured in degrees Celsius. Each input has a high
29and low alarm settings. A high limit produces an alarm when the value
30goes above it, and an alarm is also produced when the value goes below
31the low limit.
32
33Fan rotation speeds are reported in RPM (rotations per minute). An alarm is
34triggered if the rotation speed has dropped below a programmable limit. Fan
35readings can be divided by a programmable divider (1, 2, 4 or 8) to give
36the readings more range or accuracy. Not all RPM values can accurately be
37represented, so some rounding is done. With a divider of 2, the lowest
38representable value is around 2600 RPM.
39
40Voltage sensors (also known as IN sensors) report their values in
41volts. An alarm is triggered if the voltage has crossed a programmable
42minimum or maximum limit. Note that minimum in this case always means
43'closest to zero'; this is important for negative voltage measurements.
44
45If an alarm triggers, it will remain triggered until the hardware register
46is read at least once. This means that the cause for the alarm may
47already have disappeared! Note that in the current implementation, all
48hardware registers are read whenever any data is read (unless it is less
49than 1.0 seconds since the last update). This means that you can easily
50miss once-only alarms.
51
52The lm87 driver only updates its values each 1.0 seconds; reading it more
53often will do no harm, but will return 'old' values.
54
55
56Hardware Configurations
57-----------------------
58
59The LM87 has four pins which can serve one of two possible functions,
60depending on the hardware configuration.
61
62Some functions share pins, so not all functions are available at the same
63time. Which are depends on the hardware setup. This driver assumes that
64the BIOS configured the chip correctly. In that respect, it differs from
65the original driver (from lm_sensors for Linux 2.4), which would force the
66LM87 to an arbitrary, compile-time chosen mode, regardless of the actual
67chipset wiring.
68
69For reference, here is the list of exclusive functions:
70 - in0+in5 (default) or temp3
71 - fan1 (default) or in6
72 - fan2 (default) or in7
73 - VID lines (default) or IRQ lines (not handled by this driver)
diff --git a/Documentation/i2c/chips/lm90 b/Documentation/i2c/chips/lm90
new file mode 100644
index 000000000000..2c4cf39471f4
--- /dev/null
+++ b/Documentation/i2c/chips/lm90
@@ -0,0 +1,121 @@
1Kernel driver lm90
2==================
3
4Supported chips:
5 * National Semiconductor LM90
6 Prefix: 'lm90'
7 Addresses scanned: I2C 0x4c
8 Datasheet: Publicly available at the National Semiconductor website
9 http://www.national.com/pf/LM/LM90.html
10 * National Semiconductor LM89
11 Prefix: 'lm99'
12 Addresses scanned: I2C 0x4c and 0x4d
13 Datasheet: Publicly available at the National Semiconductor website
14 http://www.national.com/pf/LM/LM89.html
15 * National Semiconductor LM99
16 Prefix: 'lm99'
17 Addresses scanned: I2C 0x4c and 0x4d
18 Datasheet: Publicly available at the National Semiconductor website
19 http://www.national.com/pf/LM/LM99.html
20 * National Semiconductor LM86
21 Prefix: 'lm86'
22 Addresses scanned: I2C 0x4c
23 Datasheet: Publicly available at the National Semiconductor website
24 http://www.national.com/pf/LM/LM86.html
25 * Analog Devices ADM1032
26 Prefix: 'adm1032'
27 Addresses scanned: I2C 0x4c
28 Datasheet: Publicly available at the Analog Devices website
29 http://products.analog.com/products/info.asp?product=ADM1032
30 * Analog Devices ADT7461
31 Prefix: 'adt7461'
32 Addresses scanned: I2C 0x4c
33 Datasheet: Publicly available at the Analog Devices website
34 http://products.analog.com/products/info.asp?product=ADT7461
35 Note: Only if in ADM1032 compatibility mode
36 * Maxim MAX6657
37 Prefix: 'max6657'
38 Addresses scanned: I2C 0x4c
39 Datasheet: Publicly available at the Maxim website
40 http://www.maxim-ic.com/quick_view2.cfm/qv_pk/2578
41 * Maxim MAX6658
42 Prefix: 'max6657'
43 Addresses scanned: I2C 0x4c
44 Datasheet: Publicly available at the Maxim website
45 http://www.maxim-ic.com/quick_view2.cfm/qv_pk/2578
46 * Maxim MAX6659
47 Prefix: 'max6657'
48 Addresses scanned: I2C 0x4c, 0x4d (unsupported 0x4e)
49 Datasheet: Publicly available at the Maxim website
50 http://www.maxim-ic.com/quick_view2.cfm/qv_pk/2578
51
52
53Author: Jean Delvare <khali@linux-fr.org>
54
55
56Description
57-----------
58
59The LM90 is a digital temperature sensor. It senses its own temperature as
60well as the temperature of up to one external diode. It is compatible
61with many other devices such as the LM86, the LM89, the LM99, the ADM1032,
62the MAX6657, MAX6658 and the MAX6659 all of which are supported by this driver.
63Note that there is no easy way to differentiate between the last three
64variants. The extra address and features of the MAX6659 are not supported by
65this driver. Additionally, the ADT7461 is supported if found in ADM1032
66compatibility mode.
67
68The specificity of this family of chipsets over the ADM1021/LM84
69family is that it features critical limits with hysteresis, and an
70increased resolution of the remote temperature measurement.
71
72The different chipsets of the family are not strictly identical, although
73very similar. This driver doesn't handle any specific feature for now,
74but could if there ever was a need for it. For reference, here comes a
75non-exhaustive list of specific features:
76
77LM90:
78 * Filter and alert configuration register at 0xBF.
79 * ALERT is triggered by temperatures over critical limits.
80
81LM86 and LM89:
82 * Same as LM90
83 * Better external channel accuracy
84
85LM99:
86 * Same as LM89
87 * External temperature shifted by 16 degrees down
88
89ADM1032:
90 * Consecutive alert register at 0x22.
91 * Conversion averaging.
92 * Up to 64 conversions/s.
93 * ALERT is triggered by open remote sensor.
94
95ADT7461
96 * Extended temperature range (breaks compatibility)
97 * Lower resolution for remote temperature
98
99MAX6657 and MAX6658:
100 * Remote sensor type selection
101
102MAX6659
103 * Selectable address
104 * Second critical temperature limit
105 * Remote sensor type selection
106
107All temperature values are given in degrees Celsius. Resolution
108is 1.0 degree for the local temperature, 0.125 degree for the remote
109temperature.
110
111Each sensor has its own high and low limits, plus a critical limit.
112Additionally, there is a relative hysteresis value common to both critical
113values. To make life easier to user-space applications, two absolute values
114are exported, one for each channel, but these values are of course linked.
115Only the local hysteresis can be set from user-space, and the same delta
116applies to the remote hysteresis.
117
118The lm90 driver will not update its values more frequently than every
119other second; reading them more often will do no harm, but will return
120'old' values.
121
diff --git a/Documentation/i2c/chips/lm92 b/Documentation/i2c/chips/lm92
new file mode 100644
index 000000000000..7705bfaa0708
--- /dev/null
+++ b/Documentation/i2c/chips/lm92
@@ -0,0 +1,37 @@
1Kernel driver lm92
2==================
3
4Supported chips:
5 * National Semiconductor LM92
6 Prefix: 'lm92'
7 Addresses scanned: I2C 0x48 - 0x4b
8 Datasheet: http://www.national.com/pf/LM/LM92.html
9 * National Semiconductor LM76
10 Prefix: 'lm92'
11 Addresses scanned: none, force parameter needed
12 Datasheet: http://www.national.com/pf/LM/LM76.html
13 * Maxim MAX6633/MAX6634/MAX6635
14 Prefix: 'lm92'
15 Addresses scanned: I2C 0x48 - 0x4b
16 MAX6633 with address in 0x40 - 0x47, 0x4c - 0x4f needs force parameter
17 and MAX6634 with address in 0x4c - 0x4f needs force parameter
18 Datasheet: http://www.maxim-ic.com/quick_view2.cfm/qv_pk/3074
19
20Authors:
21 Abraham van der Merwe <abraham@2d3d.co.za>
22 Jean Delvare <khali@linux-fr.org>
23
24
25Description
26-----------
27
28This driver implements support for the National Semiconductor LM92
29temperature sensor.
30
31Each LM92 temperature sensor supports a single temperature sensor. There are
32alarms for high, low, and critical thresholds. There's also an hysteresis to
33control the thresholds for resetting alarms.
34
35Support was added later for the LM76 and Maxim MAX6633/MAX6634/MAX6635,
36which are mostly compatible. They have not all been tested, so you
37may need to use the force parameter.
diff --git a/Documentation/i2c/chips/max1619 b/Documentation/i2c/chips/max1619
new file mode 100644
index 000000000000..d6f8d9cd7d7f
--- /dev/null
+++ b/Documentation/i2c/chips/max1619
@@ -0,0 +1,29 @@
1Kernel driver max1619
2=====================
3
4Supported chips:
5 * Maxim MAX1619
6 Prefix: 'max1619'
7 Addresses scanned: I2C 0x18-0x1a, 0x29-0x2b, 0x4c-0x4e
8 Datasheet: Publicly available at the Maxim website
9 http://pdfserv.maxim-ic.com/en/ds/MAX1619.pdf
10
11Authors:
12 Alexey Fisher <fishor@mail.ru>,
13 Jean Delvare <khali@linux-fr.org>
14
15Description
16-----------
17
18The MAX1619 is a digital temperature sensor. It senses its own temperature as
19well as the temperature of up to one external diode.
20
21All temperature values are given in degrees Celsius. Resolution
22is 1.0 degree for the local temperature and for the remote temperature.
23
24Only the external sensor has high and low limits.
25
26The max1619 driver will not update its values more frequently than every
27other second; reading them more often will do no harm, but will return
28'old' values.
29
diff --git a/Documentation/i2c/chips/max6875 b/Documentation/i2c/chips/max6875
new file mode 100644
index 000000000000..b4fb49b41813
--- /dev/null
+++ b/Documentation/i2c/chips/max6875
@@ -0,0 +1,54 @@
1Kernel driver max6875
2=====================
3
4Supported chips:
5 * Maxim max6874, max6875
6 Prefixes: 'max6875'
7 Addresses scanned: 0x50, 0x52
8 Datasheets:
9 http://pdfserv.maxim-ic.com/en/ds/MAX6874-MAX6875.pdf
10
11Author: Ben Gardner <bgardner@wabtec.com>
12
13
14Module Parameters
15-----------------
16
17* allow_write int
18 Set to non-zero to enable write permission:
19 *0: Read only
20 1: Read and write
21
22
23Description
24-----------
25
26The MAXIM max6875 is a EEPROM-programmable power-supply sequencer/supervisor.
27It provides timed outputs that can be used as a watchdog, if properly wired.
28It also provides 512 bytes of user EEPROM.
29
30At reset, the max6875 reads the configuration eeprom into its configuration
31registers. The chip then begins to operate according to the values in the
32registers.
33
34See the datasheet for details on how to program the EEPROM.
35
36
37Sysfs entries
38-------------
39
40eeprom_user - 512 bytes of user-defined EEPROM space. Only writable if
41 allow_write was set and register 0x43 is 0.
42
43eeprom_config - 70 bytes of config EEPROM. Note that changes will not get
44 loaded into register space until a power cycle or device reset.
45
46reg_config - 70 bytes of register space. Any changes take affect immediately.
47
48
49General Remarks
50---------------
51
52A typical application will require that the EEPROMs be programmed once and
53never altered afterwards.
54
diff --git a/Documentation/i2c/chips/pc87360 b/Documentation/i2c/chips/pc87360
new file mode 100644
index 000000000000..89a8fcfa78df
--- /dev/null
+++ b/Documentation/i2c/chips/pc87360
@@ -0,0 +1,189 @@
1Kernel driver pc87360
2=====================
3
4Supported chips:
5 * National Semiconductor PC87360, PC87363, PC87364, PC87365 and PC87366
6 Prefixes: 'pc87360', 'pc87363', 'pc87364', 'pc87365', 'pc87366'
7 Addresses scanned: none, address read from Super I/O config space
8 Datasheets:
9 http://www.national.com/pf/PC/PC87360.html
10 http://www.national.com/pf/PC/PC87363.html
11 http://www.national.com/pf/PC/PC87364.html
12 http://www.national.com/pf/PC/PC87365.html
13 http://www.national.com/pf/PC/PC87366.html
14
15Authors: Jean Delvare <khali@linux-fr.org>
16
17Thanks to Sandeep Mehta, Tonko de Rooy and Daniel Ceregatti for testing.
18Thanks to Rudolf Marek for helping me investigate conversion issues.
19
20
21Module Parameters
22-----------------
23
24* init int
25 Chip initialization level:
26 0: None
27 *1: Forcibly enable internal voltage and temperature channels, except in9
28 2: Forcibly enable all voltage and temperature channels, except in9
29 3: Forcibly enable all voltage and temperature channels, including in9
30
31Note that this parameter has no effect for the PC87360, PC87363 and PC87364
32chips.
33
34Also note that for the PC87366, initialization levels 2 and 3 don't enable
35all temperature channels, because some of them share pins with each other,
36so they can't be used at the same time.
37
38
39Description
40-----------
41
42The National Semiconductor PC87360 Super I/O chip contains monitoring and
43PWM control circuitry for two fans. The PC87363 chip is similar, and the
44PC87364 chip has monitoring and PWM control for a third fan.
45
46The National Semiconductor PC87365 and PC87366 Super I/O chips are complete
47hardware monitoring chipsets, not only controlling and monitoring three fans,
48but also monitoring eleven voltage inputs and two (PC87365) or up to four
49(PC87366) temperatures.
50
51 Chip #vin #fan #pwm #temp devid
52
53 PC87360 - 2 2 - 0xE1
54 PC87363 - 2 2 - 0xE8
55 PC87364 - 3 3 - 0xE4
56 PC87365 11 3 3 2 0xE5
57 PC87366 11 3 3 3-4 0xE9
58
59The driver assumes that no more than one chip is present, and one of the
60standard Super I/O addresses is used (0x2E/0x2F or 0x4E/0x4F)
61
62Fan Monitoring
63--------------
64
65Fan rotation speeds are reported in RPM (revolutions per minute). An alarm
66is triggered if the rotation speed has dropped below a programmable limit.
67A different alarm is triggered if the fan speed is too low to be measured.
68
69Fan readings are affected by a programmable clock divider, giving the
70readings more range or accuracy. Usually, users have to learn how it works,
71but this driver implements dynamic clock divider selection, so you don't
72have to care no more.
73
74For reference, here are a few values about clock dividers:
75
76 slowest accuracy highest
77 measurable around 3000 accurate
78 divider speed (RPM) RPM (RPM) speed (RPM)
79 1 1882 18 6928
80 2 941 37 4898
81 4 470 74 3464
82 8 235 150 2449
83
84For the curious, here is how the values above were computed:
85 * slowest measurable speed: clock/(255*divider)
86 * accuracy around 3000 RPM: 3000^2/clock
87 * highest accurate speed: sqrt(clock*100)
88The clock speed for the PC87360 family is 480 kHz. I arbitrarily chose 100
89RPM as the lowest acceptable accuracy.
90
91As mentioned above, you don't have to care about this no more.
92
93Note that not all RPM values can be represented, even when the best clock
94divider is selected. This is not only true for the measured speeds, but
95also for the programmable low limits, so don't be surprised if you try to
96set, say, fan1_min to 2900 and it finally reads 2909.
97
98
99Fan Control
100-----------
101
102PWM (pulse width modulation) values range from 0 to 255, with 0 meaning
103that the fan is stopped, and 255 meaning that the fan goes at full speed.
104
105Be extremely careful when changing PWM values. Low PWM values, even
106non-zero, can stop the fan, which may cause irreversible damage to your
107hardware if temperature increases too much. When changing PWM values, go
108step by step and keep an eye on temperatures.
109
110One user reported problems with PWM. Changing PWM values would break fan
111speed readings. No explanation nor fix could be found.
112
113
114Temperature Monitoring
115----------------------
116
117Temperatures are reported in degrees Celsius. Each temperature measured has
118associated low, high and overtemperature limits, each of which triggers an
119alarm when crossed.
120
121The first two temperature channels are external. The third one (PC87366
122only) is internal.
123
124The PC87366 has three additional temperature channels, based on
125thermistors (as opposed to thermal diodes for the first three temperature
126channels). For technical reasons, these channels are held by the VLM
127(voltage level monitor) logical device, not the TMS (temperature
128measurement) one. As a consequence, these temperatures are exported as
129voltages, and converted into temperatures in user-space.
130
131Note that these three additional channels share their pins with the
132external thermal diode channels, so you (physically) can't use them all at
133the same time. Although it should be possible to mix the two sensor types,
134the documents from National Semiconductor suggest that motherboard
135manufacturers should choose one type and stick to it. So you will more
136likely have either channels 1 to 3 (thermal diodes) or 3 to 6 (internal
137thermal diode, and thermistors).
138
139
140Voltage Monitoring
141------------------
142
143Voltages are reported relatively to a reference voltage, either internal or
144external. Some of them (in7:Vsb, in8:Vdd and in10:AVdd) are divided by two
145internally, you will have to compensate in sensors.conf. Others (in0 to in6)
146are likely to be divided externally. The meaning of each of these inputs as
147well as the values of the resistors used for division is left to the
148motherboard manufacturers, so you will have to document yourself and edit
149sensors.conf accordingly. National Semiconductor has a document with
150recommended resistor values for some voltages, but this still leaves much
151room for per motherboard specificities, unfortunately. Even worse,
152motherboard manufacturers don't seem to care about National Semiconductor's
153recommendations.
154
155Each voltage measured has associated low and high limits, each of which
156triggers an alarm when crossed.
157
158When available, VID inputs are used to provide the nominal CPU Core voltage.
159The driver will default to VRM 9.0, but this can be changed from user-space.
160The chipsets can handle two sets of VID inputs (on dual-CPU systems), but
161the driver will only export one for now. This may change later if there is
162a need.
163
164
165General Remarks
166---------------
167
168If an alarm triggers, it will remain triggered until the hardware register
169is read at least once. This means that the cause for the alarm may already
170have disappeared! Note that all hardware registers are read whenever any
171data is read (unless it is less than 2 seconds since the last update, in
172which case cached values are returned instead). As a consequence, when
173a once-only alarm triggers, it may take 2 seconds for it to show, and 2
174more seconds for it to disappear.
175
176Monitoring of in9 isn't enabled at lower init levels (<3) because that
177channel measures the battery voltage (Vbat). It is a known fact that
178repeatedly sampling the battery voltage reduces its lifetime. National
179Semiconductor smartly designed their chipset so that in9 is sampled only
180once every 1024 sampling cycles (that is every 34 minutes at the default
181sampling rate), so the effect is attenuated, but still present.
182
183
184Limitations
185-----------
186
187The datasheets suggests that some values (fan mins, fan dividers)
188shouldn't be changed once the monitoring has started, but we ignore that
189recommendation. We'll reconsider if it actually causes trouble.
diff --git a/Documentation/i2c/chips/pca9539 b/Documentation/i2c/chips/pca9539
new file mode 100644
index 000000000000..c4fce6a13537
--- /dev/null
+++ b/Documentation/i2c/chips/pca9539
@@ -0,0 +1,47 @@
1Kernel driver pca9539
2=====================
3
4Supported chips:
5 * Philips PCA9539
6 Prefix: 'pca9539'
7 Addresses scanned: 0x74 - 0x77
8 Datasheet:
9 http://www.semiconductors.philips.com/acrobat/datasheets/PCA9539_2.pdf
10
11Author: Ben Gardner <bgardner@wabtec.com>
12
13
14Description
15-----------
16
17The Philips PCA9539 is a 16 bit low power I/O device.
18All 16 lines can be individually configured as an input or output.
19The input sense can also be inverted.
20The 16 lines are split between two bytes.
21
22
23Sysfs entries
24-------------
25
26Each is a byte that maps to the 8 I/O bits.
27A '0' suffix is for bits 0-7, while '1' is for bits 8-15.
28
29input[01] - read the current value
30output[01] - sets the output value
31direction[01] - direction of each bit: 1=input, 0=output
32invert[01] - toggle the input bit sense
33
34input reads the actual state of the line and is always available.
35The direction defaults to input for all channels.
36
37
38General Remarks
39---------------
40
41Note that each output, direction, and invert entry controls 8 lines.
42You should use the read, modify, write sequence.
43For example. to set output bit 0 of 1.
44 val=$(cat output0)
45 val=$(( $val | 1 ))
46 echo $val > output0
47
diff --git a/Documentation/i2c/chips/pcf8574 b/Documentation/i2c/chips/pcf8574
new file mode 100644
index 000000000000..2752c8ce3167
--- /dev/null
+++ b/Documentation/i2c/chips/pcf8574
@@ -0,0 +1,69 @@
1Kernel driver pcf8574
2=====================
3
4Supported chips:
5 * Philips PCF8574
6 Prefix: 'pcf8574'
7 Addresses scanned: I2C 0x20 - 0x27
8 Datasheet: Publicly available at the Philips Semiconductors website
9 http://www.semiconductors.philips.com/pip/PCF8574P.html
10
11 * Philips PCF8574A
12 Prefix: 'pcf8574a'
13 Addresses scanned: I2C 0x38 - 0x3f
14 Datasheet: Publicly available at the Philips Semiconductors website
15 http://www.semiconductors.philips.com/pip/PCF8574P.html
16
17Authors:
18 Frodo Looijaard <frodol@dds.nl>,
19 Philip Edelbrock <phil@netroedge.com>,
20 Dan Eaton <dan.eaton@rocketlogix.com>,
21 Aurelien Jarno <aurelien@aurel32.net>,
22 Jean Delvare <khali@linux-fr.org>,
23
24
25Description
26-----------
27The PCF8574(A) is an 8-bit I/O expander for the I2C bus produced by Philips
28Semiconductors. It is designed to provide a byte I2C interface to up to 16
29separate devices (8 x PCF8574 and 8 x PCF8574A).
30
31This device consists of a quasi-bidirectional port. Each of the eight I/Os
32can be independently used as an input or output. To setup an I/O as an
33input, you have to write a 1 to the corresponding output.
34
35For more informations see the datasheet.
36
37
38Accessing PCF8574(A) via /sys interface
39-------------------------------------
40
41! Be careful !
42The PCF8574(A) is plainly impossible to detect ! Stupid chip.
43So every chip with address in the interval [20..27] and [38..3f] are
44detected as PCF8574(A). If you have other chips in this address
45range, the workaround is to load this module after the one
46for your others chips.
47
48On detection (i.e. insmod, modprobe et al.), directories are being
49created for each detected PCF8574(A):
50
51/sys/bus/i2c/devices/<0>-<1>/
52where <0> is the bus the chip was detected on (e. g. i2c-0)
53and <1> the chip address ([20..27] or [38..3f]):
54
55(example: /sys/bus/i2c/devices/1-0020/)
56
57Inside these directories, there are two files each:
58read and write (and one file with chip name).
59
60The read file is read-only. Reading gives you the current I/O input
61if the corresponding output is set as 1, otherwise the current output
62value, that is to say 0.
63
64The write file is read/write. Writing a value outputs it on the I/O
65port. Reading returns the last written value.
66
67On module initialization the chip is configured as eight inputs (all
68outputs to 1), so you can connect any circuit to the PCF8574(A) without
69being afraid of short-circuit.
diff --git a/Documentation/i2c/chips/pcf8591 b/Documentation/i2c/chips/pcf8591
new file mode 100644
index 000000000000..5628fcf4207f
--- /dev/null
+++ b/Documentation/i2c/chips/pcf8591
@@ -0,0 +1,90 @@
1Kernel driver pcf8591
2=====================
3
4Supported chips:
5 * Philips PCF8591
6 Prefix: 'pcf8591'
7 Addresses scanned: I2C 0x48 - 0x4f
8 Datasheet: Publicly available at the Philips Semiconductor website
9 http://www.semiconductors.philips.com/pip/PCF8591P.html
10
11Authors:
12 Aurelien Jarno <aurelien@aurel32.net>
13 valuable contributions by Jan M. Sendler <sendler@sendler.de>,
14 Jean Delvare <khali@linux-fr.org>
15
16
17Description
18-----------
19The PCF8591 is an 8-bit A/D and D/A converter (4 analog inputs and one
20analog output) for the I2C bus produced by Philips Semiconductors. It
21is designed to provide a byte I2C interface to up to 4 separate devices.
22
23The PCF8591 has 4 analog inputs programmable as single-ended or
24differential inputs :
25- mode 0 : four single ended inputs
26 Pins AIN0 to AIN3 are single ended inputs for channels 0 to 3
27
28- mode 1 : three differential inputs
29 Pins AIN3 is the common negative differential input
30 Pins AIN0 to AIN2 are positive differential inputs for channels 0 to 2
31
32- mode 2 : single ended and differential mixed
33 Pins AIN0 and AIN1 are single ended inputs for channels 0 and 1
34 Pins AIN2 is the positive differential input for channel 3
35 Pins AIN3 is the negative differential input for channel 3
36
37- mode 3 : two differential inputs
38 Pins AIN0 is the positive differential input for channel 0
39 Pins AIN1 is the negative differential input for channel 0
40 Pins AIN2 is the positive differential input for channel 1
41 Pins AIN3 is the negative differential input for channel 1
42
43See the datasheet for details.
44
45Module parameters
46-----------------
47
48* input_mode int
49
50 Analog input mode:
51 0 = four single ended inputs
52 1 = three differential inputs
53 2 = single ended and differential mixed
54 3 = two differential inputs
55
56
57Accessing PCF8591 via /sys interface
58-------------------------------------
59
60! Be careful !
61The PCF8591 is plainly impossible to detect ! Stupid chip.
62So every chip with address in the interval [48..4f] is
63detected as PCF8591. If you have other chips in this address
64range, the workaround is to load this module after the one
65for your others chips.
66
67On detection (i.e. insmod, modprobe et al.), directories are being
68created for each detected PCF8591:
69
70/sys/bus/devices/<0>-<1>/
71where <0> is the bus the chip was detected on (e. g. i2c-0)
72and <1> the chip address ([48..4f])
73
74Inside these directories, there are such files:
75in0, in1, in2, in3, out0_enable, out0_output, name
76
77Name contains chip name.
78
79The in0, in1, in2 and in3 files are RO. Reading gives the value of the
80corresponding channel. Depending on the current analog inputs configuration,
81files in2 and/or in3 do not exist. Values range are from 0 to 255 for single
82ended inputs and -128 to +127 for differential inputs (8-bit ADC).
83
84The out0_enable file is RW. Reading gives "1" for analog output enabled and
85"0" for analog output disabled. Writing accepts "0" and "1" accordingly.
86
87The out0_output file is RW. Writing a number between 0 and 255 (8-bit DAC), send
88the value to the digital-to-analog converter. Note that a voltage will
89only appears on AOUT pin if aout0_enable equals 1. Reading returns the last
90value written.
diff --git a/Documentation/i2c/chips/sis5595 b/Documentation/i2c/chips/sis5595
new file mode 100644
index 000000000000..b7ae36b8cdf5
--- /dev/null
+++ b/Documentation/i2c/chips/sis5595
@@ -0,0 +1,106 @@
1Kernel driver sis5595
2=====================
3
4Supported chips:
5 * Silicon Integrated Systems Corp. SiS5595 Southbridge Hardware Monitor
6 Prefix: 'sis5595'
7 Addresses scanned: ISA in PCI-space encoded address
8 Datasheet: Publicly available at the Silicon Integrated Systems Corp. site.
9
10Authors:
11 Kyösti Mälkki <kmalkki@cc.hut.fi>,
12 Mark D. Studebaker <mdsxyz123@yahoo.com>,
13 Aurelien Jarno <aurelien@aurel32.net> 2.6 port
14
15 SiS southbridge has a LM78-like chip integrated on the same IC.
16 This driver is a customized copy of lm78.c
17
18 Supports following revisions:
19 Version PCI ID PCI Revision
20 1 1039/0008 AF or less
21 2 1039/0008 B0 or greater
22
23 Note: these chips contain a 0008 device which is incompatible with the
24 5595. We recognize these by the presence of the listed
25 "blacklist" PCI ID and refuse to load.
26
27 NOT SUPPORTED PCI ID BLACKLIST PCI ID
28 540 0008 0540
29 550 0008 0550
30 5513 0008 5511
31 5581 0008 5597
32 5582 0008 5597
33 5597 0008 5597
34 630 0008 0630
35 645 0008 0645
36 730 0008 0730
37 735 0008 0735
38
39
40Module Parameters
41-----------------
42force_addr=0xaddr Set the I/O base address. Useful for boards
43 that don't set the address in the BIOS. Does not do a
44 PCI force; the device must still be present in lspci.
45 Don't use this unless the driver complains that the
46 base address is not set.
47 Example: 'modprobe sis5595 force_addr=0x290'
48
49
50Description
51-----------
52
53The SiS5595 southbridge has integrated hardware monitor functions. It also
54has an I2C bus, but this driver only supports the hardware monitor. For the
55I2C bus driver see i2c-sis5595.
56
57The SiS5595 implements zero or one temperature sensor, two fan speed
58sensors, four or five voltage sensors, and alarms.
59
60On the first version of the chip, there are four voltage sensors and one
61temperature sensor.
62
63On the second version of the chip, the temperature sensor (temp) and the
64fifth voltage sensor (in4) share a pin which is configurable, but not
65through the driver. Sorry. The driver senses the configuration of the pin,
66which was hopefully set by the BIOS.
67
68Temperatures are measured in degrees Celsius. An alarm is triggered once
69when the max is crossed; it is also triggered when it drops below the min
70value. Measurements are guaranteed between -55 and +125 degrees, with a
71resolution of 1 degree.
72
73Fan rotation speeds are reported in RPM (rotations per minute). An alarm is
74triggered if the rotation speed has dropped below a programmable limit. Fan
75readings can be divided by a programmable divider (1, 2, 4 or 8) to give
76the readings more range or accuracy. Not all RPM values can accurately be
77represented, so some rounding is done. With a divider of 2, the lowest
78representable value is around 2600 RPM.
79
80Voltage sensors (also known as IN sensors) report their values in volts. An
81alarm is triggered if the voltage has crossed a programmable minimum or
82maximum limit. Note that minimum in this case always means 'closest to
83zero'; this is important for negative voltage measurements. All voltage
84inputs can measure voltages between 0 and 4.08 volts, with a resolution of
850.016 volt.
86
87In addition to the alarms described above, there is a BTI alarm, which gets
88triggered when an external chip has crossed its limits. Usually, this is
89connected to some LM75-like chip; if at least one crosses its limits, this
90bit gets set.
91
92If an alarm triggers, it will remain triggered until the hardware register
93is read at least once. This means that the cause for the alarm may already
94have disappeared! Note that in the current implementation, all hardware
95registers are read whenever any data is read (unless it is less than 1.5
96seconds since the last update). This means that you can easily miss
97once-only alarms.
98
99The SiS5595 only updates its values each 1.5 seconds; reading it more often
100will do no harm, but will return 'old' values.
101
102Problems
103--------
104Some chips refuse to be enabled. We don't know why.
105The driver will recognize this and print a message in dmesg.
106
diff --git a/Documentation/i2c/chips/smsc47b397.txt b/Documentation/i2c/chips/smsc47b397
index 389edae7f8df..da9d80c96432 100644
--- a/Documentation/i2c/chips/smsc47b397.txt
+++ b/Documentation/i2c/chips/smsc47b397
@@ -1,7 +1,19 @@
1Kernel driver smsc47b397
2========================
3
4Supported chips:
5 * SMSC LPC47B397-NC
6 Prefix: 'smsc47b397'
7 Addresses scanned: none, address read from Super I/O config space
8 Datasheet: In this file
9
10Authors: Mark M. Hoffman <mhoffman@lightlink.com>
11 Utilitek Systems, Inc.
12
1November 23, 2004 13November 23, 2004
2 14
3The following specification describes the SMSC LPC47B397-NC sensor chip 15The following specification describes the SMSC LPC47B397-NC sensor chip
4(for which there is no public datasheet available). This document was 16(for which there is no public datasheet available). This document was
5provided by Craig Kelly (In-Store Broadcast Network) and edited/corrected 17provided by Craig Kelly (In-Store Broadcast Network) and edited/corrected
6by Mark M. Hoffman <mhoffman@lightlink.com>. 18by Mark M. Hoffman <mhoffman@lightlink.com>.
7 19
@@ -10,10 +22,10 @@ by Mark M. Hoffman <mhoffman@lightlink.com>.
10Methods for detecting the HP SIO and reading the thermal data on a dc7100. 22Methods for detecting the HP SIO and reading the thermal data on a dc7100.
11 23
12The thermal information on the dc7100 is contained in the SIO Hardware Monitor 24The thermal information on the dc7100 is contained in the SIO Hardware Monitor
13(HWM). The information is accessed through an index/data pair. The index/data 25(HWM). The information is accessed through an index/data pair. The index/data
14pair is located at the HWM Base Address + 0 and the HWM Base Address + 1. The 26pair is located at the HWM Base Address + 0 and the HWM Base Address + 1. The
15HWM Base address can be obtained from Logical Device 8, registers 0x60 (MSB) 27HWM Base address can be obtained from Logical Device 8, registers 0x60 (MSB)
16and 0x61 (LSB). Currently we are using 0x480 for the HWM Base Address and 28and 0x61 (LSB). Currently we are using 0x480 for the HWM Base Address and
170x480 and 0x481 for the index/data pair. 290x480 and 0x481 for the index/data pair.
18 30
19Reading temperature information. 31Reading temperature information.
@@ -50,7 +62,7 @@ Reading the tach LSB locks the tach MSB.
50The LSB Must be read first. 62The LSB Must be read first.
51 63
52How to convert the tach reading to RPM. 64How to convert the tach reading to RPM.
53The tach reading (TCount) is given by: (Tach MSB * 256) + (Tach LSB) 65The tach reading (TCount) is given by: (Tach MSB * 256) + (Tach LSB)
54The SIO counts the number of 90kHz (11.111us) pulses per revolution. 66The SIO counts the number of 90kHz (11.111us) pulses per revolution.
55RPM = 60/(TCount * 11.111us) 67RPM = 60/(TCount * 11.111us)
56 68
@@ -72,20 +84,20 @@ To program the configuration registers, the following sequence must be followed:
72 84
73Enter Configuration Mode 85Enter Configuration Mode
74To place the chip into the Configuration State The config key (0x55) is written 86To place the chip into the Configuration State The config key (0x55) is written
75to the CONFIG PORT (0x2E). 87to the CONFIG PORT (0x2E).
76 88
77Configuration Mode 89Configuration Mode
78In configuration mode, the INDEX PORT is located at the CONFIG PORT address and 90In configuration mode, the INDEX PORT is located at the CONFIG PORT address and
79the DATA PORT is at INDEX PORT address + 1. 91the DATA PORT is at INDEX PORT address + 1.
80 92
81The desired configuration registers are accessed in two steps: 93The desired configuration registers are accessed in two steps:
82a. Write the index of the Logical Device Number Configuration Register 94a. Write the index of the Logical Device Number Configuration Register
83 (i.e., 0x07) to the INDEX PORT and then write the number of the 95 (i.e., 0x07) to the INDEX PORT and then write the number of the
84 desired logical device to the DATA PORT. 96 desired logical device to the DATA PORT.
85 97
86b. Write the address of the desired configuration register within the 98b. Write the address of the desired configuration register within the
87 logical device to the INDEX PORT and then write or read the config- 99 logical device to the INDEX PORT and then write or read the config-
88 uration register through the DATA PORT. 100 uration register through the DATA PORT.
89 101
90Note: If accessing the Global Configuration Registers, step (a) is not required. 102Note: If accessing the Global Configuration Registers, step (a) is not required.
91 103
@@ -96,18 +108,18 @@ The chip returns to the RUN State. (This is important).
96Programming Example 108Programming Example
97The following is an example of how to read the SIO Device ID located at 0x20 109The following is an example of how to read the SIO Device ID located at 0x20
98 110
99; ENTER CONFIGURATION MODE 111; ENTER CONFIGURATION MODE
100MOV DX,02EH 112MOV DX,02EH
101MOV AX,055H 113MOV AX,055H
102OUT DX,AL 114OUT DX,AL
103; GLOBAL CONFIGURATION REGISTER 115; GLOBAL CONFIGURATION REGISTER
104MOV DX,02EH 116MOV DX,02EH
105MOV AL,20H 117MOV AL,20H
106OUT DX,AL 118OUT DX,AL
107; READ THE DATA 119; READ THE DATA
108MOV DX,02FH 120MOV DX,02FH
109IN AL,DX 121IN AL,DX
110; EXIT CONFIGURATION MODE 122; EXIT CONFIGURATION MODE
111MOV DX,02EH 123MOV DX,02EH
112MOV AX,0AAH 124MOV AX,0AAH
113OUT DX,AL 125OUT DX,AL
@@ -122,12 +134,12 @@ Obtaining the HWM Base Address.
122The following is an example of how to read the HWM Base Address located in 134The following is an example of how to read the HWM Base Address located in
123Logical Device 8. 135Logical Device 8.
124 136
125; ENTER CONFIGURATION MODE 137; ENTER CONFIGURATION MODE
126MOV DX,02EH 138MOV DX,02EH
127MOV AX,055H 139MOV AX,055H
128OUT DX,AL 140OUT DX,AL
129; CONFIGURE REGISTER CRE0, 141; CONFIGURE REGISTER CRE0,
130; LOGICAL DEVICE 8 142; LOGICAL DEVICE 8
131MOV DX,02EH 143MOV DX,02EH
132MOV AL,07H 144MOV AL,07H
133OUT DX,AL ;Point to LD# Config Reg 145OUT DX,AL ;Point to LD# Config Reg
@@ -135,12 +147,12 @@ MOV DX,02FH
135MOV AL, 08H 147MOV AL, 08H
136OUT DX,AL;Point to Logical Device 8 148OUT DX,AL;Point to Logical Device 8
137; 149;
138MOV DX,02EH 150MOV DX,02EH
139MOV AL,60H 151MOV AL,60H
140OUT DX,AL ; Point to HWM Base Addr MSB 152OUT DX,AL ; Point to HWM Base Addr MSB
141MOV DX,02FH 153MOV DX,02FH
142IN AL,DX ; Get MSB of HWM Base Addr 154IN AL,DX ; Get MSB of HWM Base Addr
143; EXIT CONFIGURATION MODE 155; EXIT CONFIGURATION MODE
144MOV DX,02EH 156MOV DX,02EH
145MOV AX,0AAH 157MOV AX,0AAH
146OUT DX,AL 158OUT DX,AL
diff --git a/Documentation/i2c/chips/smsc47m1 b/Documentation/i2c/chips/smsc47m1
new file mode 100644
index 000000000000..34e6478c1425
--- /dev/null
+++ b/Documentation/i2c/chips/smsc47m1
@@ -0,0 +1,52 @@
1Kernel driver smsc47m1
2======================
3
4Supported chips:
5 * SMSC LPC47B27x, LPC47M10x, LPC47M13x, LPC47M14x, LPC47M15x and LPC47M192
6 Addresses scanned: none, address read from Super I/O config space
7 Prefix: 'smsc47m1'
8 Datasheets:
9 http://www.smsc.com/main/datasheets/47b27x.pdf
10 http://www.smsc.com/main/datasheets/47m10x.pdf
11 http://www.smsc.com/main/tools/discontinued/47m13x.pdf
12 http://www.smsc.com/main/datasheets/47m14x.pdf
13 http://www.smsc.com/main/tools/discontinued/47m15x.pdf
14 http://www.smsc.com/main/datasheets/47m192.pdf
15
16Authors:
17 Mark D. Studebaker <mdsxyz123@yahoo.com>,
18 With assistance from Bruce Allen <ballen@uwm.edu>, and his
19 fan.c program: http://www.lsc-group.phys.uwm.edu/%7Eballen/driver/
20 Gabriele Gorla <gorlik@yahoo.com>,
21 Jean Delvare <khali@linux-fr.org>
22
23Description
24-----------
25
26The Standard Microsystems Corporation (SMSC) 47M1xx Super I/O chips
27contain monitoring and PWM control circuitry for two fans.
28
29The 47M15x and 47M192 chips contain a full 'hardware monitoring block'
30in addition to the fan monitoring and control. The hardware monitoring
31block is not supported by the driver.
32
33Fan rotation speeds are reported in RPM (rotations per minute). An alarm is
34triggered if the rotation speed has dropped below a programmable limit. Fan
35readings can be divided by a programmable divider (1, 2, 4 or 8) to give
36the readings more range or accuracy. Not all RPM values can accurately be
37represented, so some rounding is done. With a divider of 2, the lowest
38representable value is around 2600 RPM.
39
40PWM values are from 0 to 255.
41
42If an alarm triggers, it will remain triggered until the hardware register
43is read at least once. This means that the cause for the alarm may
44already have disappeared! Note that in the current implementation, all
45hardware registers are read whenever any data is read (unless it is less
46than 1.5 seconds since the last update). This means that you can easily
47miss once-only alarms.
48
49
50**********************
51The lm_sensors project gratefully acknowledges the support of
52Intel in the development of this driver.
diff --git a/Documentation/i2c/chips/via686a b/Documentation/i2c/chips/via686a
new file mode 100644
index 000000000000..b82014cb7c53
--- /dev/null
+++ b/Documentation/i2c/chips/via686a
@@ -0,0 +1,65 @@
1Kernel driver via686a
2=====================
3
4Supported chips:
5 * Via VT82C686A, VT82C686B Southbridge Integrated Hardware Monitor
6 Prefix: 'via686a'
7 Addresses scanned: ISA in PCI-space encoded address
8 Datasheet: On request through web form (http://www.via.com.tw/en/support/datasheets/)
9
10Authors:
11 Kyösti Mälkki <kmalkki@cc.hut.fi>,
12 Mark D. Studebaker <mdsxyz123@yahoo.com>
13 Bob Dougherty <bobd@stanford.edu>
14 (Some conversion-factor data were contributed by
15 Jonathan Teh Soon Yew <j.teh@iname.com>
16 and Alex van Kaam <darkside@chello.nl>.)
17
18Module Parameters
19-----------------
20
21force_addr=0xaddr Set the I/O base address. Useful for Asus A7V boards
22 that don't set the address in the BIOS. Does not do a
23 PCI force; the via686a must still be present in lspci.
24 Don't use this unless the driver complains that the
25 base address is not set.
26 Example: 'modprobe via686a force_addr=0x6000'
27
28Description
29-----------
30
31The driver does not distinguish between the chips and reports
32all as a 686A.
33
34The Via 686a southbridge has integrated hardware monitor functionality.
35It also has an I2C bus, but this driver only supports the hardware monitor.
36For the I2C bus driver, see <file:Documentation/i2c/busses/i2c-viapro>
37
38The Via 686a implements three temperature sensors, two fan rotation speed
39sensors, five voltage sensors and alarms.
40
41Temperatures are measured in degrees Celsius. An alarm is triggered once
42when the Overtemperature Shutdown limit is crossed; it is triggered again
43as soon as it drops below the hysteresis value.
44
45Fan rotation speeds are reported in RPM (rotations per minute). An alarm is
46triggered if the rotation speed has dropped below a programmable limit. Fan
47readings can be divided by a programmable divider (1, 2, 4 or 8) to give
48the readings more range or accuracy. Not all RPM values can accurately be
49represented, so some rounding is done. With a divider of 2, the lowest
50representable value is around 2600 RPM.
51
52Voltage sensors (also known as IN sensors) report their values in volts.
53An alarm is triggered if the voltage has crossed a programmable minimum
54or maximum limit. Voltages are internally scalled, so each voltage channel
55has a different resolution and range.
56
57If an alarm triggers, it will remain triggered until the hardware register
58is read at least once. This means that the cause for the alarm may
59already have disappeared! Note that in the current implementation, all
60hardware registers are read whenever any data is read (unless it is less
61than 1.5 seconds since the last update). This means that you can easily
62miss once-only alarms.
63
64The driver only updates its values each 1.5 seconds; reading it more often
65will do no harm, but will return 'old' values.
diff --git a/Documentation/i2c/chips/w83627hf b/Documentation/i2c/chips/w83627hf
new file mode 100644
index 000000000000..78f37c2d602e
--- /dev/null
+++ b/Documentation/i2c/chips/w83627hf
@@ -0,0 +1,66 @@
1Kernel driver w83627hf
2======================
3
4Supported chips:
5 * Winbond W83627HF (ISA accesses ONLY)
6 Prefix: 'w83627hf'
7 Addresses scanned: ISA address retrieved from Super I/O registers
8 Datasheet: http://www.winbond.com/PDF/sheet/w83627hf.pdf
9 * Winbond W83627THF
10 Prefix: 'w83627thf'
11 Addresses scanned: ISA address retrieved from Super I/O registers
12 Datasheet: http://www.winbond.com/PDF/sheet/w83627thf.pdf
13 * Winbond W83697HF
14 Prefix: 'w83697hf'
15 Addresses scanned: ISA address retrieved from Super I/O registers
16 Datasheet: http://www.winbond.com/PDF/sheet/697hf.pdf
17 * Winbond W83637HF
18 Prefix: 'w83637hf'
19 Addresses scanned: ISA address retrieved from Super I/O registers
20 Datasheet: http://www.winbond.com/PDF/sheet/w83637hf.pdf
21
22Authors:
23 Frodo Looijaard <frodol@dds.nl>,
24 Philip Edelbrock <phil@netroedge.com>,
25 Mark Studebaker <mdsxyz123@yahoo.com>,
26 Bernhard C. Schrenk <clemy@clemy.org>
27
28Module Parameters
29-----------------
30
31* force_addr: int
32 Initialize the ISA address of the sensors
33* force_i2c: int
34 Initialize the I2C address of the sensors
35* init: int
36 (default is 1)
37 Use 'init=0' to bypass initializing the chip.
38 Try this if your computer crashes when you load the module.
39
40Description
41-----------
42
43This driver implements support for ISA accesses *only* for
44the Winbond W83627HF, W83627THF, W83697HF and W83637HF Super I/O chips.
45We will refer to them collectively as Winbond chips.
46
47This driver supports ISA accesses, which should be more reliable
48than i2c accesses. Also, for Tyan boards which contain both a
49Super I/O chip and a second i2c-only Winbond chip (often a W83782D),
50using this driver will avoid i2c address conflicts and complex
51initialization that were required in the w83781d driver.
52
53If you really want i2c accesses for these Super I/O chips,
54use the w83781d driver. However this is not the preferred method
55now that this ISA driver has been developed.
56
57Technically, the w83627thf does not support a VID reading. However, it's
58possible or even likely that your mainboard maker has routed these signals
59to a specific set of general purpose IO pins (the Asus P4C800-E is one such
60board). The w83627thf driver now interprets these as VID. If the VID on
61your board doesn't work, first see doc/vid in the lm_sensors package. If
62that still doesn't help, email us at lm-sensors@lm-sensors.org.
63
64For further information on this driver see the w83781d driver
65documentation.
66
diff --git a/Documentation/i2c/chips/w83781d b/Documentation/i2c/chips/w83781d
new file mode 100644
index 000000000000..e5459333ba68
--- /dev/null
+++ b/Documentation/i2c/chips/w83781d
@@ -0,0 +1,402 @@
1Kernel driver w83781d
2=====================
3
4Supported chips:
5 * Winbond W83781D
6 Prefix: 'w83781d'
7 Addresses scanned: I2C 0x20 - 0x2f, ISA 0x290 (8 I/O ports)
8 Datasheet: http://www.winbond-usa.com/products/winbond_products/pdfs/PCIC/w83781d.pdf
9 * Winbond W83782D
10 Prefix: 'w83782d'
11 Addresses scanned: I2C 0x20 - 0x2f, ISA 0x290 (8 I/O ports)
12 Datasheet: http://www.winbond.com/PDF/sheet/w83782d.pdf
13 * Winbond W83783S
14 Prefix: 'w83783s'
15 Addresses scanned: I2C 0x2d
16 Datasheet: http://www.winbond-usa.com/products/winbond_products/pdfs/PCIC/w83783s.pdf
17 * Winbond W83627HF
18 Prefix: 'w83627hf'
19 Addresses scanned: I2C 0x20 - 0x2f, ISA 0x290 (8 I/O ports)
20 Datasheet: http://www.winbond.com/PDF/sheet/w83627hf.pdf
21 * Asus AS99127F
22 Prefix: 'as99127f'
23 Addresses scanned: I2C 0x28 - 0x2f
24 Datasheet: Unavailable from Asus
25
26Authors:
27 Frodo Looijaard <frodol@dds.nl>,
28 Philip Edelbrock <phil@netroedge.com>,
29 Mark Studebaker <mdsxyz123@yahoo.com>
30
31Module parameters
32-----------------
33
34* init int
35 (default 1)
36 Use 'init=0' to bypass initializing the chip.
37 Try this if your computer crashes when you load the module.
38
39force_subclients=bus,caddr,saddr,saddr
40 This is used to force the i2c addresses for subclients of
41 a certain chip. Typical usage is `force_subclients=0,0x2d,0x4a,0x4b'
42 to force the subclients of chip 0x2d on bus 0 to i2c addresses
43 0x4a and 0x4b. This parameter is useful for certain Tyan boards.
44
45Description
46-----------
47
48This driver implements support for the Winbond W83781D, W83782D, W83783S,
49W83627HF chips, and the Asus AS99127F chips. We will refer to them
50collectively as W8378* chips.
51
52There is quite some difference between these chips, but they are similar
53enough that it was sensible to put them together in one driver.
54The W83627HF chip is assumed to be identical to the ISA W83782D.
55The Asus chips are similar to an I2C-only W83782D.
56
57Chip #vin #fanin #pwm #temp wchipid vendid i2c ISA
58as99127f 7 3 0 3 0x31 0x12c3 yes no
59as99127f rev.2 (type_name = as99127f) 0x31 0x5ca3 yes no
60w83781d 7 3 0 3 0x10-1 0x5ca3 yes yes
61w83627hf 9 3 2 3 0x21 0x5ca3 yes yes(LPC)
62w83782d 9 3 2-4 3 0x30 0x5ca3 yes yes
63w83783s 5-6 3 2 1-2 0x40 0x5ca3 yes no
64
65Detection of these chips can sometimes be foiled because they can be in
66an internal state that allows no clean access. If you know the address
67of the chip, use a 'force' parameter; this will put them into a more
68well-behaved state first.
69
70The W8378* implements temperature sensors (three on the W83781D and W83782D,
71two on the W83783S), three fan rotation speed sensors, voltage sensors
72(seven on the W83781D, nine on the W83782D and six on the W83783S), VID
73lines, alarms with beep warnings, and some miscellaneous stuff.
74
75Temperatures are measured in degrees Celsius. There is always one main
76temperature sensor, and one (W83783S) or two (W83781D and W83782D) other
77sensors. An alarm is triggered for the main sensor once when the
78Overtemperature Shutdown limit is crossed; it is triggered again as soon as
79it drops below the Hysteresis value. A more useful behavior
80can be found by setting the Hysteresis value to +127 degrees Celsius; in
81this case, alarms are issued during all the time when the actual temperature
82is above the Overtemperature Shutdown value. The driver sets the
83hysteresis value for temp1 to 127 at initialization.
84
85For the other temperature sensor(s), an alarm is triggered when the
86temperature gets higher then the Overtemperature Shutdown value; it stays
87on until the temperature falls below the Hysteresis value. But on the
88W83781D, there is only one alarm that functions for both other sensors!
89Temperatures are guaranteed within a range of -55 to +125 degrees. The
90main temperature sensors has a resolution of 1 degree; the other sensor(s)
91of 0.5 degree.
92
93Fan rotation speeds are reported in RPM (rotations per minute). An alarm is
94triggered if the rotation speed has dropped below a programmable limit. Fan
95readings can be divided by a programmable divider (1, 2, 4 or 8 for the
96W83781D; 1, 2, 4, 8, 16, 32, 64 or 128 for the others) to give
97the readings more range or accuracy. Not all RPM values can accurately
98be represented, so some rounding is done. With a divider of 2, the lowest
99representable value is around 2600 RPM.
100
101Voltage sensors (also known as IN sensors) report their values in volts.
102An alarm is triggered if the voltage has crossed a programmable minimum
103or maximum limit. Note that minimum in this case always means 'closest to
104zero'; this is important for negative voltage measurements. All voltage
105inputs can measure voltages between 0 and 4.08 volts, with a resolution
106of 0.016 volt.
107
108The VID lines encode the core voltage value: the voltage level your processor
109should work with. This is hardcoded by the mainboard and/or processor itself.
110It is a value in volts. When it is unconnected, you will often find the
111value 3.50 V here.
112
113The W83782D and W83783S temperature conversion machine understands about
114several kinds of temperature probes. You can program the so-called
115beta value in the sensor files. '1' is the PII/Celeron diode, '2' is the
116TN3904 transistor, and 3435 the default thermistor value. Other values
117are (not yet) supported.
118
119In addition to the alarms described above, there is a CHAS alarm on the
120chips which triggers if your computer case is open.
121
122When an alarm goes off, you can be warned by a beeping signal through
123your computer speaker. It is possible to enable all beeping globally,
124or only the beeping for some alarms.
125
126If an alarm triggers, it will remain triggered until the hardware register
127is read at least once. This means that the cause for the alarm may
128already have disappeared! Note that in the current implementation, all
129hardware registers are read whenever any data is read (unless it is less
130than 1.5 seconds since the last update). This means that you can easily
131miss once-only alarms.
132
133The chips only update values each 1.5 seconds; reading them more often
134will do no harm, but will return 'old' values.
135
136AS99127F PROBLEMS
137-----------------
138The as99127f support was developed without the benefit of a datasheet.
139In most cases it is treated as a w83781d (although revision 2 of the
140AS99127F looks more like a w83782d).
141This support will be BETA until a datasheet is released.
142One user has reported problems with fans stopping
143occasionally.
144
145Note that the individual beep bits are inverted from the other chips.
146The driver now takes care of this so that user-space applications
147don't have to know about it.
148
149Known problems:
150 - Problems with diode/thermistor settings (supported?)
151 - One user reports fans stopping under high server load.
152 - Revision 2 seems to have 2 PWM registers but we don't know
153 how to handle them. More details below.
154
155These will not be fixed unless we get a datasheet.
156If you have problems, please lobby Asus to release a datasheet.
157Unfortunately several others have without success.
158Please do not send mail to us asking for better as99127f support.
159We have done the best we can without a datasheet.
160Please do not send mail to the author or the sensors group asking for
161a datasheet or ideas on how to convince Asus. We can't help.
162
163
164NOTES:
165-----
166 783s has no in1 so that in[2-6] are compatible with the 781d/782d.
167
168 783s pin is programmable for -5V or temp1; defaults to -5V,
169 no control in driver so temp1 doesn't work.
170
171 782d and 783s datasheets differ on which is pwm1 and which is pwm2.
172 We chose to follow 782d.
173
174 782d and 783s pin is programmable for fan3 input or pwm2 output;
175 defaults to fan3 input.
176 If pwm2 is enabled (with echo 255 1 > pwm2), then
177 fan3 will report 0.
178
179 782d has pwm1-2 for ISA, pwm1-4 for i2c. (pwm3-4 share pins with
180 the ISA pins)
181
182Data sheet updates:
183------------------
184 - PWM clock registers:
185
186 000: master / 512
187 001: master / 1024
188 010: master / 2048
189 011: master / 4096
190 100: master / 8192
191
192
193Answers from Winbond tech support
194---------------------------------
195>
196> 1) In the W83781D data sheet section 7.2 last paragraph, it talks about
197> reprogramming the R-T table if the Beta of the thermistor is not
198> 3435K. The R-T table is described briefly in section 8.20.
199> What formulas do I use to program a new R-T table for a given Beta?
200>
201 We are sorry that the calculation for R-T table value is
202confidential. If you have another Beta value of thermistor, we can help
203to calculate the R-T table for you. But you should give us real R-T
204Table which can be gotten by thermistor vendor. Therefore we will calculate
205them and obtain 32-byte data, and you can fill the 32-byte data to the
206register in Bank0.CR51 of W83781D.
207
208
209> 2) In the W83782D data sheet, it mentions that pins 38, 39, and 40 are
210> programmable to be either thermistor or Pentium II diode inputs.
211> How do I program them for diode inputs? I can't find any register
212> to program these to be diode inputs.
213 --> You may program Bank0 CR[5Dh] and CR[59h] registers.
214
215 CR[5Dh] bit 1(VTIN1) bit 2(VTIN2) bit 3(VTIN3)
216
217 thermistor 0 0 0
218 diode 1 1 1
219
220
221(error) CR[59h] bit 4(VTIN1) bit 2(VTIN2) bit 3(VTIN3)
222(right) CR[59h] bit 4(VTIN1) bit 5(VTIN2) bit 6(VTIN3)
223
224 PII thermal diode 1 1 1
225 2N3904 diode 0 0 0
226
227
228Asus Clones
229-----------
230
231We have no datasheets for the Asus clones (AS99127F and ASB100 Bach).
232Here are some very useful information that were given to us by Alex Van
233Kaam about how to detect these chips, and how to read their values. He
234also gives advice for another Asus chipset, the Mozart-2 (which we
235don't support yet). Thanks Alex!
236I reworded some parts and added personal comments.
237
238# Detection:
239
240AS99127F rev.1, AS99127F rev.2 and ASB100:
241- I2C address range: 0x29 - 0x2F
242- If register 0x58 holds 0x31 then we have an Asus (either ASB100 or
243 AS99127F)
244- Which one depends on register 0x4F (manufacturer ID):
245 0x06 or 0x94: ASB100
246 0x12 or 0xC3: AS99127F rev.1
247 0x5C or 0xA3: AS99127F rev.2
248 Note that 0x5CA3 is Winbond's ID (WEC), which let us think Asus get their
249 AS99127F rev.2 direct from Winbond. The other codes mean ATT and DVC,
250 respectively. ATT could stand for Asustek something (although it would be
251 very badly chosen IMHO), I don't know what DVC could stand for. Maybe
252 these codes simply aren't meant to be decoded that way.
253
254Mozart-2:
255- I2C address: 0x77
256- If register 0x58 holds 0x56 or 0x10 then we have a Mozart-2
257- Of the Mozart there are 3 types:
258 0x58=0x56, 0x4E=0x94, 0x4F=0x36: Asus ASM58 Mozart-2
259 0x58=0x56, 0x4E=0x94, 0x4F=0x06: Asus AS2K129R Mozart-2
260 0x58=0x10, 0x4E=0x5C, 0x4F=0xA3: Asus ??? Mozart-2
261 You can handle all 3 the exact same way :)
262
263# Temperature sensors:
264
265ASB100:
266- sensor 1: register 0x27
267- sensor 2 & 3 are the 2 LM75's on the SMBus
268- sensor 4: register 0x17
269Remark: I noticed that on Intel boards sensor 2 is used for the CPU
270 and 4 is ignored/stuck, on AMD boards sensor 4 is the CPU and sensor 2 is
271 either ignored or a socket temperature.
272
273AS99127F (rev.1 and 2 alike):
274- sensor 1: register 0x27
275- sensor 2 & 3 are the 2 LM75's on the SMBus
276Remark: Register 0x5b is suspected to be temperature type selector. Bit 1
277 would control temp1, bit 3 temp2 and bit 5 temp3.
278
279Mozart-2:
280- sensor 1: register 0x27
281- sensor 2: register 0x13
282
283# Fan sensors:
284
285ASB100, AS99127F (rev.1 and 2 alike):
286- 3 fans, identical to the W83781D
287
288Mozart-2:
289- 2 fans only, 1350000/RPM/div
290- fan 1: register 0x28, divisor on register 0xA1 (bits 4-5)
291- fan 2: register 0x29, divisor on register 0xA1 (bits 6-7)
292
293# Voltages:
294
295This is where there is a difference between AS99127F rev.1 and 2.
296Remark: The difference is similar to the difference between
297 W83781D and W83782D.
298
299ASB100:
300in0=r(0x20)*0.016
301in1=r(0x21)*0.016
302in2=r(0x22)*0.016
303in3=r(0x23)*0.016*1.68
304in4=r(0x24)*0.016*3.8
305in5=r(0x25)*(-0.016)*3.97
306in6=r(0x26)*(-0.016)*1.666
307
308AS99127F rev.1:
309in0=r(0x20)*0.016
310in1=r(0x21)*0.016
311in2=r(0x22)*0.016
312in3=r(0x23)*0.016*1.68
313in4=r(0x24)*0.016*3.8
314in5=r(0x25)*(-0.016)*3.97
315in6=r(0x26)*(-0.016)*1.503
316
317AS99127F rev.2:
318in0=r(0x20)*0.016
319in1=r(0x21)*0.016
320in2=r(0x22)*0.016
321in3=r(0x23)*0.016*1.68
322in4=r(0x24)*0.016*3.8
323in5=(r(0x25)*0.016-3.6)*5.14+3.6
324in6=(r(0x26)*0.016-3.6)*3.14+3.6
325
326Mozart-2:
327in0=r(0x20)*0.016
328in1=255
329in2=r(0x22)*0.016
330in3=r(0x23)*0.016*1.68
331in4=r(0x24)*0.016*4
332in5=255
333in6=255
334
335
336# PWM
337
338Additional info about PWM on the AS99127F (may apply to other Asus
339chips as well) by Jean Delvare as of 2004-04-09:
340
341AS99127F revision 2 seems to have two PWM registers at 0x59 and 0x5A,
342and a temperature sensor type selector at 0x5B (which basically means
343that they swapped registers 0x59 and 0x5B when you compare with Winbond
344chips).
345Revision 1 of the chip also has the temperature sensor type selector at
3460x5B, but PWM registers have no effect.
347
348We don't know exactly how the temperature sensor type selection works.
349Looks like bits 1-0 are for temp1, bits 3-2 for temp2 and bits 5-4 for
350temp3, although it is possible that only the most significant bit matters
351each time. So far, values other than 0 always broke the readings.
352
353PWM registers seem to be split in two parts: bit 7 is a mode selector,
354while the other bits seem to define a value or threshold.
355
356When bit 7 is clear, bits 6-0 seem to hold a threshold value. If the value
357is below a given limit, the fan runs at low speed. If the value is above
358the limit, the fan runs at full speed. We have no clue as to what the limit
359represents. Note that there seem to be some inertia in this mode, speed
360changes may need some time to trigger. Also, an hysteresis mechanism is
361suspected since walking through all the values increasingly and then
362decreasingly led to slightly different limits.
363
364When bit 7 is set, bits 3-0 seem to hold a threshold value, while bits 6-4
365would not be significant. If the value is below a given limit, the fan runs
366at full speed, while if it is above the limit it runs at low speed (so this
367is the contrary of the other mode, in a way). Here again, we don't know
368what the limit is supposed to represent.
369
370One remarkable thing is that the fans would only have two or three
371different speeds (transitional states left apart), not a whole range as
372you usually get with PWM.
373
374As a conclusion, you can write 0x00 or 0x8F to the PWM registers to make
375fans run at low speed, and 0x7F or 0x80 to make them run at full speed.
376
377Please contact us if you can figure out how it is supposed to work. As
378long as we don't know more, the w83781d driver doesn't handle PWM on
379AS99127F chips at all.
380
381Additional info about PWM on the AS99127F rev.1 by Hector Martin:
382
383I've been fiddling around with the (in)famous 0x59 register and
384found out the following values do work as a form of coarse pwm:
385
3860x80 - seems to turn fans off after some time(1-2 minutes)... might be
387some form of auto-fan-control based on temp? hmm (Qfan? this mobo is an
388old ASUS, it isn't marketed as Qfan. Maybe some beta pre-attemp at Qfan
389that was dropped at the BIOS)
3900x81 - off
3910x82 - slightly "on-ner" than off, but my fans do not get to move. I can
392hear the high-pitched PWM sound that motors give off at too-low-pwm.
3930x83 - now they do move. Estimate about 70% speed or so.
3940x84-0x8f - full on
395
396Changing the high nibble doesn't seem to do much except the high bit
397(0x80) must be set for PWM to work, else the current pwm doesn't seem to
398change.
399
400My mobo is an ASUS A7V266-E. This behavior is similar to what I got
401with speedfan under Windows, where 0-15% would be off, 15-2x% (can't
402remember the exact value) would be 70% and higher would be full on.
diff --git a/Documentation/i2c/chips/w83l785ts b/Documentation/i2c/chips/w83l785ts
new file mode 100644
index 000000000000..1841cedc25b2
--- /dev/null
+++ b/Documentation/i2c/chips/w83l785ts
@@ -0,0 +1,39 @@
1Kernel driver w83l785ts
2=======================
3
4Supported chips:
5 * Winbond W83L785TS-S
6 Prefix: 'w83l785ts'
7 Addresses scanned: I2C 0x2e
8 Datasheet: Publicly available at the Winbond USA website
9 http://www.winbond-usa.com/products/winbond_products/pdfs/PCIC/W83L785TS-S.pdf
10
11Authors:
12 Jean Delvare <khali@linux-fr.org>
13
14Description
15-----------
16
17The W83L785TS-S is a digital temperature sensor. It senses the
18temperature of a single external diode. The high limit is
19theoretically defined as 85 or 100 degrees C through a combination
20of external resistors, so the user cannot change it. Values seen so
21far suggest that the two possible limits are actually 95 and 110
22degrees C. The datasheet is rather poor and obviously inaccurate
23on several points including this one.
24
25All temperature values are given in degrees Celsius. Resolution
26is 1.0 degree. See the datasheet for details.
27
28The w83l785ts driver will not update its values more frequently than
29every other second; reading them more often will do no harm, but will
30return 'old' values.
31
32Known Issues
33------------
34
35On some systems (Asus), the BIOS is known to interfere with the driver
36and cause read errors. The driver will retry a given number of times
37(5 by default) and then give up, returning the old value (or 0 if
38there is no old value). It seems to work well enough so that you should
39not notice anything. Thanks to James Bolt for helping test this feature.
diff --git a/Documentation/i2c/porting-clients b/Documentation/i2c/porting-clients
index 56404918eabc..a7adbdd9ea8a 100644
--- a/Documentation/i2c/porting-clients
+++ b/Documentation/i2c/porting-clients
@@ -57,7 +57,7 @@ Technical changes:
57 Documentation/i2c/sysfs-interface for the individual files. Also 57 Documentation/i2c/sysfs-interface for the individual files. Also
58 convert the units these files read and write to the specified ones. 58 convert the units these files read and write to the specified ones.
59 If you need to add a new type of file, please discuss it on the 59 If you need to add a new type of file, please discuss it on the
60 sensors mailing list <sensors@stimpy.netroedge.com> by providing a 60 sensors mailing list <lm-sensors@lm-sensors.org> by providing a
61 patch to the Documentation/i2c/sysfs-interface file. 61 patch to the Documentation/i2c/sysfs-interface file.
62 62
63* [Attach] For I2C drivers, the attach function should make sure 63* [Attach] For I2C drivers, the attach function should make sure
diff --git a/Documentation/i2c/userspace-tools b/Documentation/i2c/userspace-tools
new file mode 100644
index 000000000000..2622aac65422
--- /dev/null
+++ b/Documentation/i2c/userspace-tools
@@ -0,0 +1,39 @@
1Introduction
2------------
3
4Most mainboards have sensor chips to monitor system health (like temperatures,
5voltages, fans speed). They are often connected through an I2C bus, but some
6are also connected directly through the ISA bus.
7
8The kernel drivers make the data from the sensor chips available in the /sys
9virtual filesystem. Userspace tools are then used to display or set or the
10data in a more friendly manner.
11
12Lm-sensors
13----------
14
15Core set of utilites that will allow you to obtain health information,
16setup monitoring limits etc. You can get them on their homepage
17http://www.lm-sensors.nu/ or as a package from your Linux distribution.
18
19If from website:
20Get lmsensors from project web site. Please note, you need only userspace
21part, so compile with "make user_install" target.
22
23General hints to get things working:
24
250) get lm-sensors userspace utils
261) compile all drivers in I2C section as modules in your kernel
272) run sensors-detect script, it will tell you what modules you need to load.
283) load them and run "sensors" command, you should see some results.
294) fix sensors.conf, labels, limits, fan divisors
305) if any more problems consult FAQ, or documentation
31
32Other utilites
33--------------
34
35If you want some graphical indicators of system health look for applications
36like: gkrellm, ksensors, xsensors, wmtemp, wmsensors, wmgtemp, ksysguardd,
37hardware-monitor
38
39If you are server administrator you can try snmpd or mrtgutils.
diff --git a/Documentation/i2c/writing-clients b/Documentation/i2c/writing-clients
index ad27511e3c7d..f482dae81de3 100644
--- a/Documentation/i2c/writing-clients
+++ b/Documentation/i2c/writing-clients
@@ -171,45 +171,31 @@ The following lists are used internally:
171 171
172 normal_i2c: filled in by the module writer. 172 normal_i2c: filled in by the module writer.
173 A list of I2C addresses which should normally be examined. 173 A list of I2C addresses which should normally be examined.
174 normal_i2c_range: filled in by the module writer.
175 A list of pairs of I2C addresses, each pair being an inclusive range of
176 addresses which should normally be examined.
177 probe: insmod parameter. 174 probe: insmod parameter.
178 A list of pairs. The first value is a bus number (-1 for any I2C bus), 175 A list of pairs. The first value is a bus number (-1 for any I2C bus),
179 the second is the address. These addresses are also probed, as if they 176 the second is the address. These addresses are also probed, as if they
180 were in the 'normal' list. 177 were in the 'normal' list.
181 probe_range: insmod parameter.
182 A list of triples. The first value is a bus number (-1 for any I2C bus),
183 the second and third are addresses. These form an inclusive range of
184 addresses that are also probed, as if they were in the 'normal' list.
185 ignore: insmod parameter. 178 ignore: insmod parameter.
186 A list of pairs. The first value is a bus number (-1 for any I2C bus), 179 A list of pairs. The first value is a bus number (-1 for any I2C bus),
187 the second is the I2C address. These addresses are never probed. 180 the second is the I2C address. These addresses are never probed.
188 This parameter overrules 'normal' and 'probe', but not the 'force' lists. 181 This parameter overrules 'normal' and 'probe', but not the 'force' lists.
189 ignore_range: insmod parameter.
190 A list of triples. The first value is a bus number (-1 for any I2C bus),
191 the second and third are addresses. These form an inclusive range of
192 I2C addresses that are never probed.
193 This parameter overrules 'normal' and 'probe', but not the 'force' lists.
194 force: insmod parameter. 182 force: insmod parameter.
195 A list of pairs. The first value is a bus number (-1 for any I2C bus), 183 A list of pairs. The first value is a bus number (-1 for any I2C bus),
196 the second is the I2C address. A device is blindly assumed to be on 184 the second is the I2C address. A device is blindly assumed to be on
197 the given address, no probing is done. 185 the given address, no probing is done.
198 186
199Fortunately, as a module writer, you just have to define the `normal' 187Fortunately, as a module writer, you just have to define the `normal_i2c'
200and/or `normal_range' parameters. The complete declaration could look 188parameter. The complete declaration could look like this:
201like this:
202 189
203 /* Scan 0x20 to 0x2f, 0x37, and 0x40 to 0x4f */ 190 /* Scan 0x37, and 0x48 to 0x4f */
204 static unsigned short normal_i2c[] = { 0x37,I2C_CLIENT_END }; 191 static unsigned short normal_i2c[] = { 0x37, 0x48, 0x49, 0x4a, 0x4b, 0x4c,
205 static unsigned short normal_i2c_range[] = { 0x20, 0x2f, 0x40, 0x4f, 192 0x4d, 0x4e, 0x4f, I2C_CLIENT_END };
206 I2C_CLIENT_END };
207 193
208 /* Magic definition of all other variables and things */ 194 /* Magic definition of all other variables and things */
209 I2C_CLIENT_INSMOD; 195 I2C_CLIENT_INSMOD;
210 196
211Note that you *have* to call the two defined variables `normal_i2c' and 197Note that you *have* to call the defined variable `normal_i2c',
212`normal_i2c_range', without any prefix! 198without any prefix!
213 199
214 200
215Probing classes (sensors) 201Probing classes (sensors)
@@ -223,39 +209,17 @@ The following lists are used internally. They are all lists of integers.
223 209
224 normal_i2c: filled in by the module writer. Terminated by SENSORS_I2C_END. 210 normal_i2c: filled in by the module writer. Terminated by SENSORS_I2C_END.
225 A list of I2C addresses which should normally be examined. 211 A list of I2C addresses which should normally be examined.
226 normal_i2c_range: filled in by the module writer. Terminated by
227 SENSORS_I2C_END
228 A list of pairs of I2C addresses, each pair being an inclusive range of
229 addresses which should normally be examined.
230 normal_isa: filled in by the module writer. Terminated by SENSORS_ISA_END. 212 normal_isa: filled in by the module writer. Terminated by SENSORS_ISA_END.
231 A list of ISA addresses which should normally be examined. 213 A list of ISA addresses which should normally be examined.
232 normal_isa_range: filled in by the module writer. Terminated by
233 SENSORS_ISA_END
234 A list of triples. The first two elements are ISA addresses, being an
235 range of addresses which should normally be examined. The third is the
236 modulo parameter: only addresses which are 0 module this value relative
237 to the first address of the range are actually considered.
238 probe: insmod parameter. Initialize this list with SENSORS_I2C_END values. 214 probe: insmod parameter. Initialize this list with SENSORS_I2C_END values.
239 A list of pairs. The first value is a bus number (SENSORS_ISA_BUS for 215 A list of pairs. The first value is a bus number (SENSORS_ISA_BUS for
240 the ISA bus, -1 for any I2C bus), the second is the address. These 216 the ISA bus, -1 for any I2C bus), the second is the address. These
241 addresses are also probed, as if they were in the 'normal' list. 217 addresses are also probed, as if they were in the 'normal' list.
242 probe_range: insmod parameter. Initialize this list with SENSORS_I2C_END
243 values.
244 A list of triples. The first value is a bus number (SENSORS_ISA_BUS for
245 the ISA bus, -1 for any I2C bus), the second and third are addresses.
246 These form an inclusive range of addresses that are also probed, as
247 if they were in the 'normal' list.
248 ignore: insmod parameter. Initialize this list with SENSORS_I2C_END values. 218 ignore: insmod parameter. Initialize this list with SENSORS_I2C_END values.
249 A list of pairs. The first value is a bus number (SENSORS_ISA_BUS for 219 A list of pairs. The first value is a bus number (SENSORS_ISA_BUS for
250 the ISA bus, -1 for any I2C bus), the second is the I2C address. These 220 the ISA bus, -1 for any I2C bus), the second is the I2C address. These
251 addresses are never probed. This parameter overrules 'normal' and 221 addresses are never probed. This parameter overrules 'normal' and
252 'probe', but not the 'force' lists. 222 'probe', but not the 'force' lists.
253 ignore_range: insmod parameter. Initialize this list with SENSORS_I2C_END
254 values.
255 A list of triples. The first value is a bus number (SENSORS_ISA_BUS for
256 the ISA bus, -1 for any I2C bus), the second and third are addresses.
257 These form an inclusive range of I2C addresses that are never probed.
258 This parameter overrules 'normal' and 'probe', but not the 'force' lists.
259 223
260Also used is a list of pointers to sensors_force_data structures: 224Also used is a list of pointers to sensors_force_data structures:
261 force_data: insmod parameters. A list, ending with an element of which 225 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:
269So we have a generic insmod variabled `force', and chip-specific variables 233So we have a generic insmod variabled `force', and chip-specific variables
270`force_CHIPNAME'. 234`force_CHIPNAME'.
271 235
272Fortunately, as a module writer, you just have to define the `normal' 236Fortunately, as a module writer, you just have to define the `normal_i2c'
273and/or `normal_range' parameters, and define what chip names are used. 237and `normal_isa' parameters, and define what chip names are used.
274The complete declaration could look like this: 238The complete declaration could look like this:
275 /* Scan i2c addresses 0x20 to 0x2f, 0x37, and 0x40 to 0x4f 239 /* Scan i2c addresses 0x37, and 0x48 to 0x4f */
276 static unsigned short normal_i2c[] = {0x37,SENSORS_I2C_END}; 240 static unsigned short normal_i2c[] = { 0x37, 0x48, 0x49, 0x4a, 0x4b, 0x4c,
277 static unsigned short normal_i2c_range[] = {0x20,0x2f,0x40,0x4f, 241 0x4d, 0x4e, 0x4f, I2C_CLIENT_END };
278 SENSORS_I2C_END};
279 /* Scan ISA address 0x290 */ 242 /* Scan ISA address 0x290 */
280 static unsigned int normal_isa[] = {0x0290,SENSORS_ISA_END}; 243 static unsigned int normal_isa[] = {0x0290,SENSORS_ISA_END};
281 static unsigned int normal_isa_range[] = {SENSORS_ISA_END};
282 244
283 /* Define chips foo and bar, as well as all module parameters and things */ 245 /* Define chips foo and bar, as well as all module parameters and things */
284 SENSORS_INSMOD_2(foo,bar); 246 SENSORS_INSMOD_2(foo,bar);
diff --git a/Documentation/kdump/gdbmacros.txt b/Documentation/kdump/gdbmacros.txt
new file mode 100644
index 000000000000..bc1b9eb92ae1
--- /dev/null
+++ b/Documentation/kdump/gdbmacros.txt
@@ -0,0 +1,179 @@
1#
2# This file contains a few gdb macros (user defined commands) to extract
3# useful information from kernel crashdump (kdump) like stack traces of
4# all the processes or a particular process and trapinfo.
5#
6# These macros can be used by copying this file in .gdbinit (put in home
7# directory or current directory) or by invoking gdb command with
8# --command=<command-file-name> option
9#
10# Credits:
11# Alexander Nyberg <alexn@telia.com>
12# V Srivatsa <vatsa@in.ibm.com>
13# Maneesh Soni <maneesh@in.ibm.com>
14#
15
16define bttnobp
17 set $tasks_off=((size_t)&((struct task_struct *)0)->tasks)
18 set $pid_off=((size_t)&((struct task_struct *)0)->pids[1].pid_list.next)
19 set $init_t=&init_task
20 set $next_t=(((char *)($init_t->tasks).next) - $tasks_off)
21 while ($next_t != $init_t)
22 set $next_t=(struct task_struct *)$next_t
23 printf "\npid %d; comm %s:\n", $next_t.pid, $next_t.comm
24 printf "===================\n"
25 set var $stackp = $next_t.thread.esp
26 set var $stack_top = ($stackp & ~4095) + 4096
27
28 while ($stackp < $stack_top)
29 if (*($stackp) > _stext && *($stackp) < _sinittext)
30 info symbol *($stackp)
31 end
32 set $stackp += 4
33 end
34 set $next_th=(((char *)$next_t->pids[1].pid_list.next) - $pid_off)
35 while ($next_th != $next_t)
36 set $next_th=(struct task_struct *)$next_th
37 printf "\npid %d; comm %s:\n", $next_t.pid, $next_t.comm
38 printf "===================\n"
39 set var $stackp = $next_t.thread.esp
40 set var $stack_top = ($stackp & ~4095) + 4096
41
42 while ($stackp < $stack_top)
43 if (*($stackp) > _stext && *($stackp) < _sinittext)
44 info symbol *($stackp)
45 end
46 set $stackp += 4
47 end
48 set $next_th=(((char *)$next_th->pids[1].pid_list.next) - $pid_off)
49 end
50 set $next_t=(char *)($next_t->tasks.next) - $tasks_off
51 end
52end
53document bttnobp
54 dump all thread stack traces on a kernel compiled with !CONFIG_FRAME_POINTER
55end
56
57define btt
58 set $tasks_off=((size_t)&((struct task_struct *)0)->tasks)
59 set $pid_off=((size_t)&((struct task_struct *)0)->pids[1].pid_list.next)
60 set $init_t=&init_task
61 set $next_t=(((char *)($init_t->tasks).next) - $tasks_off)
62 while ($next_t != $init_t)
63 set $next_t=(struct task_struct *)$next_t
64 printf "\npid %d; comm %s:\n", $next_t.pid, $next_t.comm
65 printf "===================\n"
66 set var $stackp = $next_t.thread.esp
67 set var $stack_top = ($stackp & ~4095) + 4096
68 set var $stack_bot = ($stackp & ~4095)
69
70 set $stackp = *($stackp)
71 while (($stackp < $stack_top) && ($stackp > $stack_bot))
72 set var $addr = *($stackp + 4)
73 info symbol $addr
74 set $stackp = *($stackp)
75 end
76
77 set $next_th=(((char *)$next_t->pids[1].pid_list.next) - $pid_off)
78 while ($next_th != $next_t)
79 set $next_th=(struct task_struct *)$next_th
80 printf "\npid %d; comm %s:\n", $next_t.pid, $next_t.comm
81 printf "===================\n"
82 set var $stackp = $next_t.thread.esp
83 set var $stack_top = ($stackp & ~4095) + 4096
84 set var $stack_bot = ($stackp & ~4095)
85
86 set $stackp = *($stackp)
87 while (($stackp < $stack_top) && ($stackp > $stack_bot))
88 set var $addr = *($stackp + 4)
89 info symbol $addr
90 set $stackp = *($stackp)
91 end
92 set $next_th=(((char *)$next_th->pids[1].pid_list.next) - $pid_off)
93 end
94 set $next_t=(char *)($next_t->tasks.next) - $tasks_off
95 end
96end
97document btt
98 dump all thread stack traces on a kernel compiled with CONFIG_FRAME_POINTER
99end
100
101define btpid
102 set var $pid = $arg0
103 set $tasks_off=((size_t)&((struct task_struct *)0)->tasks)
104 set $pid_off=((size_t)&((struct task_struct *)0)->pids[1].pid_list.next)
105 set $init_t=&init_task
106 set $next_t=(((char *)($init_t->tasks).next) - $tasks_off)
107 set var $pid_task = 0
108
109 while ($next_t != $init_t)
110 set $next_t=(struct task_struct *)$next_t
111
112 if ($next_t.pid == $pid)
113 set $pid_task = $next_t
114 end
115
116 set $next_th=(((char *)$next_t->pids[1].pid_list.next) - $pid_off)
117 while ($next_th != $next_t)
118 set $next_th=(struct task_struct *)$next_th
119 if ($next_th.pid == $pid)
120 set $pid_task = $next_th
121 end
122 set $next_th=(((char *)$next_th->pids[1].pid_list.next) - $pid_off)
123 end
124 set $next_t=(char *)($next_t->tasks.next) - $tasks_off
125 end
126
127 printf "\npid %d; comm %s:\n", $pid_task.pid, $pid_task.comm
128 printf "===================\n"
129 set var $stackp = $pid_task.thread.esp
130 set var $stack_top = ($stackp & ~4095) + 4096
131 set var $stack_bot = ($stackp & ~4095)
132
133 set $stackp = *($stackp)
134 while (($stackp < $stack_top) && ($stackp > $stack_bot))
135 set var $addr = *($stackp + 4)
136 info symbol $addr
137 set $stackp = *($stackp)
138 end
139end
140document btpid
141 backtrace of pid
142end
143
144
145define trapinfo
146 set var $pid = $arg0
147 set $tasks_off=((size_t)&((struct task_struct *)0)->tasks)
148 set $pid_off=((size_t)&((struct task_struct *)0)->pids[1].pid_list.next)
149 set $init_t=&init_task
150 set $next_t=(((char *)($init_t->tasks).next) - $tasks_off)
151 set var $pid_task = 0
152
153 while ($next_t != $init_t)
154 set $next_t=(struct task_struct *)$next_t
155
156 if ($next_t.pid == $pid)
157 set $pid_task = $next_t
158 end
159
160 set $next_th=(((char *)$next_t->pids[1].pid_list.next) - $pid_off)
161 while ($next_th != $next_t)
162 set $next_th=(struct task_struct *)$next_th
163 if ($next_th.pid == $pid)
164 set $pid_task = $next_th
165 end
166 set $next_th=(((char *)$next_th->pids[1].pid_list.next) - $pid_off)
167 end
168 set $next_t=(char *)($next_t->tasks.next) - $tasks_off
169 end
170
171 printf "Trapno %ld, cr2 0x%lx, error_code %ld\n", $pid_task.thread.trap_no, \
172 $pid_task.thread.cr2, $pid_task.thread.error_code
173
174end
175document trapinfo
176 Run info threads and lookup pid of thread #1
177 'trapinfo <pid>' will tell you by which trap & possibly
178 addresthe kernel paniced.
179end
diff --git a/Documentation/kdump/kdump.txt b/Documentation/kdump/kdump.txt
new file mode 100644
index 000000000000..7ff213f4becd
--- /dev/null
+++ b/Documentation/kdump/kdump.txt
@@ -0,0 +1,141 @@
1Documentation for kdump - the kexec-based crash dumping solution
2================================================================
3
4DESIGN
5======
6
7Kdump uses kexec to reboot to a second kernel whenever a dump needs to be taken.
8This second kernel is booted with very little memory. The first kernel reserves
9the section of memory that the second kernel uses. This ensures that on-going
10DMA from the first kernel does not corrupt the second kernel.
11
12All the necessary information about Core image is encoded in ELF format and
13stored in reserved area of memory before crash. Physical address of start of
14ELF header is passed to new kernel through command line parameter elfcorehdr=.
15
16On i386, the first 640 KB of physical memory is needed to boot, irrespective
17of where the kernel loads. Hence, this region is backed up by kexec just before
18rebooting into the new kernel.
19
20In the second kernel, "old memory" can be accessed in two ways.
21
22- The first one is through a /dev/oldmem device interface. A capture utility
23 can read the device file and write out the memory in raw format. This is raw
24 dump of memory and analysis/capture tool should be intelligent enough to
25 determine where to look for the right information. ELF headers (elfcorehdr=)
26 can become handy here.
27
28- The second interface is through /proc/vmcore. This exports the dump as an ELF
29 format file which can be written out using any file copy command
30 (cp, scp, etc). Further, gdb can be used to perform limited debugging on
31 the dump file. This method ensures methods ensure that there is correct
32 ordering of the dump pages (corresponding to the first 640 KB that has been
33 relocated).
34
35SETUP
36=====
37
381) Download http://www.xmission.com/~ebiederm/files/kexec/kexec-tools-1.101.tar.gz
39 and apply http://lse.sourceforge.net/kdump/patches/kexec-tools-1.101-kdump.patch
40 and after that build the source.
41
422) Download and build the appropriate (latest) kexec/kdump (-mm) kernel
43 patchset and apply it to the vanilla kernel tree.
44
45 Two kernels need to be built in order to get this feature working.
46
47 A) First kernel:
48 a) Enable "kexec system call" feature (in Processor type and features).
49 CONFIG_KEXEC=y
50 b) This kernel's physical load address should be the default value of
51 0x100000 (0x100000, 1 MB) (in Processor type and features).
52 CONFIG_PHYSICAL_START=0x100000
53 c) Enable "sysfs file system support" (in Pseudo filesystems).
54 CONFIG_SYSFS=y
55 d) Boot into first kernel with the command line parameter "crashkernel=Y@X".
56 Use appropriate values for X and Y. Y denotes how much memory to reserve
57 for the second kernel, and X denotes at what physical address the reserved
58 memory section starts. For example: "crashkernel=64M@16M".
59
60 B) Second kernel:
61 a) Enable "kernel crash dumps" feature (in Processor type and features).
62 CONFIG_CRASH_DUMP=y
63 b) Specify a suitable value for "Physical address where the kernel is
64 loaded" (in Processor type and features). Typically this value
65 should be same as X (See option d) above, e.g., 16 MB or 0x1000000.
66 CONFIG_PHYSICAL_START=0x1000000
67 c) Enable "/proc/vmcore support" (Optional, in Pseudo filesystems).
68 CONFIG_PROC_VMCORE=y
69 d) Disable SMP support and build a UP kernel (Until it is fixed).
70 CONFIG_SMP=n
71 e) Enable "Local APIC support on uniprocessors".
72 CONFIG_X86_UP_APIC=y
73 f) Enable "IO-APIC support on uniprocessors"
74 CONFIG_X86_UP_IOAPIC=y
75
76 Note: i) Options a) and b) depend upon "Configure standard kernel features
77 (for small systems)" (under General setup).
78 ii) Option a) also depends on CONFIG_HIGHMEM (under Processor
79 type and features).
80 iii) Both option a) and b) are under "Processor type and features".
81
823) Boot into the first kernel. You are now ready to try out kexec-based crash
83 dumps.
84
854) Load the second kernel to be booted using:
86
87 kexec -p <second-kernel> --crash-dump --args-linux --append="root=<root-dev>
88 init 1 irqpoll"
89
90 Note: i) <second-kernel> has to be a vmlinux image. bzImage will not work,
91 as of now.
92 ii) By default ELF headers are stored in ELF32 format (for i386). This
93 is sufficient to represent the physical memory up to 4GB. To store
94 headers in ELF64 format, specifiy "--elf64-core-headers" on the
95 kexec command line additionally.
96 iii) Specify "irqpoll" as command line parameter. This reduces driver
97 initialization failures in second kernel due to shared interrupts.
98
995) System reboots into the second kernel when a panic occurs. A module can be
100 written to force the panic or "ALT-SysRq-c" can be used initiate a crash
101 dump for testing purposes.
102
1036) Write out the dump file using
104
105 cp /proc/vmcore <dump-file>
106
107 Dump memory can also be accessed as a /dev/oldmem device for a linear/raw
108 view. To create the device, type:
109
110 mknod /dev/oldmem c 1 12
111
112 Use "dd" with suitable options for count, bs and skip to access specific
113 portions of the dump.
114
115 Entire memory: dd if=/dev/oldmem of=oldmem.001
116
117ANALYSIS
118========
119
120Limited analysis can be done using gdb on the dump file copied out of
121/proc/vmcore. Use vmlinux built with -g and run
122
123 gdb vmlinux <dump-file>
124
125Stack trace for the task on processor 0, register display, memory display
126work fine.
127
128Note: gdb cannot analyse core files generated in ELF64 format for i386.
129
130TODO
131====
132
1331) Provide a kernel pages filtering mechanism so that core file size is not
134 insane on systems having huge memory banks.
1352) Modify "crash" tool to make it recognize this dump.
136
137CONTACT
138=======
139
140Vivek Goyal (vgoyal@in.ibm.com)
141Maneesh Soni (maneesh@in.ibm.com)
diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
index 4924d387a657..f44bb5567c5b 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -358,6 +358,10 @@ running once the system is up.
358 cpia_pp= [HW,PPT] 358 cpia_pp= [HW,PPT]
359 Format: { parport<nr> | auto | none } 359 Format: { parport<nr> | auto | none }
360 360
361 crashkernel=nn[KMG]@ss[KMG]
362 [KNL] Reserve a chunk of physical memory to
363 hold a kernel to switch to with kexec on panic.
364
361 cs4232= [HW,OSS] 365 cs4232= [HW,OSS]
362 Format: <io>,<irq>,<dma>,<dma2>,<mpuio>,<mpuirq> 366 Format: <io>,<irq>,<dma>,<dma2>,<mpuio>,<mpuirq>
363 367
@@ -447,6 +451,10 @@ running once the system is up.
447 Format: {"as"|"cfq"|"deadline"|"noop"} 451 Format: {"as"|"cfq"|"deadline"|"noop"}
448 See Documentation/block/as-iosched.txt 452 See Documentation/block/as-iosched.txt
449 and Documentation/block/deadline-iosched.txt for details. 453 and Documentation/block/deadline-iosched.txt for details.
454 elfcorehdr= [IA-32]
455 Specifies physical address of start of kernel core image
456 elf header.
457 See Documentation/kdump.txt for details.
450 458
451 enforcing [SELINUX] Set initial enforcing status. 459 enforcing [SELINUX] Set initial enforcing status.
452 Format: {"0" | "1"} 460 Format: {"0" | "1"}
@@ -548,6 +556,9 @@ running once the system is up.
548 556
549 i810= [HW,DRM] 557 i810= [HW,DRM]
550 558
559 i8k.ignore_dmi [HW] Continue probing hardware even if DMI data
560 indicates that the driver is running on unsupported
561 hardware.
551 i8k.force [HW] Activate i8k driver even if SMM BIOS signature 562 i8k.force [HW] Activate i8k driver even if SMM BIOS signature
552 does not match list of supported models. 563 does not match list of supported models.
553 i8k.power_status 564 i8k.power_status
diff --git a/Documentation/keys.txt b/Documentation/keys.txt
index 36d80aeeaf28..0321ded4b9ae 100644
--- a/Documentation/keys.txt
+++ b/Documentation/keys.txt
@@ -22,6 +22,7 @@ This document has the following sections:
22 - New procfs files 22 - New procfs files
23 - Userspace system call interface 23 - Userspace system call interface
24 - Kernel services 24 - Kernel services
25 - Notes on accessing payload contents
25 - Defining a key type 26 - Defining a key type
26 - Request-key callback service 27 - Request-key callback service
27 - Key access filesystem 28 - Key access filesystem
@@ -45,27 +46,26 @@ Each key has a number of attributes:
45 - State. 46 - State.
46 47
47 48
48 (*) Each key is issued a serial number of type key_serial_t that is unique 49 (*) Each key is issued a serial number of type key_serial_t that is unique for
49 for the lifetime of that key. All serial numbers are positive non-zero 50 the lifetime of that key. All serial numbers are positive non-zero 32-bit
50 32-bit integers. 51 integers.
51 52
52 Userspace programs can use a key's serial numbers as a way to gain access 53 Userspace programs can use a key's serial numbers as a way to gain access
53 to it, subject to permission checking. 54 to it, subject to permission checking.
54 55
55 (*) Each key is of a defined "type". Types must be registered inside the 56 (*) Each key is of a defined "type". Types must be registered inside the
56 kernel by a kernel service (such as a filesystem) before keys of that 57 kernel by a kernel service (such as a filesystem) before keys of that type
57 type can be added or used. Userspace programs cannot define new types 58 can be added or used. Userspace programs cannot define new types directly.
58 directly.
59 59
60 Key types are represented in the kernel by struct key_type. This defines 60 Key types are represented in the kernel by struct key_type. This defines a
61 a number of operations that can be performed on a key of that type. 61 number of operations that can be performed on a key of that type.
62 62
63 Should a type be removed from the system, all the keys of that type will 63 Should a type be removed from the system, all the keys of that type will
64 be invalidated. 64 be invalidated.
65 65
66 (*) Each key has a description. This should be a printable string. The key 66 (*) Each key has a description. This should be a printable string. The key
67 type provides an operation to perform a match between the description on 67 type provides an operation to perform a match between the description on a
68 a key and a criterion string. 68 key and a criterion string.
69 69
70 (*) Each key has an owner user ID, a group ID and a permissions mask. These 70 (*) Each key has an owner user ID, a group ID and a permissions mask. These
71 are used to control what a process may do to a key from userspace, and 71 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:
74 (*) Each key can be set to expire at a specific time by the key type's 74 (*) Each key can be set to expire at a specific time by the key type's
75 instantiation function. Keys can also be immortal. 75 instantiation function. Keys can also be immortal.
76 76
77 (*) Each key can have a payload. This is a quantity of data that represent 77 (*) Each key can have a payload. This is a quantity of data that represent the
78 the actual "key". In the case of a keyring, this is a list of keys to 78 actual "key". In the case of a keyring, this is a list of keys to which
79 which the keyring links; in the case of a user-defined key, it's an 79 the keyring links; in the case of a user-defined key, it's an arbitrary
80 arbitrary blob of data. 80 blob of data.
81 81
82 Having a payload is not required; and the payload can, in fact, just be a 82 Having a payload is not required; and the payload can, in fact, just be a
83 value stored in the struct key itself. 83 value stored in the struct key itself.
@@ -92,8 +92,8 @@ Each key has a number of attributes:
92 92
93 (*) Each key can be in one of a number of basic states: 93 (*) Each key can be in one of a number of basic states:
94 94
95 (*) Uninstantiated. The key exists, but does not have any data 95 (*) Uninstantiated. The key exists, but does not have any data attached.
96 attached. Keys being requested from userspace will be in this state. 96 Keys being requested from userspace will be in this state.
97 97
98 (*) Instantiated. This is the normal state. The key is fully formed, and 98 (*) Instantiated. This is the normal state. The key is fully formed, and
99 has data attached. 99 has data attached.
@@ -140,10 +140,10 @@ The key service provides a number of features besides keys:
140 clone, fork, vfork or execve occurs. A new keyring is created only when 140 clone, fork, vfork or execve occurs. A new keyring is created only when
141 required. 141 required.
142 142
143 The process-specific keyring is replaced with an empty one in the child 143 The process-specific keyring is replaced with an empty one in the child on
144 on clone, fork, vfork unless CLONE_THREAD is supplied, in which case it 144 clone, fork, vfork unless CLONE_THREAD is supplied, in which case it is
145 is shared. execve also discards the process's process keyring and creates 145 shared. execve also discards the process's process keyring and creates a
146 a new one. 146 new one.
147 147
148 The session-specific keyring is persistent across clone, fork, vfork and 148 The session-specific keyring is persistent across clone, fork, vfork and
149 execve, even when the latter executes a set-UID or set-GID binary. A 149 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:
177 If a system call that modifies a key or keyring in some way would put the 177 If a system call that modifies a key or keyring in some way would put the
178 user over quota, the operation is refused and error EDQUOT is returned. 178 user over quota, the operation is refused and error EDQUOT is returned.
179 179
180 (*) There's a system call interface by which userspace programs can create 180 (*) There's a system call interface by which userspace programs can create and
181 and manipulate keys and keyrings. 181 manipulate keys and keyrings.
182 182
183 (*) There's a kernel interface by which services can register types and 183 (*) There's a kernel interface by which services can register types and search
184 search for keys. 184 for keys.
185 185
186 (*) There's a way for the a search done from the kernel to call back to 186 (*) There's a way for the a search done from the kernel to call back to
187 userspace to request a key that can't be found in a process's keyrings. 187 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:
194KEY ACCESS PERMISSIONS 194KEY ACCESS PERMISSIONS
195====================== 195======================
196 196
197Keys have an owner user ID, a group access ID, and a permissions mask. The 197Keys have an owner user ID, a group access ID, and a permissions mask. The mask
198mask has up to eight bits each for user, group and other access. Only five of 198has up to eight bits each for user, group and other access. Only five of each
199each set of eight bits are defined. These permissions granted are: 199set of eight bits are defined. These permissions granted are:
200 200
201 (*) View 201 (*) View
202 202
@@ -210,8 +210,8 @@ each set of eight bits are defined. These permissions granted are:
210 210
211 (*) Write 211 (*) Write
212 212
213 This permits a key's payload to be instantiated or updated, or it allows 213 This permits a key's payload to be instantiated or updated, or it allows a
214 a link to be added to or removed from a keyring. 214 link to be added to or removed from a keyring.
215 215
216 (*) Search 216 (*) Search
217 217
@@ -238,8 +238,8 @@ about the status of the key service:
238 (*) /proc/keys 238 (*) /proc/keys
239 239
240 This lists all the keys on the system, giving information about their 240 This lists all the keys on the system, giving information about their
241 type, description and permissions. The payload of the key is not 241 type, description and permissions. The payload of the key is not available
242 available this way: 242 this way:
243 243
244 SERIAL FLAGS USAGE EXPY PERM UID GID TYPE DESCRIPTION: SUMMARY 244 SERIAL FLAGS USAGE EXPY PERM UID GID TYPE DESCRIPTION: SUMMARY
245 00000001 I----- 39 perm 1f0000 0 0 keyring _uid_ses.0: 1/4 245 00000001 I----- 39 perm 1f0000 0 0 keyring _uid_ses.0: 1/4
@@ -318,21 +318,21 @@ The main syscalls are:
318 If a key of the same type and description as that proposed already exists 318 If a key of the same type and description as that proposed already exists
319 in the keyring, this will try to update it with the given payload, or it 319 in the keyring, this will try to update it with the given payload, or it
320 will return error EEXIST if that function is not supported by the key 320 will return error EEXIST if that function is not supported by the key
321 type. The process must also have permission to write to the key to be 321 type. The process must also have permission to write to the key to be able
322 able to update it. The new key will have all user permissions granted and 322 to update it. The new key will have all user permissions granted and no
323 no group or third party permissions. 323 group or third party permissions.
324 324
325 Otherwise, this will attempt to create a new key of the specified type 325 Otherwise, this will attempt to create a new key of the specified type and
326 and description, and to instantiate it with the supplied payload and 326 description, and to instantiate it with the supplied payload and attach it
327 attach it to the keyring. In this case, an error will be generated if the 327 to the keyring. In this case, an error will be generated if the process
328 process does not have permission to write to the keyring. 328 does not have permission to write to the keyring.
329 329
330 The payload is optional, and the pointer can be NULL if not required by 330 The payload is optional, and the pointer can be NULL if not required by
331 the type. The payload is plen in size, and plen can be zero for an empty 331 the type. The payload is plen in size, and plen can be zero for an empty
332 payload. 332 payload.
333 333
334 A new keyring can be generated by setting type "keyring", the keyring 334 A new keyring can be generated by setting type "keyring", the keyring name
335 name as the description (or NULL) and setting the payload to NULL. 335 as the description (or NULL) and setting the payload to NULL.
336 336
337 User defined keys can be created by specifying type "user". It is 337 User defined keys can be created by specifying type "user". It is
338 recommended that a user defined key's description by prefixed with a type 338 recommended that a user defined key's description by prefixed with a type
@@ -369,9 +369,9 @@ The keyctl syscall functions are:
369 key_serial_t keyctl(KEYCTL_GET_KEYRING_ID, key_serial_t id, 369 key_serial_t keyctl(KEYCTL_GET_KEYRING_ID, key_serial_t id,
370 int create); 370 int create);
371 371
372 The special key specified by "id" is looked up (with the key being 372 The special key specified by "id" is looked up (with the key being created
373 created if necessary) and the ID of the key or keyring thus found is 373 if necessary) and the ID of the key or keyring thus found is returned if
374 returned if it exists. 374 it exists.
375 375
376 If the key does not yet exist, the key will be created if "create" is 376 If the key does not yet exist, the key will be created if "create" is
377 non-zero; and the error ENOKEY will be returned if "create" is zero. 377 non-zero; and the error ENOKEY will be returned if "create" is zero.
@@ -402,8 +402,8 @@ The keyctl syscall functions are:
402 402
403 This will try to update the specified key with the given payload, or it 403 This will try to update the specified key with the given payload, or it
404 will return error EOPNOTSUPP if that function is not supported by the key 404 will return error EOPNOTSUPP if that function is not supported by the key
405 type. The process must also have permission to write to the key to be 405 type. The process must also have permission to write to the key to be able
406 able to update it. 406 to update it.
407 407
408 The payload is of length plen, and may be absent or empty as for 408 The payload is of length plen, and may be absent or empty as for
409 add_key(). 409 add_key().
@@ -422,8 +422,8 @@ The keyctl syscall functions are:
422 422
423 long keyctl(KEYCTL_CHOWN, key_serial_t key, uid_t uid, gid_t gid); 423 long keyctl(KEYCTL_CHOWN, key_serial_t key, uid_t uid, gid_t gid);
424 424
425 This function permits a key's owner and group ID to be changed. Either 425 This function permits a key's owner and group ID to be changed. Either one
426 one of uid or gid can be set to -1 to suppress that change. 426 of uid or gid can be set to -1 to suppress that change.
427 427
428 Only the superuser can change a key's owner to something other than the 428 Only the superuser can change a key's owner to something other than the
429 key's current owner. Similarly, only the superuser can change a key's 429 key's current owner. Similarly, only the superuser can change a key's
@@ -484,12 +484,12 @@ The keyctl syscall functions are:
484 484
485 long keyctl(KEYCTL_LINK, key_serial_t keyring, key_serial_t key); 485 long keyctl(KEYCTL_LINK, key_serial_t keyring, key_serial_t key);
486 486
487 This function creates a link from the keyring to the key. The process 487 This function creates a link from the keyring to the key. The process must
488 must have write permission on the keyring and must have link permission 488 have write permission on the keyring and must have link permission on the
489 on the key. 489 key.
490 490
491 Should the keyring not be a keyring, error ENOTDIR will result; and if 491 Should the keyring not be a keyring, error ENOTDIR will result; and if the
492 the keyring is full, error ENFILE will result. 492 keyring is full, error ENFILE will result.
493 493
494 The link procedure checks the nesting of the keyrings, returning ELOOP if 494 The link procedure checks the nesting of the keyrings, returning ELOOP if
495 it appears to deep or EDEADLK if the link would introduce a cycle. 495 it appears to deep or EDEADLK if the link would introduce a cycle.
@@ -503,8 +503,8 @@ The keyctl syscall functions are:
503 specified key, and removes it if found. Subsequent links to that key are 503 specified key, and removes it if found. Subsequent links to that key are
504 ignored. The process must have write permission on the keyring. 504 ignored. The process must have write permission on the keyring.
505 505
506 If the keyring is not a keyring, error ENOTDIR will result; and if the 506 If the keyring is not a keyring, error ENOTDIR will result; and if the key
507 key is not present, error ENOENT will be the result. 507 is not present, error ENOENT will be the result.
508 508
509 509
510 (*) Search a keyring tree for a key: 510 (*) Search a keyring tree for a key:
@@ -513,9 +513,9 @@ The keyctl syscall functions are:
513 const char *type, const char *description, 513 const char *type, const char *description,
514 key_serial_t dest_keyring); 514 key_serial_t dest_keyring);
515 515
516 This searches the keyring tree headed by the specified keyring until a 516 This searches the keyring tree headed by the specified keyring until a key
517 key is found that matches the type and description criteria. Each keyring 517 is found that matches the type and description criteria. Each keyring is
518 is checked for keys before recursion into its children occurs. 518 checked for keys before recursion into its children occurs.
519 519
520 The process must have search permission on the top level keyring, or else 520 The process must have search permission on the top level keyring, or else
521 error EACCES will result. Only keyrings that the process has search 521 error EACCES will result. Only keyrings that the process has search
@@ -549,8 +549,8 @@ The keyctl syscall functions are:
549 As much of the data as can be fitted into the buffer will be copied to 549 As much of the data as can be fitted into the buffer will be copied to
550 userspace if the buffer pointer is not NULL. 550 userspace if the buffer pointer is not NULL.
551 551
552 On a successful return, the function will always return the amount of 552 On a successful return, the function will always return the amount of data
553 data available rather than the amount copied. 553 available rather than the amount copied.
554 554
555 555
556 (*) Instantiate a partially constructed key. 556 (*) Instantiate a partially constructed key.
@@ -568,8 +568,8 @@ The keyctl syscall functions are:
568 it, and the key must be uninstantiated. 568 it, and the key must be uninstantiated.
569 569
570 If a keyring is specified (non-zero), the key will also be linked into 570 If a keyring is specified (non-zero), the key will also be linked into
571 that keyring, however all the constraints applying in KEYCTL_LINK apply 571 that keyring, however all the constraints applying in KEYCTL_LINK apply in
572 in this case too. 572 this case too.
573 573
574 The payload and plen arguments describe the payload data as for add_key(). 574 The payload and plen arguments describe the payload data as for add_key().
575 575
@@ -587,8 +587,39 @@ The keyctl syscall functions are:
587 it, and the key must be uninstantiated. 587 it, and the key must be uninstantiated.
588 588
589 If a keyring is specified (non-zero), the key will also be linked into 589 If a keyring is specified (non-zero), the key will also be linked into
590 that keyring, however all the constraints applying in KEYCTL_LINK apply 590 that keyring, however all the constraints applying in KEYCTL_LINK apply in
591 in this case too. 591 this case too.
592
593
594 (*) Set the default request-key destination keyring.
595
596 long keyctl(KEYCTL_SET_REQKEY_KEYRING, int reqkey_defl);
597
598 This sets the default keyring to which implicitly requested keys will be
599 attached for this thread. reqkey_defl should be one of these constants:
600
601 CONSTANT VALUE NEW DEFAULT KEYRING
602 ====================================== ====== =======================
603 KEY_REQKEY_DEFL_NO_CHANGE -1 No change
604 KEY_REQKEY_DEFL_DEFAULT 0 Default[1]
605 KEY_REQKEY_DEFL_THREAD_KEYRING 1 Thread keyring
606 KEY_REQKEY_DEFL_PROCESS_KEYRING 2 Process keyring
607 KEY_REQKEY_DEFL_SESSION_KEYRING 3 Session keyring
608 KEY_REQKEY_DEFL_USER_KEYRING 4 User keyring
609 KEY_REQKEY_DEFL_USER_SESSION_KEYRING 5 User session keyring
610 KEY_REQKEY_DEFL_GROUP_KEYRING 6 Group keyring
611
612 The old default will be returned if successful and error EINVAL will be
613 returned if reqkey_defl is not one of the above values.
614
615 The default keyring can be overridden by the keyring indicated to the
616 request_key() system call.
617
618 Note that this setting is inherited across fork/exec.
619
620 [1] The default default is: the thread keyring if there is one, otherwise
621 the process keyring if there is one, otherwise the session keyring if
622 there is one, otherwise the user default session keyring.
592 623
593 624
594=============== 625===============
@@ -601,17 +632,14 @@ be broken down into two areas: keys and key types.
601Dealing with keys is fairly straightforward. Firstly, the kernel service 632Dealing with keys is fairly straightforward. Firstly, the kernel service
602registers its type, then it searches for a key of that type. It should retain 633registers its type, then it searches for a key of that type. It should retain
603the key as long as it has need of it, and then it should release it. For a 634the key as long as it has need of it, and then it should release it. For a
604filesystem or device file, a search would probably be performed during the 635filesystem or device file, a search would probably be performed during the open
605open call, and the key released upon close. How to deal with conflicting keys 636call, and the key released upon close. How to deal with conflicting keys due to
606due to two different users opening the same file is left to the filesystem 637two different users opening the same file is left to the filesystem author to
607author to solve. 638solve.
608 639
609When accessing a key's payload data, key->lock should be at least read locked, 640When accessing a key's payload contents, certain precautions must be taken to
610or else the data may be changed by an update being performed from userspace 641prevent access vs modification races. See the section "Notes on accessing
611whilst the driver or filesystem is trying to access it. If no update method is 642payload contents" for more information.
612supplied, then the key's payload may be accessed without holding a lock as
613there is no way to change it, provided it can be guaranteed that the key's
614type definition won't go away.
615 643
616(*) To search for a key, call: 644(*) To search for a key, call:
617 645
@@ -629,6 +657,9 @@ type definition won't go away.
629 Should the function fail error ENOKEY, EKEYEXPIRED or EKEYREVOKED will be 657 Should the function fail error ENOKEY, EKEYEXPIRED or EKEYREVOKED will be
630 returned. 658 returned.
631 659
660 If successful, the key will have been attached to the default keyring for
661 implicitly obtained request-key keys, as set by KEYCTL_SET_REQKEY_KEYRING.
662
632 663
633(*) When it is no longer required, the key should be released using: 664(*) When it is no longer required, the key should be released using:
634 665
@@ -690,6 +721,54 @@ type definition won't go away.
690 void unregister_key_type(struct key_type *type); 721 void unregister_key_type(struct key_type *type);
691 722
692 723
724===================================
725NOTES ON ACCESSING PAYLOAD CONTENTS
726===================================
727
728The simplest payload is just a number in key->payload.value. In this case,
729there's no need to indulge in RCU or locking when accessing the payload.
730
731More complex payload contents must be allocated and a pointer to them set in
732key->payload.data. One of the following ways must be selected to access the
733data:
734
735 (1) Unmodifyable key type.
736
737 If the key type does not have a modify method, then the key's payload can
738 be accessed without any form of locking, provided that it's known to be
739 instantiated (uninstantiated keys cannot be "found").
740
741 (2) The key's semaphore.
742
743 The semaphore could be used to govern access to the payload and to control
744 the payload pointer. It must be write-locked for modifications and would
745 have to be read-locked for general access. The disadvantage of doing this
746 is that the accessor may be required to sleep.
747
748 (3) RCU.
749
750 RCU must be used when the semaphore isn't already held; if the semaphore
751 is held then the contents can't change under you unexpectedly as the
752 semaphore must still be used to serialise modifications to the key. The
753 key management code takes care of this for the key type.
754
755 However, this means using:
756
757 rcu_read_lock() ... rcu_dereference() ... rcu_read_unlock()
758
759 to read the pointer, and:
760
761 rcu_dereference() ... rcu_assign_pointer() ... call_rcu()
762
763 to set the pointer and dispose of the old contents after a grace period.
764 Note that only the key type should ever modify a key's payload.
765
766 Furthermore, an RCU controlled payload must hold a struct rcu_head for the
767 use of call_rcu() and, if the payload is of variable size, the length of
768 the payload. key->datalen cannot be relied upon to be consistent with the
769 payload just dereferenced if the key's semaphore is not held.
770
771
693=================== 772===================
694DEFINING A KEY TYPE 773DEFINING A KEY TYPE
695=================== 774===================
@@ -717,15 +796,15 @@ The structure has a number of fields, some of which are mandatory:
717 796
718 int key_payload_reserve(struct key *key, size_t datalen); 797 int key_payload_reserve(struct key *key, size_t datalen);
719 798
720 With the revised data length. Error EDQUOT will be returned if this is 799 With the revised data length. Error EDQUOT will be returned if this is not
721 not viable. 800 viable.
722 801
723 802
724 (*) int (*instantiate)(struct key *key, const void *data, size_t datalen); 803 (*) int (*instantiate)(struct key *key, const void *data, size_t datalen);
725 804
726 This method is called to attach a payload to a key during construction. 805 This method is called to attach a payload to a key during construction.
727 The payload attached need not bear any relation to the data passed to 806 The payload attached need not bear any relation to the data passed to this
728 this function. 807 function.
729 808
730 If the amount of data attached to the key differs from the size in 809 If the amount of data attached to the key differs from the size in
731 keytype->def_datalen, then key_payload_reserve() should be called. 810 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:
734 The fact that KEY_FLAG_INSTANTIATED is not set in key->flags prevents 813 The fact that KEY_FLAG_INSTANTIATED is not set in key->flags prevents
735 anything else from gaining access to the key. 814 anything else from gaining access to the key.
736 815
737 This method may sleep if it wishes. 816 It is safe to sleep in this method.
738 817
739 818
740 (*) int (*duplicate)(struct key *key, const struct key *source); 819 (*) int (*duplicate)(struct key *key, const struct key *source);
741 820
742 If this type of key can be duplicated, then this method should be 821 If this type of key can be duplicated, then this method should be
743 provided. It is called to copy the payload attached to the source into 822 provided. It is called to copy the payload attached to the source into the
744 the new key. The data length on the new key will have been updated and 823 new key. The data length on the new key will have been updated and the
745 the quota adjusted already. 824 quota adjusted already.
746 825
747 This method will be called with the source key's semaphore read-locked to 826 This method will be called with the source key's semaphore read-locked to
748 prevent its payload from being changed. It is safe to sleep here. 827 prevent its payload from being changed, thus RCU constraints need not be
828 applied to the source key.
829
830 This method does not have to lock the destination key in order to attach a
831 payload. The fact that KEY_FLAG_INSTANTIATED is not set in key->flags
832 prevents anything else from gaining access to the key.
833
834 It is safe to sleep in this method.
749 835
750 836
751 (*) int (*update)(struct key *key, const void *data, size_t datalen); 837 (*) int (*update)(struct key *key, const void *data, size_t datalen);
752 838
753 If this type of key can be updated, then this method should be 839 If this type of key can be updated, then this method should be provided.
754 provided. It is called to update a key's payload from the blob of data 840 It is called to update a key's payload from the blob of data provided.
755 provided.
756 841
757 key_payload_reserve() should be called if the data length might change 842 key_payload_reserve() should be called if the data length might change
758 before any changes are actually made. Note that if this succeeds, the 843 before any changes are actually made. Note that if this succeeds, the type
759 type is committed to changing the key because it's already been altered, 844 is committed to changing the key because it's already been altered, so all
760 so all memory allocation must be done first. 845 memory allocation must be done first.
846
847 The key will have its semaphore write-locked before this method is called,
848 but this only deters other writers; any changes to the key's payload must
849 be made under RCU conditions, and call_rcu() must be used to dispose of
850 the old payload.
761 851
762 key_payload_reserve() should be called with the key->lock write locked, 852 key_payload_reserve() should be called before the changes are made, but
763 and the changes to the key's attached payload should be made before the 853 after all allocations and other potentially failing function calls are
764 key is locked. 854 made.
765 855
766 The key will have its semaphore write-locked before this method is 856 It is safe to sleep in this method.
767 called. Any changes to the key should be made with the key's rwlock
768 write-locked also. It is safe to sleep here.
769 857
770 858
771 (*) int (*match)(const struct key *key, const void *desc); 859 (*) 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:
782 870
783 (*) void (*destroy)(struct key *key); 871 (*) void (*destroy)(struct key *key);
784 872
785 This method is optional. It is called to discard the payload data on a 873 This method is optional. It is called to discard the payload data on a key
786 key when it is being destroyed. 874 when it is being destroyed.
787 875
788 This method does not need to lock the key; it can consider the key as 876 This method does not need to lock the key to access the payload; it can
789 being inaccessible. Note that the key's type may have changed before this 877 consider the key as being inaccessible at this time. Note that the key's
790 function is called. 878 type may have been changed before this function is called.
791 879
792 It is not safe to sleep in this method; the caller may hold spinlocks. 880 It is not safe to sleep in this method; the caller may hold spinlocks.
793 881
@@ -797,26 +885,31 @@ The structure has a number of fields, some of which are mandatory:
797 This method is optional. It is called during /proc/keys reading to 885 This method is optional. It is called during /proc/keys reading to
798 summarise a key's description and payload in text form. 886 summarise a key's description and payload in text form.
799 887
800 This method will be called with the key's rwlock read-locked. This will 888 This method will be called with the RCU read lock held. rcu_dereference()
801 prevent the key's payload and state changing; also the description should 889 should be used to read the payload pointer if the payload is to be
802 not change. This also means it is not safe to sleep in this method. 890 accessed. key->datalen cannot be trusted to stay consistent with the
891 contents of the payload.
892
893 The description will not change, though the key's state may.
894
895 It is not safe to sleep in this method; the RCU read lock is held by the
896 caller.
803 897
804 898
805 (*) long (*read)(const struct key *key, char __user *buffer, size_t buflen); 899 (*) long (*read)(const struct key *key, char __user *buffer, size_t buflen);
806 900
807 This method is optional. It is called by KEYCTL_READ to translate the 901 This method is optional. It is called by KEYCTL_READ to translate the
808 key's payload into something a blob of data for userspace to deal 902 key's payload into something a blob of data for userspace to deal with.
809 with. Ideally, the blob should be in the same format as that passed in to 903 Ideally, the blob should be in the same format as that passed in to the
810 the instantiate and update methods. 904 instantiate and update methods.
811 905
812 If successful, the blob size that could be produced should be returned 906 If successful, the blob size that could be produced should be returned
813 rather than the size copied. 907 rather than the size copied.
814 908
815 This method will be called with the key's semaphore read-locked. This 909 This method will be called with the key's semaphore read-locked. This will
816 will prevent the key's payload changing. It is not necessary to also 910 prevent the key's payload changing. It is not necessary to use RCU locking
817 read-lock key->lock when accessing the key's payload. It is safe to sleep 911 when accessing the key's payload. It is safe to sleep in this method, such
818 in this method, such as might happen when the userspace buffer is 912 as might happen when the userspace buffer is accessed.
819 accessed.
820 913
821 914
822============================ 915============================
@@ -853,8 +946,8 @@ If it returns with the key remaining in the unconstructed state, the key will
853be marked as being negative, it will be added to the session keyring, and an 946be marked as being negative, it will be added to the session keyring, and an
854error will be returned to the key requestor. 947error will be returned to the key requestor.
855 948
856Supplementary information may be provided from whoever or whatever invoked 949Supplementary information may be provided from whoever or whatever invoked this
857this service. This will be passed as the <callout_info> parameter. If no such 950service. This will be passed as the <callout_info> parameter. If no such
858information was made available, then "-" will be passed as this parameter 951information was made available, then "-" will be passed as this parameter
859instead. 952instead.
860 953
diff --git a/Documentation/networking/00-INDEX b/Documentation/networking/00-INDEX
index 834993d26730..5b01d5cc4e95 100644
--- a/Documentation/networking/00-INDEX
+++ b/Documentation/networking/00-INDEX
@@ -114,9 +114,7 @@ tuntap.txt
114vortex.txt 114vortex.txt
115 - info on using 3Com Vortex (3c590, 3c592, 3c595, 3c597) Ethernet cards. 115 - info on using 3Com Vortex (3c590, 3c592, 3c595, 3c597) Ethernet cards.
116wan-router.txt 116wan-router.txt
117 - Wan router documentation 117 - WAN router documentation
118wanpipe.txt
119 - WANPIPE(tm) Multiprotocol WAN Driver for Linux WAN Router
120wavelan.txt 118wavelan.txt
121 - AT&T GIS (nee NCR) WaveLAN card: An Ethernet-like radio transceiver 119 - AT&T GIS (nee NCR) WaveLAN card: An Ethernet-like radio transceiver
122x25.txt 120x25.txt
diff --git a/Documentation/networking/dmfe.txt b/Documentation/networking/dmfe.txt
index c0e8398674ef..046363552d09 100644
--- a/Documentation/networking/dmfe.txt
+++ b/Documentation/networking/dmfe.txt
@@ -1,59 +1,65 @@
1 dmfe.c: Version 1.28 01/18/2000 1Davicom DM9102(A)/DM9132/DM9801 fast ethernet driver for Linux.
2 2
3 A Davicom DM9102(A)/DM9132/DM9801 fast ethernet driver for Linux. 3This program is free software; you can redistribute it and/or
4 Copyright (C) 1997 Sten Wang 4modify it under the terms of the GNU General Public License
5as published by the Free Software Foundation; either version 2
6of the License, or (at your option) any later version.
5 7
6 This program is free software; you can redistribute it and/or 8This program is distributed in the hope that it will be useful,
7 modify it under the terms of the GNU General Public License 9but WITHOUT ANY WARRANTY; without even the implied warranty of
8 as published by the Free Software Foundation; either version 2 10MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
9 of the License, or (at your option) any later version. 11GNU General Public License for more details.
10 12
11 This program is distributed in the hope that it will be useful,
12 but WITHOUT ANY WARRANTY; without even the implied warranty of
13 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
14 GNU General Public License for more details.
15 13
14This driver provides kernel support for Davicom DM9102(A)/DM9132/DM9801 ethernet cards ( CNET
1510/100 ethernet cards uses Davicom chipset too, so this driver supports CNET cards too ).If you
16didn't compile this driver as a module, it will automatically load itself on boot and print a
17line similar to :
16 18
17 A. Compiler command: 19 dmfe: Davicom DM9xxx net driver, version 1.36.4 (2002-01-17)
18 20
19 A-1: For normal single or multiple processor kernel 21If you compiled this driver as a module, you have to load it on boot.You can load it with command :
20 "gcc -DMODULE -D__KERNEL__ -I/usr/src/linux/net/inet -Wall
21 -Wstrict-prototypes -O6 -c dmfe.c"
22 22
23 A-2: For single or multiple processor with kernel module version function 23 insmod dmfe
24 "gcc -DMODULE -DMODVERSIONS -D__KERNEL__ -I/usr/src/linux/net/inet
25 -Wall -Wstrict-prototypes -O6 -c dmfe.c"
26 24
25This way it will autodetect the device mode.This is the suggested way to load the module.Or you can pass
26a mode= setting to module while loading, like :
27 27
28 B. The following steps teach you how to activate a DM9102 board: 28 insmod dmfe mode=0 # Force 10M Half Duplex
29 insmod dmfe mode=1 # Force 100M Half Duplex
30 insmod dmfe mode=4 # Force 10M Full Duplex
31 insmod dmfe mode=5 # Force 100M Full Duplex
29 32
30 1. Used the upper compiler command to compile dmfe.c 33Next you should configure your network interface with a command similar to :
31 34
32 2. Insert dmfe module into kernel 35 ifconfig eth0 172.22.3.18
33 "insmod dmfe" ;;Auto Detection Mode (Suggest) 36 ^^^^^^^^^^^
34 "insmod dmfe mode=0" ;;Force 10M Half Duplex 37 Your IP Adress
35 "insmod dmfe mode=1" ;;Force 100M Half Duplex
36 "insmod dmfe mode=4" ;;Force 10M Full Duplex
37 "insmod dmfe mode=5" ;;Force 100M Full Duplex
38 38
39 3. Config a dm9102 network interface 39Then you may have to modify the default routing table with command :
40 "ifconfig eth0 172.22.3.18"
41 ^^^^^^^^^^^ Your IP address
42 40
43 4. Activate the IP routing table. For some distributions, it is not 41 route add default eth0
44 necessary. You can type "route" to check.
45 42
46 "route add default eth0"
47 43
44Now your ethernet card should be up and running.
48 45
49 5. Well done. Your DM9102 adapter is now activated.
50 46
47TODO:
51 48
52 C. Object files description: 49Implement pci_driver::suspend() and pci_driver::resume() power management methods.
53 1. dmfe_rh61.o: For Redhat 6.1 50Check on 64 bit boxes.
51Check and fix on big endian boxes.
52Test and make sure PCI latency is now correct for all cases.
54 53
55 If you can make sure your kernel version, you can rename
56 to dmfe.o and directly use it without re-compiling.
57 54
55Authors:
58 56
59 Author: Sten Wang, 886-3-5798797-8517, E-mail: sten_wang@davicom.com.tw 57Sten Wang <sten_wang@davicom.com.tw > : Original Author
58Tobias Ringstrom <tori@unhappy.mine.nu> : Current Maintainer
59
60Contributors:
61
62Marcelo Tosatti <marcelo@conectiva.com.br>
63Alan Cox <alan@redhat.com>
64Jeff Garzik <jgarzik@pobox.com>
65Vojtech Pavlik <vojtech@suse.cz>
diff --git a/Documentation/networking/generic-hdlc.txt b/Documentation/networking/generic-hdlc.txt
index 7d1dc6b884f3..31bc8b759b75 100644
--- a/Documentation/networking/generic-hdlc.txt
+++ b/Documentation/networking/generic-hdlc.txt
@@ -1,21 +1,21 @@
1Generic HDLC layer 1Generic HDLC layer
2Krzysztof Halasa <khc@pm.waw.pl> 2Krzysztof Halasa <khc@pm.waw.pl>
3January, 2003
4 3
5 4
6Generic HDLC layer currently supports: 5Generic HDLC layer currently supports:
7- Frame Relay (ANSI, CCITT and no LMI), with ARP support (no InARP). 61. Frame Relay (ANSI, CCITT, Cisco and no LMI).
8 Normal (routed) and Ethernet-bridged (Ethernet device emulation) 7 - Normal (routed) and Ethernet-bridged (Ethernet device emulation)
9 interfaces can share a single PVC. 8 interfaces can share a single PVC.
10- raw HDLC - either IP (IPv4) interface or Ethernet device emulation. 9 - ARP support (no InARP support in the kernel - there is an
11- Cisco HDLC, 10 experimental InARP user-space daemon available on:
12- PPP (uses syncppp.c), 11 http://www.kernel.org/pub/linux/utils/net/hdlc/).
13- X.25 (uses X.25 routines). 122. raw HDLC - either IP (IPv4) interface or Ethernet device emulation.
14 133. Cisco HDLC.
15There are hardware drivers for the following cards: 144. PPP (uses syncppp.c).
16- C101 by Moxa Technologies Co., Ltd. 155. X.25 (uses X.25 routines).
17- RISCom/N2 by SDL Communications Inc. 16
18- and others, some not in the official kernel. 17Generic HDLC is a protocol driver only - it needs a low-level driver
18for your particular hardware.
19 19
20Ethernet device emulation (using HDLC or Frame-Relay PVC) is compatible 20Ethernet device emulation (using HDLC or Frame-Relay PVC) is compatible
21with IEEE 802.1Q (VLANs) and 802.1D (Ethernet bridging). 21with IEEE 802.1Q (VLANs) and 802.1D (Ethernet bridging).
@@ -24,7 +24,7 @@ with IEEE 802.1Q (VLANs) and 802.1D (Ethernet bridging).
24Make sure the hdlc.o and the hardware driver are loaded. It should 24Make sure the hdlc.o and the hardware driver are loaded. It should
25create a number of "hdlc" (hdlc0 etc) network devices, one for each 25create a number of "hdlc" (hdlc0 etc) network devices, one for each
26WAN port. You'll need the "sethdlc" utility, get it from: 26WAN port. You'll need the "sethdlc" utility, get it from:
27 http://hq.pm.waw.pl/hdlc/ 27 http://www.kernel.org/pub/linux/utils/net/hdlc/
28 28
29Compile sethdlc.c utility: 29Compile sethdlc.c utility:
30 gcc -O2 -Wall -o sethdlc sethdlc.c 30 gcc -O2 -Wall -o sethdlc sethdlc.c
@@ -52,12 +52,12 @@ Setting interface:
52* v35 | rs232 | x21 | t1 | e1 - sets physical interface for a given port 52* v35 | rs232 | x21 | t1 | e1 - sets physical interface for a given port
53 if the card has software-selectable interfaces 53 if the card has software-selectable interfaces
54 loopback - activate hardware loopback (for testing only) 54 loopback - activate hardware loopback (for testing only)
55* clock ext - external clock (uses DTE RX and TX clock) 55* clock ext - both RX clock and TX clock external
56* clock int - internal clock (provides clock signal on DCE clock output) 56* clock int - both RX clock and TX clock internal
57* clock txint - TX internal, RX external (provides TX clock on DCE output) 57* clock txint - RX clock external, TX clock internal
58* clock txfromrx - TX clock derived from RX clock (TX clock on DCE output) 58* clock txfromrx - RX clock external, TX clock derived from RX clock
59* rate - sets clock rate in bps (not required for external clock or 59* rate - sets clock rate in bps (for "int" or "txint" clock only)
60 for txfromrx) 60
61 61
62Setting protocol: 62Setting protocol:
63 63
@@ -79,7 +79,7 @@ Setting protocol:
79* x25 - sets X.25 mode 79* x25 - sets X.25 mode
80 80
81* fr - Frame Relay mode 81* fr - Frame Relay mode
82 lmi ansi / ccitt / none - LMI (link management) type 82 lmi ansi / ccitt / cisco / none - LMI (link management) type
83 dce - Frame Relay DCE (network) side LMI instead of default DTE (user). 83 dce - Frame Relay DCE (network) side LMI instead of default DTE (user).
84 It has nothing to do with clocks! 84 It has nothing to do with clocks!
85 t391 - link integrity verification polling timer (in seconds) - user 85 t391 - link integrity verification polling timer (in seconds) - user
@@ -119,13 +119,14 @@ or
119 119
120 120
121 121
122If you have a problem with N2 or C101 card, you can issue the "private" 122If you have a problem with N2, C101 or PLX200SYN card, you can issue the
123command to see port's packet descriptor rings (in kernel logs): 123"private" command to see port's packet descriptor rings (in kernel logs):
124 124
125 sethdlc hdlc0 private 125 sethdlc hdlc0 private
126 126
127The hardware driver has to be build with CONFIG_HDLC_DEBUG_RINGS. 127The hardware driver has to be build with #define DEBUG_RINGS.
128Attaching this info to bug reports would be helpful. Anyway, let me know 128Attaching this info to bug reports would be helpful. Anyway, let me know
129if you have problems using this. 129if you have problems using this.
130 130
131For patches and other info look at http://hq.pm.waw.pl/hdlc/ 131For patches and other info look at:
132<http://www.kernel.org/pub/linux/utils/net/hdlc/>.
diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt
index a2c893a7475d..ab65714d95fc 100644
--- a/Documentation/networking/ip-sysctl.txt
+++ b/Documentation/networking/ip-sysctl.txt
@@ -304,57 +304,6 @@ tcp_low_latency - BOOLEAN
304 changed would be a Beowulf compute cluster. 304 changed would be a Beowulf compute cluster.
305 Default: 0 305 Default: 0
306 306
307tcp_westwood - BOOLEAN
308 Enable TCP Westwood+ congestion control algorithm.
309 TCP Westwood+ is a sender-side only modification of the TCP Reno
310 protocol stack that optimizes the performance of TCP congestion
311 control. It is based on end-to-end bandwidth estimation to set
312 congestion window and slow start threshold after a congestion
313 episode. Using this estimation, TCP Westwood+ adaptively sets a
314 slow start threshold and a congestion window which takes into
315 account the bandwidth used at the time congestion is experienced.
316 TCP Westwood+ significantly increases fairness wrt TCP Reno in
317 wired networks and throughput over wireless links.
318 Default: 0
319
320tcp_vegas_cong_avoid - BOOLEAN
321 Enable TCP Vegas congestion avoidance algorithm.
322 TCP Vegas is a sender-side only change to TCP that anticipates
323 the onset of congestion by estimating the bandwidth. TCP Vegas
324 adjusts the sending rate by modifying the congestion
325 window. TCP Vegas should provide less packet loss, but it is
326 not as aggressive as TCP Reno.
327 Default:0
328
329tcp_bic - BOOLEAN
330 Enable BIC TCP congestion control algorithm.
331 BIC-TCP is a sender-side only change that ensures a linear RTT
332 fairness under large windows while offering both scalability and
333 bounded TCP-friendliness. The protocol combines two schemes
334 called additive increase and binary search increase. When the
335 congestion window is large, additive increase with a large
336 increment ensures linear RTT fairness as well as good
337 scalability. Under small congestion windows, binary search
338 increase provides TCP friendliness.
339 Default: 0
340
341tcp_bic_low_window - INTEGER
342 Sets the threshold window (in packets) where BIC TCP starts to
343 adjust the congestion window. Below this threshold BIC TCP behaves
344 the same as the default TCP Reno.
345 Default: 14
346
347tcp_bic_fast_convergence - BOOLEAN
348 Forces BIC TCP to more quickly respond to changes in congestion
349 window. Allows two flows sharing the same connection to converge
350 more rapidly.
351 Default: 1
352
353tcp_default_win_scale - INTEGER
354 Sets the minimum window scale TCP will negotiate for on all
355 conections.
356 Default: 7
357
358tcp_tso_win_divisor - INTEGER 307tcp_tso_win_divisor - INTEGER
359 This allows control over what percentage of the congestion window 308 This allows control over what percentage of the congestion window
360 can be consumed by a single TSO frame. 309 can be consumed by a single TSO frame.
@@ -368,6 +317,11 @@ tcp_frto - BOOLEAN
368 where packet loss is typically due to random radio interference 317 where packet loss is typically due to random radio interference
369 rather than intermediate router congestion. 318 rather than intermediate router congestion.
370 319
320tcp_congestion_control - STRING
321 Set the congestion control algorithm to be used for new
322 connections. The algorithm "reno" is always available, but
323 additional choices may be available based on kernel configuration.
324
371somaxconn - INTEGER 325somaxconn - INTEGER
372 Limit of socket listen() backlog, known in userspace as SOMAXCONN. 326 Limit of socket listen() backlog, known in userspace as SOMAXCONN.
373 Defaults to 128. See also tcp_max_syn_backlog for additional tuning 327 Defaults to 128. See also tcp_max_syn_backlog for additional tuning
diff --git a/Documentation/networking/multicast.txt b/Documentation/networking/multicast.txt
index 5049a64313d1..b06c8c69266f 100644
--- a/Documentation/networking/multicast.txt
+++ b/Documentation/networking/multicast.txt
@@ -47,7 +47,6 @@ ni52 <------------------ Buggy ------------------>
47ni65 YES YES YES Software(#) 47ni65 YES YES YES Software(#)
48seeq NO NO NO N/A 48seeq NO NO NO N/A
49sgiseek <------------------ Buggy ------------------> 49sgiseek <------------------ Buggy ------------------>
50sk_g16 NO NO YES N/A
51smc-ultra YES YES YES Hardware 50smc-ultra YES YES YES Hardware
52sunlance YES YES YES Hardware 51sunlance YES YES YES Hardware
53tulip YES YES YES Hardware 52tulip YES YES YES Hardware
diff --git a/Documentation/networking/net-modules.txt b/Documentation/networking/net-modules.txt
index 3830a83513d2..0b27863f155c 100644
--- a/Documentation/networking/net-modules.txt
+++ b/Documentation/networking/net-modules.txt
@@ -284,9 +284,6 @@ ppp.c:
284seeq8005.c: *Not modularized* 284seeq8005.c: *Not modularized*
285 (Probes ports: 0x300, 0x320, 0x340, 0x360) 285 (Probes ports: 0x300, 0x320, 0x340, 0x360)
286 286
287sk_g16.c: *Not modularized*
288 (Probes ports: 0x100, 0x180, 0x208, 0x220m 0x288, 0x320, 0x328, 0x390)
289
290skeleton.c: *Skeleton* 287skeleton.c: *Skeleton*
291 288
292slhc.c: 289slhc.c:
diff --git a/Documentation/networking/tcp.txt b/Documentation/networking/tcp.txt
index 71749007091e..0fa300425575 100644
--- a/Documentation/networking/tcp.txt
+++ b/Documentation/networking/tcp.txt
@@ -1,5 +1,72 @@
1How the new TCP output machine [nyi] works. 1TCP protocol
2============
3
4Last updated: 21 June 2005
5
6Contents
7========
8
9- Congestion control
10- How the new TCP output machine [nyi] works
11
12Congestion control
13==================
14
15The following variables are used in the tcp_sock for congestion control:
16snd_cwnd The size of the congestion window
17snd_ssthresh Slow start threshold. We are in slow start if
18 snd_cwnd is less than this.
19snd_cwnd_cnt A counter used to slow down the rate of increase
20 once we exceed slow start threshold.
21snd_cwnd_clamp This is the maximum size that snd_cwnd can grow to.
22snd_cwnd_stamp Timestamp for when congestion window last validated.
23snd_cwnd_used Used as a highwater mark for how much of the
24 congestion window is in use. It is used to adjust
25 snd_cwnd down when the link is limited by the
26 application rather than the network.
27
28As of 2.6.13, Linux supports pluggable congestion control algorithms.
29A congestion control mechanism can be registered through functions in
30tcp_cong.c. The functions used by the congestion control mechanism are
31registered via passing a tcp_congestion_ops struct to
32tcp_register_congestion_control. As a minimum name, ssthresh,
33cong_avoid, min_cwnd must be valid.
2 34
35Private data for a congestion control mechanism is stored in tp->ca_priv.
36tcp_ca(tp) returns a pointer to this space. This is preallocated space - it
37is important to check the size of your private data will fit this space, or
38alternatively space could be allocated elsewhere and a pointer to it could
39be stored here.
40
41There are three kinds of congestion control algorithms currently: The
42simplest ones are derived from TCP reno (highspeed, scalable) and just
43provide an alternative the congestion window calculation. More complex
44ones like BIC try to look at other events to provide better
45heuristics. There are also round trip time based algorithms like
46Vegas and Westwood+.
47
48Good TCP congestion control is a complex problem because the algorithm
49needs to maintain fairness and performance. Please review current
50research and RFC's before developing new modules.
51
52The method that is used to determine which congestion control mechanism is
53determined by the setting of the sysctl net.ipv4.tcp_congestion_control.
54The default congestion control will be the last one registered (LIFO);
55so if you built everything as modules. the default will be reno. If you
56build with the default's from Kconfig, then BIC will be builtin (not a module)
57and it will end up the default.
58
59If you really want a particular default value then you will need
60to set it with the sysctl. If you use a sysctl, the module will be autoloaded
61if needed and you will get the expected protocol. If you ask for an
62unknown congestion method, then the sysctl attempt will fail.
63
64If you remove a tcp congestion control module, then you will get the next
65available one. Since reno can not be built as a module, and can not be
66deleted, it will always be available.
67
68How the new TCP output machine [nyi] works.
69===========================================
3 70
4Data is kept on a single queue. The skb->users flag tells us if the frame is 71Data is kept on a single queue. The skb->users flag tells us if the frame is
5one that has been queued already. To add a frame we throw it on the end. Ack 72one that has been queued already. To add a frame we throw it on the end. Ack
diff --git a/Documentation/networking/vortex.txt b/Documentation/networking/vortex.txt
index fa12a9e4abdd..80e1cb19609f 100644
--- a/Documentation/networking/vortex.txt
+++ b/Documentation/networking/vortex.txt
@@ -12,7 +12,7 @@ Don is no longer the prime maintainer of this version of the driver.
12Please report problems to one or more of: 12Please report problems to one or more of:
13 13
14 Andrew Morton <andrewm@uow.edu.au> 14 Andrew Morton <andrewm@uow.edu.au>
15 Netdev mailing list <netdev@oss.sgi.com> 15 Netdev mailing list <netdev@vger.kernel.org>
16 Linux kernel mailing list <linux-kernel@vger.kernel.org> 16 Linux kernel mailing list <linux-kernel@vger.kernel.org>
17 17
18Please note the 'Reporting and Diagnosing Problems' section at the end 18Please note the 'Reporting and Diagnosing Problems' section at the end
diff --git a/Documentation/networking/wanpipe.txt b/Documentation/networking/wanpipe.txt
deleted file mode 100644
index aea20cd2a56e..000000000000
--- a/Documentation/networking/wanpipe.txt
+++ /dev/null
@@ -1,622 +0,0 @@
1------------------------------------------------------------------------------
2Linux WAN Router Utilities Package
3------------------------------------------------------------------------------
4Version 2.2.1
5Mar 28, 2001
6Author: Nenad Corbic <ncorbic@sangoma.com>
7Copyright (c) 1995-2001 Sangoma Technologies Inc.
8------------------------------------------------------------------------------
9
10INTRODUCTION
11
12Wide Area Networks (WANs) are used to interconnect Local Area Networks (LANs)
13and/or stand-alone hosts over vast distances with data transfer rates
14significantly higher than those achievable with commonly used dial-up
15connections.
16
17Usually an external device called `WAN router' sitting on your local network
18or connected to your machine's serial port provides physical connection to
19WAN. Although router's job may be as simple as taking your local network
20traffic, converting it to WAN format and piping it through the WAN link, these
21devices are notoriously expensive, with prices as much as 2 - 5 times higher
22then the price of a typical PC box.
23
24Alternatively, considering robustness and multitasking capabilities of Linux,
25an internal router can be built (most routers use some sort of stripped down
26Unix-like operating system anyway). With a number of relatively inexpensive WAN
27interface cards available on the market, a perfectly usable router can be
28built for less than half a price of an external router. Yet a Linux box
29acting as a router can still be used for other purposes, such as fire-walling,
30running FTP, WWW or DNS server, etc.
31
32This kernel module introduces the notion of a WAN Link Driver (WLD) to Linux
33operating system and provides generic hardware-independent services for such
34drivers. Why can existing Linux network device interface not be used for
35this purpose? Well, it can. However, there are a few key differences between
36a typical network interface (e.g. Ethernet) and a WAN link.
37
38Many WAN protocols, such as X.25 and frame relay, allow for multiple logical
39connections (known as `virtual circuits' in X.25 terminology) over a single
40physical link. Each such virtual circuit may (and almost always does) lead
41to a different geographical location and, therefore, different network. As a
42result, it is the virtual circuit, not the physical link, that represents a
43route and, therefore, a network interface in Linux terms.
44
45To further complicate things, virtual circuits are usually volatile in nature
46(excluding so called `permanent' virtual circuits or PVCs). With almost no
47time required to set up and tear down a virtual circuit, it is highly desirable
48to implement on-demand connections in order to minimize network charges. So
49unlike a typical network driver, the WAN driver must be able to handle multiple
50network interfaces and cope as multiple virtual circuits come into existence
51and go away dynamically.
52
53Last, but not least, WAN configuration is much more complex than that of say
54Ethernet and may well amount to several dozens of parameters. Some of them
55are "link-wide" while others are virtual circuit-specific. The same holds
56true for WAN statistics which is by far more extensive and extremely useful
57when troubleshooting WAN connections. Extending the ifconfig utility to suit
58these needs may be possible, but does not seem quite reasonable. Therefore, a
59WAN configuration utility and corresponding application programmer's interface
60is needed for this purpose.
61
62Most of these problems are taken care of by this module. Its goal is to
63provide a user with more-or-less standard look and feel for all WAN devices and
64assist a WAN device driver writer by providing common services, such as:
65
66 o User-level interface via /proc file system
67 o Centralized configuration
68 o Device management (setup, shutdown, etc.)
69 o Network interface management (dynamic creation/destruction)
70 o Protocol encapsulation/decapsulation
71
72To ba able to use the Linux WAN Router you will also need a WAN Tools package
73available from
74
75 ftp.sangoma.com/pub/linux/current_wanpipe/wanpipe-X.Y.Z.tgz
76
77where vX.Y.Z represent the wanpipe version number.
78
79For technical questions and/or comments please e-mail to ncorbic@sangoma.com.
80For general inquiries please contact Sangoma Technologies Inc. by
81
82 Hotline: 1-800-388-2475 (USA and Canada, toll free)
83 Phone: (905) 474-1990 ext: 106
84 Fax: (905) 474-9223
85 E-mail: dm@sangoma.com (David Mandelstam)
86 WWW: http://www.sangoma.com
87
88
89INSTALLATION
90
91Please read the WanpipeForLinux.pdf manual on how to
92install the WANPIPE tools and drivers properly.
93
94
95After installing wanpipe package: /usr/local/wanrouter/doc.
96On the ftp.sangoma.com : /linux/current_wanpipe/doc
97
98
99COPYRIGHT AND LICENSING INFORMATION
100
101This program is free software; you can redistribute it and/or modify it under
102the terms of the GNU General Public License as published by the Free Software
103Foundation; either version 2, or (at your option) any later version.
104
105This program is distributed in the hope that it will be useful, but WITHOUT
106ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS
107FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.
108
109You should have received a copy of the GNU General Public License along with
110this program; if not, write to the Free Software Foundation, Inc., 675 Mass
111Ave, Cambridge, MA 02139, USA.
112
113
114
115ACKNOWLEDGEMENTS
116
117This product is based on the WANPIPE(tm) Multiprotocol WAN Router developed
118by Sangoma Technologies Inc. for Linux 2.0.x and 2.2.x. Success of the WANPIPE
119together with the next major release of Linux kernel in summer 1996 commanded
120adequate changes to the WANPIPE code to take full advantage of new Linux
121features.
122
123Instead of continuing developing proprietary interface tied to Sangoma WAN
124cards, we decided to separate all hardware-independent code into a separate
125module and defined two levels of interfaces - one for user-level applications
126and another for kernel-level WAN drivers. WANPIPE is now implemented as a
127WAN driver compliant with the WAN Link Driver interface. Also a general
128purpose WAN configuration utility and a set of shell scripts was developed to
129support WAN router at the user level.
130
131Many useful ideas concerning hardware-independent interface implementation
132were given by Mike McLagan <mike.mclagan@linux.org> and his implementation
133of the Frame Relay router and drivers for Sangoma cards (dlci/sdla).
134
135With the new implementation of the APIs being incorporated into the WANPIPE,
136a special thank goes to Alan Cox in providing insight into BSD sockets.
137
138Special thanks to all the WANPIPE users who performed field-testing, reported
139bugs and made valuable comments and suggestions that help us to improve this
140product.
141
142
143
144NEW IN THIS RELEASE
145
146 o Updated the WANCFG utility
147 Calls the pppconfig to configure the PPPD
148 for async connections.
149
150 o Added the PPPCONFIG utility
151 Used to configure the PPPD dameon for the
152 WANPIPE Async PPP and standard serial port.
153 The wancfg calls the pppconfig to configure
154 the pppd.
155
156 o Fixed the PCI autodetect feature.
157 The SLOT 0 was used as an autodetect option
158 however, some high end PC's slot numbers start
159 from 0.
160
161 o This release has been tested with the new backupd
162 daemon release.
163
164
165PRODUCT COMPONENTS AND RELATED FILES
166
167/etc: (or user defined)
168 wanpipe1.conf default router configuration file
169
170/lib/modules/X.Y.Z/misc:
171 wanrouter.o router kernel loadable module
172 af_wanpipe.o wanpipe api socket module
173
174/lib/modules/X.Y.Z/net:
175 sdladrv.o Sangoma SDLA support module
176 wanpipe.o Sangoma WANPIPE(tm) driver module
177
178/proc/net/wanrouter
179 Config reads current router configuration
180 Status reads current router status
181 {name} reads WAN driver statistics
182
183/usr/sbin:
184 wanrouter wanrouter start-up script
185 wanconfig wanrouter configuration utility
186 sdladump WANPIPE adapter memory dump utility
187 fpipemon Monitor for Frame Relay
188 cpipemon Monitor for Cisco HDLC
189 ppipemon Monitor for PPP
190 xpipemon Monitor for X25
191 wpkbdmon WANPIPE keyboard led monitor/debugger
192
193/usr/local/wanrouter:
194 README this file
195 COPYING GNU General Public License
196 Setup installation script
197 Filelist distribution definition file
198 wanrouter.rc meta-configuration file
199 (used by the Setup and wanrouter script)
200
201/usr/local/wanrouter/doc:
202 wanpipeForLinux.pdf WAN Router User's Manual
203
204/usr/local/wanrouter/patches:
205 wanrouter-v2213.gz patch for Linux kernels 2.2.11 up to 2.2.13.
206 wanrouter-v2214.gz patch for Linux kernel 2.2.14.
207 wanrouter-v2215.gz patch for Linux kernels 2.2.15 to 2.2.17.
208 wanrouter-v2218.gz patch for Linux kernels 2.2.18 and up.
209 wanrouter-v240.gz patch for Linux kernel 2.4.0.
210 wanrouter-v242.gz patch for Linux kernel 2.4.2 and up.
211 wanrouter-v2034.gz patch for Linux kernel 2.0.34
212 wanrouter-v2036.gz patch for Linux kernel 2.0.36 and up.
213
214/usr/local/wanrouter/patches/kdrivers:
215 Sources of the latest WANPIPE device drivers.
216 These are used to UPGRADE the linux kernel to the newest
217 version if the kernel source has already been pathced with
218 WANPIPE drivers.
219
220/usr/local/wanrouter/samples:
221 interface sample interface configuration file
222 wanpipe1.cpri CHDLC primary port
223 wanpipe2.csec CHDLC secondary port
224 wanpipe1.fr Frame Relay protocol
225 wanpipe1.ppp PPP protocol )
226 wanpipe1.asy CHDLC ASYNC protocol
227 wanpipe1.x25 X25 protocol
228 wanpipe1.stty Sync TTY driver (Used by Kernel PPPD daemon)
229 wanpipe1.atty Async TTY driver (Used by Kernel PPPD daemon)
230 wanrouter.rc sample meta-configuration file
231
232/usr/local/wanrouter/util:
233 * wan-tools utilities source code
234
235/usr/local/wanrouter/api/x25:
236 * x25 api sample programs.
237/usr/local/wanrouter/api/chdlc:
238 * chdlc api sample programs.
239/usr/local/wanrouter/api/fr:
240 * fr api sample programs.
241/usr/local/wanrouter/config/wancfg:
242 wancfg WANPIPE GUI configuration program.
243 Creates wanpipe#.conf files.
244/usr/local/wanrouter/config/cfgft1:
245 cfgft1 GUI CSU/DSU configuration program.
246
247/usr/include/linux:
248 wanrouter.h router API definitions
249 wanpipe.h WANPIPE API definitions
250 sdladrv.h SDLA support module API definitions
251 sdlasfm.h SDLA firmware module definitions
252 if_wanpipe.h WANPIPE Socket definitions
253 if_wanpipe_common.h WANPIPE Socket/Driver common definitions.
254 sdlapci.h WANPIPE PCI definitions
255
256
257/usr/src/linux/net/wanrouter:
258 * wanrouter source code
259
260/var/log:
261 wanrouter wanrouter start-up log (created by the Setup script)
262
263/var/lock: (or /var/lock/subsys for RedHat)
264 wanrouter wanrouter lock file (created by the Setup script)
265
266/usr/local/wanrouter/firmware:
267 fr514.sfm Frame relay firmware for Sangoma S508/S514 card
268 cdual514.sfm Dual Port Cisco HDLC firmware for Sangoma S508/S514 card
269 ppp514.sfm PPP Firmware for Sangoma S508 and S514 cards
270 x25_508.sfm X25 Firmware for Sangoma S508 card.
271
272
273REVISION HISTORY
274
2751.0.0 December 31, 1996 Initial version
276
2771.0.1 January 30, 1997 Status and statistics can be read via /proc
278 filesystem entries.
279
2801.0.2 April 30, 1997 Added UDP management via monitors.
281
2821.0.3 June 3, 1997 UDP management for multiple boards using Frame
283 Relay and PPP
284 Enabled continuous transmission of Configure
285 Request Packet for PPP (for 508 only)
286 Connection Timeout for PPP changed from 900 to 0
287 Flow Control Problem fixed for Frame Relay
288
2891.0.4 July 10, 1997 S508/FT1 monitoring capability in fpipemon and
290 ppipemon utilities.
291 Configurable TTL for UDP packets.
292 Multicast and Broadcast IP source addresses are
293 silently discarded.
294
2951.0.5 July 28, 1997 Configurable T391,T392,N391,N392,N393 for Frame
296 Relay in router.conf.
297 Configurable Memory Address through router.conf
298 for Frame Relay, PPP and X.25. (commenting this
299 out enables auto-detection).
300 Fixed freeing up received buffers using kfree()
301 for Frame Relay and X.25.
302 Protect sdla_peek() by calling save_flags(),
303 cli() and restore_flags().
304 Changed number of Trace elements from 32 to 20
305 Added DLCI specific data monitoring in FPIPEMON.
3062.0.0 Nov 07, 1997 Implemented protection of RACE conditions by
307 critical flags for FRAME RELAY and PPP.
308 DLCI List interrupt mode implemented.
309 IPX support in FRAME RELAY and PPP.
310 IPX Server Support (MARS)
311 More driver specific stats included in FPIPEMON
312 and PIPEMON.
313
3142.0.1 Nov 28, 1997 Bug Fixes for version 2.0.0.
315 Protection of "enable_irq()" while
316 "disable_irq()" has been enabled from any other
317 routine (for Frame Relay, PPP and X25).
318 Added additional Stats for Fpipemon and Ppipemon
319 Improved Load Sharing for multiple boards
320
3212.0.2 Dec 09, 1997 Support for PAP and CHAP for ppp has been
322 implemented.
323
3242.0.3 Aug 15, 1998 New release supporting Cisco HDLC, CIR for Frame
325 relay, Dynamic IP assignment for PPP and Inverse
326 Arp support for Frame-relay. Man Pages are
327 included for better support and a new utility
328 for configuring FT1 cards.
329
3302.0.4 Dec 09, 1998 Dual Port support for Cisco HDLC.
331 Support for HDLC (LAPB) API.
332 Supports BiSync Streaming code for S502E
333 and S503 cards.
334 Support for Streaming HDLC API.
335 Provides a BSD socket interface for
336 creating applications using BiSync
337 streaming.
338
3392.0.5 Aug 04, 1999 CHDLC initializatin bug fix.
340 PPP interrupt driven driver:
341 Fix to the PPP line hangup problem.
342 New PPP firmware
343 Added comments to the startup SYSTEM ERROR messages
344 Xpipemon debugging application for the X25 protocol
345 New USER_MANUAL.txt
346 Fixed the odd boundary 4byte writes to the board.
347 BiSync Streaming code has been taken out.
348 Available as a patch.
349 Streaming HDLC API has been taken out.
350 Available as a patch.
351
3522.0.6 Aug 17, 1999 Increased debugging in statup scripts
353 Fixed insallation bugs from 2.0.5
354 Kernel patch works for both 2.2.10 and 2.2.11 kernels.
355 There is no functional difference between the two packages
356
3572.0.7 Aug 26, 1999 o Merged X25API code into WANPIPE.
358 o Fixed a memeory leak for X25API
359 o Updated the X25API code for 2.2.X kernels.
360 o Improved NEM handling.
361
3622.1.0 Oct 25, 1999 o New code for S514 PCI Card
363 o New CHDLC and Frame Relay drivers
364 o PPP and X25 are not supported in this release
365
3662.1.1 Nov 30, 1999 o PPP support for S514 PCI Cards
367
3682.1.3 Apr 06, 2000 o Socket based x25api
369 o Socket based chdlc api
370 o Socket based fr api
371 o Dual Port Receive only CHDLC support.
372 o Asynchronous CHDLC support (Secondary Port)
373 o cfgft1 GUI csu/dsu configurator
374 o wancfg GUI configuration file
375 configurator.
376 o Architectual directory changes.
377
378beta-2.1.4 Jul 2000 o Dynamic interface configuration:
379 Network interfaces reflect the state
380 of protocol layer. If the protocol becomes
381 disconnected, driver will bring down
382 the interface. Once the protocol reconnects
383 the interface will be brought up.
384
385 Note: This option is turned off by default.
386
387 o Dynamic wanrouter setup using 'wanconfig':
388 wanconfig utility can be used to
389 shutdown,restart,start or reconfigure
390 a virtual circuit dynamically.
391
392 Frame Relay: Each DLCI can be:
393 created,stopped,restarted and reconfigured
394 dynamically using wanconfig.
395
396 ex: wanconfig card wanpipe1 dev wp1_fr16 up
397
398 o Wanrouter startup via command line arguments:
399 wanconfig also supports wanrouter startup via command line
400 arguments. Thus, there is no need to create a wanpipe#.conf
401 configuration file.
402
403 o Socket based x25api update/bug fixes.
404 Added support for LCN numbers greater than 255.
405 Option to pass up modem messages.
406 Provided a PCI IRQ check, so a single S514
407 card is guaranteed to have a non-sharing interrupt.
408
409 o Fixes to the wancfg utility.
410 o New FT1 debugging support via *pipemon utilities.
411 o Frame Relay ARP support Enabled.
412
413beta3-2.1.4 Jul 2000 o X25 M_BIT Problem fix.
414 o Added the Multi-Port PPP
415 Updated utilites for the Multi-Port PPP.
416
4172.1.4 Aut 2000
418 o In X25API:
419 Maximum packet an application can send
420 to the driver has been extended to 4096 bytes.
421
422 Fixed the x25 startup bug. Enable
423 communications only after all interfaces
424 come up. HIGH SVC/PVC is used to calculate
425 the number of channels.
426 Enable protocol only after all interfaces
427 are enabled.
428
429 o Added an extra state to the FT1 config, kernel module.
430 o Updated the pipemon debuggers.
431
432 o Blocked the Multi-Port PPP from running on kernels
433 2.2.16 or greater, due to syncppp kernel module
434 change.
435
436beta1-2.1.5 Nov 15 2000
437 o Fixed the MulitPort PPP Support for kernels 2.2.16 and above.
438 2.2.X kernels only
439
440 o Secured the driver UDP debugging calls
441 - All illegal netowrk debugging calls are reported to
442 the log.
443 - Defined a set of allowed commands, all other denied.
444
445 o Cpipemon
446 - Added set FT1 commands to the cpipemon. Thus CSU/DSU
447 configuraiton can be performed using cpipemon.
448 All systems that cannot run cfgft1 GUI utility should
449 use cpipemon to configure the on board CSU/DSU.
450
451
452 o Keyboard Led Monitor/Debugger
453 - A new utilty /usr/sbin/wpkbdmon uses keyboard leds
454 to convey operatinal statistic information of the
455 Sangoma WANPIPE cards.
456 NUM_LOCK = Line State (On=connected, Off=disconnected)
457 CAPS_LOCK = Tx data (On=transmitting, Off=no tx data)
458 SCROLL_LOCK = Rx data (On=receiving, Off=no rx data
459
460 o Hardware probe on module load and dynamic device allocation
461 - During WANPIPE module load, all Sangoma cards are probed
462 and found information is printed in the /var/log/messages.
463 - If no cards are found, the module load fails.
464 - Appropriate number of devices are dynamically loaded
465 based on the number of Sangoma cards found.
466
467 Note: The kernel configuraiton option
468 CONFIG_WANPIPE_CARDS has been taken out.
469
470 o Fixed the Frame Relay and Chdlc network interfaces so they are
471 compatible with libpcap libraries. Meaning, tcpdump, snort,
472 ethereal, and all other packet sniffers and debuggers work on
473 all WANPIPE netowrk interfaces.
474 - Set the network interface encoding type to ARPHRD_PPP.
475 This tell the sniffers that data obtained from the
476 network interface is in pure IP format.
477 Fix for 2.2.X kernels only.
478
479 o True interface encoding option for Frame Relay and CHDLC
480 - The above fix sets the network interface encoding
481 type to ARPHRD_PPP, however some customers use
482 the encoding interface type to determine the
483 protocol running. Therefore, the TURE ENCODING
484 option will set the interface type back to the
485 original value.
486
487 NOTE: If this option is used with Frame Relay and CHDLC
488 libpcap library support will be broken.
489 i.e. tcpdump will not work.
490 Fix for 2.2.x Kernels only.
491
492 o Ethernet Bridgind over Frame Relay
493 - The Frame Relay bridging has been developed by
494 Kristian Hoffmann and Mark Wells.
495 - The Linux kernel bridge is used to send ethernet
496 data over the frame relay links.
497 For 2.2.X Kernels only.
498
499 o Added extensive 2.0.X support. Most new features of
500 2.1.5 for protocols Frame Relay, PPP and CHDLC are
501 supported under 2.0.X kernels.
502
503beta1-2.2.0 Dec 30 2000
504 o Updated drivers for 2.4.X kernels.
505 o Updated drivers for SMP support.
506 o X25API is now able to share PCI interrupts.
507 o Took out a general polling routine that was used
508 only by X25API.
509 o Added appropriate locks to the dynamic reconfiguration
510 code.
511 o Fixed a bug in the keyboard debug monitor.
512
513beta2-2.2.0 Jan 8 2001
514 o Patches for 2.4.0 kernel
515 o Patches for 2.2.18 kernel
516 o Minor updates to PPP and CHLDC drivers.
517 Note: No functinal difference.
518
519beta3-2.2.9 Jan 10 2001
520 o I missed the 2.2.18 kernel patches in beta2-2.2.0
521 release. They are included in this release.
522
523Stable Release
5242.2.0 Feb 01 2001
525 o Bug fix in wancfg GUI configurator.
526 The edit function didn't work properly.
527
528
529bata1-2.2.1 Feb 09 2001
530 o WANPIPE TTY Driver emulation.
531 Two modes of operation Sync and Async.
532 Sync: Using the PPPD daemon, kernel SyncPPP layer
533 and the Wanpipe sync TTY driver: a PPP protocol
534 connection can be established via Sangoma adapter, over
535 a T1 leased line.
536
537 The 2.4.0 kernel PPP layer supports MULTILINK
538 protocol, that can be used to bundle any number of Sangoma
539 adapters (T1 lines) into one, under a single IP address.
540 Thus, efficiently obtaining multiple T1 throughput.
541
542 NOTE: The remote side must also implement MULTILINK PPP
543 protocol.
544
545 Async:Using the PPPD daemon, kernel AsyncPPP layer
546 and the WANPIPE async TTY driver: a PPP protocol
547 connection can be established via Sangoma adapter and
548 a modem, over a telephone line.
549
550 Thus, the WANPIPE async TTY driver simulates a serial
551 TTY driver that would normally be used to interface the
552 MODEM to the linux kernel.
553
554 o WANPIPE PPP Backup Utility
555 This utility will monitor the state of the PPP T1 line.
556 In case of failure, a dial up connection will be established
557 via pppd daemon, ether via a serial tty driver (serial port),
558 or a WANPIPE async TTY driver (in case serial port is unavailable).
559
560 Furthermore, while in dial up mode, the primary PPP T1 link
561 will be monitored for signs of life.
562
563 If the PPP T1 link comes back to life, the dial up connection
564 will be shutdown and T1 line re-established.
565
566
567 o New Setup installation script.
568 Option to UPGRADE device drivers if the kernel source has
569 already been patched with WANPIPE.
570
571 Option to COMPILE WANPIPE modules against the currently
572 running kernel, thus no need for manual kernel and module
573 re-compilatin.
574
575 o Updates and Bug Fixes to wancfg utility.
576
577bata2-2.2.1 Feb 20 2001
578
579 o Bug fixes to the CHDLC device drivers.
580 The driver had compilation problems under kernels
581 2.2.14 or lower.
582
583 o Bug fixes to the Setup installation script.
584 The device drivers compilation options didn't work
585 properly.
586
587 o Update to the wpbackupd daemon.
588 Optimized the cross-over times, between the primary
589 link and the backup dialup.
590
591beta3-2.2.1 Mar 02 2001
592 o Patches for 2.4.2 kernel.
593
594 o Bug fixes to util/ make files.
595 o Bug fixes to the Setup installation script.
596
597 o Took out the backupd support and made it into
598 as separate package.
599
600beta4-2.2.1 Mar 12 2001
601
602 o Fix to the Frame Relay Device driver.
603 IPSAC sends a packet of zero length
604 header to the frame relay driver. The
605 driver tries to push its own 2 byte header
606 into the packet, which causes the driver to
607 crash.
608
609 o Fix the WANPIPE re-configuration code.
610 Bug was found by trying to run the cfgft1 while the
611 interface was already running.
612
613 o Updates to cfgft1.
614 Writes a wanpipe#.cfgft1 configuration file
615 once the CSU/DSU is configured. This file can
616 holds the current CSU/DSU configuration.
617
618
619
620>>>>>> END OF README <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
621
622
diff --git a/Documentation/power/kernel_threads.txt b/Documentation/power/kernel_threads.txt
index 60b548105edf..fb57784986b1 100644
--- a/Documentation/power/kernel_threads.txt
+++ b/Documentation/power/kernel_threads.txt
@@ -12,8 +12,7 @@ refrigerator. Code to do this looks like this:
12 do { 12 do {
13 hub_events(); 13 hub_events();
14 wait_event_interruptible(khubd_wait, !list_empty(&hub_event_list)); 14 wait_event_interruptible(khubd_wait, !list_empty(&hub_event_list));
15 if (current->flags & PF_FREEZE) 15 try_to_freeze();
16 refrigerator(PF_FREEZE);
17 } while (!signal_pending(current)); 16 } while (!signal_pending(current));
18 17
19from drivers/usb/core/hub.c::hub_thread() 18from drivers/usb/core/hub.c::hub_thread()
diff --git a/Documentation/power/pci.txt b/Documentation/power/pci.txt
index 35b1a7dae342..6fc9d511fc39 100644
--- a/Documentation/power/pci.txt
+++ b/Documentation/power/pci.txt
@@ -291,6 +291,44 @@ a request to enable wake events from D3, two calls should be made to
291pci_enable_wake (one for both D3hot and D3cold). 291pci_enable_wake (one for both D3hot and D3cold).
292 292
293 293
294A reference implementation
295-------------------------
296.suspend()
297{
298 /* driver specific operations */
299
300 /* Disable IRQ */
301 free_irq();
302 /* If using MSI */
303 pci_disable_msi();
304
305 pci_save_state();
306 pci_enable_wake();
307 /* Disable IO/bus master/irq router */
308 pci_disable_device();
309 pci_set_power_state(pci_choose_state());
310}
311
312.resume()
313{
314 pci_set_power_state(PCI_D0);
315 pci_restore_state();
316 /* device's irq possibly is changed, driver should take care */
317 pci_enable_device();
318 pci_set_master();
319
320 /* if using MSI, device's vector possibly is changed */
321 pci_enable_msi();
322
323 request_irq();
324 /* driver specific operations; */
325}
326
327This is a typical implementation. Drivers can slightly change the order
328of the operations in the implementation, ignore some operations or add
329more deriver specific operations in it, but drivers should do something like
330this on the whole.
331
2945. Resources 3325. Resources
295~~~~~~~~~~~~ 333~~~~~~~~~~~~
296 334
diff --git a/Documentation/power/swsusp.txt b/Documentation/power/swsusp.txt
index c7c3459fde43..7a6b78966459 100644
--- a/Documentation/power/swsusp.txt
+++ b/Documentation/power/swsusp.txt
@@ -164,11 +164,11 @@ place where the thread is safe to be frozen (no kernel semaphores
164should be held at that point and it must be safe to sleep there), and 164should be held at that point and it must be safe to sleep there), and
165add: 165add:
166 166
167 if (current->flags & PF_FREEZE) 167 try_to_freeze();
168 refrigerator(PF_FREEZE);
169 168
170If the thread is needed for writing the image to storage, you should 169If the thread is needed for writing the image to storage, you should
171instead set the PF_NOFREEZE process flag when creating the thread. 170instead set the PF_NOFREEZE process flag when creating the thread (and
171be very carefull).
172 172
173 173
174Q: What is the difference between between "platform", "shutdown" and 174Q: What is the difference between between "platform", "shutdown" and
@@ -233,3 +233,81 @@ A: Try running
233cat `cat /proc/[0-9]*/maps | grep / | sed 's:.* /:/:' | sort -u` > /dev/null 233cat `cat /proc/[0-9]*/maps | grep / | sed 's:.* /:/:' | sort -u` > /dev/null
234 234
235after resume. swapoff -a; swapon -a may also be usefull. 235after resume. swapoff -a; swapon -a may also be usefull.
236
237Q: What happens to devices during swsusp? They seem to be resumed
238during system suspend?
239
240A: That's correct. We need to resume them if we want to write image to
241disk. Whole sequence goes like
242
243 Suspend part
244 ~~~~~~~~~~~~
245 running system, user asks for suspend-to-disk
246
247 user processes are stopped
248
249 suspend(PMSG_FREEZE): devices are frozen so that they don't interfere
250 with state snapshot
251
252 state snapshot: copy of whole used memory is taken with interrupts disabled
253
254 resume(): devices are woken up so that we can write image to swap
255
256 write image to swap
257
258 suspend(PMSG_SUSPEND): suspend devices so that we can power off
259
260 turn the power off
261
262 Resume part
263 ~~~~~~~~~~~
264 (is actually pretty similar)
265
266 running system, user asks for suspend-to-disk
267
268 user processes are stopped (in common case there are none, but with resume-from-initrd, noone knows)
269
270 read image from disk
271
272 suspend(PMSG_FREEZE): devices are frozen so that they don't interfere
273 with image restoration
274
275 image restoration: rewrite memory with image
276
277 resume(): devices are woken up so that system can continue
278
279 thaw all user processes
280
281Q: What is this 'Encrypt suspend image' for?
282
283A: First of all: it is not a replacement for dm-crypt encrypted swap.
284It cannot protect your computer while it is suspended. Instead it does
285protect from leaking sensitive data after resume from suspend.
286
287Think of the following: you suspend while an application is running
288that keeps sensitive data in memory. The application itself prevents
289the data from being swapped out. Suspend, however, must write these
290data to swap to be able to resume later on. Without suspend encryption
291your sensitive data are then stored in plaintext on disk. This means
292that after resume your sensitive data are accessible to all
293applications having direct access to the swap device which was used
294for suspend. If you don't need swap after resume these data can remain
295on disk virtually forever. Thus it can happen that your system gets
296broken in weeks later and sensitive data which you thought were
297encrypted and protected are retrieved and stolen from the swap device.
298To prevent this situation you should use 'Encrypt suspend image'.
299
300During suspend a temporary key is created and this key is used to
301encrypt the data written to disk. When, during resume, the data was
302read back into memory the temporary key is destroyed which simply
303means that all data written to disk during suspend are then
304inaccessible so they can't be stolen later on. The only thing that
305you must then take care of is that you call 'mkswap' for the swap
306partition used for suspend as early as possible during regular
307boot. This asserts that any temporary key from an oopsed suspend or
308from a failed or aborted resume is erased from the swap device.
309
310As a rule of thumb use encrypted swap to protect your data while your
311system is shut down or suspended. Additionally use the encrypted
312suspend image to prevent sensitive data from being stolen after
313resume.
diff --git a/Documentation/power/video.txt b/Documentation/power/video.txt
index 68734355d7cf..881a37e3eeb0 100644
--- a/Documentation/power/video.txt
+++ b/Documentation/power/video.txt
@@ -83,8 +83,10 @@ Compaq Armada E500 - P3-700 none (1) (S1 also works OK)
83Compaq Evo N620c vga=normal, s3_bios (2) 83Compaq Evo N620c vga=normal, s3_bios (2)
84Dell 600m, ATI R250 Lf none (1), but needs xorg-x11-6.8.1.902-1 84Dell 600m, ATI R250 Lf none (1), but needs xorg-x11-6.8.1.902-1
85Dell D600, ATI RV250 vga=normal and X, or try vbestate (6) 85Dell D600, ATI RV250 vga=normal and X, or try vbestate (6)
86Dell D610 vga=normal and X (possibly vbestate (6) too, but not tested)
86Dell Inspiron 4000 ??? (*) 87Dell Inspiron 4000 ??? (*)
87Dell Inspiron 500m ??? (*) 88Dell Inspiron 500m ??? (*)
89Dell Inspiron 510m ???
88Dell Inspiron 600m ??? (*) 90Dell Inspiron 600m ??? (*)
89Dell Inspiron 8200 ??? (*) 91Dell Inspiron 8200 ??? (*)
90Dell Inspiron 8500 ??? (*) 92Dell Inspiron 8500 ??? (*)
@@ -123,6 +125,7 @@ Toshiba Satellite 4030CDT s3_mode (3)
123Toshiba Satellite 4080XCDT s3_mode (3) 125Toshiba Satellite 4080XCDT s3_mode (3)
124Toshiba Satellite 4090XCDT ??? (*) 126Toshiba Satellite 4090XCDT ??? (*)
125Toshiba Satellite P10-554 s3_bios,s3_mode (4)(****) 127Toshiba Satellite P10-554 s3_bios,s3_mode (4)(****)
128Toshiba M30 (2) xor X with nvidia driver using internal AGP
126Uniwill 244IIO ??? (*) 129Uniwill 244IIO ??? (*)
127 130
128 131
diff --git a/Documentation/power/video_extension.txt b/Documentation/power/video_extension.txt
index 8e33d7c82c49..b2f9b1598ac2 100644
--- a/Documentation/power/video_extension.txt
+++ b/Documentation/power/video_extension.txt
@@ -1,13 +1,16 @@
1This driver implement the ACPI Extensions For Display Adapters 1ACPI video extensions
2for integrated graphics devices on motherboard, as specified in 2~~~~~~~~~~~~~~~~~~~~~
3ACPI 2.0 Specification, Appendix B, allowing to perform some basic 3
4control like defining the video POST device, retrieving EDID information 4This driver implement the ACPI Extensions For Display Adapters for
5or to setup a video output, etc. Note that this is an ref. implementation only. 5integrated graphics devices on motherboard, as specified in ACPI 2.0
6It may or may not work for your integrated video device. 6Specification, Appendix B, allowing to perform some basic control like
7defining the video POST device, retrieving EDID information or to
8setup a video output, etc. Note that this is an ref. implementation
9only. It may or may not work for your integrated video device.
7 10
8Interfaces exposed to userland through /proc/acpi/video: 11Interfaces exposed to userland through /proc/acpi/video:
9 12
10VGA/info : display the supported video bus device capability like ,Video ROM, CRT/LCD/TV. 13VGA/info : display the supported video bus device capability like Video ROM, CRT/LCD/TV.
11VGA/ROM : Used to get a copy of the display devices' ROM data (up to 4k). 14VGA/ROM : Used to get a copy of the display devices' ROM data (up to 4k).
12VGA/POST_info : Used to determine what options are implemented. 15VGA/POST_info : Used to determine what options are implemented.
13VGA/POST : Used to get/set POST device. 16VGA/POST : Used to get/set POST device.
@@ -15,7 +18,7 @@ VGA/DOS : Used to get/set ownership of output switching:
15 Please refer ACPI spec B.4.1 _DOS 18 Please refer ACPI spec B.4.1 _DOS
16VGA/CRT : CRT output 19VGA/CRT : CRT output
17VGA/LCD : LCD output 20VGA/LCD : LCD output
18VGA/TV : TV output 21VGA/TVO : TV output
19VGA/*/brightness : Used to get/set brightness of output device 22VGA/*/brightness : Used to get/set brightness of output device
20 23
21Notify event through /proc/acpi/event: 24Notify event through /proc/acpi/event:
diff --git a/Documentation/s390/CommonIO b/Documentation/s390/CommonIO
index a831d9ae5a5e..59d1166d41ee 100644
--- a/Documentation/s390/CommonIO
+++ b/Documentation/s390/CommonIO
@@ -30,7 +30,7 @@ Command line parameters
30 device numbers (0xabcd or abcd, for 2.4 backward compatibility). 30 device numbers (0xabcd or abcd, for 2.4 backward compatibility).
31 You can use the 'all' keyword to ignore all devices. 31 You can use the 'all' keyword to ignore all devices.
32 The '!' operator will cause the I/O-layer to _not_ ignore a device. 32 The '!' operator will cause the I/O-layer to _not_ ignore a device.
33 The order on the command line is not important. 33 The command line is parsed from left to right.
34 34
35 For example, 35 For example,
36 cio_ignore=0.0.0023-0.0.0042,0.0.4711 36 cio_ignore=0.0.0023-0.0.0042,0.0.4711
@@ -72,13 +72,14 @@ Command line parameters
72 /proc/cio_ignore; "add <device range>, <device range>, ..." will ignore the 72 /proc/cio_ignore; "add <device range>, <device range>, ..." will ignore the
73 specified devices. 73 specified devices.
74 74
75 Note: Already known devices cannot be ignored. 75 Note: While already known devices can be added to the list of devices to be
76 ignored, there will be no effect on then. However, if such a device
77 disappears and then reappeares, it will then be ignored.
76 78
77 For example, if device 0.0.abcd is already known and all other devices 79 For example,
78 0.0.a000-0.0.afff are not known,
79 "echo add 0.0.a000-0.0.accc, 0.0.af00-0.0.afff > /proc/cio_ignore" 80 "echo add 0.0.a000-0.0.accc, 0.0.af00-0.0.afff > /proc/cio_ignore"
80 will add 0.0.a000-0.0.abcc, 0.0.abce-0.0.accc and 0.0.af00-0.0.afff to the 81 will add 0.0.a000-0.0.accc and 0.0.af00-0.0.afff to the list of ignored
81 list of ignored devices and skip 0.0.abcd. 82 devices.
82 83
83 The devices can be specified either by bus id (0.0.abcd) or, for 2.4 backward 84 The devices can be specified either by bus id (0.0.abcd) or, for 2.4 backward
84 compatibilty, by the device number in hexadecimal (0xabcd or abcd). 85 compatibilty, by the device number in hexadecimal (0xabcd or abcd).
@@ -98,7 +99,8 @@ Command line parameters
98 99
99 - /proc/s390dbf/cio_trace/hex_ascii 100 - /proc/s390dbf/cio_trace/hex_ascii
100 Logs the calling of functions in the common I/O-layer and, if applicable, 101 Logs the calling of functions in the common I/O-layer and, if applicable,
101 which subchannel they were called for. 102 which subchannel they were called for, as well as dumps of some data
103 structures (like irb in an error case).
102 104
103 The level of logging can be changed to be more or less verbose by piping to 105 The level of logging can be changed to be more or less verbose by piping to
104 /proc/s390dbf/cio_*/level a number between 0 and 6; see the documentation on 106 /proc/s390dbf/cio_*/level a number between 0 and 6; see the documentation on
diff --git a/Documentation/s390/s390dbf.txt b/Documentation/s390/s390dbf.txt
index 2d1cd939b4df..e24fdeada970 100644
--- a/Documentation/s390/s390dbf.txt
+++ b/Documentation/s390/s390dbf.txt
@@ -12,8 +12,8 @@ where log records can be stored efficiently in memory, where each component
12One purpose of this is to inspect the debug logs after a production system crash 12One purpose of this is to inspect the debug logs after a production system crash
13in order to analyze the reason for the crash. 13in order to analyze the reason for the crash.
14If the system still runs but only a subcomponent which uses dbf failes, 14If the system still runs but only a subcomponent which uses dbf failes,
15it is possible to look at the debug logs on a live system via the Linux proc 15it is possible to look at the debug logs on a live system via the Linux
16filesystem. 16debugfs filesystem.
17The debug feature may also very useful for kernel and driver development. 17The debug feature may also very useful for kernel and driver development.
18 18
19Design: 19Design:
@@ -52,16 +52,18 @@ Each debug entry contains the following data:
52- Flag, if entry is an exception or not 52- Flag, if entry is an exception or not
53 53
54The debug logs can be inspected in a live system through entries in 54The debug logs can be inspected in a live system through entries in
55the proc-filesystem. Under the path /proc/s390dbf there is 55the debugfs-filesystem. Under the toplevel directory "s390dbf" there is
56a directory for each registered component, which is named like the 56a directory for each registered component, which is named like the
57corresponding component. 57corresponding component. The debugfs normally should be mounted to
58/sys/kernel/debug therefore the debug feature can be accessed unter
59/sys/kernel/debug/s390dbf.
58 60
59The content of the directories are files which represent different views 61The content of the directories are files which represent different views
60to the debug log. Each component can decide which views should be 62to the debug log. Each component can decide which views should be
61used through registering them with the function debug_register_view(). 63used through registering them with the function debug_register_view().
62Predefined views for hex/ascii, sprintf and raw binary data are provided. 64Predefined views for hex/ascii, sprintf and raw binary data are provided.
63It is also possible to define other views. The content of 65It is also possible to define other views. The content of
64a view can be inspected simply by reading the corresponding proc file. 66a view can be inspected simply by reading the corresponding debugfs file.
65 67
66All debug logs have an an actual debug level (range from 0 to 6). 68All debug logs have an an actual debug level (range from 0 to 6).
67The default level is 3. Event and Exception functions have a 'level' 69The 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
69than the actual level are written to the log. This means, when 71than the actual level are written to the log. This means, when
70writing events, high priority log entries should have a low level 72writing events, high priority log entries should have a low level
71value whereas low priority entries should have a high one. 73value whereas low priority entries should have a high one.
72The actual debug level can be changed with the help of the proc-filesystem 74The actual debug level can be changed with the help of the debugfs-filesystem
73through writing a number string "x" to the 'level' proc file which is 75through writing a number string "x" to the 'level' debugfs file which is
74provided for every debug log. Debugging can be switched off completely 76provided for every debug log. Debugging can be switched off completely
75by using "-" on the 'level' proc file. 77by using "-" on the 'level' debugfs file.
76 78
77Example: 79Example:
78 80
79> echo "-" > /proc/s390dbf/dasd/level 81> echo "-" > /sys/kernel/debug/s390dbf/dasd/level
80 82
81It is also possible to deactivate the debug feature globally for every 83It is also possible to deactivate the debug feature globally for every
82debug log. You can change the behavior using 2 sysctl parameters in 84debug log. You can change the behavior using 2 sysctl parameters in
@@ -99,11 +101,11 @@ Kernel Interfaces:
99------------------ 101------------------
100 102
101---------------------------------------------------------------------------- 103----------------------------------------------------------------------------
102debug_info_t *debug_register(char *name, int pages_index, int nr_areas, 104debug_info_t *debug_register(char *name, int pages, int nr_areas,
103 int buf_size); 105 int buf_size);
104 106
105Parameter: name: Name of debug log (e.g. used for proc entry) 107Parameter: name: Name of debug log (e.g. used for debugfs entry)
106 pages_index: 2^pages_index pages will be allocated per area 108 pages: number of pages, which will be allocated per area
107 nr_areas: number of debug areas 109 nr_areas: number of debug areas
108 buf_size: size of data area in each debug entry 110 buf_size: size of data area in each debug entry
109 111
@@ -134,7 +136,7 @@ Return Value: none
134Description: Sets new actual debug level if new_level is valid. 136Description: Sets new actual debug level if new_level is valid.
135 137
136--------------------------------------------------------------------------- 138---------------------------------------------------------------------------
137+void debug_stop_all(void); 139void debug_stop_all(void);
138 140
139Parameter: none 141Parameter: none
140 142
@@ -270,7 +272,7 @@ Parameter: id: handle for debug log
270Return Value: 0 : ok 272Return Value: 0 : ok
271 < 0: Error 273 < 0: Error
272 274
273Description: registers new debug view and creates proc dir entry 275Description: registers new debug view and creates debugfs dir entry
274 276
275--------------------------------------------------------------------------- 277---------------------------------------------------------------------------
276int debug_unregister_view (debug_info_t * id, struct debug_view *view); 278int debug_unregister_view (debug_info_t * id, struct debug_view *view);
@@ -281,7 +283,7 @@ Parameter: id: handle for debug log
281Return Value: 0 : ok 283Return Value: 0 : ok
282 < 0: Error 284 < 0: Error
283 285
284Description: unregisters debug view and removes proc dir entry 286Description: unregisters debug view and removes debugfs dir entry
285 287
286 288
287 289
@@ -308,7 +310,7 @@ static int init(void)
308{ 310{
309 /* register 4 debug areas with one page each and 4 byte data field */ 311 /* register 4 debug areas with one page each and 4 byte data field */
310 312
311 debug_info = debug_register ("test", 0, 4, 4 ); 313 debug_info = debug_register ("test", 1, 4, 4 );
312 debug_register_view(debug_info,&debug_hex_ascii_view); 314 debug_register_view(debug_info,&debug_hex_ascii_view);
313 debug_register_view(debug_info,&debug_raw_view); 315 debug_register_view(debug_info,&debug_raw_view);
314 316
@@ -343,7 +345,7 @@ static int init(void)
343 /* register 4 debug areas with one page each and data field for */ 345 /* register 4 debug areas with one page each and data field for */
344 /* format string pointer + 2 varargs (= 3 * sizeof(long)) */ 346 /* format string pointer + 2 varargs (= 3 * sizeof(long)) */
345 347
346 debug_info = debug_register ("test", 0, 4, sizeof(long) * 3); 348 debug_info = debug_register ("test", 1, 4, sizeof(long) * 3);
347 debug_register_view(debug_info,&debug_sprintf_view); 349 debug_register_view(debug_info,&debug_sprintf_view);
348 350
349 debug_sprintf_event(debug_info, 2 , "first event in %s:%i\n",__FILE__,__LINE__); 351 debug_sprintf_event(debug_info, 2 , "first event in %s:%i\n",__FILE__,__LINE__);
@@ -362,16 +364,16 @@ module_exit(cleanup);
362 364
363 365
364 366
365ProcFS Interface 367Debugfs Interface
366---------------- 368----------------
367Views to the debug logs can be investigated through reading the corresponding 369Views to the debug logs can be investigated through reading the corresponding
368proc-files: 370debugfs-files:
369 371
370Example: 372Example:
371 373
372> ls /proc/s390dbf/dasd 374> ls /sys/kernel/debug/s390dbf/dasd
373flush hex_ascii level raw 375flush hex_ascii level pages raw
374> cat /proc/s390dbf/dasd/hex_ascii | sort +1 376> cat /sys/kernel/debug/s390dbf/dasd/hex_ascii | sort +1
37500 00974733272:680099 2 - 02 0006ad7e 07 ea 4a 90 | .... 37700 00974733272:680099 2 - 02 0006ad7e 07 ea 4a 90 | ....
37600 00974733272:682210 2 - 02 0006ade6 46 52 45 45 | FREE 37800 00974733272:682210 2 - 02 0006ade6 46 52 45 45 | FREE
37700 00974733272:682213 2 - 02 0006adf6 07 ea 4a 90 | .... 37900 00974733272:682213 2 - 02 0006adf6 07 ea 4a 90 | ....
@@ -391,25 +393,36 @@ Changing the debug level
391Example: 393Example:
392 394
393 395
394> cat /proc/s390dbf/dasd/level 396> cat /sys/kernel/debug/s390dbf/dasd/level
3953 3973
396> echo "5" > /proc/s390dbf/dasd/level 398> echo "5" > /sys/kernel/debug/s390dbf/dasd/level
397> cat /proc/s390dbf/dasd/level 399> cat /sys/kernel/debug/s390dbf/dasd/level
3985 4005
399 401
400Flushing debug areas 402Flushing debug areas
401-------------------- 403--------------------
402Debug areas can be flushed with piping the number of the desired 404Debug areas can be flushed with piping the number of the desired
403area (0...n) to the proc file "flush". When using "-" all debug areas 405area (0...n) to the debugfs file "flush". When using "-" all debug areas
404are flushed. 406are flushed.
405 407
406Examples: 408Examples:
407 409
4081. Flush debug area 0: 4101. Flush debug area 0:
409> echo "0" > /proc/s390dbf/dasd/flush 411> echo "0" > /sys/kernel/debug/s390dbf/dasd/flush
410 412
4112. Flush all debug areas: 4132. Flush all debug areas:
412> echo "-" > /proc/s390dbf/dasd/flush 414> echo "-" > /sys/kernel/debug/s390dbf/dasd/flush
415
416Changing the size of debug areas
417------------------------------------
418It is possible the change the size of debug areas through piping
419the number of pages to the debugfs file "pages". The resize request will
420also flush the debug areas.
421
422Example:
423
424Define 4 pages for the debug areas of debug feature "dasd":
425> echo "4" > /sys/kernel/debug/s390dbf/dasd/pages
413 426
414Stooping the debug feature 427Stooping the debug feature
415-------------------------- 428--------------------------
@@ -491,7 +504,7 @@ Defining views
491-------------- 504--------------
492 505
493Views are specified with the 'debug_view' structure. There are defined 506Views are specified with the 'debug_view' structure. There are defined
494callback functions which are used for reading and writing the proc files: 507callback functions which are used for reading and writing the debugfs files:
495 508
496struct debug_view { 509struct debug_view {
497 char name[DEBUG_MAX_PROCF_LEN]; 510 char name[DEBUG_MAX_PROCF_LEN];
@@ -525,7 +538,7 @@ typedef int (debug_input_proc_t) (debug_info_t* id,
525The "private_data" member can be used as pointer to view specific data. 538The "private_data" member can be used as pointer to view specific data.
526It is not used by the debug feature itself. 539It is not used by the debug feature itself.
527 540
528The output when reading a debug-proc file is structured like this: 541The output when reading a debugfs file is structured like this:
529 542
530"prolog_proc output" 543"prolog_proc output"
531 544
@@ -534,13 +547,13 @@ The output when reading a debug-proc file is structured like this:
534"header_proc output 3" "format_proc output 3" 547"header_proc output 3" "format_proc output 3"
535... 548...
536 549
537When a view is read from the proc fs, the Debug Feature calls the 550When a view is read from the debugfs, the Debug Feature calls the
538'prolog_proc' once for writing the prolog. 551'prolog_proc' once for writing the prolog.
539Then 'header_proc' and 'format_proc' are called for each 552Then 'header_proc' and 'format_proc' are called for each
540existing debug entry. 553existing debug entry.
541 554
542The input_proc can be used to implement functionality when it is written to 555The input_proc can be used to implement functionality when it is written to
543the view (e.g. like with 'echo "0" > /proc/s390dbf/dasd/level). 556the view (e.g. like with 'echo "0" > /sys/kernel/debug/s390dbf/dasd/level).
544 557
545For header_proc there can be used the default function 558For header_proc there can be used the default function
546debug_dflt_header_fn() which is defined in in debug.h. 559debug_dflt_header_fn() which is defined in in debug.h.
@@ -602,7 +615,7 @@ debug_info = debug_register ("test", 0, 4, 4 ));
602debug_register_view(debug_info, &debug_test_view); 615debug_register_view(debug_info, &debug_test_view);
603for(i = 0; i < 10; i ++) debug_int_event(debug_info, 1, i); 616for(i = 0; i < 10; i ++) debug_int_event(debug_info, 1, i);
604 617
605> cat /proc/s390dbf/test/myview 618> cat /sys/kernel/debug/s390dbf/test/myview
60600 00964419734:611402 1 - 00 88042ca This error........... 61900 00964419734:611402 1 - 00 88042ca This error...........
60700 00964419734:611405 1 - 00 88042ca That error........... 62000 00964419734:611405 1 - 00 88042ca That error...........
60800 00964419734:611408 1 - 00 88042ca Problem.............. 62100 00964419734:611408 1 - 00 88042ca Problem..............
diff --git a/Documentation/scsi/ChangeLog.megaraid b/Documentation/scsi/ChangeLog.megaraid
index a9356c63b800..5331d91432c7 100644
--- a/Documentation/scsi/ChangeLog.megaraid
+++ b/Documentation/scsi/ChangeLog.megaraid
@@ -1,3 +1,69 @@
1Release Date : Mon Mar 07 12:27:22 EST 2005 - Seokmann Ju <sju@lsil.com>
2Current Version : 2.20.4.6 (scsi module), 2.20.2.6 (cmm module)
3Older Version : 2.20.4.5 (scsi module), 2.20.2.5 (cmm module)
4
51. Added IOCTL backward compatibility.
6 Convert megaraid_mm driver to new compat_ioctl entry points.
7 I don't have easy access to hardware, so only compile tested.
8 - Signed-off-by:Andi Kleen <ak@muc.de>
9
102. megaraid_mbox fix: wrong order of arguments in memset()
11 That, BTW, shows why cross-builds are useful-the only indication of
12 problem had been a new warning showing up in sparse output on alpha
13 build (number of exceeding 256 got truncated).
14 - Signed-off-by: Al Viro
15 <viro@parcelfarce.linux.theplanet.co.uk>
16
173. Convert pci_module_init to pci_register_driver
18 Convert from pci_module_init to pci_register_driver
19 (from:http://kerneljanitors.org/TODO)
20 - Signed-off-by: Domen Puncer <domen@coderock.org>
21
224. Use the pre defined DMA mask constants from dma-mapping.h
23 Use the DMA_{64,32}BIT_MASK constants from dma-mapping.h when calling
24 pci_set_dma_mask() or pci_set_consistend_dma_mask(). See
25 http://marc.theaimsgroup.com/?t=108001993000001&r=1&w=2 for more
26 details.
27 Signed-off-by: Tobias Klauser <tklauser@nuerscht.ch>
28 Signed-off-by: Domen Puncer <domen@coderock.org>
29
305. Remove SSID checking for Dobson, Lindsay, and Verde based products.
31 Checking the SSVID/SSID for controllers which have Dobson, Lindsay,
32 and Verde is unnecessary because device ID has been assigned by LSI
33 and it is unique value. So, all controllers with these IOPs have to be
34 supported by the driver regardless SSVID/SSID.
35
366. Date Thu, 27 Jan 2005 04:31:09 +0100
37 From Herbert Poetzl <>
38 Subject RFC: assert_spin_locked() for 2.6
39
40 Greetings!
41
42 overcautious programming will kill your kernel ;)
43 ever thought about checking a spin_lock or even
44 asserting that it must be held (maybe just for
45 spinlock debugging?) ...
46
47 there are several checks present in the kernel
48 where somebody does a variation on the following:
49
50 BUG_ON(!spin_is_locked(&some_lock));
51
52 so what's wrong about that? nothing, unless you
53 compile the code with CONFIG_DEBUG_SPINLOCK but
54 without CONFIG_SMP ... in which case the BUG()
55 will kill your kernel ...
56
57 maybe it's not advised to make such assertions,
58 but here is a solution which works for me ...
59 (compile tested for sh, x86_64 and x86, boot/run
60 tested for x86 only)
61
62 best,
63 Herbert
64
65 - Herbert Poetzl <herbert@13thfloor.at>, Thu, 27 Jan 2005
66
1Release Date : Thu Feb 03 12:27:22 EST 2005 - Seokmann Ju <sju@lsil.com> 67Release Date : Thu Feb 03 12:27:22 EST 2005 - Seokmann Ju <sju@lsil.com>
2Current Version : 2.20.4.5 (scsi module), 2.20.2.5 (cmm module) 68Current Version : 2.20.4.5 (scsi module), 2.20.2.5 (cmm module)
3Older Version : 2.20.4.4 (scsi module), 2.20.2.4 (cmm module) 69Older Version : 2.20.4.4 (scsi module), 2.20.2.4 (cmm module)
diff --git a/Documentation/scsi/scsi-changer.txt b/Documentation/scsi/scsi-changer.txt
new file mode 100644
index 000000000000..c132687b017a
--- /dev/null
+++ b/Documentation/scsi/scsi-changer.txt
@@ -0,0 +1,180 @@
1
2README for the SCSI media changer driver
3========================================
4
5This is a driver for SCSI Medium Changer devices, which are listed
6with "Type: Medium Changer" in /proc/scsi/scsi.
7
8This is for *real* Jukeboxes. It is *not* supported to work with
9common small CD-ROM changers, neither one-lun-per-slot SCSI changers
10nor IDE drives.
11
12Userland tools available from here:
13 http://linux.bytesex.org/misc/changer.html
14
15
16General Information
17-------------------
18
19First some words about how changers work: A changer has 2 (possibly
20more) SCSI ID's. One for the changer device which controls the robot,
21and one for the device which actually reads and writes the data. The
22later may be anything, a MOD, a CD-ROM, a tape or whatever. For the
23changer device this is a "don't care", he *only* shuffles around the
24media, nothing else.
25
26
27The SCSI changer model is complex, compared to - for example - IDE-CD
28changers. But it allows to handle nearly all possible cases. It knows
294 different types of changer elements:
30
31 media transport - this one shuffles around the media, i.e. the
32 transport arm. Also known as "picker".
33 storage - a slot which can hold a media.
34 import/export - the same as above, but is accessable from outside,
35 i.e. there the operator (you !) can use this to
36 fill in and remove media from the changer.
37 Sometimes named "mailslot".
38 data transfer - this is the device which reads/writes, i.e. the
39 CD-ROM / Tape / whatever drive.
40
41None of these is limited to one: A huge Jukebox could have slots for
42123 CD-ROM's, 5 CD-ROM readers (and therefore 6 SCSI ID's: the changer
43and each CD-ROM) and 2 transport arms. No problem to handle.
44
45
46How it is implemented
47---------------------
48
49I implemented the driver as character device driver with a NetBSD-like
50ioctl interface. Just grabbed NetBSD's header file and one of the
51other linux SCSI device drivers as starting point. The interface
52should be source code compatible with NetBSD. So if there is any
53software (anybody knows ???) which supports a BSDish changer driver,
54it should work with this driver too.
55
56Over time a few more ioctls where added, volume tag support for example
57wasn't covered by the NetBSD ioctl API.
58
59
60Current State
61-------------
62
63Support for more than one transport arm is not implemented yet (and
64nobody asked for it so far...).
65
66I test and use the driver myself with a 35 slot cdrom jukebox from
67Grundig. I got some reports telling it works ok with tape autoloaders
68(Exabyte, HP and DEC). Some People use this driver with amanda. It
69works fine with small (11 slots) and a huge (4 MOs, 88 slots)
70magneto-optical Jukebox. Probably with lots of other changers too, most
71(but not all :-) people mail me only if it does *not* work...
72
73I don't have any device lists, neither black-list nor white-list. Thus
74it is quite useless to ask me whenever a specific device is supported or
75not. In theory every changer device which supports the SCSI-2 media
76changer command set should work out-of-the-box with this driver. If it
77doesn't, it is a bug. Either within the driver or within the firmware
78of the changer device.
79
80
81Using it
82--------
83
84This is a character device with major number is 86, so use
85"mknod /dev/sch0 c 86 0" to create the special file for the driver.
86
87If the module finds the changer, it prints some messages about the
88device [ try "dmesg" if you don't see anything ] and should show up in
89/proc/devices. If not.... some changers use ID ? / LUN 0 for the
90device and ID ? / LUN 1 for the robot mechanism. But Linux does *not*
91look for LUN's other than 0 as default, becauce there are to many
92broken devices. So you can try:
93
94 1) echo "scsi add-single-device 0 0 ID 1" > /proc/scsi/scsi
95 (replace ID with the SCSI-ID of the device)
96 2) boot the kernel with "max_scsi_luns=1" on the command line
97 (append="max_scsi_luns=1" in lilo.conf should do the trick)
98
99
100Trouble?
101--------
102
103If you insmod the driver with "insmod debug=1", it will be verbose and
104prints a lot of stuff to the syslog. Compiling the kernel with
105CONFIG_SCSI_CONSTANTS=y improves the quality of the error messages alot
106because the kernel will translate the error codes into human-readable
107strings then.
108
109You can display these messages with the dmesg command (or check the
110logfiles). If you email me some question becauce of a problem with the
111driver, please include these messages.
112
113
114Insmod options
115--------------
116
117debug=0/1
118 Enable debug messages (see above, default: 0).
119
120verbose=0/1
121 Be verbose (default: 1).
122
123init=0/1
124 Send INITIALIZE ELEMENT STATUS command to the changer
125 at insmod time (default: 1).
126
127timeout_init=<seconds>
128 timeout for the INITIALIZE ELEMENT STATUS command
129 (default: 3600).
130
131timeout_move=<seconds>
132 timeout for all other commands (default: 120).
133
134dt_id=<id1>,<id2>,...
135dt_lun=<lun1>,<lun2>,...
136 These two allow to specify the SCSI ID and LUN for the data
137 transfer elements. You likely don't need this as the jukebox
138 should provide this information. But some devices don't ...
139
140vendor_firsts=
141vendor_counts=
142vendor_labels=
143 These insmod options can be used to tell the driver that there
144 are some vendor-specific element types. Grundig for example
145 does this. Some jukeboxes have a printer to label fresh burned
146 CDs, which is addressed as element 0xc000 (type 5). To tell the
147 driver about this vendor-specific element, use this:
148 $ insmod ch \
149 vendor_firsts=0xc000 \
150 vendor_counts=1 \
151 vendor_labels=printer
152 All three insmod options accept up to four comma-separated
153 values, this way you can configure the element types 5-8.
154 You likely need the SCSI specs for the device in question to
155 find the correct values as they are not covered by the SCSI-2
156 standard.
157
158
159Credits
160-------
161
162I wrote this driver using the famous mailing-patches-around-the-world
163method. With (more or less) help from:
164
165 Daniel Moehwald <moehwald@hdg.de>
166 Dane Jasper <dane@sonic.net>
167 R. Scott Bailey <sbailey@dsddi.eds.com>
168 Jonathan Corbet <corbet@lwn.net>
169
170Special thanks go to
171 Martin Kuehne <martin.kuehne@bnbt.de>
172for a old, second-hand (but full functional) cdrom jukebox which I use
173to develop/test driver and tools now.
174
175Have fun,
176
177 Gerd
178
179--
180Gerd Knorr <kraxel@bytesex.org>
diff --git a/Documentation/scsi/scsi_mid_low_api.txt b/Documentation/scsi/scsi_mid_low_api.txt
index e41703d7d24d..da176c95d0fb 100644
--- a/Documentation/scsi/scsi_mid_low_api.txt
+++ b/Documentation/scsi/scsi_mid_low_api.txt
@@ -936,8 +936,7 @@ Details:
936 * 936 *
937 * Returns SUCCESS if command aborted else FAILED 937 * Returns SUCCESS if command aborted else FAILED
938 * 938 *
939 * Locks: struct Scsi_Host::host_lock held (with irqsave) on entry 939 * Locks: None held
940 * and assumed to be held on return.
941 * 940 *
942 * Calling context: kernel thread 941 * Calling context: kernel thread
943 * 942 *
@@ -955,8 +954,7 @@ Details:
955 * 954 *
956 * Returns SUCCESS if command aborted else FAILED 955 * Returns SUCCESS if command aborted else FAILED
957 * 956 *
958 * Locks: struct Scsi_Host::host_lock held (with irqsave) on entry 957 * Locks: None held
959 * and assumed to be held on return.
960 * 958 *
961 * Calling context: kernel thread 959 * Calling context: kernel thread
962 * 960 *
@@ -974,8 +972,7 @@ Details:
974 * 972 *
975 * Returns SUCCESS if command aborted else FAILED 973 * Returns SUCCESS if command aborted else FAILED
976 * 974 *
977 * Locks: struct Scsi_Host::host_lock held (with irqsave) on entry 975 * Locks: None held
978 * and assumed to be held on return.
979 * 976 *
980 * Calling context: kernel thread 977 * Calling context: kernel thread
981 * 978 *
@@ -993,8 +990,7 @@ Details:
993 * 990 *
994 * Returns SUCCESS if command aborted else FAILED 991 * Returns SUCCESS if command aborted else FAILED
995 * 992 *
996 * Locks: struct Scsi_Host::host_lock held (with irqsave) on entry 993 * Locks: None held
997 * and assumed to be held on return.
998 * 994 *
999 * Calling context: kernel thread 995 * Calling context: kernel thread
1000 * 996 *
diff --git a/Documentation/sgi-ioc4.txt b/Documentation/sgi-ioc4.txt
new file mode 100644
index 000000000000..876c96ae38db
--- /dev/null
+++ b/Documentation/sgi-ioc4.txt
@@ -0,0 +1,45 @@
1The SGI IOC4 PCI device is a bit of a strange beast, so some notes on
2it are in order.
3
4First, even though the IOC4 performs multiple functions, such as an
5IDE controller, a serial controller, a PS/2 keyboard/mouse controller,
6and an external interrupt mechanism, it's not implemented as a
7multifunction device. The consequence of this from a software
8standpoint is that all these functions share a single IRQ, and
9they can't all register to own the same PCI device ID. To make
10matters a bit worse, some of the register blocks (and even registers
11themselves) present in IOC4 are mixed-purpose between these several
12functions, meaning that there's no clear "owning" device driver.
13
14The solution is to organize the IOC4 driver into several independent
15drivers, "ioc4", "sgiioc4", and "ioc4_serial". Note that there is no
16PS/2 controller driver as this functionality has never been wired up
17on a shipping IO card.
18
19ioc4
20====
21This is the core (or shim) driver for IOC4. It is responsible for
22initializing the basic functionality of the chip, and allocating
23the PCI resources that are shared between the IOC4 functions.
24
25This driver also provides registration functions that the other
26IOC4 drivers can call to make their presence known. Each driver
27needs to provide a probe and remove function, which are invoked
28by the core driver at appropriate times. The interface of these
29IOC4 function probe and remove operations isn't precisely the same
30as PCI device probe and remove operations, but is logically the
31same operation.
32
33sgiioc4
34=======
35This is the IDE driver for IOC4. Its name isn't very descriptive
36simply for historical reasons (it used to be the only IOC4 driver
37component). There's not much to say about it other than it hooks
38up to the ioc4 driver via the appropriate registration, probe, and
39remove functions.
40
41ioc4_serial
42===========
43This is the serial driver for IOC4. There's not much to say about it
44other than it hooks up to the ioc4 driver via the appropriate registration,
45probe, and remove functions.
diff --git a/Documentation/sound/alsa/ALSA-Configuration.txt b/Documentation/sound/alsa/ALSA-Configuration.txt
index 71ef0498d5e0..104a994b8289 100644
--- a/Documentation/sound/alsa/ALSA-Configuration.txt
+++ b/Documentation/sound/alsa/ALSA-Configuration.txt
@@ -615,9 +615,11 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
615 Module snd-hda-intel 615 Module snd-hda-intel
616 -------------------- 616 --------------------
617 617
618 Module for Intel HD Audio (ICH6, ICH6M, ICH7) 618 Module for Intel HD Audio (ICH6, ICH6M, ICH7), ATI SB450,
619 VIA VT8251/VT8237A
619 620
620 model - force the model name 621 model - force the model name
622 position_fix - Fix DMA pointer (0 = FIFO size, 1 = none, 2 = POSBUF)
621 623
622 Module supports up to 8 cards. 624 Module supports up to 8 cards.
623 625
@@ -635,6 +637,10 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
635 5stack 5-jack in back, 2-jack in front 637 5stack 5-jack in back, 2-jack in front
636 5stack-digout 5-jack in back, 2-jack in front, a SPDIF out 638 5stack-digout 5-jack in back, 2-jack in front, a SPDIF out
637 w810 3-jack 639 w810 3-jack
640 z71v 3-jack (HP shared SPDIF)
641 asus 3-jack
642 uniwill 3-jack
643 F1734 2-jack
638 644
639 CMI9880 645 CMI9880
640 minimal 3-jack in back 646 minimal 3-jack in back
@@ -642,6 +648,15 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
642 full 6-jack in back, 2-jack in front 648 full 6-jack in back, 2-jack in front
643 full_dig 6-jack in back, 2-jack in front, SPDIF I/O 649 full_dig 6-jack in back, 2-jack in front, SPDIF I/O
644 allout 5-jack in back, 2-jack in front, SPDIF out 650 allout 5-jack in back, 2-jack in front, SPDIF out
651 auto auto-config reading BIOS (default)
652
653 Note 2: If you get click noises on output, try the module option
654 position_fix=1 or 2. position_fix=1 will use the SD_LPIB
655 register value without FIFO size correction as the current
656 DMA pointer. position_fix=2 will make the driver to use
657 the position buffer instead of reading SD_LPIB register.
658 (Usually SD_LPLIB register is more accurate than the
659 position buffer.)
645 660
646 Module snd-hdsp 661 Module snd-hdsp
647 --------------- 662 ---------------
@@ -660,7 +675,19 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
660 module did formerly. It will allocate the buffers in advance 675 module did formerly. It will allocate the buffers in advance
661 when any HDSP cards are found. To make the buffer 676 when any HDSP cards are found. To make the buffer
662 allocation sure, load snd-page-alloc module in the early 677 allocation sure, load snd-page-alloc module in the early
663 stage of boot sequence. 678 stage of boot sequence. See "Early Buffer Allocation"
679 section.
680
681 Module snd-hdspm
682 ----------------
683
684 Module for RME HDSP MADI board.
685
686 precise_ptr - Enable precise pointer, or disable.
687 line_outs_monitor - Send playback streams to analog outs by default.
688 enable_monitor - Enable Analog Out on Channel 63/64 by default.
689
690 See hdspm.txt for details.
664 691
665 Module snd-ice1712 692 Module snd-ice1712
666 ------------------ 693 ------------------
@@ -677,15 +704,19 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
677 * TerraTec EWS 88D 704 * TerraTec EWS 88D
678 * TerraTec EWX 24/96 705 * TerraTec EWX 24/96
679 * TerraTec DMX 6Fire 706 * TerraTec DMX 6Fire
707 * TerraTec Phase 88
680 * Hoontech SoundTrack DSP 24 708 * Hoontech SoundTrack DSP 24
681 * Hoontech SoundTrack DSP 24 Value 709 * Hoontech SoundTrack DSP 24 Value
682 * Hoontech SoundTrack DSP 24 Media 7.1 710 * Hoontech SoundTrack DSP 24 Media 7.1
711 * Event Electronics, EZ8
683 * Digigram VX442 712 * Digigram VX442
713 * Lionstracs, Mediastaton
684 714
685 model - Use the given board model, one of the following: 715 model - Use the given board model, one of the following:
686 delta1010, dio2496, delta66, delta44, audiophile, delta410, 716 delta1010, dio2496, delta66, delta44, audiophile, delta410,
687 delta1010lt, vx442, ewx2496, ews88mt, ews88mt_new, ews88d, 717 delta1010lt, vx442, ewx2496, ews88mt, ews88mt_new, ews88d,
688 dmx6fire, dsp24, dsp24_value, dsp24_71, ez8 718 dmx6fire, dsp24, dsp24_value, dsp24_71, ez8,
719 phase88, mediastation
689 omni - Omni I/O support for MidiMan M-Audio Delta44/66 720 omni - Omni I/O support for MidiMan M-Audio Delta44/66
690 cs8427_timeout - reset timeout for the CS8427 chip (S/PDIF transciever) 721 cs8427_timeout - reset timeout for the CS8427 chip (S/PDIF transciever)
691 in msec resolution, default value is 500 (0.5 sec) 722 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.
694 is not used with all Envy24 based cards (for example in the MidiMan Delta 725 is not used with all Envy24 based cards (for example in the MidiMan Delta
695 serie). 726 serie).
696 727
728 Note: The supported board is detected by reading EEPROM or PCI
729 SSID (if EEPROM isn't available). You can override the
730 model by passing "model" module option in case that the
731 driver isn't configured properly or you want to try another
732 type for testing.
733
697 Module snd-ice1724 734 Module snd-ice1724
698 ------------------ 735 ------------------
699 736
700 Module for Envy24HT (VT/ICE1724) based PCI sound cards. 737 Module for Envy24HT (VT/ICE1724), Envy24PT (VT1720) based PCI sound cards.
701 * MidiMan M Audio Revolution 7.1 738 * MidiMan M Audio Revolution 7.1
702 * AMP Ltd AUDIO2000 739 * AMP Ltd AUDIO2000
703 * TerraTec Aureon Sky-5.1, Space-7.1 740 * TerraTec Aureon 5.1 Sky
741 * TerraTec Aureon 7.1 Space
742 * TerraTec Aureon 7.1 Universe
743 * TerraTec Phase 22
744 * TerraTec Phase 28
745 * AudioTrak Prodigy 7.1
746 * AudioTrak Prodigy 192
747 * Pontis MS300
748 * Albatron K8X800 Pro II
749 * Chaintech ZNF3-150
750 * Chaintech ZNF3-250
751 * Chaintech 9CJS
752 * Chaintech AV-710
753 * Shuttle SN25P
704 754
705 model - Use the given board model, one of the following: 755 model - Use the given board model, one of the following:
706 revo71, amp2000, prodigy71, aureon51, aureon71, 756 revo71, amp2000, prodigy71, prodigy192, aureon51,
707 k8x800 757 aureon71, universe, k8x800, phase22, phase28, ms300,
758 av710
708 759
709 Module supports up to 8 cards and autoprobe. 760 Module supports up to 8 cards and autoprobe.
710 761
762 Note: The supported board is detected by reading EEPROM or PCI
763 SSID (if EEPROM isn't available). You can override the
764 model by passing "model" module option in case that the
765 driver isn't configured properly or you want to try another
766 type for testing.
767
711 Module snd-intel8x0 768 Module snd-intel8x0
712 ------------------- 769 -------------------
713 770
@@ -1026,7 +1083,8 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
1026 module did formerly. It will allocate the buffers in advance 1083 module did formerly. It will allocate the buffers in advance
1027 when any RME9652 cards are found. To make the buffer 1084 when any RME9652 cards are found. To make the buffer
1028 allocation sure, load snd-page-alloc module in the early 1085 allocation sure, load snd-page-alloc module in the early
1029 stage of boot sequence. 1086 stage of boot sequence. See "Early Buffer Allocation"
1087 section.
1030 1088
1031 Module snd-sa11xx-uda1341 (on arm only) 1089 Module snd-sa11xx-uda1341 (on arm only)
1032 --------------------------------------- 1090 ---------------------------------------
@@ -1211,16 +1269,18 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
1211 ------------------ 1269 ------------------
1212 1270
1213 Module for AC'97 motherboards based on VIA 82C686A/686B, 8233, 1271 Module for AC'97 motherboards based on VIA 82C686A/686B, 8233,
1214 8233A, 8233C, 8235 (south) bridge. 1272 8233A, 8233C, 8235, 8237 (south) bridge.
1215 1273
1216 mpu_port - 0x300,0x310,0x320,0x330, otherwise obtain BIOS setup 1274 mpu_port - 0x300,0x310,0x320,0x330, otherwise obtain BIOS setup
1217 [VIA686A/686B only] 1275 [VIA686A/686B only]
1218 joystick - Enable joystick (default off) [VIA686A/686B only] 1276 joystick - Enable joystick (default off) [VIA686A/686B only]
1219 ac97_clock - AC'97 codec clock base (default 48000Hz) 1277 ac97_clock - AC'97 codec clock base (default 48000Hz)
1220 dxs_support - support DXS channels, 1278 dxs_support - support DXS channels,
1221 0 = auto (defalut), 1 = enable, 2 = disable, 1279 0 = auto (default), 1 = enable, 2 = disable,
1222 3 = 48k only, 4 = no VRA 1280 3 = 48k only, 4 = no VRA, 5 = enable any sample
1223 [VIA8233/C,8235 only] 1281 rate and different sample rates on different
1282 channels
1283 [VIA8233/C, 8235, 8237 only]
1224 ac97_quirk - AC'97 workaround for strange hardware 1284 ac97_quirk - AC'97 workaround for strange hardware
1225 See the description of intel8x0 module for details. 1285 See the description of intel8x0 module for details.
1226 1286
@@ -1232,18 +1292,23 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
1232 default value 1.4. Then the interrupt number will be 1292 default value 1.4. Then the interrupt number will be
1233 assigned under 15. You might also upgrade your BIOS. 1293 assigned under 15. You might also upgrade your BIOS.
1234 1294
1235 Note: VIA8233/5 (not VIA8233A) can support DXS (direct sound) 1295 Note: VIA8233/5/7 (not VIA8233A) can support DXS (direct sound)
1236 channels as the first PCM. On these channels, up to 4 1296 channels as the first PCM. On these channels, up to 4
1237 streams can be played at the same time. 1297 streams can be played at the same time, and the controller
1298 can perform sample rate conversion with separate rates for
1299 each channel.
1238 As default (dxs_support = 0), 48k fixed rate is chosen 1300 As default (dxs_support = 0), 48k fixed rate is chosen
1239 except for the known devices since the output is often 1301 except for the known devices since the output is often
1240 noisy except for 48k on some mother boards due to the 1302 noisy except for 48k on some mother boards due to the
1241 bug of BIOS. 1303 bug of BIOS.
1242 Please try once dxs_support=1 and if it works on other 1304 Please try once dxs_support=5 and if it works on other
1243 sample rates (e.g. 44.1kHz of mp3 playback), please let us 1305 sample rates (e.g. 44.1kHz of mp3 playback), please let us
1244 know the PCI subsystem vendor/device id's (output of 1306 know the PCI subsystem vendor/device id's (output of
1245 "lspci -nv"). 1307 "lspci -nv").
1246 If it doesn't work, try dxs_support=4. If it still doesn't 1308 If dxs_support=5 does not work, try dxs_support=4; if it
1309 doesn't work too, try dxs_support=1. (dxs_support=1 is
1310 usually for old motherboards. The correct implementated
1311 board should work with 4 or 5.) If it still doesn't
1247 work and the default setting is ok, dxs_support=3 is the 1312 work and the default setting is ok, dxs_support=3 is the
1248 right choice. If the default setting doesn't work at all, 1313 right choice. If the default setting doesn't work at all,
1249 try dxs_support=2 to disable the DXS channels. 1314 try dxs_support=2 to disable the DXS channels.
@@ -1497,6 +1562,36 @@ Proc interfaces (/proc/asound)
1497 echo "rvplayer 0 0 block" > /proc/asound/card0/pcm0p/oss 1562 echo "rvplayer 0 0 block" > /proc/asound/card0/pcm0p/oss
1498 1563
1499 1564
1565Early Buffer Allocation
1566=======================
1567
1568Some drivers (e.g. hdsp) require the large contiguous buffers, and
1569sometimes it's too late to find such spaces when the driver module is
1570actually loaded due to memory fragmentation. You can pre-allocate the
1571PCM buffers by loading snd-page-alloc module and write commands to its
1572proc file in prior, for example, in the early boot stage like
1573/etc/init.d/*.local scripts.
1574
1575Reading the proc file /proc/drivers/snd-page-alloc shows the current
1576usage of page allocation. In writing, you can send the following
1577commands to the snd-page-alloc driver:
1578
1579 - add VENDOR DEVICE MASK SIZE BUFFERS
1580
1581 VENDOR and DEVICE are PCI vendor and device IDs. They take
1582 integer numbers (0x prefix is needed for the hex).
1583 MASK is the PCI DMA mask. Pass 0 if not restricted.
1584 SIZE is the size of each buffer to allocate. You can pass
1585 k and m suffix for KB and MB. The max number is 16MB.
1586 BUFFERS is the number of buffers to allocate. It must be greater
1587 than 0. The max number is 4.
1588
1589 - erase
1590
1591 This will erase the all pre-allocated buffers which are not in
1592 use.
1593
1594
1500Links 1595Links
1501===== 1596=====
1502 1597
diff --git a/Documentation/sound/alsa/CMIPCI.txt b/Documentation/sound/alsa/CMIPCI.txt
index 4a7df771b806..1872e24442a4 100644
--- a/Documentation/sound/alsa/CMIPCI.txt
+++ b/Documentation/sound/alsa/CMIPCI.txt
@@ -89,19 +89,22 @@ and use the interleaved 4 channel data.
89 89
90There are some control switchs affecting to the speaker connections: 90There are some control switchs affecting to the speaker connections:
91 91
92"Line-In As Rear" - As mentioned above, the line-in jack is used 92"Line-In Mode" - an enum control to change the behavior of line-in
93 for the rear (3th and 4th channels) output. 93 jack. Either "Line-In", "Rear Output" or "Bass Output" can
94"Line-In As Bass" - The line-in jack is used for the bass (5th 94 be selected. The last item is available only with model 039
95 and 6th channels) output. 95 or newer.
96"Mic As Center/LFE" - The mic jack is used for the bass output. 96 When "Rear Output" is chosen, the surround channels 3 and 4
97 If this switch is on, you cannot use a microphone as a capture 97 are output to line-in jack.
98 source, of course. 98"Mic-In Mode" - an enum control to change the behavior of mic-in
99 99 jack. Either "Mic-In" or "Center/LFE Output" can be
100 selected.
101 When "Center/LFE Output" is chosen, the center and bass
102 channels (channels 5 and 6) are output to mic-in jack.
100 103
101Digital I/O 104Digital I/O
102----------- 105-----------
103 106
104The CM8x38 provides the excellent SPDIF capability with very chip 107The CM8x38 provides the excellent SPDIF capability with very cheap
105price (yes, that's the reason I bought the card :) 108price (yes, that's the reason I bought the card :)
106 109
107The SPDIF playback and capture are done via the third PCM device 110The 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
122simultaneously. 125simultaneously.
123 126
124To enable SPDIF output, you need to turn on "IEC958 Output Switch" 127To enable SPDIF output, you need to turn on "IEC958 Output Switch"
125control via mixer or alsactl. Then you'll see the red light on from 128control via mixer or alsactl ("IEC958" is the official name of
126the card so you know that's working obviously :) 129so-called S/PDIF). Then you'll see the red light on from the card so
130you know that's working obviously :)
127The SPDIF input is always enabled, so you can hear SPDIF input data 131The SPDIF input is always enabled, so you can hear SPDIF input data
128from line-out with "IEC958 In Monitor" switch at any time (see 132from line-out with "IEC958 In Monitor" switch at any time (see
129below). 133below).
@@ -205,9 +209,10 @@ In addition to the standard SB mixer, CM8x38 provides more functions.
205MIDI CONTROLLER 209MIDI CONTROLLER
206--------------- 210---------------
207 211
208The MPU401-UART interface is enabled as default only for the first 212The MPU401-UART interface is disabled as default. You need to set
209(CMIPCI) card. You need to set module option "midi_port" properly 213module option "mpu_port" with a valid I/O port address to enable the
210for the 2nd (CMIPCI) card. 214MIDI support. The valid I/O ports are 0x300, 0x310, 0x320 and 0x330.
215Choose the value which doesn't conflict with other cards.
211 216
212There is _no_ hardware wavetable function on this chip (except for 217There is _no_ hardware wavetable function on this chip (except for
213OPL3 synth below). 218OPL3 synth below).
@@ -229,9 +234,11 @@ I don't know why..
229Joystick and Modem 234Joystick and Modem
230------------------ 235------------------
231 236
232The joystick and modem should be available by enabling the control 237The legacy joystick is supported. To enable the joystick support, pass
233switch "Joystick" and "Modem" respectively. But I myself have never 238joystick_port=1 module option. The value 1 means the auto-detection.
234tested them yet. 239If the auto-detection fails, try to pass the exact I/O address.
240
241The modem is enabled dynamically via a card control switch "Modem".
235 242
236 243
237Debugging Information 244Debugging Information
diff --git a/Documentation/sound/alsa/DocBook/writing-an-alsa-driver.tmpl b/Documentation/sound/alsa/DocBook/writing-an-alsa-driver.tmpl
index e789475304b6..db0b7d2dc477 100644
--- a/Documentation/sound/alsa/DocBook/writing-an-alsa-driver.tmpl
+++ b/Documentation/sound/alsa/DocBook/writing-an-alsa-driver.tmpl
@@ -371,7 +371,7 @@
371 <listitem><para>create <function>probe()</function> callback.</para></listitem> 371 <listitem><para>create <function>probe()</function> callback.</para></listitem>
372 <listitem><para>create <function>remove()</function> callback.</para></listitem> 372 <listitem><para>create <function>remove()</function> callback.</para></listitem>
373 <listitem><para>create pci_driver table which contains the three pointers above.</para></listitem> 373 <listitem><para>create pci_driver table which contains the three pointers above.</para></listitem>
374 <listitem><para>create <function>init()</function> function just calling <function>pci_module_init()</function> to register the pci_driver table defined above.</para></listitem> 374 <listitem><para>create <function>init()</function> function just calling <function>pci_register_driver()</function> to register the pci_driver table defined above.</para></listitem>
375 <listitem><para>create <function>exit()</function> function to call <function>pci_unregister_driver()</function> function.</para></listitem> 375 <listitem><para>create <function>exit()</function> function to call <function>pci_unregister_driver()</function> function.</para></listitem>
376 </itemizedlist> 376 </itemizedlist>
377 </para> 377 </para>
@@ -1198,7 +1198,7 @@
1198 /* initialization of the module */ 1198 /* initialization of the module */
1199 static int __init alsa_card_mychip_init(void) 1199 static int __init alsa_card_mychip_init(void)
1200 { 1200 {
1201 return pci_module_init(&driver); 1201 return pci_register_driver(&driver);
1202 } 1202 }
1203 1203
1204 /* clean up the module */ 1204 /* clean up the module */
@@ -1654,7 +1654,7 @@
1654<![CDATA[ 1654<![CDATA[
1655 static int __init alsa_card_mychip_init(void) 1655 static int __init alsa_card_mychip_init(void)
1656 { 1656 {
1657 return pci_module_init(&driver); 1657 return pci_register_driver(&driver);
1658 } 1658 }
1659 1659
1660 static void __exit alsa_card_mychip_exit(void) 1660 static void __exit alsa_card_mychip_exit(void)
diff --git a/Documentation/sound/alsa/emu10k1-jack.txt b/Documentation/sound/alsa/emu10k1-jack.txt
new file mode 100644
index 000000000000..751d45036a05
--- /dev/null
+++ b/Documentation/sound/alsa/emu10k1-jack.txt
@@ -0,0 +1,74 @@
1This document is a guide to using the emu10k1 based devices with JACK for low
2latency, multichannel recording functionality. All of my recent work to allow
3Linux users to use the full capabilities of their hardware has been inspired
4by the kX Project. Without their work I never would have discovered the true
5power of this hardware.
6
7 http://www.kxproject.com
8 - Lee Revell, 2005.03.30
9
10Low latency, multichannel audio with JACK and the emu10k1/emu10k2
11-----------------------------------------------------------------
12
13Until recently, emu10k1 users on Linux did not have access to the same low
14latency, multichannel features offered by the "kX ASIO" feature of their
15Windows driver. As of ALSA 1.0.9 this is no more!
16
17For those unfamiliar with kX ASIO, this consists of 16 capture and 16 playback
18channels. With a post 2.6.9 Linux kernel, latencies down to 64 (1.33 ms) or
19even 32 (0.66ms) frames should work well.
20
21The configuration is slightly more involved than on Windows, as you have to
22select the correct device for JACK to use. Actually, for qjackctl users it's
23fairly self explanatory - select Duplex, then for capture and playback select
24the multichannel devices, set the in and out channels to 16, and the sample
25rate to 48000Hz. The command line looks like this:
26
27/usr/local/bin/jackd -R -dalsa -r48000 -p64 -n2 -D -Chw:0,2 -Phw:0,3 -S
28
29This will give you 16 input ports and 16 output ports.
30
31The 16 output ports map onto the 16 FX buses (or the first 16 of 64, for the
32Audigy). The mapping from FX bus to physical output is described in
33SB-Live-mixer.txt (or Audigy-mixer.txt).
34
35The 16 input ports are connected to the 16 physical inputs. Contrary to
36popular belief, all emu10k1 cards are multichannel cards. Which of these
37input channels have physical inputs connected to them depends on the card
38model. Trial and error is highly recommended; the pinout diagrams
39for the card have been reverse engineered by some enterprising kX users and are
40available on the internet. Meterbridge is helpful here, and the kX forums are
41packed with useful information.
42
43Each input port will either correspond to a digital (SPDIF) input, an analog
44input, or nothing. The one exception is the SBLive! 5.1. On these devices,
45the second and third input ports are wired to the center/LFE output. You will
46still see 16 capture channels, but only 14 are available for recording inputs.
47
48This chart, borrowed from kxfxlib/da_asio51.cpp, describes the mapping of JACK
49ports to FXBUS2 (multitrack recording input) and EXTOUT (physical output)
50channels.
51
52/*JACK (& ASIO) mappings on 10k1 5.1 SBLive cards:
53--------------------------------------------
54JACK Epilog FXBUS2(nr)
55--------------------------------------------
56capture_1 asio14 FXBUS2(0xe)
57capture_2 asio15 FXBUS2(0xf)
58capture_3 asio0 FXBUS2(0x0)
59~capture_4 Center EXTOUT(0x11) // mapped to by Center
60~capture_5 LFE EXTOUT(0x12) // mapped to by LFE
61capture_6 asio3 FXBUS2(0x3)
62capture_7 asio4 FXBUS2(0x4)
63capture_8 asio5 FXBUS2(0x5)
64capture_9 asio6 FXBUS2(0x6)
65capture_10 asio7 FXBUS2(0x7)
66capture_11 asio8 FXBUS2(0x8)
67capture_12 asio9 FXBUS2(0x9)
68capture_13 asio10 FXBUS2(0xa)
69capture_14 asio11 FXBUS2(0xb)
70capture_15 asio12 FXBUS2(0xc)
71capture_16 asio13 FXBUS2(0xd)
72*/
73
74TODO: describe use of ld10k1/qlo10k1 in conjunction with JACK
diff --git a/Documentation/sound/alsa/hdspm.txt b/Documentation/sound/alsa/hdspm.txt
new file mode 100644
index 000000000000..7a67ff71a9f8
--- /dev/null
+++ b/Documentation/sound/alsa/hdspm.txt
@@ -0,0 +1,362 @@
1Software Interface ALSA-DSP MADI Driver
2
3(translated from German, so no good English ;-),
42004 - winfried ritsch
5
6
7
8 Full functionality has been added to the driver. Since some of
9 the Controls and startup-options are ALSA-Standard and only the
10 special Controls are described and discussed below.
11
12
13 hardware functionality:
14
15
16 Audio transmission:
17
18 number of channels -- depends on transmission mode
19
20 The number of channels chosen is from 1..Nmax. The reason to
21 use for a lower number of channels is only resource allocation,
22 since unused DMA channels are disabled and less memory is
23 allocated. So also the throughput of the PCI system can be
24 scaled. (Only important for low performance boards).
25
26 Single Speed -- 1..64 channels
27
28 (Note: Choosing the 56channel mode for transmission or as
29 receiver, only 56 are transmitted/received over the MADI, but
30 all 64 channels are available for the mixer, so channel count
31 for the driver)
32
33 Double Speed -- 1..32 channels
34
35 Note: Choosing the 56-channel mode for
36 transmission/receive-mode , only 28 are transmitted/received
37 over the MADI, but all 32 channels are available for the mixer,
38 so channel count for the driver
39
40
41 Quad Speed -- 1..16 channels
42
43 Note: Choosing the 56-channel mode for
44 transmission/receive-mode , only 14 are transmitted/received
45 over the MADI, but all 16 channels are available for the mixer,
46 so channel count for the driver
47
48 Format -- signed 32 Bit Little Endian (SNDRV_PCM_FMTBIT_S32_LE)
49
50 Sample Rates --
51
52 Single Speed -- 32000, 44100, 48000
53
54 Double Speed -- 64000, 88200, 96000 (untested)
55
56 Quad Speed -- 128000, 176400, 192000 (untested)
57
58 access-mode -- MMAP (memory mapped), Not interleaved
59 (PCM_NON-INTERLEAVED)
60
61 buffer-sizes -- 64,128,256,512,1024,2048,8192 Samples
62
63 fragments -- 2
64
65 Hardware-pointer -- 2 Modi
66
67
68 The Card supports the readout of the actual Buffer-pointer,
69 where DMA reads/writes. Since of the bulk mode of PCI it is only
70 64 Byte accurate. SO it is not really usable for the
71 ALSA-mid-level functions (here the buffer-ID gives a better
72 result), but if MMAP is used by the application. Therefore it
73 can be configured at load-time with the parameter
74 precise-pointer.
75
76
77 (Hint: Experimenting I found that the pointer is maximum 64 to
78 large never to small. So if you subtract 64 you always have a
79 safe pointer for writing, which is used on this mode inside
80 ALSA. In theory now you can get now a latency as low as 16
81 Samples, which is a quarter of the interrupt possibilities.)
82
83 Precise Pointer -- off
84 interrupt used for pointer-calculation
85
86 Precise Pointer -- on
87 hardware pointer used.
88
89 Controller:
90
91
92 Since DSP-MADI-Mixer has 8152 Fader, it does not make sense to
93 use the standard mixer-controls, since this would break most of
94 (especially graphic) ALSA-Mixer GUIs. So Mixer control has be
95 provided by a 2-dimensional controller using the
96 hwdep-interface.
97
98 Also all 128+256 Peak and RMS-Meter can be accessed via the
99 hwdep-interface. Since it could be a performance problem always
100 copying and converting Peak and RMS-Levels even if you just need
101 one, I decided to export the hardware structure, so that of
102 needed some driver-guru can implement a memory-mapping of mixer
103 or peak-meters over ioctl, or also to do only copying and no
104 conversion. A test-application shows the usage of the controller.
105
106 Latency Controls --- not implemented !!!
107
108
109 Note: Within the windows-driver the latency is accessible of a
110 control-panel, but buffer-sizes are controlled with ALSA from
111 hwparams-calls and should not be changed in run-state, I did not
112 implement it here.
113
114
115 System Clock -- suspended !!!!
116
117 Name -- "System Clock Mode"
118
119 Access -- Read Write
120
121 Values -- "Master" "Slave"
122
123
124 !!!! This is a hardware-function but is in conflict with the
125 Clock-source controller, which is a kind of ALSA-standard. I
126 makes sense to set the card to a special mode (master at some
127 frequency or slave), since even not using an Audio-application
128 a studio should have working synchronisations setup. So use
129 Clock-source-controller instead !!!!
130
131 Clock Source
132
133 Name -- "Sample Clock Source"
134
135 Access -- Read Write
136
137 Values -- "AutoSync", "Internal 32.0 kHz", "Internal 44.1 kHz",
138 "Internal 48.0 kHz", "Internal 64.0 kHz", "Internal 88.2 kHz",
139 "Internal 96.0 kHz"
140
141 Choose between Master at a specific Frequency and so also the
142 Speed-mode or Slave (Autosync). Also see "Preferred Sync Ref"
143
144
145 !!!! This is no pure hardware function but was implemented by
146 ALSA by some ALSA-drivers before, so I use it also. !!!
147
148
149 Preferred Sync Ref
150
151 Name -- "Preferred Sync Reference"
152
153 Access -- Read Write
154
155 Values -- "Word" "MADI"
156
157
158 Within the Auto-sync-Mode the preferred Sync Source can be
159 chosen. If it is not available another is used if possible.
160
161 Note: Since MADI has a much higher bit-rate than word-clock, the
162 card should synchronise better in MADI Mode. But since the
163 RME-PLL is very good, there are almost no problems with
164 word-clock too. I never found a difference.
165
166
167 TX 64 channel ---
168
169 Name -- "TX 64 channels mode"
170
171 Access -- Read Write
172
173 Values -- 0 1
174
175 Using 64-channel-modus (1) or 56-channel-modus for
176 MADI-transmission (0).
177
178
179 Note: This control is for output only. Input-mode is detected
180 automatically from hardware sending MADI.
181
182
183 Clear TMS ---
184
185 Name -- "Clear Track Marker"
186
187 Access -- Read Write
188
189 Values -- 0 1
190
191
192 Don't use to lower 5 Audio-bits on AES as additional Bits.
193
194
195 Safe Mode oder Auto Input ---
196
197 Name -- "Safe Mode"
198
199 Access -- Read Write
200
201 Values -- 0 1
202
203 (default on)
204
205 If on (1), then if either the optical or coaxial connection
206 has a failure, there is a takeover to the working one, with no
207 sample failure. Its only useful if you use the second as a
208 backup connection.
209
210 Input ---
211
212 Name -- "Input Select"
213
214 Access -- Read Write
215
216 Values -- optical coaxial
217
218
219 Choosing the Input, optical or coaxial. If Safe-mode is active,
220 this is the preferred Input.
221
222-------------- Mixer ----------------------
223
224 Mixer
225
226 Name -- "Mixer"
227
228 Access -- Read Write
229
230 Values - <channel-number 0-127> <Value 0-65535>
231
232
233 Here as a first value the channel-index is taken to get/set the
234 corresponding mixer channel, where 0-63 are the input to output
235 fader and 64-127 the playback to outputs fader. Value 0
236 is channel muted 0 and 32768 an amplification of 1.
237
238 Chn 1-64
239
240 fast mixer for the ALSA-mixer utils. The diagonal of the
241 mixer-matrix is implemented from playback to output.
242
243
244 Line Out
245
246 Name -- "Line Out"
247
248 Access -- Read Write
249
250 Values -- 0 1
251
252 Switching on and off the analog out, which has nothing to do
253 with mixing or routing. the analog outs reflects channel 63,64.
254
255
256--- information (only read access):
257
258 Sample Rate
259
260 Name -- "System Sample Rate"
261
262 Access -- Read-only
263
264 getting the sample rate.
265
266
267 External Rate measured
268
269 Name -- "External Rate"
270
271 Access -- Read only
272
273
274 Should be "Autosync Rate", but Name used is
275 ALSA-Scheme. External Sample frequency liked used on Autosync is
276 reported.
277
278
279 MADI Sync Status
280
281 Name -- "MADI Sync Lock Status"
282
283 Access -- Read
284
285 Values -- 0,1,2
286
287 MADI-Input is 0=Unlocked, 1=Locked, or 2=Synced.
288
289
290 Word Clock Sync Status
291
292 Name -- "Word Clock Lock Status"
293
294 Access -- Read
295
296 Values -- 0,1,2
297
298 Word Clock Input is 0=Unlocked, 1=Locked, or 2=Synced.
299
300 AutoSync
301
302 Name -- "AutoSync Reference"
303
304 Access -- Read
305
306 Values -- "WordClock", "MADI", "None"
307
308 Sync-Reference is either "WordClock", "MADI" or none.
309
310 RX 64ch --- noch nicht implementiert
311
312 MADI-Receiver is in 64 channel mode oder 56 channel mode.
313
314
315 AB_inp --- not tested
316
317 Used input for Auto-Input.
318
319
320 actual Buffer Position --- not implemented
321
322 !!! this is a ALSA internal function, so no control is used !!!
323
324
325
326Calling Parameter:
327
328 index int array (min = 1, max = 8),
329 "Index value for RME HDSPM interface." card-index within ALSA
330
331 note: ALSA-standard
332
333 id string array (min = 1, max = 8),
334 "ID string for RME HDSPM interface."
335
336 note: ALSA-standard
337
338 enable int array (min = 1, max = 8),
339 "Enable/disable specific HDSPM sound-cards."
340
341 note: ALSA-standard
342
343 precise_ptr int array (min = 1, max = 8),
344 "Enable precise pointer, or disable."
345
346 note: Use only when the application supports this (which is a special case).
347
348 line_outs_monitor int array (min = 1, max = 8),
349 "Send playback streams to analog outs by default."
350
351
352 note: each playback channel is mixed to the same numbered output
353 channel (routed). This is against the ALSA-convention, where all
354 channels have to be muted on after loading the driver, but was
355 used before on other cards, so i historically use it again)
356
357
358
359 enable_monitor int array (min = 1, max = 8),
360 "Enable Analog Out on Channel 63/64 by default."
361
362 note: here the analog output is enabled (but not routed). \ No newline at end of file
diff --git a/Documentation/sysctl/kernel.txt b/Documentation/sysctl/kernel.txt
index 35159176997b..9f11d36a8c10 100644
--- a/Documentation/sysctl/kernel.txt
+++ b/Documentation/sysctl/kernel.txt
@@ -49,6 +49,7 @@ show up in /proc/sys/kernel:
49- shmmax [ sysv ipc ] 49- shmmax [ sysv ipc ]
50- shmmni 50- shmmni
51- stop-a [ SPARC only ] 51- stop-a [ SPARC only ]
52- suid_dumpable
52- sysrq ==> Documentation/sysrq.txt 53- sysrq ==> Documentation/sysrq.txt
53- tainted 54- tainted
54- threads-max 55- threads-max
@@ -300,6 +301,25 @@ kernel. This value defaults to SHMMAX.
300 301
301============================================================== 302==============================================================
302 303
304suid_dumpable:
305
306This value can be used to query and set the core dump mode for setuid
307or otherwise protected/tainted binaries. The modes are
308
3090 - (default) - traditional behaviour. Any process which has changed
310 privilege levels or is execute only will not be dumped
3111 - (debug) - all processes dump core when possible. The core dump is
312 owned by the current user and no security is applied. This is
313 intended for system debugging situations only. Ptrace is unchecked.
3142 - (suidsafe) - any binary which normally would not be dumped is dumped
315 readable by root only. This allows the end user to remove
316 such a dump but not access it directly. For security reasons
317 core dumps in this mode will not overwrite one another or
318 other files. This mode is appropriate when adminstrators are
319 attempting to debug problems in a normal environment.
320
321==============================================================
322
303tainted: 323tainted:
304 324
305Non-zero if the kernel has been tainted. Numeric values, which 325Non-zero if the kernel has been tainted. Numeric values, which
diff --git a/Documentation/sysrq.txt b/Documentation/sysrq.txt
index f98c2e31c143..136d817c01ba 100644
--- a/Documentation/sysrq.txt
+++ b/Documentation/sysrq.txt
@@ -72,6 +72,8 @@ On all - write a character to /proc/sysrq-trigger. eg:
72'b' - Will immediately reboot the system without syncing or unmounting 72'b' - Will immediately reboot the system without syncing or unmounting
73 your disks. 73 your disks.
74 74
75'c' - Will perform a kexec reboot in order to take a crashdump.
76
75'o' - Will shut your system off (if configured and supported). 77'o' - Will shut your system off (if configured and supported).
76 78
77's' - Will attempt to sync all mounted filesystems. 79's' - Will attempt to sync all mounted filesystems.
@@ -122,6 +124,9 @@ useful when you want to exit a program that will not let you switch consoles.
122re'B'oot is good when you're unable to shut down. But you should also 'S'ync 124re'B'oot is good when you're unable to shut down. But you should also 'S'ync
123and 'U'mount first. 125and 'U'mount first.
124 126
127'C'rashdump can be used to manually trigger a crashdump when the system is hung.
128The kernel needs to have been built with CONFIG_KEXEC enabled.
129
125'S'ync is great when your system is locked up, it allows you to sync your 130'S'ync is great when your system is locked up, it allows you to sync your
126disks and will certainly lessen the chance of data loss and fscking. Note 131disks and will certainly lessen the chance of data loss and fscking. Note
127that the sync hasn't taken place until you see the "OK" and "Done" appear 132that the sync hasn't taken place until you see the "OK" and "Done" appear
diff --git a/Documentation/tty.txt b/Documentation/tty.txt
index 3958cf746dde..8ff7bc2a0811 100644
--- a/Documentation/tty.txt
+++ b/Documentation/tty.txt
@@ -22,7 +22,7 @@ copy of the structure. You must not re-register over the top of the line
22discipline even with the same data or your computer again will be eaten by 22discipline even with the same data or your computer again will be eaten by
23demons. 23demons.
24 24
25In order to remove a line discipline call tty_register_ldisc passing NULL. 25In order to remove a line discipline call tty_unregister_ldisc().
26In ancient times this always worked. In modern times the function will 26In ancient times this always worked. In modern times the function will
27return -EBUSY if the ldisc is currently in use. Since the ldisc referencing 27return -EBUSY if the ldisc is currently in use. Since the ldisc referencing
28code manages the module counts this should not usually be a concern. 28code manages the module counts this should not usually be a concern.
diff --git a/Documentation/video4linux/CARDLIST.bttv b/Documentation/video4linux/CARDLIST.bttv
index e46761c39e3f..aeeafec0594c 100644
--- a/Documentation/video4linux/CARDLIST.bttv
+++ b/Documentation/video4linux/CARDLIST.bttv
@@ -119,3 +119,17 @@ card=117 - NGS NGSTV+
119card=118 - LMLBT4 119card=118 - LMLBT4
120card=119 - Tekram M205 PRO 120card=119 - Tekram M205 PRO
121card=120 - Conceptronic CONTVFMi 121card=120 - Conceptronic CONTVFMi
122card=121 - Euresys Picolo Tetra
123card=122 - Spirit TV Tuner
124card=123 - AVerMedia AVerTV DVB-T 771
125card=124 - AverMedia AverTV DVB-T 761
126card=125 - MATRIX Vision Sigma-SQ
127card=126 - MATRIX Vision Sigma-SLC
128card=127 - APAC Viewcomp 878(AMAX)
129card=128 - DVICO FusionHDTV DVB-T Lite
130card=129 - V-Gear MyVCD
131card=130 - Super TV Tuner
132card=131 - Tibet Systems 'Progress DVR' CS16
133card=132 - Kodicom 4400R (master)
134card=133 - Kodicom 4400R (slave)
135card=134 - Adlink RTV24
diff --git a/Documentation/video4linux/CARDLIST.cx88 b/Documentation/video4linux/CARDLIST.cx88
new file mode 100644
index 000000000000..216f705495cc
--- /dev/null
+++ b/Documentation/video4linux/CARDLIST.cx88
@@ -0,0 +1,29 @@
1card=0 - UNKNOWN/GENERIC
2card=1 - Hauppauge WinTV 34xxx models
3card=2 - GDI Black Gold
4card=3 - PixelView
5card=4 - ATI TV Wonder Pro
6card=5 - Leadtek Winfast 2000XP Expert
7card=6 - AverTV Studio 303 (M126)
8card=7 - MSI TV-@nywhere Master
9card=8 - Leadtek Winfast DV2000
10card=9 - Leadtek PVR 2000
11card=10 - IODATA GV-VCP3/PCI
12card=11 - Prolink PlayTV PVR
13card=12 - ASUS PVR-416
14card=13 - MSI TV-@nywhere
15card=14 - KWorld/VStream XPert DVB-T
16card=15 - DVICO FusionHDTV DVB-T1
17card=16 - KWorld LTV883RF
18card=17 - DViCO - FusionHDTV 3 Gold
19card=18 - Hauppauge Nova-T DVB-T
20card=19 - Conexant DVB-T reference design
21card=20 - Provideo PV259
22card=21 - DVICO FusionHDTV DVB-T Plus
23card=22 - digitalnow DNTV Live! DVB-T
24card=23 - pcHDTV HD3000 HDTV
25card=24 - Hauppauge WinTV 28xxx (Roslyn) models
26card=25 - Digital-Logic MICROSPACE Entertainment Center (MEC)
27card=26 - IODATA GV/BCTV7E
28card=27 - PixelView PlayTV Ultra Pro (Stereo)
29card=28 - DViCO - FusionHDTV 3 Gold-T
diff --git a/Documentation/video4linux/CARDLIST.saa7134 b/Documentation/video4linux/CARDLIST.saa7134
index a6c82fa4de02..d5ed95d28500 100644
--- a/Documentation/video4linux/CARDLIST.saa7134
+++ b/Documentation/video4linux/CARDLIST.saa7134
@@ -20,16 +20,37 @@
20 19 -> Compro VideoMate TV [185b:c100] 20 19 -> Compro VideoMate TV [185b:c100]
21 20 -> Matrox CronosPlus [102B:48d0] 21 20 -> Matrox CronosPlus [102B:48d0]
22 21 -> 10MOONS PCI TV CAPTURE CARD [1131:2001] 22 21 -> 10MOONS PCI TV CAPTURE CARD [1131:2001]
23 22 -> Medion 2819/ AverMedia M156 [1461:a70b,1461:2115] 23 22 -> AverMedia M156 / Medion 2819 [1461:a70b]
24 23 -> BMK MPEX Tuner 24 23 -> BMK MPEX Tuner
25 24 -> KNC One TV-Station DVR [1894:a006] 25 24 -> KNC One TV-Station DVR [1894:a006]
26 25 -> ASUS TV-FM 7133 [1043:4843] 26 25 -> ASUS TV-FM 7133 [1043:4843]
27 26 -> Pinnacle PCTV Stereo (saa7134) [11bd:002b] 27 26 -> Pinnacle PCTV Stereo (saa7134) [11bd:002b]
28 27 -> Manli MuchTV M-TV002 28 27 -> Manli MuchTV M-TV002/Behold TV 403 FM
29 28 -> Manli MuchTV M-TV001 29 28 -> Manli MuchTV M-TV001/Behold TV 401
30 29 -> Nagase Sangyo TransGear 3000TV [1461:050c] 30 29 -> Nagase Sangyo TransGear 3000TV [1461:050c]
31 30 -> Elitegroup ECS TVP3XP FM1216 Tuner Card(PAL-BG,FM) [1019:4cb4] 31 30 -> Elitegroup ECS TVP3XP FM1216 Tuner Card(PAL-BG,FM) [1019:4cb4]
32 31 -> Elitegroup ECS TVP3XP FM1236 Tuner Card (NTSC,FM) [1019:4cb5] 32 31 -> Elitegroup ECS TVP3XP FM1236 Tuner Card (NTSC,FM) [1019:4cb5]
33 32 -> AVACS SmartTV 33 32 -> AVACS SmartTV
34 33 -> AVerMedia DVD EZMaker [1461:10ff] 34 33 -> AVerMedia DVD EZMaker [1461:10ff]
35 34 -> LifeView FlyTV Platinum33 mini [5168:0212] 35 34 -> Noval Prime TV 7133
36 35 -> AverMedia AverTV Studio 305 [1461:2115]
37 37 -> Items MuchTV Plus / IT-005
38 38 -> Terratec Cinergy 200 TV [153B:1152]
39 39 -> LifeView FlyTV Platinum Mini [5168:0212]
40 40 -> Compro VideoMate TV PVR/FM [185b:c100]
41 41 -> Compro VideoMate TV Gold+ [185b:c100]
42 42 -> Sabrent SBT-TVFM (saa7130)
43 43 -> :Zolid Xpert TV7134
44 44 -> Empire PCI TV-Radio LE
45 45 -> Avermedia AVerTV Studio 307 [1461:9715]
46 46 -> AVerMedia Cardbus TV/Radio [1461:d6ee]
47 47 -> Terratec Cinergy 400 mobile [153b:1162]
48 48 -> Terratec Cinergy 600 TV MK3 [153B:1158]
49 49 -> Compro VideoMate Gold+ Pal [185b:c200]
50 50 -> Pinnacle PCTV 300i DVB-T + PAL [11bd:002d]
51 51 -> ProVideo PV952 [1540:9524]
52 52 -> AverMedia AverTV/305 [1461:2108]
53 54 -> LifeView FlyTV Platinum FM [5168:0214,1489:0214]
54 55 -> LifeView FlyDVB-T DUO [5168:0306]
55 56 -> Avermedia AVerTV 307 [1461:a70a]
56 57 -> Avermedia AVerTV GO 007 FM [1461:f31f]
diff --git a/Documentation/video4linux/CARDLIST.tuner b/Documentation/video4linux/CARDLIST.tuner
index f7bafe862ba0..aeb8df8ce890 100644
--- a/Documentation/video4linux/CARDLIST.tuner
+++ b/Documentation/video4linux/CARDLIST.tuner
@@ -44,3 +44,18 @@ tuner=42 - Philips 1236D ATSC/NTSC daul in
44tuner=43 - Philips NTSC MK3 (FM1236MK3 or FM1236/F) 44tuner=43 - Philips NTSC MK3 (FM1236MK3 or FM1236/F)
45tuner=44 - Philips 4 in 1 (ATI TV Wonder Pro/Conexant) 45tuner=44 - Philips 4 in 1 (ATI TV Wonder Pro/Conexant)
46tuner=45 - Microtune 4049 FM5 46tuner=45 - Microtune 4049 FM5
47tuner=46 - Panasonic VP27s/ENGE4324D
48tuner=47 - LG NTSC (TAPE series)
49tuner=48 - Tenna TNF 8831 BGFF)
50tuner=49 - Microtune 4042 FI5 ATSC/NTSC dual in
51tuner=50 - TCL 2002N
52tuner=51 - Philips PAL/SECAM_D (FM 1256 I-H3)
53tuner=52 - Thomson DDT 7610 (ATSC/NTSC)
54tuner=53 - Philips FQ1286
55tuner=54 - tda8290+75
56tuner=55 - LG PAL (TAPE series)
57tuner=56 - Philips PAL/SECAM multi (FQ1216AME MK4)
58tuner=57 - Philips FQ1236A MK4
59tuner=58 - Ymec TVision TVF-8531MF
60tuner=59 - Ymec TVision TVF-5533MF
61tuner=60 - Thomson DDT 7611 (ATSC/NTSC)
diff --git a/Documentation/video4linux/hauppauge-wintv-cx88-ir.txt b/Documentation/video4linux/hauppauge-wintv-cx88-ir.txt
new file mode 100644
index 000000000000..93fec32a1188
--- /dev/null
+++ b/Documentation/video4linux/hauppauge-wintv-cx88-ir.txt
@@ -0,0 +1,54 @@
1The controls for the mux are GPIO [0,1] for source, and GPIO 2 for muting.
2
3GPIO0 GPIO1
4 0 0 TV Audio
5 1 0 FM radio
6 0 1 Line-In
7 1 1 Mono tuner bypass or CD passthru (tuner specific)
8
9GPIO 16(i believe) is tied to the IR port (if present).
10
11------------------------------------------------------------------------------------
12
13>From the data sheet:
14 Register 24'h20004 PCI Interrupt Status
15 bit [18] IR_SMP_INT Set when 32 input samples have been collected over
16 gpio[16] pin into GP_SAMPLE register.
17
18What's missing from the data sheet:
19
20Setup 4KHz sampling rate (roughly 2x oversampled; good enough for our RC5
21compat remote)
22set register 0x35C050 to 0xa80a80
23
24enable sampling
25set register 0x35C054 to 0x5
26
27Of course, enable the IRQ bit 18 in the interrupt mask register .(and
28provide for a handler)
29
30GP_SAMPLE register is at 0x35C058
31
32Bits are then right shifted into the GP_SAMPLE register at the specified
33rate; you get an interrupt when a full DWORD is recieved.
34You need to recover the actual RC5 bits out of the (oversampled) IR sensor
35bits. (Hint: look for the 0/1and 1/0 crossings of the RC5 bi-phase data) An
36actual raw RC5 code will span 2-3 DWORDS, depending on the actual alignment.
37
38I'm pretty sure when no IR signal is present the receiver is always in a
39marking state(1); but stray light, etc can cause intermittent noise values
40as well. Remember, this is a free running sample of the IR receiver state
41over time, so don't assume any sample starts at any particular place.
42
43http://www.atmel.com/dyn/resources/prod_documents/doc2817.pdf
44This data sheet (google search) seems to have a lovely description of the
45RC5 basics
46
47http://users.pandora.be/nenya/electronics/rc5/ and more data
48
49http://www.ee.washington.edu/circuit_archive/text/ir_decode.txt
50and even a reference to how to decode a bi-phase data stream.
51
52http://www.xs4all.nl/~sbp/knowledge/ir/rc5.htm
53still more info
54
diff --git a/Documentation/video4linux/lifeview.txt b/Documentation/video4linux/lifeview.txt
new file mode 100644
index 000000000000..b07ea79c2b7e
--- /dev/null
+++ b/Documentation/video4linux/lifeview.txt
@@ -0,0 +1,42 @@
1collecting data about the lifeview models and the config coding on
2gpio pins 0-9 ...
3==================================================================
4
5bt878:
6 LR50 rev. Q ("PARTS: 7031505116), Tuner wurde als Nr. 5 erkannt, Eingänge
7 SVideo, TV, Composite, Audio, Remote. CP9..1=100001001 (1: 0-Ohm-Widerstand
8 gegen GND unbestückt; 0: bestückt)
9
10------------------------------------------------------------------------------
11
12saa7134:
13 /* LifeView FlyTV Platinum FM (LR214WF) */
14 /* "Peter Missel <peter.missel@onlinehome.de> */
15 .name = "LifeView FlyTV Platinum FM",
16 /* GP27 MDT2005 PB4 pin 10 */
17 /* GP26 MDT2005 PB3 pin 9 */
18 /* GP25 MDT2005 PB2 pin 8 */
19 /* GP23 MDT2005 PB1 pin 7 */
20 /* GP22 MDT2005 PB0 pin 6 */
21 /* GP21 MDT2005 PB5 pin 11 */
22 /* GP20 MDT2005 PB6 pin 12 */
23 /* GP19 MDT2005 PB7 pin 13 */
24 /* nc MDT2005 PA3 pin 2 */
25 /* Remote MDT2005 PA2 pin 1 */
26 /* GP18 MDT2005 PA1 pin 18 */
27 /* nc MDT2005 PA0 pin 17 strap low */
28
29 /* GP17 Strap "GP7"=High */
30 /* GP16 Strap "GP6"=High
31 0=Radio 1=TV
32 Drives SA630D ENCH1 and HEF4052 A1 pins
33 to do FM radio through SIF input */
34 /* GP15 nc */
35 /* GP14 nc */
36 /* GP13 nc */
37 /* GP12 Strap "GP5" = High */
38 /* GP11 Strap "GP4" = High */
39 /* GP10 Strap "GP3" = High */
40 /* GP09 Strap "GP2" = Low */
41 /* GP08 Strap "GP1" = Low */
42 /* GP07.00 nc */
diff --git a/Documentation/video4linux/not-in-cx2388x-datasheet.txt b/Documentation/video4linux/not-in-cx2388x-datasheet.txt
new file mode 100644
index 000000000000..96b638b5ba1d
--- /dev/null
+++ b/Documentation/video4linux/not-in-cx2388x-datasheet.txt
@@ -0,0 +1,37 @@
1=================================================================================
2MO_OUTPUT_FORMAT (0x310164)
3
4 Previous default from DScaler: 0x1c1f0008
5 Digit 8: 31-28
6 28: PREVREMOD = 1
7
8 Digit 7: 27-24 (0xc = 12 = b1100 )
9 27: COMBALT = 1
10 26: PAL_INV_PHASE
11 (DScaler apparently set this to 1, resulted in sucky picture)
12
13 Digits 6,5: 23-16
14 25-16: COMB_RANGE = 0x1f [default] (9 bits -> max 512)
15
16 Digit 4: 15-12
17 15: DISIFX = 0
18 14: INVCBF = 0
19 13: DISADAPT = 0
20 12: NARROWADAPT = 0
21
22 Digit 3: 11-8
23 11: FORCE2H
24 10: FORCEREMD
25 9: NCHROMAEN
26 8: NREMODEN
27
28 Digit 2: 7-4
29 7-6: YCORE
30 5-4: CCORE
31
32 Digit 1: 3-0
33 3: RANGE = 1
34 2: HACTEXT
35 1: HSFMT
36
37=================================================================================
diff --git a/Documentation/w1/w1.generic b/Documentation/w1/w1.generic
index eace3046a858..f937fbe1cacb 100644
--- a/Documentation/w1/w1.generic
+++ b/Documentation/w1/w1.generic
@@ -1,19 +1,92 @@
1Any w1 device must be connected to w1 bus master device - for example 1The 1-wire (w1) subsystem
2ds9490 usb device or w1-over-GPIO or RS232 converter. 2------------------------------------------------------------------
3Driver for w1 bus master must provide several functions(you can find 3The 1-wire bus is a simple master-slave bus that communicates via a single
4them in struct w1_bus_master definition in w1.h) which then will be 4signal wire (plus ground, so two wires).
5called by w1 core to send various commands over w1 bus(by default it is 5
6reset and search commands). When some device is found on the bus, w1 core 6Devices communicate on the bus by pulling the signal to ground via an open
7checks if driver for it's family is loaded. 7drain output and by sampling the logic level of the signal line.
8If driver is loaded w1 core creates new w1_slave object and registers it 8
9in the system(creates some generic sysfs files(struct w1_family_ops in 9The w1 subsystem provides the framework for managing w1 masters and
10w1_family.h), notifies any registered listener and so on...). 10communication with slaves.
11It is device driver's business to provide any communication method 11
12upstream. 12All w1 slave devices must be connected to a w1 bus master device.
13For example w1_therm driver(ds18?20 thermal sensor family driver) 13
14provides temperature reading function which is bound to ->rbin() method 14Example w1 master devices:
15of the above w1_family_ops structure. 15 DS9490 usb device
16w1_smem - driver for simple 64bit memory cell provides ID reading 16 W1-over-GPIO
17method. 17 DS2482 (i2c to w1 bridge)
18 Emulated devices, such as a RS232 converter, parallel port adapter, etc
19
20
21What does the w1 subsystem do?
22------------------------------------------------------------------
23When a w1 master driver registers with the w1 subsystem, the following occurs:
24
25 - sysfs entries for that w1 master are created
26 - the w1 bus is periodically searched for new slave devices
27
28When a device is found on the bus, w1 core checks if driver for it's family is
29loaded. If so, the family driver is attached to the slave.
30If there is no driver for the family, a simple sysfs entry is created
31for the slave device.
32
33
34W1 device families
35------------------------------------------------------------------
36Slave devices are handled by a driver written for a family of w1 devices.
37
38A family driver populates a struct w1_family_ops (see w1_family.h) and
39registers with the w1 subsystem.
40
41Current family drivers:
42w1_therm - (ds18?20 thermal sensor family driver)
43 provides temperature reading function which is bound to ->rbin() method
44 of the above w1_family_ops structure.
45
46w1_smem - driver for simple 64bit memory cell provides ID reading method.
18 47
19You can call above methods by reading appropriate sysfs files. 48You can call above methods by reading appropriate sysfs files.
49
50
51What does a w1 master driver need to implement?
52------------------------------------------------------------------
53
54The driver for w1 bus master must provide at minimum two functions.
55
56Emulated devices must provide the ability to set the output signal level
57(write_bit) and sample the signal level (read_bit).
58
59Devices that support the 1-wire natively must provide the ability to write and
60sample a bit (touch_bit) and reset the bus (reset_bus).
61
62Most hardware provides higher-level functions that offload w1 handling.
63See struct w1_bus_master definition in w1.h for details.
64
65
66w1 master sysfs interface
67------------------------------------------------------------------
68<xx-xxxxxxxxxxxxx> - a directory for a found device. The format is family-serial
69bus - (standard) symlink to the w1 bus
70driver - (standard) symlink to the w1 driver
71w1_master_attempts - the number of times a search was attempted
72w1_master_max_slave_count
73 - the maximum slaves that may be attached to a master
74w1_master_name - the name of the device (w1_bus_masterX)
75w1_master_search - the number of searches left to do, -1=continual (default)
76w1_master_slave_count
77 - the number of slaves found
78w1_master_slaves - the names of the slaves, one per line
79w1_master_timeout - the delay in seconds between searches
80
81If you have a w1 bus that never changes (you don't add or remove devices),
82you can set w1_master_search to a positive value to disable searches.
83
84
85w1 slave sysfs interface
86------------------------------------------------------------------
87bus - (standard) symlink to the w1 bus
88driver - (standard) symlink to the w1 driver
89name - the device name, usually the same as the directory name
90w1_slave - (optional) a binary file whose meaning depends on the
91 family driver
92