11 files changed, 844 insertions, 226 deletions

diff --git a/Documentation/ABI/testing/sysfs-bus-usb b/Documentation/ABI/testing/sysfs-bus-usb
index 9734577d1711..11a3c1682cec 100644
--- a/Documentation/ABI/testing/sysfs-bus-usb
+++ b/Documentation/ABI/testing/sysfs-bus-usb
@@ -52,3 +52,36 @@ Description:
                 facility is inherently dangerous, it is disabled by default
                 for all devices except hubs.  For more information, see
                 Documentation/usb/persist.txt.
+
+What:           /sys/bus/usb/device/.../power/connected_duration
+Date:           January 2008
+KernelVersion:  2.6.25
+Contact:        Sarah Sharp <sarah.a.sharp@intel.com>
+Description:
+                If CONFIG_PM and CONFIG_USB_SUSPEND are enabled, then this file
+                is present.  When read, it returns the total time (in msec)
+                that the USB device has been connected to the machine.  This
+                file is read-only.
+Users:
+                PowerTOP <power@bughost.org>
+                http://www.lesswatts.org/projects/powertop/
+
+What:           /sys/bus/usb/device/.../power/active_duration
+Date:           January 2008
+KernelVersion:  2.6.25
+Contact:        Sarah Sharp <sarah.a.sharp@intel.com>
+Description:
+                If CONFIG_PM and CONFIG_USB_SUSPEND are enabled, then this file
+                is present.  When read, it returns the total time (in msec)
+                that the USB device has been active, i.e. not in a suspended
+                state.  This file is read-only.
+
+                Tools can use this file and the connected_duration file to
+                compute the percentage of time that a device has been active.
+                For example,
+                echo $((100 * `cat active_duration` / `cat connected_duration`))
+                will give an integer percentage.  Note that this does not
+                account for counter wrap.
+Users:
+                PowerTOP <power@bughost.org>
+                http://www.lesswatts.org/projects/powertop/
diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt
index 181bff005167..a7d9d179131a 100644
--- a/Documentation/feature-removal-schedule.txt
+++ b/Documentation/feature-removal-schedule.txt
@@ -156,22 +156,6 @@ Who:	Arjan van de Ven <arjan@linux.intel.com>
 
 ---------------------------
 
-What:   USB driver API moves to EXPORT_SYMBOL_GPL
-When:   February 2008
-Files:  include/linux/usb.h, drivers/usb/core/driver.c
-Why:    The USB subsystem has changed a lot over time, and it has been
-        possible to create userspace USB drivers using usbfs/libusb/gadgetfs
-        that operate as fast as the USB bus allows.  Because of this, the USB
-        subsystem will not be allowing closed source kernel drivers to
-        register with it, after this grace period is over.  If anyone needs
-        any help in converting their closed source drivers over to use the
-        userspace filesystems, please contact the
-        linux-usb-devel@lists.sourceforge.net mailing list, and the developers
-        there will be glad to help you out.
-Who:    Greg Kroah-Hartman <gregkh@suse.de>
-
----------------------------
-
 What:   vm_ops.nopage
 When:   Soon, provided in-kernel callers have been converted
 Why:    This interface is replaced by vm_ops.fault, but it has been around
diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
index 92c40d174355..cf3868956f1e 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -168,6 +168,11 @@ and is between 256 and 4096 characters. It is defined in the file
         acpi_irq_isa=   [HW,ACPI] If irq_balance, mark listed IRQs used by ISA
                         Format: <irq>,<irq>...
 
+        acpi_new_pts_ordering [HW,ACPI]
+                        Enforce the ACPI 2.0 ordering of the _PTS control
+                        method wrt putting devices into low power states
+                        default: pre ACPI 2.0 ordering of _PTS
+
         acpi_no_auto_ssdt       [HW,ACPI] Disable automatic loading of SSDT
 
         acpi_os_name=   [HW,ACPI] Tell ACPI BIOS the name of the OS
diff --git a/Documentation/pci.txt b/Documentation/pci.txt
index 7754f5aea4e9..72b20c639596 100644
--- a/Documentation/pci.txt
+++ b/Documentation/pci.txt
@@ -274,8 +274,6 @@ the PCI device by calling pci_enable_device(). This will:
         o allocate an IRQ (if BIOS did not).
 
 NOTE: pci_enable_device() can fail! Check the return value.
