diff options
Diffstat (limited to 'Documentation')
| -rw-r--r-- | Documentation/ABI/testing/sysfs-power | 17 | ||||
| -rw-r--r-- | Documentation/DocBook/Makefile | 2 | ||||
| -rw-r--r-- | Documentation/DocBook/filesystems.tmpl (renamed from Documentation/DocBook/journal-api.tmpl) | 252 | ||||
| -rw-r--r-- | Documentation/DocBook/kernel-api.tmpl | 60 | ||||
| -rw-r--r-- | Documentation/accounting/getdelays.c | 2 | ||||
| -rw-r--r-- | Documentation/feature-removal-schedule.txt | 12 | ||||
| -rw-r--r-- | Documentation/filesystems/udf.txt | 13 | ||||
| -rw-r--r-- | Documentation/kernel-doc-nano-HOWTO.txt | 2 | ||||
| -rw-r--r-- | Documentation/kernel-parameters.txt | 4 | ||||
| -rw-r--r-- | Documentation/kprobes.txt | 5 | ||||
| -rw-r--r-- | Documentation/memory-barriers.txt | 2 | ||||
| -rw-r--r-- | Documentation/mips/time.README | 49 | ||||
| -rw-r--r-- | Documentation/power/interface.txt | 13 | ||||
| -rw-r--r-- | Documentation/sound/alsa/ALSA-Configuration.txt | 2 | ||||
| -rw-r--r-- | Documentation/usb/usb-serial.txt | 6 | ||||
| -rw-r--r-- | Documentation/watchdog/src/watchdog-simple.c | 2 |
16 files changed, 227 insertions, 216 deletions
diff --git a/Documentation/ABI/testing/sysfs-power b/Documentation/ABI/testing/sysfs-power index d882f809387..dcff4d0623a 100644 --- a/Documentation/ABI/testing/sysfs-power +++ b/Documentation/ABI/testing/sysfs-power @@ -21,7 +21,7 @@ Description: these states. What: /sys/power/disk -Date: August 2006 +Date: September 2006 Contact: Rafael J. Wysocki <rjw@sisk.pl> Description: The /sys/power/disk file controls the operating mode of the @@ -39,6 +39,19 @@ Description: 'reboot' - the memory image will be saved by the kernel and the system will be rebooted. + Additionally, /sys/power/disk can be used to turn on one of the + two testing modes of the suspend-to-disk mechanism: 'testproc' + or 'test'. If the suspend-to-disk mechanism is in the + 'testproc' mode, writing 'disk' to /sys/power/state will cause + the kernel to disable nonboot CPUs and freeze tasks, wait for 5 + seconds, unfreeze tasks and enable nonboot CPUs. If it is in + the 'test' mode, writing 'disk' to /sys/power/state will cause + the kernel to disable nonboot CPUs and freeze tasks, shrink + memory, suspend devices, wait for 5 seconds, resume devices, + unfreeze tasks and enable nonboot CPUs. Then, we are able to + look in the log messages and work out, for example, which code + is being slow and which device drivers are misbehaving. + The suspend-to-disk method may be chosen by writing to this file one of the accepted strings: @@ -46,6 +59,8 @@ Description: 'platform' 'shutdown' 'reboot' + 'testproc' + 'test' It will only change to 'firmware' or 'platform' if the system supports that. diff --git a/Documentation/DocBook/Makefile b/Documentation/DocBook/Makefile index 66e1cf73357..db9499adbed 100644 --- a/Documentation/DocBook/Makefile +++ b/Documentation/DocBook/Makefile @@ -9,7 +9,7 @@ DOCBOOKS := wanbook.xml z8530book.xml mcabook.xml videobook.xml \ kernel-hacking.xml kernel-locking.xml deviceiobook.xml \ procfs-guide.xml writing_usb_driver.xml \ - kernel-api.xml journal-api.xml lsm.xml usb.xml \ + kernel-api.xml filesystems.xml lsm.xml usb.xml \ gadget.xml libata.xml mtdnand.xml librs.xml rapidio.xml \ genericirq.xml diff --git a/Documentation/DocBook/journal-api.tmpl b/Documentation/DocBook/filesystems.tmpl index 2077f9a28c1..39fa2aba7f9 100644 --- a/Documentation/DocBook/journal-api.tmpl +++ b/Documentation/DocBook/filesystems.tmpl @@ -2,39 +2,11 @@ <!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN" "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd" []> -<book id="LinuxJBDAPI"> +<book id="Linux-filesystems-API"> <bookinfo> - <title>The Linux Journalling API</title> - <authorgroup> - <author> - <firstname>Roger</firstname> - <surname>Gammans</surname> - <affiliation> - <address> - <email>rgammans@computer-surgery.co.uk</email> - </address> - </affiliation> - </author> - </authorgroup> - - <authorgroup> - <author> - <firstname>Stephen</firstname> - <surname>Tweedie</surname> - <affiliation> - <address> - <email>sct@redhat.com</email> - </address> - </affiliation> - </author> - </authorgroup> + <title>Linux Filesystems API</title> - <copyright> - <year>2002</year> - <holder>Roger Gammans</holder> - </copyright> - -<legalnotice> + <legalnotice> <para> This documentation is free software; you can redistribute it and/or modify it under the terms of the GNU General Public @@ -42,21 +14,21 @@ version 2 of the License, or (at your option) any later version. </para> - + <para> This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. </para> - + <para> You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA </para> - + <para> For more details see the file COPYING in the source distribution of Linux. @@ -66,17 +38,113 @@ <toc></toc> - <chapter id="Overview"> + <chapter id="vfs"> + <title>The Linux VFS</title> + <sect1><title>The Filesystem types</title> +!Iinclude/linux/fs.h + </sect1> + <sect1><title>The Directory Cache</title> +!Efs/dcache.c +!Iinclude/linux/dcache.h + </sect1> + <sect1><title>Inode Handling</title> +!Efs/inode.c +!Efs/bad_inode.c + </sect1> + <sect1><title>Registration and Superblocks</title> +!Efs/super.c + </sect1> + <sect1><title>File Locks</title> +!Efs/locks.c +!Ifs/locks.c + </sect1> + <sect1><title>Other Functions</title> +!Efs/mpage.c +!Efs/namei.c +!Efs/buffer.c +!Efs/bio.c +!Efs/seq_file.c +!Efs/filesystems.c +!Efs/fs-writeback.c +!Efs/block_dev.c + </sect1> + </chapter> + + <chapter id="proc"> + <title>The proc filesystem</title> + + <sect1><title>sysctl interface</title> +!Ekernel/sysctl.c + </sect1> + + <sect1><title>proc filesystem interface</title> +!Ifs/proc/base.c + </sect1> + </chapter> + + <chapter id="sysfs"> + <title>The Filesystem for Exporting Kernel Objects</title> +!Efs/sysfs/file.c +!Efs/sysfs/symlink.c +!Efs/sysfs/bin.c + </chapter> + + <chapter id="debugfs"> + <title>The debugfs filesystem</title> + + <sect1><title>debugfs interface</title> +!Efs/debugfs/inode.c +!Efs/debugfs/file.c + </sect1> + </chapter> + + <chapter id="LinuxJDBAPI"> + <chapterinfo> + <title>The Linux Journalling API</title> + + <authorgroup> + <author> + <firstname>Roger</firstname> + <surname>Gammans</surname> + <affiliation> + <address> + <email>rgammans@computer-surgery.co.uk</email> + </address> + </affiliation> + </author> + </authorgroup> + + <authorgroup> + <author> + <firstname>Stephen</firstname> + <surname>Tweedie</surname> + <affiliation> + <address> + <email>sct@redhat.com</email> + </address> + </affiliation> + </author> + </authorgroup> + + <copyright> + <year>2002</year> + <holder>Roger Gammans</holder> + </copyright> + </chapterinfo> + + <title>The Linux Journalling API</title> + + <sect1> <title>Overview</title> - <sect1> + <sect2> <title>Details</title> <para> -The journalling layer is easy to use. You need to +The journalling layer is easy to use. You need to first of all create a journal_t data structure. There are two calls to do this dependent on how you decide to allocate the physical -media on which the journal resides. The journal_init_inode() call +media on which the journal resides. The journal_init_inode() call is for journals stored in filesystem inodes, or the journal_init_dev() -call can be use for journal stored on a raw device (in a continuous range +call can be use for journal stored on a raw device (in a continuous range of blocks). A journal_t is a typedef for a struct pointer, so when you are finally finished make sure you call journal_destroy() on it to free up any used kernel memory. @@ -91,27 +159,26 @@ need to call journal_create(). <para> Most of the time however your journal file will already have been created, but before you load it you must call journal_wipe() to empty the journal file. -Hang on, you say , what if the filesystem wasn't cleanly umount()'d . Well, it is the +Hang on, you say , what if the filesystem wasn't cleanly umount()'d . Well, it is the job of the client file system to detect this and skip the call to journal_wipe(). </para> <para> In either case the next call should be to journal_load() which prepares the -journal file for use. Note that journal_wipe(..,0) calls journal_skip_recovery() +journal file for use. Note that journal_wipe(..,0) calls journal_skip_recovery() for you if it detects any outstanding transactions in the journal and similarly journal_load() will call journal_recover() if necessary. I would advise reading fs/ext3/super.c for examples on this stage. -[RGG: Why is the journal_wipe() call necessary - doesn't this needlessly -complicate the API. Or isn't a good idea for the journal layer to hide +[RGG: Why is the journal_wipe() call necessary - doesn't this needlessly +complicate the API. Or isn't a good idea for the journal layer to hide dirty mounts from the client fs] </para> <para> -Now you can go ahead and start modifying the underlying +Now you can go ahead and start modifying the underlying filesystem. Almost. </para> - <para> You still need to actually journal your filesystem changes, this @@ -138,10 +205,10 @@ individual buffers (blocks). Before you start to modify a buffer you need to call journal_get_{create,write,undo}_access() as appropriate, this allows the journalling layer to copy the unmodified data if it needs to. After all the buffer may be part of a previously uncommitted -transaction. +transaction. At this point you are at last ready to modify a buffer, and once you are have done so you need to call journal_dirty_{meta,}data(). -Or if you've asked for access to a buffer you now know is now longer +Or if you've asked for access to a buffer you now know is now longer required to be pushed back on the device you can call journal_forget() in much the same way as you might have used bforget() in the past. </para> @@ -156,7 +223,6 @@ Then at umount time , in your put_super() (2.4) or write_super() (2.5) you can then call journal_destroy() to clean up your in-core journal object. </para> - <para> Unfortunately there a couple of ways the journal layer can cause a deadlock. The first thing to note is that each task can only have @@ -164,19 +230,19 @@ a single outstanding transaction at any one time, remember nothing commits until the outermost journal_stop(). This means you must complete the transaction at the end of each file/inode/address etc. operation you perform, so that the journalling system isn't re-entered -on another journal. Since transactions can't be nested/batched +on another journal. Since transactions can't be nested/batched across differing journals, and another filesystem other than yours (say ext3) may be modified in a later syscall. </para> <para> -The second case to bear in mind is that journal_start() can -block if there isn't enough space in the journal for your transaction +The second case to bear in mind is that journal_start() can +block if there isn't enough space in the journal for your transaction (based on the passed nblocks param) - when it blocks it merely(!) needs to -wait for transactions to complete and be committed from other tasks, -so essentially we are waiting for journal_stop(). So to avoid +wait for transactions to complete and be committed from other tasks, +so essentially we are waiting for journal_stop(). So to avoid deadlocks you must treat journal_start/stop() as if they -were semaphores and include them in your semaphore ordering rules to prevent +were semaphores and include them in your semaphore ordering rules to prevent deadlocks. Note that journal_extend() has similar blocking behaviour to journal_start() so you can deadlock here just as easily as on journal_start(). </para> @@ -184,7 +250,7 @@ journal_start() so you can deadlock here just as easily as on journal_start(). <para> Try to reserve the right number of blocks the first time. ;-). This will be the maximum number of blocks you are going to touch in this transaction. -I advise having a look at at least ext3_jbd.h to see the basis on which +I advise having a look at at least ext3_jbd.h to see the basis on which ext3 uses to make these decisions. </para> @@ -193,13 +259,13 @@ Another wriggle to watch out for is your on-disk block allocation strategy. why? Because, if you undo a delete, you need to ensure you haven't reused any of the freed blocks in a later transaction. One simple way of doing this is make sure any blocks you allocate only have checkpointed transactions -listed against them. Ext3 does this in ext3_test_allocatable(). +listed against them. Ext3 does this in ext3_test_allocatable(). </para> <para> Lock is also providing through journal_{un,}lock_updates(), ext3 uses this when it wants a window with a clean and stable fs for a moment. -eg. +eg. </para> <programlisting> @@ -230,19 +296,19 @@ extend it like this:- struct journal_callback for_jbd; // Stuff for myfs allocated together. myfs_inode* i_commited; - + } </programlisting> <para> -this would be useful if you needed to know when data was committed to a +this would be useful if you needed to know when data was committed to a particular inode. </para> -</sect1> + </sect2> -<sect1> -<title>Summary</title> + <sect2> + <title>Summary</title> <para> Using the journal is a matter of wrapping the different context changes, being each mount, each modification (transaction) and each changed buffer @@ -260,15 +326,15 @@ an example. if (clean) journal_wipe(); journal_load(); - foreach(transaction) { /*transactions must be + foreach(transaction) { /*transactions must be completed before - a syscall returns to + a syscall returns to userspace*/ handle_t * xct=journal_start(my_jnrl); foreach(bh) { journal_get_{create,write,undo}_access(xact,bh); - if ( myfs_modify(bh) ) { /* returns true + if ( myfs_modify(bh) ) { /* returns true if makes changes */ journal_dirty_{meta,}data(xact,bh); } else { @@ -279,55 +345,57 @@ an example. } journal_destroy(my_jrnl); </programlisting> -</sect1> + </sect2> -</chapter> + </sect1> - <chapter id="adt"> + <sect1> <title>Data Types</title> - <para> + <para> The journalling layer uses typedefs to 'hide' the concrete definitions of the structures used. As a client of the JBD layer you can just rely on the using the pointer as a magic cookie of some sort. - + Obviously the hiding is not enforced as this is 'C'. - </para> - <sect1><title>Structures</title> + </para> + <sect2><title>Structures</title> !Iinclude/linux/jbd.h - </sect1> -</chapter> + </sect2> + </sect1> - <chapter id="calls"> + <sect1> <title>Functions</title> - <para> + <para> The functions here are split into two groups those that affect a journal as a whole, and those which are used to manage transactions -</para> - <sect1><title>Journal Level</title> + </para> + <sect2><title>Journal Level</title> !Efs/jbd/journal.c !Ifs/jbd/recovery.c - </sect1> - <sect1><title>Transasction Level</title> -!Efs/jbd/transaction.c - </sect1> -</chapter> -<chapter> + </sect2> + <sect2><title>Transasction Level</title> +!Efs/jbd/transaction.c + </sect2> + </sect1> + <sect1> <title>See also</title> <para> - <citation> + <citation> <ulink url="ftp://ftp.uk.linux.org/pub/linux/sct/fs/jfs/journal-design.ps.gz"> - Journaling the Linux ext2fs Filesystem,LinuxExpo 98, Stephen Tweedie + Journaling the Linux ext2fs Filesystem, LinuxExpo 98, Stephen Tweedie </ulink> - </citation> - </para> - <para> + </citation> + </para> + <para> <citation> <ulink url="http://olstrans.sourceforge.net/release/OLS2000-ext3/OLS2000-ext3.html"> - Ext3 Journalling FileSystem , OLS 2000, Dr. Stephen Tweedie + Ext3 Journalling FileSystem, OLS 2000, Dr. Stephen Tweedie </ulink> </citation> - </para> -</chapter> + </para> + </sect1> + + </chapter> </book> diff --git a/Documentation/DocBook/kernel-api.tmpl b/Documentation/DocBook/kernel-api.tmpl index 2b5ac604948..a166675c430 100644 --- a/Documentation/DocBook/kernel-api.tmpl +++ b/Documentation/DocBook/kernel-api.tmpl @@ -182,66 +182,6 @@ X!Ilib/string.c </sect1> </chapter> - <chapter id="vfs"> - <title>The Linux VFS</title> - <sect1><title>The Filesystem types</title> -!Iinclude/linux/fs.h - </sect1> - <sect1><title>The Directory Cache</title> -!Efs/dcache.c -!Iinclude/linux/dcache.h - </sect1> - <sect1><title>Inode Handling</title> -!Efs/inode.c -!Efs/bad_inode.c - </sect1> - <sect1><title>Registration and Superblocks</title> -!Efs/super.c - </sect1> - <sect1><title>File Locks</title> -!Efs/locks.c -!Ifs/locks.c - </sect1> - <sect1><title>Other Functions</title> -!Efs/mpage.c -!Efs/namei.c -!Efs/buffer.c -!Efs/bio.c -!Efs/seq_file.c -!Efs/filesystems.c -!Efs/fs-writeback.c -!Efs/block_dev.c - </sect1> - </chapter> - - <chapter id="proc"> - <title>The proc filesystem</title> - - <sect1><title>sysctl interface</title> -!Ekernel/sysctl.c - </sect1> - - <sect1><title>proc filesystem interface</title> -!Ifs/proc/base.c - </sect1> - </chapter> - - <chapter id="sysfs"> - <title>The Filesystem for Exporting Kernel Objects</title> -!Efs/sysfs/file.c -!Efs/sysfs/symlink.c -!Efs/sysfs/bin.c - </chapter> - - <chapter id="debugfs"> - <title>The debugfs filesystem</title> - - <sect1><title>debugfs interface</title> -!Efs/debugfs/inode.c -!Efs/debugfs/file.c - </sect1> - </chapter> - <chapter id="relayfs"> <title>relay interface support</title> diff --git a/Documentation/accounting/getdelays.c b/Documentation/accounting/getdelays.c index b11792abd6b..bf2b0e2f87e 100644 --- a/Documentation/accounting/getdelays.c +++ b/Documentation/accounting/getdelays.c @@ -49,7 +49,7 @@ __u64 stime, utime; } /* Maximum size of response requested or message sent */ -#define MAX_MSG_SIZE 256 +#define MAX_MSG_SIZE 1024 /* Maximum number of cpus expected to be specified in a cpumask */ #define MAX_CPUS 32 /* Maximum length of pathname to log file */ diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt index 1ac3c74646e..d52c4aaaf17 100644 --- a/Documentation/feature-removal-schedule.txt +++ b/Documentation/feature-removal-schedule.txt @@ -53,18 +53,6 @@ Who: Mauro Carvalho Chehab <mchehab@brturbo.com.br> --------------------------- -What: sys_sysctl -When: January 2007 -Why: The same information is available through /proc/sys and that is the - interface user space prefers to use. And there do not appear to be - any existing user in user space of sys_sysctl. The additional - maintenance overhead of keeping a set of binary names gets - in the way of doing a good job of maintaining this interface. - -Who: Eric Biederman <ebiederm@xmission.com> - ---------------------------- - What: PCMCIA control ioctl (needed for pcmcia-cs [cardmgr, cardctl]) When: November 2005 Files: drivers/pcmcia/: pcmcia_ioctl.c diff --git a/Documentation/filesystems/udf.txt b/Documentation/filesystems/udf.txt index 511b4230c05..fde829a756e 100644 --- a/Documentation/filesystems/udf.txt +++ b/Documentation/filesystems/udf.txt @@ -7,8 +7,17 @@ If you encounter problems with reading UDF discs using this driver, please report them to linux_udf@hpesjro.fc.hp.com, which is the developer's list. -Write support requires a block driver which supports writing. The current -scsi and ide cdrom drivers do not support writing. +Write support requires a block driver which supports writing. Currently +dvd+rw drives and media support true random sector writes, and so a udf +filesystem on such devices can be directly mounted read/write. CD-RW +media however, does not support this. Instead the media can be formatted +for packet mode using the utility cdrwtool, then the pktcdvd driver can +be bound to the underlying cd device to provide the required buffering +and read-modify-write cycles to allow the filesystem random sector writes +while providing the hardware with only full packet writes. While not +required for dvd+rw media, use of the pktcdvd driver often enhances +performance due to very poor read-modify-write support supplied internally +by drive firmware. ------------------------------------------------------------------------------- The following mount options are supported: diff --git a/Documentation/kernel-doc-nano-HOWTO.txt b/Documentation/kernel-doc-nano-HOWTO.txt index c65233d430f..284e7e198e9 100644 --- a/Documentation/kernel-doc-nano-HOWTO.txt +++ b/Documentation/kernel-doc-nano-HOWTO.txt @@ -17,7 +17,7 @@ are: special place-holders for where the extracted documentation should go. -- scripts/docproc.c +- scripts/basic/docproc.c This is a program for converting SGML template files into SGML files. When a file is referenced it is searched for symbols diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index dd00fd556a6..67473849f20 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -164,6 +164,10 @@ and is between 256 and 4096 characters. It is defined in the file acpi_skip_timer_override [HW,ACPI] Recognize and ignore IRQ0/pin2 Interrupt Override. For broken nForce2 BIOS resulting in XT-PIC timer. + acpi_use_timer_override [HW,ACPI} + Use timer override. For some broken Nvidia NF5 boards + that require a timer override, but don't have + HPET acpi_dbg_layer= [HW,ACPI] Format: <int> diff --git a/Documentation/kprobes.txt b/Documentation/kprobes.txt index ba26201d502..d71fafffce9 100644 --- a/Documentation/kprobes.txt +++ b/Documentation/kprobes.txt @@ -442,9 +442,10 @@ static int __init kprobe_init(void) kp.fault_handler = handler_fault; kp.symbol_name = "do_fork"; - if ((ret = register_kprobe(&kp) < 0)) { + ret = register_kprobe(&kp); + if (ret < 0) { printk("register_kprobe failed, returned %d\n", ret); - return -1; + return ret; } printk("kprobe registered\n"); return 0; diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt index 7f790f66ec6..7751704b6db 100644 --- a/Documentation/memory-barriers.txt +++ b/Documentation/memory-barriers.txt @@ -1016,7 +1016,7 @@ There are some more advanced barrier functions: (*) set_mb(var, value) - This assigns the value to the variable and then inserts at least a write + This assigns the value to the variable and then inserts a full memory barrier after it, depending on the function. It isn't guaranteed to insert anything more than a compiler barrier in a UP compilation. diff --git a/Documentation/mips/time.README b/Documentation/mips/time.README index 69ddc5c14b7..a4ce603ed3b 100644 --- a/Documentation/mips/time.README +++ b/Documentation/mips/time.README @@ -38,19 +38,14 @@ The new time code provide the following services: a) Implements functions required by Linux common code: time_init - do_gettimeofday - do_settimeofday b) provides an abstraction of RTC and null RTC implementation as default. extern unsigned long (*rtc_get_time)(void); extern int (*rtc_set_time)(unsigned long); - c) a set of gettimeoffset functions for different CPUs and different - needs. - - d) high-level and low-level timer interrupt routines where the timer - interrupt source may or may not be the CPU timer. The high-level - routine is dispatched through do_IRQ() while the low-level is + c) high-level and low-level timer interrupt routines where the timer + interrupt source may or may not be the CPU timer. The high-level + routine is dispatched through do_IRQ() while the low-level is dispatched in assemably code (usually int-handler.S) @@ -63,7 +58,7 @@ the following functions or values: a) board_time_init - a function pointer. Invoked at the beginnig of time_init(). It is optional. 1. (optional) set up RTC routines - 2. (optional) calibrate and set the mips_counter_frequency + 2. (optional) calibrate and set the mips_hpt_frequency b) plat_timer_setup - a function pointer. Invoked at the end of time_init() 1. (optional) over-ride any decisions made in time_init() @@ -72,9 +67,8 @@ the following functions or values: c) (optional) board-specific RTC routines. - d) (optional) mips_counter_frequency - It must be definied if the board - is using CPU counter for timer interrupt or it is using fixed rate - gettimeoffset(). + d) (optional) mips_hpt_frequency - It must be definied if the board + is using CPU counter for timer interrupt. PORTING GUIDE @@ -89,22 +83,12 @@ Step 1: decide how you like to implement the time services. If the answer is no, you need a timer to provide the timer interrupt at 100 HZ speed. - You cannot use the fast gettimeoffset functions, i.e., - - unsigned long fixed_rate_gettimeoffset(void); - unsigned long calibrate_div32_gettimeoffset(void); - unsigned long calibrate_div64_gettimeoffset(void); - - You can use null_gettimeoffset() will gives the same time resolution as - jiffy. Or you can implement your own gettimeoffset (probably based on - some ad hoc hardware on your machine.) - c) The following sub steps assume your CPU has counter register. Do you plan to use the CPU counter register as the timer interrupt or use an exnternal timer? In order to use CPU counter register as the timer interrupt source, you - must know the counter speed (mips_counter_frequency). It is usually the + must know the counter speed (mips_hpt_frequency). It is usually the same as the CPU speed or an integral divisor of it. d) decide on whether you want to use high-level or low-level timer @@ -121,10 +105,10 @@ Step 3: implement rtc routines, board_time_init() and plat_timer_setup() if needed. board_time_init() - - a) (optional) set up RTC routines, - b) (optional) calibrate and set the mips_counter_frequency - (only needed if you intended to use fixed_rate_gettimeoffset - or use cpu counter as timer interrupt source) + a) (optional) set up RTC routines, + b) (optional) calibrate and set the mips_hpt_frequency + (only needed if you intended to use cpu counter as timer interrupt + source) plat_timer_setup() - a) (optional) over-write any choices made above by time_init(). @@ -154,8 +138,8 @@ for some of the functions in time.c. For example, you may define your own timer interrupt routine, which does some of its own processing and then calls timer_interrupt(). -You can also over-ride any of the built-in functions (gettimeoffset, -RTC routines and/or timer interrupt routine). +You can also over-ride any of the built-in functions (RTC routines +and/or timer interrupt routine). PORTING NOTES FOR SMP @@ -187,10 +171,3 @@ You need to decide on your timer interrupt sources. You can also do the low-level version of those interrupt routines, following similar dispatching routes described above. - -Note about do_gettimeoffset(): - - It is very likely the CPU counter registers are not sync'ed up in a SMP box. - Therefore you cannot really use the many of the existing routines that - are based on CPU counter. You should wirte your own gettimeoffset rouinte - if you want intra-jiffy resolution. diff --git a/Documentation/power/interface.txt b/Documentation/power/interface.txt index a66bec222b1..74311d7e0f3 100644 --- a/Documentation/power/interface.txt +++ b/Documentation/power/interface.txt @@ -30,6 +30,17 @@ testing). The system will support either 'firmware' or 'platform', and that is known a priori. But, the user may choose 'shutdown' or 'reboot' as alternatives. +Additionally, /sys/power/disk can be used to turn on one of the two testing +modes of the suspend-to-disk mechanism: 'testproc' or 'test'. If the +suspend-to-disk mechanism is in the 'testproc' mode, writing 'disk' to +/sys/power/state will cause the kernel to disable nonboot CPUs and freeze +tasks, wait for 5 seconds, unfreeze tasks and enable nonboot CPUs. If it is +in the 'test' mode, writing 'disk' to /sys/power/state will cause the kernel +to disable nonboot CPUs and freeze tasks, shrink memory, suspend devices, wait +for 5 seconds, resume devices, unfreeze tasks and enable nonboot CPUs. Then, +we are able to look in the log messages and work out, for example, which code +is being slow and which device drivers are misbehaving. + Reading from this file will display what the mode is currently set to. Writing to this file will accept one of @@ -37,6 +48,8 @@ to. Writing to this file will accept one of 'platform' 'shutdown' 'reboot' + 'testproc' + 'test' It will only change to 'firmware' or 'platform' if the system supports it. diff --git a/Documentation/sound/alsa/ALSA-Configuration.txt b/Documentation/sound/alsa/ALSA-Configuration.txt index 138673a907f..3472d9c4ef1 100644 --- a/Documentation/sound/alsa/ALSA-Configuration.txt +++ b/Documentation/sound/alsa/ALSA-Configuration.txt @@ -753,7 +753,7 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. position_fix - Fix DMA pointer (0 = auto, 1 = none, 2 = POSBUF, 3 = FIFO size) single_cmd - Use single immediate commands to communicate with codecs (for debugging only) - disable_msi - Disable Message Signaled Interrupt (MSI) + enable_msi - Enable Message Signaled Interrupt (MSI) (default = off) This module supports one card and autoprobe. diff --git a/Documentation/usb/usb-serial.txt b/Documentation/usb/usb-serial.txt index 8dc2bacc8f1..50436e1663e 100644 --- a/Documentation/usb/usb-serial.txt +++ b/Documentation/usb/usb-serial.txt @@ -428,12 +428,6 @@ Options supported: See http://www.uuhaus.de/linux/palmconnect.html for up-to-date information on this driver. -AIRcable USB Dongle Bluetooth driver - If there is the cdc_acm driver loaded in the system, you will find that the - cdc_acm claims the device before AIRcable can. This is simply corrected - by unloading both modules and then loading the aircable module before - cdc_acm module - Generic Serial driver If your device is not one of the above listed devices, compatible with diff --git a/Documentation/watchdog/src/watchdog-simple.c b/Documentation/watchdog/src/watchdog-simple.c index 85cf17c4866..47801bc7e74 100644 --- a/Documentation/watchdog/src/watchdog-simple.c +++ b/Documentation/watchdog/src/watchdog-simple.c @@ -1,4 +1,6 @@ +#include <stdio.h> #include <stdlib.h> +#include <unistd.h> #include <fcntl.h> int main(int argc, const char *argv[]) { |