aboutsummaryrefslogtreecommitdiffstats
path: root/Documentation
diff options
context:
space:
mode:
Diffstat (limited to 'Documentation')
-rw-r--r--Documentation/ABI/testing/sysfs-dev20
-rw-r--r--Documentation/ABI/testing/sysfs-devices-memory24
-rw-r--r--Documentation/ABI/testing/sysfs-kernel-mm6
-rw-r--r--Documentation/ABI/testing/sysfs-kernel-mm-hugepages15
-rw-r--r--Documentation/DMA-attributes.txt9
-rw-r--r--Documentation/DocBook/gadget.tmpl38
-rw-r--r--Documentation/DocBook/kernel-locking.tmpl57
-rw-r--r--Documentation/DocBook/uio-howto.tmpl63
-rw-r--r--Documentation/HOWTO2
-rw-r--r--Documentation/fb/sh7760fb.txt131
-rw-r--r--Documentation/fb/tridentfb.txt46
-rw-r--r--Documentation/feature-removal-schedule.txt8
-rw-r--r--Documentation/filesystems/Locking7
-rw-r--r--Documentation/filesystems/bfs.txt10
-rw-r--r--Documentation/filesystems/proc.txt44
-rw-r--r--Documentation/filesystems/sysfs.txt6
-rw-r--r--Documentation/ia64/paravirt_ops.txt137
-rw-r--r--Documentation/kernel-parameters.txt42
-rw-r--r--Documentation/laptops/thinkpad-acpi.txt26
-rw-r--r--Documentation/networking/e1000.txt14
-rw-r--r--Documentation/networking/udplite.txt2
-rw-r--r--Documentation/power/00-INDEX4
-rw-r--r--Documentation/power/apm-acpi.txt32
-rw-r--r--Documentation/power/pm.txt257
-rw-r--r--Documentation/powerpc/booting-without-of.txt189
-rw-r--r--Documentation/powerpc/dts-bindings/fsl/cpm_qe/gpio.txt38
-rw-r--r--Documentation/powerpc/dts-bindings/fsl/cpm_qe/qe/usb.txt53
-rw-r--r--Documentation/powerpc/dts-bindings/fsl/mcu-mpc8349emitx.txt17
-rw-r--r--Documentation/powerpc/dts-bindings/fsl/pmc.txt63
-rw-r--r--Documentation/powerpc/dts-bindings/fsl/tsec.txt31
-rw-r--r--Documentation/powerpc/dts-bindings/fsl/upm-nand.txt28
-rw-r--r--Documentation/powerpc/dts-bindings/gpio/led.txt15
-rw-r--r--Documentation/sound/alsa/DocBook/alsa-driver-api.tmpl2
-rw-r--r--Documentation/specialix.txt8
-rw-r--r--Documentation/sysfs-rules.txt5
-rw-r--r--Documentation/telephony/ixj.txt13
-rw-r--r--Documentation/usb/gadget_serial.txt35
-rw-r--r--Documentation/usb/persist.txt7
-rw-r--r--Documentation/usb/uhci.txt165
-rw-r--r--Documentation/video4linux/w9968cf.txt3
-rw-r--r--Documentation/vm/hugetlbpage.txt23
41 files changed, 1025 insertions, 670 deletions
diff --git a/Documentation/ABI/testing/sysfs-dev b/Documentation/ABI/testing/sysfs-dev
new file mode 100644
index 000000000000..a9f2b8b0530f
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-dev
@@ -0,0 +1,20 @@
1What: /sys/dev
2Date: April 2008
3KernelVersion: 2.6.26
4Contact: Dan Williams <dan.j.williams@intel.com>
5Description: The /sys/dev tree provides a method to look up the sysfs
6 path for a device using the information returned from
7 stat(2). There are two directories, 'block' and 'char',
8 beneath /sys/dev containing symbolic links with names of
9 the form "<major>:<minor>". These links point to the
10 corresponding sysfs path for the given device.
11
12 Example:
13 $ readlink /sys/dev/block/8:32
14 ../../block/sdc
15
16 Entries in /sys/dev/char and /sys/dev/block will be
17 dynamically created and destroyed as devices enter and
18 leave the system.
19
20Users: mdadm <linux-raid@vger.kernel.org>
diff --git a/Documentation/ABI/testing/sysfs-devices-memory b/Documentation/ABI/testing/sysfs-devices-memory
new file mode 100644
index 000000000000..7a16fe1e2270
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-devices-memory
@@ -0,0 +1,24 @@
1What: /sys/devices/system/memory
2Date: June 2008
3Contact: Badari Pulavarty <pbadari@us.ibm.com>
4Description:
5 The /sys/devices/system/memory contains a snapshot of the
6 internal state of the kernel memory blocks. Files could be
7 added or removed dynamically to represent hot-add/remove
8 operations.
9
10Users: hotplug memory add/remove tools
11 https://w3.opensource.ibm.com/projects/powerpc-utils/
12
13What: /sys/devices/system/memory/memoryX/removable
14Date: June 2008
15Contact: Badari Pulavarty <pbadari@us.ibm.com>
16Description:
17 The file /sys/devices/system/memory/memoryX/removable
18 indicates whether this memory block is removable or not.
19 This is useful for a user-level agent to determine
20 identify removable sections of the memory before attempting
21 potentially expensive hot-remove memory operation
22
23Users: hotplug memory remove tools
24 https://w3.opensource.ibm.com/projects/powerpc-utils/
diff --git a/Documentation/ABI/testing/sysfs-kernel-mm b/Documentation/ABI/testing/sysfs-kernel-mm
new file mode 100644
index 000000000000..190d523ac159
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-kernel-mm
@@ -0,0 +1,6 @@
1What: /sys/kernel/mm
2Date: July 2008
3Contact: Nishanth Aravamudan <nacc@us.ibm.com>, VM maintainers
4Description:
5 /sys/kernel/mm/ should contain any and all VM
6 related information in /sys/kernel/.
diff --git a/Documentation/ABI/testing/sysfs-kernel-mm-hugepages b/Documentation/ABI/testing/sysfs-kernel-mm-hugepages
new file mode 100644
index 000000000000..e21c00571cf4
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-kernel-mm-hugepages
@@ -0,0 +1,15 @@
1What: /sys/kernel/mm/hugepages/
2Date: June 2008
3Contact: Nishanth Aravamudan <nacc@us.ibm.com>, hugetlb maintainers
4Description:
5 /sys/kernel/mm/hugepages/ contains a number of subdirectories
6 of the form hugepages-<size>kB, where <size> is the page size
7 of the hugepages supported by the kernel/CPU combination.
8
9 Under these directories are a number of files:
10 nr_hugepages
11 nr_overcommit_hugepages
12 free_hugepages
13 surplus_hugepages
14 resv_hugepages
15 See Documentation/vm/hugetlbpage.txt for details.
diff --git a/Documentation/DMA-attributes.txt b/Documentation/DMA-attributes.txt
index 6d772f84b477..b768cc0e402b 100644
--- a/Documentation/DMA-attributes.txt
+++ b/Documentation/DMA-attributes.txt
@@ -22,3 +22,12 @@ ready and available in memory. The DMA of the "completion indication"
22could race with data DMA. Mapping the memory used for completion 22could race with data DMA. Mapping the memory used for completion
23indications with DMA_ATTR_WRITE_BARRIER would prevent the race. 23indications with DMA_ATTR_WRITE_BARRIER would prevent the race.
24 24
25DMA_ATTR_WEAK_ORDERING
26----------------------
27
28DMA_ATTR_WEAK_ORDERING specifies that reads and writes to the mapping
29may be weakly ordered, that is that reads and writes may pass each other.
30
31Since it is optional for platforms to implement DMA_ATTR_WEAK_ORDERING,
32those that do not will simply ignore the attribute and exhibit default
33behavior.
diff --git a/Documentation/DocBook/gadget.tmpl b/Documentation/DocBook/gadget.tmpl
index 5a8ffa761e09..ea3bc9565e6a 100644
--- a/Documentation/DocBook/gadget.tmpl
+++ b/Documentation/DocBook/gadget.tmpl
@@ -524,6 +524,44 @@ These utilities include endpoint autoconfiguration.
524<!-- !Edrivers/usb/gadget/epautoconf.c --> 524<!-- !Edrivers/usb/gadget/epautoconf.c -->
525</sect1> 525</sect1>
526 526
527<sect1 id="composite"><title>Composite Device Framework</title>
528
529<para>The core API is sufficient for writing drivers for composite
530USB devices (with more than one function in a given configuration),
531and also multi-configuration devices (also more than one function,
532but not necessarily sharing a given configuration).
533There is however an optional framework which makes it easier to
534reuse and combine functions.
535</para>
536
537<para>Devices using this framework provide a <emphasis>struct
538usb_composite_driver</emphasis>, which in turn provides one or
539more <emphasis>struct usb_configuration</emphasis> instances.
540Each such configuration includes at least one
541<emphasis>struct usb_function</emphasis>, which packages a user
542visible role such as "network link" or "mass storage device".
543Management functions may also exist, such as "Device Firmware
544Upgrade".
545</para>
546
547!Iinclude/linux/usb/composite.h
548!Edrivers/usb/gadget/composite.c
549
550</sect1>
551
552<sect1 id="functions"><title>Composite Device Functions</title>
553
554<para>At this writing, a few of the current gadget drivers have
555been converted to this framework.
556Near-term plans include converting all of them, except for "gadgetfs".
557</para>
558
559!Edrivers/usb/gadget/f_acm.c
560!Edrivers/usb/gadget/f_serial.c
561
562</sect1>
563
564
527</chapter> 565</chapter>
528 566
529<chapter id="controllers"><title>Peripheral Controller Drivers</title> 567<chapter id="controllers"><title>Peripheral Controller Drivers</title>
diff --git a/Documentation/DocBook/kernel-locking.tmpl b/Documentation/DocBook/kernel-locking.tmpl
index 2510763295d0..084f6ad7b7a0 100644
--- a/Documentation/DocBook/kernel-locking.tmpl
+++ b/Documentation/DocBook/kernel-locking.tmpl
@@ -219,10 +219,10 @@
219 </para> 219 </para>
220 220
221 <sect1 id="lock-intro"> 221 <sect1 id="lock-intro">
222 <title>Three Main Types of Kernel Locks: Spinlocks, Mutexes and Semaphores</title> 222 <title>Two Main Types of Kernel Locks: Spinlocks and Mutexes</title>
223 223
224 <para> 224 <para>
225 There are three main types of kernel locks. The fundamental type 225 There are two main types of kernel locks. The fundamental type
226 is the spinlock 226 is the spinlock
227 (<filename class="headerfile">include/asm/spinlock.h</filename>), 227 (<filename class="headerfile">include/asm/spinlock.h</filename>),
228 which is a very simple single-holder lock: if you can't get the 228 which is a very simple single-holder lock: if you can't get the
@@ -240,14 +240,6 @@
240 use a spinlock instead. 240 use a spinlock instead.
241 </para> 241 </para>
242 <para> 242 <para>
243 The third type is a semaphore
244 (<filename class="headerfile">include/linux/semaphore.h</filename>): it
245 can have more than one holder at any time (the number decided at
246 initialization time), although it is most commonly used as a
247 single-holder lock (a mutex). If you can't get a semaphore, your
248 task will be suspended and later on woken up - just like for mutexes.
249 </para>
250 <para>
251 Neither type of lock is recursive: see 243 Neither type of lock is recursive: see
252 <xref linkend="deadlock"/>. 244 <xref linkend="deadlock"/>.
253 </para> 245 </para>
@@ -278,7 +270,7 @@
278 </para> 270 </para>
279 271
280 <para> 272 <para>
281 Semaphores still exist, because they are required for 273 Mutexes still exist, because they are required for
282 synchronization between <firstterm linkend="gloss-usercontext">user 274 synchronization between <firstterm linkend="gloss-usercontext">user
283 contexts</firstterm>, as we will see below. 275 contexts</firstterm>, as we will see below.
284 </para> 276 </para>
@@ -289,18 +281,17 @@
289 281
290 <para> 282 <para>
291 If you have a data structure which is only ever accessed from 283 If you have a data structure which is only ever accessed from
292 user context, then you can use a simple semaphore 284 user context, then you can use a simple mutex
293 (<filename>linux/linux/semaphore.h</filename>) to protect it. This 285 (<filename>include/linux/mutex.h</filename>) to protect it. This
294 is the most trivial case: you initialize the semaphore to the number 286 is the most trivial case: you initialize the mutex. Then you can
295 of resources available (usually 1), and call 287 call <function>mutex_lock_interruptible()</function> to grab the mutex,
296 <function>down_interruptible()</function> to grab the semaphore, and 288 and <function>mutex_unlock()</function> to release it. There is also a
297 <function>up()</function> to release it. There is also a 289 <function>mutex_lock()</function>, which should be avoided, because it
298 <function>down()</function>, which should be avoided, because it
299 will not return if a signal is received. 290 will not return if a signal is received.
300 </para> 291 </para>
301 292
302 <para> 293 <para>
303 Example: <filename>linux/net/core/netfilter.c</filename> allows 294 Example: <filename>net/netfilter/nf_sockopt.c</filename> allows
304 registration of new <function>setsockopt()</function> and 295 registration of new <function>setsockopt()</function> and
305 <function>getsockopt()</function> calls, with 296 <function>getsockopt()</function> calls, with
306 <function>nf_register_sockopt()</function>. Registration and 297 <function>nf_register_sockopt()</function>. Registration and
@@ -515,7 +506,7 @@
515 <listitem> 506 <listitem>
516 <para> 507 <para>
517 If you are in a process context (any syscall) and want to 508 If you are in a process context (any syscall) and want to
518 lock other process out, use a semaphore. You can take a semaphore 509 lock other process out, use a mutex. You can take a mutex
519 and sleep (<function>copy_from_user*(</function> or 510 and sleep (<function>copy_from_user*(</function> or
520 <function>kmalloc(x,GFP_KERNEL)</function>). 511 <function>kmalloc(x,GFP_KERNEL)</function>).
521 </para> 512 </para>
@@ -662,7 +653,7 @@
662<entry>SLBH</entry> 653<entry>SLBH</entry>
663<entry>SLBH</entry> 654<entry>SLBH</entry>
664<entry>SLBH</entry> 655<entry>SLBH</entry>
665<entry>DI</entry> 656<entry>MLI</entry>
666<entry>None</entry> 657<entry>None</entry>
667</row> 658</row>
668 659
@@ -692,8 +683,8 @@
692<entry>spin_lock_bh</entry> 683<entry>spin_lock_bh</entry>
693</row> 684</row>
694<row> 685<row>
695<entry>DI</entry> 686<entry>MLI</entry>
696<entry>down_interruptible</entry> 687<entry>mutex_lock_interruptible</entry>
697</row> 688</row>
698 689
699</tbody> 690</tbody>
@@ -1310,7 +1301,7 @@ as Alan Cox says, <quote>Lock data, not code</quote>.
1310 <para> 1301 <para>
1311 There is a coding bug where a piece of code tries to grab a 1302 There is a coding bug where a piece of code tries to grab a
1312 spinlock twice: it will spin forever, waiting for the lock to 1303 spinlock twice: it will spin forever, waiting for the lock to
1313 be released (spinlocks, rwlocks and semaphores are not 1304 be released (spinlocks, rwlocks and mutexes are not
1314 recursive in Linux). This is trivial to diagnose: not a 1305 recursive in Linux). This is trivial to diagnose: not a
1315 stay-up-five-nights-talk-to-fluffy-code-bunnies kind of 1306 stay-up-five-nights-talk-to-fluffy-code-bunnies kind of
1316 problem. 1307 problem.
@@ -1335,7 +1326,7 @@ as Alan Cox says, <quote>Lock data, not code</quote>.
1335 1326
1336 <para> 1327 <para>
1337 This complete lockup is easy to diagnose: on SMP boxes the 1328 This complete lockup is easy to diagnose: on SMP boxes the
1338 watchdog timer or compiling with <symbol>DEBUG_SPINLOCKS</symbol> set 1329 watchdog timer or compiling with <symbol>DEBUG_SPINLOCK</symbol> set
1339 (<filename>include/linux/spinlock.h</filename>) will show this up 1330 (<filename>include/linux/spinlock.h</filename>) will show this up
1340 immediately when it happens. 1331 immediately when it happens.
1341 </para> 1332 </para>
@@ -1558,7 +1549,7 @@ the amount of locking which needs to be done.
1558 <title>Read/Write Lock Variants</title> 1549 <title>Read/Write Lock Variants</title>
1559 1550
1560 <para> 1551 <para>
1561 Both spinlocks and semaphores have read/write variants: 1552 Both spinlocks and mutexes have read/write variants:
1562 <type>rwlock_t</type> and <structname>struct rw_semaphore</structname>. 1553 <type>rwlock_t</type> and <structname>struct rw_semaphore</structname>.
1563 These divide users into two classes: the readers and the writers. If 1554 These divide users into two classes: the readers and the writers. If
1564 you are only reading the data, you can get a read lock, but to write to 1555 you are only reading the data, you can get a read lock, but to write to
@@ -1681,7 +1672,7 @@ the amount of locking which needs to be done.
1681 #include &lt;linux/slab.h&gt; 1672 #include &lt;linux/slab.h&gt;
1682 #include &lt;linux/string.h&gt; 1673 #include &lt;linux/string.h&gt;
1683+#include &lt;linux/rcupdate.h&gt; 1674+#include &lt;linux/rcupdate.h&gt;
1684 #include &lt;linux/semaphore.h&gt; 1675 #include &lt;linux/mutex.h&gt;
1685 #include &lt;asm/errno.h&gt; 1676 #include &lt;asm/errno.h&gt;
1686 1677
1687 struct object 1678 struct object
@@ -1913,7 +1904,7 @@ machines due to caching.
1913 </listitem> 1904 </listitem>
1914 <listitem> 1905 <listitem>
1915 <para> 1906 <para>
1916 <function> put_user()</function> 1907 <function>put_user()</function>
1917 </para> 1908 </para>
1918 </listitem> 1909 </listitem>
1919 </itemizedlist> 1910 </itemizedlist>
@@ -1927,13 +1918,13 @@ machines due to caching.
1927 1918
1928 <listitem> 1919 <listitem>
1929 <para> 1920 <para>
1930 <function>down_interruptible()</function> and 1921 <function>mutex_lock_interruptible()</function> and
1931 <function>down()</function> 1922 <function>mutex_lock()</function>
1932 </para> 1923 </para>
1933 <para> 1924 <para>
1934 There is a <function>down_trylock()</function> which can be 1925 There is a <function>mutex_trylock()</function> which can be
1935 used inside interrupt context, as it will not sleep. 1926 used inside interrupt context, as it will not sleep.
1936 <function>up()</function> will also never sleep. 1927 <function>mutex_unlock()</function> will also never sleep.
1937 </para> 1928 </para>
1938 </listitem> 1929 </listitem>
1939 </itemizedlist> 1930 </itemizedlist>
@@ -2023,7 +2014,7 @@ machines due to caching.
2023 <para> 2014 <para>
2024 Prior to 2.5, or when <symbol>CONFIG_PREEMPT</symbol> is 2015 Prior to 2.5, or when <symbol>CONFIG_PREEMPT</symbol> is
2025 unset, processes in user context inside the kernel would not 2016 unset, processes in user context inside the kernel would not
2026 preempt each other (ie. you had that CPU until you have it up, 2017 preempt each other (ie. you had that CPU until you gave it up,
2027 except for interrupts). With the addition of 2018 except for interrupts). With the addition of
2028 <symbol>CONFIG_PREEMPT</symbol> in 2.5.4, this changed: when 2019 <symbol>CONFIG_PREEMPT</symbol> in 2.5.4, this changed: when
2029 in user context, higher priority tasks can "cut in": spinlocks 2020 in user context, higher priority tasks can "cut in": spinlocks
diff --git a/Documentation/DocBook/uio-howto.tmpl b/Documentation/DocBook/uio-howto.tmpl
index fdd7f4f887b7..df87d1b93605 100644
--- a/Documentation/DocBook/uio-howto.tmpl
+++ b/Documentation/DocBook/uio-howto.tmpl
@@ -21,6 +21,18 @@
21 </affiliation> 21 </affiliation>
22</author> 22</author>
23 23
24<copyright>
25 <year>2006-2008</year>
26 <holder>Hans-Jürgen Koch.</holder>
27</copyright>
28
29<legalnotice>
30<para>
31This documentation is Free Software licensed under the terms of the
32GPL version 2.
33</para>
34</legalnotice>
35
24<pubdate>2006-12-11</pubdate> 36<pubdate>2006-12-11</pubdate>
25 37
26<abstract> 38<abstract>
@@ -30,6 +42,12 @@
30 42
31<revhistory> 43<revhistory>
32 <revision> 44 <revision>
45 <revnumber>0.5</revnumber>
46 <date>2008-05-22</date>
47 <authorinitials>hjk</authorinitials>
48 <revremark>Added description of write() function.</revremark>
49 </revision>
50 <revision>
33 <revnumber>0.4</revnumber> 51 <revnumber>0.4</revnumber>
34 <date>2007-11-26</date> 52 <date>2007-11-26</date>
35 <authorinitials>hjk</authorinitials> 53 <authorinitials>hjk</authorinitials>
@@ -57,20 +75,9 @@
57</bookinfo> 75</bookinfo>
58 76
59<chapter id="aboutthisdoc"> 77<chapter id="aboutthisdoc">
60<?dbhtml filename="about.html"?> 78<?dbhtml filename="aboutthis.html"?>
61<title>About this document</title> 79<title>About this document</title>
62 80
63<sect1 id="copyright">
64<?dbhtml filename="copyright.html"?>
65<title>Copyright and License</title>
66<para>
67 Copyright (c) 2006 by Hans-Jürgen Koch.</para>
68<para>
69This documentation is Free Software licensed under the terms of the
70GPL version 2.
71</para>
72</sect1>
73
74<sect1 id="translations"> 81<sect1 id="translations">
75<?dbhtml filename="translations.html"?> 82<?dbhtml filename="translations.html"?>
76<title>Translations</title> 83<title>Translations</title>
@@ -189,6 +196,30 @@ interested in translating it, please email me
189 represents the total interrupt count. You can use this number 196 represents the total interrupt count. You can use this number
190 to figure out if you missed some interrupts. 197 to figure out if you missed some interrupts.
191 </para> 198 </para>
199 <para>
200 For some hardware that has more than one interrupt source internally,
201 but not separate IRQ mask and status registers, there might be
202 situations where userspace cannot determine what the interrupt source
203 was if the kernel handler disables them by writing to the chip's IRQ
204 register. In such a case, the kernel has to disable the IRQ completely
205 to leave the chip's register untouched. Now the userspace part can
206 determine the cause of the interrupt, but it cannot re-enable
207 interrupts. Another cornercase is chips where re-enabling interrupts
208 is a read-modify-write operation to a combined IRQ status/acknowledge
209 register. This would be racy if a new interrupt occurred
210 simultaneously.
211 </para>
212 <para>
213 To address these problems, UIO also implements a write() function. It
214 is normally not used and can be ignored for hardware that has only a
215 single interrupt source or has separate IRQ mask and status registers.
216 If you need it, however, a write to <filename>/dev/uioX</filename>
217 will call the <function>irqcontrol()</function> function implemented
218 by the driver. You have to write a 32-bit value that is usually either
219 0 or 1 to disable or enable interrupts. If a driver does not implement
220 <function>irqcontrol()</function>, <function>write()</function> will
221 return with <varname>-ENOSYS</varname>.
222 </para>
192 223
193 <para> 224 <para>
194 To handle interrupts properly, your custom kernel module can 225 To handle interrupts properly, your custom kernel module can
@@ -362,6 +393,14 @@ device is actually used.
362<function>open()</function>, you will probably also want a custom 393<function>open()</function>, you will probably also want a custom
363<function>release()</function> function. 394<function>release()</function> function.
364</para></listitem> 395</para></listitem>
396
397<listitem><para>
398<varname>int (*irqcontrol)(struct uio_info *info, s32 irq_on)
399</varname>: Optional. If you need to be able to enable or disable
400interrupts from userspace by writing to <filename>/dev/uioX</filename>,
401you can implement this function. The parameter <varname>irq_on</varname>
402will be 0 to disable interrupts and 1 to enable them.
403</para></listitem>
365</itemizedlist> 404</itemizedlist>
366 405
367<para> 406<para>
diff --git a/Documentation/HOWTO b/Documentation/HOWTO
index 619e8caf30db..c2371c5a98f9 100644
--- a/Documentation/HOWTO
+++ b/Documentation/HOWTO
@@ -358,7 +358,7 @@ Here is a list of some of the different kernel trees available:
358 - pcmcia, Dominik Brodowski <linux@dominikbrodowski.net> 358 - pcmcia, Dominik Brodowski <linux@dominikbrodowski.net>
359 git.kernel.org:/pub/scm/linux/kernel/git/brodo/pcmcia-2.6.git 359 git.kernel.org:/pub/scm/linux/kernel/git/brodo/pcmcia-2.6.git
360 360
361 - SCSI, James Bottomley <James.Bottomley@SteelEye.com> 361 - SCSI, James Bottomley <James.Bottomley@hansenpartnership.com>
362 git.kernel.org:/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6.git 362 git.kernel.org:/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6.git
363 363
364 - x86, Ingo Molnar <mingo@elte.hu> 364 - x86, Ingo Molnar <mingo@elte.hu>
diff --git a/Documentation/fb/sh7760fb.txt b/Documentation/fb/sh7760fb.txt
new file mode 100644
index 000000000000..c87bfe5c630a
--- /dev/null
+++ b/Documentation/fb/sh7760fb.txt
@@ -0,0 +1,131 @@
1SH7760/SH7763 integrated LCDC Framebuffer driver
2================================================
3
40. Overwiew
5-----------
6The SH7760/SH7763 have an integrated LCD Display controller (LCDC) which
7supports (in theory) resolutions ranging from 1x1 to 1024x1024,
8with color depths ranging from 1 to 16 bits, on STN, DSTN and TFT Panels.
9
10Caveats:
11* Framebuffer memory must be a large chunk allocated at the top
12 of Area3 (HW requirement). Because of this requirement you should NOT
13 make the driver a module since at runtime it may become impossible to
14 get a large enough contiguous chunk of memory.
15
16* The driver does not support changing resolution while loaded
17 (displays aren't hotpluggable anyway)
18
19* Heavy flickering may be observed
20 a) if you're using 15/16bit color modes at >= 640x480 px resolutions,
21 b) during PCMCIA (or any other slow bus) activity.
22
23* Rotation works only 90degress clockwise, and only if horizontal
24 resolution is <= 320 pixels.
25
26files: drivers/video/sh7760fb.c
27 include/asm-sh/sh7760fb.h
28 Documentation/fb/sh7760fb.txt
29
301. Platform setup
31-----------------
32SH7760:
33 Video data is fetched via the DMABRG DMA engine, so you have to
34 configure the SH DMAC for DMABRG mode (write 0x94808080 to the
35 DMARSRA register somewhere at boot).
36
37 PFC registers PCCR and PCDR must be set to peripheral mode.
38 (write zeros to both).
39
40The driver does NOT do the above for you since board setup is, well, job
41of the board setup code.
42
432. Panel definitions
44--------------------
45The LCDC must explicitly be told about the type of LCD panel
46attached. Data must be wrapped in a "struct sh7760fb_platdata" and
47passed to the driver as platform_data.
48
49Suggest you take a closer look at the SH7760 Manual, Section 30.
50(http://documentation.renesas.com/eng/products/mpumcu/e602291_sh7760.pdf)
51
52The following code illustrates what needs to be done to
53get the framebuffer working on a 640x480 TFT:
54
55====================== cut here ======================================
56
57#include <linux/fb.h>
58#include <asm/sh7760fb.h>
59
60/*
61 * NEC NL6440bc26-01 640x480 TFT
62 * dotclock 25175 kHz
63 * Xres 640 Yres 480
64 * Htotal 800 Vtotal 525
65 * HsynStart 656 VsynStart 490
66 * HsynLenn 30 VsynLenn 2
67 *
68 * The linux framebuffer layer does not use the syncstart/synclen
69 * values but right/left/upper/lower margin values. The comments
70 * for the x_margin explain how to calculate those from given
71 * panel sync timings.
72 */
73static struct fb_videomode nl6448bc26 = {
74 .name = "NL6448BC26",
75 .refresh = 60,
76 .xres = 640,
77 .yres = 480,
78 .pixclock = 39683, /* in picoseconds! */
79 .hsync_len = 30,
80 .vsync_len = 2,
81 .left_margin = 114, /* HTOT - (HSYNSLEN + HSYNSTART) */
82 .right_margin = 16, /* HSYNSTART - XRES */
83 .upper_margin = 33, /* VTOT - (VSYNLEN + VSYNSTART) */
84 .lower_margin = 10, /* VSYNSTART - YRES */
85 .sync = FB_SYNC_HOR_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT,
86 .vmode = FB_VMODE_NONINTERLACED,
87 .flag = 0,
88};
89
90static struct sh7760fb_platdata sh7760fb_nl6448 = {
91 .def_mode = &nl6448bc26,
92 .ldmtr = LDMTR_TFT_COLOR_16, /* 16bit TFT panel */
93 .lddfr = LDDFR_8BPP, /* we want 8bit output */
94 .ldpmmr = 0x0070,
95 .ldpspr = 0x0500,
96 .ldaclnr = 0,
97 .ldickr = LDICKR_CLKSRC(LCDC_CLKSRC_EXTERNAL) |
98 LDICKR_CLKDIV(1),
99 .rotate = 0,
100 .novsync = 1,
101 .blank = NULL,
102};
103
104/* SH7760:
105 * 0xFE300800: 256 * 4byte xRGB palette ram
106 * 0xFE300C00: 42 bytes ctrl registers
107 */
108static struct resource sh7760_lcdc_res[] = {
109 [0] = {
110 .start = 0xFE300800,
111 .end = 0xFE300CFF,
112 .flags = IORESOURCE_MEM,
113 },
114 [1] = {
115 .start = 65,
116 .end = 65,
117 .flags = IORESOURCE_IRQ,
118 },
119};
120
121static struct platform_device sh7760_lcdc_dev = {
122 .dev = {
123 .platform_data = &sh7760fb_nl6448,
124 },
125 .name = "sh7760-lcdc",
126 .id = -1,
127 .resource = sh7760_lcdc_res,
128 .num_resources = ARRAY_SIZE(sh7760_lcdc_res),
129};
130
131====================== cut here ======================================
diff --git a/Documentation/fb/tridentfb.txt b/Documentation/fb/tridentfb.txt
index 8a6c8a43e6a3..45d9de5b13a3 100644
--- a/Documentation/fb/tridentfb.txt
+++ b/Documentation/fb/tridentfb.txt
@@ -3,11 +3,25 @@ Tridentfb is a framebuffer driver for some Trident chip based cards.
3The following list of chips is thought to be supported although not all are 3The following list of chips is thought to be supported although not all are
4tested: 4tested:
5 5
6those from the Image series with Cyber in their names - accelerated 6those from the TGUI series 9440/96XX and with Cyber in their names
7those with Blade in their names (Blade3D,CyberBlade...) - accelerated 7those from the Image series and with Cyber in their names
8the newer CyberBladeXP family - nonaccelerated 8those with Blade in their names (Blade3D,CyberBlade...)
9 9the newer CyberBladeXP family
10Only PCI/AGP based cards are supported, none of the older Tridents. 10
11All families are accelerated. Only PCI/AGP based cards are supported,
12none of the older Tridents.
13The driver supports 8, 16 and 32 bits per pixel depths.
14The TGUI family requires a line length to be power of 2 if acceleration
15is enabled. This means that range of possible resolutions and bpp is
16limited comparing to the range if acceleration is disabled (see list
17of parameters below).
18
19Known bugs:
201. The driver randomly locks up on 3DImage975 chip with acceleration
21 enabled. The same happens in X11 (Xorg).
222. The ramdac speeds require some more fine tuning. It is possible to
23 switch resolution which the chip does not support at some depths for
24 older chips.
11 25
12How to use it? 26How to use it?
13============== 27==============
@@ -17,12 +31,11 @@ video=tridentfb
17 31
18The parameters for tridentfb are concatenated with a ':' as in this example. 32The parameters for tridentfb are concatenated with a ':' as in this example.
19 33
20video=tridentfb:800x600,bpp=16,noaccel 34video=tridentfb:800x600-16@75,noaccel
21 35
22The second level parameters that tridentfb understands are: 36The second level parameters that tridentfb understands are:
23 37
24noaccel - turns off acceleration (when it doesn't work for your card) 38noaccel - turns off acceleration (when it doesn't work for your card)
25accel - force text acceleration (for boards which by default are noacceled)
26 39
27fp - use flat panel related stuff 40fp - use flat panel related stuff
28crt - assume monitor is present instead of fp 41crt - assume monitor is present instead of fp
@@ -31,21 +44,24 @@ center - for flat panels and resolutions smaller than native size center the
31 image, otherwise use 44 image, otherwise use
32stretch 45stretch
33 46
34memsize - integer value in Kb, use if your card's memory size is misdetected. 47memsize - integer value in KB, use if your card's memory size is misdetected.
35 look at the driver output to see what it says when initializing. 48 look at the driver output to see what it says when initializing.
36memdiff - integer value in Kb,should be nonzero if your card reports 49
37 more memory than it actually has.For instance mine is 192K less than 50memdiff - integer value in KB, should be nonzero if your card reports
51 more memory than it actually has. For instance mine is 192K less than
38 detection says in all three BIOS selectable situations 2M, 4M, 8M. 52 detection says in all three BIOS selectable situations 2M, 4M, 8M.
39 Only use if your video memory is taken from main memory hence of 53 Only use if your video memory is taken from main memory hence of
40 configurable size.Otherwise use memsize. 54 configurable size. Otherwise use memsize.
41 If in some modes which barely fit the memory you see garbage at the bottom 55 If in some modes which barely fit the memory you see garbage
42 this might help by not letting change to that mode anymore. 56 at the bottom this might help by not letting change to that mode
57 anymore.
43 58
44nativex - the width in pixels of the flat panel.If you know it (usually 1024 59nativex - the width in pixels of the flat panel.If you know it (usually 1024
45 800 or 1280) and it is not what the driver seems to detect use it. 60 800 or 1280) and it is not what the driver seems to detect use it.
46 61
47bpp - bits per pixel (8,16 or 32) 62bpp - bits per pixel (8,16 or 32)
48mode - a mode name like 800x600 (as described in Documentation/fb/modedb.txt) 63mode - a mode name like 800x600-8@75 as described in
64 Documentation/fb/modedb.txt
49 65
50Using insane values for the above parameters will probably result in driver 66Using insane values for the above parameters will probably result in driver
51misbehaviour so take care(for instance memsize=12345678 or memdiff=23784 or 67misbehaviour so take care(for instance memsize=12345678 or memdiff=23784 or
diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt
index 9f73587219e8..09c4a1efb8e3 100644
--- a/Documentation/feature-removal-schedule.txt
+++ b/Documentation/feature-removal-schedule.txt
@@ -300,14 +300,6 @@ Who: ocfs2-devel@oss.oracle.com
300 300
301--------------------------- 301---------------------------
302 302
303What: asm/semaphore.h
304When: 2.6.26
305Why: Implementation became generic; users should now include
306 linux/semaphore.h instead.
307Who: Matthew Wilcox <willy@linux.intel.com>
308
309---------------------------
310
311What: SCTP_GET_PEER_ADDRS_NUM_OLD, SCTP_GET_PEER_ADDRS_OLD, 303What: SCTP_GET_PEER_ADDRS_NUM_OLD, SCTP_GET_PEER_ADDRS_OLD,
312 SCTP_GET_LOCAL_ADDRS_NUM_OLD, SCTP_GET_LOCAL_ADDRS_OLD 304 SCTP_GET_LOCAL_ADDRS_NUM_OLD, SCTP_GET_LOCAL_ADDRS_OLD
313When: June 2009 305When: June 2009
diff --git a/Documentation/filesystems/Locking b/Documentation/filesystems/Locking
index 8b22d7d8b991..680fb566b928 100644
--- a/Documentation/filesystems/Locking
+++ b/Documentation/filesystems/Locking
@@ -510,6 +510,7 @@ prototypes:
510 void (*close)(struct vm_area_struct*); 510 void (*close)(struct vm_area_struct*);
511 int (*fault)(struct vm_area_struct*, struct vm_fault *); 511 int (*fault)(struct vm_area_struct*, struct vm_fault *);
512 int (*page_mkwrite)(struct vm_area_struct *, struct page *); 512 int (*page_mkwrite)(struct vm_area_struct *, struct page *);
513 int (*access)(struct vm_area_struct *, unsigned long, void*, int, int);
513 514
514locking rules: 515locking rules:
515 BKL mmap_sem PageLocked(page) 516 BKL mmap_sem PageLocked(page)
@@ -517,6 +518,7 @@ open: no yes
517close: no yes 518close: no yes
518fault: no yes 519fault: no yes
519page_mkwrite: no yes no 520page_mkwrite: no yes no
521access: no yes
520 522
521 ->page_mkwrite() is called when a previously read-only page is 523 ->page_mkwrite() is called when a previously read-only page is
522about to become writeable. The file system is responsible for 524about to become writeable. The file system is responsible for
@@ -525,6 +527,11 @@ taking to lock out truncate, the page range should be verified to be
525within i_size. The page mapping should also be checked that it is not 527within i_size. The page mapping should also be checked that it is not
526NULL. 528NULL.
527 529
530 ->access() is called when get_user_pages() fails in
531acces_process_vm(), typically used to debug a process through
532/proc/pid/mem or ptrace. This function is needed only for
533VM_IO | VM_PFNMAP VMAs.
534
528================================================================================ 535================================================================================
529 Dubious stuff 536 Dubious stuff
530 537
diff --git a/Documentation/filesystems/bfs.txt b/Documentation/filesystems/bfs.txt
index ea825e178e79..78043d5a8fc3 100644
--- a/Documentation/filesystems/bfs.txt
+++ b/Documentation/filesystems/bfs.txt
@@ -26,11 +26,11 @@ You can simplify mounting by just typing:
26 26
27this will allocate the first available loopback device (and load loop.o 27this will allocate the first available loopback device (and load loop.o
28kernel module if necessary) automatically. If the loopback driver is not 28kernel module if necessary) automatically. If the loopback driver is not
29loaded automatically, make sure that your kernel is compiled with kmod 29loaded automatically, make sure that you have compiled the module and
30support (CONFIG_KMOD) enabled. Beware that umount will not 30that modprobe is functioning. Beware that umount will not deallocate
31deallocate /dev/loopN device if /etc/mtab file on your system is a 31/dev/loopN device if /etc/mtab file on your system is a symbolic link to
32symbolic link to /proc/mounts. You will need to do it manually using 32/proc/mounts. You will need to do it manually using "-d" switch of
33"-d" switch of losetup(8). Read losetup(8) manpage for more info. 33losetup(8). Read losetup(8) manpage for more info.
34 34
35To create the BFS image under UnixWare you need to find out first which 35To create the BFS image under UnixWare you need to find out first which
36slice contains it. The command prtvtoc(1M) is your friend: 36slice contains it. The command prtvtoc(1M) is your friend:
diff --git a/Documentation/filesystems/proc.txt b/Documentation/filesystems/proc.txt
index 7f268f327d75..8c6384bdfed4 100644
--- a/Documentation/filesystems/proc.txt
+++ b/Documentation/filesystems/proc.txt
@@ -296,6 +296,7 @@ Table 1-4: Kernel info in /proc
296 uptime System uptime 296 uptime System uptime
297 version Kernel version 297 version Kernel version
298 video bttv info of video resources (2.4) 298 video bttv info of video resources (2.4)
299 vmallocinfo Show vmalloced areas
299.............................................................................. 300..............................................................................
300 301
301You can, for example, check which interrupts are currently in use and what 302You can, for example, check which interrupts are currently in use and what
@@ -557,6 +558,49 @@ VmallocTotal: total size of vmalloc memory area
557 VmallocUsed: amount of vmalloc area which is used 558 VmallocUsed: amount of vmalloc area which is used
558VmallocChunk: largest contigious block of vmalloc area which is free 559VmallocChunk: largest contigious block of vmalloc area which is free
559 560
561..............................................................................
562
563vmallocinfo:
564
565Provides information about vmalloced/vmaped areas. One line per area,
566containing the virtual address range of the area, size in bytes,
567caller information of the creator, and optional information depending
568on the kind of area :
569
570 pages=nr number of pages
571 phys=addr if a physical address was specified
572 ioremap I/O mapping (ioremap() and friends)
573 vmalloc vmalloc() area
574 vmap vmap()ed pages
575 user VM_USERMAP area
576 vpages buffer for pages pointers was vmalloced (huge area)
577 N<node>=nr (Only on NUMA kernels)
578 Number of pages allocated on memory node <node>
579
580> cat /proc/vmallocinfo
5810xffffc20000000000-0xffffc20000201000 2101248 alloc_large_system_hash+0x204 ...
582 /0x2c0 pages=512 vmalloc N0=128 N1=128 N2=128 N3=128
5830xffffc20000201000-0xffffc20000302000 1052672 alloc_large_system_hash+0x204 ...
584 /0x2c0 pages=256 vmalloc N0=64 N1=64 N2=64 N3=64
5850xffffc20000302000-0xffffc20000304000 8192 acpi_tb_verify_table+0x21/0x4f...
586 phys=7fee8000 ioremap
5870xffffc20000304000-0xffffc20000307000 12288 acpi_tb_verify_table+0x21/0x4f...
588 phys=7fee7000 ioremap
5890xffffc2000031d000-0xffffc2000031f000 8192 init_vdso_vars+0x112/0x210
5900xffffc2000031f000-0xffffc2000032b000 49152 cramfs_uncompress_init+0x2e ...
591 /0x80 pages=11 vmalloc N0=3 N1=3 N2=2 N3=3
5920xffffc2000033a000-0xffffc2000033d000 12288 sys_swapon+0x640/0xac0 ...
593 pages=2 vmalloc N1=2
5940xffffc20000347000-0xffffc2000034c000 20480 xt_alloc_table_info+0xfe ...
595 /0x130 [x_tables] pages=4 vmalloc N0=4
5960xffffffffa0000000-0xffffffffa000f000 61440 sys_init_module+0xc27/0x1d00 ...
597 pages=14 vmalloc N2=14
5980xffffffffa000f000-0xffffffffa0014000 20480 sys_init_module+0xc27/0x1d00 ...
599 pages=4 vmalloc N1=4
6000xffffffffa0014000-0xffffffffa0017000 12288 sys_init_module+0xc27/0x1d00 ...
601 pages=2 vmalloc N1=2
6020xffffffffa0017000-0xffffffffa0022000 45056 sys_init_module+0xc27/0x1d00 ...
603 pages=10 vmalloc N0=10
560 604
5611.3 IDE devices in /proc/ide 6051.3 IDE devices in /proc/ide
562---------------------------- 606----------------------------
diff --git a/Documentation/filesystems/sysfs.txt b/Documentation/filesystems/sysfs.txt
index 7f27b8f840d0..9e9c348275a9 100644
--- a/Documentation/filesystems/sysfs.txt
+++ b/Documentation/filesystems/sysfs.txt
@@ -248,6 +248,7 @@ The top level sysfs directory looks like:
248block/ 248block/
249bus/ 249bus/
250class/ 250class/
251dev/
251devices/ 252devices/
252firmware/ 253firmware/
253net/ 254net/
@@ -274,6 +275,11 @@ fs/ contains a directory for some filesystems. Currently each
274filesystem wanting to export attributes must create its own hierarchy 275filesystem wanting to export attributes must create its own hierarchy
275below fs/ (see ./fuse.txt for an example). 276below fs/ (see ./fuse.txt for an example).
276 277
278dev/ contains two directories char/ and block/. Inside these two
279directories there are symlinks named <major>:<minor>. These symlinks
280point to the sysfs directory for the given device. /sys/dev provides a
281quick way to lookup the sysfs interface for a device from the result of
282a stat(2) operation.
277 283
278More information can driver-model specific features can be found in 284More information can driver-model specific features can be found in
279Documentation/driver-model/. 285Documentation/driver-model/.
diff --git a/Documentation/ia64/paravirt_ops.txt b/Documentation/ia64/paravirt_ops.txt
new file mode 100644
index 000000000000..39ded02ec33f
--- /dev/null
+++ b/Documentation/ia64/paravirt_ops.txt
@@ -0,0 +1,137 @@
1Paravirt_ops on IA64
2====================
3 21 May 2008, Isaku Yamahata <yamahata@valinux.co.jp>
4
5
6Introduction
7------------
8The aim of this documentation is to help with maintainability and/or to
9encourage people to use paravirt_ops/IA64.
10
11paravirt_ops (pv_ops in short) is a way for virtualization support of
12Linux kernel on x86. Several ways for virtualization support were
13proposed, paravirt_ops is the winner.
14On the other hand, now there are also several IA64 virtualization
15technologies like kvm/IA64, xen/IA64 and many other academic IA64
16hypervisors so that it is good to add generic virtualization
17infrastructure on Linux/IA64.
18
19
20What is paravirt_ops?
21---------------------
22It has been developed on x86 as virtualization support via API, not ABI.
23It allows each hypervisor to override operations which are important for
24hypervisors at API level. And it allows a single kernel binary to run on
25all supported execution environments including native machine.
26Essentially paravirt_ops is a set of function pointers which represent
27operations corresponding to low level sensitive instructions and high
28level functionalities in various area. But one significant difference
29from usual function pointer table is that it allows optimization with
30binary patch. It is because some of these operations are very
31performance sensitive and indirect call overhead is not negligible.
32With binary patch, indirect C function call can be transformed into
33direct C function call or in-place execution to eliminate the overhead.
34
35Thus, operations of paravirt_ops are classified into three categories.
36- simple indirect call
37 These operations correspond to high level functionality so that the
38 overhead of indirect call isn't very important.
39
40- indirect call which allows optimization with binary patch
41 Usually these operations correspond to low level instructions. They
42 are called frequently and performance critical. So the overhead is
43 very important.
44
45- a set of macros for hand written assembly code
46 Hand written assembly codes (.S files) also need paravirtualization
47 because they include sensitive instructions or some of code paths in
48 them are very performance critical.
49
50
51The relation to the IA64 machine vector
52---------------------------------------
53Linux/IA64 has the IA64 machine vector functionality which allows the
54kernel to switch implementations (e.g. initialization, ipi, dma api...)
55depending on executing platform.
56We can replace some implementations very easily defining a new machine
57vector. Thus another approach for virtualization support would be
58enhancing the machine vector functionality.
59But paravirt_ops approach was taken because
60- virtualization support needs wider support than machine vector does.
61 e.g. low level instruction paravirtualization. It must be
62 initialized very early before platform detection.
63
64- virtualization support needs more functionality like binary patch.
65 Probably the calling overhead might not be very large compared to the
66 emulation overhead of virtualization. However in the native case, the
67 overhead should be eliminated completely.
68 A single kernel binary should run on each environment including native,
69 and the overhead of paravirt_ops on native environment should be as
70 small as possible.
71
72- for full virtualization technology, e.g. KVM/IA64 or
73 Xen/IA64 HVM domain, the result would be
74 (the emulated platform machine vector. probably dig) + (pv_ops).
75 This means that the virtualization support layer should be under
76 the machine vector layer.
77
78Possibly it might be better to move some function pointers from
79paravirt_ops to machine vector. In fact, Xen domU case utilizes both
80pv_ops and machine vector.
81
82
83IA64 paravirt_ops
84-----------------
85In this section, the concrete paravirt_ops will be discussed.
86Because of the architecture difference between ia64 and x86, the
87resulting set of functions is very different from x86 pv_ops.
88
89- C function pointer tables
90They are not very performance critical so that simple C indirect
91function call is acceptable. The following structures are defined at
92this moment. For details see linux/include/asm-ia64/paravirt.h
93 - struct pv_info
94 This structure describes the execution environment.
95 - struct pv_init_ops
96 This structure describes the various initialization hooks.
97 - struct pv_iosapic_ops
98 This structure describes hooks to iosapic operations.
99 - struct pv_irq_ops
100 This structure describes hooks to irq related operations
101 - struct pv_time_op
102 This structure describes hooks to steal time accounting.
103
104- a set of indirect calls which need optimization
105Currently this class of functions correspond to a subset of IA64
106intrinsics. At this moment the optimization with binary patch isn't
107implemented yet.
108struct pv_cpu_op is defined. For details see
109linux/include/asm-ia64/paravirt_privop.h
110Mostly they correspond to ia64 intrinsics 1-to-1.
111Caveat: Now they are defined as C indirect function pointers, but in
112order to support binary patch optimization, they will be changed
113using GCC extended inline assembly code.
114
115- a set of macros for hand written assembly code (.S files)
116For maintenance purpose, the taken approach for .S files is single
117source code and compile multiple times with different macros definitions.
118Each pv_ops instance must define those macros to compile.
119The important thing here is that sensitive, but non-privileged
120instructions must be paravirtualized and that some privileged
121instructions also need paravirtualization for reasonable performance.
122Developers who modify .S files must be aware of that. At this moment
123an easy checker is implemented to detect paravirtualization breakage.
124But it doesn't cover all the cases.
125
126Sometimes this set of macros is called pv_cpu_asm_op. But there is no
127corresponding structure in the source code.
128Those macros mostly 1:1 correspond to a subset of privileged
129instructions. See linux/include/asm-ia64/native/inst.h.
130And some functions written in assembly also need to be overrided so
131that each pv_ops instance have to define some macros. Again see
132linux/include/asm-ia64/native/inst.h.
133
134
135Those structures must be initialized very early before start_kernel.
136Probably initialized in head.S using multi entry point or some other trick.
137For native case implementation see linux/arch/ia64/kernel/paravirt.c.
diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
index 30d44b78171a..497a98dafdaa 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -87,7 +87,8 @@ parameter is applicable:
87 SH SuperH architecture is enabled. 87 SH SuperH architecture is enabled.
88 SMP The kernel is an SMP kernel. 88 SMP The kernel is an SMP kernel.
89 SPARC Sparc architecture is enabled. 89 SPARC Sparc architecture is enabled.
90 SWSUSP Software suspend is enabled. 90 SWSUSP Software suspend (hibernation) is enabled.
91 SUSPEND System suspend states are enabled.
91 TS Appropriate touchscreen support is enabled. 92 TS Appropriate touchscreen support is enabled.
92 USB USB support is enabled. 93 USB USB support is enabled.
93 USBHID USB Human Interface Device support is enabled. 94 USBHID USB Human Interface Device support is enabled.
@@ -147,10 +148,12 @@ and is between 256 and 4096 characters. It is defined in the file
147 default: 0 148 default: 0
148 149
149 acpi_sleep= [HW,ACPI] Sleep options 150 acpi_sleep= [HW,ACPI] Sleep options
150 Format: { s3_bios, s3_mode, s3_beep, old_ordering } 151 Format: { s3_bios, s3_mode, s3_beep, s4_nohwsig, old_ordering }
151 See Documentation/power/video.txt for s3_bios and s3_mode. 152 See Documentation/power/video.txt for s3_bios and s3_mode.
152 s3_beep is for debugging; it makes the PC's speaker beep 153 s3_beep is for debugging; it makes the PC's speaker beep
153 as soon as the kernel's real-mode entry point is called. 154 as soon as the kernel's real-mode entry point is called.
155 s4_nohwsig prevents ACPI hardware signature from being
156 used during resume from hibernation.
154 old_ordering causes the ACPI 1.0 ordering of the _PTS 157 old_ordering causes the ACPI 1.0 ordering of the _PTS
155 control method, wrt putting devices into low power 158 control method, wrt putting devices into low power
156 states, to be enforced (the ACPI 2.0 ordering of _PTS is 159 states, to be enforced (the ACPI 2.0 ordering of _PTS is
@@ -774,8 +777,22 @@ and is between 256 and 4096 characters. It is defined in the file
774 hisax= [HW,ISDN] 777 hisax= [HW,ISDN]
775 See Documentation/isdn/README.HiSax. 778 See Documentation/isdn/README.HiSax.
776 779
777 hugepages= [HW,X86-32,IA-64] Maximal number of HugeTLB pages. 780 hugepages= [HW,X86-32,IA-64] HugeTLB pages to allocate at boot.
778 hugepagesz= [HW,IA-64,PPC] The size of the HugeTLB pages. 781 hugepagesz= [HW,IA-64,PPC,X86-64] The size of the HugeTLB pages.
782 On x86-64 and powerpc, this option can be specified
783 multiple times interleaved with hugepages= to reserve
784 huge pages of different sizes. Valid pages sizes on
785 x86-64 are 2M (when the CPU supports "pse") and 1G
786 (when the CPU supports the "pdpe1gb" cpuinfo flag)
787 Note that 1GB pages can only be allocated at boot time
788 using hugepages= and not freed afterwards.
789 default_hugepagesz=
790 [same as hugepagesz=] The size of the default
791 HugeTLB page size. This is the size represented by
792 the legacy /proc/ hugepages APIs, used for SHM, and
793 default size when mounting hugetlbfs filesystems.
794 Defaults to the default architecture's huge page size
795 if not specified.
779 796
780 i8042.direct [HW] Put keyboard port into non-translated mode 797 i8042.direct [HW] Put keyboard port into non-translated mode
781 i8042.dumbkbd [HW] Pretend that controller can only read data from 798 i8042.dumbkbd [HW] Pretend that controller can only read data from
@@ -1225,6 +1242,14 @@ and is between 256 and 4096 characters. It is defined in the file
1225 1242
1226 mga= [HW,DRM] 1243 mga= [HW,DRM]
1227 1244
1245 mminit_loglevel=
1246 [KNL] When CONFIG_DEBUG_MEMORY_INIT is set, this
1247 parameter allows control of the logging verbosity for
1248 the additional memory initialisation checks. A value
1249 of 0 disables mminit logging and a level of 4 will
1250 log everything. Information is printed at KERN_DEBUG
1251 so loglevel=8 may also need to be specified.
1252
1228 mousedev.tap_time= 1253 mousedev.tap_time=
1229 [MOUSE] Maximum time between finger touching and 1254 [MOUSE] Maximum time between finger touching and
1230 leaving touchpad surface for touch to be considered 1255 leaving touchpad surface for touch to be considered
@@ -2034,6 +2059,9 @@ and is between 256 and 4096 characters. It is defined in the file
2034 2059
2035 snd-ymfpci= [HW,ALSA] 2060 snd-ymfpci= [HW,ALSA]
2036 2061
2062 softlockup_panic=
2063 [KNL] Should the soft-lockup detector generate panics.
2064
2037 sonypi.*= [HW] Sony Programmable I/O Control Device driver 2065 sonypi.*= [HW] Sony Programmable I/O Control Device driver
2038 See Documentation/sonypi.txt 2066 See Documentation/sonypi.txt
2039 2067
@@ -2098,6 +2126,12 @@ and is between 256 and 4096 characters. It is defined in the file
2098 2126
2099 tdfx= [HW,DRM] 2127 tdfx= [HW,DRM]
2100 2128
2129 test_suspend= [SUSPEND]
2130 Specify "mem" (for Suspend-to-RAM) or "standby" (for
2131 standby suspend) as the system sleep state to briefly
2132 enter during system startup. The system is woken from
2133 this state using a wakeup-capable RTC alarm.
2134
2101 thash_entries= [KNL,NET] 2135 thash_entries= [KNL,NET]
2102 Set number of hash buckets for TCP connection 2136 Set number of hash buckets for TCP connection
2103 2137
diff --git a/Documentation/laptops/thinkpad-acpi.txt b/Documentation/laptops/thinkpad-acpi.txt
index 64b3f146e4b0..02dc748b76c4 100644
--- a/Documentation/laptops/thinkpad-acpi.txt
+++ b/Documentation/laptops/thinkpad-acpi.txt
@@ -1,7 +1,7 @@
1 ThinkPad ACPI Extras Driver 1 ThinkPad ACPI Extras Driver
2 2
3 Version 0.20 3 Version 0.21
4 April 09th, 2008 4 May 29th, 2008
5 5
6 Borislav Deianov <borislav@users.sf.net> 6 Borislav Deianov <borislav@users.sf.net>
7 Henrique de Moraes Holschuh <hmh@hmh.eng.br> 7 Henrique de Moraes Holschuh <hmh@hmh.eng.br>
@@ -621,7 +621,8 @@ Bluetooth
621--------- 621---------
622 622
623procfs: /proc/acpi/ibm/bluetooth 623procfs: /proc/acpi/ibm/bluetooth
624sysfs device attribute: bluetooth_enable 624sysfs device attribute: bluetooth_enable (deprecated)
625sysfs rfkill class: switch "tpacpi_bluetooth_sw"
625 626
626This feature shows the presence and current state of a ThinkPad 627This feature shows the presence and current state of a ThinkPad
627Bluetooth device in the internal ThinkPad CDC slot. 628Bluetooth device in the internal ThinkPad CDC slot.
@@ -643,8 +644,12 @@ Sysfs notes:
643 0: disables Bluetooth / Bluetooth is disabled 644 0: disables Bluetooth / Bluetooth is disabled
644 1: enables Bluetooth / Bluetooth is enabled. 645 1: enables Bluetooth / Bluetooth is enabled.
645 646
646 Note: this interface will be probably be superseded by the 647 Note: this interface has been superseded by the generic rfkill
647 generic rfkill class, so it is NOT to be considered stable yet. 648 class. It has been deprecated, and it will be removed in year
649 2010.
650
651 rfkill controller switch "tpacpi_bluetooth_sw": refer to
652 Documentation/rfkill.txt for details.
648 653
649Video output control -- /proc/acpi/ibm/video 654Video output control -- /proc/acpi/ibm/video
650-------------------------------------------- 655--------------------------------------------
@@ -1374,7 +1379,8 @@ EXPERIMENTAL: WAN
1374----------------- 1379-----------------
1375 1380
1376procfs: /proc/acpi/ibm/wan 1381procfs: /proc/acpi/ibm/wan
1377sysfs device attribute: wwan_enable 1382sysfs device attribute: wwan_enable (deprecated)
1383sysfs rfkill class: switch "tpacpi_wwan_sw"
1378 1384
1379This feature is marked EXPERIMENTAL because the implementation 1385This feature is marked EXPERIMENTAL because the implementation
1380directly accesses hardware registers and may not work as expected. USE 1386directly accesses hardware registers and may not work as expected. USE
@@ -1404,8 +1410,12 @@ Sysfs notes:
1404 0: disables WWAN card / WWAN card is disabled 1410 0: disables WWAN card / WWAN card is disabled
1405 1: enables WWAN card / WWAN card is enabled. 1411 1: enables WWAN card / WWAN card is enabled.
1406 1412
1407 Note: this interface will be probably be superseded by the 1413 Note: this interface has been superseded by the generic rfkill
1408 generic rfkill class, so it is NOT to be considered stable yet. 1414 class. It has been deprecated, and it will be removed in year
1415 2010.
1416
1417 rfkill controller switch "tpacpi_wwan_sw": refer to
1418 Documentation/rfkill.txt for details.
1409 1419
1410Multiple Commands, Module Parameters 1420Multiple Commands, Module Parameters
1411------------------------------------ 1421------------------------------------
diff --git a/Documentation/networking/e1000.txt b/Documentation/networking/e1000.txt
index 61b171cf5313..2df71861e578 100644
--- a/Documentation/networking/e1000.txt
+++ b/Documentation/networking/e1000.txt
@@ -513,21 +513,11 @@ Additional Configurations
513 Intel(R) PRO/1000 PT Dual Port Server Connection 513 Intel(R) PRO/1000 PT Dual Port Server Connection
514 Intel(R) PRO/1000 PT Dual Port Server Adapter 514 Intel(R) PRO/1000 PT Dual Port Server Adapter
515 Intel(R) PRO/1000 PF Dual Port Server Adapter 515 Intel(R) PRO/1000 PF Dual Port Server Adapter
516 Intel(R) PRO/1000 PT Quad Port Server Adapter 516 Intel(R) PRO/1000 PT Quad Port Server Adapter
517 517
518 NAPI 518 NAPI
519 ---- 519 ----
520 NAPI (Rx polling mode) is supported in the e1000 driver. NAPI is enabled 520 NAPI (Rx polling mode) is enabled in the e1000 driver.
521 or disabled based on the configuration of the kernel. To override
522 the default, use the following compile-time flags.
523
524 To enable NAPI, compile the driver module, passing in a configuration option:
525
526 make CFLAGS_EXTRA=-DE1000_NAPI install
527
528 To disable NAPI, compile the driver module, passing in a configuration option:
529
530 make CFLAGS_EXTRA=-DE1000_NO_NAPI install
531 521
532 See www.cyberus.ca/~hadi/usenix-paper.tgz for more information on NAPI. 522 See www.cyberus.ca/~hadi/usenix-paper.tgz for more information on NAPI.
533 523
diff --git a/Documentation/networking/udplite.txt b/Documentation/networking/udplite.txt
index 3870f280280b..855d8da57a23 100644
--- a/Documentation/networking/udplite.txt
+++ b/Documentation/networking/udplite.txt
@@ -148,7 +148,7 @@
148 getsockopt(sockfd, SOL_SOCKET, SO_NO_CHECK, &value, ...); 148 getsockopt(sockfd, SOL_SOCKET, SO_NO_CHECK, &value, ...);
149 149
150 is meaningless (as in TCP). Packets with a zero checksum field are 150 is meaningless (as in TCP). Packets with a zero checksum field are
151 illegal (cf. RFC 3828, sec. 3.1) will be silently discarded. 151 illegal (cf. RFC 3828, sec. 3.1) and will be silently discarded.
152 152
153 4) Fragmentation 153 4) Fragmentation
154 154
diff --git a/Documentation/power/00-INDEX b/Documentation/power/00-INDEX
index a55d7f1c836d..fb742c213c9e 100644
--- a/Documentation/power/00-INDEX
+++ b/Documentation/power/00-INDEX
@@ -1,5 +1,7 @@
100-INDEX 100-INDEX
2 - This file 2 - This file
3apm-acpi.txt
4 - basic info about the APM and ACPI support.
3basic-pm-debugging.txt 5basic-pm-debugging.txt
4 - Debugging suspend and resume 6 - Debugging suspend and resume
5devices.txt 7devices.txt
@@ -14,8 +16,6 @@ notifiers.txt
14 - Registering suspend notifiers in device drivers 16 - Registering suspend notifiers in device drivers
15pci.txt 17pci.txt
16 - How the PCI Subsystem Does Power Management 18 - How the PCI Subsystem Does Power Management
17pm.txt
18 - info on Linux power management support.
19pm_qos_interface.txt 19pm_qos_interface.txt
20 - info on Linux PM Quality of Service interface 20 - info on Linux PM Quality of Service interface
21power_supply_class.txt 21power_supply_class.txt
diff --git a/Documentation/power/apm-acpi.txt b/Documentation/power/apm-acpi.txt
new file mode 100644
index 000000000000..1bd799dc17e8
--- /dev/null
+++ b/Documentation/power/apm-acpi.txt
@@ -0,0 +1,32 @@
1APM or ACPI?
2------------
3If you have a relatively recent x86 mobile, desktop, or server system,
4odds are it supports either Advanced Power Management (APM) or
5Advanced Configuration and Power Interface (ACPI). ACPI is the newer
6of the two technologies and puts power management in the hands of the
7operating system, allowing for more intelligent power management than
8is possible with BIOS controlled APM.
9
10The best way to determine which, if either, your system supports is to
11build a kernel with both ACPI and APM enabled (as of 2.3.x ACPI is
12enabled by default). If a working ACPI implementation is found, the
13ACPI driver will override and disable APM, otherwise the APM driver
14will be used.
15
16No, sorry, you cannot have both ACPI and APM enabled and running at
17once. Some people with broken ACPI or broken APM implementations
18would like to use both to get a full set of working features, but you
19simply cannot mix and match the two. Only one power management
20interface can be in control of the machine at once. Think about it..
21
22User-space Daemons
23------------------
24Both APM and ACPI rely on user-space daemons, apmd and acpid
25respectively, to be completely functional. Obtain both of these
26daemons from your Linux distribution or from the Internet (see below)
27and be sure that they are started sometime in the system boot process.
28Go ahead and start both. If ACPI or APM is not available on your
29system the associated daemon will exit gracefully.
30
31 apmd: http://worldvisions.ca/~apenwarr/apmd/
32 acpid: http://acpid.sf.net/
diff --git a/Documentation/power/pm.txt b/Documentation/power/pm.txt
deleted file mode 100644
index be841507e43f..000000000000
--- a/Documentation/power/pm.txt
+++ /dev/null
@@ -1,257 +0,0 @@
1 Linux Power Management Support
2
3This document briefly describes how to use power management with your
4Linux system and how to add power management support to Linux drivers.
5
6APM or ACPI?
7------------
8If you have a relatively recent x86 mobile, desktop, or server system,
9odds are it supports either Advanced Power Management (APM) or
10Advanced Configuration and Power Interface (ACPI). ACPI is the newer
11of the two technologies and puts power management in the hands of the
12operating system, allowing for more intelligent power management than
13is possible with BIOS controlled APM.
14
15The best way to determine which, if either, your system supports is to
16build a kernel with both ACPI and APM enabled (as of 2.3.x ACPI is
17enabled by default). If a working ACPI implementation is found, the
18ACPI driver will override and disable APM, otherwise the APM driver
19will be used.
20
21No, sorry, you cannot have both ACPI and APM enabled and running at
22once. Some people with broken ACPI or broken APM implementations
23would like to use both to get a full set of working features, but you
24simply cannot mix and match the two. Only one power management
25interface can be in control of the machine at once. Think about it..
26
27User-space Daemons
28------------------
29Both APM and ACPI rely on user-space daemons, apmd and acpid
30respectively, to be completely functional. Obtain both of these
31daemons from your Linux distribution or from the Internet (see below)
32and be sure that they are started sometime in the system boot process.
33Go ahead and start both. If ACPI or APM is not available on your
34system the associated daemon will exit gracefully.
35
36 apmd: http://worldvisions.ca/~apenwarr/apmd/
37 acpid: http://acpid.sf.net/
38
39Driver Interface -- OBSOLETE, DO NOT USE!
40----------------*************************
41
42Note: pm_register(), pm_access(), pm_dev_idle() and friends are
43obsolete. Please do not use them. Instead you should properly hook
44your driver into the driver model, and use its suspend()/resume()
45callbacks to do this kind of stuff.
46
47If you are writing a new driver or maintaining an old driver, it
48should include power management support. Without power management
49support, a single driver may prevent a system with power management
50capabilities from ever being able to suspend (safely).
51
52Overview:
531) Register each instance of a device with "pm_register"
542) Call "pm_access" before accessing the hardware.
55 (this will ensure that the hardware is awake and ready)
563) Your "pm_callback" is called before going into a
57 suspend state (ACPI D1-D3) or after resuming (ACPI D0)
58 from a suspend.
594) Call "pm_dev_idle" when the device is not being used
60 (optional but will improve device idle detection)
615) When unloaded, unregister the device with "pm_unregister"
62
63/*
64 * Description: Register a device with the power-management subsystem
65 *
66 * Parameters:
67 * type - device type (PCI device, system device, ...)
68 * id - instance number or unique identifier
69 * cback - request handler callback (suspend, resume, ...)
70 *
71 * Returns: Registered PM device or NULL on error
72 *
73 * Examples:
74 * dev = pm_register(PM_SYS_DEV, PM_SYS_VGA, vga_callback);
75 *
76 * struct pci_dev *pci_dev = pci_find_dev(...);
77 * dev = pm_register(PM_PCI_DEV, PM_PCI_ID(pci_dev), callback);
78 */
79struct pm_dev *pm_register(pm_dev_t type, unsigned long id, pm_callback cback);
80
81/*
82 * Description: Unregister a device with the power management subsystem
83 *
84 * Parameters:
85 * dev - PM device previously returned from pm_register
86 */
87void pm_unregister(struct pm_dev *dev);
88
89/*
90 * Description: Unregister all devices with a matching callback function
91 *
92 * Parameters:
93 * cback - previously registered request callback
94 *
95 * Notes: Provided for easier porting from old APM interface
96 */
97void pm_unregister_all(pm_callback cback);
98
99/*
100 * Power management request callback
101 *
102 * Parameters:
103 * dev - PM device previously returned from pm_register
104 * rqst - request type
105 * data - data, if any, associated with the request
106 *
107 * Returns: 0 if the request is successful
108 * EINVAL if the request is not supported
109 * EBUSY if the device is now busy and cannot handle the request
110 * ENOMEM if the device was unable to handle the request due to memory
111 *
112 * Details: The device request callback will be called before the
113 * device/system enters a suspend state (ACPI D1-D3) or
114 * or after the device/system resumes from suspend (ACPI D0).
115 * For PM_SUSPEND, the ACPI D-state being entered is passed
116 * as the "data" argument to the callback. The device
117 * driver should save (PM_SUSPEND) or restore (PM_RESUME)
118 * device context when the request callback is called.
119 *
120 * Once a driver returns 0 (success) from a suspend
121 * request, it should not process any further requests or
122 * access the device hardware until a call to "pm_access" is made.
123 */
124typedef int (*pm_callback)(struct pm_dev *dev, pm_request_t rqst, void *data);
125
126Driver Details
127--------------
128This is just a quick Q&A as a stopgap until a real driver writers'
129power management guide is available.
130
131Q: When is a device suspended?
132
133Devices can be suspended based on direct user request (eg. laptop lid
134closes), system power policy (eg. sleep after 30 minutes of console
135inactivity), or device power policy (eg. power down device after 5
136minutes of inactivity)
137
138Q: Must a driver honor a suspend request?
139
140No, a driver can return -EBUSY from a suspend request and this
141will stop the system from suspending. When a suspend request
142fails, all suspended devices are resumed and the system continues
143to run. Suspend can be retried at a later time.
144
145Q: Can the driver block suspend/resume requests?
146
147Yes, a driver can delay its return from a suspend or resume
148request until the device is ready to handle requests. It
149is advantageous to return as quickly as possible from a
150request as suspend/resume are done serially.
151
152Q: What context is a suspend/resume initiated from?
153
154A suspend or resume is initiated from a kernel thread context.
155It is safe to block, allocate memory, initiate requests
156or anything else you can do within the kernel.
157
158Q: Will requests continue to arrive after a suspend?
159
160Possibly. It is the driver's responsibility to queue(*),
161fail, or drop any requests that arrive after returning
162success to a suspend request. It is important that the
163driver not access its device until after it receives
164a resume request as the device's bus may no longer
165be active.
166
167(*) If a driver queues requests for processing after
168 resume be aware that the device, network, etc.
169 might be in a different state than at suspend time.
170 It's probably better to drop requests unless
171 the driver is a storage device.
172
173Q: Do I have to manage bus-specific power management registers
174
175No. It is the responsibility of the bus driver to manage
176PCI, USB, etc. power management registers. The bus driver
177or the power management subsystem will also enable any
178wake-on functionality that the device has.
179
180Q: So, really, what do I need to do to support suspend/resume?
181
182You need to save any device context that would
183be lost if the device was powered off and then restore
184it at resume time. When ACPI is active, there are
185three levels of device suspend states; D1, D2, and D3.
186(The suspend state is passed as the "data" argument
187to the device callback.) With D3, the device is powered
188off and loses all context, D1 and D2 are shallower power
189states and require less device context to be saved. To
190play it safe, just save everything at suspend and restore
191everything at resume.
192
193Q: Where do I store device context for suspend?
194
195Anywhere in memory, kmalloc a buffer or store it
196in the device descriptor. You are guaranteed that the
197contents of memory will be restored and accessible
198before resume, even when the system suspends to disk.
199
200Q: What do I need to do for ACPI vs. APM vs. etc?
201
202Drivers need not be aware of the specific power management
203technology that is active. They just need to be aware
204of when the overlying power management system requests
205that they suspend or resume.
206
207Q: What about device dependencies?
208
209When a driver registers a device, the power management
210subsystem uses the information provided to build a
211tree of device dependencies (eg. USB device X is on
212USB controller Y which is on PCI bus Z) When power
213management wants to suspend a device, it first sends
214a suspend request to its driver, then the bus driver,
215and so on up to the system bus. Device resumes
216proceed in the opposite direction.
217
218Q: Who do I contact for additional information about
219 enabling power management for my specific driver/device?
220
221ACPI Development mailing list: linux-acpi@vger.kernel.org
222
223System Interface -- OBSOLETE, DO NOT USE!
224----------------*************************
225If you are providing new power management support to Linux (ie.
226adding support for something like APM or ACPI), you should
227communicate with drivers through the existing generic power
228management interface.
229
230/*
231 * Send a request to all devices
232 *
233 * Parameters:
234 * rqst - request type
235 * data - data, if any, associated with the request
236 *
237 * Returns: 0 if the request is successful
238 * See "pm_callback" return for errors
239 *
240 * Details: Walk list of registered devices and call pm_send
241 * for each until complete or an error is encountered.
242 * If an error is encountered for a suspend request,
243 * return all devices to the state they were in before
244 * the suspend request.
245 */
246int pm_send_all(pm_request_t rqst, void *data);
247
248/*
249 * Find a matching device
250 *
251 * Parameters:
252 * type - device type (PCI device, system device, or 0 to match all devices)
253 * from - previous match or NULL to start from the beginning
254 *
255 * Returns: Matching device or NULL if none found
256 */
257struct pm_dev *pm_find(pm_dev_t type, struct pm_dev *from);
diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/powerpc/booting-without-of.txt
index ee92fedada1a..99514ced82c5 100644
--- a/Documentation/powerpc/booting-without-of.txt
+++ b/Documentation/powerpc/booting-without-of.txt
@@ -90,10 +90,12 @@ Table of Contents
90 3) OpenPIC Interrupt Controllers 90 3) OpenPIC Interrupt Controllers
91 4) ISA Interrupt Controllers 91 4) ISA Interrupt Controllers
92 92
93 VIII - Specifying GPIO information for devices 93 IX - Specifying GPIO information for devices
94 1) gpios property 94 1) gpios property
95 2) gpio-controller nodes 95 2) gpio-controller nodes
96 96
97 X - Specifying device power management information (sleep property)
98
97 Appendix A - Sample SOC node for MPC8540 99 Appendix A - Sample SOC node for MPC8540
98 100
99 101
@@ -2545,8 +2547,8 @@ encodings listed below:
2545 2 = high to low edge sensitive type enabled 2547 2 = high to low edge sensitive type enabled
2546 3 = low to high edge sensitive type enabled 2548 3 = low to high edge sensitive type enabled
2547 2549
2548VIII - Specifying GPIO information for devices 2550IX - Specifying GPIO information for devices
2549============================================== 2551============================================
2550 2552
25511) gpios property 25531) gpios property
2552----------------- 2554-----------------
@@ -2594,116 +2596,151 @@ Example of two SOC GPIO banks defined as gpio-controller nodes:
2594 gpio-controller; 2596 gpio-controller;
2595 }; 2597 };
2596 2598
2599X - Specifying Device Power Management Information (sleep property)
2600===================================================================
2601
2602Devices on SOCs often have mechanisms for placing devices into low-power
2603states that are decoupled from the devices' own register blocks. Sometimes,
2604this information is more complicated than a cell-index property can
2605reasonably describe. Thus, each device controlled in such a manner
2606may contain a "sleep" property which describes these connections.
2607
2608The sleep property consists of one or more sleep resources, each of
2609which consists of a phandle to a sleep controller, followed by a
2610controller-specific sleep specifier of zero or more cells.
2611
2612The semantics of what type of low power modes are possible are defined
2613by the sleep controller. Some examples of the types of low power modes
2614that may be supported are:
2615
2616 - Dynamic: The device may be disabled or enabled at any time.
2617 - System Suspend: The device may request to be disabled or remain
2618 awake during system suspend, but will not be disabled until then.
2619 - Permanent: The device is disabled permanently (until the next hard
2620 reset).
2621
2622Some devices may share a clock domain with each other, such that they should
2623only be suspended when none of the devices are in use. Where reasonable,
2624such nodes should be placed on a virtual bus, where the bus has the sleep
2625property. If the clock domain is shared among devices that cannot be
2626reasonably grouped in this manner, then create a virtual sleep controller
2627(similar to an interrupt nexus, except that defining a standardized
2628sleep-map should wait until its necessity is demonstrated).
2629
2597Appendix A - Sample SOC node for MPC8540 2630Appendix A - Sample SOC node for MPC8540
2598======================================== 2631========================================
2599 2632
2600Note that the #address-cells and #size-cells for the SoC node 2633 soc@e0000000 {
2601in this example have been explicitly listed; these are likely
2602not necessary as they are usually the same as the root node.
2603
2604 soc8540@e0000000 {
2605 #address-cells = <1>; 2634 #address-cells = <1>;
2606 #size-cells = <1>; 2635 #size-cells = <1>;
2607 #interrupt-cells = <2>; 2636 compatible = "fsl,mpc8540-ccsr", "simple-bus";
2608 device_type = "soc"; 2637 device_type = "soc";
2609 ranges = <00000000 e0000000 00100000> 2638 ranges = <0x00000000 0xe0000000 0x00100000>
2610 reg = <e0000000 00003000>;
2611 bus-frequency = <0>; 2639 bus-frequency = <0>;
2612 2640 interrupt-parent = <&pic>;
2613 mdio@24520 {
2614 reg = <24520 20>;
2615 device_type = "mdio";
2616 compatible = "gianfar";
2617
2618 ethernet-phy@0 {
2619 linux,phandle = <2452000>
2620 interrupt-parent = <40000>;
2621 interrupts = <35 1>;
2622 reg = <0>;
2623 device_type = "ethernet-phy";
2624 };
2625
2626 ethernet-phy@1 {
2627 linux,phandle = <2452001>
2628 interrupt-parent = <40000>;
2629 interrupts = <35 1>;
2630 reg = <1>;
2631 device_type = "ethernet-phy";
2632 };
2633
2634 ethernet-phy@3 {
2635 linux,phandle = <2452002>
2636 interrupt-parent = <40000>;
2637 interrupts = <35 1>;
2638 reg = <3>;
2639 device_type = "ethernet-phy";
2640 };
2641
2642 };
2643 2641
2644 ethernet@24000 { 2642 ethernet@24000 {
2645 #size-cells = <0>; 2643 #address-cells = <1>;
2644 #size-cells = <1>;
2646 device_type = "network"; 2645 device_type = "network";
2647 model = "TSEC"; 2646 model = "TSEC";
2648 compatible = "gianfar"; 2647 compatible = "gianfar", "simple-bus";
2649 reg = <24000 1000>; 2648 reg = <0x24000 0x1000>;
2650 mac-address = [ 00 E0 0C 00 73 00 ]; 2649 local-mac-address = [ 00 E0 0C 00 73 00 ];
2651 interrupts = <d 3 e 3 12 3>; 2650 interrupts = <29 2 30 2 34 2>;
2652 interrupt-parent = <40000>; 2651 phy-handle = <&phy0>;
2653 phy-handle = <2452000>; 2652 sleep = <&pmc 00000080>;
2653 ranges;
2654
2655 mdio@24520 {
2656 reg = <0x24520 0x20>;
2657 compatible = "fsl,gianfar-mdio";
2658
2659 phy0: ethernet-phy@0 {
2660 interrupts = <5 1>;
2661 reg = <0>;
2662 device_type = "ethernet-phy";
2663 };
2664
2665 phy1: ethernet-phy@1 {
2666 interrupts = <5 1>;
2667 reg = <1>;
2668 device_type = "ethernet-phy";
2669 };
2670
2671 phy3: ethernet-phy@3 {
2672 interrupts = <7 1>;
2673 reg = <3>;
2674 device_type = "ethernet-phy";
2675 };
2676 };
2654 }; 2677 };
2655 2678
2656 ethernet@25000 { 2679 ethernet@25000 {
2657 #address-cells = <1>;
2658 #size-cells = <0>;
2659 device_type = "network"; 2680 device_type = "network";
2660 model = "TSEC"; 2681 model = "TSEC";
2661 compatible = "gianfar"; 2682 compatible = "gianfar";
2662 reg = <25000 1000>; 2683 reg = <0x25000 0x1000>;
2663 mac-address = [ 00 E0 0C 00 73 01 ]; 2684 local-mac-address = [ 00 E0 0C 00 73 01 ];
2664 interrupts = <13 3 14 3 18 3>; 2685 interrupts = <13 2 14 2 18 2>;
2665 interrupt-parent = <40000>; 2686 phy-handle = <&phy1>;
2666 phy-handle = <2452001>; 2687 sleep = <&pmc 00000040>;
2667 }; 2688 };
2668 2689
2669 ethernet@26000 { 2690 ethernet@26000 {
2670 #address-cells = <1>;
2671 #size-cells = <0>;
2672 device_type = "network"; 2691 device_type = "network";
2673 model = "FEC"; 2692 model = "FEC";
2674 compatible = "gianfar"; 2693 compatible = "gianfar";
2675 reg = <26000 1000>; 2694 reg = <0x26000 0x1000>;
2676 mac-address = [ 00 E0 0C 00 73 02 ]; 2695 local-mac-address = [ 00 E0 0C 00 73 02 ];
2677 interrupts = <19 3>; 2696 interrupts = <41 2>;
2678 interrupt-parent = <40000>; 2697 phy-handle = <&phy3>;
2679 phy-handle = <2452002>; 2698 sleep = <&pmc 00000020>;
2680 }; 2699 };
2681 2700
2682 serial@4500 { 2701 serial@4500 {
2683 device_type = "serial"; 2702 #address-cells = <1>;
2684 compatible = "ns16550"; 2703 #size-cells = <1>;
2685 reg = <4500 100>; 2704 compatible = "fsl,mpc8540-duart", "simple-bus";
2686 clock-frequency = <0>; 2705 sleep = <&pmc 00000002>;
2687 interrupts = <1a 3>; 2706 ranges;
2688 interrupt-parent = <40000>; 2707
2708 serial@4500 {
2709 device_type = "serial";
2710 compatible = "ns16550";
2711 reg = <0x4500 0x100>;
2712 clock-frequency = <0>;
2713 interrupts = <42 2>;
2714 };
2715
2716 serial@4600 {
2717 device_type = "serial";
2718 compatible = "ns16550";
2719 reg = <0x4600 0x100>;
2720 clock-frequency = <0>;
2721 interrupts = <42 2>;
2722 };
2689 }; 2723 };
2690 2724
2691 pic@40000 { 2725 pic: pic@40000 {
2692 linux,phandle = <40000>;
2693 interrupt-controller; 2726 interrupt-controller;
2694 #address-cells = <0>; 2727 #address-cells = <0>;
2695 reg = <40000 40000>; 2728 #interrupt-cells = <2>;
2729 reg = <0x40000 0x40000>;
2696 compatible = "chrp,open-pic"; 2730 compatible = "chrp,open-pic";
2697 device_type = "open-pic"; 2731 device_type = "open-pic";
2698 }; 2732 };
2699 2733
2700 i2c@3000 { 2734 i2c@3000 {
2701 interrupt-parent = <40000>; 2735 interrupts = <43 2>;
2702 interrupts = <1b 3>; 2736 reg = <0x3000 0x100>;
2703 reg = <3000 18>;
2704 device_type = "i2c";
2705 compatible = "fsl-i2c"; 2737 compatible = "fsl-i2c";
2706 dfsrr; 2738 dfsrr;
2739 sleep = <&pmc 00000004>;
2707 }; 2740 };
2708 2741
2742 pmc: power@e0070 {
2743 compatible = "fsl,mpc8540-pmc", "fsl,mpc8548-pmc";
2744 reg = <0xe0070 0x20>;
2745 };
2709 }; 2746 };
diff --git a/Documentation/powerpc/dts-bindings/fsl/cpm_qe/gpio.txt b/Documentation/powerpc/dts-bindings/fsl/cpm_qe/gpio.txt
new file mode 100644
index 000000000000..1815dfede1bc
--- /dev/null
+++ b/Documentation/powerpc/dts-bindings/fsl/cpm_qe/gpio.txt
@@ -0,0 +1,38 @@
1Every GPIO controller node must have #gpio-cells property defined,
2this information will be used to translate gpio-specifiers.
3
4On CPM1 devices, all ports are using slightly different register layouts.
5Ports A, C and D are 16bit ports and Ports B and E are 32bit ports.
6
7On CPM2 devices, all ports are 32bit ports and use a common register layout.
8
9Required properties:
10- compatible : "fsl,cpm1-pario-bank-a", "fsl,cpm1-pario-bank-b",
11 "fsl,cpm1-pario-bank-c", "fsl,cpm1-pario-bank-d",
12 "fsl,cpm1-pario-bank-e", "fsl,cpm2-pario-bank"
13- #gpio-cells : Should be two. The first cell is the pin number and the
14 second cell is used to specify optional paramters (currently unused).
15- gpio-controller : Marks the port as GPIO controller.
16
17Example of three SOC GPIO banks defined as gpio-controller nodes:
18
19 CPM1_PIO_A: gpio-controller@950 {
20 #gpio-cells = <2>;
21 compatible = "fsl,cpm1-pario-bank-a";
22 reg = <0x950 0x10>;
23 gpio-controller;
24 };
25
26 CPM1_PIO_B: gpio-controller@ab8 {
27 #gpio-cells = <2>;
28 compatible = "fsl,cpm1-pario-bank-b";
29 reg = <0xab8 0x10>;
30 gpio-controller;
31 };
32
33 CPM1_PIO_E: gpio-controller@ac8 {
34 #gpio-cells = <2>;
35 compatible = "fsl,cpm1-pario-bank-e";
36 reg = <0xac8 0x18>;
37 gpio-controller;
38 };
diff --git a/Documentation/powerpc/dts-bindings/fsl/cpm_qe/qe/usb.txt b/Documentation/powerpc/dts-bindings/fsl/cpm_qe/qe/usb.txt
index c8f44d6bcbcf..9ccd5f30405b 100644
--- a/Documentation/powerpc/dts-bindings/fsl/cpm_qe/qe/usb.txt
+++ b/Documentation/powerpc/dts-bindings/fsl/cpm_qe/qe/usb.txt
@@ -1,22 +1,37 @@
1* USB (Universal Serial Bus Controller) 1Freescale QUICC Engine USB Controller
2 2
3Required properties: 3Required properties:
4- compatible : could be "qe_udc" or "fhci-hcd". 4- compatible : should be "fsl,<chip>-qe-usb", "fsl,mpc8323-qe-usb".
5- mode : the could be "host" or "slave". 5- reg : the first two cells should contain usb registers location and
6- reg : Offset and length of the register set for the device 6 length, the next two two cells should contain PRAM location and
7- interrupts : <a b> where a is the interrupt number and b is a 7 length.
8 field that represents an encoding of the sense and level 8- interrupts : should contain USB interrupt.
9 information for the interrupt. This should be encoded based on 9- interrupt-parent : interrupt source phandle.
10 the information in section 2) depending on the type of interrupt 10- fsl,fullspeed-clock : specifies the full speed USB clock source:
11 controller you have. 11 "none": clock source is disabled
12- interrupt-parent : the phandle for the interrupt controller that 12 "brg1" through "brg16": clock source is BRG1-BRG16, respectively
13 services interrupts for this device. 13 "clk1" through "clk24": clock source is CLK1-CLK24, respectively
14- fsl,lowspeed-clock : specifies the low speed USB clock source:
15 "none": clock source is disabled
16 "brg1" through "brg16": clock source is BRG1-BRG16, respectively
17 "clk1" through "clk24": clock source is CLK1-CLK24, respectively
18- hub-power-budget : USB power budget for the root hub, in mA.
19- gpios : should specify GPIOs in this order: USBOE, USBTP, USBTN, USBRP,
20 USBRN, SPEED (optional), and POWER (optional).
14 21
15Example(slave): 22Example:
16 usb@6c0 { 23
17 compatible = "qe_udc"; 24usb@6c0 {
18 reg = <6c0 40>; 25 compatible = "fsl,mpc8360-qe-usb", "fsl,mpc8323-qe-usb";
19 interrupts = <8b 0>; 26 reg = <0x6c0 0x40 0x8b00 0x100>;
20 interrupt-parent = <700>; 27 interrupts = <11>;
21 mode = "slave"; 28 interrupt-parent = <&qeic>;
22 }; 29 fsl,fullspeed-clock = "clk21";
30 gpios = <&qe_pio_b 2 0 /* USBOE */
31 &qe_pio_b 3 0 /* USBTP */
32 &qe_pio_b 8 0 /* USBTN */
33 &qe_pio_b 9 0 /* USBRP */
34 &qe_pio_b 11 0 /* USBRN */
35 &qe_pio_e 20 0 /* SPEED */
36 &qe_pio_e 21 0 /* POWER */>;
37};
diff --git a/Documentation/powerpc/dts-bindings/fsl/mcu-mpc8349emitx.txt b/Documentation/powerpc/dts-bindings/fsl/mcu-mpc8349emitx.txt
new file mode 100644
index 000000000000..0f766333b6eb
--- /dev/null
+++ b/Documentation/powerpc/dts-bindings/fsl/mcu-mpc8349emitx.txt
@@ -0,0 +1,17 @@
1Freescale MPC8349E-mITX-compatible Power Management Micro Controller Unit (MCU)
2
3Required properties:
4- compatible : "fsl,<mcu-chip>-<board>", "fsl,mcu-mpc8349emitx".
5- reg : should specify I2C address (0x0a).
6- #gpio-cells : should be 2.
7- gpio-controller : should be present.
8
9Example:
10
11mcu@0a {
12 #gpio-cells = <2>;
13 compatible = "fsl,mc9s08qg8-mpc8349emitx",
14 "fsl,mcu-mpc8349emitx";
15 reg = <0x0a>;
16 gpio-controller;
17};
diff --git a/Documentation/powerpc/dts-bindings/fsl/pmc.txt b/Documentation/powerpc/dts-bindings/fsl/pmc.txt
new file mode 100644
index 000000000000..02f6f43ee1b7
--- /dev/null
+++ b/Documentation/powerpc/dts-bindings/fsl/pmc.txt
@@ -0,0 +1,63 @@
1* Power Management Controller
2
3Properties:
4- compatible: "fsl,<chip>-pmc".
5
6 "fsl,mpc8349-pmc" should be listed for any chip whose PMC is
7 compatible. "fsl,mpc8313-pmc" should also be listed for any chip
8 whose PMC is compatible, and implies deep-sleep capability.
9
10 "fsl,mpc8548-pmc" should be listed for any chip whose PMC is
11 compatible. "fsl,mpc8536-pmc" should also be listed for any chip
12 whose PMC is compatible, and implies deep-sleep capability.
13
14 "fsl,mpc8641d-pmc" should be listed for any chip whose PMC is
15 compatible; all statements below that apply to "fsl,mpc8548-pmc" also
16 apply to "fsl,mpc8641d-pmc".
17
18 Compatibility does not include bit assigments in SCCR/PMCDR/DEVDISR; these
19 bit assigments are indicated via the sleep specifier in each device's
20 sleep property.
21
22- reg: For devices compatible with "fsl,mpc8349-pmc", the first resource
23 is the PMC block, and the second resource is the Clock Configuration
24 block.
25
26 For devices compatible with "fsl,mpc8548-pmc", the first resource
27 is a 32-byte block beginning with DEVDISR.
28
29- interrupts: For "fsl,mpc8349-pmc"-compatible devices, the first
30 resource is the PMC block interrupt.
31
32- fsl,mpc8313-wakeup-timer: For "fsl,mpc8313-pmc"-compatible devices,
33 this is a phandle to an "fsl,gtm" node on which timer 4 can be used as
34 a wakeup source from deep sleep.
35
36Sleep specifiers:
37
38 fsl,mpc8349-pmc: Sleep specifiers consist of one cell. For each bit
39 that is set in the cell, the corresponding bit in SCCR will be saved
40 and cleared on suspend, and restored on resume. This sleep controller
41 supports disabling and resuming devices at any time.
42
43 fsl,mpc8536-pmc: Sleep specifiers consist of three cells, the third of
44 which will be ORed into PMCDR upon suspend, and cleared from PMCDR
45 upon resume. The first two cells are as described for fsl,mpc8578-pmc.
46 This sleep controller only supports disabling devices during system
47 sleep, or permanently.
48
49 fsl,mpc8548-pmc: Sleep specifiers consist of one or two cells, the
50 first of which will be ORed into DEVDISR (and the second into
51 DEVDISR2, if present -- this cell should be zero or absent if the
52 hardware does not have DEVDISR2) upon a request for permanent device
53 disabling. This sleep controller does not support configuring devices
54 to disable during system sleep (unless supported by another compatible
55 match), or dynamically.
56
57Example:
58
59 power@b00 {
60 compatible = "fsl,mpc8313-pmc", "fsl,mpc8349-pmc";
61 reg = <0xb00 0x100 0xa00 0x100>;
62 interrupts = <80 8>;
63 };
diff --git a/Documentation/powerpc/dts-bindings/fsl/tsec.txt b/Documentation/powerpc/dts-bindings/fsl/tsec.txt
index 583ef6b56c43..cf55fa4112d2 100644
--- a/Documentation/powerpc/dts-bindings/fsl/tsec.txt
+++ b/Documentation/powerpc/dts-bindings/fsl/tsec.txt
@@ -24,46 +24,39 @@ Example:
24 24
25* Gianfar-compatible ethernet nodes 25* Gianfar-compatible ethernet nodes
26 26
27Required properties: 27Properties:
28 28
29 - device_type : Should be "network" 29 - device_type : Should be "network"
30 - model : Model of the device. Can be "TSEC", "eTSEC", or "FEC" 30 - model : Model of the device. Can be "TSEC", "eTSEC", or "FEC"
31 - compatible : Should be "gianfar" 31 - compatible : Should be "gianfar"
32 - reg : Offset and length of the register set for the device 32 - reg : Offset and length of the register set for the device
33 - mac-address : List of bytes representing the ethernet address of 33 - local-mac-address : List of bytes representing the ethernet address of
34 this controller 34 this controller
35 - interrupts : <a b> where a is the interrupt number and b is a 35 - interrupts : For FEC devices, the first interrupt is the device's
36 field that represents an encoding of the sense and level 36 interrupt. For TSEC and eTSEC devices, the first interrupt is
37 information for the interrupt. This should be encoded based on 37 transmit, the second is receive, and the third is error.
38 the information in section 2) depending on the type of interrupt
39 controller you have.
40 - interrupt-parent : the phandle for the interrupt controller that
41 services interrupts for this device.
42 - phy-handle : The phandle for the PHY connected to this ethernet 38 - phy-handle : The phandle for the PHY connected to this ethernet
43 controller. 39 controller.
44 - fixed-link : <a b c d e> where a is emulated phy id - choose any, 40 - fixed-link : <a b c d e> where a is emulated phy id - choose any,
45 but unique to the all specified fixed-links, b is duplex - 0 half, 41 but unique to the all specified fixed-links, b is duplex - 0 half,
46 1 full, c is link speed - d#10/d#100/d#1000, d is pause - 0 no 42 1 full, c is link speed - d#10/d#100/d#1000, d is pause - 0 no
47 pause, 1 pause, e is asym_pause - 0 no asym_pause, 1 asym_pause. 43 pause, 1 pause, e is asym_pause - 0 no asym_pause, 1 asym_pause.
48
49Recommended properties:
50
51 - phy-connection-type : a string naming the controller/PHY interface type, 44 - phy-connection-type : a string naming the controller/PHY interface type,
52 i.e., "mii" (default), "rmii", "gmii", "rgmii", "rgmii-id", "sgmii", 45 i.e., "mii" (default), "rmii", "gmii", "rgmii", "rgmii-id", "sgmii",
53 "tbi", or "rtbi". This property is only really needed if the connection 46 "tbi", or "rtbi". This property is only really needed if the connection
54 is of type "rgmii-id", as all other connection types are detected by 47 is of type "rgmii-id", as all other connection types are detected by
55 hardware. 48 hardware.
56 49 - fsl,magic-packet : If present, indicates that the hardware supports
50 waking up via magic packet.
57 51
58Example: 52Example:
59 ethernet@24000 { 53 ethernet@24000 {
60 #size-cells = <0>;
61 device_type = "network"; 54 device_type = "network";
62 model = "TSEC"; 55 model = "TSEC";
63 compatible = "gianfar"; 56 compatible = "gianfar";
64 reg = <24000 1000>; 57 reg = <0x24000 0x1000>;
65 mac-address = [ 00 E0 0C 00 73 00 ]; 58 local-mac-address = [ 00 E0 0C 00 73 00 ];
66 interrupts = <d 3 e 3 12 3>; 59 interrupts = <29 2 30 2 34 2>;
67 interrupt-parent = <40000>; 60 interrupt-parent = <&mpic>;
68 phy-handle = <2452000> 61 phy-handle = <&phy0>
69 }; 62 };
diff --git a/Documentation/powerpc/dts-bindings/fsl/upm-nand.txt b/Documentation/powerpc/dts-bindings/fsl/upm-nand.txt
new file mode 100644
index 000000000000..84a04d5eb8e6
--- /dev/null
+++ b/Documentation/powerpc/dts-bindings/fsl/upm-nand.txt
@@ -0,0 +1,28 @@
1Freescale Localbus UPM programmed to work with NAND flash
2
3Required properties:
4- compatible : "fsl,upm-nand".
5- reg : should specify localbus chip select and size used for the chip.
6- fsl,upm-addr-offset : UPM pattern offset for the address latch.
7- fsl,upm-cmd-offset : UPM pattern offset for the command latch.
8- gpios : may specify optional GPIO connected to the Ready-Not-Busy pin.
9
10Example:
11
12upm@1,0 {
13 compatible = "fsl,upm-nand";
14 reg = <1 0 1>;
15 fsl,upm-addr-offset = <16>;
16 fsl,upm-cmd-offset = <8>;
17 gpios = <&qe_pio_e 18 0>;
18
19 flash {
20 #address-cells = <1>;
21 #size-cells = <1>;
22 compatible = "...";
23
24 partition@0 {
25 ...
26 };
27 };
28};
diff --git a/Documentation/powerpc/dts-bindings/gpio/led.txt b/Documentation/powerpc/dts-bindings/gpio/led.txt
new file mode 100644
index 000000000000..ff51f4c0fa9d
--- /dev/null
+++ b/Documentation/powerpc/dts-bindings/gpio/led.txt
@@ -0,0 +1,15 @@
1LED connected to GPIO
2
3Required properties:
4- compatible : should be "gpio-led".
5- label : (optional) the label for this LED. If omitted, the label is
6 taken from the node name (excluding the unit address).
7- gpios : should specify LED GPIO.
8
9Example:
10
11led@0 {
12 compatible = "gpio-led";
13 label = "hdd";
14 gpios = <&mcu_pio 0 1>;
15};
diff --git a/Documentation/sound/alsa/DocBook/alsa-driver-api.tmpl b/Documentation/sound/alsa/DocBook/alsa-driver-api.tmpl
index c4d2e3507af9..9d644f7e241e 100644
--- a/Documentation/sound/alsa/DocBook/alsa-driver-api.tmpl
+++ b/Documentation/sound/alsa/DocBook/alsa-driver-api.tmpl
@@ -42,7 +42,7 @@
42 <sect1><title>Device Components</title> 42 <sect1><title>Device Components</title>
43!Esound/core/device.c 43!Esound/core/device.c
44 </sect1> 44 </sect1>
45 <sect1><title>KMOD and Device File Entries</title> 45 <sect1><title>Module requests and Device File Entries</title>
46!Esound/core/sound.c 46!Esound/core/sound.c
47 </sect1> 47 </sect1>
48 <sect1><title>Memory Management Helpers</title> 48 <sect1><title>Memory Management Helpers</title>
diff --git a/Documentation/specialix.txt b/Documentation/specialix.txt
index 4a4b428ce8f6..6eb6f3a3331c 100644
--- a/Documentation/specialix.txt
+++ b/Documentation/specialix.txt
@@ -270,8 +270,8 @@ The pinout of the connectors on the IO8+ is:
270Hardware handshaking issues. 270Hardware handshaking issues.
271============================ 271============================
272 272
273The driver can be compiled in two different ways. The default 273The driver can be told to operate in two different ways. The default
274("Specialix DTR/RTS pin is RTS" is off) the pin behaves as DTR when 274behaviour is specialix.sx_rtscts = 0 where the pin behaves as DTR when
275hardware handshaking is off. It behaves as the RTS hardware 275hardware handshaking is off. It behaves as the RTS hardware
276handshaking signal when hardware handshaking is selected. 276handshaking signal when hardware handshaking is selected.
277 277
@@ -280,7 +280,7 @@ cable will either be compatible with hardware handshaking or with
280software handshaking. So switching on the fly is not really an 280software handshaking. So switching on the fly is not really an
281option. 281option.
282 282
283I actually prefer to use the "Specialix DTR/RTS pin is RTS" option. 283I actually prefer to use the "specialix.sx_rtscts=1" option.
284This makes the DTR/RTS pin always an RTS pin, and ioctls to 284This makes the DTR/RTS pin always an RTS pin, and ioctls to
285change DTR are always ignored. I have a cable that is configured 285change DTR are always ignored. I have a cable that is configured
286for this. 286for this.
@@ -379,7 +379,5 @@ it doesn't fit in your computer, bring back the card.
379 You have to WRITE to the address register to even 379 You have to WRITE to the address register to even
380 read-probe a CD186x register. Disable autodetection? 380 read-probe a CD186x register. Disable autodetection?
381 -- Specialix: any suggestions? 381 -- Specialix: any suggestions?
382 - Arbitrary baud rates are not implemented yet.
383 If you need this, bug me about it.
384 382
385 383
diff --git a/Documentation/sysfs-rules.txt b/Documentation/sysfs-rules.txt
index 80ef562160bb..6049a2a84dda 100644
--- a/Documentation/sysfs-rules.txt
+++ b/Documentation/sysfs-rules.txt
@@ -3,9 +3,8 @@ Rules on how to access information in the Linux kernel sysfs
3The kernel-exported sysfs exports internal kernel implementation details 3The kernel-exported sysfs exports internal kernel implementation details
4and depends on internal kernel structures and layout. It is agreed upon 4and depends on internal kernel structures and layout. It is agreed upon
5by the kernel developers that the Linux kernel does not provide a stable 5by the kernel developers that the Linux kernel does not provide a stable
6internal API. As sysfs is a direct export of kernel internal 6internal API. Therefore, there are aspects of the sysfs interface that
7structures, the sysfs interface cannot provide a stable interface either; 7may not be stable across kernel releases.
8it may always change along with internal kernel changes.
9 8
10To minimize the risk of breaking users of sysfs, which are in most cases 9To minimize the risk of breaking users of sysfs, which are in most cases
11low-level userspace applications, with a new kernel release, the users 10low-level userspace applications, with a new kernel release, the users
diff --git a/Documentation/telephony/ixj.txt b/Documentation/telephony/ixj.txt
index 621024fd3a18..44d124005bad 100644
--- a/Documentation/telephony/ixj.txt
+++ b/Documentation/telephony/ixj.txt
@@ -305,21 +305,14 @@ driver, like this:
305 305
306which will result in the needed drivers getting loaded automatically. 306which will result in the needed drivers getting loaded automatically.
307 307
308 g. if you are planning on using kerneld to automatically load the 308 g. if you are planning on having the kernel automatically request
309module for you, then you need to edit /etc/conf.modules and add the 309the module for you, then you need to edit /etc/conf.modules and add the
310following lines: 310following lines:
311 311
312 options ixj dspio=0x340 xio=0x330 ixjdebug=0 312 options ixj dspio=0x340 xio=0x330 ixjdebug=0
313 313
314If you do this, then when you execute an application that uses the 314If you do this, then when you execute an application that uses the
315module kerneld will load the module for you. Note that to do this, 315module the kernel will request that it is loaded.
316you need to have your kernel set to support kerneld. You can check
317for this by looking at /usr/src/linux/.config and you should see this:
318
319 # Loadable module support
320 #
321 <snip>
322 CONFIG_KMOD=y
323 316
324 h. if you want non-root users to be able to read and write to the 317 h. if you want non-root users to be able to read and write to the
325ixj devices (this is a good idea!) you should do the following: 318ixj devices (this is a good idea!) you should do the following:
diff --git a/Documentation/usb/gadget_serial.txt b/Documentation/usb/gadget_serial.txt
index 815f5c2301ff..9b22bd14c348 100644
--- a/Documentation/usb/gadget_serial.txt
+++ b/Documentation/usb/gadget_serial.txt
@@ -1,6 +1,7 @@
1 1
2 Linux Gadget Serial Driver v2.0 2 Linux Gadget Serial Driver v2.0
3 11/20/2004 3 11/20/2004
4 (updated 8-May-2008 for v2.3)
4 5
5 6
6License and Disclaimer 7License and Disclaimer
@@ -31,7 +32,7 @@ Prerequisites
31------------- 32-------------
32Versions of the gadget serial driver are available for the 33Versions of the gadget serial driver are available for the
332.4 Linux kernels, but this document assumes you are using 342.4 Linux kernels, but this document assumes you are using
34version 2.0 or later of the gadget serial driver in a 2.6 35version 2.3 or later of the gadget serial driver in a 2.6
35Linux kernel. 36Linux kernel.
36 37
37This document assumes that you are familiar with Linux and 38This document assumes that you are familiar with Linux and
@@ -40,6 +41,12 @@ standard utilities, use minicom and HyperTerminal, and work with
40USB and serial devices. It also assumes you configure the Linux 41USB and serial devices. It also assumes you configure the Linux
41gadget and usb drivers as modules. 42gadget and usb drivers as modules.
42 43
44With version 2.3 of the driver, major and minor device nodes are
45no longer statically defined. Your Linux based system should mount
46sysfs in /sys, and use "mdev" (in Busybox) or "udev" to make the
47/dev nodes matching the sysfs /sys/class/tty files.
48
49
43 50
44Overview 51Overview
45-------- 52--------
@@ -104,15 +111,8 @@ driver. All this are listed under "USB Gadget Support" when
104configuring the kernel. Then rebuild and install the kernel or 111configuring the kernel. Then rebuild and install the kernel or
105modules. 112modules.
106 113
107The gadget serial driver uses major number 127, for now. So you
108will need to create a device node for it, like this:
109
110 mknod /dev/ttygserial c 127 0
111
112You only need to do this once.
113
114Then you must load the gadget serial driver. To load it as an 114Then you must load the gadget serial driver. To load it as an
115ACM device, do this: 115ACM device (recommended for interoperability), do this:
116 116
117 modprobe g_serial use_acm=1 117 modprobe g_serial use_acm=1
118 118
@@ -125,6 +125,23 @@ controller driver. This must be done each time you reboot the gadget
125side Linux system. You can add this to the start up scripts, if 125side Linux system. You can add this to the start up scripts, if
126desired. 126desired.
127 127
128Your system should use mdev (from busybox) or udev to make the
129device nodes. After this gadget driver has been set up you should
130then see a /dev/ttyGS0 node:
131
132 # ls -l /dev/ttyGS0 | cat
133 crw-rw---- 1 root root 253, 0 May 8 14:10 /dev/ttyGS0
134 #
135
136Note that the major number (253, above) is system-specific. If
137you need to create /dev nodes by hand, the right numbers to use
138will be in the /sys/class/tty/ttyGS0/dev file.
139
140When you link this gadget driver early, perhaps even statically,
141you may want to set up an /etc/inittab entry to run "getty" on it.
142The /dev/ttyGS0 line should work like most any other serial port.
143
144
128If gadget serial is loaded as an ACM device you will want to use 145If gadget serial is loaded as an ACM device you will want to use
129either the Windows or Linux ACM driver on the host side. If gadget 146either the Windows or Linux ACM driver on the host side. If gadget
130serial is loaded as a bulk in/out device, you will want to use the 147serial is loaded as a bulk in/out device, you will want to use the
diff --git a/Documentation/usb/persist.txt b/Documentation/usb/persist.txt
index d56cb1a11550..074b159b77c2 100644
--- a/Documentation/usb/persist.txt
+++ b/Documentation/usb/persist.txt
@@ -81,8 +81,11 @@ re-enumeration shows that the device now attached to that port has the
81same descriptors as before, including the Vendor and Product IDs, then 81same descriptors as before, including the Vendor and Product IDs, then
82the kernel continues to use the same device structure. In effect, the 82the kernel continues to use the same device structure. In effect, the
83kernel treats the device as though it had merely been reset instead of 83kernel treats the device as though it had merely been reset instead of
84unplugged. The same thing happens if the host controller is in the 84unplugged.
85expected state but a USB device was unplugged and then replugged. 85
86The same thing happens if the host controller is in the expected state
87but a USB device was unplugged and then replugged, or if a USB device
88fails to carry out a normal resume.
86 89
87If no device is now attached to the port, or if the descriptors are 90If no device is now attached to the port, or if the descriptors are
88different from what the kernel remembers, then the treatment is what 91different from what the kernel remembers, then the treatment is what
diff --git a/Documentation/usb/uhci.txt b/Documentation/usb/uhci.txt
deleted file mode 100644
index 2f25952c86c6..000000000000
--- a/Documentation/usb/uhci.txt
+++ /dev/null
@@ -1,165 +0,0 @@
1Specification and Internals for the New UHCI Driver (Whitepaper...)
2
3 brought to you by
4
5 Georg Acher, acher@in.tum.de (executive slave) (base guitar)
6 Deti Fliegl, deti@fliegl.de (executive slave) (lead voice)
7 Thomas Sailer, sailer@ife.ee.ethz.ch (chief consultant) (cheer leader)
8
9 $Id: README.uhci,v 1.1 1999/12/14 14:03:02 fliegl Exp $
10
11This document and the new uhci sources can be found on
12 http://hotswap.in.tum.de/usb
13
141. General issues
15
161.1 Why a new UHCI driver, we already have one?!?
17
18Correct, but its internal structure got more and more mixed up by the (still
19ongoing) efforts to get isochronous transfers (ISO) to work.
20Since there is an increasing need for reliable ISO-transfers (especially
21for USB-audio needed by TS and for a DAB-USB-Receiver build by GA and DF),
22this state was a bit unsatisfying in our opinion, so we've decided (based
23on knowledge and experiences with the old UHCI driver) to start
24from scratch with a new approach, much simpler but at the same time more
25powerful.
26It is inspired by the way Win98/Win2000 handles USB requests via URBs,
27but it's definitely 100% free of MS-code and doesn't crash while
28unplugging an used ISO-device like Win98 ;-)
29Some code for HW setup and root hub management was taken from the
30original UHCI driver, but heavily modified to fit into the new code.
31The invention of the basic concept, and major coding were completed in two
32days (and nights) on the 16th and 17th of October 1999, now known as the
33great USB-October-Revolution started by GA, DF, and TS ;-)
34
35Since the concept is in no way UHCI dependent, we hope that it will also be
36transferred to the OHCI-driver, so both drivers share a common API.
37
381.2. Advantages and disadvantages
39
40+ All USB transfer types work now!
41+ Asynchronous operation
42+ Simple, but powerful interface (only two calls for start and cancel)
43+ Easy migration to the new API, simplified by a compatibility API
44+ Simple usage of ISO transfers
45+ Automatic linking of requests
46+ ISO transfers allow variable length for each frame and striping
47+ No CPU dependent and non-portable atomic memory access, no asm()-inlines
48+ Tested on x86 and Alpha
49
50- Rewriting for ISO transfers needed
51
521.3. Is there some compatibility to the old API?
53
54Yes, but only for control, bulk and interrupt transfers. We've implemented
55some wrapper calls for these transfer types. The usbcore works fine with
56these wrappers. For ISO there's no compatibility, because the old ISO-API
57and its semantics were unnecessary complicated in our opinion.
58
591.4. What's really working?
60
61As said above, CTRL and BULK already work fine even with the wrappers,
62so legacy code wouldn't notice the change.
63Regarding to Thomas, ISO transfers now run stable with USB audio.
64INT transfers (e.g. mouse driver) work fine, too.
65
661.5. Are there any bugs?
67
68No ;-)
69Hm...
70Well, of course this implementation needs extensive testing on all available
71hardware, but we believe that any fixes shouldn't harm the overall concept.
72
731.6. What should be done next?
74
75A large part of the request handling seems to be identical for UHCI and
76OHCI, so it would be a good idea to extract the common parts and have only
77the HW specific stuff in uhci.c. Furthermore, all other USB device drivers
78should need URBification, if they use isochronous or interrupt transfers.
79One thing missing in the current implementation (and the old UHCI driver)
80is fair queueing for BULK transfers. Since this would need (in principle)
81the alteration of already constructed TD chains (to switch from depth to
82breadth execution), another way has to be found. Maybe some simple
83heuristics work with the same effect.
84
85---------------------------------------------------------------------------
86
872. Internal structure and mechanisms
88
89To get quickly familiar with the internal structures, here's a short
90description how the new UHCI driver works. However, the ultimate source of
91truth is only uhci.c!
92
932.1. Descriptor structure (QHs and TDs)
94
95During initialization, the following skeleton is allocated in init_skel:
96
97 framespecific | common chain
98
99framelist[]
100[ 0 ]-----> TD --> TD -------\
101[ 1 ]-----> TD --> TD --------> TD ----> QH -------> QH -------> QH ---> NULL
102 ... TD --> TD -------/
103[1023]-----> TD --> TD ------/
104
105 ^^ ^^ ^^ ^^ ^^ ^^
106 1024 TDs for 7 TDs for 1 TD for Start of Start of End Chain
107 ISO INT (2-128ms) 1ms-INT CTRL Chain BULK Chain
108
109For each CTRL or BULK transfer a new QH is allocated and the containing data
110transfers are appended as (vertical) TDs. After building the whole QH with its
111dangling TDs, the QH is inserted before the BULK Chain QH (for CTRL) or
112before the End Chain QH (for BULK). Since only the QH->next pointers are
113affected, no atomic memory operation is required. The three QHs in the
114common chain are never equipped with TDs!
115
116For ISO or INT, the TD for each frame is simply inserted into the appropriate
117ISO/INT-TD-chain for the desired frame. The 7 skeleton INT-TDs are scattered
118among the 1024 frames similar to the old UHCI driver.
119
120For CTRL/BULK/ISO, the last TD in the transfer has the IOC-bit set. For INT,
121every TD (there is only one...) has the IOC-bit set.
122
123Besides the data for the UHCI controller (2 or 4 32bit words), the descriptors
124are double-linked through the .vertical and .horizontal elements in the
125SW data of the descriptor (using the double-linked list structures and
126operations), but SW-linking occurs only in closed domains, i.e. for each of
127the 1024 ISO-chains and the 8 INT-chains there is a closed cycle. This
128simplifies all insertions and unlinking operations and avoids costly
129bus_to_virt()-calls.
130
1312.2. URB structure and linking to QH/TDs
132
133During assembly of the QH and TDs of the requested action, these descriptors
134are stored in urb->urb_list, so the allocated QH/TD descriptors are bound to
135this URB.
136If the assembly was successful and the descriptors were added to the HW chain,
137the corresponding URB is inserted into a global URB list for this controller.
138This list stores all pending URBs.
139
1402.3. Interrupt processing
141
142Since UHCI provides no means to directly detect completed transactions, the
143following is done in each UHCI interrupt (uhci_interrupt()):
144
145For each URB in the pending queue (process_urb()), the ACTIVE-flag of the
146associated TDs are processed (depending on the transfer type
147process_{transfer|interrupt|iso}()). If the TDs are not active anymore,
148they indicate the completion of the transaction and the status is calculated.
149Inactive QH/TDs are removed from the HW chain (since the host controller
150already removed the TDs from the QH, no atomic access is needed) and
151eventually the URB is marked as completed (OK or errors) and removed from the
152pending queue. Then the next linked URB is submitted. After (or immediately
153before) that, the completion handler is called.
154
1552.4. Unlinking URBs
156
157First, all QH/TDs stored in the URB are unlinked from the HW chain.
158To ensure that the host controller really left a vertical TD chain, we
159wait for one frame. After that, the TDs are physically destroyed.
160
1612.5. URB linking and the consequences
162
163Since URBs can be linked and the corresponding submit_urb is called in
164the UHCI-interrupt, all work associated with URB/QH/TD assembly has to be
165interrupt save. This forces kmalloc to use GFP_ATOMIC in the interrupt.
diff --git a/Documentation/video4linux/w9968cf.txt b/Documentation/video4linux/w9968cf.txt
index e0bba8393c77..05138e8aea07 100644
--- a/Documentation/video4linux/w9968cf.txt
+++ b/Documentation/video4linux/w9968cf.txt
@@ -193,9 +193,6 @@ Description: Automatic 'ovcamchip' module loading: 0 disabled, 1 enabled.
193 loads that module automatically. This action is performed as 193 loads that module automatically. This action is performed as
194 once soon as the 'w9968cf' module is loaded into memory. 194 once soon as the 'w9968cf' module is loaded into memory.
195Default: 1 195Default: 1
196Note: The kernel must be compiled with the CONFIG_KMOD option
197 enabled for the 'ovcamchip' module to be loaded and for
198 this parameter to be present.
199------------------------------------------------------------------------------- 196-------------------------------------------------------------------------------
200Name: simcams 197Name: simcams
201Type: int 198Type: int
diff --git a/Documentation/vm/hugetlbpage.txt b/Documentation/vm/hugetlbpage.txt
index 3102b81bef88..8a5b5763f0fe 100644
--- a/Documentation/vm/hugetlbpage.txt
+++ b/Documentation/vm/hugetlbpage.txt
@@ -95,6 +95,29 @@ this condition holds, however, no more surplus huge pages will be
95allowed on the system until one of the two sysctls are increased 95allowed on the system until one of the two sysctls are increased
96sufficiently, or the surplus huge pages go out of use and are freed. 96sufficiently, or the surplus huge pages go out of use and are freed.
97 97
98With support for multiple hugepage pools at run-time available, much of
99the hugepage userspace interface has been duplicated in sysfs. The above
100information applies to the default hugepage size (which will be
101controlled by the proc interfaces for backwards compatibility). The root
102hugepage control directory is
103
104 /sys/kernel/mm/hugepages
105
106For each hugepage size supported by the running kernel, a subdirectory
107will exist, of the form
108
109 hugepages-${size}kB
110
111Inside each of these directories, the same set of files will exist:
112
113 nr_hugepages
114 nr_overcommit_hugepages
115 free_hugepages
116 resv_hugepages
117 surplus_hugepages
118
119which function as described above for the default hugepage-sized case.
120
98If the user applications are going to request hugepages using mmap system 121If the user applications are going to request hugepages using mmap system
99call, then it is required that system administrator mount a file system of 122call, then it is required that system administrator mount a file system of
100type hugetlbfs: 123type hugetlbfs:
generated by cgit v1.2.2 (git 2.25.0) at 2024-11-17 17:13:47 -0500