-NOTE2: Also see pci_enable_device_bars() below. Drivers can
-    attempt to enable only a subset of BARs they need.
 
 [ OS BUG: we don't check resource allocations before enabling those
   resources. The sequence would make more sense if we called
@@ -605,40 +603,7 @@ device lists. This is still possible but discouraged.
 
 
 
-10. pci_enable_device_bars() and Legacy I/O Port space
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Large servers may not be able to provide I/O port resources to all PCI
-devices. I/O Port space is only 64KB on Intel Architecture[1] and is
-likely also fragmented since the I/O base register of PCI-to-PCI
-bridge will usually be aligned to a 4KB boundary[2]. On such systems,
-pci_enable_device() and pci_request_region() will fail when
-attempting to enable I/O Port regions that don't have I/O Port
-resources assigned.
-
-Fortunately, many PCI devices which request I/O Port resources also
-provide access to the same registers via MMIO BARs. These devices can
-be handled without using I/O port space and the drivers typically
-offer a CONFIG_ option to only use MMIO regions
-(e.g. CONFIG_TULIP_MMIO). PCI devices typically provide I/O port
-interface for legacy OSes and will work when I/O port resources are not
-assigned. The "PCI Local Bus Specification Revision 3.0" discusses
-this on p.44, "IMPLEMENTATION NOTE".
-
-If your PCI device driver doesn't need I/O port resources assigned to
-I/O Port BARs, you should use pci_enable_device_bars() instead of
-pci_enable_device() in order not to enable I/O port regions for the
-corresponding devices. In addition, you should use
-pci_request_selected_regions() and pci_release_selected_regions()
-instead of pci_request_regions()/pci_release_regions() in order not to
-request/release I/O port regions for the corresponding devices.
-
-[1] Some systems support 64KB I/O port space per PCI segment.
-[2] Some PCI-to-PCI bridges support optional 1KB aligned I/O base.
-
-
-
-11. MMIO Space and "Write Posting"
+10. MMIO Space and "Write Posting"
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Converting a driver from using I/O Port space to using MMIO space
diff --git a/Documentation/power/basic-pm-debugging.txt b/Documentation/power/basic-pm-debugging.txt
index 57aef2f6e0de..1555001bc733 100644
--- a/Documentation/power/basic-pm-debugging.txt
+++ b/Documentation/power/basic-pm-debugging.txt
@@ -1,45 +1,111 @@
-Debugging suspend and resume
+Debugging hibernation and suspend
         (C) 2007 Rafael J. Wysocki <rjw@sisk.pl>, GPL
 
-1. Testing suspend to disk (STD)
+1. Testing hibernation (aka suspend to disk or STD)
 
-To verify that the STD works, you can try to suspend in the "reboot" mode:
+To check if hibernation works, you can try to hibernate in the "reboot" mode:
 
 # echo reboot > /sys/power/disk
 # echo disk > /sys/power/state
 
-and the system should suspend, reboot, resume and get back to the command prompt
-where you have started the transition.  If that happens, the STD is most likely
-to work correctly, but you need to repeat the test at least a couple of times in
-a row for confidence.  This is necessary, because some problems only show up on
-a second attempt at suspending and resuming the system.  You should also test
-the "platform" and "shutdown" modes of suspend:
+and the system should create a hibernation image, reboot, resume and get back to
+the command prompt where you have started the transition.  If that happens,
+hibernation is most likely to work correctly.  Still, you need to repeat the
+test at least a couple of times in a row for confidence.  [This is necessary,
+because some problems only show up on a second attempt at suspending and
+resuming the system.]  Moreover, hibernating in the "reboot" and "shutdown"
+modes causes the PM core to skip some platform-related callbacks which on ACPI
+systems might be necessary to make hibernation work.  Thus, if you machine fails
+to hibernate or resume in the "reboot" mode, you should try the "platform" mode:
 
 # echo platform > /sys/power/disk
 # echo disk > /sys/power/state
 
-or
+which is the default and recommended mode of hibernation.
+
+Unfortunately, the "platform" mode of hibernation does not work on some systems
+with broken BIOSes.  In such cases the "shutdown" mode of hibernation might
+work:
 
 # echo shutdown > /sys/power/disk
 # echo disk > /sys/power/state
 
-in which cases you will have to press the power button to make the system
-resume.  If that does not work, you will need to identify what goes wrong.
+(it is similar to the "reboot" mode, but it requires you to press the power
+button to make the system resume).
+
+If neither "platform" nor "shutdown" hibernation mode works, you will need to
+identify what goes wrong.
+
+a) Test modes of hibernation
+
+To find out why hibernation fails on your system, you can use a special testing
+facility available if the kernel is compiled with CONFIG_PM_DEBUG set.  Then,
+there is the file /sys/power/pm_test that can be used to make the hibernation
+core run in a test mode.  There are 5 test modes available:
+
+freezer
+- test the freezing of processes
+
+devices
+- test the freezing of processes and suspending of devices
 
-a) Test mode of STD
+platform
+- test the freezing of processes, suspending of devices and platform
+  global control methods(*)
 
-To verify if there are any drivers that cause problems you can run the STD
-in the test mode:
+processors
+- test the freezing of processes, suspending of devices, platform
+  global control methods(*) and the disabling of nonboot CPUs
 
-# echo test > /sys/power/disk
+core
+- test the freezing of processes, suspending of devices, platform global
+  control methods(*), the disabling of nonboot CPUs and suspending of
+  platform/system devices
+
+(*) the platform global control methods are only available on ACPI systems
+    and are only tested if the hibernation mode is set to "platform"
+
+To use one of them it is necessary to write the corresponding string to
+/sys/power/pm_test (eg. "devices" to test the freezing of processes and
+suspending devices) and issue the standard hibernation commands.  For example,
+to use the "devices" test mode along with the "platform" mode of hibernation,
+you should do the following:
+
+# echo devices > /sys/power/pm_test
+# echo platform > /sys/power/disk
 # echo disk > /sys/power/state
 
-in which case the system should freeze tasks, suspend devices, disable nonboot
-CPUs (if any), wait for 5 seconds, enable nonboot CPUs, resume devices, thaw
-tasks and return to your command prompt.  If that fails, most likely there is
-a driver that fails to either suspend or resume (in the latter case the system
-may hang or be unstable after the test, so please take that into consideration).
-To find this driver, you can carry out a binary search according to the rules:
+Then, the kernel will try to freeze processes, suspend devices, wait 5 seconds,
+resume devices and thaw processes.  If "platform" is written to
+/sys/power/pm_test , then after suspending devices the kernel will additionally
+invoke the global control methods (eg. ACPI global control methods) used to
+prepare the platform firmware for hibernation.  Next, it will wait 5 seconds and
+invoke the platform (eg. ACPI) global methods used to cancel hibernation etc.
+
+Writing "none" to /sys/power/pm_test causes the kernel to switch to the normal
+hibernation/suspend operations.  Also, when open for reading, /sys/power/pm_test
+contains a space-separated list of all available tests (including "none" that
+represents the normal functionality) in which the current test level is
+indicated by square brackets.
+
+Generally, as you can see, each test level is more "invasive" than the previous
+one and the "core" level tests the hardware and drivers as deeply as possible
+without creating a hibernation image.  Obviously, if the "devices" test fails,
+the "platform" test will fail as well and so on.  Thus, as a rule of thumb, you
+should try the test modes starting from "freezer", through "devices", "platform"
+and "processors" up to "core" (repeat the test on each level a couple of times
+to make sure that any random factors are avoided).
+
+If the "freezer" test fails, there is a task that cannot be frozen (in that case
+it usually is possible to identify the offending task by analysing the output of
+dmesg obtained after the failing test).  Failure at this level usually means
+that there is a problem with the tasks freezer subsystem that should be
+reported.
+
+If the "devices" test fails, most likely there is a driver that cannot suspend
+or resume its device (in the latter case the system may hang or become unstable
+after the test, so please take that into consideration).  To find this driver,
+you can carry out a binary search according to the rules:
 - if the test fails, unload a half of the drivers currently loaded and repeat
 (that would probably involve rebooting the system, so always note what drivers
 have been loaded before the test),
