diff options
author | Jeff Garzik <jeff@garzik.org> | 2006-09-30 23:55:03 -0400 |
---|---|---|
committer | Jeff Garzik <jeff@garzik.org> | 2006-09-30 23:55:03 -0400 |
commit | e993835441734c184d70d3716eed78a08eeb71c2 (patch) | |
tree | 583aa17813cdae1c4640e353f8c6df3f197e7548 /Documentation | |
parent | 360f654e7cda850034f3f6252a7a7cff3fa77356 (diff) | |
parent | 1bdfd554be94def718323659173517c5d4a69d25 (diff) |
Merge branch 'master' into upstream
Diffstat (limited to 'Documentation')
23 files changed, 786 insertions, 221 deletions
diff --git a/Documentation/CodingStyle b/Documentation/CodingStyle index 6d2412ec91ed..29c18966b050 100644 --- a/Documentation/CodingStyle +++ b/Documentation/CodingStyle | |||
@@ -532,6 +532,40 @@ appears outweighs the potential value of the hint that tells gcc to do | |||
532 | something it would have done anyway. | 532 | something it would have done anyway. |
533 | 533 | ||
534 | 534 | ||
535 | Chapter 16: Function return values and names | ||
536 | |||
537 | Functions can return values of many different kinds, and one of the | ||
538 | most common is a value indicating whether the function succeeded or | ||
539 | failed. Such a value can be represented as an error-code integer | ||
540 | (-Exxx = failure, 0 = success) or a "succeeded" boolean (0 = failure, | ||
541 | non-zero = success). | ||
542 | |||
543 | Mixing up these two sorts of representations is a fertile source of | ||
544 | difficult-to-find bugs. If the C language included a strong distinction | ||
545 | between integers and booleans then the compiler would find these mistakes | ||
546 | for us... but it doesn't. To help prevent such bugs, always follow this | ||
547 | convention: | ||
548 | |||
549 | If the name of a function is an action or an imperative command, | ||
550 | the function should return an error-code integer. If the name | ||
551 | is a predicate, the function should return a "succeeded" boolean. | ||
552 | |||
553 | For example, "add work" is a command, and the add_work() function returns 0 | ||
554 | for success or -EBUSY for failure. In the same way, "PCI device present" is | ||
555 | a predicate, and the pci_dev_present() function returns 1 if it succeeds in | ||
556 | finding a matching device or 0 if it doesn't. | ||
557 | |||
558 | All EXPORTed functions must respect this convention, and so should all | ||
559 | public functions. Private (static) functions need not, but it is | ||
560 | recommended that they do. | ||
561 | |||
562 | Functions whose return value is the actual result of a computation, rather | ||
563 | than an indication of whether the computation succeeded, are not subject to | ||
564 | this rule. Generally they indicate failure by returning some out-of-range | ||
565 | result. Typical examples would be functions that return pointers; they use | ||
566 | NULL or the ERR_PTR mechanism to report failure. | ||
567 | |||
568 | |||
535 | 569 | ||
536 | Appendix I: References | 570 | Appendix I: References |
537 | 571 | ||
diff --git a/Documentation/DocBook/kernel-api.tmpl b/Documentation/DocBook/kernel-api.tmpl index f8fe882e33dc..6d4b1ef5b6f1 100644 --- a/Documentation/DocBook/kernel-api.tmpl +++ b/Documentation/DocBook/kernel-api.tmpl | |||
@@ -181,27 +181,6 @@ X!Ilib/string.c | |||
181 | </sect1> | 181 | </sect1> |
182 | </chapter> | 182 | </chapter> |
183 | 183 | ||
184 | <chapter id="proc"> | ||
185 | <title>The proc filesystem</title> | ||
186 | |||
187 | <sect1><title>sysctl interface</title> | ||
188 | !Ekernel/sysctl.c | ||
189 | </sect1> | ||
190 | |||
191 | <sect1><title>proc filesystem interface</title> | ||
192 | !Ifs/proc/base.c | ||
193 | </sect1> | ||
194 | </chapter> | ||
195 | |||
196 | <chapter id="debugfs"> | ||
197 | <title>The debugfs filesystem</title> | ||
198 | |||
199 | <sect1><title>debugfs interface</title> | ||
200 | !Efs/debugfs/inode.c | ||
201 | !Efs/debugfs/file.c | ||
202 | </sect1> | ||
203 | </chapter> | ||
204 | |||
205 | <chapter id="vfs"> | 184 | <chapter id="vfs"> |
206 | <title>The Linux VFS</title> | 185 | <title>The Linux VFS</title> |
207 | <sect1><title>The Filesystem types</title> | 186 | <sect1><title>The Filesystem types</title> |
@@ -234,6 +213,50 @@ X!Ilib/string.c | |||
234 | </sect1> | 213 | </sect1> |
235 | </chapter> | 214 | </chapter> |
236 | 215 | ||
216 | <chapter id="proc"> | ||
217 | <title>The proc filesystem</title> | ||
218 | |||
219 | <sect1><title>sysctl interface</title> | ||
220 | !Ekernel/sysctl.c | ||
221 | </sect1> | ||
222 | |||
223 | <sect1><title>proc filesystem interface</title> | ||
224 | !Ifs/proc/base.c | ||
225 | </sect1> | ||
226 | </chapter> | ||
227 | |||
228 | <chapter id="sysfs"> | ||
229 | <title>The Filesystem for Exporting Kernel Objects</title> | ||
230 | !Efs/sysfs/file.c | ||
231 | !Efs/sysfs/symlink.c | ||
232 | !Efs/sysfs/bin.c | ||
233 | </chapter> | ||
234 | |||
235 | <chapter id="debugfs"> | ||
236 | <title>The debugfs filesystem</title> | ||
237 | |||
238 | <sect1><title>debugfs interface</title> | ||
239 | !Efs/debugfs/inode.c | ||
240 | !Efs/debugfs/file.c | ||
241 | </sect1> | ||
242 | </chapter> | ||
243 | |||
244 | <chapter id="relayfs"> | ||
245 | <title>relay interface support</title> | ||
246 | |||
247 | <para> | ||
248 | Relay interface support | ||
249 | is designed to provide an efficient mechanism for tools and | ||
250 | facilities to relay large amounts of data from kernel space to | ||
251 | user space. | ||
252 | </para> | ||
253 | |||
254 | <sect1><title>relay interface</title> | ||
255 | !Ekernel/relay.c | ||
256 | !Ikernel/relay.c | ||
257 | </sect1> | ||
258 | </chapter> | ||
259 | |||
237 | <chapter id="netcore"> | 260 | <chapter id="netcore"> |
238 | <title>Linux Networking</title> | 261 | <title>Linux Networking</title> |
239 | <sect1><title>Networking Base Types</title> | 262 | <sect1><title>Networking Base Types</title> |
@@ -349,13 +372,6 @@ X!Earch/i386/kernel/mca.c | |||
349 | </sect1> | 372 | </sect1> |
350 | </chapter> | 373 | </chapter> |
351 | 374 | ||
352 | <chapter id="sysfs"> | ||
353 | <title>The Filesystem for Exporting Kernel Objects</title> | ||
354 | !Efs/sysfs/file.c | ||
355 | !Efs/sysfs/symlink.c | ||
356 | !Efs/sysfs/bin.c | ||
357 | </chapter> | ||
358 | |||
359 | <chapter id="security"> | 375 | <chapter id="security"> |
360 | <title>Security Framework</title> | 376 | <title>Security Framework</title> |
361 | !Esecurity/security.c | 377 | !Esecurity/security.c |
@@ -386,6 +402,7 @@ X!Iinclude/linux/device.h | |||
386 | --> | 402 | --> |
387 | !Edrivers/base/driver.c | 403 | !Edrivers/base/driver.c |
388 | !Edrivers/base/core.c | 404 | !Edrivers/base/core.c |
405 | !Edrivers/base/class.c | ||
389 | !Edrivers/base/firmware_class.c | 406 | !Edrivers/base/firmware_class.c |
390 | !Edrivers/base/transport_class.c | 407 | !Edrivers/base/transport_class.c |
391 | !Edrivers/base/dmapool.c | 408 | !Edrivers/base/dmapool.c |
@@ -437,6 +454,11 @@ X!Edrivers/pnp/system.c | |||
437 | !Eblock/ll_rw_blk.c | 454 | !Eblock/ll_rw_blk.c |
438 | </chapter> | 455 | </chapter> |
439 | 456 | ||
457 | <chapter id="chrdev"> | ||
458 | <title>Char devices</title> | ||
459 | !Efs/char_dev.c | ||
460 | </chapter> | ||
461 | |||
440 | <chapter id="miscdev"> | 462 | <chapter id="miscdev"> |
441 | <title>Miscellaneous Devices</title> | 463 | <title>Miscellaneous Devices</title> |
442 | !Edrivers/char/misc.c | 464 | !Edrivers/char/misc.c |
diff --git a/Documentation/SubmitChecklist b/Documentation/SubmitChecklist index a10bfb6ecd9f..a6cb6ffd2933 100644 --- a/Documentation/SubmitChecklist +++ b/Documentation/SubmitChecklist | |||
@@ -61,3 +61,6 @@ kernel patches. | |||
61 | Documentation/kernel-parameters.txt. | 61 | Documentation/kernel-parameters.txt. |
62 | 62 | ||
63 | 18: All new module parameters are documented with MODULE_PARM_DESC() | 63 | 18: All new module parameters are documented with MODULE_PARM_DESC() |
64 | |||
65 | 19: All new userspace interfaces are documented in Documentation/ABI/. | ||
66 | See Documentation/ABI/README for more information. | ||
diff --git a/Documentation/SubmittingDrivers b/Documentation/SubmittingDrivers index 6bd30fdd0786..58bead05eabb 100644 --- a/Documentation/SubmittingDrivers +++ b/Documentation/SubmittingDrivers | |||
@@ -59,11 +59,11 @@ Copyright: The copyright owner must agree to use of GPL. | |||
59 | are the same person/entity. If not, the name of | 59 | are the same person/entity. If not, the name of |
60 | the person/entity authorizing use of GPL should be | 60 | the person/entity authorizing use of GPL should be |
61 | listed in case it's necessary to verify the will of | 61 | listed in case it's necessary to verify the will of |
62 | the copright owner. | 62 | the copyright owner. |
63 | 63 | ||
64 | Interfaces: If your driver uses existing interfaces and behaves like | 64 | Interfaces: If your driver uses existing interfaces and behaves like |
65 | other drivers in the same class it will be much more likely | 65 | other drivers in the same class it will be much more likely |
66 | to be accepted than if it invents gratuitous new ones. | 66 | to be accepted than if it invents gratuitous new ones. |
67 | If you need to implement a common API over Linux and NT | 67 | If you need to implement a common API over Linux and NT |
68 | drivers do it in userspace. | 68 | drivers do it in userspace. |
69 | 69 | ||
@@ -88,7 +88,7 @@ Clarity: It helps if anyone can see how to fix the driver. It helps | |||
88 | it will go in the bitbucket. | 88 | it will go in the bitbucket. |
89 | 89 | ||
90 | Control: In general if there is active maintainance of a driver by | 90 | Control: In general if there is active maintainance of a driver by |
91 | the author then patches will be redirected to them unless | 91 | the author then patches will be redirected to them unless |
92 | they are totally obvious and without need of checking. | 92 | they are totally obvious and without need of checking. |
93 | If you want to be the contact and update point for the | 93 | If you want to be the contact and update point for the |
94 | driver it is a good idea to state this in the comments, | 94 | driver it is a good idea to state this in the comments, |
@@ -100,7 +100,7 @@ What Criteria Do Not Determine Acceptance | |||
100 | Vendor: Being the hardware vendor and maintaining the driver is | 100 | Vendor: Being the hardware vendor and maintaining the driver is |
101 | often a good thing. If there is a stable working driver from | 101 | often a good thing. If there is a stable working driver from |
102 | other people already in the tree don't expect 'we are the | 102 | other people already in the tree don't expect 'we are the |
103 | vendor' to get your driver chosen. Ideally work with the | 103 | vendor' to get your driver chosen. Ideally work with the |
104 | existing driver author to build a single perfect driver. | 104 | existing driver author to build a single perfect driver. |
105 | 105 | ||
106 | Author: It doesn't matter if a large Linux company wrote the driver, | 106 | Author: It doesn't matter if a large Linux company wrote the driver, |
@@ -116,17 +116,13 @@ Linux kernel master tree: | |||
116 | ftp.??.kernel.org:/pub/linux/kernel/... | 116 | ftp.??.kernel.org:/pub/linux/kernel/... |
117 | ?? == your country code, such as "us", "uk", "fr", etc. | 117 | ?? == your country code, such as "us", "uk", "fr", etc. |
118 | 118 | ||
119 | Linux kernel mailing list: | 119 | Linux kernel mailing list: |
120 | linux-kernel@vger.kernel.org | 120 | linux-kernel@vger.kernel.org |
121 | [mail majordomo@vger.kernel.org to subscribe] | 121 | [mail majordomo@vger.kernel.org to subscribe] |
122 | 122 | ||
123 | Linux Device Drivers, Third Edition (covers 2.6.10): | 123 | Linux Device Drivers, Third Edition (covers 2.6.10): |
124 | http://lwn.net/Kernel/LDD3/ (free version) | 124 | http://lwn.net/Kernel/LDD3/ (free version) |
125 | 125 | ||
126 | Kernel traffic: | ||
127 | Weekly summary of kernel list activity (much easier to read) | ||
128 | http://www.kerneltraffic.org/kernel-traffic/ | ||
129 | |||
130 | LWN.net: | 126 | LWN.net: |
131 | Weekly summary of kernel development activity - http://lwn.net/ | 127 | Weekly summary of kernel development activity - http://lwn.net/ |
132 | 2.6 API changes: | 128 | 2.6 API changes: |
@@ -145,11 +141,8 @@ KernelNewbies: | |||
145 | Linux USB project: | 141 | Linux USB project: |
146 | http://www.linux-usb.org/ | 142 | http://www.linux-usb.org/ |
147 | 143 | ||
148 | How to NOT write kernel driver by arjanv@redhat.com | 144 | How to NOT write kernel driver by Arjan van de Ven: |
149 | http://people.redhat.com/arjanv/olspaper.pdf | 145 | http://www.fenrus.org/how-to-not-write-a-device-driver-paper.pdf |
150 | 146 | ||
151 | Kernel Janitor: | 147 | Kernel Janitor: |
152 | http://janitor.kernelnewbies.org/ | 148 | http://janitor.kernelnewbies.org/ |
153 | |||
154 | -- | ||
155 | Last updated on 17 Nov 2005. | ||
diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches index d42ab4c9e893..302d148c2e18 100644 --- a/Documentation/SubmittingPatches +++ b/Documentation/SubmittingPatches | |||
@@ -173,15 +173,15 @@ For small patches you may want to CC the Trivial Patch Monkey | |||
173 | trivial@kernel.org managed by Adrian Bunk; which collects "trivial" | 173 | trivial@kernel.org managed by Adrian Bunk; which collects "trivial" |
174 | patches. Trivial patches must qualify for one of the following rules: | 174 | patches. Trivial patches must qualify for one of the following rules: |
175 | Spelling fixes in documentation | 175 | Spelling fixes in documentation |
176 | Spelling fixes which could break grep(1). | 176 | Spelling fixes which could break grep(1) |
177 | Warning fixes (cluttering with useless warnings is bad) | 177 | Warning fixes (cluttering with useless warnings is bad) |
178 | Compilation fixes (only if they are actually correct) | 178 | Compilation fixes (only if they are actually correct) |
179 | Runtime fixes (only if they actually fix things) | 179 | Runtime fixes (only if they actually fix things) |
180 | Removing use of deprecated functions/macros (eg. check_region). | 180 | Removing use of deprecated functions/macros (eg. check_region) |
181 | Contact detail and documentation fixes | 181 | Contact detail and documentation fixes |
182 | Non-portable code replaced by portable code (even in arch-specific, | 182 | Non-portable code replaced by portable code (even in arch-specific, |
183 | since people copy, as long as it's trivial) | 183 | since people copy, as long as it's trivial) |
184 | Any fix by the author/maintainer of the file. (ie. patch monkey | 184 | Any fix by the author/maintainer of the file (ie. patch monkey |
185 | in re-transmission mode) | 185 | in re-transmission mode) |
186 | URL: <http://www.kernel.org/pub/linux/kernel/people/bunk/trivial/> | 186 | URL: <http://www.kernel.org/pub/linux/kernel/people/bunk/trivial/> |
187 | 187 | ||
@@ -209,6 +209,19 @@ Exception: If your mailer is mangling patches then someone may ask | |||
209 | you to re-send them using MIME. | 209 | you to re-send them using MIME. |
210 | 210 | ||
211 | 211 | ||
212 | WARNING: Some mailers like Mozilla send your messages with | ||
213 | ---- message header ---- | ||
214 | Content-Type: text/plain; charset=us-ascii; format=flowed | ||
215 | ---- message header ---- | ||
216 | The problem is that "format=flowed" makes some of the mailers | ||
217 | on receiving side to replace TABs with spaces and do similar | ||
218 | changes. Thus the patches from you can look corrupted. | ||
219 | |||
220 | To fix this just make your mozilla defaults/pref/mailnews.js file to look like: | ||
221 | pref("mailnews.send_plaintext_flowed", false); // RFC 2646======= | ||
222 | pref("mailnews.display.disable_format_flowed_support", true); | ||
223 | |||
224 | |||
212 | 225 | ||
213 | 7) E-mail size. | 226 | 7) E-mail size. |
214 | 227 | ||
@@ -245,13 +258,13 @@ updated change. | |||
245 | It is quite common for Linus to "drop" your patch without comment. | 258 | It is quite common for Linus to "drop" your patch without comment. |
246 | That's the nature of the system. If he drops your patch, it could be | 259 | That's the nature of the system. If he drops your patch, it could be |
247 | due to | 260 | due to |
248 | * Your patch did not apply cleanly to the latest kernel version | 261 | * Your patch did not apply cleanly to the latest kernel version. |
249 | * Your patch was not sufficiently discussed on linux-kernel. | 262 | * Your patch was not sufficiently discussed on linux-kernel. |
250 | * A style issue (see section 2), | 263 | * A style issue (see section 2). |
251 | * An e-mail formatting issue (re-read this section) | 264 | * An e-mail formatting issue (re-read this section). |
252 | * A technical problem with your change | 265 | * A technical problem with your change. |
253 | * He gets tons of e-mail, and yours got lost in the shuffle | 266 | * He gets tons of e-mail, and yours got lost in the shuffle. |
254 | * You are being annoying (See Figure 1) | 267 | * You are being annoying. |
255 | 268 | ||
256 | When in doubt, solicit comments on linux-kernel mailing list. | 269 | When in doubt, solicit comments on linux-kernel mailing list. |
257 | 270 | ||
@@ -476,10 +489,10 @@ SECTION 3 - REFERENCES | |||
476 | Andrew Morton, "The perfect patch" (tpp). | 489 | Andrew Morton, "The perfect patch" (tpp). |
477 | <http://www.zip.com.au/~akpm/linux/patches/stuff/tpp.txt> | 490 | <http://www.zip.com.au/~akpm/linux/patches/stuff/tpp.txt> |
478 | 491 | ||
479 | Jeff Garzik, "Linux kernel patch submission format." | 492 | Jeff Garzik, "Linux kernel patch submission format". |
480 | <http://linux.yyz.us/patch-format.html> | 493 | <http://linux.yyz.us/patch-format.html> |
481 | 494 | ||
482 | Greg Kroah-Hartman "How to piss off a kernel subsystem maintainer". | 495 | Greg Kroah-Hartman, "How to piss off a kernel subsystem maintainer". |
483 | <http://www.kroah.com/log/2005/03/31/> | 496 | <http://www.kroah.com/log/2005/03/31/> |
484 | <http://www.kroah.com/log/2005/07/08/> | 497 | <http://www.kroah.com/log/2005/07/08/> |
485 | <http://www.kroah.com/log/2005/10/19/> | 498 | <http://www.kroah.com/log/2005/10/19/> |
@@ -488,9 +501,9 @@ Greg Kroah-Hartman "How to piss off a kernel subsystem maintainer". | |||
488 | NO!!!! No more huge patch bombs to linux-kernel@vger.kernel.org people! | 501 | NO!!!! No more huge patch bombs to linux-kernel@vger.kernel.org people! |
489 | <http://marc.theaimsgroup.com/?l=linux-kernel&m=112112749912944&w=2> | 502 | <http://marc.theaimsgroup.com/?l=linux-kernel&m=112112749912944&w=2> |
490 | 503 | ||
491 | Kernel Documentation/CodingStyle | 504 | Kernel Documentation/CodingStyle: |
492 | <http://sosdg.org/~coywolf/lxr/source/Documentation/CodingStyle> | 505 | <http://sosdg.org/~coywolf/lxr/source/Documentation/CodingStyle> |
493 | 506 | ||
494 | Linus Torvald's mail on the canonical patch format: | 507 | Linus Torvalds's mail on the canonical patch format: |
495 | <http://lkml.org/lkml/2005/4/7/183> | 508 | <http://lkml.org/lkml/2005/4/7/183> |
496 | -- | 509 | -- |
diff --git a/Documentation/cpusets.txt b/Documentation/cpusets.txt index 76b44290c154..842f0d1ab216 100644 --- a/Documentation/cpusets.txt +++ b/Documentation/cpusets.txt | |||
@@ -217,11 +217,11 @@ exclusive cpuset. Also, the use of a Linux virtual file system (vfs) | |||
217 | to represent the cpuset hierarchy provides for a familiar permission | 217 | to represent the cpuset hierarchy provides for a familiar permission |
218 | and name space for cpusets, with a minimum of additional kernel code. | 218 | and name space for cpusets, with a minimum of additional kernel code. |
219 | 219 | ||
220 | The cpus file in the root (top_cpuset) cpuset is read-only. | 220 | The cpus and mems files in the root (top_cpuset) cpuset are |
221 | It automatically tracks the value of cpu_online_map, using a CPU | 221 | read-only. The cpus file automatically tracks the value of |
222 | hotplug notifier. If and when memory nodes can be hotplugged, | 222 | cpu_online_map using a CPU hotplug notifier, and the mems file |
223 | we expect to make the mems file in the root cpuset read-only | 223 | automatically tracks the value of node_online_map using the |
224 | as well, and have it track the value of node_online_map. | 224 | cpuset_track_online_nodes() hook. |
225 | 225 | ||
226 | 226 | ||
227 | 1.4 What are exclusive cpusets ? | 227 | 1.4 What are exclusive cpusets ? |
diff --git a/Documentation/fb/intelfb.txt b/Documentation/fb/intelfb.txt index c12d39a23c3d..aa0d322db171 100644 --- a/Documentation/fb/intelfb.txt +++ b/Documentation/fb/intelfb.txt | |||
@@ -1,16 +1,19 @@ | |||
1 | Intel 830M/845G/852GM/855GM/865G/915G Framebuffer driver | 1 | Intel 830M/845G/852GM/855GM/865G/915G/945G Framebuffer driver |
2 | ================================================================ | 2 | ================================================================ |
3 | 3 | ||
4 | A. Introduction | 4 | A. Introduction |
5 | This is a framebuffer driver for various Intel 810/815 compatible | 5 | This is a framebuffer driver for various Intel 8xx/9xx compatible |
6 | graphics devices. These would include: | 6 | graphics devices. These would include: |
7 | 7 | ||
8 | Intel 830M | 8 | Intel 830M |
9 | Intel 810E845G | 9 | Intel 845G |
10 | Intel 852GM | 10 | Intel 852GM |
11 | Intel 855GM | 11 | Intel 855GM |
12 | Intel 865G | 12 | Intel 865G |
13 | Intel 915G | 13 | Intel 915G |
14 | Intel 915GM | ||
15 | Intel 945G | ||
16 | Intel 945GM | ||
14 | 17 | ||
15 | B. List of available options | 18 | B. List of available options |
16 | 19 | ||
@@ -78,7 +81,7 @@ C. Kernel booting | |||
78 | Separate each option/option-pair by commas (,) and the option from its value | 81 | Separate each option/option-pair by commas (,) and the option from its value |
79 | with an equals sign (=) as in the following: | 82 | with an equals sign (=) as in the following: |
80 | 83 | ||
81 | video=i810fb:option1,option2=value2 | 84 | video=intelfb:option1,option2=value2 |
82 | 85 | ||
83 | Sample Usage | 86 | Sample Usage |
84 | ------------ | 87 | ------------ |
diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt index 436697cb9388..9364f47c7116 100644 --- a/Documentation/feature-removal-schedule.txt +++ b/Documentation/feature-removal-schedule.txt | |||
@@ -46,17 +46,8 @@ Who: Jody McIntyre <scjody@modernduck.com> | |||
46 | 46 | ||
47 | --------------------------- | 47 | --------------------------- |
48 | 48 | ||
49 | What: sbp2: module parameter "force_inquiry_hack" | ||
50 | When: July 2006 | ||
51 | Why: Superceded by parameter "workarounds". Both parameters are meant to be | ||
52 | used ad-hoc and for single devices only, i.e. not in modprobe.conf, | ||
53 | therefore the impact of this feature replacement should be low. | ||
54 | Who: Stefan Richter <stefanr@s5r6.in-berlin.de> | ||
55 | |||
56 | --------------------------- | ||
57 | |||
58 | What: Video4Linux API 1 ioctls and video_decoder.h from Video devices. | 49 | What: Video4Linux API 1 ioctls and video_decoder.h from Video devices. |
59 | When: July 2006 | 50 | When: December 2006 |
60 | Why: V4L1 AP1 was replaced by V4L2 API. during migration from 2.4 to 2.6 | 51 | Why: V4L1 AP1 was replaced by V4L2 API. during migration from 2.4 to 2.6 |
61 | series. The old API have lots of drawbacks and don't provide enough | 52 | series. The old API have lots of drawbacks and don't provide enough |
62 | means to work with all video and audio standards. The newer API is | 53 | means to work with all video and audio standards. The newer API is |
diff --git a/Documentation/filesystems/proc.txt b/Documentation/filesystems/proc.txt index 7db71d6fba82..7240ee7515de 100644 --- a/Documentation/filesystems/proc.txt +++ b/Documentation/filesystems/proc.txt | |||
@@ -39,6 +39,8 @@ Table of Contents | |||
39 | 2.9 Appletalk | 39 | 2.9 Appletalk |
40 | 2.10 IPX | 40 | 2.10 IPX |
41 | 2.11 /proc/sys/fs/mqueue - POSIX message queues filesystem | 41 | 2.11 /proc/sys/fs/mqueue - POSIX message queues filesystem |
42 | 2.12 /proc/<pid>/oom_adj - Adjust the oom-killer score | ||
43 | 2.13 /proc/<pid>/oom_score - Display current oom-killer score | ||
42 | 44 | ||
43 | ------------------------------------------------------------------------------ | 45 | ------------------------------------------------------------------------------ |
44 | Preface | 46 | Preface |
@@ -1962,6 +1964,22 @@ a queue must be less or equal then msg_max. | |||
1962 | maximum message size value (it is every message queue's attribute set during | 1964 | maximum message size value (it is every message queue's attribute set during |
1963 | its creation). | 1965 | its creation). |
1964 | 1966 | ||
1967 | 2.12 /proc/<pid>/oom_adj - Adjust the oom-killer score | ||
1968 | ------------------------------------------------------ | ||
1969 | |||
1970 | This file can be used to adjust the score used to select which processes | ||
1971 | should be killed in an out-of-memory situation. Giving it a high score will | ||
1972 | increase the likelihood of this process being killed by the oom-killer. Valid | ||
1973 | values are in the range -16 to +15, plus the special value -17, which disables | ||
1974 | oom-killing altogether for this process. | ||
1975 | |||
1976 | 2.13 /proc/<pid>/oom_score - Display current oom-killer score | ||
1977 | ------------------------------------------------------------- | ||
1978 | |||
1979 | ------------------------------------------------------------------------------ | ||
1980 | This file can be used to check the current score used by the oom-killer is for | ||
1981 | any given <pid>. Use it together with /proc/<pid>/oom_adj to tune which | ||
1982 | process should be killed in an out-of-memory situation. | ||
1965 | 1983 | ||
1966 | ------------------------------------------------------------------------------ | 1984 | ------------------------------------------------------------------------------ |
1967 | Summary | 1985 | Summary |
diff --git a/Documentation/hwmon/it87 b/Documentation/hwmon/it87 index 9555be1ed999..e783fd62e308 100644 --- a/Documentation/hwmon/it87 +++ b/Documentation/hwmon/it87 | |||
@@ -13,12 +13,25 @@ Supported chips: | |||
13 | from Super I/O config space (8 I/O ports) | 13 | from Super I/O config space (8 I/O ports) |
14 | Datasheet: Publicly available at the ITE website | 14 | Datasheet: Publicly available at the ITE website |
15 | http://www.ite.com.tw/ | 15 | http://www.ite.com.tw/ |
16 | * IT8716F | ||
17 | Prefix: 'it8716' | ||
18 | Addresses scanned: from Super I/O config space (8 I/O ports) | ||
19 | Datasheet: Publicly available at the ITE website | ||
20 | http://www.ite.com.tw/product_info/file/pc/IT8716F_V0.3.ZIP | ||
21 | * IT8718F | ||
22 | Prefix: 'it8718' | ||
23 | Addresses scanned: from Super I/O config space (8 I/O ports) | ||
24 | Datasheet: Publicly available at the ITE website | ||
25 | http://www.ite.com.tw/product_info/file/pc/IT8718F_V0.2.zip | ||
26 | http://www.ite.com.tw/product_info/file/pc/IT8718F_V0%203_(for%20C%20version).zip | ||
16 | * SiS950 [clone of IT8705F] | 27 | * SiS950 [clone of IT8705F] |
17 | Prefix: 'it87' | 28 | Prefix: 'it87' |
18 | Addresses scanned: from Super I/O config space (8 I/O ports) | 29 | Addresses scanned: from Super I/O config space (8 I/O ports) |
19 | Datasheet: No longer be available | 30 | Datasheet: No longer be available |
20 | 31 | ||
21 | Author: Christophe Gauthron <chrisg@0-in.com> | 32 | Authors: |
33 | Christophe Gauthron <chrisg@0-in.com> | ||
34 | Jean Delvare <khali@linux-fr.org> | ||
22 | 35 | ||
23 | 36 | ||
24 | Module Parameters | 37 | Module Parameters |
@@ -43,26 +56,46 @@ Module Parameters | |||
43 | Description | 56 | Description |
44 | ----------- | 57 | ----------- |
45 | 58 | ||
46 | This driver implements support for the IT8705F, IT8712F and SiS950 chips. | 59 | This driver implements support for the IT8705F, IT8712F, IT8716F, |
47 | 60 | IT8718F and SiS950 chips. | |
48 | This driver also supports IT8712F, which adds SMBus access, and a VID | ||
49 | input, used to report the Vcore voltage of the Pentium processor. | ||
50 | The IT8712F additionally features VID inputs. | ||
51 | 61 | ||
52 | These chips are 'Super I/O chips', supporting floppy disks, infrared ports, | 62 | These chips are 'Super I/O chips', supporting floppy disks, infrared ports, |
53 | joysticks and other miscellaneous stuff. For hardware monitoring, they | 63 | joysticks and other miscellaneous stuff. For hardware monitoring, they |
54 | include an 'environment controller' with 3 temperature sensors, 3 fan | 64 | include an 'environment controller' with 3 temperature sensors, 3 fan |
55 | rotation speed sensors, 8 voltage sensors, and associated alarms. | 65 | rotation speed sensors, 8 voltage sensors, and associated alarms. |
56 | 66 | ||
67 | The IT8712F and IT8716F additionally feature VID inputs, used to report | ||
68 | the Vcore voltage of the processor. The early IT8712F have 5 VID pins, | ||
69 | the IT8716F and late IT8712F have 6. They are shared with other functions | ||
70 | though, so the functionality may not be available on a given system. | ||
71 | The driver dumbly assume it is there. | ||
72 | |||
73 | The IT8718F also features VID inputs (up to 8 pins) but the value is | ||
74 | stored in the Super-I/O configuration space. Due to technical limitations, | ||
75 | this value can currently only be read once at initialization time, so | ||
76 | the driver won't notice and report changes in the VID value. The two | ||
77 | upper VID bits share their pins with voltage inputs (in5 and in6) so you | ||
78 | can't have both on a given board. | ||
79 | |||
80 | The IT8716F, IT8718F and later IT8712F revisions have support for | ||
81 | 2 additional fans. They are not yet supported by the driver. | ||
82 | |||
83 | The IT8716F and IT8718F, and late IT8712F and IT8705F also have optional | ||
84 | 16-bit tachometer counters for fans 1 to 3. This is better (no more fan | ||
85 | clock divider mess) but not compatible with the older chips and | ||
86 | revisions. For now, the driver only uses the 16-bit mode on the | ||
87 | IT8716F and IT8718F. | ||
88 | |||
57 | Temperatures are measured in degrees Celsius. An alarm is triggered once | 89 | Temperatures are measured in degrees Celsius. An alarm is triggered once |
58 | when the Overtemperature Shutdown limit is crossed. | 90 | when the Overtemperature Shutdown limit is crossed. |
59 | 91 | ||
60 | Fan rotation speeds are reported in RPM (rotations per minute). An alarm is | 92 | Fan rotation speeds are reported in RPM (rotations per minute). An alarm is |
61 | triggered if the rotation speed has dropped below a programmable limit. Fan | 93 | triggered if the rotation speed has dropped below a programmable limit. When |
62 | readings can be divided by a programmable divider (1, 2, 4 or 8) to give the | 94 | 16-bit tachometer counters aren't used, fan readings can be divided by |
63 | readings more range or accuracy. Not all RPM values can accurately be | 95 | a programmable divider (1, 2, 4 or 8) to give the readings more range or |
64 | represented, so some rounding is done. With a divider of 2, the lowest | 96 | accuracy. With a divider of 2, the lowest representable value is around |
65 | representable value is around 2600 RPM. | 97 | 2600 RPM. Not all RPM values can accurately be represented, so some rounding |
98 | is done. | ||
66 | 99 | ||
67 | Voltage sensors (also known as IN sensors) report their values in volts. An | 100 | Voltage sensors (also known as IN sensors) report their values in volts. An |
68 | alarm is triggered if the voltage has crossed a programmable minimum or | 101 | alarm is triggered if the voltage has crossed a programmable minimum or |
@@ -71,9 +104,9 @@ zero'; this is important for negative voltage measurements. All voltage | |||
71 | inputs can measure voltages between 0 and 4.08 volts, with a resolution of | 104 | inputs can measure voltages between 0 and 4.08 volts, with a resolution of |
72 | 0.016 volt. The battery voltage in8 does not have limit registers. | 105 | 0.016 volt. The battery voltage in8 does not have limit registers. |
73 | 106 | ||
74 | The VID lines (IT8712F only) encode the core voltage value: the voltage | 107 | The VID lines (IT8712F/IT8716F/IT8718F) encode the core voltage value: |
75 | level your processor should work with. This is hardcoded by the mainboard | 108 | the voltage level your processor should work with. This is hardcoded by |
76 | and/or processor itself. It is a value in volts. | 109 | the mainboard and/or processor itself. It is a value in volts. |
77 | 110 | ||
78 | If an alarm triggers, it will remain triggered until the hardware register | 111 | If an alarm triggers, it will remain triggered until the hardware register |
79 | is read at least once. This means that the cause for the alarm may already | 112 | is read at least once. This means that the cause for the alarm may already |
diff --git a/Documentation/hwmon/k8temp b/Documentation/hwmon/k8temp new file mode 100644 index 000000000000..bab445ab0f52 --- /dev/null +++ b/Documentation/hwmon/k8temp | |||
@@ -0,0 +1,52 @@ | |||
1 | Kernel driver k8temp | ||
2 | ==================== | ||
3 | |||
4 | Supported chips: | ||
5 | * AMD K8 CPU | ||
6 | Prefix: 'k8temp' | ||
7 | Addresses scanned: PCI space | ||
8 | Datasheet: http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/32559.pdf | ||
9 | |||
10 | Author: Rudolf Marek | ||
11 | Contact: Rudolf Marek <r.marek@sh.cvut.cz> | ||
12 | |||
13 | Description | ||
14 | ----------- | ||
15 | |||
16 | This driver permits reading temperature sensor(s) embedded inside AMD K8 CPUs. | ||
17 | Official documentation says that it works from revision F of K8 core, but | ||
18 | in fact it seems to be implemented for all revisions of K8 except the first | ||
19 | two revisions (SH-B0 and SH-B3). | ||
20 | |||
21 | There can be up to four temperature sensors inside single CPU. The driver | ||
22 | will auto-detect the sensors and will display only temperatures from | ||
23 | implemented sensors. | ||
24 | |||
25 | Mapping of /sys files is as follows: | ||
26 | |||
27 | temp1_input - temperature of Core 0 and "place" 0 | ||
28 | temp2_input - temperature of Core 0 and "place" 1 | ||
29 | temp3_input - temperature of Core 1 and "place" 0 | ||
30 | temp4_input - temperature of Core 1 and "place" 1 | ||
31 | |||
32 | Temperatures are measured in degrees Celsius and measurement resolution is | ||
33 | 1 degree C. It is expected that future CPU will have better resolution. The | ||
34 | temperature is updated once a second. Valid temperatures are from -49 to | ||
35 | 206 degrees C. | ||
36 | |||
37 | Temperature known as TCaseMax was specified for processors up to revision E. | ||
38 | This temperature is defined as temperature between heat-spreader and CPU | ||
39 | case, so the internal CPU temperature supplied by this driver can be higher. | ||
40 | There is no easy way how to measure the temperature which will correlate | ||
41 | with TCaseMax temperature. | ||
42 | |||
43 | For newer revisions of CPU (rev F, socket AM2) there is a mathematically | ||
44 | computed temperature called TControl, which must be lower than TControlMax. | ||
45 | |||
46 | The relationship is following: | ||
47 | |||
48 | temp1_input - TjOffset*2 < TControlMax, | ||
49 | |||
50 | TjOffset is not yet exported by the driver, TControlMax is usually | ||
51 | 70 degrees C. The rule of the thumb -> CPU temperature should not cross | ||
52 | 60 degrees C too much. | ||
diff --git a/Documentation/hwmon/vt1211 b/Documentation/hwmon/vt1211 new file mode 100644 index 000000000000..77fa633b97a8 --- /dev/null +++ b/Documentation/hwmon/vt1211 | |||
@@ -0,0 +1,206 @@ | |||
1 | Kernel driver vt1211 | ||
2 | ==================== | ||
3 | |||
4 | Supported chips: | ||
5 | * VIA VT1211 | ||
6 | Prefix: 'vt1211' | ||
7 | Addresses scanned: none, address read from Super-I/O config space | ||
8 | Datasheet: Provided by VIA upon request and under NDA | ||
9 | |||
10 | Authors: Juerg Haefliger <juergh@gmail.com> | ||
11 | |||
12 | This driver is based on the driver for kernel 2.4 by Mark D. Studebaker and | ||
13 | its port to kernel 2.6 by Lars Ekman. | ||
14 | |||
15 | Thanks to Joseph Chan and Fiona Gatt from VIA for providing documentation and | ||
16 | technical support. | ||
17 | |||
18 | |||
19 | Module Parameters | ||
20 | ----------------- | ||
21 | |||
22 | * uch_config: int Override the BIOS default universal channel (UCH) | ||
23 | configuration for channels 1-5. | ||
24 | Legal values are in the range of 0-31. Bit 0 maps to | ||
25 | UCH1, bit 1 maps to UCH2 and so on. Setting a bit to 1 | ||
26 | enables the thermal input of that particular UCH and | ||
27 | setting a bit to 0 enables the voltage input. | ||
28 | |||
29 | * int_mode: int Override the BIOS default temperature interrupt mode. | ||
30 | The only possible value is 0 which forces interrupt | ||
31 | mode 0. In this mode, any pending interrupt is cleared | ||
32 | when the status register is read but is regenerated as | ||
33 | long as the temperature stays above the hysteresis | ||
34 | limit. | ||
35 | |||
36 | Be aware that overriding BIOS defaults might cause some unwanted side effects! | ||
37 | |||
38 | |||
39 | Description | ||
40 | ----------- | ||
41 | |||
42 | The VIA VT1211 Super-I/O chip includes complete hardware monitoring | ||
43 | capabilities. It monitors 2 dedicated temperature sensor inputs (temp1 and | ||
44 | temp2), 1 dedicated voltage (in5) and 2 fans. Additionally, the chip | ||
45 | implements 5 universal input channels (UCH1-5) that can be individually | ||
46 | programmed to either monitor a voltage or a temperature. | ||
47 | |||
48 | This chip also provides manual and automatic control of fan speeds (according | ||
49 | to the datasheet). The driver only supports automatic control since the manual | ||
50 | mode doesn't seem to work as advertised in the datasheet. In fact I couldn't | ||
51 | get manual mode to work at all! Be aware that automatic mode hasn't been | ||
52 | tested very well (due to the fact that my EPIA M10000 doesn't have the fans | ||
53 | connected to the PWM outputs of the VT1211 :-(). | ||
54 | |||
55 | The following table shows the relationship between the vt1211 inputs and the | ||
56 | sysfs nodes. | ||
57 | |||
58 | Sensor Voltage Mode Temp Mode Default Use (from the datasheet) | ||
59 | ------ ------------ --------- -------------------------------- | ||
60 | Reading 1 temp1 Intel thermal diode | ||
61 | Reading 3 temp2 Internal thermal diode | ||
62 | UCH1/Reading2 in0 temp3 NTC type thermistor | ||
63 | UCH2 in1 temp4 +2.5V | ||
64 | UCH3 in2 temp5 VccP (processor core) | ||
65 | UCH4 in3 temp6 +5V | ||
66 | UCH5 in4 temp7 +12V | ||
67 | +3.3V in5 Internal VCC (+3.3V) | ||
68 | |||
69 | |||
70 | Voltage Monitoring | ||
71 | ------------------ | ||
72 | |||
73 | Voltages are sampled by an 8-bit ADC with a LSB of ~10mV. The supported input | ||
74 | range is thus from 0 to 2.60V. Voltage values outside of this range need | ||
75 | external scaling resistors. This external scaling needs to be compensated for | ||
76 | via compute lines in sensors.conf, like: | ||
77 | |||
78 | compute inx @*(1+R1/R2), @/(1+R1/R2) | ||
79 | |||
80 | The board level scaling resistors according to VIA's recommendation are as | ||
81 | follows. And this is of course totally dependent on the actual board | ||
82 | implementation :-) You will have to find documentation for your own | ||
83 | motherboard and edit sensors.conf accordingly. | ||
84 | |||
85 | Expected | ||
86 | Voltage R1 R2 Divider Raw Value | ||
87 | ----------------------------------------------- | ||
88 | +2.5V 2K 10K 1.2 2083 mV | ||
89 | VccP --- --- 1.0 1400 mV (1) | ||
90 | +5V 14K 10K 2.4 2083 mV | ||
91 | +12V 47K 10K 5.7 2105 mV | ||
92 | +3.3V (int) 2K 3.4K 1.588 3300 mV (2) | ||
93 | +3.3V (ext) 6.8K 10K 1.68 1964 mV | ||
94 | |||
95 | (1) Depending on the CPU (1.4V is for a VIA C3 Nehemiah). | ||
96 | (2) R1 and R2 for 3.3V (int) are internal to the VT1211 chip and the driver | ||
97 | performs the scaling and returns the properly scaled voltage value. | ||
98 | |||
99 | Each measured voltage has an associated low and high limit which triggers an | ||
100 | alarm when crossed. | ||
101 | |||
102 | |||
103 | Temperature Monitoring | ||
104 | ---------------------- | ||
105 | |||
106 | Temperatures are reported in millidegree Celsius. Each measured temperature | ||
107 | has a high limit which triggers an alarm if crossed. There is an associated | ||
108 | hysteresis value with each temperature below which the temperature has to drop | ||
109 | before the alarm is cleared (this is only true for interrupt mode 0). The | ||
110 | interrupt mode can be forced to 0 in case the BIOS doesn't do it | ||
111 | automatically. See the 'Module Parameters' section for details. | ||
112 | |||
113 | All temperature channels except temp2 are external. Temp2 is the VT1211 | ||
114 | internal thermal diode and the driver does all the scaling for temp2 and | ||
115 | returns the temperature in millidegree Celsius. For the external channels | ||
116 | temp1 and temp3-temp7, scaling depends on the board implementation and needs | ||
117 | to be performed in userspace via sensors.conf. | ||
118 | |||
119 | Temp1 is an Intel-type thermal diode which requires the following formula to | ||
120 | convert between sysfs readings and real temperatures: | ||
121 | |||
122 | compute temp1 (@-Offset)/Gain, (@*Gain)+Offset | ||
123 | |||
124 | According to the VIA VT1211 BIOS porting guide, the following gain and offset | ||
125 | values should be used: | ||
126 | |||
127 | Diode Type Offset Gain | ||
128 | ---------- ------ ---- | ||
129 | Intel CPU 88.638 0.9528 | ||
130 | 65.000 0.9686 *) | ||
131 | VIA C3 Ezra 83.869 0.9528 | ||
132 | VIA C3 Ezra-T 73.869 0.9528 | ||
133 | |||
134 | *) This is the formula from the lm_sensors 2.10.0 sensors.conf file. I don't | ||
135 | know where it comes from or how it was derived, it's just listed here for | ||
136 | completeness. | ||
137 | |||
138 | Temp3-temp7 support NTC thermistors. For these channels, the driver returns | ||
139 | the voltages as seen at the individual pins of UCH1-UCH5. The voltage at the | ||
140 | pin (Vpin) is formed by a voltage divider made of the thermistor (Rth) and a | ||
141 | scaling resistor (Rs): | ||
142 | |||
143 | Vpin = 2200 * Rth / (Rs + Rth) (2200 is the ADC max limit of 2200 mV) | ||
144 | |||
145 | The equation for the thermistor is as follows (google it if you want to know | ||
146 | more about it): | ||
147 | |||
148 | Rth = Ro * exp(B * (1 / T - 1 / To)) (To is 298.15K (25C) and Ro is the | ||
149 | nominal resistance at 25C) | ||
150 | |||
151 | Mingling the above two equations and assuming Rs = Ro and B = 3435 yields the | ||
152 | following formula for sensors.conf: | ||
153 | |||
154 | compute tempx 1 / (1 / 298.15 - (` (2200 / @ - 1)) / 3435) - 273.15, | ||
155 | 2200 / (1 + (^ (3435 / 298.15 - 3435 / (273.15 + @)))) | ||
156 | |||
157 | |||
158 | Fan Speed Control | ||
159 | ----------------- | ||
160 | |||
161 | The VT1211 provides 2 programmable PWM outputs to control the speeds of 2 | ||
162 | fans. Writing a 2 to any of the two pwm[1-2]_enable sysfs nodes will put the | ||
163 | PWM controller in automatic mode. There is only a single controller that | ||
164 | controls both PWM outputs but each PWM output can be individually enabled and | ||
165 | disabled. | ||
166 | |||
167 | Each PWM has 4 associated distinct output duty-cycles: full, high, low and | ||
168 | off. Full and off are internally hard-wired to 255 (100%) and 0 (0%), | ||
169 | respectively. High and low can be programmed via | ||
170 | pwm[1-2]_auto_point[2-3]_pwm. Each PWM output can be associated with a | ||
171 | different thermal input but - and here's the weird part - only one set of | ||
172 | thermal thresholds exist that controls both PWMs output duty-cycles. The | ||
173 | thermal thresholds are accessible via pwm[1-2]_auto_point[1-4]_temp. Note | ||
174 | that even though there are 2 sets of 4 auto points each, they map to the same | ||
175 | registers in the VT1211 and programming one set is sufficient (actually only | ||
176 | the first set pwm1_auto_point[1-4]_temp is writable, the second set is | ||
177 | read-only). | ||
178 | |||
179 | PWM Auto Point PWM Output Duty-Cycle | ||
180 | ------------------------------------------------ | ||
181 | pwm[1-2]_auto_point4_pwm full speed duty-cycle (hard-wired to 255) | ||
182 | pwm[1-2]_auto_point3_pwm high speed duty-cycle | ||
183 | pwm[1-2]_auto_point2_pwm low speed duty-cycle | ||
184 | pwm[1-2]_auto_point1_pwm off duty-cycle (hard-wired to 0) | ||
185 | |||
186 | Temp Auto Point Thermal Threshold | ||
187 | --------------------------------------------- | ||
188 | pwm[1-2]_auto_point4_temp full speed temp | ||
189 | pwm[1-2]_auto_point3_temp high speed temp | ||
190 | pwm[1-2]_auto_point2_temp low speed temp | ||
191 | pwm[1-2]_auto_point1_temp off temp | ||
192 | |||
193 | Long story short, the controller implements the following algorithm to set the | ||
194 | PWM output duty-cycle based on the input temperature: | ||
195 | |||
196 | Thermal Threshold Output Duty-Cycle | ||
197 | (Rising Temp) (Falling Temp) | ||
198 | ---------------------------------------------------------- | ||
199 | full speed duty-cycle full speed duty-cycle | ||
200 | full speed temp | ||
201 | high speed duty-cycle full speed duty-cycle | ||
202 | high speed temp | ||
203 | low speed duty-cycle high speed duty-cycle | ||
204 | low speed temp | ||
205 | off duty-cycle low speed duty-cycle | ||
206 | off temp | ||
diff --git a/Documentation/hwmon/w83627ehf b/Documentation/hwmon/w83627ehf new file mode 100644 index 000000000000..fae3b781d82d --- /dev/null +++ b/Documentation/hwmon/w83627ehf | |||
@@ -0,0 +1,85 @@ | |||
1 | Kernel driver w83627ehf | ||
2 | ======================= | ||
3 | |||
4 | Supported chips: | ||
5 | * Winbond W83627EHF/EHG (ISA access ONLY) | ||
6 | Prefix: 'w83627ehf' | ||
7 | Addresses scanned: ISA address retrieved from Super I/O registers | ||
8 | Datasheet: http://www.winbond-usa.com/products/winbond_products/pdfs/PCIC/W83627EHF_%20W83627EHGb.pdf | ||
9 | |||
10 | Authors: | ||
11 | Jean Delvare <khali@linux-fr.org> | ||
12 | Yuan Mu (Winbond) | ||
13 | Rudolf Marek <r.marek@sh.cvut.cz> | ||
14 | |||
15 | Description | ||
16 | ----------- | ||
17 | |||
18 | This driver implements support for the Winbond W83627EHF and W83627EHG | ||
19 | super I/O chips. We will refer to them collectively as Winbond chips. | ||
20 | |||
21 | The chips implement three temperature sensors, five fan rotation | ||
22 | speed sensors, ten analog voltage sensors, alarms with beep warnings (control | ||
23 | unimplemented), and some automatic fan regulation strategies (plus manual | ||
24 | fan control mode). | ||
25 | |||
26 | Temperatures are measured in degrees Celsius and measurement resolution is 1 | ||
27 | degC for temp1 and 0.5 degC for temp2 and temp3. An alarm is triggered when | ||
28 | the temperature gets higher than high limit; it stays on until the temperature | ||
29 | falls below the Hysteresis value. | ||
30 | |||
31 | Fan rotation speeds are reported in RPM (rotations per minute). An alarm is | ||
32 | triggered if the rotation speed has dropped below a programmable limit. Fan | ||
33 | readings can be divided by a programmable divider (1, 2, 4, 8, 16, 32, 64 or | ||
34 | 128) to give the readings more range or accuracy. The driver sets the most | ||
35 | suitable fan divisor itself. Some fans might not be present because they | ||
36 | share pins with other functions. | ||
37 | |||
38 | Voltage sensors (also known as IN sensors) report their values in millivolts. | ||
39 | An alarm is triggered if the voltage has crossed a programmable minimum | ||
40 | or maximum limit. | ||
41 | |||
42 | The driver supports automatic fan control mode known as Thermal Cruise. | ||
43 | In this mode, the chip attempts to keep the measured temperature in a | ||
44 | predefined temperature range. If the temperature goes out of range, fan | ||
45 | is driven slower/faster to reach the predefined range again. | ||
46 | |||
47 | The mode works for fan1-fan4. Mapping of temperatures to pwm outputs is as | ||
48 | follows: | ||
49 | |||
50 | temp1 -> pwm1 | ||
51 | temp2 -> pwm2 | ||
52 | temp3 -> pwm3 | ||
53 | prog -> pwm4 (the programmable setting is not supported by the driver) | ||
54 | |||
55 | /sys files | ||
56 | ---------- | ||
57 | |||
58 | pwm[1-4] - this file stores PWM duty cycle or DC value (fan speed) in range: | ||
59 | 0 (stop) to 255 (full) | ||
60 | |||
61 | pwm[1-4]_enable - this file controls mode of fan/temperature control: | ||
62 | * 1 Manual Mode, write to pwm file any value 0-255 (full speed) | ||
63 | * 2 Thermal Cruise | ||
64 | |||
65 | Thermal Cruise mode | ||
66 | ------------------- | ||
67 | |||
68 | If the temperature is in the range defined by: | ||
69 | |||
70 | pwm[1-4]_target - set target temperature, unit millidegree Celcius | ||
71 | (range 0 - 127000) | ||
72 | pwm[1-4]_tolerance - tolerance, unit millidegree Celcius (range 0 - 15000) | ||
73 | |||
74 | there are no changes to fan speed. Once the temperature leaves the interval, | ||
75 | fan speed increases (temp is higher) or decreases if lower than desired. | ||
76 | There are defined steps and times, but not exported by the driver yet. | ||
77 | |||
78 | pwm[1-4]_min_output - minimum fan speed (range 1 - 255), when the temperature | ||
79 | is below defined range. | ||
80 | pwm[1-4]_stop_time - how many milliseconds [ms] must elapse to switch | ||
81 | corresponding fan off. (when the temperature was below | ||
82 | defined range). | ||
83 | |||
84 | Note: last two functions are influenced by other control bits, not yet exported | ||
85 | by the driver, so a change might not have any effect. | ||
diff --git a/Documentation/hwmon/w83791d b/Documentation/hwmon/w83791d index 83a3836289c2..19b2ed739fa1 100644 --- a/Documentation/hwmon/w83791d +++ b/Documentation/hwmon/w83791d | |||
@@ -5,7 +5,7 @@ Supported chips: | |||
5 | * Winbond W83791D | 5 | * Winbond W83791D |
6 | Prefix: 'w83791d' | 6 | Prefix: 'w83791d' |
7 | Addresses scanned: I2C 0x2c - 0x2f | 7 | Addresses scanned: I2C 0x2c - 0x2f |
8 | Datasheet: http://www.winbond-usa.com/products/winbond_products/pdfs/PCIC/W83791Da.pdf | 8 | Datasheet: http://www.winbond-usa.com/products/winbond_products/pdfs/PCIC/W83791D_W83791Gb.pdf |
9 | 9 | ||
10 | Author: Charles Spirakis <bezaur@gmail.com> | 10 | Author: Charles Spirakis <bezaur@gmail.com> |
11 | 11 | ||
@@ -20,6 +20,9 @@ Credits: | |||
20 | Chunhao Huang <DZShen@Winbond.com.tw>, | 20 | Chunhao Huang <DZShen@Winbond.com.tw>, |
21 | Rudolf Marek <r.marek@sh.cvut.cz> | 21 | Rudolf Marek <r.marek@sh.cvut.cz> |
22 | 22 | ||
23 | Additional contributors: | ||
24 | Sven Anders <anders@anduras.de> | ||
25 | |||
23 | Module Parameters | 26 | Module Parameters |
24 | ----------------- | 27 | ----------------- |
25 | 28 | ||
@@ -46,7 +49,8 @@ Module Parameters | |||
46 | Description | 49 | Description |
47 | ----------- | 50 | ----------- |
48 | 51 | ||
49 | This driver implements support for the Winbond W83791D chip. | 52 | This driver implements support for the Winbond W83791D chip. The W83791G |
53 | chip appears to be the same as the W83791D but is lead free. | ||
50 | 54 | ||
51 | Detection of the chip can sometimes be foiled because it can be in an | 55 | Detection of the chip can sometimes be foiled because it can be in an |
52 | internal state that allows no clean access (Bank with ID register is not | 56 | internal state that allows no clean access (Bank with ID register is not |
@@ -71,34 +75,36 @@ Voltage sensors (also known as IN sensors) report their values in millivolts. | |||
71 | An alarm is triggered if the voltage has crossed a programmable minimum | 75 | An alarm is triggered if the voltage has crossed a programmable minimum |
72 | or maximum limit. | 76 | or maximum limit. |
73 | 77 | ||
74 | Alarms are provided as output from a "realtime status register". The | 78 | The bit ordering for the alarm "realtime status register" and the |
75 | following bits are defined: | 79 | "beep enable registers" are different. |
76 | 80 | ||
77 | bit - alarm on: | 81 | in0 (VCORE) : alarms: 0x000001 beep_enable: 0x000001 |
78 | 0 - Vcore | 82 | in1 (VINR0) : alarms: 0x000002 beep_enable: 0x002000 <== mismatch |
79 | 1 - VINR0 | 83 | in2 (+3.3VIN): alarms: 0x000004 beep_enable: 0x000004 |
80 | 2 - +3.3VIN | 84 | in3 (5VDD) : alarms: 0x000008 beep_enable: 0x000008 |
81 | 3 - 5VDD | 85 | in4 (+12VIN) : alarms: 0x000100 beep_enable: 0x000100 |
82 | 4 - temp1 | 86 | in5 (-12VIN) : alarms: 0x000200 beep_enable: 0x000200 |
83 | 5 - temp2 | 87 | in6 (-5VIN) : alarms: 0x000400 beep_enable: 0x000400 |
84 | 6 - fan1 | 88 | in7 (VSB) : alarms: 0x080000 beep_enable: 0x010000 <== mismatch |
85 | 7 - fan2 | 89 | in8 (VBAT) : alarms: 0x100000 beep_enable: 0x020000 <== mismatch |
86 | 8 - +12VIN | 90 | in9 (VINR1) : alarms: 0x004000 beep_enable: 0x004000 |
87 | 9 - -12VIN | 91 | temp1 : alarms: 0x000010 beep_enable: 0x000010 |
88 | 10 - -5VIN | 92 | temp2 : alarms: 0x000020 beep_enable: 0x000020 |
89 | 11 - fan3 | 93 | temp3 : alarms: 0x002000 beep_enable: 0x000002 <== mismatch |
90 | 12 - chassis | 94 | fan1 : alarms: 0x000040 beep_enable: 0x000040 |
91 | 13 - temp3 | 95 | fan2 : alarms: 0x000080 beep_enable: 0x000080 |
92 | 14 - VINR1 | 96 | fan3 : alarms: 0x000800 beep_enable: 0x000800 |
93 | 15 - reserved | 97 | fan4 : alarms: 0x200000 beep_enable: 0x200000 |
94 | 16 - tart1 | 98 | fan5 : alarms: 0x400000 beep_enable: 0x400000 |
95 | 17 - tart2 | 99 | tart1 : alarms: 0x010000 beep_enable: 0x040000 <== mismatch |
96 | 18 - tart3 | 100 | tart2 : alarms: 0x020000 beep_enable: 0x080000 <== mismatch |
97 | 19 - VSB | 101 | tart3 : alarms: 0x040000 beep_enable: 0x100000 <== mismatch |
98 | 20 - VBAT | 102 | case_open : alarms: 0x001000 beep_enable: 0x001000 |
99 | 21 - fan4 | 103 | user_enable : alarms: -------- beep_enable: 0x800000 |
100 | 22 - fan5 | 104 | |
101 | 23 - reserved | 105 | *** NOTE: It is the responsibility of user-space code to handle the fact |
106 | that the beep enable and alarm bits are in different positions when using that | ||
107 | feature of the chip. | ||
102 | 108 | ||
103 | When an alarm goes off, you can be warned by a beeping signal through your | 109 | When an alarm goes off, you can be warned by a beeping signal through your |
104 | computer speaker. It is possible to enable all beeping globally, or only | 110 | computer speaker. It is possible to enable all beeping globally, or only |
@@ -109,5 +115,6 @@ often will do no harm, but will return 'old' values. | |||
109 | 115 | ||
110 | W83791D TODO: | 116 | W83791D TODO: |
111 | --------------- | 117 | --------------- |
112 | Provide a patch for per-file alarms as discussed on the mailing list | 118 | Provide a patch for per-file alarms and beep enables as defined in the hwmon |
119 | documentation (Documentation/hwmon/sysfs-interface) | ||
113 | Provide a patch for smart-fan control (still need appropriate motherboard/fans) | 120 | Provide a patch for smart-fan control (still need appropriate motherboard/fans) |
diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index 54983246930d..137e993f4329 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt | |||
@@ -110,6 +110,13 @@ be entered as an environment variable, whereas its absence indicates that | |||
110 | it will appear as a kernel argument readable via /proc/cmdline by programs | 110 | it will appear as a kernel argument readable via /proc/cmdline by programs |
111 | running once the system is up. | 111 | running once the system is up. |
112 | 112 | ||
113 | The number of kernel parameters is not limited, but the length of the | ||
114 | complete command line (parameters including spaces etc.) is limited to | ||
115 | a fixed number of characters. This limit depends on the architecture | ||
116 | and is between 256 and 4096 characters. It is defined in the file | ||
117 | ./include/asm/setup.h as COMMAND_LINE_SIZE. | ||
118 | |||
119 | |||
113 | 53c7xx= [HW,SCSI] Amiga SCSI controllers | 120 | 53c7xx= [HW,SCSI] Amiga SCSI controllers |
114 | See header of drivers/scsi/53c7xx.c. | 121 | See header of drivers/scsi/53c7xx.c. |
115 | See also Documentation/scsi/ncr53c7xx.txt. | 122 | See also Documentation/scsi/ncr53c7xx.txt. |
@@ -1324,7 +1331,7 @@ running once the system is up. | |||
1324 | pt. [PARIDE] | 1331 | pt. [PARIDE] |
1325 | See Documentation/paride.txt. | 1332 | See Documentation/paride.txt. |
1326 | 1333 | ||
1327 | quiet= [KNL] Disable log messages | 1334 | quiet [KNL] Disable most log messages |
1328 | 1335 | ||
1329 | r128= [HW,DRM] | 1336 | r128= [HW,DRM] |
1330 | 1337 | ||
diff --git a/Documentation/networking/pktgen.txt b/Documentation/networking/pktgen.txt index 44f2f769e865..18d385c068fc 100644 --- a/Documentation/networking/pktgen.txt +++ b/Documentation/networking/pktgen.txt | |||
@@ -100,6 +100,7 @@ Examples: | |||
100 | are: IPSRC_RND #IP Source is random (between min/max), | 100 | are: IPSRC_RND #IP Source is random (between min/max), |
101 | IPDST_RND, UDPSRC_RND, | 101 | IPDST_RND, UDPSRC_RND, |
102 | UDPDST_RND, MACSRC_RND, MACDST_RND | 102 | UDPDST_RND, MACSRC_RND, MACDST_RND |
103 | MPLS_RND, VID_RND, SVID_RND | ||
103 | 104 | ||
104 | pgset "udp_src_min 9" set UDP source port min, If < udp_src_max, then | 105 | pgset "udp_src_min 9" set UDP source port min, If < udp_src_max, then |
105 | cycle through the port range. | 106 | cycle through the port range. |
@@ -125,6 +126,21 @@ Examples: | |||
125 | 126 | ||
126 | pgset "mpls 0" turn off mpls (or any invalid argument works too!) | 127 | pgset "mpls 0" turn off mpls (or any invalid argument works too!) |
127 | 128 | ||
129 | pgset "vlan_id 77" set VLAN ID 0-4095 | ||
130 | pgset "vlan_p 3" set priority bit 0-7 (default 0) | ||
131 | pgset "vlan_cfi 0" set canonical format identifier 0-1 (default 0) | ||
132 | |||
133 | pgset "svlan_id 22" set SVLAN ID 0-4095 | ||
134 | pgset "svlan_p 3" set priority bit 0-7 (default 0) | ||
135 | pgset "svlan_cfi 0" set canonical format identifier 0-1 (default 0) | ||
136 | |||
137 | pgset "vlan_id 9999" > 4095 remove vlan and svlan tags | ||
138 | pgset "svlan 9999" > 4095 remove svlan tag | ||
139 | |||
140 | |||
141 | pgset "tos XX" set former IPv4 TOS field (e.g. "tos 28" for AF11 no ECN, default 00) | ||
142 | pgset "traffic_class XX" set former IPv6 TRAFFIC CLASS (e.g. "traffic_class B8" for EF no ECN, default 00) | ||
143 | |||
128 | pgset stop aborts injection. Also, ^C aborts generator. | 144 | pgset stop aborts injection. Also, ^C aborts generator. |
129 | 145 | ||
130 | 146 | ||
diff --git a/Documentation/seclvl.txt b/Documentation/seclvl.txt deleted file mode 100644 index 97274d122d0e..000000000000 --- a/Documentation/seclvl.txt +++ /dev/null | |||
@@ -1,97 +0,0 @@ | |||
1 | BSD Secure Levels Linux Security Module | ||
2 | Michael A. Halcrow <mike@halcrow.us> | ||
3 | |||
4 | |||
5 | Introduction | ||
6 | |||
7 | Under the BSD Secure Levels security model, sets of policies are | ||
8 | associated with levels. Levels range from -1 to 2, with -1 being the | ||
9 | weakest and 2 being the strongest. These security policies are | ||
10 | enforced at the kernel level, so not even the superuser is able to | ||
11 | disable or circumvent them. This hardens the machine against attackers | ||
12 | who gain root access to the system. | ||
13 | |||
14 | |||
15 | Levels and Policies | ||
16 | |||
17 | Level -1 (Permanently Insecure): | ||
18 | - Cannot increase the secure level | ||
19 | |||
20 | Level 0 (Insecure): | ||
21 | - Cannot ptrace the init process | ||
22 | |||
23 | Level 1 (Default): | ||
24 | - /dev/mem and /dev/kmem are read-only | ||
25 | - IMMUTABLE and APPEND extended attributes, if set, may not be unset | ||
26 | - Cannot load or unload kernel modules | ||
27 | - Cannot write directly to a mounted block device | ||
28 | - Cannot perform raw I/O operations | ||
29 | - Cannot perform network administrative tasks | ||
30 | - Cannot setuid any file | ||
31 | |||
32 | Level 2 (Secure): | ||
33 | - Cannot decrement the system time | ||
34 | - Cannot write to any block device, whether mounted or not | ||
35 | - Cannot unmount any mounted filesystems | ||
36 | |||
37 | |||
38 | Compilation | ||
39 | |||
40 | To compile the BSD Secure Levels LSM, seclvl.ko, enable the | ||
41 | SECURITY_SECLVL configuration option. This is found under Security | ||
42 | options -> BSD Secure Levels in the kernel configuration menu. | ||
43 | |||
44 | |||
45 | Basic Usage | ||
46 | |||
47 | Once the machine is in a running state, with all the necessary modules | ||
48 | loaded and all the filesystems mounted, you can load the seclvl.ko | ||
49 | module: | ||
50 | |||
51 | # insmod seclvl.ko | ||
52 | |||
53 | The module defaults to secure level 1, except when compiled directly | ||
54 | into the kernel, in which case it defaults to secure level 0. To raise | ||
55 | the secure level to 2, the administrator writes ``2'' to the | ||
56 | seclvl/seclvl file under the sysfs mount point (assumed to be /sys in | ||
57 | these examples): | ||
58 | |||
59 | # echo -n "2" > /sys/seclvl/seclvl | ||
60 | |||
61 | Alternatively, you can initialize the module at secure level 2 with | ||
62 | the initlvl module parameter: | ||
63 | |||
64 | # insmod seclvl.ko initlvl=2 | ||
65 | |||
66 | At this point, it is impossible to remove the module or reduce the | ||
67 | secure level. If the administrator wishes to have the option of doing | ||
68 | so, he must provide a module parameter, sha1_passwd, that specifies | ||
69 | the SHA1 hash of the password that can be used to reduce the secure | ||
70 | level to 0. | ||
71 | |||
72 | To generate this SHA1 hash, the administrator can use OpenSSL: | ||
73 | |||
74 | # echo -n "boogabooga" | openssl sha1 | ||
75 | abeda4e0f33defa51741217592bf595efb8d289c | ||
76 | |||
77 | In order to use password-instigated secure level reduction, the SHA1 | ||
78 | crypto module must be loaded or compiled into the kernel: | ||
79 | |||
80 | # insmod sha1.ko | ||
81 | |||
82 | The administrator can then insmod the seclvl module, including the | ||
83 | SHA1 hash of the password: | ||
84 | |||
85 | # insmod seclvl.ko | ||
86 | sha1_passwd=abeda4e0f33defa51741217592bf595efb8d289c | ||
87 | |||
88 | To reduce the secure level, write the password to seclvl/passwd under | ||
89 | your sysfs mount point: | ||
90 | |||
91 | # echo -n "boogabooga" > /sys/seclvl/passwd | ||
92 | |||
93 | The September 2004 edition of Sys Admin Magazine has an article about | ||
94 | the BSD Secure Levels LSM. I encourage you to refer to that article | ||
95 | for a more in-depth treatment of this security module: | ||
96 | |||
97 | http://www.samag.com/documents/s=9304/sam0409a/0409a.htm | ||
diff --git a/Documentation/video4linux/CARDLIST.cx88 b/Documentation/video4linux/CARDLIST.cx88 index 00d9a1f2a54c..669a09aa5bb4 100644 --- a/Documentation/video4linux/CARDLIST.cx88 +++ b/Documentation/video4linux/CARDLIST.cx88 | |||
@@ -7,10 +7,10 @@ | |||
7 | 6 -> AverTV Studio 303 (M126) [1461:000b] | 7 | 6 -> AverTV Studio 303 (M126) [1461:000b] |
8 | 7 -> MSI TV-@nywhere Master [1462:8606] | 8 | 7 -> MSI TV-@nywhere Master [1462:8606] |
9 | 8 -> Leadtek Winfast DV2000 [107d:6620] | 9 | 8 -> Leadtek Winfast DV2000 [107d:6620] |
10 | 9 -> Leadtek PVR 2000 [107d:663b,107d:663C] | 10 | 9 -> Leadtek PVR 2000 [107d:663b,107d:663c,107d:6632] |
11 | 10 -> IODATA GV-VCP3/PCI [10fc:d003] | 11 | 10 -> IODATA GV-VCP3/PCI [10fc:d003] |
12 | 11 -> Prolink PlayTV PVR | 12 | 11 -> Prolink PlayTV PVR |
13 | 12 -> ASUS PVR-416 [1043:4823] | 13 | 12 -> ASUS PVR-416 [1043:4823,1461:c111] |
14 | 13 -> MSI TV-@nywhere | 14 | 13 -> MSI TV-@nywhere |
15 | 14 -> KWorld/VStream XPert DVB-T [17de:08a6] | 15 | 14 -> KWorld/VStream XPert DVB-T [17de:08a6] |
16 | 15 -> DViCO FusionHDTV DVB-T1 [18ac:db00] | 16 | 15 -> DViCO FusionHDTV DVB-T1 [18ac:db00] |
@@ -51,3 +51,7 @@ | |||
51 | 50 -> NPG Tech Real TV FM Top 10 [14f1:0842] | 51 | 50 -> NPG Tech Real TV FM Top 10 [14f1:0842] |
52 | 51 -> WinFast DTV2000 H [107d:665e] | 52 | 51 -> WinFast DTV2000 H [107d:665e] |
53 | 52 -> Geniatech DVB-S [14f1:0084] | 53 | 52 -> Geniatech DVB-S [14f1:0084] |
54 | 53 -> Hauppauge WinTV-HVR3000 TriMode Analog/DVB-S/DVB-T [0070:1404] | ||
55 | 54 -> Norwood Micro TV Tuner | ||
56 | 55 -> Shenzhen Tungsten Ages Tech TE-DTV-250 / Swann OEM [c180:c980] | ||
57 | 56 -> Hauppauge WinTV-HVR1300 DVB-T/Hybrid MPEG Encoder [0070:9600,0070:9601,0070:9602] | ||
diff --git a/Documentation/video4linux/CARDLIST.saa7134 b/Documentation/video4linux/CARDLIST.saa7134 index 9068b669f5ee..94cf695b1378 100644 --- a/Documentation/video4linux/CARDLIST.saa7134 +++ b/Documentation/video4linux/CARDLIST.saa7134 | |||
@@ -58,7 +58,7 @@ | |||
58 | 57 -> Avermedia AVerTV GO 007 FM [1461:f31f] | 58 | 57 -> Avermedia AVerTV GO 007 FM [1461:f31f] |
59 | 58 -> ADS Tech Instant TV (saa7135) [1421:0350,1421:0351,1421:0370,1421:1370] | 59 | 58 -> ADS Tech Instant TV (saa7135) [1421:0350,1421:0351,1421:0370,1421:1370] |
60 | 59 -> Kworld/Tevion V-Stream Xpert TV PVR7134 | 60 | 59 -> Kworld/Tevion V-Stream Xpert TV PVR7134 |
61 | 60 -> LifeView/Typhoon FlyDVB-T Duo Cardbus [5168:0502,4e42:0502] | 61 | 60 -> LifeView/Typhoon/Genius FlyDVB-T Duo Cardbus [5168:0502,4e42:0502,1489:0502] |
62 | 61 -> Philips TOUGH DVB-T reference design [1131:2004] | 62 | 61 -> Philips TOUGH DVB-T reference design [1131:2004] |
63 | 62 -> Compro VideoMate TV Gold+II | 63 | 62 -> Compro VideoMate TV Gold+II |
64 | 63 -> Kworld Xpert TV PVR7134 | 64 | 63 -> Kworld Xpert TV PVR7134 |
@@ -83,7 +83,7 @@ | |||
83 | 82 -> MSI TV@Anywhere plus [1462:6231] | 83 | 82 -> MSI TV@Anywhere plus [1462:6231] |
84 | 83 -> Terratec Cinergy 250 PCI TV [153b:1160] | 84 | 83 -> Terratec Cinergy 250 PCI TV [153b:1160] |
85 | 84 -> LifeView FlyDVB Trio [5168:0319] | 85 | 84 -> LifeView FlyDVB Trio [5168:0319] |
86 | 85 -> AverTV DVB-T 777 [1461:2c05] | 86 | 85 -> AverTV DVB-T 777 [1461:2c05,1461:2c05] |
87 | 86 -> LifeView FlyDVB-T / Genius VideoWonder DVB-T [5168:0301,1489:0301] | 87 | 86 -> LifeView FlyDVB-T / Genius VideoWonder DVB-T [5168:0301,1489:0301] |
88 | 87 -> ADS Instant TV Duo Cardbus PTV331 [0331:1421] | 88 | 87 -> ADS Instant TV Duo Cardbus PTV331 [0331:1421] |
89 | 88 -> Tevion/KWorld DVB-T 220RF [17de:7201] | 89 | 88 -> Tevion/KWorld DVB-T 220RF [17de:7201] |
@@ -94,3 +94,6 @@ | |||
94 | 93 -> Medion 7134 Bridge #2 [16be:0005] | 94 | 93 -> Medion 7134 Bridge #2 [16be:0005] |
95 | 94 -> LifeView FlyDVB-T Hybrid Cardbus [5168:3306,5168:3502] | 95 | 94 -> LifeView FlyDVB-T Hybrid Cardbus [5168:3306,5168:3502] |
96 | 95 -> LifeView FlyVIDEO3000 (NTSC) [5169:0138] | 96 | 95 -> LifeView FlyVIDEO3000 (NTSC) [5169:0138] |
97 | 96 -> Medion Md8800 Quadro [16be:0007,16be:0008] | ||
98 | 97 -> LifeView FlyDVB-S /Acorp TV134DS [5168:0300,4e42:0300] | ||
99 | 98 -> Proteus Pro 2309 [0919:2003] | ||
diff --git a/Documentation/video4linux/bttv/Insmod-options b/Documentation/video4linux/bttv/Insmod-options index fc94ff235ffa..bb7c2cac7917 100644 --- a/Documentation/video4linux/bttv/Insmod-options +++ b/Documentation/video4linux/bttv/Insmod-options | |||
@@ -54,6 +54,12 @@ bttv.o | |||
54 | dropouts. | 54 | dropouts. |
55 | chroma_agc=0/1 AGC of chroma signal, off by default. | 55 | chroma_agc=0/1 AGC of chroma signal, off by default. |
56 | adc_crush=0/1 Luminance ADC crush, on by default. | 56 | adc_crush=0/1 Luminance ADC crush, on by default. |
57 | i2c_udelay= Allow reduce I2C speed. Default is 5 usecs | ||
58 | (meaning 66,67 Kbps). The default is the | ||
59 | maximum supported speed by kernel bitbang | ||
60 | algoritm. You may use lower numbers, if I2C | ||
61 | messages are lost (16 is known to work on | ||
62 | all supported cards). | ||
57 | 63 | ||
58 | bttv_gpio=0/1 | 64 | bttv_gpio=0/1 |
59 | gpiomask= | 65 | gpiomask= |
diff --git a/Documentation/video4linux/cx2341x/README.hm12 b/Documentation/video4linux/cx2341x/README.hm12 new file mode 100644 index 000000000000..0e213ed095e6 --- /dev/null +++ b/Documentation/video4linux/cx2341x/README.hm12 | |||
@@ -0,0 +1,116 @@ | |||
1 | The cx23416 can produce (and the cx23415 can also read) raw YUV output. The | ||
2 | format of a YUV frame is specific to this chip and is called HM12. 'HM' stands | ||
3 | for 'Hauppauge Macroblock', which is a misnomer as 'Conexant Macroblock' would | ||
4 | be more accurate. | ||
5 | |||
6 | The format is YUV 4:2:0 which uses 1 Y byte per pixel and 1 U and V byte per | ||
7 | four pixels. | ||
8 | |||
9 | The data is encoded as two macroblock planes, the first containing the Y | ||
10 | values, the second containing UV macroblocks. | ||
11 | |||
12 | The Y plane is divided into blocks of 16x16 pixels from left to right | ||
13 | and from top to bottom. Each block is transmitted in turn, line-by-line. | ||
14 | |||
15 | So the first 16 bytes are the first line of the top-left block, the | ||
16 | second 16 bytes are the second line of the top-left block, etc. After | ||
17 | transmitting this block the first line of the block on the right to the | ||
18 | first block is transmitted, etc. | ||
19 | |||
20 | The UV plane is divided into blocks of 16x8 UV values going from left | ||
21 | to right, top to bottom. Each block is transmitted in turn, line-by-line. | ||
22 | |||
23 | So the first 16 bytes are the first line of the top-left block and | ||
24 | contain 8 UV value pairs (16 bytes in total). The second 16 bytes are the | ||
25 | second line of 8 UV pairs of the top-left block, etc. After transmitting | ||
26 | this block the first line of the block on the right to the first block is | ||
27 | transmitted, etc. | ||
28 | |||
29 | The code below is given as an example on how to convert HM12 to separate | ||
30 | Y, U and V planes. This code assumes frames of 720x576 (PAL) pixels. | ||
31 | |||
32 | The width of a frame is always 720 pixels, regardless of the actual specified | ||
33 | width. | ||
34 | |||
35 | -------------------------------------------------------------------------- | ||
36 | |||
37 | #include <stdio.h> | ||
38 | #include <stdlib.h> | ||
39 | #include <string.h> | ||
40 | |||
41 | static unsigned char frame[576*720*3/2]; | ||
42 | static unsigned char framey[576*720]; | ||
43 | static unsigned char frameu[576*720 / 4]; | ||
44 | static unsigned char framev[576*720 / 4]; | ||
45 | |||
46 | static void de_macro_y(unsigned char* dst, unsigned char *src, int dstride, int w, int h) | ||
47 | { | ||
48 | unsigned int y, x, i; | ||
49 | |||
50 | // descramble Y plane | ||
51 | // dstride = 720 = w | ||
52 | // The Y plane is divided into blocks of 16x16 pixels | ||
53 | // Each block in transmitted in turn, line-by-line. | ||
54 | for (y = 0; y < h; y += 16) { | ||
55 | for (x = 0; x < w; x += 16) { | ||
56 | for (i = 0; i < 16; i++) { | ||
57 | memcpy(dst + x + (y + i) * dstride, src, 16); | ||
58 | src += 16; | ||
59 | } | ||
60 | } | ||
61 | } | ||
62 | } | ||
63 | |||
64 | static void de_macro_uv(unsigned char *dstu, unsigned char *dstv, unsigned char *src, int dstride, int w, int h) | ||
65 | { | ||
66 | unsigned int y, x, i; | ||
67 | |||
68 | // descramble U/V plane | ||
69 | // dstride = 720 / 2 = w | ||
70 | // The U/V values are interlaced (UVUV...). | ||
71 | // Again, the UV plane is divided into blocks of 16x16 UV values. | ||
72 | // Each block in transmitted in turn, line-by-line. | ||
73 | for (y = 0; y < h; y += 16) { | ||
74 | for (x = 0; x < w; x += 8) { | ||
75 | for (i = 0; i < 16; i++) { | ||
76 | int idx = x + (y + i) * dstride; | ||
77 | |||
78 | dstu[idx+0] = src[0]; dstv[idx+0] = src[1]; | ||
79 | dstu[idx+1] = src[2]; dstv[idx+1] = src[3]; | ||
80 | dstu[idx+2] = src[4]; dstv[idx+2] = src[5]; | ||
81 | dstu[idx+3] = src[6]; dstv[idx+3] = src[7]; | ||
82 | dstu[idx+4] = src[8]; dstv[idx+4] = src[9]; | ||
83 | dstu[idx+5] = src[10]; dstv[idx+5] = src[11]; | ||
84 | dstu[idx+6] = src[12]; dstv[idx+6] = src[13]; | ||
85 | dstu[idx+7] = src[14]; dstv[idx+7] = src[15]; | ||
86 | src += 16; | ||
87 | } | ||
88 | } | ||
89 | } | ||
90 | } | ||
91 | |||
92 | /*************************************************************************/ | ||
93 | int main(int argc, char **argv) | ||
94 | { | ||
95 | FILE *fin; | ||
96 | int i; | ||
97 | |||
98 | if (argc == 1) fin = stdin; | ||
99 | else fin = fopen(argv[1], "r"); | ||
100 | |||
101 | if (fin == NULL) { | ||
102 | fprintf(stderr, "cannot open input\n"); | ||
103 | exit(-1); | ||
104 | } | ||
105 | while (fread(frame, sizeof(frame), 1, fin) == 1) { | ||
106 | de_macro_y(framey, frame, 720, 720, 576); | ||
107 | de_macro_uv(frameu, framev, frame + 720 * 576, 720 / 2, 720 / 2, 576 / 2); | ||
108 | fwrite(framey, sizeof(framey), 1, stdout); | ||
109 | fwrite(framev, sizeof(framev), 1, stdout); | ||
110 | fwrite(frameu, sizeof(frameu), 1, stdout); | ||
111 | } | ||
112 | fclose(fin); | ||
113 | return 0; | ||
114 | } | ||
115 | |||
116 | -------------------------------------------------------------------------- | ||
diff --git a/Documentation/video4linux/cx2341x/README.vbi b/Documentation/video4linux/cx2341x/README.vbi new file mode 100644 index 000000000000..5807cf156173 --- /dev/null +++ b/Documentation/video4linux/cx2341x/README.vbi | |||
@@ -0,0 +1,45 @@ | |||
1 | |||
2 | Format of embedded V4L2_MPEG_STREAM_VBI_FMT_IVTV VBI data | ||
3 | ========================================================= | ||
4 | |||
5 | This document describes the V4L2_MPEG_STREAM_VBI_FMT_IVTV format of the VBI data | ||
6 | embedded in an MPEG-2 program stream. This format is in part dictated by some | ||
7 | hardware limitations of the ivtv driver (the driver for the Conexant cx23415/6 | ||
8 | chips), in particular a maximum size for the VBI data. Anything longer is cut | ||
9 | off when the MPEG stream is played back through the cx23415. | ||
10 | |||
11 | The advantage of this format is it is very compact and that all VBI data for | ||
12 | all lines can be stored while still fitting within the maximum allowed size. | ||
13 | |||
14 | The stream ID of the VBI data is 0xBD. The maximum size of the embedded data is | ||
15 | 4 + 43 * 36, which is 4 bytes for a header and 2 * 18 VBI lines with a 1 byte | ||
16 | header and a 42 bytes payload each. Anything beyond this limit is cut off by | ||
17 | the cx23415/6 firmware. Besides the data for the VBI lines we also need 36 bits | ||
18 | for a bitmask determining which lines are captured and 4 bytes for a magic cookie, | ||
19 | signifying that this data package contains V4L2_MPEG_STREAM_VBI_FMT_IVTV VBI data. | ||
20 | If all lines are used, then there is no longer room for the bitmask. To solve this | ||
21 | two different magic numbers were introduced: | ||
22 | |||
23 | 'itv0': After this magic number two unsigned longs follow. Bits 0-17 of the first | ||
24 | unsigned long denote which lines of the first field are captured. Bits 18-31 of | ||
25 | the first unsigned long and bits 0-3 of the second unsigned long are used for the | ||
26 | second field. | ||
27 | |||
28 | 'ITV0': This magic number assumes all VBI lines are captured, i.e. it implicitly | ||
29 | implies that the bitmasks are 0xffffffff and 0xf. | ||
30 | |||
31 | After these magic cookies (and the 8 byte bitmask in case of cookie 'itv0') the | ||
32 | captured VBI lines start: | ||
33 | |||
34 | For each line the least significant 4 bits of the first byte contain the data type. | ||
35 | Possible values are shown in the table below. The payload is in the following 42 | ||
36 | bytes. | ||
37 | |||
38 | Here is the list of possible data types: | ||
39 | |||
40 | #define IVTV_SLICED_TYPE_TELETEXT 0x1 // Teletext (uses lines 6-22 for PAL) | ||
41 | #define IVTV_SLICED_TYPE_CC 0x4 // Closed Captions (line 21 NTSC) | ||
42 | #define IVTV_SLICED_TYPE_WSS 0x5 // Wide Screen Signal (line 23 PAL) | ||
43 | #define IVTV_SLICED_TYPE_VPS 0x7 // Video Programming System (PAL) (line 16) | ||
44 | |||
45 | Hans Verkuil <hverkuil@xs4all.nl> | ||
diff --git a/Documentation/x86_64/boot-options.txt b/Documentation/x86_64/boot-options.txt index 4303e0c12476..74b77f9e91bc 100644 --- a/Documentation/x86_64/boot-options.txt +++ b/Documentation/x86_64/boot-options.txt | |||
@@ -199,6 +199,11 @@ IOMMU | |||
199 | allowed overwrite iommu off workarounds for specific chipsets. | 199 | allowed overwrite iommu off workarounds for specific chipsets. |
200 | soft Use software bounce buffering (default for Intel machines) | 200 | soft Use software bounce buffering (default for Intel machines) |
201 | noaperture Don't touch the aperture for AGP. | 201 | noaperture Don't touch the aperture for AGP. |
202 | allowdac Allow DMA >4GB | ||
203 | When off all DMA over >4GB is forced through an IOMMU or bounce | ||
204 | buffering. | ||
205 | nodac Forbid DMA >4GB | ||
206 | panic Always panic when IOMMU overflows | ||
202 | 207 | ||
203 | swiotlb=pages[,force] | 208 | swiotlb=pages[,force] |
204 | 209 | ||