@@ -47,23 +113,46 @@ have been loaded before the test),
 recently and repeat.
 
 Once you have found the failing driver (there can be more than just one of
-them), you have to unload it every time before the STD transition.  In that case
-please make sure to report the problem with the driver.
-
-It is also possible that a cycle can still fail after you have unloaded
-all modules. In that case, you would want to look in your kernel configuration
-for the drivers that can be compiled as modules (testing again with them as
-modules), and possibly also try boot time options such as "noapic" or "noacpi".
+them), you have to unload it every time before hibernation.  In that case please
+make sure to report the problem with the driver.
+
+It is also possible that the "devices" test will still fail after you have
+unloaded all modules. In that case, you may want to look in your kernel
+configuration for the drivers that can be compiled as modules (and test again
+with these drivers compiled as modules).  You may also try to use some special
+kernel command line options such as "noapic", "noacpi" or even "acpi=off".
+
+If the "platform" test fails, there is a problem with the handling of the
+platform (eg. ACPI) firmware on your system.  In that case the "platform" mode
+of hibernation is not likely to work.  You can try the "shutdown" mode, but that
+is rather a poor man's workaround.
+
+If the "processors" test fails, the disabling/enabling of nonboot CPUs does not
+work (of course, this only may be an issue on SMP systems) and the problem
+should be reported.  In that case you can also try to switch the nonboot CPUs
+off and on using the /sys/devices/system/cpu/cpu*/online sysfs attributes and
+see if that works.
+
+If the "core" test fails, which means that suspending of the system/platform
+devices has failed (these devices are suspended on one CPU with interrupts off),
+the problem is most probably hardware-related and serious, so it should be
+reported.
+
+A failure of any of the "platform", "processors" or "core" tests may cause your
+system to hang or become unstable, so please beware.  Such a failure usually
+indicates a serious problem that very well may be related to the hardware, but
+please report it anyway.
 
 b) Testing minimal configuration
 
-If the test mode of STD works, you can boot the system with "init=/bin/bash"
-and attempt to suspend in the "reboot", "shutdown" and "platform" modes.  If
-that does not work, there probably is a problem with a driver statically
-compiled into the kernel and you can try to compile more drivers as modules,
-so that they can be tested individually.  Otherwise, there is a problem with a
-modular driver and you can find it by loading a half of the modules you normally
-use and binary searching in accordance with the algorithm:
+If all of the hibernation test modes work, you can boot the system with the
+"init=/bin/bash" command line parameter and attempt to hibernate in the
+"reboot", "shutdown" and "platform" modes.  If that does not work, there
+probably is a problem with a driver statically compiled into the kernel and you
+can try to compile more drivers as modules, so that they can be tested
+individually.  Otherwise, there is a problem with a modular driver and you can
+find it by loading a half of the modules you normally use and binary searching
+in accordance with the algorithm:
 - if there are n modules loaded and the attempt to suspend and resume fails,
 unload n/2 of the modules and try again (that would probably involve rebooting
 the system),
@@ -71,19 +160,19 @@ the system),
 load n/2 modules more and try again.
 
 Again, if you find the offending module(s), it(they) must be unloaded every time
-before the STD transition, and please report the problem with it(them).
+before hibernation, and please report the problem with it(them).
 
 c) Advanced debugging
 
-In case the STD does not work on your system even in the minimal configuration
-and compiling more drivers as modules is not practical or some modules cannot
-be unloaded, you can use one of the more advanced debugging techniques to find
-the problem.  First, if there is a serial port in your box, you can boot the
-kernel with the 'no_console_suspend' parameter and try to log kernel
-messages using the serial console.  This may provide you with some information
-about the reasons of the suspend (resume) failure.  Alternatively, it may be
-possible to use a FireWire port for debugging with firescope
-(ftp://ftp.firstfloor.org/pub/ak/firescope/).  On i386 it is also possible to
+In case that hibernation does not work on your system even in the minimal
+configuration and compiling more drivers as modules is not practical or some
+modules cannot be unloaded, you can use one of the more advanced debugging
+techniques to find the problem.  First, if there is a serial port in your box,
+you can boot the kernel with the 'no_console_suspend' parameter and try to log
+kernel messages using the serial console.  This may provide you with some
+information about the reasons of the suspend (resume) failure.  Alternatively,
+it may be possible to use a FireWire port for debugging with firescope
+(ftp://ftp.firstfloor.org/pub/ak/firescope/).  On x86 it is also possible to
 use the PM_TRACE mechanism documented in Documentation/s2ram.txt .
 
 2. Testing suspend to RAM (STR)
@@ -91,16 +180,25 @@ use the PM_TRACE mechanism documented in Documentation/s2ram.txt .
 To verify that the STR works, it is generally more convenient to use the s2ram
 tool available from http://suspend.sf.net and documented at
 http://en.opensuse.org/s2ram .  However, before doing that it is recommended to
-carry out the procedure described in section 1.
-
-Assume you have resolved the problems with the STD and you have found some
-failing drivers.  These drivers are also likely to fail during the STR or
-during the resume, so it is better to unload them every time before the STR
-transition.  Now, you can follow the instructions at
-http://en.opensuse.org/s2ram to test the system, but if it does not work
-"out of the box", you may need to boot it with "init=/bin/bash" and test
-s2ram in the minimal configuration.  In that case, you may be able to search
-for failing drivers by following the procedure analogous to the one described in
-1b).  If you find some failing drivers, you will have to unload them every time
-before the STR transition (ie. before you run s2ram), and please report the
-problems with them.
+carry out STR testing using the facility described in section 1.
+
+Namely, after writing "freezer", "devices", "platform", "processors", or "core"
+into /sys/power/pm_test (available if the kernel is compiled with
+CONFIG_PM_DEBUG set) the suspend code will work in the test mode corresponding
+to given string.  The STR test modes are defined in the same way as for
+hibernation, so please refer to Section 1 for more information about them.  In
+particular, the "core" test allows you to test everything except for the actual
+invocation of the platform firmware in order to put the system into the sleep
+state.
+
+Among other things, the testing with the help of /sys/power/pm_test may allow
+you to identify drivers that fail to suspend or resume their devices.  They
+should be unloaded every time before an STR transition.
+
+Next, you can follow the instructions at http://en.opensuse.org/s2ram to test
+the system, but if it does not work "out of the box", you may need to boot it
+with "init=/bin/bash" and test s2ram in the minimal configuration.  In that
+case, you may be able to search for failing drivers by following the procedure
+analogous to the one described in section 1.  If you find some failing drivers,
+you will have to unload them every time before an STR transition (ie. before
+you run s2ram), and please report the problems with them.
diff --git a/Documentation/power/devices.txt b/Documentation/power/devices.txt
index d0e79d5820a5..c53d26361919 100644
--- a/Documentation/power/devices.txt
+++ b/Documentation/power/devices.txt
@@ -502,52 +502,3 @@ If the CPU can have a "cpufreq" driver, there also may be opportunities
 to shift to lower voltage settings and reduce the power cost of executing
 a given number of instructions.  (Without voltage adjustment, it's rare
 for cpufreq to save much power; the cost-per-instruction must go down.)
-
-
-/sys/devices/.../power/state files
-==================================
-For now you can also test some of this functionality using sysfs.
-
-        DEPRECATED:  USE "power/state" ONLY FOR DRIVER TESTING, AND
-        AVOID USING dev->power.power_state IN DRIVERS.
-
-        THESE WILL BE REMOVED.  IF THE "power/state" FILE GETS REPLACED,
-        IT WILL BECOME SOMETHING COUPLED TO THE BUS OR DRIVER.
-
-In each device's directory, there is a 'power' directory, which contains
-at least a 'state' file.  The value of this field is effectively boolean,
-PM_EVENT_ON or PM_EVENT_SUSPEND.
-
-   *    Reading from this file displays a value corresponding to
-        the power.power_state.event field.  All nonzero values are
-        displayed as "2", corresponding to a low power state; zero
-        is displayed as "0", corresponding to normal operation.
-
-   *    Writing to this file initiates a transition using the
-        specified event code number; only '0', '2', and '3' are
-        accepted (without a newline); '2' and '3' are both
-        mapped to PM_EVENT_SUSPEND.
-
-On writes, the PM core relies on that recorded event code and the device/bus
-capabilities to determine whether it uses a partial suspend() or resume()
-sequence to change things so that the recorded event corresponds to the
-numeric parameter.
-
-   -    If the bus requires the irqs-disabled suspend_late()/resume_early()
-        phases, writes fail because those operations are not supported here.
-
-   -    If the recorded value is the expected value, nothing is done.
-
-   -    If the recorded value is nonzero, the device is partially resumed,
-        using the bus.resume() and/or class.resume() methods.
-
-   -    If the target value is nonzero, the device is partially suspended,
-        using the class.suspend() and/or bus.suspend() methods and the
-        PM_EVENT_SUSPEND message.
-
-Drivers have no way to tell whether their suspend() and resume() calls
-have come through the sysfs power/state file or as part of entering a
-system sleep state, except that when accessed through sysfs the normal
-parent/child sequencing rules are ignored.  Drivers (such as bus, bridge,
-or hub drivers) which expose child devices may need to enforce those rules
-on their own.
diff --git a/Documentation/power/drivers-testing.txt b/Documentation/power/drivers-testing.txt
index e4bdcaee24e4..7f7a737f7f9f 100644
--- a/Documentation/power/drivers-testing.txt
+++ b/Documentation/power/drivers-testing.txt
@@ -6,9 +6,9 @@ Testing suspend and resume support in device drivers
 Unfortunately, to effectively test the support for the system-wide suspend and
 resume transitions in a driver, it is necessary to suspend and resume a fully
 functional system with this driver loaded.  Moreover, that should be done
-several times, preferably several times in a row, and separately for the suspend
-to disk (STD) and the suspend to RAM (STR) transitions, because each of these
-cases involves different ordering of operations and different interactions with
+several times, preferably several times in a row, and separately for hibernation
+(aka suspend to disk or STD) and suspend to RAM (STR), because each of these
+cases involves slightly different operations and different interactions with
 the machine's BIOS.
 
 Of course, for this purpose the test system has to be known to suspend and
@@ -22,20 +22,24 @@ for more information about the debugging of suspend/resume functionality.
 Once you have resolved the suspend/resume-related problems with your test system
 without the new driver, you are ready to test it:
 
-a) Build the driver as a module, load it and try the STD in the test mode (see:
-Documents/power/basic-pm-debugging.txt, 1a)).
+a) Build the driver as a module, load it and try the test modes of hibernation
+   (see: Documents/power/basic-pm-debugging.txt, 1).
 
-b) Load the driver and attempt to suspend to disk in the "reboot", "shutdown"
-and "platform" modes (see: Documents/power/basic-pm-debugging.txt, 1).
+b) Load the driver and attempt to hibernate in the "reboot", "shutdown" and
+   "platform" modes (see: Documents/power/basic-pm-debugging.txt, 1).
 
-c) Compile the driver directly into the kernel and try the STD in the test mode.
+c) Compile the driver directly into the kernel and try the test modes of
+   hibernation.
 
-d) Attempt to suspend to disk with the driver compiled directly into the kernel
-in the "reboot", "shutdown" and "platform" modes.
+d) Attempt to hibernate with the driver compiled directly into the kernel
+   in the "reboot", "shutdown" and "platform" modes.
 
-e) Attempt to suspend to RAM using the s2ram tool with the driver loaded (see:
-Documents/power/basic-pm-debugging.txt, 2).  As far as the STR tests are
-concerned, it should not matter whether or not the driver is built as a module.
+e) Try the test modes of suspend (see: Documents/power/basic-pm-debugging.txt,
+   2).  [As far as the STR tests are concerned, it should not matter whether or
+   not the driver is built as a module.]
+
+f) Attempt to suspend to RAM using the s2ram tool with the driver loaded
+   (see: Documents/power/basic-pm-debugging.txt, 2).
 
 Each of the above tests should be repeated several times and the STD tests
 should be mixed with the STR tests.  If any of them fails, the driver cannot be
diff --git a/Documentation/power/notifiers.txt b/Documentation/power/notifiers.txt
index 9293e4bc857c..ae1b7ec07684 100644
--- a/Documentation/power/notifiers.txt
+++ b/Documentation/power/notifiers.txt
@@ -28,6 +28,14 @@ PM_POST_HIBERNATION	The system memory state has been restored from a
                         hibernation.  Device drivers' .resume() callbacks have
                         been executed and tasks have been thawed.
 
+PM_RESTORE_PREPARE      The system is going to restore a hibernation image.
+                        If all goes well the restored kernel will issue a
+                        PM_POST_HIBERNATION notification.
+
+PM_POST_RESTORE         An error occurred during the hibernation restore.
+                        Device drivers' .resume() callbacks have been executed
+                        and tasks have been thawed.
+
 PM_SUSPEND_PREPARE      The system is preparing for a suspend.
 
 PM_POST_SUSPEND         The system has just resumed or an error occured during
diff --git a/Documentation/power/userland-swsusp.txt b/Documentation/power/userland-swsusp.txt
index e00c6cf09e85..7b99636564c8 100644
--- a/Documentation/power/userland-swsusp.txt
+++ b/Documentation/power/userland-swsusp.txt
@@ -14,7 +14,7 @@ are going to develop your own suspend/resume utilities.
 
 The interface consists of a character device providing the open(),
 release(), read(), and write() operations as well as several ioctl()
-commands defined in kernel/power/power.h.  The major and minor
+commands defined in include/linux/suspend_ioctls.h .  The major and minor
 numbers of the device are, respectively, 10 and 231, and they can
 be read from /sys/class/misc/snapshot/dev.
 
@@ -27,17 +27,17 @@ once at a time.
 The ioctl() commands recognized by the device are:
 
 SNAPSHOT_FREEZE - freeze user space processes (the current process is
-        not frozen); this is required for SNAPSHOT_ATOMIC_SNAPSHOT
+        not frozen); this is required for SNAPSHOT_CREATE_IMAGE
         and SNAPSHOT_ATOMIC_RESTORE to succeed
 
 SNAPSHOT_UNFREEZE - thaw user space processes frozen by SNAPSHOT_FREEZE
 
-SNAPSHOT_ATOMIC_SNAPSHOT - create a snapshot of the system memory; the
+SNAPSHOT_CREATE_IMAGE - create a snapshot of the system memory; the
         last argument of ioctl() should be a pointer to an int variable,
         the value of which will indicate whether the call returned after
         creating the snapshot (1) or after restoring the system memory state
         from it (0) (after resume the system finds itself finishing the
-        SNAPSHOT_ATOMIC_SNAPSHOT ioctl() again); after the snapshot
+        SNAPSHOT_CREATE_IMAGE ioctl() again); after the snapshot
         has been created the read() operation can be used to transfer
         it out of the kernel
 
@@ -49,39 +49,37 @@ SNAPSHOT_ATOMIC_RESTORE - restore the system memory state from the
 
 SNAPSHOT_FREE - free memory allocated for the snapshot image
 
-SNAPSHOT_SET_IMAGE_SIZE - set the preferred maximum size of the image
+SNAPSHOT_PREF_IMAGE_SIZE - set the preferred maximum size of the image
         (the kernel will do its best to ensure the image size will not exceed
         this number, but if it turns out to be impossible, the kernel will
         create the smallest image possible)
 
-SNAPSHOT_AVAIL_SWAP - return the amount of available swap in bytes (the last
-        argument should be a pointer to an unsigned int variable that will
+SNAPSHOT_GET_IMAGE_SIZE - return the actual size of the hibernation image
+
+SNAPSHOT_AVAIL_SWAP_SIZE - return the amount of available swap in bytes (the
+        last argument should be a pointer to an unsigned int variable that will
         contain the result if the call is successful).
 
-SNAPSHOT_GET_SWAP_PAGE - allocate a swap page from the resume partition
+SNAPSHOT_ALLOC_SWAP_PAGE - allocate a swap page from the resume partition
         (the last argument should be a pointer to a loff_t variable that
         will contain the swap page offset if the call is successful)
 
-SNAPSHOT_FREE_SWAP_PAGES - free all swap pages allocated with
-        SNAPSHOT_GET_SWAP_PAGE
-
-SNAPSHOT_SET_SWAP_FILE - set the resume partition (the last ioctl() argument
-        should specify the device's major and minor numbers in the old
-        two-byte format, as returned by the stat() function in the .st_rdev
-        member of the stat structure)
+SNAPSHOT_FREE_SWAP_PAGES - free all swap pages allocated by
+        SNAPSHOT_ALLOC_SWAP_PAGE
 
 SNAPSHOT_SET_SWAP_AREA - set the resume partition and the offset (in <PAGE_SIZE>
         units) from the beginning of the partition at which the swap header is
         located (the last ioctl() argument should point to a struct
-        resume_swap_area, as defined in kernel/power/power.h, containing the
-        resume device specification, as for the SNAPSHOT_SET_SWAP_FILE ioctl(),
-        and the offset); for swap partitions the offset is always 0, but it is
-        different to zero for swap files (please see
-        Documentation/swsusp-and-swap-files.txt for details).
-        The SNAPSHOT_SET_SWAP_AREA ioctl() is considered as a replacement for
-        SNAPSHOT_SET_SWAP_FILE which is regarded as obsolete.   It is
-        recommended to always use this call, because the code to set the resume
-        partition may be removed from future kernels
+        resume_swap_area, as defined in kernel/power/suspend_ioctls.h,
+        containing the resume device specification and the offset); for swap
+        partitions the offset is always 0, but it is different from zero for
+        swap files (see Documentation/swsusp-and-swap-files.txt for details).
+
+SNAPSHOT_PLATFORM_SUPPORT - enable/disable the hibernation platform support,
+        depending on the argument value (enable, if the argument is nonzero)
+
+SNAPSHOT_POWER_OFF - make the kernel transition the system to the hibernation
+        state (eg. ACPI S4) using the platform (eg. ACPI) driver
 
 SNAPSHOT_S2RAM - suspend to RAM; using this call causes the kernel to
         immediately enter the suspend-to-RAM state, so this call must always
@@ -93,24 +91,6 @@ SNAPSHOT_S2RAM - suspend to RAM; using this call causes the kernel to
         to resume the system from RAM if there's enough battery power or restore
         its state on the basis of the saved suspend image otherwise)
 
-SNAPSHOT_PMOPS - enable the usage of the hibernation_ops->prepare,
-        hibernate_ops->enter and hibernation_ops->finish methods (the in-kernel
-        swsusp knows these as the "platform method") which are needed on many
-        machines to (among others) speed up the resume by letting the BIOS skip
-        some steps or to let the system recognise the correct state of the
-        hardware after the resume (in particular on many machines this ensures
-        that unplugged AC adapters get correctly detected and that kacpid does
-        not run wild after the resume).  The last ioctl() argument can take one
-        of the three values, defined in kernel/power/power.h:
-        PMOPS_PREPARE - make the kernel carry out the
-                hibernation_ops->prepare() operation
-        PMOPS_ENTER - make the kernel power off the system by calling
-                hibernation_ops->enter()
-        PMOPS_FINISH - make the kernel carry out the
-                hibernation_ops->finish() operation
-        Note that the actual constants are misnamed because they surface
-        internal kernel implementation details that have changed.
-
 The device's read() operation can be used to transfer the snapshot image from
 the kernel.  It has the following limitations:
 - you cannot read() more than one virtual memory page at a time
@@ -122,7 +102,7 @@ The device's write() operation is used for uploading the system memory snapshot
 into the kernel.  It has the same limitations as the read() operation.
 
 The release() operation frees all memory allocated for the snapshot image
-and all swap pages allocated with SNAPSHOT_GET_SWAP_PAGE (if any).
+and all swap pages allocated with SNAPSHOT_ALLOC_SWAP_PAGE (if any).
 Thus it is not necessary to use either SNAPSHOT_FREE or
 SNAPSHOT_FREE_SWAP_PAGES before closing the device (in fact it will also
 unfreeze user space processes frozen by SNAPSHOT_UNFREEZE if they are
@@ -133,16 +113,12 @@ snapshot image from/to the kernel will use a swap parition, called the resume
 partition, or a swap file as storage space (if a swap file is used, the resume
 partition is the partition that holds this file).  However, this is not really
 required, as they can use, for example, a special (blank) suspend partition or
-a file on a partition that is unmounted before SNAPSHOT_ATOMIC_SNAPSHOT and
+a file on a partition that is unmounted before SNAPSHOT_CREATE_IMAGE and
 mounted afterwards.
 
-These utilities SHOULD NOT make any assumptions regarding the ordering of
-data within the snapshot image, except for the image header that MAY be
-assumed to start with an swsusp_info structure, as specified in
-kernel/power/power.h.  This structure MAY be used by the userland utilities
-to obtain some information about the snapshot image, such as the size
-of the snapshot image, including the metadata and the header itself,
-contained in the .size member of swsusp_info.
+These utilities MUST NOT make any assumptions regarding the ordering of
+data within the snapshot image.  The contents of the image are entirely owned
+by the kernel and its structure may be changed in future kernel releases.
 
 The snapshot image MUST be written to the kernel unaltered (ie. all of the image
 data, metadata and header MUST be written in _exactly_ the same amount, form
@@ -159,7 +135,7 @@ means, such as checksums, to ensure the integrity of the snapshot image.
 The suspending and resuming utilities MUST lock themselves in memory,
 preferrably using mlockall(), before calling SNAPSHOT_FREEZE.
 
-The suspending utility MUST check the value stored by SNAPSHOT_ATOMIC_SNAPSHOT
+The suspending utility MUST check the value stored by SNAPSHOT_CREATE_IMAGE
 in the memory location pointed to by the last argument of ioctl() and proceed
 in accordance with it:
 1.      If the value is 1 (ie. the system memory snapshot has just been
@@ -173,7 +149,7 @@ in accordance with it:
                 image has been saved.
         (b)     The suspending utility SHOULD NOT attempt to perform any
                 file system operations (including reads) on the file systems
-                that were mounted before SNAPSHOT_ATOMIC_SNAPSHOT has been
+                that were mounted before SNAPSHOT_CREATE_IMAGE has been
                 called.  However, it MAY mount a file system that was not
                 mounted at that time and perform some operations on it (eg.
                 use it for saving the image).
diff --git a/Documentation/usb/gadget_printer.txt b/Documentation/usb/gadget_printer.txt
new file mode 100644
index 000000000000..ad995bf0db41
--- /dev/null
+++ b/Documentation/usb/gadget_printer.txt
@@ -0,0 +1,510 @@
+
+                       Linux USB Printer Gadget Driver
+                                 06/04/2007
+
+              Copyright (C) 2007 Craig W. Nadler <craig@nadler.us>
+
+
+
+GENERAL
+=======
+
+This driver may be used if you are writing printer firmware using Linux as
+the embedded OS. This driver has nothing to do with using a printer with
+your Linux host system.
+
+You will need a USB device controller and a Linux driver for it that accepts
+a gadget / "device class" driver using the Linux USB Gadget API. After the
+USB device controller driver is loaded then load the printer gadget driver.
+This will present a printer interface to the USB Host that your USB Device
+port is connected to.
+
+This driver is structured for printer firmware that runs in user mode. The
+user mode printer firmware will read and write data from the kernel mode
+printer gadget driver using a device file. The printer returns a printer status
+byte when the USB HOST sends a device request to get the printer status.  The
+user space firmware can read or write this status byte using a device file
+/dev/g_printer . Both blocking and non-blocking read/write calls are supported.
+
+
+
+
+HOWTO USE THIS DRIVER
+=====================
+
+To load the USB device controller driver and the printer gadget driver. The
+following example uses the Netchip 2280 USB device controller driver:
+
+modprobe net2280
+modprobe g_printer
+
+
+The follow command line parameter can be used when loading the printer gadget
+(ex: modprobe g_printer idVendor=0x0525 idProduct=0xa4a8 ):
+
+idVendor - This is the Vendor ID used in the device descriptor. The default is
+        the Netchip vendor id 0x0525. YOU MUST CHANGE TO YOUR OWN VENDOR ID
+        BEFORE RELEASING A PRODUCT. If you plan to release a product and don't
+        already have a Vendor ID please see www.usb.org for details on how to
+        get one.
+
+idProduct - This is the Product ID used in the device descriptor. The default
+        is 0xa4a8, you should change this to an ID that's not used by any of
+        your other USB products if you have any. It would be a good idea to
+        start numbering your products starting with say 0x0001.
+
+bcdDevice - This is the version number of your product. It would be a good idea
+        to put your firmware version here.
+
+iManufacturer - A string containing the name of the Vendor.
+
+iProduct - A string containing the Product Name.
+
+iSerialNum - A string containing the Serial Number. This should be changed for
+        each unit of your product.
+
+iPNPstring -  The PNP ID string used for this printer. You will want to set
+        either on the command line or hard code the PNP ID string used for
+        your printer product.
+
+qlen - The number of 8k buffers to use per endpoint. The default is 10, you
+        should tune this for your product. You may also want to tune the
+        size of each buffer for your product.
+
+
+
+
+USING THE EXAMPLE CODE
+======================
+
+This example code talks to stdout, instead of a print engine.
+
+To compile the test code below:
+
+1) save it to a file called prn_example.c
+2) compile the code with the follow command:
+         gcc prn_example.c -o prn_example
+
+
+
+To read printer data from the host to stdout:
+
+        # prn_example -read_data
+
+
+To write printer data from a file (data_file) to the host:
+
+        # cat data_file | prn_example -write_data
+
+
+To get the current printer status for the gadget driver:
+
+        # prn_example -get_status
+
+        Printer status is:
+             Printer is NOT Selected
+             Paper is Out
+             Printer OK
+
+
+To set printer to Selected/On-line:
+
+        # prn_example -selected
+
+
+To set printer to Not Selected/Off-line:
+
+        # prn_example -not_selected
+
+
+To set paper status to paper out:
+
+        # prn_example -paper_out
+
+
+To set paper status to paper loaded:
+
+        # prn_example -paper_loaded
+
+
+To set error status to printer OK:
+
+        # prn_example -no_error
+
+
+To set error status to ERROR:
+
+        # prn_example -error
+
+
+
+
+EXAMPLE CODE
+============
+
+
+#include <stdio.h>
+#include <stdlib.h>
+#include <fcntl.h>
+#include <linux/poll.h>
+#include <sys/ioctl.h>
+#include <linux/usb/g_printer.h>
+
+#define PRINTER_FILE                    "/dev/g_printer"
+#define BUF_SIZE                        512
+
+
+/*
+ * 'usage()' - Show program usage.
+ */
+
+static void
+usage(const char *option)               /* I - Option string or NULL */
+{
+        if (option) {
+                fprintf(stderr,"prn_example: Unknown option \"%s\"!\n",
+                                option);
+        }
+
+        fputs("\n", stderr);
+        fputs("Usage: prn_example -[options]\n", stderr);
+        fputs("Options:\n", stderr);
+        fputs("\n", stderr);
+        fputs("-get_status    Get the current printer status.\n", stderr);
+        fputs("-selected      Set the selected status to selected.\n", stderr);
+        fputs("-not_selected  Set the selected status to NOT selected.\n",
+                        stderr);
+        fputs("-error         Set the error status to error.\n", stderr);
+        fputs("-no_error      Set the error status to NO error.\n", stderr);
+        fputs("-paper_out     Set the paper status to paper out.\n", stderr);
+        fputs("-paper_loaded  Set the paper status to paper loaded.\n",
+                        stderr);
+        fputs("-read_data     Read printer data from driver.\n", stderr);
+        fputs("-write_data    Write printer sata to driver.\n", stderr);
+        fputs("-NB_read_data  (Non-Blocking) Read printer data from driver.\n",
+                        stderr);
+        fputs("\n\n", stderr);
+
+        exit(1);
+}
+
+
+static int
+read_printer_data()
+{
+        struct pollfd   fd[1];
+
+        /* Open device file for printer gadget. */
+        fd[0].fd = open(PRINTER_FILE, O_RDWR);
+        if (fd[0].fd < 0) {
+                printf("Error %d opening %s\n", fd[0].fd, PRINTER_FILE);
+                close(fd[0].fd);
+                return(-1);
+        }
+
+        fd[0].events = POLLIN | POLLRDNORM;
+
+        while (1) {
+                static char buf[BUF_SIZE];
+                int bytes_read;
+                int retval;
+
+                /* Wait for up to 1 second for data. */
+                retval = poll(fd, 1, 1000);
+
+                if (retval && (fd[0].revents & POLLRDNORM)) {
+
+                        /* Read data from printer gadget driver. */
+                        bytes_read = read(fd[0].fd, buf, BUF_SIZE);
+
+                        if (bytes_read < 0) {
+                                printf("Error %d reading from %s\n",
+                                                fd[0].fd, PRINTER_FILE);
+                                close(fd[0].fd);
+                                return(-1);
+                        } else if (bytes_read > 0) {
+                                /* Write data to standard OUTPUT (stdout). */
+                                fwrite(buf, 1, bytes_read, stdout);
+                                fflush(stdout);
+                        }
+
+                }
+
+        }
+
+        /* Close the device file. */
+        close(fd[0].fd);
+
+        return 0;
+}
+
+
+static int
+write_printer_data()
+{
+        struct pollfd   fd[1];
+
+        /* Open device file for printer gadget. */
+        fd[0].fd = open (PRINTER_FILE, O_RDWR);
+        if (fd[0].fd < 0) {
+                printf("Error %d opening %s\n", fd[0].fd, PRINTER_FILE);
+                close(fd[0].fd);
+                return(-1);
+        }
+
+        fd[0].events = POLLOUT | POLLWRNORM;
+
+        while (1) {
+                int retval;
+                static char buf[BUF_SIZE];
+                /* Read data from standard INPUT (stdin). */
+                int bytes_read = fread(buf, 1, BUF_SIZE, stdin);
+
+                if (!bytes_read) {
+                        break;
+                }
+
+                while (bytes_read) {
+
+                        /* Wait for up to 1 second to sent data. */
+                        retval = poll(fd, 1, 1000);
+
+                        /* Write data to printer gadget driver. */
+                        if (retval && (fd[0].revents & POLLWRNORM)) {
+                                retval = write(fd[0].fd, buf, bytes_read);
+                                if (retval < 0) {
+                                        printf("Error %d writing to %s\n",
+                                                        fd[0].fd,
+                                                        PRINTER_FILE);
+                                        close(fd[0].fd);
+                                        return(-1);
+                                } else {
+                                        bytes_read -= retval;
+                                }
+
+                        }
+
+                }
+
+        }
+
+        /* Wait until the data has been sent. */
+        fsync(fd[0].fd);
+
+        /* Close the device file. */
+        close(fd[0].fd);
+
+        return 0;
+}
+
+
+static int
+read_NB_printer_data()
+{
+        int             fd;
+        static char     buf[BUF_SIZE];
+        int             bytes_read;
+
+        /* Open device file for printer gadget. */
+        fd = open(PRINTER_FILE, O_RDWR|O_NONBLOCK);
+        if (fd < 0) {
+                printf("Error %d opening %s\n", fd, PRINTER_FILE);
+                close(fd);
+                return(-1);
+        }
+
+        while (1) {
+                /* Read data from printer gadget driver. */
+                bytes_read = read(fd, buf, BUF_SIZE);
+                if (bytes_read <= 0) {
+                        break;
+                }
+
+                /* Write data to standard OUTPUT (stdout). */
+                fwrite(buf, 1, bytes_read, stdout);
+                fflush(stdout);
+        }
+
+        /* Close the device file. */
+        close(fd);
+
+        return 0;
+}
+
+
+static int
+get_printer_status()
+{
+        int     retval;
+        int     fd;
+
+        /* Open device file for printer gadget. */
+        fd = open(PRINTER_FILE, O_RDWR);
+        if (fd < 0) {
+                printf("Error %d opening %s\n", fd, PRINTER_FILE);
+                close(fd);
+                return(-1);
+        }
+
+        /* Make the IOCTL call. */
+        retval = ioctl(fd, GADGET_GET_PRINTER_STATUS);
+        if (retval < 0) {
+                fprintf(stderr, "ERROR: Failed to set printer status\n");
+                return(-1);
+        }
+
+        /* Close the device file. */
+        close(fd);
+
+        return(retval);
+}
+
+
+static int
+set_printer_status(unsigned char buf, int clear_printer_status_bit)
+{
+        int     retval;
+        int     fd;
+
+        retval = get_printer_status();
+        if (retval < 0) {
+                fprintf(stderr, "ERROR: Failed to get printer status\n");
+                return(-1);
+        }
+
+        /* Open device file for printer gadget. */
+        fd = open(PRINTER_FILE, O_RDWR);
+
+        if (fd < 0) {
+                printf("Error %d opening %s\n", fd, PRINTER_FILE);
+                close(fd);
+                return(-1);
+        }
+
+        if (clear_printer_status_bit) {
+                retval &= ~buf;
+        } else {
+                retval |= buf;
+        }
+
+        /* Make the IOCTL call. */
+        if (ioctl(fd, GADGET_SET_PRINTER_STATUS, (unsigned char)retval)) {
+                fprintf(stderr, "ERROR: Failed to set printer status\n");
+                return(-1);
+        }
+
+        /* Close the device file. */
+        close(fd);
+
+        return 0;
+}
+
+
+static int
+display_printer_status()
+{
+        char    printer_status;
+
+        printer_status = get_printer_status();
+        if (printer_status < 0) {
+                fprintf(stderr, "ERROR: Failed to get printer status\n");
+                return(-1);
+        }
+
+        printf("Printer status is:\n");
+        if (printer_status & PRINTER_SELECTED) {
+                printf("     Printer is Selected\n");
+        } else {
+                printf("     Printer is NOT Selected\n");
+        }
+        if (printer_status & PRINTER_PAPER_EMPTY) {
+                printf("     Paper is Out\n");
+        } else {
+                printf("     Paper is Loaded\n");
+        }
+        if (printer_status & PRINTER_NOT_ERROR) {
+                printf("     Printer OK\n");
+        } else {
+                printf("     Printer ERROR\n");
+        }
+
+        return(0);
+}
+
+
+int
+main(int  argc, char *argv[])
+{
+        int     i;              /* Looping var */
+        int     retval = 0;
+
+        /* No Args */
+        if (argc == 1) {
+                usage(0);
+                exit(0);
+        }
+
+        for (i = 1; i < argc && !retval; i ++) {
+
+                if (argv[i][0] != '-') {
+                        continue;
+                }
+
+                if (!strcmp(argv[i], "-get_status")) {
+                        if (display_printer_status()) {
+                                retval = 1;
+                        }
+
+                } else if (!strcmp(argv[i], "-paper_loaded")) {
+                        if (set_printer_status(PRINTER_PAPER_EMPTY, 1)) {
+                                retval = 1;
+                        }
+
+                } else if (!strcmp(argv[i], "-paper_out")) {
+                        if (set_printer_status(PRINTER_PAPER_EMPTY, 0)) {
+                                retval = 1;
+                        }
+
+                } else if (!strcmp(argv[i], "-selected")) {
+                        if (set_printer_status(PRINTER_SELECTED, 0)) {
+                                retval = 1;
+                        }
+
+                } else if (!strcmp(argv[i], "-not_selected")) {
+                        if (set_printer_status(PRINTER_SELECTED, 1)) {
+                                retval = 1;
+                        }
+
+                } else if (!strcmp(argv[i], "-error")) {
+                        if (set_printer_status(PRINTER_NOT_ERROR, 1)) {
+                                retval = 1;
+                        }
+
+                } else if (!strcmp(argv[i], "-no_error")) {
+                        if (set_printer_status(PRINTER_NOT_ERROR, 0)) {
+                                retval = 1;
+                        }
+
+                } else if (!strcmp(argv[i], "-read_data")) {
+                        if (read_printer_data()) {
+                                retval = 1;
+                        }
+
+                } else if (!strcmp(argv[i], "-write_data")) {
+                        if (write_printer_data()) {
+                                retval = 1;
+                        }
+
+                } else if (!strcmp(argv[i], "-NB_read_data")) {
+                        if (read_NB_printer_data()) {
+                                retval = 1;
+                        }
+
+                } else {
+                        usage(argv[i]);
+                        retval = 1;
+                }
+        }
+
+        exit(retval);
+}
diff --git a/Documentation/usb/iuu_phoenix.txt b/Documentation/usb/iuu_phoenix.txt
new file mode 100644
index 000000000000..e5f048067da4
--- /dev/null
+++ b/Documentation/usb/iuu_phoenix.txt
@@ -0,0 +1,84 @@
+Infinity Usb Unlimited Readme
+-----------------------------
+
+Hi all,
+
+
+This module provide a serial interface to use your
+IUU unit in phoenix mode. Loading this module will
+bring a ttyUSB[0-x] interface. This driver must be
+used by your favorite application to pilot the IUU
+
+This driver is still in beta stage, so bugs can
+occur and your system may freeze. As far I now,
+I never had any problem with it, but I'm not a real
+guru, so don't blame me if your system is unstable
+
+You can plug more than one IUU. Every unit will
+have his own device file(/dev/ttyUSB0,/dev/ttyUSB1,...)
+
+
+
+How to tune the reader speed ?
+
+ A few parameters can be used at load time
+ To use parameters, just unload the module if it is
+ already loaded and use modprobe iuu_phoenix param=value.
+ In case of prebuilt module, use the command
+ insmod iuu_phoenix param=value.
+
+ Example:
+
+ modprobe iuu_phoenix clockmode=3
+
+ The parameters are:
+
+ parm:           clockmode:1=3Mhz579,2=3Mhz680,3=6Mhz (int)
+ parm:           boost:overclock boost percent 100 to 500 (int)
+ parm:           cdmode:Card detect mode 0=none, 1=CD, 2=!CD, 3=DSR, 4=!DSR, 5=CTS, 6=!CTS, 7=RING, 8=!RING (int)
+ parm:           xmas:xmas color enabled or not (bool)
+ parm:           debug:Debug enabled or not (bool)
+
+-  clockmode will provide 3 different base settings commonly adopted by
+   different software:
+        1. 3Mhz579
+        2. 3Mhz680
+        3. 6Mhz
+
+-  boost provide a way to overclock the reader ( my favorite :-)  )
+   For example to have best performance than a simple clockmode=3, try this:
+
+      modprobe boost=195
+
+   This will put the reader in a base of 3Mhz579 but boosted a 195 % !
+   the real clock will be now : 6979050 Hz ( 6Mhz979 ) and will increase
+   the speed to a score 10 to 20% better than the simple clockmode=3 !!!
+
+
+-  cdmode permit to setup the signal used to inform the userland ( ioctl answer )
+   if the card is present or not. Eight signals are possible.
+
+-  xmas is completely useless except for your eyes. This is one of my friend who was
+   so sad to have a nice device like the iuu without seeing all color range available.
+   So I have added this option to permit him to see a lot of color ( each activity change the color
+   and the frequency randomly )
+
+-  debug will produce a lot of debugging messages...
+
+
+ Last notes:
+
+ Don't worry about the serial settings, the serial emulation
+ is an abstraction, so use any speed or parity setting will
+ work. ( This will not change anything ).Later I will perhaps
+ use this settings to deduce de boost but is that feature
+ really necessary ?
+ The autodetect feature used is the serial CD. If that doesn't
+ work for your software, disable detection mechanism in it.
+
+
+ Have fun !
+
+ Alain Degreffe
+
+ eczema(at)ecze.com