Merge commit 'v2.6.27-rc1' into for-linus
This commit is contained in:
commit
e4ddcb0a6b
4010 changed files with 172705 additions and 98061 deletions
11
CREDITS
11
CREDITS
|
@ -317,6 +317,14 @@ S: 2322 37th Ave SW
|
||||||
S: Seattle, Washington 98126-2010
|
S: Seattle, Washington 98126-2010
|
||||||
S: USA
|
S: USA
|
||||||
|
|
||||||
|
N: Muli Ben-Yehuda
|
||||||
|
E: mulix@mulix.org
|
||||||
|
E: muli@il.ibm.com
|
||||||
|
W: http://www.mulix.org
|
||||||
|
D: trident OSS sound driver, x86-64 dma-ops and Calgary IOMMU,
|
||||||
|
D: KVM and Xen bits and other misc. hackery.
|
||||||
|
S: Haifa, Israel
|
||||||
|
|
||||||
N: Johannes Berg
|
N: Johannes Berg
|
||||||
E: johannes@sipsolutions.net
|
E: johannes@sipsolutions.net
|
||||||
W: http://johannes.sipsolutions.net/
|
W: http://johannes.sipsolutions.net/
|
||||||
|
@ -3344,8 +3352,7 @@ S: Spain
|
||||||
N: Linus Torvalds
|
N: Linus Torvalds
|
||||||
E: torvalds@linux-foundation.org
|
E: torvalds@linux-foundation.org
|
||||||
D: Original kernel hacker
|
D: Original kernel hacker
|
||||||
S: 12725 SW Millikan Way, Suite 400
|
S: Portland, Oregon 97005
|
||||||
S: Beaverton, Oregon 97005
|
|
||||||
S: USA
|
S: USA
|
||||||
|
|
||||||
N: Marcelo Tosatti
|
N: Marcelo Tosatti
|
||||||
|
|
|
@ -361,8 +361,6 @@ telephony/
|
||||||
- directory with info on telephony (e.g. voice over IP) support.
|
- directory with info on telephony (e.g. voice over IP) support.
|
||||||
time_interpolators.txt
|
time_interpolators.txt
|
||||||
- info on time interpolators.
|
- info on time interpolators.
|
||||||
tipar.txt
|
|
||||||
- information about Parallel link cable for Texas Instruments handhelds.
|
|
||||||
tty.txt
|
tty.txt
|
||||||
- guide to the locking policies of the tty layer.
|
- guide to the locking policies of the tty layer.
|
||||||
uml/
|
uml/
|
||||||
|
|
20
Documentation/ABI/testing/sysfs-dev
Normal file
20
Documentation/ABI/testing/sysfs-dev
Normal file
|
@ -0,0 +1,20 @@
|
||||||
|
What: /sys/dev
|
||||||
|
Date: April 2008
|
||||||
|
KernelVersion: 2.6.26
|
||||||
|
Contact: Dan Williams <dan.j.williams@intel.com>
|
||||||
|
Description: The /sys/dev tree provides a method to look up the sysfs
|
||||||
|
path for a device using the information returned from
|
||||||
|
stat(2). There are two directories, 'block' and 'char',
|
||||||
|
beneath /sys/dev containing symbolic links with names of
|
||||||
|
the form "<major>:<minor>". These links point to the
|
||||||
|
corresponding sysfs path for the given device.
|
||||||
|
|
||||||
|
Example:
|
||||||
|
$ readlink /sys/dev/block/8:32
|
||||||
|
../../block/sdc
|
||||||
|
|
||||||
|
Entries in /sys/dev/char and /sys/dev/block will be
|
||||||
|
dynamically created and destroyed as devices enter and
|
||||||
|
leave the system.
|
||||||
|
|
||||||
|
Users: mdadm <linux-raid@vger.kernel.org>
|
24
Documentation/ABI/testing/sysfs-devices-memory
Normal file
24
Documentation/ABI/testing/sysfs-devices-memory
Normal file
|
@ -0,0 +1,24 @@
|
||||||
|
What: /sys/devices/system/memory
|
||||||
|
Date: June 2008
|
||||||
|
Contact: Badari Pulavarty <pbadari@us.ibm.com>
|
||||||
|
Description:
|
||||||
|
The /sys/devices/system/memory contains a snapshot of the
|
||||||
|
internal state of the kernel memory blocks. Files could be
|
||||||
|
added or removed dynamically to represent hot-add/remove
|
||||||
|
operations.
|
||||||
|
|
||||||
|
Users: hotplug memory add/remove tools
|
||||||
|
https://w3.opensource.ibm.com/projects/powerpc-utils/
|
||||||
|
|
||||||
|
What: /sys/devices/system/memory/memoryX/removable
|
||||||
|
Date: June 2008
|
||||||
|
Contact: Badari Pulavarty <pbadari@us.ibm.com>
|
||||||
|
Description:
|
||||||
|
The file /sys/devices/system/memory/memoryX/removable
|
||||||
|
indicates whether this memory block is removable or not.
|
||||||
|
This is useful for a user-level agent to determine
|
||||||
|
identify removable sections of the memory before attempting
|
||||||
|
potentially expensive hot-remove memory operation
|
||||||
|
|
||||||
|
Users: hotplug memory remove tools
|
||||||
|
https://w3.opensource.ibm.com/projects/powerpc-utils/
|
6
Documentation/ABI/testing/sysfs-kernel-mm
Normal file
6
Documentation/ABI/testing/sysfs-kernel-mm
Normal file
|
@ -0,0 +1,6 @@
|
||||||
|
What: /sys/kernel/mm
|
||||||
|
Date: July 2008
|
||||||
|
Contact: Nishanth Aravamudan <nacc@us.ibm.com>, VM maintainers
|
||||||
|
Description:
|
||||||
|
/sys/kernel/mm/ should contain any and all VM
|
||||||
|
related information in /sys/kernel/.
|
15
Documentation/ABI/testing/sysfs-kernel-mm-hugepages
Normal file
15
Documentation/ABI/testing/sysfs-kernel-mm-hugepages
Normal file
|
@ -0,0 +1,15 @@
|
||||||
|
What: /sys/kernel/mm/hugepages/
|
||||||
|
Date: June 2008
|
||||||
|
Contact: Nishanth Aravamudan <nacc@us.ibm.com>, hugetlb maintainers
|
||||||
|
Description:
|
||||||
|
/sys/kernel/mm/hugepages/ contains a number of subdirectories
|
||||||
|
of the form hugepages-<size>kB, where <size> is the page size
|
||||||
|
of the hugepages supported by the kernel/CPU combination.
|
||||||
|
|
||||||
|
Under these directories are a number of files:
|
||||||
|
nr_hugepages
|
||||||
|
nr_overcommit_hugepages
|
||||||
|
free_hugepages
|
||||||
|
surplus_hugepages
|
||||||
|
resv_hugepages
|
||||||
|
See Documentation/vm/hugetlbpage.txt for details.
|
|
@ -474,25 +474,29 @@ make a good program).
|
||||||
So, you can either get rid of GNU emacs, or change it to use saner
|
So, you can either get rid of GNU emacs, or change it to use saner
|
||||||
values. To do the latter, you can stick the following in your .emacs file:
|
values. To do the latter, you can stick the following in your .emacs file:
|
||||||
|
|
||||||
(defun linux-c-mode ()
|
(defun c-lineup-arglist-tabs-only (ignored)
|
||||||
"C mode with adjusted defaults for use with the Linux kernel."
|
"Line up argument lists by tabs, not spaces"
|
||||||
(interactive)
|
(let* ((anchor (c-langelem-pos c-syntactic-element))
|
||||||
(c-mode)
|
(column (c-langelem-2nd-pos c-syntactic-element))
|
||||||
(c-set-style "K&R")
|
(offset (- (1+ column) anchor))
|
||||||
(setq tab-width 8)
|
(steps (floor offset c-basic-offset)))
|
||||||
(setq indent-tabs-mode t)
|
(* (max steps 1)
|
||||||
(setq c-basic-offset 8))
|
c-basic-offset)))
|
||||||
|
|
||||||
This will define the M-x linux-c-mode command. When hacking on a
|
(add-hook 'c-mode-hook
|
||||||
module, if you put the string -*- linux-c -*- somewhere on the first
|
(lambda ()
|
||||||
two lines, this mode will be automatically invoked. Also, you may want
|
(let ((filename (buffer-file-name)))
|
||||||
to add
|
;; Enable kernel mode for the appropriate files
|
||||||
|
(when (and filename
|
||||||
|
(string-match "~/src/linux-trees" filename))
|
||||||
|
(setq indent-tabs-mode t)
|
||||||
|
(c-set-style "linux")
|
||||||
|
(c-set-offset 'arglist-cont-nonempty
|
||||||
|
'(c-lineup-gcc-asm-reg
|
||||||
|
c-lineup-arglist-tabs-only))))))
|
||||||
|
|
||||||
(setq auto-mode-alist (cons '("/usr/src/linux.*/.*\\.[ch]$" . linux-c-mode)
|
This will make emacs go better with the kernel coding style for C
|
||||||
auto-mode-alist))
|
files below ~/src/linux-trees.
|
||||||
|
|
||||||
to your .emacs file if you want to have linux-c-mode switched on
|
|
||||||
automagically when you edit source files under /usr/src/linux.
|
|
||||||
|
|
||||||
But even if you fail in getting emacs to do sane formatting, not
|
But even if you fail in getting emacs to do sane formatting, not
|
||||||
everything is lost: use "indent".
|
everything is lost: use "indent".
|
||||||
|
|
|
@ -298,10 +298,10 @@ recommended that you never use these unless you really know what the
|
||||||
cache width is.
|
cache width is.
|
||||||
|
|
||||||
int
|
int
|
||||||
dma_mapping_error(dma_addr_t dma_addr)
|
dma_mapping_error(struct device *dev, dma_addr_t dma_addr)
|
||||||
|
|
||||||
int
|
int
|
||||||
pci_dma_mapping_error(dma_addr_t dma_addr)
|
pci_dma_mapping_error(struct pci_dev *hwdev, dma_addr_t dma_addr)
|
||||||
|
|
||||||
In some circumstances dma_map_single and dma_map_page will fail to create
|
In some circumstances dma_map_single and dma_map_page will fail to create
|
||||||
a mapping. A driver can check for these errors by testing the returned
|
a mapping. A driver can check for these errors by testing the returned
|
||||||
|
|
|
@ -22,3 +22,12 @@ ready and available in memory. The DMA of the "completion indication"
|
||||||
could race with data DMA. Mapping the memory used for completion
|
could race with data DMA. Mapping the memory used for completion
|
||||||
indications with DMA_ATTR_WRITE_BARRIER would prevent the race.
|
indications with DMA_ATTR_WRITE_BARRIER would prevent the race.
|
||||||
|
|
||||||
|
DMA_ATTR_WEAK_ORDERING
|
||||||
|
----------------------
|
||||||
|
|
||||||
|
DMA_ATTR_WEAK_ORDERING specifies that reads and writes to the mapping
|
||||||
|
may be weakly ordered, that is that reads and writes may pass each other.
|
||||||
|
|
||||||
|
Since it is optional for platforms to implement DMA_ATTR_WEAK_ORDERING,
|
||||||
|
those that do not will simply ignore the attribute and exhibit default
|
||||||
|
behavior.
|
||||||
|
|
|
@ -524,6 +524,44 @@ These utilities include endpoint autoconfiguration.
|
||||||
<!-- !Edrivers/usb/gadget/epautoconf.c -->
|
<!-- !Edrivers/usb/gadget/epautoconf.c -->
|
||||||
</sect1>
|
</sect1>
|
||||||
|
|
||||||
|
<sect1 id="composite"><title>Composite Device Framework</title>
|
||||||
|
|
||||||
|
<para>The core API is sufficient for writing drivers for composite
|
||||||
|
USB devices (with more than one function in a given configuration),
|
||||||
|
and also multi-configuration devices (also more than one function,
|
||||||
|
but not necessarily sharing a given configuration).
|
||||||
|
There is however an optional framework which makes it easier to
|
||||||
|
reuse and combine functions.
|
||||||
|
</para>
|
||||||
|
|
||||||
|
<para>Devices using this framework provide a <emphasis>struct
|
||||||
|
usb_composite_driver</emphasis>, which in turn provides one or
|
||||||
|
more <emphasis>struct usb_configuration</emphasis> instances.
|
||||||
|
Each such configuration includes at least one
|
||||||
|
<emphasis>struct usb_function</emphasis>, which packages a user
|
||||||
|
visible role such as "network link" or "mass storage device".
|
||||||
|
Management functions may also exist, such as "Device Firmware
|
||||||
|
Upgrade".
|
||||||
|
</para>
|
||||||
|
|
||||||
|
!Iinclude/linux/usb/composite.h
|
||||||
|
!Edrivers/usb/gadget/composite.c
|
||||||
|
|
||||||
|
</sect1>
|
||||||
|
|
||||||
|
<sect1 id="functions"><title>Composite Device Functions</title>
|
||||||
|
|
||||||
|
<para>At this writing, a few of the current gadget drivers have
|
||||||
|
been converted to this framework.
|
||||||
|
Near-term plans include converting all of them, except for "gadgetfs".
|
||||||
|
</para>
|
||||||
|
|
||||||
|
!Edrivers/usb/gadget/f_acm.c
|
||||||
|
!Edrivers/usb/gadget/f_serial.c
|
||||||
|
|
||||||
|
</sect1>
|
||||||
|
|
||||||
|
|
||||||
</chapter>
|
</chapter>
|
||||||
|
|
||||||
<chapter id="controllers"><title>Peripheral Controller Drivers</title>
|
<chapter id="controllers"><title>Peripheral Controller Drivers</title>
|
||||||
|
|
|
@ -219,10 +219,10 @@
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<sect1 id="lock-intro">
|
<sect1 id="lock-intro">
|
||||||
<title>Three Main Types of Kernel Locks: Spinlocks, Mutexes and Semaphores</title>
|
<title>Two Main Types of Kernel Locks: Spinlocks and Mutexes</title>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
There are three main types of kernel locks. The fundamental type
|
There are two main types of kernel locks. The fundamental type
|
||||||
is the spinlock
|
is the spinlock
|
||||||
(<filename class="headerfile">include/asm/spinlock.h</filename>),
|
(<filename class="headerfile">include/asm/spinlock.h</filename>),
|
||||||
which is a very simple single-holder lock: if you can't get the
|
which is a very simple single-holder lock: if you can't get the
|
||||||
|
@ -239,14 +239,6 @@
|
||||||
can't sleep (see <xref linkend="sleeping-things"/>), and so have to
|
can't sleep (see <xref linkend="sleeping-things"/>), and so have to
|
||||||
use a spinlock instead.
|
use a spinlock instead.
|
||||||
</para>
|
</para>
|
||||||
<para>
|
|
||||||
The third type is a semaphore
|
|
||||||
(<filename class="headerfile">include/linux/semaphore.h</filename>): it
|
|
||||||
can have more than one holder at any time (the number decided at
|
|
||||||
initialization time), although it is most commonly used as a
|
|
||||||
single-holder lock (a mutex). If you can't get a semaphore, your
|
|
||||||
task will be suspended and later on woken up - just like for mutexes.
|
|
||||||
</para>
|
|
||||||
<para>
|
<para>
|
||||||
Neither type of lock is recursive: see
|
Neither type of lock is recursive: see
|
||||||
<xref linkend="deadlock"/>.
|
<xref linkend="deadlock"/>.
|
||||||
|
@ -278,7 +270,7 @@
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
Semaphores still exist, because they are required for
|
Mutexes still exist, because they are required for
|
||||||
synchronization between <firstterm linkend="gloss-usercontext">user
|
synchronization between <firstterm linkend="gloss-usercontext">user
|
||||||
contexts</firstterm>, as we will see below.
|
contexts</firstterm>, as we will see below.
|
||||||
</para>
|
</para>
|
||||||
|
@ -289,18 +281,17 @@
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
If you have a data structure which is only ever accessed from
|
If you have a data structure which is only ever accessed from
|
||||||
user context, then you can use a simple semaphore
|
user context, then you can use a simple mutex
|
||||||
(<filename>linux/linux/semaphore.h</filename>) to protect it. This
|
(<filename>include/linux/mutex.h</filename>) to protect it. This
|
||||||
is the most trivial case: you initialize the semaphore to the number
|
is the most trivial case: you initialize the mutex. Then you can
|
||||||
of resources available (usually 1), and call
|
call <function>mutex_lock_interruptible()</function> to grab the mutex,
|
||||||
<function>down_interruptible()</function> to grab the semaphore, and
|
and <function>mutex_unlock()</function> to release it. There is also a
|
||||||
<function>up()</function> to release it. There is also a
|
<function>mutex_lock()</function>, which should be avoided, because it
|
||||||
<function>down()</function>, which should be avoided, because it
|
|
||||||
will not return if a signal is received.
|
will not return if a signal is received.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
Example: <filename>linux/net/core/netfilter.c</filename> allows
|
Example: <filename>net/netfilter/nf_sockopt.c</filename> allows
|
||||||
registration of new <function>setsockopt()</function> and
|
registration of new <function>setsockopt()</function> and
|
||||||
<function>getsockopt()</function> calls, with
|
<function>getsockopt()</function> calls, with
|
||||||
<function>nf_register_sockopt()</function>. Registration and
|
<function>nf_register_sockopt()</function>. Registration and
|
||||||
|
@ -515,7 +506,7 @@
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
If you are in a process context (any syscall) and want to
|
If you are in a process context (any syscall) and want to
|
||||||
lock other process out, use a semaphore. You can take a semaphore
|
lock other process out, use a mutex. You can take a mutex
|
||||||
and sleep (<function>copy_from_user*(</function> or
|
and sleep (<function>copy_from_user*(</function> or
|
||||||
<function>kmalloc(x,GFP_KERNEL)</function>).
|
<function>kmalloc(x,GFP_KERNEL)</function>).
|
||||||
</para>
|
</para>
|
||||||
|
@ -662,7 +653,7 @@
|
||||||
<entry>SLBH</entry>
|
<entry>SLBH</entry>
|
||||||
<entry>SLBH</entry>
|
<entry>SLBH</entry>
|
||||||
<entry>SLBH</entry>
|
<entry>SLBH</entry>
|
||||||
<entry>DI</entry>
|
<entry>MLI</entry>
|
||||||
<entry>None</entry>
|
<entry>None</entry>
|
||||||
</row>
|
</row>
|
||||||
|
|
||||||
|
@ -692,8 +683,8 @@
|
||||||
<entry>spin_lock_bh</entry>
|
<entry>spin_lock_bh</entry>
|
||||||
</row>
|
</row>
|
||||||
<row>
|
<row>
|
||||||
<entry>DI</entry>
|
<entry>MLI</entry>
|
||||||
<entry>down_interruptible</entry>
|
<entry>mutex_lock_interruptible</entry>
|
||||||
</row>
|
</row>
|
||||||
|
|
||||||
</tbody>
|
</tbody>
|
||||||
|
@ -1310,7 +1301,7 @@ as Alan Cox says, <quote>Lock data, not code</quote>.
|
||||||
<para>
|
<para>
|
||||||
There is a coding bug where a piece of code tries to grab a
|
There is a coding bug where a piece of code tries to grab a
|
||||||
spinlock twice: it will spin forever, waiting for the lock to
|
spinlock twice: it will spin forever, waiting for the lock to
|
||||||
be released (spinlocks, rwlocks and semaphores are not
|
be released (spinlocks, rwlocks and mutexes are not
|
||||||
recursive in Linux). This is trivial to diagnose: not a
|
recursive in Linux). This is trivial to diagnose: not a
|
||||||
stay-up-five-nights-talk-to-fluffy-code-bunnies kind of
|
stay-up-five-nights-talk-to-fluffy-code-bunnies kind of
|
||||||
problem.
|
problem.
|
||||||
|
@ -1335,7 +1326,7 @@ as Alan Cox says, <quote>Lock data, not code</quote>.
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
This complete lockup is easy to diagnose: on SMP boxes the
|
This complete lockup is easy to diagnose: on SMP boxes the
|
||||||
watchdog timer or compiling with <symbol>DEBUG_SPINLOCKS</symbol> set
|
watchdog timer or compiling with <symbol>DEBUG_SPINLOCK</symbol> set
|
||||||
(<filename>include/linux/spinlock.h</filename>) will show this up
|
(<filename>include/linux/spinlock.h</filename>) will show this up
|
||||||
immediately when it happens.
|
immediately when it happens.
|
||||||
</para>
|
</para>
|
||||||
|
@ -1558,7 +1549,7 @@ the amount of locking which needs to be done.
|
||||||
<title>Read/Write Lock Variants</title>
|
<title>Read/Write Lock Variants</title>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
Both spinlocks and semaphores have read/write variants:
|
Both spinlocks and mutexes have read/write variants:
|
||||||
<type>rwlock_t</type> and <structname>struct rw_semaphore</structname>.
|
<type>rwlock_t</type> and <structname>struct rw_semaphore</structname>.
|
||||||
These divide users into two classes: the readers and the writers. If
|
These divide users into two classes: the readers and the writers. If
|
||||||
you are only reading the data, you can get a read lock, but to write to
|
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.
|
||||||
#include <linux/slab.h>
|
#include <linux/slab.h>
|
||||||
#include <linux/string.h>
|
#include <linux/string.h>
|
||||||
+#include <linux/rcupdate.h>
|
+#include <linux/rcupdate.h>
|
||||||
#include <linux/semaphore.h>
|
#include <linux/mutex.h>
|
||||||
#include <asm/errno.h>
|
#include <asm/errno.h>
|
||||||
|
|
||||||
struct object
|
struct object
|
||||||
|
@ -1913,7 +1904,7 @@ machines due to caching.
|
||||||
</listitem>
|
</listitem>
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
<function> put_user()</function>
|
<function>put_user()</function>
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
</itemizedlist>
|
</itemizedlist>
|
||||||
|
@ -1927,13 +1918,13 @@ machines due to caching.
|
||||||
|
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
<function>down_interruptible()</function> and
|
<function>mutex_lock_interruptible()</function> and
|
||||||
<function>down()</function>
|
<function>mutex_lock()</function>
|
||||||
</para>
|
</para>
|
||||||
<para>
|
<para>
|
||||||
There is a <function>down_trylock()</function> which can be
|
There is a <function>mutex_trylock()</function> which can be
|
||||||
used inside interrupt context, as it will not sleep.
|
used inside interrupt context, as it will not sleep.
|
||||||
<function>up()</function> will also never sleep.
|
<function>mutex_unlock()</function> will also never sleep.
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
</itemizedlist>
|
</itemizedlist>
|
||||||
|
@ -2023,7 +2014,7 @@ machines due to caching.
|
||||||
<para>
|
<para>
|
||||||
Prior to 2.5, or when <symbol>CONFIG_PREEMPT</symbol> is
|
Prior to 2.5, or when <symbol>CONFIG_PREEMPT</symbol> is
|
||||||
unset, processes in user context inside the kernel would not
|
unset, processes in user context inside the kernel would not
|
||||||
preempt each other (ie. you had that CPU until you have it up,
|
preempt each other (ie. you had that CPU until you gave it up,
|
||||||
except for interrupts). With the addition of
|
except for interrupts). With the addition of
|
||||||
<symbol>CONFIG_PREEMPT</symbol> in 2.5.4, this changed: when
|
<symbol>CONFIG_PREEMPT</symbol> in 2.5.4, this changed: when
|
||||||
in user context, higher priority tasks can "cut in": spinlocks
|
in user context, higher priority tasks can "cut in": spinlocks
|
||||||
|
|
|
@ -29,12 +29,12 @@
|
||||||
|
|
||||||
<revhistory>
|
<revhistory>
|
||||||
<revision>
|
<revision>
|
||||||
<revnumber>1.0 </revnumber>
|
<revnumber>1.0</revnumber>
|
||||||
<date>May 30, 2001</date>
|
<date>May 30, 2001</date>
|
||||||
<revremark>Initial revision posted to linux-kernel</revremark>
|
<revremark>Initial revision posted to linux-kernel</revremark>
|
||||||
</revision>
|
</revision>
|
||||||
<revision>
|
<revision>
|
||||||
<revnumber>1.1 </revnumber>
|
<revnumber>1.1</revnumber>
|
||||||
<date>June 3, 2001</date>
|
<date>June 3, 2001</date>
|
||||||
<revremark>Revised after comments from linux-kernel</revremark>
|
<revremark>Revised after comments from linux-kernel</revremark>
|
||||||
</revision>
|
</revision>
|
||||||
|
|
|
@ -21,6 +21,18 @@
|
||||||
</affiliation>
|
</affiliation>
|
||||||
</author>
|
</author>
|
||||||
|
|
||||||
|
<copyright>
|
||||||
|
<year>2006-2008</year>
|
||||||
|
<holder>Hans-Jürgen Koch.</holder>
|
||||||
|
</copyright>
|
||||||
|
|
||||||
|
<legalnotice>
|
||||||
|
<para>
|
||||||
|
This documentation is Free Software licensed under the terms of the
|
||||||
|
GPL version 2.
|
||||||
|
</para>
|
||||||
|
</legalnotice>
|
||||||
|
|
||||||
<pubdate>2006-12-11</pubdate>
|
<pubdate>2006-12-11</pubdate>
|
||||||
|
|
||||||
<abstract>
|
<abstract>
|
||||||
|
@ -29,6 +41,12 @@
|
||||||
</abstract>
|
</abstract>
|
||||||
|
|
||||||
<revhistory>
|
<revhistory>
|
||||||
|
<revision>
|
||||||
|
<revnumber>0.5</revnumber>
|
||||||
|
<date>2008-05-22</date>
|
||||||
|
<authorinitials>hjk</authorinitials>
|
||||||
|
<revremark>Added description of write() function.</revremark>
|
||||||
|
</revision>
|
||||||
<revision>
|
<revision>
|
||||||
<revnumber>0.4</revnumber>
|
<revnumber>0.4</revnumber>
|
||||||
<date>2007-11-26</date>
|
<date>2007-11-26</date>
|
||||||
|
@ -57,20 +75,9 @@
|
||||||
</bookinfo>
|
</bookinfo>
|
||||||
|
|
||||||
<chapter id="aboutthisdoc">
|
<chapter id="aboutthisdoc">
|
||||||
<?dbhtml filename="about.html"?>
|
<?dbhtml filename="aboutthis.html"?>
|
||||||
<title>About this document</title>
|
<title>About this document</title>
|
||||||
|
|
||||||
<sect1 id="copyright">
|
|
||||||
<?dbhtml filename="copyright.html"?>
|
|
||||||
<title>Copyright and License</title>
|
|
||||||
<para>
|
|
||||||
Copyright (c) 2006 by Hans-Jürgen Koch.</para>
|
|
||||||
<para>
|
|
||||||
This documentation is Free Software licensed under the terms of the
|
|
||||||
GPL version 2.
|
|
||||||
</para>
|
|
||||||
</sect1>
|
|
||||||
|
|
||||||
<sect1 id="translations">
|
<sect1 id="translations">
|
||||||
<?dbhtml filename="translations.html"?>
|
<?dbhtml filename="translations.html"?>
|
||||||
<title>Translations</title>
|
<title>Translations</title>
|
||||||
|
@ -189,6 +196,30 @@ interested in translating it, please email me
|
||||||
represents the total interrupt count. You can use this number
|
represents the total interrupt count. You can use this number
|
||||||
to figure out if you missed some interrupts.
|
to figure out if you missed some interrupts.
|
||||||
</para>
|
</para>
|
||||||
|
<para>
|
||||||
|
For some hardware that has more than one interrupt source internally,
|
||||||
|
but not separate IRQ mask and status registers, there might be
|
||||||
|
situations where userspace cannot determine what the interrupt source
|
||||||
|
was if the kernel handler disables them by writing to the chip's IRQ
|
||||||
|
register. In such a case, the kernel has to disable the IRQ completely
|
||||||
|
to leave the chip's register untouched. Now the userspace part can
|
||||||
|
determine the cause of the interrupt, but it cannot re-enable
|
||||||
|
interrupts. Another cornercase is chips where re-enabling interrupts
|
||||||
|
is a read-modify-write operation to a combined IRQ status/acknowledge
|
||||||
|
register. This would be racy if a new interrupt occurred
|
||||||
|
simultaneously.
|
||||||
|
</para>
|
||||||
|
<para>
|
||||||
|
To address these problems, UIO also implements a write() function. It
|
||||||
|
is normally not used and can be ignored for hardware that has only a
|
||||||
|
single interrupt source or has separate IRQ mask and status registers.
|
||||||
|
If you need it, however, a write to <filename>/dev/uioX</filename>
|
||||||
|
will call the <function>irqcontrol()</function> function implemented
|
||||||
|
by the driver. You have to write a 32-bit value that is usually either
|
||||||
|
0 or 1 to disable or enable interrupts. If a driver does not implement
|
||||||
|
<function>irqcontrol()</function>, <function>write()</function> will
|
||||||
|
return with <varname>-ENOSYS</varname>.
|
||||||
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
To handle interrupts properly, your custom kernel module can
|
To handle interrupts properly, your custom kernel module can
|
||||||
|
@ -362,6 +393,14 @@ device is actually used.
|
||||||
<function>open()</function>, you will probably also want a custom
|
<function>open()</function>, you will probably also want a custom
|
||||||
<function>release()</function> function.
|
<function>release()</function> function.
|
||||||
</para></listitem>
|
</para></listitem>
|
||||||
|
|
||||||
|
<listitem><para>
|
||||||
|
<varname>int (*irqcontrol)(struct uio_info *info, s32 irq_on)
|
||||||
|
</varname>: Optional. If you need to be able to enable or disable
|
||||||
|
interrupts from userspace by writing to <filename>/dev/uioX</filename>,
|
||||||
|
you can implement this function. The parameter <varname>irq_on</varname>
|
||||||
|
will be 0 to disable interrupts and 1 to enable them.
|
||||||
|
</para></listitem>
|
||||||
</itemizedlist>
|
</itemizedlist>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
|
|
|
@ -358,7 +358,7 @@ Here is a list of some of the different kernel trees available:
|
||||||
- pcmcia, Dominik Brodowski <linux@dominikbrodowski.net>
|
- pcmcia, Dominik Brodowski <linux@dominikbrodowski.net>
|
||||||
git.kernel.org:/pub/scm/linux/kernel/git/brodo/pcmcia-2.6.git
|
git.kernel.org:/pub/scm/linux/kernel/git/brodo/pcmcia-2.6.git
|
||||||
|
|
||||||
- SCSI, James Bottomley <James.Bottomley@SteelEye.com>
|
- SCSI, James Bottomley <James.Bottomley@hansenpartnership.com>
|
||||||
git.kernel.org:/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6.git
|
git.kernel.org:/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6.git
|
||||||
|
|
||||||
- x86, Ingo Molnar <mingo@elte.hu>
|
- x86, Ingo Molnar <mingo@elte.hu>
|
||||||
|
|
|
@ -48,7 +48,7 @@ IOVA generation is pretty generic. We used the same technique as vmalloc()
|
||||||
but these are not global address spaces, but separate for each domain.
|
but these are not global address spaces, but separate for each domain.
|
||||||
Different DMA engines may support different number of domains.
|
Different DMA engines may support different number of domains.
|
||||||
|
|
||||||
We also allocate gaurd pages with each mapping, so we can attempt to catch
|
We also allocate guard pages with each mapping, so we can attempt to catch
|
||||||
any overflow that might happen.
|
any overflow that might happen.
|
||||||
|
|
||||||
|
|
||||||
|
@ -112,4 +112,4 @@ TBD
|
||||||
|
|
||||||
- For compatibility testing, could use unity map domain for all devices, just
|
- For compatibility testing, could use unity map domain for all devices, just
|
||||||
provide a 1-1 for all useful memory under a single domain for all devices.
|
provide a 1-1 for all useful memory under a single domain for all devices.
|
||||||
- API for paravirt ops for abstracting functionlity for VMM folks.
|
- API for paravirt ops for abstracting functionality for VMM folks.
|
||||||
|
|
|
@ -528,7 +528,33 @@ See more details on the proper patch format in the following
|
||||||
references.
|
references.
|
||||||
|
|
||||||
|
|
||||||
|
16) Sending "git pull" requests (from Linus emails)
|
||||||
|
|
||||||
|
Please write the git repo address and branch name alone on the same line
|
||||||
|
so that I can't even by mistake pull from the wrong branch, and so
|
||||||
|
that a triple-click just selects the whole thing.
|
||||||
|
|
||||||
|
So the proper format is something along the lines of:
|
||||||
|
|
||||||
|
"Please pull from
|
||||||
|
|
||||||
|
git://jdelvare.pck.nerim.net/jdelvare-2.6 i2c-for-linus
|
||||||
|
|
||||||
|
to get these changes:"
|
||||||
|
|
||||||
|
so that I don't have to hunt-and-peck for the address and inevitably
|
||||||
|
get it wrong (actually, I've only gotten it wrong a few times, and
|
||||||
|
checking against the diffstat tells me when I get it wrong, but I'm
|
||||||
|
just a lot more comfortable when I don't have to "look for" the right
|
||||||
|
thing to pull, and double-check that I have the right branch-name).
|
||||||
|
|
||||||
|
|
||||||
|
Please use "git diff -M --stat --summary" to generate the diffstat:
|
||||||
|
the -M enables rename detection, and the summary enables a summary of
|
||||||
|
new/deleted or renamed files.
|
||||||
|
|
||||||
|
With rename detection, the statistics are rather different [...]
|
||||||
|
because git will notice that a fair number of the changes are renames.
|
||||||
|
|
||||||
-----------------------------------
|
-----------------------------------
|
||||||
SECTION 2 - HINTS, TIPS, AND TRICKS
|
SECTION 2 - HINTS, TIPS, AND TRICKS
|
||||||
|
|
|
@ -11,6 +11,7 @@ the delays experienced by a task while
|
||||||
a) waiting for a CPU (while being runnable)
|
a) waiting for a CPU (while being runnable)
|
||||||
b) completion of synchronous block I/O initiated by the task
|
b) completion of synchronous block I/O initiated by the task
|
||||||
c) swapping in pages
|
c) swapping in pages
|
||||||
|
d) memory reclaim
|
||||||
|
|
||||||
and makes these statistics available to userspace through
|
and makes these statistics available to userspace through
|
||||||
the taskstats interface.
|
the taskstats interface.
|
||||||
|
@ -41,7 +42,7 @@ this structure. See
|
||||||
include/linux/taskstats.h
|
include/linux/taskstats.h
|
||||||
for a description of the fields pertaining to delay accounting.
|
for a description of the fields pertaining to delay accounting.
|
||||||
It will generally be in the form of counters returning the cumulative
|
It will generally be in the form of counters returning the cumulative
|
||||||
delay seen for cpu, sync block I/O, swapin etc.
|
delay seen for cpu, sync block I/O, swapin, memory reclaim etc.
|
||||||
|
|
||||||
Taking the difference of two successive readings of a given
|
Taking the difference of two successive readings of a given
|
||||||
counter (say cpu_delay_total) for a task will give the delay
|
counter (say cpu_delay_total) for a task will give the delay
|
||||||
|
@ -94,7 +95,9 @@ CPU count real total virtual total delay total
|
||||||
7876 92005750 100000000 24001500
|
7876 92005750 100000000 24001500
|
||||||
IO count delay total
|
IO count delay total
|
||||||
0 0
|
0 0
|
||||||
MEM count delay total
|
SWAP count delay total
|
||||||
|
0 0
|
||||||
|
RECLAIM count delay total
|
||||||
0 0
|
0 0
|
||||||
|
|
||||||
Get delays seen in executing a given simple command
|
Get delays seen in executing a given simple command
|
||||||
|
@ -108,5 +111,7 @@ CPU count real total virtual total delay total
|
||||||
6 4000250 4000000 0
|
6 4000250 4000000 0
|
||||||
IO count delay total
|
IO count delay total
|
||||||
0 0
|
0 0
|
||||||
MEM count delay total
|
SWAP count delay total
|
||||||
|
0 0
|
||||||
|
RECLAIM count delay total
|
||||||
0 0
|
0 0
|
||||||
|
|
|
@ -196,14 +196,18 @@ void print_delayacct(struct taskstats *t)
|
||||||
" %15llu%15llu%15llu%15llu\n"
|
" %15llu%15llu%15llu%15llu\n"
|
||||||
"IO %15s%15s\n"
|
"IO %15s%15s\n"
|
||||||
" %15llu%15llu\n"
|
" %15llu%15llu\n"
|
||||||
"MEM %15s%15s\n"
|
"SWAP %15s%15s\n"
|
||||||
|
" %15llu%15llu\n"
|
||||||
|
"RECLAIM %12s%15s\n"
|
||||||
" %15llu%15llu\n",
|
" %15llu%15llu\n",
|
||||||
"count", "real total", "virtual total", "delay total",
|
"count", "real total", "virtual total", "delay total",
|
||||||
t->cpu_count, t->cpu_run_real_total, t->cpu_run_virtual_total,
|
t->cpu_count, t->cpu_run_real_total, t->cpu_run_virtual_total,
|
||||||
t->cpu_delay_total,
|
t->cpu_delay_total,
|
||||||
"count", "delay total",
|
"count", "delay total",
|
||||||
t->blkio_count, t->blkio_delay_total,
|
t->blkio_count, t->blkio_delay_total,
|
||||||
"count", "delay total", t->swapin_count, t->swapin_delay_total);
|
"count", "delay total", t->swapin_count, t->swapin_delay_total,
|
||||||
|
"count", "delay total",
|
||||||
|
t->freepages_count, t->freepages_delay_total);
|
||||||
}
|
}
|
||||||
|
|
||||||
void task_context_switch_counts(struct taskstats *t)
|
void task_context_switch_counts(struct taskstats *t)
|
||||||
|
|
|
@ -6,7 +6,7 @@ This document contains an explanation of the struct taskstats fields.
|
||||||
There are three different groups of fields in the struct taskstats:
|
There are three different groups of fields in the struct taskstats:
|
||||||
|
|
||||||
1) Common and basic accounting fields
|
1) Common and basic accounting fields
|
||||||
If CONFIG_TASKSTATS is set, the taskstats inteface is enabled and
|
If CONFIG_TASKSTATS is set, the taskstats interface is enabled and
|
||||||
the common fields and basic accounting fields are collected for
|
the common fields and basic accounting fields are collected for
|
||||||
delivery at do_exit() of a task.
|
delivery at do_exit() of a task.
|
||||||
2) Delay accounting fields
|
2) Delay accounting fields
|
||||||
|
@ -26,6 +26,8 @@ There are three different groups of fields in the struct taskstats:
|
||||||
|
|
||||||
5) Time accounting for SMT machines
|
5) Time accounting for SMT machines
|
||||||
|
|
||||||
|
6) Extended delay accounting fields for memory reclaim
|
||||||
|
|
||||||
Future extension should add fields to the end of the taskstats struct, and
|
Future extension should add fields to the end of the taskstats struct, and
|
||||||
should not change the relative position of each field within the struct.
|
should not change the relative position of each field within the struct.
|
||||||
|
|
||||||
|
@ -170,4 +172,9 @@ struct taskstats {
|
||||||
__u64 ac_utimescaled; /* utime scaled on frequency etc */
|
__u64 ac_utimescaled; /* utime scaled on frequency etc */
|
||||||
__u64 ac_stimescaled; /* stime scaled on frequency etc */
|
__u64 ac_stimescaled; /* stime scaled on frequency etc */
|
||||||
__u64 cpu_scaled_run_real_total; /* scaled cpu_run_real_total */
|
__u64 cpu_scaled_run_real_total; /* scaled cpu_run_real_total */
|
||||||
|
|
||||||
|
6) Extended delay accounting fields for memory reclaim
|
||||||
|
/* Delay waiting for memory reclaim */
|
||||||
|
__u64 freepages_count;
|
||||||
|
__u64 freepages_delay_total;
|
||||||
}
|
}
|
||||||
|
|
|
@ -138,14 +138,8 @@ So, what's changed?
|
||||||
|
|
||||||
Set active the IRQ edge(s)/level. This replaces the
|
Set active the IRQ edge(s)/level. This replaces the
|
||||||
SA1111 INTPOL manipulation, and the set_GPIO_IRQ_edge()
|
SA1111 INTPOL manipulation, and the set_GPIO_IRQ_edge()
|
||||||
function. Type should be one of the following:
|
function. Type should be one of IRQ_TYPE_xxx defined in
|
||||||
|
<linux/irq.h>
|
||||||
#define IRQT_NOEDGE (0)
|
|
||||||
#define IRQT_RISING (__IRQT_RISEDGE)
|
|
||||||
#define IRQT_FALLING (__IRQT_FALEDGE)
|
|
||||||
#define IRQT_BOTHEDGE (__IRQT_RISEDGE|__IRQT_FALEDGE)
|
|
||||||
#define IRQT_LOW (__IRQT_LOWLVL)
|
|
||||||
#define IRQT_HIGH (__IRQT_HIGHLVL)
|
|
||||||
|
|
||||||
3. set_GPIO_IRQ_edge() is obsolete, and should be replaced by set_irq_type.
|
3. set_GPIO_IRQ_edge() is obsolete, and should be replaced by set_irq_type.
|
||||||
|
|
||||||
|
|
67
Documentation/bt8xxgpio.txt
Normal file
67
Documentation/bt8xxgpio.txt
Normal file
|
@ -0,0 +1,67 @@
|
||||||
|
===============================================================
|
||||||
|
== BT8XXGPIO driver ==
|
||||||
|
== ==
|
||||||
|
== A driver for a selfmade cheap BT8xx based PCI GPIO-card ==
|
||||||
|
== ==
|
||||||
|
== For advanced documentation, see ==
|
||||||
|
== http://www.bu3sch.de/btgpio.php ==
|
||||||
|
===============================================================
|
||||||
|
|
||||||
|
|
||||||
|
A generic digital 24-port PCI GPIO card can be built out of an ordinary
|
||||||
|
Brooktree bt848, bt849, bt878 or bt879 based analog TV tuner card. The
|
||||||
|
Brooktree chip is used in old analog Hauppauge WinTV PCI cards. You can easily
|
||||||
|
find them used for low prices on the net.
|
||||||
|
|
||||||
|
The bt8xx chip does have 24 digital GPIO ports.
|
||||||
|
These ports are accessible via 24 pins on the SMD chip package.
|
||||||
|
|
||||||
|
|
||||||
|
==============================================
|
||||||
|
== How to physically access the GPIO pins ==
|
||||||
|
==============================================
|
||||||
|
|
||||||
|
The are several ways to access these pins. One might unsolder the whole chip
|
||||||
|
and put it on a custom PCI board, or one might only unsolder each individual
|
||||||
|
GPIO pin and solder that to some tiny wire. As the chip package really is tiny
|
||||||
|
there are some advanced soldering skills needed in any case.
|
||||||
|
|
||||||
|
The physical pinouts are drawn in the following ASCII art.
|
||||||
|
The GPIO pins are marked with G00-G23
|
||||||
|
|
||||||
|
G G G G G G G G G G G G G G G G G G
|
||||||
|
0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1
|
||||||
|
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7
|
||||||
|
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
|
||||||
|
---------------------------------------------------------------------------
|
||||||
|
--| ^ ^ |--
|
||||||
|
--| pin 86 pin 67 |--
|
||||||
|
--| |--
|
||||||
|
--| pin 61 > |-- G18
|
||||||
|
--| |-- G19
|
||||||
|
--| |-- G20
|
||||||
|
--| |-- G21
|
||||||
|
--| |-- G22
|
||||||
|
--| pin 56 > |-- G23
|
||||||
|
--| |--
|
||||||
|
--| Brooktree 878/879 |--
|
||||||
|
--| |--
|
||||||
|
--| |--
|
||||||
|
--| |--
|
||||||
|
--| |--
|
||||||
|
--| |--
|
||||||
|
--| |--
|
||||||
|
--| |--
|
||||||
|
--| |--
|
||||||
|
--| |--
|
||||||
|
--| |--
|
||||||
|
--| |--
|
||||||
|
--| |--
|
||||||
|
--| |--
|
||||||
|
--| O |--
|
||||||
|
--| |--
|
||||||
|
---------------------------------------------------------------------------
|
||||||
|
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
|
||||||
|
^
|
||||||
|
This is pin 1
|
||||||
|
|
|
@ -242,8 +242,7 @@ rmdir() if there are no tasks.
|
||||||
1. Add support for accounting huge pages (as a separate controller)
|
1. Add support for accounting huge pages (as a separate controller)
|
||||||
2. Make per-cgroup scanner reclaim not-shared pages first
|
2. Make per-cgroup scanner reclaim not-shared pages first
|
||||||
3. Teach controller to account for shared-pages
|
3. Teach controller to account for shared-pages
|
||||||
4. Start reclamation when the limit is lowered
|
4. Start reclamation in the background when the limit is
|
||||||
5. Start reclamation in the background when the limit is
|
|
||||||
not yet hit but the usage is getting closer
|
not yet hit but the usage is getting closer
|
||||||
|
|
||||||
Summary
|
Summary
|
||||||
|
|
|
@ -122,7 +122,7 @@ around '10000' or more.
|
||||||
show_sampling_rate_(min|max): the minimum and maximum sampling rates
|
show_sampling_rate_(min|max): the minimum and maximum sampling rates
|
||||||
available that you may set 'sampling_rate' to.
|
available that you may set 'sampling_rate' to.
|
||||||
|
|
||||||
up_threshold: defines what the average CPU usaged between the samplings
|
up_threshold: defines what the average CPU usage between the samplings
|
||||||
of 'sampling_rate' needs to be for the kernel to make a decision on
|
of 'sampling_rate' needs to be for the kernel to make a decision on
|
||||||
whether it should increase the frequency. For example when it is set
|
whether it should increase the frequency. For example when it is set
|
||||||
to its default value of '80' it means that between the checking
|
to its default value of '80' it means that between the checking
|
||||||
|
|
|
@ -222,74 +222,9 @@ both csrow2 and csrow3 are populated, this indicates a dual ranked
|
||||||
set of DIMMs for channels 0 and 1.
|
set of DIMMs for channels 0 and 1.
|
||||||
|
|
||||||
|
|
||||||
Within each of the 'mc','mcX' and 'csrowX' directories are several
|
Within each of the 'mcX' and 'csrowX' directories are several
|
||||||
EDAC control and attribute files.
|
EDAC control and attribute files.
|
||||||
|
|
||||||
|
|
||||||
============================================================================
|
|
||||||
DIRECTORY 'mc'
|
|
||||||
|
|
||||||
In directory 'mc' are EDAC system overall control and attribute files:
|
|
||||||
|
|
||||||
|
|
||||||
Panic on UE control file:
|
|
||||||
|
|
||||||
'edac_mc_panic_on_ue'
|
|
||||||
|
|
||||||
An uncorrectable error will cause a machine panic. This is usually
|
|
||||||
desirable. It is a bad idea to continue when an uncorrectable error
|
|
||||||
occurs - it is indeterminate what was uncorrected and the operating
|
|
||||||
system context might be so mangled that continuing will lead to further
|
|
||||||
corruption. If the kernel has MCE configured, then EDAC will never
|
|
||||||
notice the UE.
|
|
||||||
|
|
||||||
LOAD TIME: module/kernel parameter: panic_on_ue=[0|1]
|
|
||||||
|
|
||||||
RUN TIME: echo "1" >/sys/devices/system/edac/mc/edac_mc_panic_on_ue
|
|
||||||
|
|
||||||
|
|
||||||
Log UE control file:
|
|
||||||
|
|
||||||
'edac_mc_log_ue'
|
|
||||||
|
|
||||||
Generate kernel messages describing uncorrectable errors. These errors
|
|
||||||
are reported through the system message log system. UE statistics
|
|
||||||
will be accumulated even when UE logging is disabled.
|
|
||||||
|
|
||||||
LOAD TIME: module/kernel parameter: log_ue=[0|1]
|
|
||||||
|
|
||||||
RUN TIME: echo "1" >/sys/devices/system/edac/mc/edac_mc_log_ue
|
|
||||||
|
|
||||||
|
|
||||||
Log CE control file:
|
|
||||||
|
|
||||||
'edac_mc_log_ce'
|
|
||||||
|
|
||||||
Generate kernel messages describing correctable errors. These
|
|
||||||
errors are reported through the system message log system.
|
|
||||||
CE statistics will be accumulated even when CE logging is disabled.
|
|
||||||
|
|
||||||
LOAD TIME: module/kernel parameter: log_ce=[0|1]
|
|
||||||
|
|
||||||
RUN TIME: echo "1" >/sys/devices/system/edac/mc/edac_mc_log_ce
|
|
||||||
|
|
||||||
|
|
||||||
Polling period control file:
|
|
||||||
|
|
||||||
'edac_mc_poll_msec'
|
|
||||||
|
|
||||||
The time period, in milliseconds, for polling for error information.
|
|
||||||
Too small a value wastes resources. Too large a value might delay
|
|
||||||
necessary handling of errors and might loose valuable information for
|
|
||||||
locating the error. 1000 milliseconds (once each second) is the current
|
|
||||||
default. Systems which require all the bandwidth they can get, may
|
|
||||||
increase this.
|
|
||||||
|
|
||||||
LOAD TIME: module/kernel parameter: poll_msec=[0|1]
|
|
||||||
|
|
||||||
RUN TIME: echo "1000" >/sys/devices/system/edac/mc/edac_mc_poll_msec
|
|
||||||
|
|
||||||
|
|
||||||
============================================================================
|
============================================================================
|
||||||
'mcX' DIRECTORIES
|
'mcX' DIRECTORIES
|
||||||
|
|
||||||
|
@ -392,7 +327,7 @@ Sdram memory scrubbing rate:
|
||||||
'sdram_scrub_rate'
|
'sdram_scrub_rate'
|
||||||
|
|
||||||
Read/Write attribute file that controls memory scrubbing. The scrubbing
|
Read/Write attribute file that controls memory scrubbing. The scrubbing
|
||||||
rate is set by writing a minimum bandwith in bytes/sec to the attribute
|
rate is set by writing a minimum bandwidth in bytes/sec to the attribute
|
||||||
file. The rate will be translated to an internal value that gives at
|
file. The rate will be translated to an internal value that gives at
|
||||||
least the specified rate.
|
least the specified rate.
|
||||||
|
|
||||||
|
@ -537,7 +472,6 @@ Channel 1 DIMM Label control file:
|
||||||
motherboard specific and determination of this information
|
motherboard specific and determination of this information
|
||||||
must occur in userland at this time.
|
must occur in userland at this time.
|
||||||
|
|
||||||
|
|
||||||
============================================================================
|
============================================================================
|
||||||
SYSTEM LOGGING
|
SYSTEM LOGGING
|
||||||
|
|
||||||
|
@ -570,7 +504,6 @@ error type, a notice of "no info" and then an optional,
|
||||||
driver-specific error message.
|
driver-specific error message.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
============================================================================
|
============================================================================
|
||||||
PCI Bus Parity Detection
|
PCI Bus Parity Detection
|
||||||
|
|
||||||
|
@ -604,6 +537,74 @@ Enable/Disable PCI Parity checking control file:
|
||||||
echo "0" >/sys/devices/system/edac/pci/check_pci_parity
|
echo "0" >/sys/devices/system/edac/pci/check_pci_parity
|
||||||
|
|
||||||
|
|
||||||
|
Parity Count:
|
||||||
|
|
||||||
|
'pci_parity_count'
|
||||||
|
|
||||||
|
This attribute file will display the number of parity errors that
|
||||||
|
have been detected.
|
||||||
|
|
||||||
|
|
||||||
|
============================================================================
|
||||||
|
MODULE PARAMETERS
|
||||||
|
|
||||||
|
Panic on UE control file:
|
||||||
|
|
||||||
|
'edac_mc_panic_on_ue'
|
||||||
|
|
||||||
|
An uncorrectable error will cause a machine panic. This is usually
|
||||||
|
desirable. It is a bad idea to continue when an uncorrectable error
|
||||||
|
occurs - it is indeterminate what was uncorrected and the operating
|
||||||
|
system context might be so mangled that continuing will lead to further
|
||||||
|
corruption. If the kernel has MCE configured, then EDAC will never
|
||||||
|
notice the UE.
|
||||||
|
|
||||||
|
LOAD TIME: module/kernel parameter: edac_mc_panic_on_ue=[0|1]
|
||||||
|
|
||||||
|
RUN TIME: echo "1" > /sys/module/edac_core/parameters/edac_mc_panic_on_ue
|
||||||
|
|
||||||
|
|
||||||
|
Log UE control file:
|
||||||
|
|
||||||
|
'edac_mc_log_ue'
|
||||||
|
|
||||||
|
Generate kernel messages describing uncorrectable errors. These errors
|
||||||
|
are reported through the system message log system. UE statistics
|
||||||
|
will be accumulated even when UE logging is disabled.
|
||||||
|
|
||||||
|
LOAD TIME: module/kernel parameter: edac_mc_log_ue=[0|1]
|
||||||
|
|
||||||
|
RUN TIME: echo "1" > /sys/module/edac_core/parameters/edac_mc_log_ue
|
||||||
|
|
||||||
|
|
||||||
|
Log CE control file:
|
||||||
|
|
||||||
|
'edac_mc_log_ce'
|
||||||
|
|
||||||
|
Generate kernel messages describing correctable errors. These
|
||||||
|
errors are reported through the system message log system.
|
||||||
|
CE statistics will be accumulated even when CE logging is disabled.
|
||||||
|
|
||||||
|
LOAD TIME: module/kernel parameter: edac_mc_log_ce=[0|1]
|
||||||
|
|
||||||
|
RUN TIME: echo "1" > /sys/module/edac_core/parameters/edac_mc_log_ce
|
||||||
|
|
||||||
|
|
||||||
|
Polling period control file:
|
||||||
|
|
||||||
|
'edac_mc_poll_msec'
|
||||||
|
|
||||||
|
The time period, in milliseconds, for polling for error information.
|
||||||
|
Too small a value wastes resources. Too large a value might delay
|
||||||
|
necessary handling of errors and might loose valuable information for
|
||||||
|
locating the error. 1000 milliseconds (once each second) is the current
|
||||||
|
default. Systems which require all the bandwidth they can get, may
|
||||||
|
increase this.
|
||||||
|
|
||||||
|
LOAD TIME: module/kernel parameter: edac_mc_poll_msec=[0|1]
|
||||||
|
|
||||||
|
RUN TIME: echo "1000" > /sys/module/edac_core/parameters/edac_mc_poll_msec
|
||||||
|
|
||||||
|
|
||||||
Panic on PCI PARITY Error:
|
Panic on PCI PARITY Error:
|
||||||
|
|
||||||
|
@ -614,21 +615,13 @@ Panic on PCI PARITY Error:
|
||||||
error has been detected.
|
error has been detected.
|
||||||
|
|
||||||
|
|
||||||
module/kernel parameter: panic_on_pci_parity=[0|1]
|
module/kernel parameter: edac_panic_on_pci_pe=[0|1]
|
||||||
|
|
||||||
Enable:
|
Enable:
|
||||||
echo "1" >/sys/devices/system/edac/pci/panic_on_pci_parity
|
echo "1" > /sys/module/edac_core/parameters/edac_panic_on_pci_pe
|
||||||
|
|
||||||
Disable:
|
Disable:
|
||||||
echo "0" >/sys/devices/system/edac/pci/panic_on_pci_parity
|
echo "0" > /sys/module/edac_core/parameters/edac_panic_on_pci_pe
|
||||||
|
|
||||||
|
|
||||||
Parity Count:
|
|
||||||
|
|
||||||
'pci_parity_count'
|
|
||||||
|
|
||||||
This attribute file will display the number of parity errors that
|
|
||||||
have been detected.
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
131
Documentation/fb/sh7760fb.txt
Normal file
131
Documentation/fb/sh7760fb.txt
Normal file
|
@ -0,0 +1,131 @@
|
||||||
|
SH7760/SH7763 integrated LCDC Framebuffer driver
|
||||||
|
================================================
|
||||||
|
|
||||||
|
0. Overwiew
|
||||||
|
-----------
|
||||||
|
The SH7760/SH7763 have an integrated LCD Display controller (LCDC) which
|
||||||
|
supports (in theory) resolutions ranging from 1x1 to 1024x1024,
|
||||||
|
with color depths ranging from 1 to 16 bits, on STN, DSTN and TFT Panels.
|
||||||
|
|
||||||
|
Caveats:
|
||||||
|
* Framebuffer memory must be a large chunk allocated at the top
|
||||||
|
of Area3 (HW requirement). Because of this requirement you should NOT
|
||||||
|
make the driver a module since at runtime it may become impossible to
|
||||||
|
get a large enough contiguous chunk of memory.
|
||||||
|
|
||||||
|
* The driver does not support changing resolution while loaded
|
||||||
|
(displays aren't hotpluggable anyway)
|
||||||
|
|
||||||
|
* Heavy flickering may be observed
|
||||||
|
a) if you're using 15/16bit color modes at >= 640x480 px resolutions,
|
||||||
|
b) during PCMCIA (or any other slow bus) activity.
|
||||||
|
|
||||||
|
* Rotation works only 90degress clockwise, and only if horizontal
|
||||||
|
resolution is <= 320 pixels.
|
||||||
|
|
||||||
|
files: drivers/video/sh7760fb.c
|
||||||
|
include/asm-sh/sh7760fb.h
|
||||||
|
Documentation/fb/sh7760fb.txt
|
||||||
|
|
||||||
|
1. Platform setup
|
||||||
|
-----------------
|
||||||
|
SH7760:
|
||||||
|
Video data is fetched via the DMABRG DMA engine, so you have to
|
||||||
|
configure the SH DMAC for DMABRG mode (write 0x94808080 to the
|
||||||
|
DMARSRA register somewhere at boot).
|
||||||
|
|
||||||
|
PFC registers PCCR and PCDR must be set to peripheral mode.
|
||||||
|
(write zeros to both).
|
||||||
|
|
||||||
|
The driver does NOT do the above for you since board setup is, well, job
|
||||||
|
of the board setup code.
|
||||||
|
|
||||||
|
2. Panel definitions
|
||||||
|
--------------------
|
||||||
|
The LCDC must explicitly be told about the type of LCD panel
|
||||||
|
attached. Data must be wrapped in a "struct sh7760fb_platdata" and
|
||||||
|
passed to the driver as platform_data.
|
||||||
|
|
||||||
|
Suggest you take a closer look at the SH7760 Manual, Section 30.
|
||||||
|
(http://documentation.renesas.com/eng/products/mpumcu/e602291_sh7760.pdf)
|
||||||
|
|
||||||
|
The following code illustrates what needs to be done to
|
||||||
|
get the framebuffer working on a 640x480 TFT:
|
||||||
|
|
||||||
|
====================== cut here ======================================
|
||||||
|
|
||||||
|
#include <linux/fb.h>
|
||||||
|
#include <asm/sh7760fb.h>
|
||||||
|
|
||||||
|
/*
|
||||||
|
* NEC NL6440bc26-01 640x480 TFT
|
||||||
|
* dotclock 25175 kHz
|
||||||
|
* Xres 640 Yres 480
|
||||||
|
* Htotal 800 Vtotal 525
|
||||||
|
* HsynStart 656 VsynStart 490
|
||||||
|
* HsynLenn 30 VsynLenn 2
|
||||||
|
*
|
||||||
|
* The linux framebuffer layer does not use the syncstart/synclen
|
||||||
|
* values but right/left/upper/lower margin values. The comments
|
||||||
|
* for the x_margin explain how to calculate those from given
|
||||||
|
* panel sync timings.
|
||||||
|
*/
|
||||||
|
static struct fb_videomode nl6448bc26 = {
|
||||||
|
.name = "NL6448BC26",
|
||||||
|
.refresh = 60,
|
||||||
|
.xres = 640,
|
||||||
|
.yres = 480,
|
||||||
|
.pixclock = 39683, /* in picoseconds! */
|
||||||
|
.hsync_len = 30,
|
||||||
|
.vsync_len = 2,
|
||||||
|
.left_margin = 114, /* HTOT - (HSYNSLEN + HSYNSTART) */
|
||||||
|
.right_margin = 16, /* HSYNSTART - XRES */
|
||||||
|
.upper_margin = 33, /* VTOT - (VSYNLEN + VSYNSTART) */
|
||||||
|
.lower_margin = 10, /* VSYNSTART - YRES */
|
||||||
|
.sync = FB_SYNC_HOR_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT,
|
||||||
|
.vmode = FB_VMODE_NONINTERLACED,
|
||||||
|
.flag = 0,
|
||||||
|
};
|
||||||
|
|
||||||
|
static struct sh7760fb_platdata sh7760fb_nl6448 = {
|
||||||
|
.def_mode = &nl6448bc26,
|
||||||
|
.ldmtr = LDMTR_TFT_COLOR_16, /* 16bit TFT panel */
|
||||||
|
.lddfr = LDDFR_8BPP, /* we want 8bit output */
|
||||||
|
.ldpmmr = 0x0070,
|
||||||
|
.ldpspr = 0x0500,
|
||||||
|
.ldaclnr = 0,
|
||||||
|
.ldickr = LDICKR_CLKSRC(LCDC_CLKSRC_EXTERNAL) |
|
||||||
|
LDICKR_CLKDIV(1),
|
||||||
|
.rotate = 0,
|
||||||
|
.novsync = 1,
|
||||||
|
.blank = NULL,
|
||||||
|
};
|
||||||
|
|
||||||
|
/* SH7760:
|
||||||
|
* 0xFE300800: 256 * 4byte xRGB palette ram
|
||||||
|
* 0xFE300C00: 42 bytes ctrl registers
|
||||||
|
*/
|
||||||
|
static struct resource sh7760_lcdc_res[] = {
|
||||||
|
[0] = {
|
||||||
|
.start = 0xFE300800,
|
||||||
|
.end = 0xFE300CFF,
|
||||||
|
.flags = IORESOURCE_MEM,
|
||||||
|
},
|
||||||
|
[1] = {
|
||||||
|
.start = 65,
|
||||||
|
.end = 65,
|
||||||
|
.flags = IORESOURCE_IRQ,
|
||||||
|
},
|
||||||
|
};
|
||||||
|
|
||||||
|
static struct platform_device sh7760_lcdc_dev = {
|
||||||
|
.dev = {
|
||||||
|
.platform_data = &sh7760fb_nl6448,
|
||||||
|
},
|
||||||
|
.name = "sh7760-lcdc",
|
||||||
|
.id = -1,
|
||||||
|
.resource = sh7760_lcdc_res,
|
||||||
|
.num_resources = ARRAY_SIZE(sh7760_lcdc_res),
|
||||||
|
};
|
||||||
|
|
||||||
|
====================== cut here ======================================
|
|
@ -3,11 +3,25 @@ Tridentfb is a framebuffer driver for some Trident chip based cards.
|
||||||
The following list of chips is thought to be supported although not all are
|
The following list of chips is thought to be supported although not all are
|
||||||
tested:
|
tested:
|
||||||
|
|
||||||
those from the Image series with Cyber in their names - accelerated
|
those from the TGUI series 9440/96XX and with Cyber in their names
|
||||||
those with Blade in their names (Blade3D,CyberBlade...) - accelerated
|
those from the Image series and with Cyber in their names
|
||||||
the newer CyberBladeXP family - nonaccelerated
|
those with Blade in their names (Blade3D,CyberBlade...)
|
||||||
|
the newer CyberBladeXP family
|
||||||
|
|
||||||
Only PCI/AGP based cards are supported, none of the older Tridents.
|
All families are accelerated. Only PCI/AGP based cards are supported,
|
||||||
|
none of the older Tridents.
|
||||||
|
The driver supports 8, 16 and 32 bits per pixel depths.
|
||||||
|
The TGUI family requires a line length to be power of 2 if acceleration
|
||||||
|
is enabled. This means that range of possible resolutions and bpp is
|
||||||
|
limited comparing to the range if acceleration is disabled (see list
|
||||||
|
of parameters below).
|
||||||
|
|
||||||
|
Known bugs:
|
||||||
|
1. The driver randomly locks up on 3DImage975 chip with acceleration
|
||||||
|
enabled. The same happens in X11 (Xorg).
|
||||||
|
2. The ramdac speeds require some more fine tuning. It is possible to
|
||||||
|
switch resolution which the chip does not support at some depths for
|
||||||
|
older chips.
|
||||||
|
|
||||||
How to use it?
|
How to use it?
|
||||||
==============
|
==============
|
||||||
|
@ -17,12 +31,11 @@ video=tridentfb
|
||||||
|
|
||||||
The parameters for tridentfb are concatenated with a ':' as in this example.
|
The parameters for tridentfb are concatenated with a ':' as in this example.
|
||||||
|
|
||||||
video=tridentfb:800x600,bpp=16,noaccel
|
video=tridentfb:800x600-16@75,noaccel
|
||||||
|
|
||||||
The second level parameters that tridentfb understands are:
|
The second level parameters that tridentfb understands are:
|
||||||
|
|
||||||
noaccel - turns off acceleration (when it doesn't work for your card)
|
noaccel - turns off acceleration (when it doesn't work for your card)
|
||||||
accel - force text acceleration (for boards which by default are noacceled)
|
|
||||||
|
|
||||||
fp - use flat panel related stuff
|
fp - use flat panel related stuff
|
||||||
crt - assume monitor is present instead of fp
|
crt - assume monitor is present instead of fp
|
||||||
|
@ -31,21 +44,24 @@ center - for flat panels and resolutions smaller than native size center the
|
||||||
image, otherwise use
|
image, otherwise use
|
||||||
stretch
|
stretch
|
||||||
|
|
||||||
memsize - integer value in Kb, use if your card's memory size is misdetected.
|
memsize - integer value in KB, use if your card's memory size is misdetected.
|
||||||
look at the driver output to see what it says when initializing.
|
look at the driver output to see what it says when initializing.
|
||||||
memdiff - integer value in Kb,should be nonzero if your card reports
|
|
||||||
more memory than it actually has.For instance mine is 192K less than
|
memdiff - integer value in KB, should be nonzero if your card reports
|
||||||
|
more memory than it actually has. For instance mine is 192K less than
|
||||||
detection says in all three BIOS selectable situations 2M, 4M, 8M.
|
detection says in all three BIOS selectable situations 2M, 4M, 8M.
|
||||||
Only use if your video memory is taken from main memory hence of
|
Only use if your video memory is taken from main memory hence of
|
||||||
configurable size.Otherwise use memsize.
|
configurable size. Otherwise use memsize.
|
||||||
If in some modes which barely fit the memory you see garbage at the bottom
|
If in some modes which barely fit the memory you see garbage
|
||||||
this might help by not letting change to that mode anymore.
|
at the bottom this might help by not letting change to that mode
|
||||||
|
anymore.
|
||||||
|
|
||||||
nativex - the width in pixels of the flat panel.If you know it (usually 1024
|
nativex - the width in pixels of the flat panel.If you know it (usually 1024
|
||||||
800 or 1280) and it is not what the driver seems to detect use it.
|
800 or 1280) and it is not what the driver seems to detect use it.
|
||||||
|
|
||||||
bpp - bits per pixel (8,16 or 32)
|
bpp - bits per pixel (8,16 or 32)
|
||||||
mode - a mode name like 800x600 (as described in Documentation/fb/modedb.txt)
|
mode - a mode name like 800x600-8@75 as described in
|
||||||
|
Documentation/fb/modedb.txt
|
||||||
|
|
||||||
Using insane values for the above parameters will probably result in driver
|
Using insane values for the above parameters will probably result in driver
|
||||||
misbehaviour so take care(for instance memsize=12345678 or memdiff=23784 or
|
misbehaviour so take care(for instance memsize=12345678 or memdiff=23784 or
|
||||||
|
|
|
@ -47,6 +47,30 @@ Who: Mauro Carvalho Chehab <mchehab@infradead.org>
|
||||||
|
|
||||||
---------------------------
|
---------------------------
|
||||||
|
|
||||||
|
What: old tuner-3036 i2c driver
|
||||||
|
When: 2.6.28
|
||||||
|
Why: This driver is for VERY old i2c-over-parallel port teletext receiver
|
||||||
|
boxes. Rather then spending effort on converting this driver to V4L2,
|
||||||
|
and since it is extremely unlikely that anyone still uses one of these
|
||||||
|
devices, it was decided to drop it.
|
||||||
|
Who: Hans Verkuil <hverkuil@xs4all.nl>
|
||||||
|
Mauro Carvalho Chehab <mchehab@infradead.org>
|
||||||
|
|
||||||
|
---------------------------
|
||||||
|
|
||||||
|
What: V4L2 dpc7146 driver
|
||||||
|
When: 2.6.28
|
||||||
|
Why: Old driver for the dpc7146 demonstration board that is no longer
|
||||||
|
relevant. The last time this was tested on actual hardware was
|
||||||
|
probably around 2002. Since this is a driver for a demonstration
|
||||||
|
board the decision was made to remove it rather than spending a
|
||||||
|
lot of effort continually updating this driver to stay in sync
|
||||||
|
with the latest internal V4L2 or I2C API.
|
||||||
|
Who: Hans Verkuil <hverkuil@xs4all.nl>
|
||||||
|
Mauro Carvalho Chehab <mchehab@infradead.org>
|
||||||
|
|
||||||
|
---------------------------
|
||||||
|
|
||||||
What: PCMCIA control ioctl (needed for pcmcia-cs [cardmgr, cardctl])
|
What: PCMCIA control ioctl (needed for pcmcia-cs [cardmgr, cardctl])
|
||||||
When: November 2005
|
When: November 2005
|
||||||
Files: drivers/pcmcia/: pcmcia_ioctl.c
|
Files: drivers/pcmcia/: pcmcia_ioctl.c
|
||||||
|
@ -138,24 +162,6 @@ Who: Kay Sievers <kay.sievers@suse.de>
|
||||||
|
|
||||||
---------------------------
|
---------------------------
|
||||||
|
|
||||||
What: find_task_by_pid
|
|
||||||
When: 2.6.26
|
|
||||||
Why: With pid namespaces, calling this funciton will return the
|
|
||||||
wrong task when called from inside a namespace.
|
|
||||||
|
|
||||||
The best way to save a task pid and find a task by this
|
|
||||||
pid later, is to find this task's struct pid pointer (or get
|
|
||||||
it directly from the task) and call pid_task() later.
|
|
||||||
|
|
||||||
If someone really needs to get a task by its pid_t, then
|
|
||||||
he most likely needs the find_task_by_vpid() to get the
|
|
||||||
task from the same namespace as the current task is in, but
|
|
||||||
this may be not so in general.
|
|
||||||
|
|
||||||
Who: Pavel Emelyanov <xemul@openvz.org>
|
|
||||||
|
|
||||||
---------------------------
|
|
||||||
|
|
||||||
What: ACPI procfs interface
|
What: ACPI procfs interface
|
||||||
When: July 2008
|
When: July 2008
|
||||||
Why: ACPI sysfs conversion should be finished by January 2008.
|
Why: ACPI sysfs conversion should be finished by January 2008.
|
||||||
|
@ -300,14 +306,6 @@ Who: ocfs2-devel@oss.oracle.com
|
||||||
|
|
||||||
---------------------------
|
---------------------------
|
||||||
|
|
||||||
What: asm/semaphore.h
|
|
||||||
When: 2.6.26
|
|
||||||
Why: Implementation became generic; users should now include
|
|
||||||
linux/semaphore.h instead.
|
|
||||||
Who: Matthew Wilcox <willy@linux.intel.com>
|
|
||||||
|
|
||||||
---------------------------
|
|
||||||
|
|
||||||
What: SCTP_GET_PEER_ADDRS_NUM_OLD, SCTP_GET_PEER_ADDRS_OLD,
|
What: SCTP_GET_PEER_ADDRS_NUM_OLD, SCTP_GET_PEER_ADDRS_OLD,
|
||||||
SCTP_GET_LOCAL_ADDRS_NUM_OLD, SCTP_GET_LOCAL_ADDRS_OLD
|
SCTP_GET_LOCAL_ADDRS_NUM_OLD, SCTP_GET_LOCAL_ADDRS_OLD
|
||||||
When: June 2009
|
When: June 2009
|
||||||
|
@ -336,3 +334,13 @@ When: After the only user (hal) has seen a release with the patches
|
||||||
Why: Over 1K .text/.data size reduction, data is available in other
|
Why: Over 1K .text/.data size reduction, data is available in other
|
||||||
ways (ioctls)
|
ways (ioctls)
|
||||||
Who: Johannes Berg <johannes@sipsolutions.net>
|
Who: Johannes Berg <johannes@sipsolutions.net>
|
||||||
|
|
||||||
|
---------------------------
|
||||||
|
|
||||||
|
What: CONFIG_NF_CT_ACCT
|
||||||
|
When: 2.6.29
|
||||||
|
Why: Accounting can now be enabled/disabled without kernel recompilation.
|
||||||
|
Currently used only to set a default value for a feature that is also
|
||||||
|
controlled by a kernel/module/sysfs/sysctl parameter.
|
||||||
|
Who: Krzysztof Piotr Oledzki <ole@ans.pl>
|
||||||
|
|
||||||
|
|
|
@ -510,6 +510,7 @@ prototypes:
|
||||||
void (*close)(struct vm_area_struct*);
|
void (*close)(struct vm_area_struct*);
|
||||||
int (*fault)(struct vm_area_struct*, struct vm_fault *);
|
int (*fault)(struct vm_area_struct*, struct vm_fault *);
|
||||||
int (*page_mkwrite)(struct vm_area_struct *, struct page *);
|
int (*page_mkwrite)(struct vm_area_struct *, struct page *);
|
||||||
|
int (*access)(struct vm_area_struct *, unsigned long, void*, int, int);
|
||||||
|
|
||||||
locking rules:
|
locking rules:
|
||||||
BKL mmap_sem PageLocked(page)
|
BKL mmap_sem PageLocked(page)
|
||||||
|
@ -517,6 +518,7 @@ open: no yes
|
||||||
close: no yes
|
close: no yes
|
||||||
fault: no yes
|
fault: no yes
|
||||||
page_mkwrite: no yes no
|
page_mkwrite: no yes no
|
||||||
|
access: no yes
|
||||||
|
|
||||||
->page_mkwrite() is called when a previously read-only page is
|
->page_mkwrite() is called when a previously read-only page is
|
||||||
about to become writeable. The file system is responsible for
|
about 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
|
||||||
within i_size. The page mapping should also be checked that it is not
|
within i_size. The page mapping should also be checked that it is not
|
||||||
NULL.
|
NULL.
|
||||||
|
|
||||||
|
->access() is called when get_user_pages() fails in
|
||||||
|
acces_process_vm(), typically used to debug a process through
|
||||||
|
/proc/pid/mem or ptrace. This function is needed only for
|
||||||
|
VM_IO | VM_PFNMAP VMAs.
|
||||||
|
|
||||||
================================================================================
|
================================================================================
|
||||||
Dubious stuff
|
Dubious stuff
|
||||||
|
|
||||||
|
|
|
@ -26,11 +26,11 @@ You can simplify mounting by just typing:
|
||||||
|
|
||||||
this will allocate the first available loopback device (and load loop.o
|
this will allocate the first available loopback device (and load loop.o
|
||||||
kernel module if necessary) automatically. If the loopback driver is not
|
kernel module if necessary) automatically. If the loopback driver is not
|
||||||
loaded automatically, make sure that your kernel is compiled with kmod
|
loaded automatically, make sure that you have compiled the module and
|
||||||
support (CONFIG_KMOD) enabled. Beware that umount will not
|
that modprobe is functioning. Beware that umount will not deallocate
|
||||||
deallocate /dev/loopN device if /etc/mtab file on your system is a
|
/dev/loopN device if /etc/mtab file on your system is a symbolic link to
|
||||||
symbolic link to /proc/mounts. You will need to do it manually using
|
/proc/mounts. You will need to do it manually using "-d" switch of
|
||||||
"-d" switch of losetup(8). Read losetup(8) manpage for more info.
|
losetup(8). Read losetup(8) manpage for more info.
|
||||||
|
|
||||||
To create the BFS image under UnixWare you need to find out first which
|
To create the BFS image under UnixWare you need to find out first which
|
||||||
slice contains it. The command prtvtoc(1M) is your friend:
|
slice contains it. The command prtvtoc(1M) is your friend:
|
||||||
|
|
106
Documentation/filesystems/omfs.txt
Normal file
106
Documentation/filesystems/omfs.txt
Normal file
|
@ -0,0 +1,106 @@
|
||||||
|
Optimized MPEG Filesystem (OMFS)
|
||||||
|
|
||||||
|
Overview
|
||||||
|
========
|
||||||
|
|
||||||
|
OMFS is a filesystem created by SonicBlue for use in the ReplayTV DVR
|
||||||
|
and Rio Karma MP3 player. The filesystem is extent-based, utilizing
|
||||||
|
block sizes from 2k to 8k, with hash-based directories. This
|
||||||
|
filesystem driver may be used to read and write disks from these
|
||||||
|
devices.
|
||||||
|
|
||||||
|
Note, it is not recommended that this FS be used in place of a general
|
||||||
|
filesystem for your own streaming media device. Native Linux filesystems
|
||||||
|
will likely perform better.
|
||||||
|
|
||||||
|
More information is available at:
|
||||||
|
|
||||||
|
http://linux-karma.sf.net/
|
||||||
|
|
||||||
|
Various utilities, including mkomfs and omfsck, are included with
|
||||||
|
omfsprogs, available at:
|
||||||
|
|
||||||
|
http://bobcopeland.com/karma/
|
||||||
|
|
||||||
|
Instructions are included in its README.
|
||||||
|
|
||||||
|
Options
|
||||||
|
=======
|
||||||
|
|
||||||
|
OMFS supports the following mount-time options:
|
||||||
|
|
||||||
|
uid=n - make all files owned by specified user
|
||||||
|
gid=n - make all files owned by specified group
|
||||||
|
umask=xxx - set permission umask to xxx
|
||||||
|
fmask=xxx - set umask to xxx for files
|
||||||
|
dmask=xxx - set umask to xxx for directories
|
||||||
|
|
||||||
|
Disk format
|
||||||
|
===========
|
||||||
|
|
||||||
|
OMFS discriminates between "sysblocks" and normal data blocks. The sysblock
|
||||||
|
group consists of super block information, file metadata, directory structures,
|
||||||
|
and extents. Each sysblock has a header containing CRCs of the entire
|
||||||
|
sysblock, and may be mirrored in successive blocks on the disk. A sysblock may
|
||||||
|
have a smaller size than a data block, but since they are both addressed by the
|
||||||
|
same 64-bit block number, any remaining space in the smaller sysblock is
|
||||||
|
unused.
|
||||||
|
|
||||||
|
Sysblock header information:
|
||||||
|
|
||||||
|
struct omfs_header {
|
||||||
|
__be64 h_self; /* FS block where this is located */
|
||||||
|
__be32 h_body_size; /* size of useful data after header */
|
||||||
|
__be16 h_crc; /* crc-ccitt of body_size bytes */
|
||||||
|
char h_fill1[2];
|
||||||
|
u8 h_version; /* version, always 1 */
|
||||||
|
char h_type; /* OMFS_INODE_X */
|
||||||
|
u8 h_magic; /* OMFS_IMAGIC */
|
||||||
|
u8 h_check_xor; /* XOR of header bytes before this */
|
||||||
|
__be32 h_fill2;
|
||||||
|
};
|
||||||
|
|
||||||
|
Files and directories are both represented by omfs_inode:
|
||||||
|
|
||||||
|
struct omfs_inode {
|
||||||
|
struct omfs_header i_head; /* header */
|
||||||
|
__be64 i_parent; /* parent containing this inode */
|
||||||
|
__be64 i_sibling; /* next inode in hash bucket */
|
||||||
|
__be64 i_ctime; /* ctime, in milliseconds */
|
||||||
|
char i_fill1[35];
|
||||||
|
char i_type; /* OMFS_[DIR,FILE] */
|
||||||
|
__be32 i_fill2;
|
||||||
|
char i_fill3[64];
|
||||||
|
char i_name[OMFS_NAMELEN]; /* filename */
|
||||||
|
__be64 i_size; /* size of file, in bytes */
|
||||||
|
};
|
||||||
|
|
||||||
|
Directories in OMFS are implemented as a large hash table. Filenames are
|
||||||
|
hashed then prepended into the bucket list beginning at OMFS_DIR_START.
|
||||||
|
Lookup requires hashing the filename, then seeking across i_sibling pointers
|
||||||
|
until a match is found on i_name. Empty buckets are represented by block
|
||||||
|
pointers with all-1s (~0).
|
||||||
|
|
||||||
|
A file is an omfs_inode structure followed by an extent table beginning at
|
||||||
|
OMFS_EXTENT_START:
|
||||||
|
|
||||||
|
struct omfs_extent_entry {
|
||||||
|
__be64 e_cluster; /* start location of a set of blocks */
|
||||||
|
__be64 e_blocks; /* number of blocks after e_cluster */
|
||||||
|
};
|
||||||
|
|
||||||
|
struct omfs_extent {
|
||||||
|
__be64 e_next; /* next extent table location */
|
||||||
|
__be32 e_extent_count; /* total # extents in this table */
|
||||||
|
__be32 e_fill;
|
||||||
|
struct omfs_extent_entry e_entry; /* start of extent entries */
|
||||||
|
};
|
||||||
|
|
||||||
|
Each extent holds the block offset followed by number of blocks allocated to
|
||||||
|
the extent. The final extent in each table is a terminator with e_cluster
|
||||||
|
being ~0 and e_blocks being ones'-complement of the total number of blocks
|
||||||
|
in the table.
|
||||||
|
|
||||||
|
If this table overflows, a continuation inode is written and pointed to by
|
||||||
|
e_next. These have a header but lack the rest of the inode structure.
|
||||||
|
|
|
@ -296,6 +296,7 @@ Table 1-4: Kernel info in /proc
|
||||||
uptime System uptime
|
uptime System uptime
|
||||||
version Kernel version
|
version Kernel version
|
||||||
video bttv info of video resources (2.4)
|
video bttv info of video resources (2.4)
|
||||||
|
vmallocinfo Show vmalloced areas
|
||||||
..............................................................................
|
..............................................................................
|
||||||
|
|
||||||
You can, for example, check which interrupts are currently in use and what
|
You can, for example, check which interrupts are currently in use and what
|
||||||
|
@ -557,6 +558,49 @@ VmallocTotal: total size of vmalloc memory area
|
||||||
VmallocUsed: amount of vmalloc area which is used
|
VmallocUsed: amount of vmalloc area which is used
|
||||||
VmallocChunk: largest contigious block of vmalloc area which is free
|
VmallocChunk: largest contigious block of vmalloc area which is free
|
||||||
|
|
||||||
|
..............................................................................
|
||||||
|
|
||||||
|
vmallocinfo:
|
||||||
|
|
||||||
|
Provides information about vmalloced/vmaped areas. One line per area,
|
||||||
|
containing the virtual address range of the area, size in bytes,
|
||||||
|
caller information of the creator, and optional information depending
|
||||||
|
on the kind of area :
|
||||||
|
|
||||||
|
pages=nr number of pages
|
||||||
|
phys=addr if a physical address was specified
|
||||||
|
ioremap I/O mapping (ioremap() and friends)
|
||||||
|
vmalloc vmalloc() area
|
||||||
|
vmap vmap()ed pages
|
||||||
|
user VM_USERMAP area
|
||||||
|
vpages buffer for pages pointers was vmalloced (huge area)
|
||||||
|
N<node>=nr (Only on NUMA kernels)
|
||||||
|
Number of pages allocated on memory node <node>
|
||||||
|
|
||||||
|
> cat /proc/vmallocinfo
|
||||||
|
0xffffc20000000000-0xffffc20000201000 2101248 alloc_large_system_hash+0x204 ...
|
||||||
|
/0x2c0 pages=512 vmalloc N0=128 N1=128 N2=128 N3=128
|
||||||
|
0xffffc20000201000-0xffffc20000302000 1052672 alloc_large_system_hash+0x204 ...
|
||||||
|
/0x2c0 pages=256 vmalloc N0=64 N1=64 N2=64 N3=64
|
||||||
|
0xffffc20000302000-0xffffc20000304000 8192 acpi_tb_verify_table+0x21/0x4f...
|
||||||
|
phys=7fee8000 ioremap
|
||||||
|
0xffffc20000304000-0xffffc20000307000 12288 acpi_tb_verify_table+0x21/0x4f...
|
||||||
|
phys=7fee7000 ioremap
|
||||||
|
0xffffc2000031d000-0xffffc2000031f000 8192 init_vdso_vars+0x112/0x210
|
||||||
|
0xffffc2000031f000-0xffffc2000032b000 49152 cramfs_uncompress_init+0x2e ...
|
||||||
|
/0x80 pages=11 vmalloc N0=3 N1=3 N2=2 N3=3
|
||||||
|
0xffffc2000033a000-0xffffc2000033d000 12288 sys_swapon+0x640/0xac0 ...
|
||||||
|
pages=2 vmalloc N1=2
|
||||||
|
0xffffc20000347000-0xffffc2000034c000 20480 xt_alloc_table_info+0xfe ...
|
||||||
|
/0x130 [x_tables] pages=4 vmalloc N0=4
|
||||||
|
0xffffffffa0000000-0xffffffffa000f000 61440 sys_init_module+0xc27/0x1d00 ...
|
||||||
|
pages=14 vmalloc N2=14
|
||||||
|
0xffffffffa000f000-0xffffffffa0014000 20480 sys_init_module+0xc27/0x1d00 ...
|
||||||
|
pages=4 vmalloc N1=4
|
||||||
|
0xffffffffa0014000-0xffffffffa0017000 12288 sys_init_module+0xc27/0x1d00 ...
|
||||||
|
pages=2 vmalloc N1=2
|
||||||
|
0xffffffffa0017000-0xffffffffa0022000 45056 sys_init_module+0xc27/0x1d00 ...
|
||||||
|
pages=10 vmalloc N0=10
|
||||||
|
|
||||||
1.3 IDE devices in /proc/ide
|
1.3 IDE devices in /proc/ide
|
||||||
----------------------------
|
----------------------------
|
||||||
|
@ -887,7 +931,7 @@ group_prealloc max_to_scan mb_groups mb_history min_to_scan order2_req
|
||||||
stats stream_req
|
stats stream_req
|
||||||
|
|
||||||
mb_groups:
|
mb_groups:
|
||||||
This file gives the details of mutiblock allocator buddy cache of free blocks
|
This file gives the details of multiblock allocator buddy cache of free blocks
|
||||||
|
|
||||||
mb_history:
|
mb_history:
|
||||||
Multiblock allocation history.
|
Multiblock allocation history.
|
||||||
|
@ -1430,7 +1474,7 @@ used because pages_free(1355) is smaller than watermark + protection[2]
|
||||||
normal page requirement. If requirement is DMA zone(index=0), protection[0]
|
normal page requirement. If requirement is DMA zone(index=0), protection[0]
|
||||||
(=0) is used.
|
(=0) is used.
|
||||||
|
|
||||||
zone[i]'s protection[j] is calculated by following exprssion.
|
zone[i]'s protection[j] is calculated by following expression.
|
||||||
|
|
||||||
(i < j):
|
(i < j):
|
||||||
zone[i]->protection[j]
|
zone[i]->protection[j]
|
||||||
|
|
|
@ -294,6 +294,16 @@ user-defined data with a channel, and is immediately available
|
||||||
(including in create_buf_file()) via chan->private_data or
|
(including in create_buf_file()) via chan->private_data or
|
||||||
buf->chan->private_data.
|
buf->chan->private_data.
|
||||||
|
|
||||||
|
Buffer-only channels
|
||||||
|
--------------------
|
||||||
|
|
||||||
|
These channels have no files associated and can be created with
|
||||||
|
relay_open(NULL, NULL, ...). Such channels are useful in scenarios such
|
||||||
|
as when doing early tracing in the kernel, before the VFS is up. In these
|
||||||
|
cases, one may open a buffer-only channel and then call
|
||||||
|
relay_late_setup_files() when the kernel is ready to handle files,
|
||||||
|
to expose the buffered data to the userspace.
|
||||||
|
|
||||||
Channel 'modes'
|
Channel 'modes'
|
||||||
---------------
|
---------------
|
||||||
|
|
||||||
|
|
|
@ -248,6 +248,7 @@ The top level sysfs directory looks like:
|
||||||
block/
|
block/
|
||||||
bus/
|
bus/
|
||||||
class/
|
class/
|
||||||
|
dev/
|
||||||
devices/
|
devices/
|
||||||
firmware/
|
firmware/
|
||||||
net/
|
net/
|
||||||
|
@ -274,6 +275,11 @@ fs/ contains a directory for some filesystems. Currently each
|
||||||
filesystem wanting to export attributes must create its own hierarchy
|
filesystem wanting to export attributes must create its own hierarchy
|
||||||
below fs/ (see ./fuse.txt for an example).
|
below fs/ (see ./fuse.txt for an example).
|
||||||
|
|
||||||
|
dev/ contains two directories char/ and block/. Inside these two
|
||||||
|
directories there are symlinks named <major>:<minor>. These symlinks
|
||||||
|
point to the sysfs directory for the given device. /sys/dev provides a
|
||||||
|
quick way to lookup the sysfs interface for a device from the result of
|
||||||
|
a stat(2) operation.
|
||||||
|
|
||||||
More information can driver-model specific features can be found in
|
More information can driver-model specific features can be found in
|
||||||
Documentation/driver-model/.
|
Documentation/driver-model/.
|
||||||
|
|
|
@ -96,6 +96,14 @@ shortname=lower|win95|winnt|mixed
|
||||||
emulate the Windows 95 rule for create.
|
emulate the Windows 95 rule for create.
|
||||||
Default setting is `lower'.
|
Default setting is `lower'.
|
||||||
|
|
||||||
|
tz=UTC -- Interpret timestamps as UTC rather than local time.
|
||||||
|
This option disables the conversion of timestamps
|
||||||
|
between local time (as used by Windows on FAT) and UTC
|
||||||
|
(which Linux uses internally). This is particuluarly
|
||||||
|
useful when mounting devices (like digital cameras)
|
||||||
|
that are set to UTC in order to avoid the pitfalls of
|
||||||
|
local time.
|
||||||
|
|
||||||
<bool>: 0,1,yes,no,true,false
|
<bool>: 0,1,yes,no,true,false
|
||||||
|
|
||||||
TODO
|
TODO
|
||||||
|
|
|
@ -143,7 +143,7 @@ struct file_system_type {
|
||||||
|
|
||||||
The get_sb() method has the following arguments:
|
The get_sb() method has the following arguments:
|
||||||
|
|
||||||
struct file_system_type *fs_type: decribes the filesystem, partly initialized
|
struct file_system_type *fs_type: describes the filesystem, partly initialized
|
||||||
by the specific filesystem code
|
by the specific filesystem code
|
||||||
|
|
||||||
int flags: mount flags
|
int flags: mount flags
|
||||||
|
@ -895,9 +895,9 @@ struct dentry_operations {
|
||||||
iput() yourself
|
iput() yourself
|
||||||
|
|
||||||
d_dname: called when the pathname of a dentry should be generated.
|
d_dname: called when the pathname of a dentry should be generated.
|
||||||
Usefull for some pseudo filesystems (sockfs, pipefs, ...) to delay
|
Useful for some pseudo filesystems (sockfs, pipefs, ...) to delay
|
||||||
pathname generation. (Instead of doing it when dentry is created,
|
pathname generation. (Instead of doing it when dentry is created,
|
||||||
its done only when the path is needed.). Real filesystems probably
|
it's done only when the path is needed.). Real filesystems probably
|
||||||
dont want to use it, because their dentries are present in global
|
dont want to use it, because their dentries are present in global
|
||||||
dcache hash, so their hash should be an invariant. As no lock is
|
dcache hash, so their hash should be an invariant. As no lock is
|
||||||
held, d_dname() should not try to modify the dentry itself, unless
|
held, d_dname() should not try to modify the dentry itself, unless
|
||||||
|
|
|
@ -347,15 +347,12 @@ necessarily be nonportable.
|
||||||
Dynamic definition of GPIOs is not currently standard; for example, as
|
Dynamic definition of GPIOs is not currently standard; for example, as
|
||||||
a side effect of configuring an add-on board with some GPIO expanders.
|
a side effect of configuring an add-on board with some GPIO expanders.
|
||||||
|
|
||||||
These calls are purely for kernel space, but a userspace API could be built
|
|
||||||
on top of them.
|
|
||||||
|
|
||||||
|
|
||||||
GPIO implementor's framework (OPTIONAL)
|
GPIO implementor's framework (OPTIONAL)
|
||||||
=======================================
|
=======================================
|
||||||
As noted earlier, there is an optional implementation framework making it
|
As noted earlier, there is an optional implementation framework making it
|
||||||
easier for platforms to support different kinds of GPIO controller using
|
easier for platforms to support different kinds of GPIO controller using
|
||||||
the same programming interface.
|
the same programming interface. This framework is called "gpiolib".
|
||||||
|
|
||||||
As a debugging aid, if debugfs is available a /sys/kernel/debug/gpio file
|
As a debugging aid, if debugfs is available a /sys/kernel/debug/gpio file
|
||||||
will be found there. That will list all the controllers registered through
|
will be found there. That will list all the controllers registered through
|
||||||
|
@ -392,11 +389,21 @@ either NULL or the label associated with that GPIO when it was requested.
|
||||||
|
|
||||||
Platform Support
|
Platform Support
|
||||||
----------------
|
----------------
|
||||||
To support this framework, a platform's Kconfig will "select HAVE_GPIO_LIB"
|
To support this framework, a platform's Kconfig will "select" either
|
||||||
|
ARCH_REQUIRE_GPIOLIB or ARCH_WANT_OPTIONAL_GPIOLIB
|
||||||
and arrange that its <asm/gpio.h> includes <asm-generic/gpio.h> and defines
|
and arrange that its <asm/gpio.h> includes <asm-generic/gpio.h> and defines
|
||||||
three functions: gpio_get_value(), gpio_set_value(), and gpio_cansleep().
|
three functions: gpio_get_value(), gpio_set_value(), and gpio_cansleep().
|
||||||
They may also want to provide a custom value for ARCH_NR_GPIOS.
|
They may also want to provide a custom value for ARCH_NR_GPIOS.
|
||||||
|
|
||||||
|
ARCH_REQUIRE_GPIOLIB means that the gpio-lib code will always get compiled
|
||||||
|
into the kernel on that architecture.
|
||||||
|
|
||||||
|
ARCH_WANT_OPTIONAL_GPIOLIB means the gpio-lib code defaults to off and the user
|
||||||
|
can enable it and build it into the kernel optionally.
|
||||||
|
|
||||||
|
If neither of these options are selected, the platform does not support
|
||||||
|
GPIOs through GPIO-lib and the code cannot be enabled by the user.
|
||||||
|
|
||||||
Trivial implementations of those functions can directly use framework
|
Trivial implementations of those functions can directly use framework
|
||||||
code, which always dispatches through the gpio_chip:
|
code, which always dispatches through the gpio_chip:
|
||||||
|
|
||||||
|
@ -439,4 +446,120 @@ becomes available. That may mean the device should not be registered until
|
||||||
calls for that GPIO can work. One way to address such dependencies is for
|
calls for that GPIO can work. One way to address such dependencies is for
|
||||||
such gpio_chip controllers to provide setup() and teardown() callbacks to
|
such gpio_chip controllers to provide setup() and teardown() callbacks to
|
||||||
board specific code; those board specific callbacks would register devices
|
board specific code; those board specific callbacks would register devices
|
||||||
once all the necessary resources are available.
|
once all the necessary resources are available, and remove them later when
|
||||||
|
the GPIO controller device becomes unavailable.
|
||||||
|
|
||||||
|
|
||||||
|
Sysfs Interface for Userspace (OPTIONAL)
|
||||||
|
========================================
|
||||||
|
Platforms which use the "gpiolib" implementors framework may choose to
|
||||||
|
configure a sysfs user interface to GPIOs. This is different from the
|
||||||
|
debugfs interface, since it provides control over GPIO direction and
|
||||||
|
value instead of just showing a gpio state summary. Plus, it could be
|
||||||
|
present on production systems without debugging support.
|
||||||
|
|
||||||
|
Given approprate hardware documentation for the system, userspace could
|
||||||
|
know for example that GPIO #23 controls the write protect line used to
|
||||||
|
protect boot loader segments in flash memory. System upgrade procedures
|
||||||
|
may need to temporarily remove that protection, first importing a GPIO,
|
||||||
|
then changing its output state, then updating the code before re-enabling
|
||||||
|
the write protection. In normal use, GPIO #23 would never be touched,
|
||||||
|
and the kernel would have no need to know about it.
|
||||||
|
|
||||||
|
Again depending on appropriate hardware documentation, on some systems
|
||||||
|
userspace GPIO can be used to determine system configuration data that
|
||||||
|
standard kernels won't know about. And for some tasks, simple userspace
|
||||||
|
GPIO drivers could be all that the system really needs.
|
||||||
|
|
||||||
|
Note that standard kernel drivers exist for common "LEDs and Buttons"
|
||||||
|
GPIO tasks: "leds-gpio" and "gpio_keys", respectively. Use those
|
||||||
|
instead of talking directly to the GPIOs; they integrate with kernel
|
||||||
|
frameworks better than your userspace code could.
|
||||||
|
|
||||||
|
|
||||||
|
Paths in Sysfs
|
||||||
|
--------------
|
||||||
|
There are three kinds of entry in /sys/class/gpio:
|
||||||
|
|
||||||
|
- Control interfaces used to get userspace control over GPIOs;
|
||||||
|
|
||||||
|
- GPIOs themselves; and
|
||||||
|
|
||||||
|
- GPIO controllers ("gpio_chip" instances).
|
||||||
|
|
||||||
|
That's in addition to standard files including the "device" symlink.
|
||||||
|
|
||||||
|
The control interfaces are write-only:
|
||||||
|
|
||||||
|
/sys/class/gpio/
|
||||||
|
|
||||||
|
"export" ... Userspace may ask the kernel to export control of
|
||||||
|
a GPIO to userspace by writing its number to this file.
|
||||||
|
|
||||||
|
Example: "echo 19 > export" will create a "gpio19" node
|
||||||
|
for GPIO #19, if that's not requested by kernel code.
|
||||||
|
|
||||||
|
"unexport" ... Reverses the effect of exporting to userspace.
|
||||||
|
|
||||||
|
Example: "echo 19 > unexport" will remove a "gpio19"
|
||||||
|
node exported using the "export" file.
|
||||||
|
|
||||||
|
GPIO signals have paths like /sys/class/gpio/gpio42/ (for GPIO #42)
|
||||||
|
and have the following read/write attributes:
|
||||||
|
|
||||||
|
/sys/class/gpio/gpioN/
|
||||||
|
|
||||||
|
"direction" ... reads as either "in" or "out". This value may
|
||||||
|
normally be written. Writing as "out" defaults to
|
||||||
|
initializing the value as low. To ensure glitch free
|
||||||
|
operation, values "low" and "high" may be written to
|
||||||
|
configure the GPIO as an output with that initial value.
|
||||||
|
|
||||||
|
Note that this attribute *will not exist* if the kernel
|
||||||
|
doesn't support changing the direction of a GPIO, or
|
||||||
|
it was exported by kernel code that didn't explicitly
|
||||||
|
allow userspace to reconfigure this GPIO's direction.
|
||||||
|
|
||||||
|
"value" ... reads as either 0 (low) or 1 (high). If the GPIO
|
||||||
|
is configured as an output, this value may be written;
|
||||||
|
any nonzero value is treated as high.
|
||||||
|
|
||||||
|
GPIO controllers have paths like /sys/class/gpio/chipchip42/ (for the
|
||||||
|
controller implementing GPIOs starting at #42) and have the following
|
||||||
|
read-only attributes:
|
||||||
|
|
||||||
|
/sys/class/gpio/gpiochipN/
|
||||||
|
|
||||||
|
"base" ... same as N, the first GPIO managed by this chip
|
||||||
|
|
||||||
|
"label" ... provided for diagnostics (not always unique)
|
||||||
|
|
||||||
|
"ngpio" ... how many GPIOs this manges (N to N + ngpio - 1)
|
||||||
|
|
||||||
|
Board documentation should in most cases cover what GPIOs are used for
|
||||||
|
what purposes. However, those numbers are not always stable; GPIOs on
|
||||||
|
a daughtercard might be different depending on the base board being used,
|
||||||
|
or other cards in the stack. In such cases, you may need to use the
|
||||||
|
gpiochip nodes (possibly in conjunction with schematics) to determine
|
||||||
|
the correct GPIO number to use for a given signal.
|
||||||
|
|
||||||
|
|
||||||
|
Exporting from Kernel code
|
||||||
|
--------------------------
|
||||||
|
Kernel code can explicitly manage exports of GPIOs which have already been
|
||||||
|
requested using gpio_request():
|
||||||
|
|
||||||
|
/* export the GPIO to userspace */
|
||||||
|
int gpio_export(unsigned gpio, bool direction_may_change);
|
||||||
|
|
||||||
|
/* reverse gpio_export() */
|
||||||
|
void gpio_unexport();
|
||||||
|
|
||||||
|
After a kernel driver requests a GPIO, it may only be made available in
|
||||||
|
the sysfs interface by gpio_export(). The driver can control whether the
|
||||||
|
signal direction may change. This helps drivers prevent userspace code
|
||||||
|
from accidentally clobbering important system state.
|
||||||
|
|
||||||
|
This explicit exporting can help with debugging (by making some kinds
|
||||||
|
of experiments easier), or can provide an always-there interface that's
|
||||||
|
suitable for documenting as part of a board support package.
|
||||||
|
|
281
Documentation/i2c/upgrading-clients
Normal file
281
Documentation/i2c/upgrading-clients
Normal file
|
@ -0,0 +1,281 @@
|
||||||
|
Upgrading I2C Drivers to the new 2.6 Driver Model
|
||||||
|
=================================================
|
||||||
|
|
||||||
|
Ben Dooks <ben-linux@fluff.org>
|
||||||
|
|
||||||
|
Introduction
|
||||||
|
------------
|
||||||
|
|
||||||
|
This guide outlines how to alter existing Linux 2.6 client drivers from
|
||||||
|
the old to the new new binding methods.
|
||||||
|
|
||||||
|
|
||||||
|
Example old-style driver
|
||||||
|
------------------------
|
||||||
|
|
||||||
|
|
||||||
|
struct example_state {
|
||||||
|
struct i2c_client client;
|
||||||
|
....
|
||||||
|
};
|
||||||
|
|
||||||
|
static struct i2c_driver example_driver;
|
||||||
|
|
||||||
|
static unsigned short ignore[] = { I2C_CLIENT_END };
|
||||||
|
static unsigned short normal_addr[] = { OUR_ADDR, I2C_CLIENT_END };
|
||||||
|
|
||||||
|
I2C_CLIENT_INSMOD;
|
||||||
|
|
||||||
|
static int example_attach(struct i2c_adapter *adap, int addr, int kind)
|
||||||
|
{
|
||||||
|
struct example_state *state;
|
||||||
|
struct device *dev = &adap->dev; /* to use for dev_ reports */
|
||||||
|
int ret;
|
||||||
|
|
||||||
|
state = kzalloc(sizeof(struct example_state), GFP_KERNEL);
|
||||||
|
if (state == NULL) {
|
||||||
|
dev_err(dev, "failed to create our state\n");
|
||||||
|
return -ENOMEM;
|
||||||
|
}
|
||||||
|
|
||||||
|
example->client.addr = addr;
|
||||||
|
example->client.flags = 0;
|
||||||
|
example->client.adapter = adap;
|
||||||
|
|
||||||
|
i2c_set_clientdata(&state->i2c_client, state);
|
||||||
|
strlcpy(client->i2c_client.name, "example", I2C_NAME_SIZE);
|
||||||
|
|
||||||
|
ret = i2c_attach_client(&state->i2c_client);
|
||||||
|
if (ret < 0) {
|
||||||
|
dev_err(dev, "failed to attach client\n");
|
||||||
|
kfree(state);
|
||||||
|
return ret;
|
||||||
|
}
|
||||||
|
|
||||||
|
dev = &state->i2c_client.dev;
|
||||||
|
|
||||||
|
/* rest of the initialisation goes here. */
|
||||||
|
|
||||||
|
dev_info(dev, "example client created\n");
|
||||||
|
|
||||||
|
return 0;
|
||||||
|
}
|
||||||
|
|
||||||
|
static int __devexit example_detach(struct i2c_client *client)
|
||||||
|
{
|
||||||
|
struct example_state *state = i2c_get_clientdata(client);
|
||||||
|
|
||||||
|
i2c_detach_client(client);
|
||||||
|
kfree(state);
|
||||||
|
return 0;
|
||||||
|
}
|
||||||
|
|
||||||
|
static int example_attach_adapter(struct i2c_adapter *adap)
|
||||||
|
{
|
||||||
|
return i2c_probe(adap, &addr_data, example_attach);
|
||||||
|
}
|
||||||
|
|
||||||
|
static struct i2c_driver example_driver = {
|
||||||
|
.driver = {
|
||||||
|
.owner = THIS_MODULE,
|
||||||
|
.name = "example",
|
||||||
|
},
|
||||||
|
.attach_adapter = example_attach_adapter,
|
||||||
|
.detach_client = __devexit_p(example_detach),
|
||||||
|
.suspend = example_suspend,
|
||||||
|
.resume = example_resume,
|
||||||
|
};
|
||||||
|
|
||||||
|
|
||||||
|
Updating the client
|
||||||
|
-------------------
|
||||||
|
|
||||||
|
The new style binding model will check against a list of supported
|
||||||
|
devices and their associated address supplied by the code registering
|
||||||
|
the busses. This means that the driver .attach_adapter and
|
||||||
|
.detach_adapter methods can be removed, along with the addr_data,
|
||||||
|
as follows:
|
||||||
|
|
||||||
|
- static struct i2c_driver example_driver;
|
||||||
|
|
||||||
|
- static unsigned short ignore[] = { I2C_CLIENT_END };
|
||||||
|
- static unsigned short normal_addr[] = { OUR_ADDR, I2C_CLIENT_END };
|
||||||
|
|
||||||
|
- I2C_CLIENT_INSMOD;
|
||||||
|
|
||||||
|
- static int example_attach_adapter(struct i2c_adapter *adap)
|
||||||
|
- {
|
||||||
|
- return i2c_probe(adap, &addr_data, example_attach);
|
||||||
|
- }
|
||||||
|
|
||||||
|
static struct i2c_driver example_driver = {
|
||||||
|
- .attach_adapter = example_attach_adapter,
|
||||||
|
- .detach_client = __devexit_p(example_detach),
|
||||||
|
}
|
||||||
|
|
||||||
|
Add the probe and remove methods to the i2c_driver, as so:
|
||||||
|
|
||||||
|
static struct i2c_driver example_driver = {
|
||||||
|
+ .probe = example_probe,
|
||||||
|
+ .remove = __devexit_p(example_remove),
|
||||||
|
}
|
||||||
|
|
||||||
|
Change the example_attach method to accept the new parameters
|
||||||
|
which include the i2c_client that it will be working with:
|
||||||
|
|
||||||
|
- static int example_attach(struct i2c_adapter *adap, int addr, int kind)
|
||||||
|
+ static int example_probe(struct i2c_client *client,
|
||||||
|
+ const struct i2c_device_id *id)
|
||||||
|
|
||||||
|
Change the name of example_attach to example_probe to align it with the
|
||||||
|
i2c_driver entry names. The rest of the probe routine will now need to be
|
||||||
|
changed as the i2c_client has already been setup for use.
|
||||||
|
|
||||||
|
The necessary client fields have already been setup before
|
||||||
|
the probe function is called, so the following client setup
|
||||||
|
can be removed:
|
||||||
|
|
||||||
|
- example->client.addr = addr;
|
||||||
|
- example->client.flags = 0;
|
||||||
|
- example->client.adapter = adap;
|
||||||
|
-
|
||||||
|
- strlcpy(client->i2c_client.name, "example", I2C_NAME_SIZE);
|
||||||
|
|
||||||
|
The i2c_set_clientdata is now:
|
||||||
|
|
||||||
|
- i2c_set_clientdata(&state->client, state);
|
||||||
|
+ i2c_set_clientdata(client, state);
|
||||||
|
|
||||||
|
The call to i2c_attach_client is no longer needed, if the probe
|
||||||
|
routine exits successfully, then the driver will be automatically
|
||||||
|
attached by the core. Change the probe routine as so:
|
||||||
|
|
||||||
|
- ret = i2c_attach_client(&state->i2c_client);
|
||||||
|
- if (ret < 0) {
|
||||||
|
- dev_err(dev, "failed to attach client\n");
|
||||||
|
- kfree(state);
|
||||||
|
- return ret;
|
||||||
|
- }
|
||||||
|
|
||||||
|
|
||||||
|
Remove the storage of 'struct i2c_client' from the 'struct example_state'
|
||||||
|
as we are provided with the i2c_client in our example_probe. Instead we
|
||||||
|
store a pointer to it for when it is needed.
|
||||||
|
|
||||||
|
struct example_state {
|
||||||
|
- struct i2c_client client;
|
||||||
|
+ struct i2c_client *client;
|
||||||
|
|
||||||
|
the new i2c client as so:
|
||||||
|
|
||||||
|
- struct device *dev = &adap->dev; /* to use for dev_ reports */
|
||||||
|
+ struct device *dev = &i2c_client->dev; /* to use for dev_ reports */
|
||||||
|
|
||||||
|
And remove the change after our client is attached, as the driver no
|
||||||
|
longer needs to register a new client structure with the core:
|
||||||
|
|
||||||
|
- dev = &state->i2c_client.dev;
|
||||||
|
|
||||||
|
In the probe routine, ensure that the new state has the client stored
|
||||||
|
in it:
|
||||||
|
|
||||||
|
static int example_probe(struct i2c_client *i2c_client,
|
||||||
|
const struct i2c_device_id *id)
|
||||||
|
{
|
||||||
|
struct example_state *state;
|
||||||
|
struct device *dev = &i2c_client->dev;
|
||||||
|
int ret;
|
||||||
|
|
||||||
|
state = kzalloc(sizeof(struct example_state), GFP_KERNEL);
|
||||||
|
if (state == NULL) {
|
||||||
|
dev_err(dev, "failed to create our state\n");
|
||||||
|
return -ENOMEM;
|
||||||
|
}
|
||||||
|
|
||||||
|
+ state->client = i2c_client;
|
||||||
|
|
||||||
|
Update the detach method, by changing the name to _remove and
|
||||||
|
to delete the i2c_detach_client call. It is possible that you
|
||||||
|
can also remove the ret variable as it is not not needed for
|
||||||
|
any of the core functions.
|
||||||
|
|
||||||
|
- static int __devexit example_detach(struct i2c_client *client)
|
||||||
|
+ static int __devexit example_remove(struct i2c_client *client)
|
||||||
|
{
|
||||||
|
struct example_state *state = i2c_get_clientdata(client);
|
||||||
|
|
||||||
|
- i2c_detach_client(client);
|
||||||
|
|
||||||
|
And finally ensure that we have the correct ID table for the i2c-core
|
||||||
|
and other utilities:
|
||||||
|
|
||||||
|
+ struct i2c_device_id example_idtable[] = {
|
||||||
|
+ { "example", 0 },
|
||||||
|
+ { }
|
||||||
|
+};
|
||||||
|
+
|
||||||
|
+MODULE_DEVICE_TABLE(i2c, example_idtable);
|
||||||
|
|
||||||
|
static struct i2c_driver example_driver = {
|
||||||
|
.driver = {
|
||||||
|
.owner = THIS_MODULE,
|
||||||
|
.name = "example",
|
||||||
|
},
|
||||||
|
+ .id_table = example_ids,
|
||||||
|
|
||||||
|
|
||||||
|
Our driver should now look like this:
|
||||||
|
|
||||||
|
struct example_state {
|
||||||
|
struct i2c_client *client;
|
||||||
|
....
|
||||||
|
};
|
||||||
|
|
||||||
|
static int example_probe(struct i2c_client *client,
|
||||||
|
const struct i2c_device_id *id)
|
||||||
|
{
|
||||||
|
struct example_state *state;
|
||||||
|
struct device *dev = &client->dev;
|
||||||
|
|
||||||
|
state = kzalloc(sizeof(struct example_state), GFP_KERNEL);
|
||||||
|
if (state == NULL) {
|
||||||
|
dev_err(dev, "failed to create our state\n");
|
||||||
|
return -ENOMEM;
|
||||||
|
}
|
||||||
|
|
||||||
|
state->client = client;
|
||||||
|
i2c_set_clientdata(client, state);
|
||||||
|
|
||||||
|
/* rest of the initialisation goes here. */
|
||||||
|
|
||||||
|
dev_info(dev, "example client created\n");
|
||||||
|
|
||||||
|
return 0;
|
||||||
|
}
|
||||||
|
|
||||||
|
static int __devexit example_remove(struct i2c_client *client)
|
||||||
|
{
|
||||||
|
struct example_state *state = i2c_get_clientdata(client);
|
||||||
|
|
||||||
|
kfree(state);
|
||||||
|
return 0;
|
||||||
|
}
|
||||||
|
|
||||||
|
static struct i2c_device_id example_idtable[] = {
|
||||||
|
{ "example", 0 },
|
||||||
|
{ }
|
||||||
|
};
|
||||||
|
|
||||||
|
MODULE_DEVICE_TABLE(i2c, example_idtable);
|
||||||
|
|
||||||
|
static struct i2c_driver example_driver = {
|
||||||
|
.driver = {
|
||||||
|
.owner = THIS_MODULE,
|
||||||
|
.name = "example",
|
||||||
|
},
|
||||||
|
.id_table = example_idtable,
|
||||||
|
.probe = example_probe,
|
||||||
|
.remove = __devexit_p(example_remove),
|
||||||
|
.suspend = example_suspend,
|
||||||
|
.resume = example_resume,
|
||||||
|
};
|
|
@ -50,9 +50,9 @@ Note: For step 2, please make sure that host page size == TARGET_PAGE_SIZE of qe
|
||||||
/usr/local/bin/qemu-system-ia64 -smp xx -m 512 -hda $your_image
|
/usr/local/bin/qemu-system-ia64 -smp xx -m 512 -hda $your_image
|
||||||
(xx is the number of virtual processors for the guest, now the maximum value is 4)
|
(xx is the number of virtual processors for the guest, now the maximum value is 4)
|
||||||
|
|
||||||
5. Known possibile issue on some platforms with old Firmware.
|
5. Known possible issue on some platforms with old Firmware.
|
||||||
|
|
||||||
If meet strange host crashe issues, try to solve it through either of the following ways:
|
In the event of strange host crash issues, try to solve it through either of the following ways:
|
||||||
|
|
||||||
(1): Upgrade your Firmware to the latest one.
|
(1): Upgrade your Firmware to the latest one.
|
||||||
|
|
||||||
|
@ -65,8 +65,8 @@ index 0b53344..f02b0f7 100644
|
||||||
mov ar.pfs = loc1
|
mov ar.pfs = loc1
|
||||||
mov rp = loc0
|
mov rp = loc0
|
||||||
;;
|
;;
|
||||||
- srlz.d // seralize restoration of psr.l
|
- srlz.d // serialize restoration of psr.l
|
||||||
+ srlz.i // seralize restoration of psr.l
|
+ srlz.i // serialize restoration of psr.l
|
||||||
+ ;;
|
+ ;;
|
||||||
br.ret.sptk.many b0
|
br.ret.sptk.many b0
|
||||||
END(ia64_pal_call_static)
|
END(ia64_pal_call_static)
|
||||||
|
|
137
Documentation/ia64/paravirt_ops.txt
Normal file
137
Documentation/ia64/paravirt_ops.txt
Normal file
|
@ -0,0 +1,137 @@
|
||||||
|
Paravirt_ops on IA64
|
||||||
|
====================
|
||||||
|
21 May 2008, Isaku Yamahata <yamahata@valinux.co.jp>
|
||||||
|
|
||||||
|
|
||||||
|
Introduction
|
||||||
|
------------
|
||||||
|
The aim of this documentation is to help with maintainability and/or to
|
||||||
|
encourage people to use paravirt_ops/IA64.
|
||||||
|
|
||||||
|
paravirt_ops (pv_ops in short) is a way for virtualization support of
|
||||||
|
Linux kernel on x86. Several ways for virtualization support were
|
||||||
|
proposed, paravirt_ops is the winner.
|
||||||
|
On the other hand, now there are also several IA64 virtualization
|
||||||
|
technologies like kvm/IA64, xen/IA64 and many other academic IA64
|
||||||
|
hypervisors so that it is good to add generic virtualization
|
||||||
|
infrastructure on Linux/IA64.
|
||||||
|
|
||||||
|
|
||||||
|
What is paravirt_ops?
|
||||||
|
---------------------
|
||||||
|
It has been developed on x86 as virtualization support via API, not ABI.
|
||||||
|
It allows each hypervisor to override operations which are important for
|
||||||
|
hypervisors at API level. And it allows a single kernel binary to run on
|
||||||
|
all supported execution environments including native machine.
|
||||||
|
Essentially paravirt_ops is a set of function pointers which represent
|
||||||
|
operations corresponding to low level sensitive instructions and high
|
||||||
|
level functionalities in various area. But one significant difference
|
||||||
|
from usual function pointer table is that it allows optimization with
|
||||||
|
binary patch. It is because some of these operations are very
|
||||||
|
performance sensitive and indirect call overhead is not negligible.
|
||||||
|
With binary patch, indirect C function call can be transformed into
|
||||||
|
direct C function call or in-place execution to eliminate the overhead.
|
||||||
|
|
||||||
|
Thus, operations of paravirt_ops are classified into three categories.
|
||||||
|
- simple indirect call
|
||||||
|
These operations correspond to high level functionality so that the
|
||||||
|
overhead of indirect call isn't very important.
|
||||||
|
|
||||||
|
- indirect call which allows optimization with binary patch
|
||||||
|
Usually these operations correspond to low level instructions. They
|
||||||
|
are called frequently and performance critical. So the overhead is
|
||||||
|
very important.
|
||||||
|
|
||||||
|
- a set of macros for hand written assembly code
|
||||||
|
Hand written assembly codes (.S files) also need paravirtualization
|
||||||
|
because they include sensitive instructions or some of code paths in
|
||||||
|
them are very performance critical.
|
||||||
|
|
||||||
|
|
||||||
|
The relation to the IA64 machine vector
|
||||||
|
---------------------------------------
|
||||||
|
Linux/IA64 has the IA64 machine vector functionality which allows the
|
||||||
|
kernel to switch implementations (e.g. initialization, ipi, dma api...)
|
||||||
|
depending on executing platform.
|
||||||
|
We can replace some implementations very easily defining a new machine
|
||||||
|
vector. Thus another approach for virtualization support would be
|
||||||
|
enhancing the machine vector functionality.
|
||||||
|
But paravirt_ops approach was taken because
|
||||||
|
- virtualization support needs wider support than machine vector does.
|
||||||
|
e.g. low level instruction paravirtualization. It must be
|
||||||
|
initialized very early before platform detection.
|
||||||
|
|
||||||
|
- virtualization support needs more functionality like binary patch.
|
||||||
|
Probably the calling overhead might not be very large compared to the
|
||||||
|
emulation overhead of virtualization. However in the native case, the
|
||||||
|
overhead should be eliminated completely.
|
||||||
|
A single kernel binary should run on each environment including native,
|
||||||
|
and the overhead of paravirt_ops on native environment should be as
|
||||||
|
small as possible.
|
||||||
|
|
||||||
|
- for full virtualization technology, e.g. KVM/IA64 or
|
||||||
|
Xen/IA64 HVM domain, the result would be
|
||||||
|
(the emulated platform machine vector. probably dig) + (pv_ops).
|
||||||
|
This means that the virtualization support layer should be under
|
||||||
|
the machine vector layer.
|
||||||
|
|
||||||
|
Possibly it might be better to move some function pointers from
|
||||||
|
paravirt_ops to machine vector. In fact, Xen domU case utilizes both
|
||||||
|
pv_ops and machine vector.
|
||||||
|
|
||||||
|
|
||||||
|
IA64 paravirt_ops
|
||||||
|
-----------------
|
||||||
|
In this section, the concrete paravirt_ops will be discussed.
|
||||||
|
Because of the architecture difference between ia64 and x86, the
|
||||||
|
resulting set of functions is very different from x86 pv_ops.
|
||||||
|
|
||||||
|
- C function pointer tables
|
||||||
|
They are not very performance critical so that simple C indirect
|
||||||
|
function call is acceptable. The following structures are defined at
|
||||||
|
this moment. For details see linux/include/asm-ia64/paravirt.h
|
||||||
|
- struct pv_info
|
||||||
|
This structure describes the execution environment.
|
||||||
|
- struct pv_init_ops
|
||||||
|
This structure describes the various initialization hooks.
|
||||||
|
- struct pv_iosapic_ops
|
||||||
|
This structure describes hooks to iosapic operations.
|
||||||
|
- struct pv_irq_ops
|
||||||
|
This structure describes hooks to irq related operations
|
||||||
|
- struct pv_time_op
|
||||||
|
This structure describes hooks to steal time accounting.
|
||||||
|
|
||||||
|
- a set of indirect calls which need optimization
|
||||||
|
Currently this class of functions correspond to a subset of IA64
|
||||||
|
intrinsics. At this moment the optimization with binary patch isn't
|
||||||
|
implemented yet.
|
||||||
|
struct pv_cpu_op is defined. For details see
|
||||||
|
linux/include/asm-ia64/paravirt_privop.h
|
||||||
|
Mostly they correspond to ia64 intrinsics 1-to-1.
|
||||||
|
Caveat: Now they are defined as C indirect function pointers, but in
|
||||||
|
order to support binary patch optimization, they will be changed
|
||||||
|
using GCC extended inline assembly code.
|
||||||
|
|
||||||
|
- a set of macros for hand written assembly code (.S files)
|
||||||
|
For maintenance purpose, the taken approach for .S files is single
|
||||||
|
source code and compile multiple times with different macros definitions.
|
||||||
|
Each pv_ops instance must define those macros to compile.
|
||||||
|
The important thing here is that sensitive, but non-privileged
|
||||||
|
instructions must be paravirtualized and that some privileged
|
||||||
|
instructions also need paravirtualization for reasonable performance.
|
||||||
|
Developers who modify .S files must be aware of that. At this moment
|
||||||
|
an easy checker is implemented to detect paravirtualization breakage.
|
||||||
|
But it doesn't cover all the cases.
|
||||||
|
|
||||||
|
Sometimes this set of macros is called pv_cpu_asm_op. But there is no
|
||||||
|
corresponding structure in the source code.
|
||||||
|
Those macros mostly 1:1 correspond to a subset of privileged
|
||||||
|
instructions. See linux/include/asm-ia64/native/inst.h.
|
||||||
|
And some functions written in assembly also need to be overrided so
|
||||||
|
that each pv_ops instance have to define some macros. Again see
|
||||||
|
linux/include/asm-ia64/native/inst.h.
|
||||||
|
|
||||||
|
|
||||||
|
Those structures must be initialized very early before start_kernel.
|
||||||
|
Probably initialized in head.S using multi entry point or some other trick.
|
||||||
|
For native case implementation see linux/arch/ia64/kernel/paravirt.c.
|
|
@ -31,7 +31,7 @@ The driver works with ALSA drivers simultaneously. For example, the xracer
|
||||||
uses joystick as input device and PCM device as sound output in one time.
|
uses joystick as input device and PCM device as sound output in one time.
|
||||||
There are no sound or input collisions detected. The source code have
|
There are no sound or input collisions detected. The source code have
|
||||||
comments about them; but I've found the joystick can be initialized
|
comments about them; but I've found the joystick can be initialized
|
||||||
separately of ALSA modules. So, you canm use only one joystick driver
|
separately of ALSA modules. So, you can use only one joystick driver
|
||||||
without ALSA drivers. The ALSA drivers are not needed to compile or
|
without ALSA drivers. The ALSA drivers are not needed to compile or
|
||||||
run this driver.
|
run this driver.
|
||||||
|
|
||||||
|
|
|
@ -1,6 +1,6 @@
|
||||||
To decode a hex IOCTL code:
|
To decode a hex IOCTL code:
|
||||||
|
|
||||||
Most architecures use this generic format, but check
|
Most architectures use this generic format, but check
|
||||||
include/ARCH/ioctl.h for specifics, e.g. powerpc
|
include/ARCH/ioctl.h for specifics, e.g. powerpc
|
||||||
uses 3 bits to encode read/write and 13 bits for size.
|
uses 3 bits to encode read/write and 13 bits for size.
|
||||||
|
|
||||||
|
@ -18,7 +18,7 @@ uses 3 bits to encode read/write and 13 bits for size.
|
||||||
7-0 function #
|
7-0 function #
|
||||||
|
|
||||||
|
|
||||||
So for example 0x82187201 is a read with arg length of 0x218,
|
So for example 0x82187201 is a read with arg length of 0x218,
|
||||||
character 'r' function 1. Grepping the source reveals this is:
|
character 'r' function 1. Grepping the source reveals this is:
|
||||||
|
|
||||||
#define VFAT_IOCTL_READDIR_BOTH _IOR('r', 1, struct dirent [2])
|
#define VFAT_IOCTL_READDIR_BOTH _IOR('r', 1, struct dirent [2])
|
||||||
|
|
|
@ -143,7 +143,7 @@ disk and partition statistics are consistent again. Since we still don't
|
||||||
keep record of the partition-relative address, an operation is attributed to
|
keep record of the partition-relative address, an operation is attributed to
|
||||||
the partition which contains the first sector of the request after the
|
the partition which contains the first sector of the request after the
|
||||||
eventual merges. As requests can be merged across partition, this could lead
|
eventual merges. As requests can be merged across partition, this could lead
|
||||||
to some (probably insignificant) innacuracy.
|
to some (probably insignificant) inaccuracy.
|
||||||
|
|
||||||
Additional notes
|
Additional notes
|
||||||
----------------
|
----------------
|
||||||
|
|
6
Documentation/isdn/README.mISDN
Normal file
6
Documentation/isdn/README.mISDN
Normal file
|
@ -0,0 +1,6 @@
|
||||||
|
mISDN is a new modular ISDN driver, in the long term it should replace
|
||||||
|
the old I4L driver architecture for passiv ISDN cards.
|
||||||
|
It was designed to allow a broad range of applications and interfaces
|
||||||
|
but only have the basic function in kernel, the interface to the user
|
||||||
|
space is based on sockets with a own address family AF_ISDN.
|
||||||
|
|
|
@ -65,26 +65,26 @@ Install kexec-tools
|
||||||
|
|
||||||
2) Download the kexec-tools user-space package from the following URL:
|
2) Download the kexec-tools user-space package from the following URL:
|
||||||
|
|
||||||
http://www.kernel.org/pub/linux/kernel/people/horms/kexec-tools/kexec-tools-testing.tar.gz
|
http://www.kernel.org/pub/linux/kernel/people/horms/kexec-tools/kexec-tools.tar.gz
|
||||||
|
|
||||||
This is a symlink to the latest version, which at the time of writing is
|
This is a symlink to the latest version.
|
||||||
20061214, the only release of kexec-tools-testing so far. As other versions
|
|
||||||
are released, the older ones will remain available at
|
|
||||||
http://www.kernel.org/pub/linux/kernel/people/horms/kexec-tools/
|
|
||||||
|
|
||||||
Note: Latest kexec-tools-testing git tree is available at
|
The latest kexec-tools git tree is available at:
|
||||||
|
|
||||||
git://git.kernel.org/pub/scm/linux/kernel/git/horms/kexec-tools-testing.git
|
git://git.kernel.org/pub/scm/linux/kernel/git/horms/kexec-tools.git
|
||||||
or
|
or
|
||||||
http://www.kernel.org/git/?p=linux/kernel/git/horms/kexec-tools-testing.git;a=summary
|
http://www.kernel.org/git/?p=linux/kernel/git/horms/kexec-tools.git
|
||||||
|
|
||||||
|
More information about kexec-tools can be found at
|
||||||
|
http://www.kernel.org/pub/linux/kernel/people/horms/kexec-tools/README.html
|
||||||
|
|
||||||
3) Unpack the tarball with the tar command, as follows:
|
3) Unpack the tarball with the tar command, as follows:
|
||||||
|
|
||||||
tar xvpzf kexec-tools-testing.tar.gz
|
tar xvpzf kexec-tools.tar.gz
|
||||||
|
|
||||||
4) Change to the kexec-tools directory, as follows:
|
4) Change to the kexec-tools directory, as follows:
|
||||||
|
|
||||||
cd kexec-tools-testing-VERSION
|
cd kexec-tools-VERSION
|
||||||
|
|
||||||
5) Configure the package, as follows:
|
5) Configure the package, as follows:
|
||||||
|
|
||||||
|
|
|
@ -87,7 +87,8 @@ parameter is applicable:
|
||||||
SH SuperH architecture is enabled.
|
SH SuperH architecture is enabled.
|
||||||
SMP The kernel is an SMP kernel.
|
SMP The kernel is an SMP kernel.
|
||||||
SPARC Sparc architecture is enabled.
|
SPARC Sparc architecture is enabled.
|
||||||
SWSUSP Software suspend is enabled.
|
SWSUSP Software suspend (hibernation) is enabled.
|
||||||
|
SUSPEND System suspend states are enabled.
|
||||||
TS Appropriate touchscreen support is enabled.
|
TS Appropriate touchscreen support is enabled.
|
||||||
USB USB support is enabled.
|
USB USB support is enabled.
|
||||||
USBHID USB Human Interface Device support is enabled.
|
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
|
||||||
default: 0
|
default: 0
|
||||||
|
|
||||||
acpi_sleep= [HW,ACPI] Sleep options
|
acpi_sleep= [HW,ACPI] Sleep options
|
||||||
Format: { s3_bios, s3_mode, s3_beep, old_ordering }
|
Format: { s3_bios, s3_mode, s3_beep, s4_nohwsig, old_ordering }
|
||||||
See Documentation/power/video.txt for s3_bios and s3_mode.
|
See Documentation/power/video.txt for s3_bios and s3_mode.
|
||||||
s3_beep is for debugging; it makes the PC's speaker beep
|
s3_beep is for debugging; it makes the PC's speaker beep
|
||||||
as soon as the kernel's real-mode entry point is called.
|
as soon as the kernel's real-mode entry point is called.
|
||||||
|
s4_nohwsig prevents ACPI hardware signature from being
|
||||||
|
used during resume from hibernation.
|
||||||
old_ordering causes the ACPI 1.0 ordering of the _PTS
|
old_ordering causes the ACPI 1.0 ordering of the _PTS
|
||||||
control method, wrt putting devices into low power
|
control method, wrt putting devices into low power
|
||||||
states, to be enforced (the ACPI 2.0 ordering of _PTS is
|
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
|
||||||
hisax= [HW,ISDN]
|
hisax= [HW,ISDN]
|
||||||
See Documentation/isdn/README.HiSax.
|
See Documentation/isdn/README.HiSax.
|
||||||
|
|
||||||
hugepages= [HW,X86-32,IA-64] Maximal number of HugeTLB pages.
|
hugepages= [HW,X86-32,IA-64] HugeTLB pages to allocate at boot.
|
||||||
hugepagesz= [HW,IA-64,PPC] The size of the HugeTLB pages.
|
hugepagesz= [HW,IA-64,PPC,X86-64] The size of the HugeTLB pages.
|
||||||
|
On x86-64 and powerpc, this option can be specified
|
||||||
|
multiple times interleaved with hugepages= to reserve
|
||||||
|
huge pages of different sizes. Valid pages sizes on
|
||||||
|
x86-64 are 2M (when the CPU supports "pse") and 1G
|
||||||
|
(when the CPU supports the "pdpe1gb" cpuinfo flag)
|
||||||
|
Note that 1GB pages can only be allocated at boot time
|
||||||
|
using hugepages= and not freed afterwards.
|
||||||
|
default_hugepagesz=
|
||||||
|
[same as hugepagesz=] The size of the default
|
||||||
|
HugeTLB page size. This is the size represented by
|
||||||
|
the legacy /proc/ hugepages APIs, used for SHM, and
|
||||||
|
default size when mounting hugetlbfs filesystems.
|
||||||
|
Defaults to the default architecture's huge page size
|
||||||
|
if not specified.
|
||||||
|
|
||||||
i8042.direct [HW] Put keyboard port into non-translated mode
|
i8042.direct [HW] Put keyboard port into non-translated mode
|
||||||
i8042.dumbkbd [HW] Pretend that controller can only read data from
|
i8042.dumbkbd [HW] Pretend that controller can only read data from
|
||||||
|
@ -1206,7 +1223,7 @@ and is between 256 and 4096 characters. It is defined in the file
|
||||||
or
|
or
|
||||||
memmap=0x10000$0x18690000
|
memmap=0x10000$0x18690000
|
||||||
|
|
||||||
memtest= [KNL,X86_64] Enable memtest
|
memtest= [KNL,X86] Enable memtest
|
||||||
Format: <integer>
|
Format: <integer>
|
||||||
range: 0,4 : pattern number
|
range: 0,4 : pattern number
|
||||||
default : 0 <disable>
|
default : 0 <disable>
|
||||||
|
@ -1225,6 +1242,14 @@ and is between 256 and 4096 characters. It is defined in the file
|
||||||
|
|
||||||
mga= [HW,DRM]
|
mga= [HW,DRM]
|
||||||
|
|
||||||
|
mminit_loglevel=
|
||||||
|
[KNL] When CONFIG_DEBUG_MEMORY_INIT is set, this
|
||||||
|
parameter allows control of the logging verbosity for
|
||||||
|
the additional memory initialisation checks. A value
|
||||||
|
of 0 disables mminit logging and a level of 4 will
|
||||||
|
log everything. Information is printed at KERN_DEBUG
|
||||||
|
so loglevel=8 may also need to be specified.
|
||||||
|
|
||||||
mousedev.tap_time=
|
mousedev.tap_time=
|
||||||
[MOUSE] Maximum time between finger touching and
|
[MOUSE] Maximum time between finger touching and
|
||||||
leaving touchpad surface for touch to be considered
|
leaving touchpad surface for touch to be considered
|
||||||
|
@ -1279,6 +1304,13 @@ and is between 256 and 4096 characters. It is defined in the file
|
||||||
This usage is only documented in each driver source
|
This usage is only documented in each driver source
|
||||||
file if at all.
|
file if at all.
|
||||||
|
|
||||||
|
nf_conntrack.acct=
|
||||||
|
[NETFILTER] Enable connection tracking flow accounting
|
||||||
|
0 to disable accounting
|
||||||
|
1 to enable accounting
|
||||||
|
Default value depends on CONFIG_NF_CT_ACCT that is
|
||||||
|
going to be removed in 2.6.29.
|
||||||
|
|
||||||
nfsaddrs= [NFS]
|
nfsaddrs= [NFS]
|
||||||
See Documentation/filesystems/nfsroot.txt.
|
See Documentation/filesystems/nfsroot.txt.
|
||||||
|
|
||||||
|
@ -2027,6 +2059,9 @@ and is between 256 and 4096 characters. It is defined in the file
|
||||||
|
|
||||||
snd-ymfpci= [HW,ALSA]
|
snd-ymfpci= [HW,ALSA]
|
||||||
|
|
||||||
|
softlockup_panic=
|
||||||
|
[KNL] Should the soft-lockup detector generate panics.
|
||||||
|
|
||||||
sonypi.*= [HW] Sony Programmable I/O Control Device driver
|
sonypi.*= [HW] Sony Programmable I/O Control Device driver
|
||||||
See Documentation/sonypi.txt
|
See Documentation/sonypi.txt
|
||||||
|
|
||||||
|
@ -2091,6 +2126,12 @@ and is between 256 and 4096 characters. It is defined in the file
|
||||||
|
|
||||||
tdfx= [HW,DRM]
|
tdfx= [HW,DRM]
|
||||||
|
|
||||||
|
test_suspend= [SUSPEND]
|
||||||
|
Specify "mem" (for Suspend-to-RAM) or "standby" (for
|
||||||
|
standby suspend) as the system sleep state to briefly
|
||||||
|
enter during system startup. The system is woken from
|
||||||
|
this state using a wakeup-capable RTC alarm.
|
||||||
|
|
||||||
thash_entries= [KNL,NET]
|
thash_entries= [KNL,NET]
|
||||||
Set number of hash buckets for TCP connection
|
Set number of hash buckets for TCP connection
|
||||||
|
|
||||||
|
@ -2118,13 +2159,6 @@ and is between 256 and 4096 characters. It is defined in the file
|
||||||
<deci-seconds>: poll all this frequency
|
<deci-seconds>: poll all this frequency
|
||||||
0: no polling (default)
|
0: no polling (default)
|
||||||
|
|
||||||
tipar.timeout= [HW,PPT]
|
|
||||||
Set communications timeout in tenths of a second
|
|
||||||
(default 15).
|
|
||||||
|
|
||||||
tipar.delay= [HW,PPT]
|
|
||||||
Set inter-bit delay in microseconds (default 10).
|
|
||||||
|
|
||||||
tmscsim= [HW,SCSI]
|
tmscsim= [HW,SCSI]
|
||||||
See comment before function dc390_setup() in
|
See comment before function dc390_setup() in
|
||||||
drivers/scsi/tmscsim.c.
|
drivers/scsi/tmscsim.c.
|
||||||
|
@ -2158,6 +2192,10 @@ and is between 256 and 4096 characters. It is defined in the file
|
||||||
Note that genuine overcurrent events won't be
|
Note that genuine overcurrent events won't be
|
||||||
reported either.
|
reported either.
|
||||||
|
|
||||||
|
unknown_nmi_panic
|
||||||
|
[X86-32,X86-64]
|
||||||
|
Set unknown_nmi_panic=1 early on boot.
|
||||||
|
|
||||||
usbcore.autosuspend=
|
usbcore.autosuspend=
|
||||||
[USB] The autosuspend time delay (in seconds) used
|
[USB] The autosuspend time delay (in seconds) used
|
||||||
for newly-detected USB devices (default 2). This
|
for newly-detected USB devices (default 2). This
|
||||||
|
|
|
@ -864,7 +864,7 @@ payload contents" for more information.
|
||||||
request_key_with_auxdata() respectively.
|
request_key_with_auxdata() respectively.
|
||||||
|
|
||||||
These two functions return with the key potentially still under
|
These two functions return with the key potentially still under
|
||||||
construction. To wait for contruction completion, the following should be
|
construction. To wait for construction completion, the following should be
|
||||||
called:
|
called:
|
||||||
|
|
||||||
int wait_for_key_construction(struct key *key, bool intr);
|
int wait_for_key_construction(struct key *key, bool intr);
|
||||||
|
|
|
@ -1,7 +1,7 @@
|
||||||
ThinkPad ACPI Extras Driver
|
ThinkPad ACPI Extras Driver
|
||||||
|
|
||||||
Version 0.20
|
Version 0.21
|
||||||
April 09th, 2008
|
May 29th, 2008
|
||||||
|
|
||||||
Borislav Deianov <borislav@users.sf.net>
|
Borislav Deianov <borislav@users.sf.net>
|
||||||
Henrique de Moraes Holschuh <hmh@hmh.eng.br>
|
Henrique de Moraes Holschuh <hmh@hmh.eng.br>
|
||||||
|
@ -621,7 +621,8 @@ Bluetooth
|
||||||
---------
|
---------
|
||||||
|
|
||||||
procfs: /proc/acpi/ibm/bluetooth
|
procfs: /proc/acpi/ibm/bluetooth
|
||||||
sysfs device attribute: bluetooth_enable
|
sysfs device attribute: bluetooth_enable (deprecated)
|
||||||
|
sysfs rfkill class: switch "tpacpi_bluetooth_sw"
|
||||||
|
|
||||||
This feature shows the presence and current state of a ThinkPad
|
This feature shows the presence and current state of a ThinkPad
|
||||||
Bluetooth device in the internal ThinkPad CDC slot.
|
Bluetooth device in the internal ThinkPad CDC slot.
|
||||||
|
@ -643,8 +644,12 @@ Sysfs notes:
|
||||||
0: disables Bluetooth / Bluetooth is disabled
|
0: disables Bluetooth / Bluetooth is disabled
|
||||||
1: enables Bluetooth / Bluetooth is enabled.
|
1: enables Bluetooth / Bluetooth is enabled.
|
||||||
|
|
||||||
Note: this interface will be probably be superseded by the
|
Note: this interface has been superseded by the generic rfkill
|
||||||
generic rfkill class, so it is NOT to be considered stable yet.
|
class. It has been deprecated, and it will be removed in year
|
||||||
|
2010.
|
||||||
|
|
||||||
|
rfkill controller switch "tpacpi_bluetooth_sw": refer to
|
||||||
|
Documentation/rfkill.txt for details.
|
||||||
|
|
||||||
Video output control -- /proc/acpi/ibm/video
|
Video output control -- /proc/acpi/ibm/video
|
||||||
--------------------------------------------
|
--------------------------------------------
|
||||||
|
@ -1374,7 +1379,8 @@ EXPERIMENTAL: WAN
|
||||||
-----------------
|
-----------------
|
||||||
|
|
||||||
procfs: /proc/acpi/ibm/wan
|
procfs: /proc/acpi/ibm/wan
|
||||||
sysfs device attribute: wwan_enable
|
sysfs device attribute: wwan_enable (deprecated)
|
||||||
|
sysfs rfkill class: switch "tpacpi_wwan_sw"
|
||||||
|
|
||||||
This feature is marked EXPERIMENTAL because the implementation
|
This feature is marked EXPERIMENTAL because the implementation
|
||||||
directly accesses hardware registers and may not work as expected. USE
|
directly accesses hardware registers and may not work as expected. USE
|
||||||
|
@ -1404,8 +1410,12 @@ Sysfs notes:
|
||||||
0: disables WWAN card / WWAN card is disabled
|
0: disables WWAN card / WWAN card is disabled
|
||||||
1: enables WWAN card / WWAN card is enabled.
|
1: enables WWAN card / WWAN card is enabled.
|
||||||
|
|
||||||
Note: this interface will be probably be superseded by the
|
Note: this interface has been superseded by the generic rfkill
|
||||||
generic rfkill class, so it is NOT to be considered stable yet.
|
class. It has been deprecated, and it will be removed in year
|
||||||
|
2010.
|
||||||
|
|
||||||
|
rfkill controller switch "tpacpi_wwan_sw": refer to
|
||||||
|
Documentation/rfkill.txt for details.
|
||||||
|
|
||||||
Multiple Commands, Module Parameters
|
Multiple Commands, Module Parameters
|
||||||
------------------------------------
|
------------------------------------
|
||||||
|
|
|
@ -59,7 +59,7 @@ Hardware accelerated blink of LEDs
|
||||||
|
|
||||||
Some LEDs can be programmed to blink without any CPU interaction. To
|
Some LEDs can be programmed to blink without any CPU interaction. To
|
||||||
support this feature, a LED driver can optionally implement the
|
support this feature, a LED driver can optionally implement the
|
||||||
blink_set() function (see <linux/leds.h>). If implemeted, triggers can
|
blink_set() function (see <linux/leds.h>). If implemented, triggers can
|
||||||
attempt to use it before falling back to software timers. The blink_set()
|
attempt to use it before falling back to software timers. The blink_set()
|
||||||
function should return 0 if the blink setting is supported, or -EINVAL
|
function should return 0 if the blink setting is supported, or -EINVAL
|
||||||
otherwise, which means that LED blinking will be handled by software.
|
otherwise, which means that LED blinking will be handled by software.
|
||||||
|
|
|
@ -36,11 +36,13 @@
|
||||||
#include <sched.h>
|
#include <sched.h>
|
||||||
#include <limits.h>
|
#include <limits.h>
|
||||||
#include <stddef.h>
|
#include <stddef.h>
|
||||||
|
#include <signal.h>
|
||||||
#include "linux/lguest_launcher.h"
|
#include "linux/lguest_launcher.h"
|
||||||
#include "linux/virtio_config.h"
|
#include "linux/virtio_config.h"
|
||||||
#include "linux/virtio_net.h"
|
#include "linux/virtio_net.h"
|
||||||
#include "linux/virtio_blk.h"
|
#include "linux/virtio_blk.h"
|
||||||
#include "linux/virtio_console.h"
|
#include "linux/virtio_console.h"
|
||||||
|
#include "linux/virtio_rng.h"
|
||||||
#include "linux/virtio_ring.h"
|
#include "linux/virtio_ring.h"
|
||||||
#include "asm-x86/bootparam.h"
|
#include "asm-x86/bootparam.h"
|
||||||
/*L:110 We can ignore the 39 include files we need for this program, but I do
|
/*L:110 We can ignore the 39 include files we need for this program, but I do
|
||||||
|
@ -64,8 +66,8 @@ typedef uint8_t u8;
|
||||||
#endif
|
#endif
|
||||||
/* We can have up to 256 pages for devices. */
|
/* We can have up to 256 pages for devices. */
|
||||||
#define DEVICE_PAGES 256
|
#define DEVICE_PAGES 256
|
||||||
/* This will occupy 2 pages: it must be a power of 2. */
|
/* This will occupy 3 pages: it must be a power of 2. */
|
||||||
#define VIRTQUEUE_NUM 128
|
#define VIRTQUEUE_NUM 256
|
||||||
|
|
||||||
/*L:120 verbose is both a global flag and a macro. The C preprocessor allows
|
/*L:120 verbose is both a global flag and a macro. The C preprocessor allows
|
||||||
* this, and although I wouldn't recommend it, it works quite nicely here. */
|
* this, and although I wouldn't recommend it, it works quite nicely here. */
|
||||||
|
@ -74,12 +76,19 @@ static bool verbose;
|
||||||
do { if (verbose) printf(args); } while(0)
|
do { if (verbose) printf(args); } while(0)
|
||||||
/*:*/
|
/*:*/
|
||||||
|
|
||||||
/* The pipe to send commands to the waker process */
|
/* File descriptors for the Waker. */
|
||||||
static int waker_fd;
|
struct {
|
||||||
|
int pipe[2];
|
||||||
|
int lguest_fd;
|
||||||
|
} waker_fds;
|
||||||
|
|
||||||
/* The pointer to the start of guest memory. */
|
/* The pointer to the start of guest memory. */
|
||||||
static void *guest_base;
|
static void *guest_base;
|
||||||
/* The maximum guest physical address allowed, and maximum possible. */
|
/* The maximum guest physical address allowed, and maximum possible. */
|
||||||
static unsigned long guest_limit, guest_max;
|
static unsigned long guest_limit, guest_max;
|
||||||
|
/* The pipe for signal hander to write to. */
|
||||||
|
static int timeoutpipe[2];
|
||||||
|
static unsigned int timeout_usec = 500;
|
||||||
|
|
||||||
/* a per-cpu variable indicating whose vcpu is currently running */
|
/* a per-cpu variable indicating whose vcpu is currently running */
|
||||||
static unsigned int __thread cpu_id;
|
static unsigned int __thread cpu_id;
|
||||||
|
@ -155,11 +164,14 @@ struct virtqueue
|
||||||
/* Last available index we saw. */
|
/* Last available index we saw. */
|
||||||
u16 last_avail_idx;
|
u16 last_avail_idx;
|
||||||
|
|
||||||
/* The routine to call when the Guest pings us. */
|
/* The routine to call when the Guest pings us, or timeout. */
|
||||||
void (*handle_output)(int fd, struct virtqueue *me);
|
void (*handle_output)(int fd, struct virtqueue *me, bool timeout);
|
||||||
|
|
||||||
/* Outstanding buffers */
|
/* Outstanding buffers */
|
||||||
unsigned int inflight;
|
unsigned int inflight;
|
||||||
|
|
||||||
|
/* Is this blocked awaiting a timer? */
|
||||||
|
bool blocked;
|
||||||
};
|
};
|
||||||
|
|
||||||
/* Remember the arguments to the program so we can "reboot" */
|
/* Remember the arguments to the program so we can "reboot" */
|
||||||
|
@ -190,6 +202,9 @@ static void *_convert(struct iovec *iov, size_t size, size_t align,
|
||||||
return iov->iov_base;
|
return iov->iov_base;
|
||||||
}
|
}
|
||||||
|
|
||||||
|
/* Wrapper for the last available index. Makes it easier to change. */
|
||||||
|
#define lg_last_avail(vq) ((vq)->last_avail_idx)
|
||||||
|
|
||||||
/* The virtio configuration space is defined to be little-endian. x86 is
|
/* The virtio configuration space is defined to be little-endian. x86 is
|
||||||
* little-endian too, but it's nice to be explicit so we have these helpers. */
|
* little-endian too, but it's nice to be explicit so we have these helpers. */
|
||||||
#define cpu_to_le16(v16) (v16)
|
#define cpu_to_le16(v16) (v16)
|
||||||
|
@ -199,6 +214,33 @@ static void *_convert(struct iovec *iov, size_t size, size_t align,
|
||||||
#define le32_to_cpu(v32) (v32)
|
#define le32_to_cpu(v32) (v32)
|
||||||
#define le64_to_cpu(v64) (v64)
|
#define le64_to_cpu(v64) (v64)
|
||||||
|
|
||||||
|
/* Is this iovec empty? */
|
||||||
|
static bool iov_empty(const struct iovec iov[], unsigned int num_iov)
|
||||||
|
{
|
||||||
|
unsigned int i;
|
||||||
|
|
||||||
|
for (i = 0; i < num_iov; i++)
|
||||||
|
if (iov[i].iov_len)
|
||||||
|
return false;
|
||||||
|
return true;
|
||||||
|
}
|
||||||
|
|
||||||
|
/* Take len bytes from the front of this iovec. */
|
||||||
|
static void iov_consume(struct iovec iov[], unsigned num_iov, unsigned len)
|
||||||
|
{
|
||||||
|
unsigned int i;
|
||||||
|
|
||||||
|
for (i = 0; i < num_iov; i++) {
|
||||||
|
unsigned int used;
|
||||||
|
|
||||||
|
used = iov[i].iov_len < len ? iov[i].iov_len : len;
|
||||||
|
iov[i].iov_base += used;
|
||||||
|
iov[i].iov_len -= used;
|
||||||
|
len -= used;
|
||||||
|
}
|
||||||
|
assert(len == 0);
|
||||||
|
}
|
||||||
|
|
||||||
/* The device virtqueue descriptors are followed by feature bitmasks. */
|
/* The device virtqueue descriptors are followed by feature bitmasks. */
|
||||||
static u8 *get_feature_bits(struct device *dev)
|
static u8 *get_feature_bits(struct device *dev)
|
||||||
{
|
{
|
||||||
|
@ -254,6 +296,7 @@ static void *map_zeroed_pages(unsigned int num)
|
||||||
PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE, fd, 0);
|
PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE, fd, 0);
|
||||||
if (addr == MAP_FAILED)
|
if (addr == MAP_FAILED)
|
||||||
err(1, "Mmaping %u pages of /dev/zero", num);
|
err(1, "Mmaping %u pages of /dev/zero", num);
|
||||||
|
close(fd);
|
||||||
|
|
||||||
return addr;
|
return addr;
|
||||||
}
|
}
|
||||||
|
@ -540,69 +583,64 @@ static void add_device_fd(int fd)
|
||||||
* watch, but handing a file descriptor mask through to the kernel is fairly
|
* watch, but handing a file descriptor mask through to the kernel is fairly
|
||||||
* icky.
|
* icky.
|
||||||
*
|
*
|
||||||
* Instead, we fork off a process which watches the file descriptors and writes
|
* Instead, we clone off a thread which watches the file descriptors and writes
|
||||||
* the LHREQ_BREAK command to the /dev/lguest file descriptor to tell the Host
|
* the LHREQ_BREAK command to the /dev/lguest file descriptor to tell the Host
|
||||||
* stop running the Guest. This causes the Launcher to return from the
|
* stop running the Guest. This causes the Launcher to return from the
|
||||||
* /dev/lguest read with -EAGAIN, where it will write to /dev/lguest to reset
|
* /dev/lguest read with -EAGAIN, where it will write to /dev/lguest to reset
|
||||||
* the LHREQ_BREAK and wake us up again.
|
* the LHREQ_BREAK and wake us up again.
|
||||||
*
|
*
|
||||||
* This, of course, is merely a different *kind* of icky.
|
* This, of course, is merely a different *kind* of icky.
|
||||||
|
*
|
||||||
|
* Given my well-known antipathy to threads, I'd prefer to use processes. But
|
||||||
|
* it's easier to share Guest memory with threads, and trivial to share the
|
||||||
|
* devices.infds as the Launcher changes it.
|
||||||
*/
|
*/
|
||||||
static void wake_parent(int pipefd, int lguest_fd)
|
static int waker(void *unused)
|
||||||
{
|
{
|
||||||
/* Add the pipe from the Launcher to the fdset in the device_list, so
|
/* Close the write end of the pipe: only the Launcher has it open. */
|
||||||
* we watch it, too. */
|
close(waker_fds.pipe[1]);
|
||||||
add_device_fd(pipefd);
|
|
||||||
|
|
||||||
for (;;) {
|
for (;;) {
|
||||||
fd_set rfds = devices.infds;
|
fd_set rfds = devices.infds;
|
||||||
unsigned long args[] = { LHREQ_BREAK, 1 };
|
unsigned long args[] = { LHREQ_BREAK, 1 };
|
||||||
|
unsigned int maxfd = devices.max_infd;
|
||||||
|
|
||||||
|
/* We also listen to the pipe from the Launcher. */
|
||||||
|
FD_SET(waker_fds.pipe[0], &rfds);
|
||||||
|
if (waker_fds.pipe[0] > maxfd)
|
||||||
|
maxfd = waker_fds.pipe[0];
|
||||||
|
|
||||||
/* Wait until input is ready from one of the devices. */
|
/* Wait until input is ready from one of the devices. */
|
||||||
select(devices.max_infd+1, &rfds, NULL, NULL, NULL);
|
select(maxfd+1, &rfds, NULL, NULL, NULL);
|
||||||
/* Is it a message from the Launcher? */
|
|
||||||
if (FD_ISSET(pipefd, &rfds)) {
|
/* Message from Launcher? */
|
||||||
int fd;
|
if (FD_ISSET(waker_fds.pipe[0], &rfds)) {
|
||||||
/* If read() returns 0, it means the Launcher has
|
char c;
|
||||||
* exited. We silently follow. */
|
/* If this fails, then assume Launcher has exited.
|
||||||
if (read(pipefd, &fd, sizeof(fd)) == 0)
|
* Don't do anything on exit: we're just a thread! */
|
||||||
exit(0);
|
if (read(waker_fds.pipe[0], &c, 1) != 1)
|
||||||
/* Otherwise it's telling us to change what file
|
_exit(0);
|
||||||
* descriptors we're to listen to. Positive means
|
continue;
|
||||||
* listen to a new one, negative means stop
|
}
|
||||||
* listening. */
|
|
||||||
if (fd >= 0)
|
/* Send LHREQ_BREAK command to snap the Launcher out of it. */
|
||||||
FD_SET(fd, &devices.infds);
|
pwrite(waker_fds.lguest_fd, args, sizeof(args), cpu_id);
|
||||||
else
|
|
||||||
FD_CLR(-fd - 1, &devices.infds);
|
|
||||||
} else /* Send LHREQ_BREAK command. */
|
|
||||||
pwrite(lguest_fd, args, sizeof(args), cpu_id);
|
|
||||||
}
|
}
|
||||||
|
return 0;
|
||||||
}
|
}
|
||||||
|
|
||||||
/* This routine just sets up a pipe to the Waker process. */
|
/* This routine just sets up a pipe to the Waker process. */
|
||||||
static int setup_waker(int lguest_fd)
|
static void setup_waker(int lguest_fd)
|
||||||
{
|
{
|
||||||
int pipefd[2], child;
|
/* This pipe is closed when Launcher dies, telling Waker. */
|
||||||
|
if (pipe(waker_fds.pipe) != 0)
|
||||||
|
err(1, "Creating pipe for Waker");
|
||||||
|
|
||||||
/* We create a pipe to talk to the Waker, and also so it knows when the
|
/* Waker also needs to know the lguest fd */
|
||||||
* Launcher dies (and closes pipe). */
|
waker_fds.lguest_fd = lguest_fd;
|
||||||
pipe(pipefd);
|
|
||||||
child = fork();
|
|
||||||
if (child == -1)
|
|
||||||
err(1, "forking");
|
|
||||||
|
|
||||||
if (child == 0) {
|
if (clone(waker, malloc(4096) + 4096, CLONE_VM | SIGCHLD, NULL) == -1)
|
||||||
/* We are the Waker: close the "writing" end of our copy of the
|
err(1, "Creating Waker");
|
||||||
* pipe and start waiting for input. */
|
|
||||||
close(pipefd[1]);
|
|
||||||
wake_parent(pipefd[0], lguest_fd);
|
|
||||||
}
|
|
||||||
/* Close the reading end of our copy of the pipe. */
|
|
||||||
close(pipefd[0]);
|
|
||||||
|
|
||||||
/* Here is the fd used to talk to the waker. */
|
|
||||||
return pipefd[1];
|
|
||||||
}
|
}
|
||||||
|
|
||||||
/*
|
/*
|
||||||
|
@ -661,19 +699,22 @@ static unsigned get_vq_desc(struct virtqueue *vq,
|
||||||
unsigned int *out_num, unsigned int *in_num)
|
unsigned int *out_num, unsigned int *in_num)
|
||||||
{
|
{
|
||||||
unsigned int i, head;
|
unsigned int i, head;
|
||||||
|
u16 last_avail;
|
||||||
|
|
||||||
/* Check it isn't doing very strange things with descriptor numbers. */
|
/* Check it isn't doing very strange things with descriptor numbers. */
|
||||||
if ((u16)(vq->vring.avail->idx - vq->last_avail_idx) > vq->vring.num)
|
last_avail = lg_last_avail(vq);
|
||||||
|
if ((u16)(vq->vring.avail->idx - last_avail) > vq->vring.num)
|
||||||
errx(1, "Guest moved used index from %u to %u",
|
errx(1, "Guest moved used index from %u to %u",
|
||||||
vq->last_avail_idx, vq->vring.avail->idx);
|
last_avail, vq->vring.avail->idx);
|
||||||
|
|
||||||
/* If there's nothing new since last we looked, return invalid. */
|
/* If there's nothing new since last we looked, return invalid. */
|
||||||
if (vq->vring.avail->idx == vq->last_avail_idx)
|
if (vq->vring.avail->idx == last_avail)
|
||||||
return vq->vring.num;
|
return vq->vring.num;
|
||||||
|
|
||||||
/* Grab the next descriptor number they're advertising, and increment
|
/* Grab the next descriptor number they're advertising, and increment
|
||||||
* the index we've seen. */
|
* the index we've seen. */
|
||||||
head = vq->vring.avail->ring[vq->last_avail_idx++ % vq->vring.num];
|
head = vq->vring.avail->ring[last_avail % vq->vring.num];
|
||||||
|
lg_last_avail(vq)++;
|
||||||
|
|
||||||
/* If their number is silly, that's a fatal mistake. */
|
/* If their number is silly, that's a fatal mistake. */
|
||||||
if (head >= vq->vring.num)
|
if (head >= vq->vring.num)
|
||||||
|
@ -821,8 +862,8 @@ static bool handle_console_input(int fd, struct device *dev)
|
||||||
unsigned long args[] = { LHREQ_BREAK, 0 };
|
unsigned long args[] = { LHREQ_BREAK, 0 };
|
||||||
/* Close the fd so Waker will know it has to
|
/* Close the fd so Waker will know it has to
|
||||||
* exit. */
|
* exit. */
|
||||||
close(waker_fd);
|
close(waker_fds.pipe[1]);
|
||||||
/* Just in case waker is blocked in BREAK, send
|
/* Just in case Waker is blocked in BREAK, send
|
||||||
* unbreak now. */
|
* unbreak now. */
|
||||||
write(fd, args, sizeof(args));
|
write(fd, args, sizeof(args));
|
||||||
exit(2);
|
exit(2);
|
||||||
|
@ -839,7 +880,7 @@ static bool handle_console_input(int fd, struct device *dev)
|
||||||
|
|
||||||
/* Handling output for console is simple: we just get all the output buffers
|
/* Handling output for console is simple: we just get all the output buffers
|
||||||
* and write them to stdout. */
|
* and write them to stdout. */
|
||||||
static void handle_console_output(int fd, struct virtqueue *vq)
|
static void handle_console_output(int fd, struct virtqueue *vq, bool timeout)
|
||||||
{
|
{
|
||||||
unsigned int head, out, in;
|
unsigned int head, out, in;
|
||||||
int len;
|
int len;
|
||||||
|
@ -854,6 +895,21 @@ static void handle_console_output(int fd, struct virtqueue *vq)
|
||||||
}
|
}
|
||||||
}
|
}
|
||||||
|
|
||||||
|
static void block_vq(struct virtqueue *vq)
|
||||||
|
{
|
||||||
|
struct itimerval itm;
|
||||||
|
|
||||||
|
vq->vring.used->flags |= VRING_USED_F_NO_NOTIFY;
|
||||||
|
vq->blocked = true;
|
||||||
|
|
||||||
|
itm.it_interval.tv_sec = 0;
|
||||||
|
itm.it_interval.tv_usec = 0;
|
||||||
|
itm.it_value.tv_sec = 0;
|
||||||
|
itm.it_value.tv_usec = timeout_usec;
|
||||||
|
|
||||||
|
setitimer(ITIMER_REAL, &itm, NULL);
|
||||||
|
}
|
||||||
|
|
||||||
/*
|
/*
|
||||||
* The Network
|
* The Network
|
||||||
*
|
*
|
||||||
|
@ -861,22 +917,34 @@ static void handle_console_output(int fd, struct virtqueue *vq)
|
||||||
* and write them (ignoring the first element) to this device's file descriptor
|
* and write them (ignoring the first element) to this device's file descriptor
|
||||||
* (/dev/net/tun).
|
* (/dev/net/tun).
|
||||||
*/
|
*/
|
||||||
static void handle_net_output(int fd, struct virtqueue *vq)
|
static void handle_net_output(int fd, struct virtqueue *vq, bool timeout)
|
||||||
{
|
{
|
||||||
unsigned int head, out, in;
|
unsigned int head, out, in, num = 0;
|
||||||
int len;
|
int len;
|
||||||
struct iovec iov[vq->vring.num];
|
struct iovec iov[vq->vring.num];
|
||||||
|
static int last_timeout_num;
|
||||||
|
|
||||||
/* Keep getting output buffers from the Guest until we run out. */
|
/* Keep getting output buffers from the Guest until we run out. */
|
||||||
while ((head = get_vq_desc(vq, iov, &out, &in)) != vq->vring.num) {
|
while ((head = get_vq_desc(vq, iov, &out, &in)) != vq->vring.num) {
|
||||||
if (in)
|
if (in)
|
||||||
errx(1, "Input buffers in output queue?");
|
errx(1, "Input buffers in output queue?");
|
||||||
/* Check header, but otherwise ignore it (we told the Guest we
|
len = writev(vq->dev->fd, iov, out);
|
||||||
* supported no features, so it shouldn't have anything
|
if (len < 0)
|
||||||
* interesting). */
|
err(1, "Writing network packet to tun");
|
||||||
(void)convert(&iov[0], struct virtio_net_hdr);
|
|
||||||
len = writev(vq->dev->fd, iov+1, out-1);
|
|
||||||
add_used_and_trigger(fd, vq, head, len);
|
add_used_and_trigger(fd, vq, head, len);
|
||||||
|
num++;
|
||||||
|
}
|
||||||
|
|
||||||
|
/* Block further kicks and set up a timer if we saw anything. */
|
||||||
|
if (!timeout && num)
|
||||||
|
block_vq(vq);
|
||||||
|
|
||||||
|
if (timeout) {
|
||||||
|
if (num < last_timeout_num)
|
||||||
|
timeout_usec += 10;
|
||||||
|
else if (timeout_usec > 1)
|
||||||
|
timeout_usec--;
|
||||||
|
last_timeout_num = num;
|
||||||
}
|
}
|
||||||
}
|
}
|
||||||
|
|
||||||
|
@ -887,7 +955,6 @@ static bool handle_tun_input(int fd, struct device *dev)
|
||||||
unsigned int head, in_num, out_num;
|
unsigned int head, in_num, out_num;
|
||||||
int len;
|
int len;
|
||||||
struct iovec iov[dev->vq->vring.num];
|
struct iovec iov[dev->vq->vring.num];
|
||||||
struct virtio_net_hdr *hdr;
|
|
||||||
|
|
||||||
/* First we need a network buffer from the Guests's recv virtqueue. */
|
/* First we need a network buffer from the Guests's recv virtqueue. */
|
||||||
head = get_vq_desc(dev->vq, iov, &out_num, &in_num);
|
head = get_vq_desc(dev->vq, iov, &out_num, &in_num);
|
||||||
|
@ -896,25 +963,23 @@ static bool handle_tun_input(int fd, struct device *dev)
|
||||||
* early, the Guest won't be ready yet. Wait until the device
|
* early, the Guest won't be ready yet. Wait until the device
|
||||||
* status says it's ready. */
|
* status says it's ready. */
|
||||||
/* FIXME: Actually want DRIVER_ACTIVE here. */
|
/* FIXME: Actually want DRIVER_ACTIVE here. */
|
||||||
if (dev->desc->status & VIRTIO_CONFIG_S_DRIVER_OK)
|
|
||||||
warn("network: no dma buffer!");
|
/* Now tell it we want to know if new things appear. */
|
||||||
|
dev->vq->vring.used->flags &= ~VRING_USED_F_NO_NOTIFY;
|
||||||
|
wmb();
|
||||||
|
|
||||||
/* We'll turn this back on if input buffers are registered. */
|
/* We'll turn this back on if input buffers are registered. */
|
||||||
return false;
|
return false;
|
||||||
} else if (out_num)
|
} else if (out_num)
|
||||||
errx(1, "Output buffers in network recv queue?");
|
errx(1, "Output buffers in network recv queue?");
|
||||||
|
|
||||||
/* First element is the header: we set it to 0 (no features). */
|
|
||||||
hdr = convert(&iov[0], struct virtio_net_hdr);
|
|
||||||
hdr->flags = 0;
|
|
||||||
hdr->gso_type = VIRTIO_NET_HDR_GSO_NONE;
|
|
||||||
|
|
||||||
/* Read the packet from the device directly into the Guest's buffer. */
|
/* Read the packet from the device directly into the Guest's buffer. */
|
||||||
len = readv(dev->fd, iov+1, in_num-1);
|
len = readv(dev->fd, iov, in_num);
|
||||||
if (len <= 0)
|
if (len <= 0)
|
||||||
err(1, "reading network");
|
err(1, "reading network");
|
||||||
|
|
||||||
/* Tell the Guest about the new packet. */
|
/* Tell the Guest about the new packet. */
|
||||||
add_used_and_trigger(fd, dev->vq, head, sizeof(*hdr) + len);
|
add_used_and_trigger(fd, dev->vq, head, len);
|
||||||
|
|
||||||
verbose("tun input packet len %i [%02x %02x] (%s)\n", len,
|
verbose("tun input packet len %i [%02x %02x] (%s)\n", len,
|
||||||
((u8 *)iov[1].iov_base)[0], ((u8 *)iov[1].iov_base)[1],
|
((u8 *)iov[1].iov_base)[0], ((u8 *)iov[1].iov_base)[1],
|
||||||
|
@ -927,11 +992,18 @@ static bool handle_tun_input(int fd, struct device *dev)
|
||||||
/*L:215 This is the callback attached to the network and console input
|
/*L:215 This is the callback attached to the network and console input
|
||||||
* virtqueues: it ensures we try again, in case we stopped console or net
|
* virtqueues: it ensures we try again, in case we stopped console or net
|
||||||
* delivery because Guest didn't have any buffers. */
|
* delivery because Guest didn't have any buffers. */
|
||||||
static void enable_fd(int fd, struct virtqueue *vq)
|
static void enable_fd(int fd, struct virtqueue *vq, bool timeout)
|
||||||
{
|
{
|
||||||
add_device_fd(vq->dev->fd);
|
add_device_fd(vq->dev->fd);
|
||||||
/* Tell waker to listen to it again */
|
/* Snap the Waker out of its select loop. */
|
||||||
write(waker_fd, &vq->dev->fd, sizeof(vq->dev->fd));
|
write(waker_fds.pipe[1], "", 1);
|
||||||
|
}
|
||||||
|
|
||||||
|
static void net_enable_fd(int fd, struct virtqueue *vq, bool timeout)
|
||||||
|
{
|
||||||
|
/* We don't need to know again when Guest refills receive buffer. */
|
||||||
|
vq->vring.used->flags |= VRING_USED_F_NO_NOTIFY;
|
||||||
|
enable_fd(fd, vq, timeout);
|
||||||
}
|
}
|
||||||
|
|
||||||
/* When the Guest tells us they updated the status field, we handle it. */
|
/* When the Guest tells us they updated the status field, we handle it. */
|
||||||
|
@ -951,7 +1023,7 @@ static void update_device_status(struct device *dev)
|
||||||
for (vq = dev->vq; vq; vq = vq->next) {
|
for (vq = dev->vq; vq; vq = vq->next) {
|
||||||
memset(vq->vring.desc, 0,
|
memset(vq->vring.desc, 0,
|
||||||
vring_size(vq->config.num, getpagesize()));
|
vring_size(vq->config.num, getpagesize()));
|
||||||
vq->last_avail_idx = 0;
|
lg_last_avail(vq) = 0;
|
||||||
}
|
}
|
||||||
} else if (dev->desc->status & VIRTIO_CONFIG_S_FAILED) {
|
} else if (dev->desc->status & VIRTIO_CONFIG_S_FAILED) {
|
||||||
warnx("Device %s configuration FAILED", dev->name);
|
warnx("Device %s configuration FAILED", dev->name);
|
||||||
|
@ -960,10 +1032,10 @@ static void update_device_status(struct device *dev)
|
||||||
|
|
||||||
verbose("Device %s OK: offered", dev->name);
|
verbose("Device %s OK: offered", dev->name);
|
||||||
for (i = 0; i < dev->desc->feature_len; i++)
|
for (i = 0; i < dev->desc->feature_len; i++)
|
||||||
verbose(" %08x", get_feature_bits(dev)[i]);
|
verbose(" %02x", get_feature_bits(dev)[i]);
|
||||||
verbose(", accepted");
|
verbose(", accepted");
|
||||||
for (i = 0; i < dev->desc->feature_len; i++)
|
for (i = 0; i < dev->desc->feature_len; i++)
|
||||||
verbose(" %08x", get_feature_bits(dev)
|
verbose(" %02x", get_feature_bits(dev)
|
||||||
[dev->desc->feature_len+i]);
|
[dev->desc->feature_len+i]);
|
||||||
|
|
||||||
if (dev->ready)
|
if (dev->ready)
|
||||||
|
@ -1000,7 +1072,7 @@ static void handle_output(int fd, unsigned long addr)
|
||||||
if (strcmp(vq->dev->name, "console") != 0)
|
if (strcmp(vq->dev->name, "console") != 0)
|
||||||
verbose("Output to %s\n", vq->dev->name);
|
verbose("Output to %s\n", vq->dev->name);
|
||||||
if (vq->handle_output)
|
if (vq->handle_output)
|
||||||
vq->handle_output(fd, vq);
|
vq->handle_output(fd, vq, false);
|
||||||
return;
|
return;
|
||||||
}
|
}
|
||||||
}
|
}
|
||||||
|
@ -1014,6 +1086,29 @@ static void handle_output(int fd, unsigned long addr)
|
||||||
strnlen(from_guest_phys(addr), guest_limit - addr));
|
strnlen(from_guest_phys(addr), guest_limit - addr));
|
||||||
}
|
}
|
||||||
|
|
||||||
|
static void handle_timeout(int fd)
|
||||||
|
{
|
||||||
|
char buf[32];
|
||||||
|
struct device *i;
|
||||||
|
struct virtqueue *vq;
|
||||||
|
|
||||||
|
/* Clear the pipe */
|
||||||
|
read(timeoutpipe[0], buf, sizeof(buf));
|
||||||
|
|
||||||
|
/* Check each device and virtqueue: flush blocked ones. */
|
||||||
|
for (i = devices.dev; i; i = i->next) {
|
||||||
|
for (vq = i->vq; vq; vq = vq->next) {
|
||||||
|
if (!vq->blocked)
|
||||||
|
continue;
|
||||||
|
|
||||||
|
vq->vring.used->flags &= ~VRING_USED_F_NO_NOTIFY;
|
||||||
|
vq->blocked = false;
|
||||||
|
if (vq->handle_output)
|
||||||
|
vq->handle_output(fd, vq, true);
|
||||||
|
}
|
||||||
|
}
|
||||||
|
}
|
||||||
|
|
||||||
/* This is called when the Waker wakes us up: check for incoming file
|
/* This is called when the Waker wakes us up: check for incoming file
|
||||||
* descriptors. */
|
* descriptors. */
|
||||||
static void handle_input(int fd)
|
static void handle_input(int fd)
|
||||||
|
@ -1024,16 +1119,20 @@ static void handle_input(int fd)
|
||||||
for (;;) {
|
for (;;) {
|
||||||
struct device *i;
|
struct device *i;
|
||||||
fd_set fds = devices.infds;
|
fd_set fds = devices.infds;
|
||||||
|
int num;
|
||||||
|
|
||||||
|
num = select(devices.max_infd+1, &fds, NULL, NULL, &poll);
|
||||||
|
/* Could get interrupted */
|
||||||
|
if (num < 0)
|
||||||
|
continue;
|
||||||
/* If nothing is ready, we're done. */
|
/* If nothing is ready, we're done. */
|
||||||
if (select(devices.max_infd+1, &fds, NULL, NULL, &poll) == 0)
|
if (num == 0)
|
||||||
break;
|
break;
|
||||||
|
|
||||||
/* Otherwise, call the device(s) which have readable file
|
/* Otherwise, call the device(s) which have readable file
|
||||||
* descriptors and a method of handling them. */
|
* descriptors and a method of handling them. */
|
||||||
for (i = devices.dev; i; i = i->next) {
|
for (i = devices.dev; i; i = i->next) {
|
||||||
if (i->handle_input && FD_ISSET(i->fd, &fds)) {
|
if (i->handle_input && FD_ISSET(i->fd, &fds)) {
|
||||||
int dev_fd;
|
|
||||||
if (i->handle_input(fd, i))
|
if (i->handle_input(fd, i))
|
||||||
continue;
|
continue;
|
||||||
|
|
||||||
|
@ -1043,13 +1142,12 @@ static void handle_input(int fd)
|
||||||
* buffers to deliver into. Console also uses
|
* buffers to deliver into. Console also uses
|
||||||
* it when it discovers that stdin is closed. */
|
* it when it discovers that stdin is closed. */
|
||||||
FD_CLR(i->fd, &devices.infds);
|
FD_CLR(i->fd, &devices.infds);
|
||||||
/* Tell waker to ignore it too, by sending a
|
|
||||||
* negative fd number (-1, since 0 is a valid
|
|
||||||
* FD number). */
|
|
||||||
dev_fd = -i->fd - 1;
|
|
||||||
write(waker_fd, &dev_fd, sizeof(dev_fd));
|
|
||||||
}
|
}
|
||||||
}
|
}
|
||||||
|
|
||||||
|
/* Is this the timeout fd? */
|
||||||
|
if (FD_ISSET(timeoutpipe[0], &fds))
|
||||||
|
handle_timeout(fd);
|
||||||
}
|
}
|
||||||
}
|
}
|
||||||
|
|
||||||
|
@ -1098,7 +1196,7 @@ static struct lguest_device_desc *new_dev_desc(u16 type)
|
||||||
/* Each device descriptor is followed by the description of its virtqueues. We
|
/* Each device descriptor is followed by the description of its virtqueues. We
|
||||||
* specify how many descriptors the virtqueue is to have. */
|
* specify how many descriptors the virtqueue is to have. */
|
||||||
static void add_virtqueue(struct device *dev, unsigned int num_descs,
|
static void add_virtqueue(struct device *dev, unsigned int num_descs,
|
||||||
void (*handle_output)(int fd, struct virtqueue *me))
|
void (*handle_output)(int, struct virtqueue *, bool))
|
||||||
{
|
{
|
||||||
unsigned int pages;
|
unsigned int pages;
|
||||||
struct virtqueue **i, *vq = malloc(sizeof(*vq));
|
struct virtqueue **i, *vq = malloc(sizeof(*vq));
|
||||||
|
@ -1114,6 +1212,7 @@ static void add_virtqueue(struct device *dev, unsigned int num_descs,
|
||||||
vq->last_avail_idx = 0;
|
vq->last_avail_idx = 0;
|
||||||
vq->dev = dev;
|
vq->dev = dev;
|
||||||
vq->inflight = 0;
|
vq->inflight = 0;
|
||||||
|
vq->blocked = false;
|
||||||
|
|
||||||
/* Initialize the configuration. */
|
/* Initialize the configuration. */
|
||||||
vq->config.num = num_descs;
|
vq->config.num = num_descs;
|
||||||
|
@ -1246,6 +1345,24 @@ static void setup_console(void)
|
||||||
}
|
}
|
||||||
/*:*/
|
/*:*/
|
||||||
|
|
||||||
|
static void timeout_alarm(int sig)
|
||||||
|
{
|
||||||
|
write(timeoutpipe[1], "", 1);
|
||||||
|
}
|
||||||
|
|
||||||
|
static void setup_timeout(void)
|
||||||
|
{
|
||||||
|
if (pipe(timeoutpipe) != 0)
|
||||||
|
err(1, "Creating timeout pipe");
|
||||||
|
|
||||||
|
if (fcntl(timeoutpipe[1], F_SETFL,
|
||||||
|
fcntl(timeoutpipe[1], F_GETFL) | O_NONBLOCK) != 0)
|
||||||
|
err(1, "Making timeout pipe nonblocking");
|
||||||
|
|
||||||
|
add_device_fd(timeoutpipe[0]);
|
||||||
|
signal(SIGALRM, timeout_alarm);
|
||||||
|
}
|
||||||
|
|
||||||
/*M:010 Inter-guest networking is an interesting area. Simplest is to have a
|
/*M:010 Inter-guest networking is an interesting area. Simplest is to have a
|
||||||
* --sharenet=<name> option which opens or creates a named pipe. This can be
|
* --sharenet=<name> option which opens or creates a named pipe. This can be
|
||||||
* used to send packets to another guest in a 1:1 manner.
|
* used to send packets to another guest in a 1:1 manner.
|
||||||
|
@ -1264,10 +1381,25 @@ static void setup_console(void)
|
||||||
|
|
||||||
static u32 str2ip(const char *ipaddr)
|
static u32 str2ip(const char *ipaddr)
|
||||||
{
|
{
|
||||||
unsigned int byte[4];
|
unsigned int b[4];
|
||||||
|
|
||||||
sscanf(ipaddr, "%u.%u.%u.%u", &byte[0], &byte[1], &byte[2], &byte[3]);
|
if (sscanf(ipaddr, "%u.%u.%u.%u", &b[0], &b[1], &b[2], &b[3]) != 4)
|
||||||
return (byte[0] << 24) | (byte[1] << 16) | (byte[2] << 8) | byte[3];
|
errx(1, "Failed to parse IP address '%s'", ipaddr);
|
||||||
|
return (b[0] << 24) | (b[1] << 16) | (b[2] << 8) | b[3];
|
||||||
|
}
|
||||||
|
|
||||||
|
static void str2mac(const char *macaddr, unsigned char mac[6])
|
||||||
|
{
|
||||||
|
unsigned int m[6];
|
||||||
|
if (sscanf(macaddr, "%02x:%02x:%02x:%02x:%02x:%02x",
|
||||||
|
&m[0], &m[1], &m[2], &m[3], &m[4], &m[5]) != 6)
|
||||||
|
errx(1, "Failed to parse mac address '%s'", macaddr);
|
||||||
|
mac[0] = m[0];
|
||||||
|
mac[1] = m[1];
|
||||||
|
mac[2] = m[2];
|
||||||
|
mac[3] = m[3];
|
||||||
|
mac[4] = m[4];
|
||||||
|
mac[5] = m[5];
|
||||||
}
|
}
|
||||||
|
|
||||||
/* This code is "adapted" from libbridge: it attaches the Host end of the
|
/* This code is "adapted" from libbridge: it attaches the Host end of the
|
||||||
|
@ -1288,6 +1420,7 @@ static void add_to_bridge(int fd, const char *if_name, const char *br_name)
|
||||||
errx(1, "interface %s does not exist!", if_name);
|
errx(1, "interface %s does not exist!", if_name);
|
||||||
|
|
||||||
strncpy(ifr.ifr_name, br_name, IFNAMSIZ);
|
strncpy(ifr.ifr_name, br_name, IFNAMSIZ);
|
||||||
|
ifr.ifr_name[IFNAMSIZ-1] = '\0';
|
||||||
ifr.ifr_ifindex = ifidx;
|
ifr.ifr_ifindex = ifidx;
|
||||||
if (ioctl(fd, SIOCBRADDIF, &ifr) < 0)
|
if (ioctl(fd, SIOCBRADDIF, &ifr) < 0)
|
||||||
err(1, "can't add %s to bridge %s", if_name, br_name);
|
err(1, "can't add %s to bridge %s", if_name, br_name);
|
||||||
|
@ -1296,64 +1429,90 @@ static void add_to_bridge(int fd, const char *if_name, const char *br_name)
|
||||||
/* This sets up the Host end of the network device with an IP address, brings
|
/* This sets up the Host end of the network device with an IP address, brings
|
||||||
* it up so packets will flow, the copies the MAC address into the hwaddr
|
* it up so packets will flow, the copies the MAC address into the hwaddr
|
||||||
* pointer. */
|
* pointer. */
|
||||||
static void configure_device(int fd, const char *devname, u32 ipaddr,
|
static void configure_device(int fd, const char *tapif, u32 ipaddr)
|
||||||
unsigned char hwaddr[6])
|
|
||||||
{
|
{
|
||||||
struct ifreq ifr;
|
struct ifreq ifr;
|
||||||
struct sockaddr_in *sin = (struct sockaddr_in *)&ifr.ifr_addr;
|
struct sockaddr_in *sin = (struct sockaddr_in *)&ifr.ifr_addr;
|
||||||
|
|
||||||
/* Don't read these incantations. Just cut & paste them like I did! */
|
|
||||||
memset(&ifr, 0, sizeof(ifr));
|
memset(&ifr, 0, sizeof(ifr));
|
||||||
strcpy(ifr.ifr_name, devname);
|
strcpy(ifr.ifr_name, tapif);
|
||||||
|
|
||||||
|
/* Don't read these incantations. Just cut & paste them like I did! */
|
||||||
sin->sin_family = AF_INET;
|
sin->sin_family = AF_INET;
|
||||||
sin->sin_addr.s_addr = htonl(ipaddr);
|
sin->sin_addr.s_addr = htonl(ipaddr);
|
||||||
if (ioctl(fd, SIOCSIFADDR, &ifr) != 0)
|
if (ioctl(fd, SIOCSIFADDR, &ifr) != 0)
|
||||||
err(1, "Setting %s interface address", devname);
|
err(1, "Setting %s interface address", tapif);
|
||||||
ifr.ifr_flags = IFF_UP;
|
ifr.ifr_flags = IFF_UP;
|
||||||
if (ioctl(fd, SIOCSIFFLAGS, &ifr) != 0)
|
if (ioctl(fd, SIOCSIFFLAGS, &ifr) != 0)
|
||||||
err(1, "Bringing interface %s up", devname);
|
err(1, "Bringing interface %s up", tapif);
|
||||||
|
}
|
||||||
|
|
||||||
|
static void get_mac(int fd, const char *tapif, unsigned char hwaddr[6])
|
||||||
|
{
|
||||||
|
struct ifreq ifr;
|
||||||
|
|
||||||
|
memset(&ifr, 0, sizeof(ifr));
|
||||||
|
strcpy(ifr.ifr_name, tapif);
|
||||||
|
|
||||||
/* SIOC stands for Socket I/O Control. G means Get (vs S for Set
|
/* SIOC stands for Socket I/O Control. G means Get (vs S for Set
|
||||||
* above). IF means Interface, and HWADDR is hardware address.
|
* above). IF means Interface, and HWADDR is hardware address.
|
||||||
* Simple! */
|
* Simple! */
|
||||||
if (ioctl(fd, SIOCGIFHWADDR, &ifr) != 0)
|
if (ioctl(fd, SIOCGIFHWADDR, &ifr) != 0)
|
||||||
err(1, "getting hw address for %s", devname);
|
err(1, "getting hw address for %s", tapif);
|
||||||
memcpy(hwaddr, ifr.ifr_hwaddr.sa_data, 6);
|
memcpy(hwaddr, ifr.ifr_hwaddr.sa_data, 6);
|
||||||
}
|
}
|
||||||
|
|
||||||
/*L:195 Our network is a Host<->Guest network. This can either use bridging or
|
static int get_tun_device(char tapif[IFNAMSIZ])
|
||||||
* routing, but the principle is the same: it uses the "tun" device to inject
|
|
||||||
* packets into the Host as if they came in from a normal network card. We
|
|
||||||
* just shunt packets between the Guest and the tun device. */
|
|
||||||
static void setup_tun_net(const char *arg)
|
|
||||||
{
|
{
|
||||||
struct device *dev;
|
|
||||||
struct ifreq ifr;
|
struct ifreq ifr;
|
||||||
int netfd, ipfd;
|
int netfd;
|
||||||
u32 ip;
|
|
||||||
const char *br_name = NULL;
|
/* Start with this zeroed. Messy but sure. */
|
||||||
struct virtio_net_config conf;
|
memset(&ifr, 0, sizeof(ifr));
|
||||||
|
|
||||||
/* We open the /dev/net/tun device and tell it we want a tap device. A
|
/* We open the /dev/net/tun device and tell it we want a tap device. A
|
||||||
* tap device is like a tun device, only somehow different. To tell
|
* tap device is like a tun device, only somehow different. To tell
|
||||||
* the truth, I completely blundered my way through this code, but it
|
* the truth, I completely blundered my way through this code, but it
|
||||||
* works now! */
|
* works now! */
|
||||||
netfd = open_or_die("/dev/net/tun", O_RDWR);
|
netfd = open_or_die("/dev/net/tun", O_RDWR);
|
||||||
memset(&ifr, 0, sizeof(ifr));
|
ifr.ifr_flags = IFF_TAP | IFF_NO_PI | IFF_VNET_HDR;
|
||||||
ifr.ifr_flags = IFF_TAP | IFF_NO_PI;
|
|
||||||
strcpy(ifr.ifr_name, "tap%d");
|
strcpy(ifr.ifr_name, "tap%d");
|
||||||
if (ioctl(netfd, TUNSETIFF, &ifr) != 0)
|
if (ioctl(netfd, TUNSETIFF, &ifr) != 0)
|
||||||
err(1, "configuring /dev/net/tun");
|
err(1, "configuring /dev/net/tun");
|
||||||
|
|
||||||
|
if (ioctl(netfd, TUNSETOFFLOAD,
|
||||||
|
TUN_F_CSUM|TUN_F_TSO4|TUN_F_TSO6|TUN_F_TSO_ECN) != 0)
|
||||||
|
err(1, "Could not set features for tun device");
|
||||||
|
|
||||||
/* We don't need checksums calculated for packets coming in this
|
/* We don't need checksums calculated for packets coming in this
|
||||||
* device: trust us! */
|
* device: trust us! */
|
||||||
ioctl(netfd, TUNSETNOCSUM, 1);
|
ioctl(netfd, TUNSETNOCSUM, 1);
|
||||||
|
|
||||||
|
memcpy(tapif, ifr.ifr_name, IFNAMSIZ);
|
||||||
|
return netfd;
|
||||||
|
}
|
||||||
|
|
||||||
|
/*L:195 Our network is a Host<->Guest network. This can either use bridging or
|
||||||
|
* routing, but the principle is the same: it uses the "tun" device to inject
|
||||||
|
* packets into the Host as if they came in from a normal network card. We
|
||||||
|
* just shunt packets between the Guest and the tun device. */
|
||||||
|
static void setup_tun_net(char *arg)
|
||||||
|
{
|
||||||
|
struct device *dev;
|
||||||
|
int netfd, ipfd;
|
||||||
|
u32 ip = INADDR_ANY;
|
||||||
|
bool bridging = false;
|
||||||
|
char tapif[IFNAMSIZ], *p;
|
||||||
|
struct virtio_net_config conf;
|
||||||
|
|
||||||
|
netfd = get_tun_device(tapif);
|
||||||
|
|
||||||
/* First we create a new network device. */
|
/* First we create a new network device. */
|
||||||
dev = new_device("net", VIRTIO_ID_NET, netfd, handle_tun_input);
|
dev = new_device("net", VIRTIO_ID_NET, netfd, handle_tun_input);
|
||||||
|
|
||||||
/* Network devices need a receive and a send queue, just like
|
/* Network devices need a receive and a send queue, just like
|
||||||
* console. */
|
* console. */
|
||||||
add_virtqueue(dev, VIRTQUEUE_NUM, enable_fd);
|
add_virtqueue(dev, VIRTQUEUE_NUM, net_enable_fd);
|
||||||
add_virtqueue(dev, VIRTQUEUE_NUM, handle_net_output);
|
add_virtqueue(dev, VIRTQUEUE_NUM, handle_net_output);
|
||||||
|
|
||||||
/* We need a socket to perform the magic network ioctls to bring up the
|
/* We need a socket to perform the magic network ioctls to bring up the
|
||||||
|
@ -1364,28 +1523,56 @@ static void setup_tun_net(const char *arg)
|
||||||
|
|
||||||
/* If the command line was --tunnet=bridge:<name> do bridging. */
|
/* If the command line was --tunnet=bridge:<name> do bridging. */
|
||||||
if (!strncmp(BRIDGE_PFX, arg, strlen(BRIDGE_PFX))) {
|
if (!strncmp(BRIDGE_PFX, arg, strlen(BRIDGE_PFX))) {
|
||||||
ip = INADDR_ANY;
|
arg += strlen(BRIDGE_PFX);
|
||||||
br_name = arg + strlen(BRIDGE_PFX);
|
bridging = true;
|
||||||
add_to_bridge(ipfd, ifr.ifr_name, br_name);
|
}
|
||||||
} else /* It is an IP address to set up the device with */
|
|
||||||
|
/* A mac address may follow the bridge name or IP address */
|
||||||
|
p = strchr(arg, ':');
|
||||||
|
if (p) {
|
||||||
|
str2mac(p+1, conf.mac);
|
||||||
|
*p = '\0';
|
||||||
|
} else {
|
||||||
|
p = arg + strlen(arg);
|
||||||
|
/* None supplied; query the randomly assigned mac. */
|
||||||
|
get_mac(ipfd, tapif, conf.mac);
|
||||||
|
}
|
||||||
|
|
||||||
|
/* arg is now either an IP address or a bridge name */
|
||||||
|
if (bridging)
|
||||||
|
add_to_bridge(ipfd, tapif, arg);
|
||||||
|
else
|
||||||
ip = str2ip(arg);
|
ip = str2ip(arg);
|
||||||
|
|
||||||
/* Set up the tun device, and get the mac address for the interface. */
|
/* Set up the tun device. */
|
||||||
configure_device(ipfd, ifr.ifr_name, ip, conf.mac);
|
configure_device(ipfd, tapif, ip);
|
||||||
|
|
||||||
/* Tell Guest what MAC address to use. */
|
/* Tell Guest what MAC address to use. */
|
||||||
add_feature(dev, VIRTIO_NET_F_MAC);
|
add_feature(dev, VIRTIO_NET_F_MAC);
|
||||||
add_feature(dev, VIRTIO_F_NOTIFY_ON_EMPTY);
|
add_feature(dev, VIRTIO_F_NOTIFY_ON_EMPTY);
|
||||||
|
/* Expect Guest to handle everything except UFO */
|
||||||
|
add_feature(dev, VIRTIO_NET_F_CSUM);
|
||||||
|
add_feature(dev, VIRTIO_NET_F_GUEST_CSUM);
|
||||||
|
add_feature(dev, VIRTIO_NET_F_MAC);
|
||||||
|
add_feature(dev, VIRTIO_NET_F_GUEST_TSO4);
|
||||||
|
add_feature(dev, VIRTIO_NET_F_GUEST_TSO6);
|
||||||
|
add_feature(dev, VIRTIO_NET_F_GUEST_ECN);
|
||||||
|
add_feature(dev, VIRTIO_NET_F_HOST_TSO4);
|
||||||
|
add_feature(dev, VIRTIO_NET_F_HOST_TSO6);
|
||||||
|
add_feature(dev, VIRTIO_NET_F_HOST_ECN);
|
||||||
set_config(dev, sizeof(conf), &conf);
|
set_config(dev, sizeof(conf), &conf);
|
||||||
|
|
||||||
/* We don't need the socket any more; setup is done. */
|
/* We don't need the socket any more; setup is done. */
|
||||||
close(ipfd);
|
close(ipfd);
|
||||||
|
|
||||||
verbose("device %u: tun net %u.%u.%u.%u\n",
|
devices.device_num++;
|
||||||
devices.device_num++,
|
|
||||||
(u8)(ip>>24),(u8)(ip>>16),(u8)(ip>>8),(u8)ip);
|
if (bridging)
|
||||||
if (br_name)
|
verbose("device %u: tun %s attached to bridge: %s\n",
|
||||||
verbose("attached to bridge: %s\n", br_name);
|
devices.device_num, tapif, arg);
|
||||||
|
else
|
||||||
|
verbose("device %u: tun %s: %s\n",
|
||||||
|
devices.device_num, tapif, arg);
|
||||||
}
|
}
|
||||||
|
|
||||||
/* Our block (disk) device should be really simple: the Guest asks for a block
|
/* Our block (disk) device should be really simple: the Guest asks for a block
|
||||||
|
@ -1550,7 +1737,7 @@ static bool handle_io_finish(int fd, struct device *dev)
|
||||||
}
|
}
|
||||||
|
|
||||||
/* When the Guest submits some I/O, we just need to wake the I/O thread. */
|
/* When the Guest submits some I/O, we just need to wake the I/O thread. */
|
||||||
static void handle_virtblk_output(int fd, struct virtqueue *vq)
|
static void handle_virtblk_output(int fd, struct virtqueue *vq, bool timeout)
|
||||||
{
|
{
|
||||||
struct vblk_info *vblk = vq->dev->priv;
|
struct vblk_info *vblk = vq->dev->priv;
|
||||||
char c = 0;
|
char c = 0;
|
||||||
|
@ -1621,6 +1808,64 @@ static void setup_block_file(const char *filename)
|
||||||
verbose("device %u: virtblock %llu sectors\n",
|
verbose("device %u: virtblock %llu sectors\n",
|
||||||
devices.device_num, le64_to_cpu(conf.capacity));
|
devices.device_num, le64_to_cpu(conf.capacity));
|
||||||
}
|
}
|
||||||
|
|
||||||
|
/* Our random number generator device reads from /dev/random into the Guest's
|
||||||
|
* input buffers. The usual case is that the Guest doesn't want random numbers
|
||||||
|
* and so has no buffers although /dev/random is still readable, whereas
|
||||||
|
* console is the reverse.
|
||||||
|
*
|
||||||
|
* The same logic applies, however. */
|
||||||
|
static bool handle_rng_input(int fd, struct device *dev)
|
||||||
|
{
|
||||||
|
int len;
|
||||||
|
unsigned int head, in_num, out_num, totlen = 0;
|
||||||
|
struct iovec iov[dev->vq->vring.num];
|
||||||
|
|
||||||
|
/* First we need a buffer from the Guests's virtqueue. */
|
||||||
|
head = get_vq_desc(dev->vq, iov, &out_num, &in_num);
|
||||||
|
|
||||||
|
/* If they're not ready for input, stop listening to this file
|
||||||
|
* descriptor. We'll start again once they add an input buffer. */
|
||||||
|
if (head == dev->vq->vring.num)
|
||||||
|
return false;
|
||||||
|
|
||||||
|
if (out_num)
|
||||||
|
errx(1, "Output buffers in rng?");
|
||||||
|
|
||||||
|
/* This is why we convert to iovecs: the readv() call uses them, and so
|
||||||
|
* it reads straight into the Guest's buffer. We loop to make sure we
|
||||||
|
* fill it. */
|
||||||
|
while (!iov_empty(iov, in_num)) {
|
||||||
|
len = readv(dev->fd, iov, in_num);
|
||||||
|
if (len <= 0)
|
||||||
|
err(1, "Read from /dev/random gave %i", len);
|
||||||
|
iov_consume(iov, in_num, len);
|
||||||
|
totlen += len;
|
||||||
|
}
|
||||||
|
|
||||||
|
/* Tell the Guest about the new input. */
|
||||||
|
add_used_and_trigger(fd, dev->vq, head, totlen);
|
||||||
|
|
||||||
|
/* Everything went OK! */
|
||||||
|
return true;
|
||||||
|
}
|
||||||
|
|
||||||
|
/* And this creates a "hardware" random number device for the Guest. */
|
||||||
|
static void setup_rng(void)
|
||||||
|
{
|
||||||
|
struct device *dev;
|
||||||
|
int fd;
|
||||||
|
|
||||||
|
fd = open_or_die("/dev/random", O_RDONLY);
|
||||||
|
|
||||||
|
/* The device responds to return from I/O thread. */
|
||||||
|
dev = new_device("rng", VIRTIO_ID_RNG, fd, handle_rng_input);
|
||||||
|
|
||||||
|
/* The device has one virtqueue, where the Guest places inbufs. */
|
||||||
|
add_virtqueue(dev, VIRTQUEUE_NUM, enable_fd);
|
||||||
|
|
||||||
|
verbose("device %u: rng\n", devices.device_num++);
|
||||||
|
}
|
||||||
/* That's the end of device setup. */
|
/* That's the end of device setup. */
|
||||||
|
|
||||||
/*L:230 Reboot is pretty easy: clean up and exec() the Launcher afresh. */
|
/*L:230 Reboot is pretty easy: clean up and exec() the Launcher afresh. */
|
||||||
|
@ -1628,11 +1873,12 @@ static void __attribute__((noreturn)) restart_guest(void)
|
||||||
{
|
{
|
||||||
unsigned int i;
|
unsigned int i;
|
||||||
|
|
||||||
/* Closing pipes causes the Waker thread and io_threads to die, and
|
/* Since we don't track all open fds, we simply close everything beyond
|
||||||
* closing /dev/lguest cleans up the Guest. Since we don't track all
|
* stderr. */
|
||||||
* open fds, we simply close everything beyond stderr. */
|
|
||||||
for (i = 3; i < FD_SETSIZE; i++)
|
for (i = 3; i < FD_SETSIZE; i++)
|
||||||
close(i);
|
close(i);
|
||||||
|
|
||||||
|
/* The exec automatically gets rid of the I/O and Waker threads. */
|
||||||
execv(main_args[0], main_args);
|
execv(main_args[0], main_args);
|
||||||
err(1, "Could not exec %s", main_args[0]);
|
err(1, "Could not exec %s", main_args[0]);
|
||||||
}
|
}
|
||||||
|
@ -1663,7 +1909,7 @@ static void __attribute__((noreturn)) run_guest(int lguest_fd)
|
||||||
/* ERESTART means that we need to reboot the guest */
|
/* ERESTART means that we need to reboot the guest */
|
||||||
} else if (errno == ERESTART) {
|
} else if (errno == ERESTART) {
|
||||||
restart_guest();
|
restart_guest();
|
||||||
/* EAGAIN means the Waker wanted us to look at some input.
|
/* EAGAIN means a signal (timeout).
|
||||||
* Anything else means a bug or incompatible change. */
|
* Anything else means a bug or incompatible change. */
|
||||||
} else if (errno != EAGAIN)
|
} else if (errno != EAGAIN)
|
||||||
err(1, "Running guest failed");
|
err(1, "Running guest failed");
|
||||||
|
@ -1691,13 +1937,14 @@ static struct option opts[] = {
|
||||||
{ "verbose", 0, NULL, 'v' },
|
{ "verbose", 0, NULL, 'v' },
|
||||||
{ "tunnet", 1, NULL, 't' },
|
{ "tunnet", 1, NULL, 't' },
|
||||||
{ "block", 1, NULL, 'b' },
|
{ "block", 1, NULL, 'b' },
|
||||||
|
{ "rng", 0, NULL, 'r' },
|
||||||
{ "initrd", 1, NULL, 'i' },
|
{ "initrd", 1, NULL, 'i' },
|
||||||
{ NULL },
|
{ NULL },
|
||||||
};
|
};
|
||||||
static void usage(void)
|
static void usage(void)
|
||||||
{
|
{
|
||||||
errx(1, "Usage: lguest [--verbose] "
|
errx(1, "Usage: lguest [--verbose] "
|
||||||
"[--tunnet=(<ipaddr>|bridge:<bridgename>)\n"
|
"[--tunnet=(<ipaddr>:<macaddr>|bridge:<bridgename>:<macaddr>)\n"
|
||||||
"|--block=<filename>|--initrd=<filename>]...\n"
|
"|--block=<filename>|--initrd=<filename>]...\n"
|
||||||
"<mem-in-mb> vmlinux [args...]");
|
"<mem-in-mb> vmlinux [args...]");
|
||||||
}
|
}
|
||||||
|
@ -1765,6 +2012,9 @@ int main(int argc, char *argv[])
|
||||||
case 'b':
|
case 'b':
|
||||||
setup_block_file(optarg);
|
setup_block_file(optarg);
|
||||||
break;
|
break;
|
||||||
|
case 'r':
|
||||||
|
setup_rng();
|
||||||
|
break;
|
||||||
case 'i':
|
case 'i':
|
||||||
initrd_name = optarg;
|
initrd_name = optarg;
|
||||||
break;
|
break;
|
||||||
|
@ -1783,6 +2033,9 @@ int main(int argc, char *argv[])
|
||||||
/* We always have a console device */
|
/* We always have a console device */
|
||||||
setup_console();
|
setup_console();
|
||||||
|
|
||||||
|
/* We can timeout waiting for Guest network transmit. */
|
||||||
|
setup_timeout();
|
||||||
|
|
||||||
/* Now we load the kernel */
|
/* Now we load the kernel */
|
||||||
start = load_kernel(open_or_die(argv[optind+1], O_RDONLY));
|
start = load_kernel(open_or_die(argv[optind+1], O_RDONLY));
|
||||||
|
|
||||||
|
@ -1826,10 +2079,10 @@ int main(int argc, char *argv[])
|
||||||
* /dev/lguest file descriptor. */
|
* /dev/lguest file descriptor. */
|
||||||
lguest_fd = tell_kernel(pgdir, start);
|
lguest_fd = tell_kernel(pgdir, start);
|
||||||
|
|
||||||
/* We fork off a child process, which wakes the Launcher whenever one
|
/* We clone off a thread, which wakes the Launcher whenever one of the
|
||||||
* of the input file descriptors needs attention. We call this the
|
* input file descriptors needs attention. We call this the Waker, and
|
||||||
* Waker, and we'll cover it in a moment. */
|
* we'll cover it in a moment. */
|
||||||
waker_fd = setup_waker(lguest_fd);
|
setup_waker(lguest_fd);
|
||||||
|
|
||||||
/* Finally, run the Guest. This doesn't return. */
|
/* Finally, run the Guest. This doesn't return. */
|
||||||
run_guest(lguest_fd);
|
run_guest(lguest_fd);
|
||||||
|
|
|
@ -36,7 +36,7 @@ It can be done by slightly modifying the standard atomic operations : only
|
||||||
their UP variant must be kept. It typically means removing LOCK prefix (on
|
their UP variant must be kept. It typically means removing LOCK prefix (on
|
||||||
i386 and x86_64) and any SMP sychronization barrier. If the architecture does
|
i386 and x86_64) and any SMP sychronization barrier. If the architecture does
|
||||||
not have a different behavior between SMP and UP, including asm-generic/local.h
|
not have a different behavior between SMP and UP, including asm-generic/local.h
|
||||||
in your archtecture's local.h is sufficient.
|
in your architecture's local.h is sufficient.
|
||||||
|
|
||||||
The local_t type is defined as an opaque signed long by embedding an
|
The local_t type is defined as an opaque signed long by embedding an
|
||||||
atomic_long_t inside a structure. This is made so a cast from this type to a
|
atomic_long_t inside a structure. This is made so a cast from this type to a
|
||||||
|
|
|
@ -236,6 +236,11 @@ All md devices contain:
|
||||||
writing the word for the desired state, however some states
|
writing the word for the desired state, however some states
|
||||||
cannot be explicitly set, and some transitions are not allowed.
|
cannot be explicitly set, and some transitions are not allowed.
|
||||||
|
|
||||||
|
Select/poll works on this file. All changes except between
|
||||||
|
active_idle and active (which can be frequent and are not
|
||||||
|
very interesting) are notified. active->active_idle is
|
||||||
|
reported if the metadata is externally managed.
|
||||||
|
|
||||||
clear
|
clear
|
||||||
No devices, no size, no level
|
No devices, no size, no level
|
||||||
Writing is equivalent to STOP_ARRAY ioctl
|
Writing is equivalent to STOP_ARRAY ioctl
|
||||||
|
@ -292,6 +297,10 @@ Each directory contains:
|
||||||
writemostly - device will only be subject to read
|
writemostly - device will only be subject to read
|
||||||
requests if there are no other options.
|
requests if there are no other options.
|
||||||
This applies only to raid1 arrays.
|
This applies only to raid1 arrays.
|
||||||
|
blocked - device has failed, metadata is "external",
|
||||||
|
and the failure hasn't been acknowledged yet.
|
||||||
|
Writes that would write to this device if
|
||||||
|
it were not faulty are blocked.
|
||||||
spare - device is working, but not a full member.
|
spare - device is working, but not a full member.
|
||||||
This includes spares that are in the process
|
This includes spares that are in the process
|
||||||
of being recovered to
|
of being recovered to
|
||||||
|
@ -301,6 +310,12 @@ Each directory contains:
|
||||||
Writing "remove" removes the device from the array.
|
Writing "remove" removes the device from the array.
|
||||||
Writing "writemostly" sets the writemostly flag.
|
Writing "writemostly" sets the writemostly flag.
|
||||||
Writing "-writemostly" clears the writemostly flag.
|
Writing "-writemostly" clears the writemostly flag.
|
||||||
|
Writing "blocked" sets the "blocked" flag.
|
||||||
|
Writing "-blocked" clear the "blocked" flag and allows writes
|
||||||
|
to complete.
|
||||||
|
|
||||||
|
This file responds to select/poll. Any change to 'faulty'
|
||||||
|
or 'blocked' causes an event.
|
||||||
|
|
||||||
errors
|
errors
|
||||||
An approximate count of read errors that have been detected on
|
An approximate count of read errors that have been detected on
|
||||||
|
@ -332,7 +347,7 @@ Each directory contains:
|
||||||
for storage of data. This will normally be the same as the
|
for storage of data. This will normally be the same as the
|
||||||
component_size. This can be written while assembling an
|
component_size. This can be written while assembling an
|
||||||
array. If a value less than the current component_size is
|
array. If a value less than the current component_size is
|
||||||
written, component_size will be reduced to this value.
|
written, it will be rejected.
|
||||||
|
|
||||||
|
|
||||||
An active md device will also contain and entry for each active device
|
An active md device will also contain and entry for each active device
|
||||||
|
@ -381,6 +396,19 @@ also have
|
||||||
'check' and 'repair' will start the appropriate process
|
'check' and 'repair' will start the appropriate process
|
||||||
providing the current state is 'idle'.
|
providing the current state is 'idle'.
|
||||||
|
|
||||||
|
This file responds to select/poll. Any important change in the value
|
||||||
|
triggers a poll event. Sometimes the value will briefly be
|
||||||
|
"recover" if a recovery seems to be needed, but cannot be
|
||||||
|
achieved. In that case, the transition to "recover" isn't
|
||||||
|
notified, but the transition away is.
|
||||||
|
|
||||||
|
degraded
|
||||||
|
This contains a count of the number of devices by which the
|
||||||
|
arrays is degraded. So an optimal array with show '0'. A
|
||||||
|
single failed/missing drive will show '1', etc.
|
||||||
|
This file responds to select/poll, any increase or decrease
|
||||||
|
in the count of missing devices will trigger an event.
|
||||||
|
|
||||||
mismatch_count
|
mismatch_count
|
||||||
When performing 'check' and 'repair', and possibly when
|
When performing 'check' and 'repair', and possibly when
|
||||||
performing 'resync', md will count the number of errors that are
|
performing 'resync', md will count the number of errors that are
|
||||||
|
|
|
@ -1,14 +1,22 @@
|
||||||
=============================================================================
|
=============================================================================
|
||||||
|
MOXA Smartio/Industio Family Device Driver Installation Guide
|
||||||
|
for Linux Kernel 2.4.x, 2.6.x
|
||||||
|
Copyright (C) 2008, Moxa Inc.
|
||||||
|
=============================================================================
|
||||||
|
Date: 01/21/2008
|
||||||
|
|
||||||
MOXA Smartio Family Device Driver Ver 1.1 Installation Guide
|
|
||||||
for Linux Kernel 2.2.x and 2.0.3x
|
|
||||||
Copyright (C) 1999, Moxa Technologies Co, Ltd.
|
|
||||||
=============================================================================
|
|
||||||
Content
|
Content
|
||||||
|
|
||||||
1. Introduction
|
1. Introduction
|
||||||
2. System Requirement
|
2. System Requirement
|
||||||
3. Installation
|
3. Installation
|
||||||
|
3.1 Hardware installation
|
||||||
|
3.2 Driver files
|
||||||
|
3.3 Device naming convention
|
||||||
|
3.4 Module driver configuration
|
||||||
|
3.5 Static driver configuration for Linux kernel 2.4.x and 2.6.x.
|
||||||
|
3.6 Custom configuration
|
||||||
|
3.7 Verify driver installation
|
||||||
4. Utilities
|
4. Utilities
|
||||||
5. Setserial
|
5. Setserial
|
||||||
6. Troubleshooting
|
6. Troubleshooting
|
||||||
|
@ -16,27 +24,48 @@ Content
|
||||||
-----------------------------------------------------------------------------
|
-----------------------------------------------------------------------------
|
||||||
1. Introduction
|
1. Introduction
|
||||||
|
|
||||||
The Smartio family Linux driver, Ver. 1.1, supports following multiport
|
The Smartio/Industio/UPCI family Linux driver supports following multiport
|
||||||
boards.
|
boards.
|
||||||
|
|
||||||
-C104P/H/HS, C104H/PCI, C104HS/PCI, CI-104J 4 port multiport board.
|
- 2 ports multiport board
|
||||||
-C168P/H/HS, C168H/PCI 8 port multiport board.
|
CP-102U, CP-102UL, CP-102UF
|
||||||
|
CP-132U-I, CP-132UL,
|
||||||
|
CP-132, CP-132I, CP132S, CP-132IS,
|
||||||
|
CI-132, CI-132I, CI-132IS,
|
||||||
|
(C102H, C102HI, C102HIS, C102P, CP-102, CP-102S)
|
||||||
|
|
||||||
This driver has been modified a little and cleaned up from the Moxa
|
- 4 ports multiport board
|
||||||
contributed driver code and merged into Linux 2.2.14pre. In particular
|
CP-104EL,
|
||||||
official major/minor numbers have been assigned which are different to
|
CP-104UL, CP-104JU,
|
||||||
those the original Moxa supplied driver used.
|
CP-134U, CP-134U-I,
|
||||||
|
C104H/PCI, C104HS/PCI,
|
||||||
|
CP-114, CP-114I, CP-114S, CP-114IS, CP-114UL,
|
||||||
|
C104H, C104HS,
|
||||||
|
CI-104J, CI-104JS,
|
||||||
|
CI-134, CI-134I, CI-134IS,
|
||||||
|
(C114HI, CT-114I, C104P)
|
||||||
|
POS-104UL,
|
||||||
|
CB-114,
|
||||||
|
CB-134I
|
||||||
|
|
||||||
|
- 8 ports multiport board
|
||||||
|
CP-118EL, CP-168EL,
|
||||||
|
CP-118U, CP-168U,
|
||||||
|
C168H/PCI,
|
||||||
|
C168H, C168HS,
|
||||||
|
(C168P),
|
||||||
|
CB-108
|
||||||
|
|
||||||
This driver and installation procedure have been developed upon Linux Kernel
|
This driver and installation procedure have been developed upon Linux Kernel
|
||||||
2.2.5 and backward compatible to 2.0.3x. This driver supports Intel x86 and
|
2.4.x and 2.6.x. This driver supports Intel x86 hardware platform. In order
|
||||||
Alpha hardware platform. In order to maintain compatibility, this version
|
to maintain compatibility, this version has also been properly tested with
|
||||||
has also been properly tested with RedHat, OpenLinux, TurboLinux and
|
RedHat, Mandrake, Fedora and S.u.S.E Linux. However, if compatibility problem
|
||||||
S.u.S.E Linux. However, if compatibility problem occurs, please contact
|
occurs, please contact Moxa at support@moxa.com.tw.
|
||||||
Moxa at support@moxa.com.tw.
|
|
||||||
|
|
||||||
In addition to device driver, useful utilities are also provided in this
|
In addition to device driver, useful utilities are also provided in this
|
||||||
version. They are
|
version. They are
|
||||||
- msdiag Diagnostic program for detecting installed Moxa Smartio boards.
|
- msdiag Diagnostic program for displaying installed Moxa
|
||||||
|
Smartio/Industio boards.
|
||||||
- msmon Monitor program to observe data count and line status signals.
|
- msmon Monitor program to observe data count and line status signals.
|
||||||
- msterm A simple terminal program which is useful in testing serial
|
- msterm A simple terminal program which is useful in testing serial
|
||||||
ports.
|
ports.
|
||||||
|
@ -47,8 +76,7 @@ Content
|
||||||
GNU General Public License in this version. Please refer to GNU General
|
GNU General Public License in this version. Please refer to GNU General
|
||||||
Public License announcement in each source code file for more detail.
|
Public License announcement in each source code file for more detail.
|
||||||
|
|
||||||
In Moxa's ftp sites, you may always find latest driver at
|
In Moxa's Web sites, you may always find latest driver at http://web.moxa.com.
|
||||||
ftp://ftp.moxa.com or ftp://ftp.moxa.com.tw.
|
|
||||||
|
|
||||||
This version of driver can be installed as Loadable Module (Module driver)
|
This version of driver can be installed as Loadable Module (Module driver)
|
||||||
or built-in into kernel (Static driver). You may refer to following
|
or built-in into kernel (Static driver). You may refer to following
|
||||||
|
@ -61,8 +89,8 @@ Content
|
||||||
|
|
||||||
-----------------------------------------------------------------------------
|
-----------------------------------------------------------------------------
|
||||||
2. System Requirement
|
2. System Requirement
|
||||||
- Hardware platform: Intel x86 or Alpha machine
|
- Hardware platform: Intel x86 machine
|
||||||
- Kernel version: 2.0.3x or 2.2.x
|
- Kernel version: 2.4.x or 2.6.x
|
||||||
- gcc version 2.72 or later
|
- gcc version 2.72 or later
|
||||||
- Maximum 4 boards can be installed in combination
|
- Maximum 4 boards can be installed in combination
|
||||||
|
|
||||||
|
@ -70,9 +98,18 @@ Content
|
||||||
3. Installation
|
3. Installation
|
||||||
|
|
||||||
3.1 Hardware installation
|
3.1 Hardware installation
|
||||||
|
3.2 Driver files
|
||||||
|
3.3 Device naming convention
|
||||||
|
3.4 Module driver configuration
|
||||||
|
3.5 Static driver configuration for Linux kernel 2.4.x, 2.6.x.
|
||||||
|
3.6 Custom configuration
|
||||||
|
3.7 Verify driver installation
|
||||||
|
|
||||||
There are two types of buses, ISA and PCI, for Smartio family multiport
|
|
||||||
board.
|
3.1 Hardware installation
|
||||||
|
|
||||||
|
There are two types of buses, ISA and PCI, for Smartio/Industio
|
||||||
|
family multiport board.
|
||||||
|
|
||||||
ISA board
|
ISA board
|
||||||
---------
|
---------
|
||||||
|
@ -81,47 +118,57 @@ Content
|
||||||
installation procedure in User's Manual before proceed any further.
|
installation procedure in User's Manual before proceed any further.
|
||||||
Please make sure the JP1 is open after the ISA board is set properly.
|
Please make sure the JP1 is open after the ISA board is set properly.
|
||||||
|
|
||||||
PCI board
|
PCI/UPCI board
|
||||||
---------
|
--------------
|
||||||
You may need to adjust IRQ usage in BIOS to avoid from IRQ conflict
|
You may need to adjust IRQ usage in BIOS to avoid from IRQ conflict
|
||||||
with other ISA devices. Please refer to hardware installation
|
with other ISA devices. Please refer to hardware installation
|
||||||
procedure in User's Manual in advance.
|
procedure in User's Manual in advance.
|
||||||
|
|
||||||
IRQ Sharing
|
PCI IRQ Sharing
|
||||||
-----------
|
-----------
|
||||||
Each port within the same multiport board shares the same IRQ. Up to
|
Each port within the same multiport board shares the same IRQ. Up to
|
||||||
4 Moxa Smartio Family multiport boards can be installed together on
|
4 Moxa Smartio/Industio PCI Family multiport boards can be installed
|
||||||
one system and they can share the same IRQ.
|
together on one system and they can share the same IRQ.
|
||||||
|
|
||||||
3.2 Driver files and device naming convention
|
|
||||||
|
3.2 Driver files
|
||||||
|
|
||||||
The driver file may be obtained from ftp, CD-ROM or floppy disk. The
|
The driver file may be obtained from ftp, CD-ROM or floppy disk. The
|
||||||
first step, anyway, is to copy driver file "mxser.tgz" into specified
|
first step, anyway, is to copy driver file "mxser.tgz" into specified
|
||||||
directory. e.g. /moxa. The execute commands as below.
|
directory. e.g. /moxa. The execute commands as below.
|
||||||
|
|
||||||
|
# cd /
|
||||||
|
# mkdir moxa
|
||||||
# cd /moxa
|
# cd /moxa
|
||||||
# tar xvf /dev/fd0
|
# tar xvf /dev/fd0
|
||||||
|
|
||||||
or
|
or
|
||||||
|
|
||||||
|
# cd /
|
||||||
|
# mkdir moxa
|
||||||
# cd /moxa
|
# cd /moxa
|
||||||
# cp /mnt/cdrom/<driver directory>/mxser.tgz .
|
# cp /mnt/cdrom/<driver directory>/mxser.tgz .
|
||||||
# tar xvfz mxser.tgz
|
# tar xvfz mxser.tgz
|
||||||
|
|
||||||
|
|
||||||
|
3.3 Device naming convention
|
||||||
|
|
||||||
You may find all the driver and utilities files in /moxa/mxser.
|
You may find all the driver and utilities files in /moxa/mxser.
|
||||||
Following installation procedure depends on the model you'd like to
|
Following installation procedure depends on the model you'd like to
|
||||||
run the driver. If you prefer module driver, please refer to 3.3.
|
run the driver. If you prefer module driver, please refer to 3.4.
|
||||||
If static driver is required, please refer to 3.4.
|
If static driver is required, please refer to 3.5.
|
||||||
|
|
||||||
Dialin and callout port
|
Dialin and callout port
|
||||||
-----------------------
|
-----------------------
|
||||||
This driver remains traditional serial device properties. There're
|
This driver remains traditional serial device properties. There are
|
||||||
two special file name for each serial port. One is dial-in port
|
two special file name for each serial port. One is dial-in port
|
||||||
which is named "ttyMxx". For callout port, the naming convention
|
which is named "ttyMxx". For callout port, the naming convention
|
||||||
is "cumxx".
|
is "cumxx".
|
||||||
|
|
||||||
Device naming when more than 2 boards installed
|
Device naming when more than 2 boards installed
|
||||||
-----------------------------------------------
|
-----------------------------------------------
|
||||||
Naming convention for each Smartio multiport board is pre-defined
|
Naming convention for each Smartio/Industio multiport board is
|
||||||
as below.
|
pre-defined as below.
|
||||||
|
|
||||||
Board Num. Dial-in Port Callout port
|
Board Num. Dial-in Port Callout port
|
||||||
1st board ttyM0 - ttyM7 cum0 - cum7
|
1st board ttyM0 - ttyM7 cum0 - cum7
|
||||||
|
@ -129,6 +176,12 @@ Content
|
||||||
3rd board ttyM16 - ttyM23 cum16 - cum23
|
3rd board ttyM16 - ttyM23 cum16 - cum23
|
||||||
4th board ttyM24 - ttym31 cum24 - cum31
|
4th board ttyM24 - ttym31 cum24 - cum31
|
||||||
|
|
||||||
|
|
||||||
|
!!!!!!!!!!!!!!!!!!!! NOTE !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
|
||||||
|
Under Kernel 2.6 the cum Device is Obsolete. So use ttyM*
|
||||||
|
device instead.
|
||||||
|
!!!!!!!!!!!!!!!!!!!! NOTE !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
|
||||||
|
|
||||||
Board sequence
|
Board sequence
|
||||||
--------------
|
--------------
|
||||||
This driver will activate ISA boards according to the parameter set
|
This driver will activate ISA boards according to the parameter set
|
||||||
|
@ -138,69 +191,131 @@ Content
|
||||||
For PCI boards, their sequence will be after ISA boards and C168H/PCI
|
For PCI boards, their sequence will be after ISA boards and C168H/PCI
|
||||||
has higher priority than C104H/PCI boards.
|
has higher priority than C104H/PCI boards.
|
||||||
|
|
||||||
3.3 Module driver configuration
|
3.4 Module driver configuration
|
||||||
Module driver is easiest way to install. If you prefer static driver
|
Module driver is easiest way to install. If you prefer static driver
|
||||||
installation, please skip this paragraph.
|
installation, please skip this paragraph.
|
||||||
1. Find "Makefile" in /moxa/mxser, then run
|
|
||||||
|
|
||||||
# make install
|
|
||||||
|
|
||||||
The driver files "mxser.o" and utilities will be properly compiled
|
------------- Prepare to use the MOXA driver--------------------
|
||||||
and copied to system directories respectively.Then run
|
3.4.1 Create tty device with correct major number
|
||||||
|
Before using MOXA driver, your system must have the tty devices
|
||||||
|
which are created with driver's major number. We offer one shell
|
||||||
|
script "msmknod" to simplify the procedure.
|
||||||
|
This step is only needed to be executed once. But you still
|
||||||
|
need to do this procedure when:
|
||||||
|
a. You change the driver's major number. Please refer the "3.7"
|
||||||
|
section.
|
||||||
|
b. Your total installed MOXA boards number is changed. Maybe you
|
||||||
|
add/delete one MOXA board.
|
||||||
|
c. You want to change the tty name. This needs to modify the
|
||||||
|
shell script "msmknod"
|
||||||
|
|
||||||
# insmod mxser
|
The procedure is:
|
||||||
|
|
||||||
to activate the modular driver. You may run "lsmod" to check
|
|
||||||
if "mxser.o" is activated.
|
|
||||||
|
|
||||||
2. Create special files by executing "msmknod".
|
|
||||||
# cd /moxa/mxser/driver
|
# cd /moxa/mxser/driver
|
||||||
# ./msmknod
|
# ./msmknod
|
||||||
|
|
||||||
Default major numbers for dial-in device and callout device are
|
This shell script will require the major number for dial-in
|
||||||
174, 175. Msmknod will delete any special files occupying the same
|
device and callout device to create tty device. You also need
|
||||||
device naming.
|
to specify the total installed MOXA board number. Default major
|
||||||
|
numbers for dial-in device and callout device are 30, 35. If
|
||||||
|
you need to change to other number, please refer section "3.7"
|
||||||
|
for more detailed procedure.
|
||||||
|
Msmknod will delete any special files occupying the same device
|
||||||
|
naming.
|
||||||
|
|
||||||
3. Up to now, you may manually execute "insmod mxser" to activate
|
3.4.2 Build the MOXA driver and utilities
|
||||||
this driver and run "rmmod mxser" to remove it. However, it's
|
Before using the MOXA driver and utilities, you need compile the
|
||||||
better to have a boot time configuration to eliminate manual
|
all the source code. This step is only need to be executed once.
|
||||||
operation.
|
But you still re-compile the source code if you modify the source
|
||||||
Boot time configuration can be achieved by rc file. Run following
|
code. For example, if you change the driver's major number (see
|
||||||
command for setting rc files.
|
"3.7" section), then you need to do this step again.
|
||||||
|
|
||||||
|
Find "Makefile" in /moxa/mxser, then run
|
||||||
|
|
||||||
|
# make clean; make install
|
||||||
|
|
||||||
|
!!!!!!!!!! NOTE !!!!!!!!!!!!!!!!!
|
||||||
|
For Red Hat 9, Red Hat Enterprise Linux AS3/ES3/WS3 & Fedora Core1:
|
||||||
|
# make clean; make installsp1
|
||||||
|
|
||||||
|
For Red Hat Enterprise Linux AS4/ES4/WS4:
|
||||||
|
# make clean; make installsp2
|
||||||
|
!!!!!!!!!! NOTE !!!!!!!!!!!!!!!!!
|
||||||
|
|
||||||
|
The driver files "mxser.o" and utilities will be properly compiled
|
||||||
|
and copied to system directories respectively.
|
||||||
|
|
||||||
|
------------- Load MOXA driver--------------------
|
||||||
|
3.4.3 Load the MOXA driver
|
||||||
|
|
||||||
|
# modprobe mxser <argument>
|
||||||
|
|
||||||
|
will activate the module driver. You may run "lsmod" to check
|
||||||
|
if "mxser" is activated. If the MOXA board is ISA board, the
|
||||||
|
<argument> is needed. Please refer to section "3.4.5" for more
|
||||||
|
information.
|
||||||
|
|
||||||
|
|
||||||
|
------------- Load MOXA driver on boot --------------------
|
||||||
|
3.4.4 For the above description, you may manually execute
|
||||||
|
"modprobe mxser" to activate this driver and run
|
||||||
|
"rmmod mxser" to remove it.
|
||||||
|
However, it's better to have a boot time configuration to
|
||||||
|
eliminate manual operation. Boot time configuration can be
|
||||||
|
achieved by rc file. We offer one "rc.mxser" file to simplify
|
||||||
|
the procedure under "moxa/mxser/driver".
|
||||||
|
|
||||||
|
But if you use ISA board, please modify the "modprobe ..." command
|
||||||
|
to add the argument (see "3.4.5" section). After modifying the
|
||||||
|
rc.mxser, please try to execute "/moxa/mxser/driver/rc.mxser"
|
||||||
|
manually to make sure the modification is ok. If any error
|
||||||
|
encountered, please try to modify again. If the modification is
|
||||||
|
completed, follow the below step.
|
||||||
|
|
||||||
|
Run following command for setting rc files.
|
||||||
|
|
||||||
# cd /moxa/mxser/driver
|
# cd /moxa/mxser/driver
|
||||||
# cp ./rc.mxser /etc/rc.d
|
# cp ./rc.mxser /etc/rc.d
|
||||||
# cd /etc/rc.d
|
# cd /etc/rc.d
|
||||||
|
|
||||||
You may have to modify part of the content in rc.mxser to specify
|
Check "rc.serial" is existed or not. If "rc.serial" doesn't exist,
|
||||||
parameters for ISA board. Please refer to rc.mxser for more detail.
|
create it by vi, run "chmod 755 rc.serial" to change the permission.
|
||||||
Find "rc.serial". If "rc.serial" doesn't exist, create it by vi.
|
Add "/etc/rc.d/rc.mxser" in last line,
|
||||||
Add "rc.mxser" in last line. Next, open rc.local by vi
|
|
||||||
and append following content.
|
|
||||||
|
|
||||||
if [ -f /etc/rc.d/rc.serial ]; then
|
Reboot and check if moxa.o activated by "lsmod" command.
|
||||||
sh /etc/rc.d/rc.serial
|
|
||||||
fi
|
|
||||||
|
|
||||||
4. Reboot and check if mxser.o activated by "lsmod" command.
|
3.4.5. If you'd like to drive Smartio/Industio ISA boards in the system,
|
||||||
5. If you'd like to drive Smartio ISA boards in the system, you'll
|
you'll have to add parameter to specify CAP address of given
|
||||||
have to add parameter to specify CAP address of given board while
|
board while activating "mxser.o". The format for parameters are
|
||||||
activating "mxser.o". The format for parameters are as follows.
|
as follows.
|
||||||
|
|
||||||
insmod mxser ioaddr=0x???,0x???,0x???,0x???
|
modprobe mxser ioaddr=0x???,0x???,0x???,0x???
|
||||||
| | | |
|
| | | |
|
||||||
| | | +- 4th ISA board
|
| | | +- 4th ISA board
|
||||||
| | +------ 3rd ISA board
|
| | +------ 3rd ISA board
|
||||||
| +------------ 2nd ISA board
|
| +------------ 2nd ISA board
|
||||||
+------------------- 1st ISA board
|
+------------------- 1st ISA board
|
||||||
|
|
||||||
3.4 Static driver configuration
|
3.5 Static driver configuration for Linux kernel 2.4.x and 2.6.x
|
||||||
|
|
||||||
1. Create link
|
Note: To use static driver, you must install the linux kernel
|
||||||
|
source package.
|
||||||
|
|
||||||
|
3.5.1 Backup the built-in driver in the kernel.
|
||||||
|
# cd /usr/src/linux/drivers/char
|
||||||
|
# mv mxser.c mxser.c.old
|
||||||
|
|
||||||
|
For Red Hat 7.x user, you need to create link:
|
||||||
|
# cd /usr/src
|
||||||
|
# ln -s linux-2.4 linux
|
||||||
|
|
||||||
|
3.5.2 Create link
|
||||||
# cd /usr/src/linux/drivers/char
|
# cd /usr/src/linux/drivers/char
|
||||||
# ln -s /moxa/mxser/driver/mxser.c mxser.c
|
# ln -s /moxa/mxser/driver/mxser.c mxser.c
|
||||||
|
|
||||||
2. Add CAP address list for ISA boards
|
3.5.3 Add CAP address list for ISA boards. For PCI boards user,
|
||||||
|
please skip this step.
|
||||||
|
|
||||||
In module mode, the CAP address for ISA board is given by
|
In module mode, the CAP address for ISA board is given by
|
||||||
parameter. In static driver configuration, you'll have to
|
parameter. In static driver configuration, you'll have to
|
||||||
assign it within driver's source code. If you will not
|
assign it within driver's source code. If you will not
|
||||||
|
@ -222,73 +337,55 @@ Content
|
||||||
static int mxserBoardCAP[]
|
static int mxserBoardCAP[]
|
||||||
= {0x280, 0x180, 0x00, 0x00};
|
= {0x280, 0x180, 0x00, 0x00};
|
||||||
|
|
||||||
3. Modify tty_io.c
|
3.5.4 Setup kernel configuration
|
||||||
# cd /usr/src/linux/drivers/char/
|
|
||||||
# vi tty_io.c
|
|
||||||
Find pty_init(), insert "mxser_init()" as
|
|
||||||
|
|
||||||
pty_init();
|
Configure the kernel:
|
||||||
mxser_init();
|
|
||||||
|
|
||||||
4. Modify tty.h
|
# cd /usr/src/linux
|
||||||
# cd /usr/src/linux/include/linux
|
# make menuconfig
|
||||||
# vi tty.h
|
|
||||||
Find extern int tty_init(void), insert "mxser_init()" as
|
|
||||||
|
|
||||||
extern int tty_init(void);
|
You will go into a menu-driven system. Please select [Character
|
||||||
extern int mxser_init(void);
|
devices][Non-standard serial port support], enable the [Moxa
|
||||||
|
SmartIO support] driver with "[*]" for built-in (not "[M]"), then
|
||||||
5. Modify Makefile
|
select [Exit] to exit this program.
|
||||||
# cd /usr/src/linux/drivers/char
|
|
||||||
# vi Makefile
|
|
||||||
Find L_OBJS := tty_io.o ...... random.o, add
|
|
||||||
"mxser.o" at last of this line as
|
|
||||||
L_OBJS := tty_io.o ....... mxser.o
|
|
||||||
|
|
||||||
6. Rebuild kernel
|
3.5.5 Rebuild kernel
|
||||||
The following are for Linux kernel rebuilding,for your reference only.
|
The following are for Linux kernel rebuilding, for your
|
||||||
|
reference only.
|
||||||
For appropriate details, please refer to the Linux document.
|
For appropriate details, please refer to the Linux document.
|
||||||
|
|
||||||
If 'lilo' utility is installed, please use 'make zlilo' to rebuild
|
|
||||||
kernel. If 'lilo' is not installed, please follow the following steps.
|
|
||||||
|
|
||||||
a. cd /usr/src/linux
|
a. cd /usr/src/linux
|
||||||
b. make clean /* take a few minutes */
|
b. make clean /* take a few minutes */
|
||||||
c. make bzImage /* take probably 10-20 minutes */
|
c. make dep /* take a few minutes */
|
||||||
d. Backup original boot kernel. /* optional step */
|
d. make bzImage /* take probably 10-20 minutes */
|
||||||
e. cp /usr/src/linux/arch/i386/boot/bzImage /boot/vmlinuz
|
e. make install /* copy boot image to correct position */
|
||||||
f. Please make sure the boot kernel (vmlinuz) is in the
|
f. Please make sure the boot kernel (vmlinuz) is in the
|
||||||
correct position. If you use 'lilo' utility, you should
|
correct position.
|
||||||
check /etc/lilo.conf 'image' item specified the path
|
g. If you use 'lilo' utility, you should check /etc/lilo.conf
|
||||||
which is the 'vmlinuz' path, or you will load wrong
|
'image' item specified the path which is the 'vmlinuz' path,
|
||||||
(or old) boot kernel image (vmlinuz).
|
or you will load wrong (or old) boot kernel image (vmlinuz).
|
||||||
g. chmod 400 /vmlinuz
|
After checking /etc/lilo.conf, please run "lilo".
|
||||||
h. lilo
|
|
||||||
i. rdev -R /vmlinuz 1
|
|
||||||
j. sync
|
|
||||||
|
|
||||||
Note that if the result of "make zImage" is ERROR, then you have to
|
Note that if the result of "make bzImage" is ERROR, then you have to
|
||||||
go back to Linux configuration Setup. Type "make config" in directory
|
go back to Linux configuration Setup. Type "make menuconfig" in
|
||||||
/usr/src/linux or "setup".
|
directory /usr/src/linux.
|
||||||
|
|
||||||
Since system include file, /usr/src/linux/include/linux/interrupt.h,
|
|
||||||
is modified each time the MOXA driver is installed, kernel rebuilding
|
|
||||||
is inevitable. And it takes about 10 to 20 minutes depends on the
|
|
||||||
machine.
|
|
||||||
|
|
||||||
7. Make utility
|
3.5.6 Make tty device and special file
|
||||||
# cd /moxa/mxser/utility
|
|
||||||
# make install
|
|
||||||
|
|
||||||
8. Make special file
|
|
||||||
# cd /moxa/mxser/driver
|
# cd /moxa/mxser/driver
|
||||||
# ./msmknod
|
# ./msmknod
|
||||||
|
|
||||||
9. Reboot
|
3.5.7 Make utility
|
||||||
|
# cd /moxa/mxser/utility
|
||||||
|
# make clean; make install
|
||||||
|
|
||||||
3.5 Custom configuration
|
3.5.8 Reboot
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
3.6 Custom configuration
|
||||||
Although this driver already provides you default configuration, you
|
Although this driver already provides you default configuration, you
|
||||||
still can change the device name and major number.The instruction to
|
still can change the device name and major number. The instruction to
|
||||||
change these parameters are shown as below.
|
change these parameters are shown as below.
|
||||||
|
|
||||||
Change Device name
|
Change Device name
|
||||||
|
@ -306,33 +403,37 @@ Content
|
||||||
2 free major numbers for this driver. There are 3 steps to change
|
2 free major numbers for this driver. There are 3 steps to change
|
||||||
major numbers.
|
major numbers.
|
||||||
|
|
||||||
1. Find free major numbers
|
3.6.1 Find free major numbers
|
||||||
In /proc/devices, you may find all the major numbers occupied
|
In /proc/devices, you may find all the major numbers occupied
|
||||||
in the system. Please select 2 major numbers that are available.
|
in the system. Please select 2 major numbers that are available.
|
||||||
e.g. 40, 45.
|
e.g. 40, 45.
|
||||||
2. Create special files
|
3.6.2 Create special files
|
||||||
Run /moxa/mxser/driver/msmknod to create special files with
|
Run /moxa/mxser/driver/msmknod to create special files with
|
||||||
specified major numbers.
|
specified major numbers.
|
||||||
3. Modify driver with new major number
|
3.6.3 Modify driver with new major number
|
||||||
Run vi to open /moxa/mxser/driver/mxser.c. Locate the line
|
Run vi to open /moxa/mxser/driver/mxser.c. Locate the line
|
||||||
contains "MXSERMAJOR". Change the content as below.
|
contains "MXSERMAJOR". Change the content as below.
|
||||||
#define MXSERMAJOR 40
|
#define MXSERMAJOR 40
|
||||||
#define MXSERCUMAJOR 45
|
#define MXSERCUMAJOR 45
|
||||||
4. Run # make install in /moxa/mxser/driver.
|
3.6.4 Run "make clean; make install" in /moxa/mxser/driver.
|
||||||
|
|
||||||
3.6 Verify driver installation
|
3.7 Verify driver installation
|
||||||
You may refer to /var/log/messages to check the latest status
|
You may refer to /var/log/messages to check the latest status
|
||||||
log reported by this driver whenever it's activated.
|
log reported by this driver whenever it's activated.
|
||||||
|
|
||||||
-----------------------------------------------------------------------------
|
-----------------------------------------------------------------------------
|
||||||
4. Utilities
|
4. Utilities
|
||||||
There are 3 utilities contained in this driver. They are msdiag, msmon and
|
There are 3 utilities contained in this driver. They are msdiag, msmon and
|
||||||
msterm. These 3 utilities are released in form of source code. They should
|
msterm. These 3 utilities are released in form of source code. They should
|
||||||
be compiled into executable file and copied into /usr/bin.
|
be compiled into executable file and copied into /usr/bin.
|
||||||
|
|
||||||
|
Before using these utilities, please load driver (refer 3.4 & 3.5) and
|
||||||
|
make sure you had run the "msmknod" utility.
|
||||||
|
|
||||||
msdiag - Diagnostic
|
msdiag - Diagnostic
|
||||||
--------------------
|
--------------------
|
||||||
This utility provides the function to detect what Moxa Smartio multiport
|
This utility provides the function to display what Moxa Smartio/Industio
|
||||||
board exists in the system.
|
board found by driver in the system.
|
||||||
|
|
||||||
msmon - Port Monitoring
|
msmon - Port Monitoring
|
||||||
-----------------------
|
-----------------------
|
||||||
|
@ -353,12 +454,13 @@ Content
|
||||||
application, for example, sending AT command to a modem connected to the
|
application, for example, sending AT command to a modem connected to the
|
||||||
port or used as a terminal for login purpose. Note that this is only a
|
port or used as a terminal for login purpose. Note that this is only a
|
||||||
dumb terminal emulation without handling full screen operation.
|
dumb terminal emulation without handling full screen operation.
|
||||||
|
|
||||||
-----------------------------------------------------------------------------
|
-----------------------------------------------------------------------------
|
||||||
5. Setserial
|
5. Setserial
|
||||||
|
|
||||||
Supported Setserial parameters are listed as below.
|
Supported Setserial parameters are listed as below.
|
||||||
|
|
||||||
uart set UART type(16450-->disable FIFO, 16550A-->enable FIFO)
|
uart set UART type(16450-->disable FIFO, 16550A-->enable FIFO)
|
||||||
close_delay set the amount of time(in 1/100 of a second) that DTR
|
close_delay set the amount of time(in 1/100 of a second) that DTR
|
||||||
should be kept low while being closed.
|
should be kept low while being closed.
|
||||||
closing_wait set the amount of time(in 1/100 of a second) that the
|
closing_wait set the amount of time(in 1/100 of a second) that the
|
||||||
|
@ -366,7 +468,13 @@ Content
|
||||||
being closed, before the receiver is disable.
|
being closed, before the receiver is disable.
|
||||||
spd_hi Use 57.6kb when the application requests 38.4kb.
|
spd_hi Use 57.6kb when the application requests 38.4kb.
|
||||||
spd_vhi Use 115.2kb when the application requests 38.4kb.
|
spd_vhi Use 115.2kb when the application requests 38.4kb.
|
||||||
|
spd_shi Use 230.4kb when the application requests 38.4kb.
|
||||||
|
spd_warp Use 460.8kb when the application requests 38.4kb.
|
||||||
spd_normal Use 38.4kb when the application requests 38.4kb.
|
spd_normal Use 38.4kb when the application requests 38.4kb.
|
||||||
|
spd_cust Use the custom divisor to set the speed when the
|
||||||
|
application requests 38.4kb.
|
||||||
|
divisor This option set the custom divison.
|
||||||
|
baud_base This option set the base baud rate.
|
||||||
|
|
||||||
-----------------------------------------------------------------------------
|
-----------------------------------------------------------------------------
|
||||||
6. Troubleshooting
|
6. Troubleshooting
|
||||||
|
@ -375,8 +483,9 @@ Content
|
||||||
possible. If all the possible solutions fail, please contact our technical
|
possible. If all the possible solutions fail, please contact our technical
|
||||||
support team to get more help.
|
support team to get more help.
|
||||||
|
|
||||||
Error msg: More than 4 Moxa Smartio family boards found. Fifth board and
|
|
||||||
after are ignored.
|
Error msg: More than 4 Moxa Smartio/Industio family boards found. Fifth board
|
||||||
|
and after are ignored.
|
||||||
Solution:
|
Solution:
|
||||||
To avoid this problem, please unplug fifth and after board, because Moxa
|
To avoid this problem, please unplug fifth and after board, because Moxa
|
||||||
driver supports up to 4 boards.
|
driver supports up to 4 boards.
|
||||||
|
@ -384,7 +493,7 @@ Content
|
||||||
Error msg: Request_irq fail, IRQ(?) may be conflict with another device.
|
Error msg: Request_irq fail, IRQ(?) may be conflict with another device.
|
||||||
Solution:
|
Solution:
|
||||||
Other PCI or ISA devices occupy the assigned IRQ. If you are not sure
|
Other PCI or ISA devices occupy the assigned IRQ. If you are not sure
|
||||||
which device causes the situation,please check /proc/interrupts to find
|
which device causes the situation, please check /proc/interrupts to find
|
||||||
free IRQ and simply change another free IRQ for Moxa board.
|
free IRQ and simply change another free IRQ for Moxa board.
|
||||||
|
|
||||||
Error msg: Board #: C1xx Series(CAP=xxx) interrupt number invalid.
|
Error msg: Board #: C1xx Series(CAP=xxx) interrupt number invalid.
|
||||||
|
@ -397,15 +506,18 @@ Content
|
||||||
Moxa ISA board needs an interrupt vector.Please refer to user's manual
|
Moxa ISA board needs an interrupt vector.Please refer to user's manual
|
||||||
"Hardware Installation" chapter to set interrupt vector.
|
"Hardware Installation" chapter to set interrupt vector.
|
||||||
|
|
||||||
Error msg: Couldn't install MOXA Smartio family driver!
|
Error msg: Couldn't install MOXA Smartio/Industio family driver!
|
||||||
Solution:
|
Solution:
|
||||||
Load Moxa driver fail, the major number may conflict with other devices.
|
Load Moxa driver fail, the major number may conflict with other devices.
|
||||||
Please refer to previous section 3.5 to change a free major number for
|
Please refer to previous section 3.7 to change a free major number for
|
||||||
Moxa driver.
|
Moxa driver.
|
||||||
|
|
||||||
Error msg: Couldn't install MOXA Smartio family callout driver!
|
Error msg: Couldn't install MOXA Smartio/Industio family callout driver!
|
||||||
Solution:
|
Solution:
|
||||||
Load Moxa callout driver fail, the callout device major number may
|
Load Moxa callout driver fail, the callout device major number may
|
||||||
conflict with other devices. Please refer to previous section 3.5 to
|
conflict with other devices. Please refer to previous section 3.7 to
|
||||||
change a free callout device major number for Moxa driver.
|
change a free callout device major number for Moxa driver.
|
||||||
|
|
||||||
|
|
||||||
-----------------------------------------------------------------------------
|
-----------------------------------------------------------------------------
|
||||||
|
|
||||||
|
|
|
@ -631,7 +631,7 @@ xmit_hash_policy
|
||||||
in environments where a layer3 gateway device is
|
in environments where a layer3 gateway device is
|
||||||
required to reach most destinations.
|
required to reach most destinations.
|
||||||
|
|
||||||
This algorithm is 802.3ad complient.
|
This algorithm is 802.3ad compliant.
|
||||||
|
|
||||||
layer3+4
|
layer3+4
|
||||||
|
|
||||||
|
|
|
@ -186,7 +186,7 @@ solution for a couple of reasons:
|
||||||
|
|
||||||
The Linux network devices (by default) just can handle the
|
The Linux network devices (by default) just can handle the
|
||||||
transmission and reception of media dependent frames. Due to the
|
transmission and reception of media dependent frames. Due to the
|
||||||
arbritration on the CAN bus the transmission of a low prio CAN-ID
|
arbitration on the CAN bus the transmission of a low prio CAN-ID
|
||||||
may be delayed by the reception of a high prio CAN frame. To
|
may be delayed by the reception of a high prio CAN frame. To
|
||||||
reflect the correct* traffic on the node the loopback of the sent
|
reflect the correct* traffic on the node the loopback of the sent
|
||||||
data has to be performed right after a successful transmission. If
|
data has to be performed right after a successful transmission. If
|
||||||
|
@ -481,7 +481,7 @@ solution for a couple of reasons:
|
||||||
- stats_timer: To calculate the Socket CAN core statistics
|
- stats_timer: To calculate the Socket CAN core statistics
|
||||||
(e.g. current/maximum frames per second) this 1 second timer is
|
(e.g. current/maximum frames per second) this 1 second timer is
|
||||||
invoked at can.ko module start time by default. This timer can be
|
invoked at can.ko module start time by default. This timer can be
|
||||||
disabled by using stattimer=0 on the module comandline.
|
disabled by using stattimer=0 on the module commandline.
|
||||||
|
|
||||||
- debug: (removed since SocketCAN SVN r546)
|
- debug: (removed since SocketCAN SVN r546)
|
||||||
|
|
||||||
|
|
|
@ -513,21 +513,11 @@ Additional Configurations
|
||||||
Intel(R) PRO/1000 PT Dual Port Server Connection
|
Intel(R) PRO/1000 PT Dual Port Server Connection
|
||||||
Intel(R) PRO/1000 PT Dual Port Server Adapter
|
Intel(R) PRO/1000 PT Dual Port Server Adapter
|
||||||
Intel(R) PRO/1000 PF Dual Port Server Adapter
|
Intel(R) PRO/1000 PF Dual Port Server Adapter
|
||||||
Intel(R) PRO/1000 PT Quad Port Server Adapter
|
Intel(R) PRO/1000 PT Quad Port Server Adapter
|
||||||
|
|
||||||
NAPI
|
NAPI
|
||||||
----
|
----
|
||||||
NAPI (Rx polling mode) is supported in the e1000 driver. NAPI is enabled
|
NAPI (Rx polling mode) is enabled in the e1000 driver.
|
||||||
or disabled based on the configuration of the kernel. To override
|
|
||||||
the default, use the following compile-time flags.
|
|
||||||
|
|
||||||
To enable NAPI, compile the driver module, passing in a configuration option:
|
|
||||||
|
|
||||||
make CFLAGS_EXTRA=-DE1000_NAPI install
|
|
||||||
|
|
||||||
To disable NAPI, compile the driver module, passing in a configuration option:
|
|
||||||
|
|
||||||
make CFLAGS_EXTRA=-DE1000_NO_NAPI install
|
|
||||||
|
|
||||||
See www.cyberus.ca/~hadi/usenix-paper.tgz for more information on NAPI.
|
See www.cyberus.ca/~hadi/usenix-paper.tgz for more information on NAPI.
|
||||||
|
|
||||||
|
|
|
@ -326,7 +326,7 @@ just one call to mmap is needed:
|
||||||
mmap(0, size, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0);
|
mmap(0, size, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0);
|
||||||
|
|
||||||
If tp_frame_size is a divisor of tp_block_size frames will be
|
If tp_frame_size is a divisor of tp_block_size frames will be
|
||||||
contiguosly spaced by tp_frame_size bytes. If not, each
|
contiguously spaced by tp_frame_size bytes. If not, each
|
||||||
tp_block_size/tp_frame_size frames there will be a gap between
|
tp_block_size/tp_frame_size frames there will be a gap between
|
||||||
the frames. This is because a frame cannot be spawn across two
|
the frames. This is because a frame cannot be spawn across two
|
||||||
blocks.
|
blocks.
|
||||||
|
|
|
@ -4,26 +4,27 @@ The "enviromental" rules for authors of any new tc actions are:
|
||||||
1) If you stealeth or borroweth any packet thou shalt be branching
|
1) If you stealeth or borroweth any packet thou shalt be branching
|
||||||
from the righteous path and thou shalt cloneth.
|
from the righteous path and thou shalt cloneth.
|
||||||
|
|
||||||
For example if your action queues a packet to be processed later
|
For example if your action queues a packet to be processed later,
|
||||||
or intentionaly branches by redirecting a packet then you need to
|
or intentionally branches by redirecting a packet, then you need to
|
||||||
clone the packet.
|
clone the packet.
|
||||||
|
|
||||||
There are certain fields in the skb tc_verd that need to be reset so we
|
There are certain fields in the skb tc_verd that need to be reset so we
|
||||||
avoid loops etc. A few are generic enough so much so that skb_act_clone()
|
avoid loops, etc. A few are generic enough that skb_act_clone()
|
||||||
resets them for you. So invoke skb_act_clone() rather than skb_clone()
|
resets them for you, so invoke skb_act_clone() rather than skb_clone().
|
||||||
|
|
||||||
2) If you munge any packet thou shalt call pskb_expand_head in the case
|
2) If you munge any packet thou shalt call pskb_expand_head in the case
|
||||||
someone else is referencing the skb. After that you "own" the skb.
|
someone else is referencing the skb. After that you "own" the skb.
|
||||||
You must also tell us if it is ok to munge the packet (TC_OK2MUNGE),
|
You must also tell us if it is ok to munge the packet (TC_OK2MUNGE),
|
||||||
this way any action downstream can stomp on the packet.
|
this way any action downstream can stomp on the packet.
|
||||||
|
|
||||||
3) dropping packets you dont own is a nono. You simply return
|
3) Dropping packets you don't own is a no-no. You simply return
|
||||||
TC_ACT_SHOT to the caller and they will drop it.
|
TC_ACT_SHOT to the caller and they will drop it.
|
||||||
|
|
||||||
The "enviromental" rules for callers of actions (qdiscs etc) are:
|
The "enviromental" rules for callers of actions (qdiscs etc) are:
|
||||||
|
|
||||||
*) thou art responsible for freeing anything returned as being
|
*) Thou art responsible for freeing anything returned as being
|
||||||
TC_ACT_SHOT/STOLEN/QUEUED. If none of TC_ACT_SHOT/STOLEN/QUEUED is
|
TC_ACT_SHOT/STOLEN/QUEUED. If none of TC_ACT_SHOT/STOLEN/QUEUED is
|
||||||
returned then all is great and you dont need to do anything.
|
returned, then all is great and you don't need to do anything.
|
||||||
|
|
||||||
Post on netdev if something is unclear.
|
Post on netdev if something is unclear.
|
||||||
|
|
||||||
|
|
|
@ -148,7 +148,7 @@
|
||||||
getsockopt(sockfd, SOL_SOCKET, SO_NO_CHECK, &value, ...);
|
getsockopt(sockfd, SOL_SOCKET, SO_NO_CHECK, &value, ...);
|
||||||
|
|
||||||
is meaningless (as in TCP). Packets with a zero checksum field are
|
is meaningless (as in TCP). Packets with a zero checksum field are
|
||||||
illegal (cf. RFC 3828, sec. 3.1) will be silently discarded.
|
illegal (cf. RFC 3828, sec. 3.1) and will be silently discarded.
|
||||||
|
|
||||||
4) Fragmentation
|
4) Fragmentation
|
||||||
|
|
||||||
|
|
|
@ -1,5 +1,7 @@
|
||||||
00-INDEX
|
00-INDEX
|
||||||
- This file
|
- This file
|
||||||
|
apm-acpi.txt
|
||||||
|
- basic info about the APM and ACPI support.
|
||||||
basic-pm-debugging.txt
|
basic-pm-debugging.txt
|
||||||
- Debugging suspend and resume
|
- Debugging suspend and resume
|
||||||
devices.txt
|
devices.txt
|
||||||
|
@ -14,8 +16,6 @@ notifiers.txt
|
||||||
- Registering suspend notifiers in device drivers
|
- Registering suspend notifiers in device drivers
|
||||||
pci.txt
|
pci.txt
|
||||||
- How the PCI Subsystem Does Power Management
|
- How the PCI Subsystem Does Power Management
|
||||||
pm.txt
|
|
||||||
- info on Linux power management support.
|
|
||||||
pm_qos_interface.txt
|
pm_qos_interface.txt
|
||||||
- info on Linux PM Quality of Service interface
|
- info on Linux PM Quality of Service interface
|
||||||
power_supply_class.txt
|
power_supply_class.txt
|
||||||
|
|
32
Documentation/power/apm-acpi.txt
Normal file
32
Documentation/power/apm-acpi.txt
Normal file
|
@ -0,0 +1,32 @@
|
||||||
|
APM or ACPI?
|
||||||
|
------------
|
||||||
|
If you have a relatively recent x86 mobile, desktop, or server system,
|
||||||
|
odds are it supports either Advanced Power Management (APM) or
|
||||||
|
Advanced Configuration and Power Interface (ACPI). ACPI is the newer
|
||||||
|
of the two technologies and puts power management in the hands of the
|
||||||
|
operating system, allowing for more intelligent power management than
|
||||||
|
is possible with BIOS controlled APM.
|
||||||
|
|
||||||
|
The best way to determine which, if either, your system supports is to
|
||||||
|
build a kernel with both ACPI and APM enabled (as of 2.3.x ACPI is
|
||||||
|
enabled by default). If a working ACPI implementation is found, the
|
||||||
|
ACPI driver will override and disable APM, otherwise the APM driver
|
||||||
|
will be used.
|
||||||
|
|
||||||
|
No, sorry, you cannot have both ACPI and APM enabled and running at
|
||||||
|
once. Some people with broken ACPI or broken APM implementations
|
||||||
|
would like to use both to get a full set of working features, but you
|
||||||
|
simply cannot mix and match the two. Only one power management
|
||||||
|
interface can be in control of the machine at once. Think about it..
|
||||||
|
|
||||||
|
User-space Daemons
|
||||||
|
------------------
|
||||||
|
Both APM and ACPI rely on user-space daemons, apmd and acpid
|
||||||
|
respectively, to be completely functional. Obtain both of these
|
||||||
|
daemons from your Linux distribution or from the Internet (see below)
|
||||||
|
and be sure that they are started sometime in the system boot process.
|
||||||
|
Go ahead and start both. If ACPI or APM is not available on your
|
||||||
|
system the associated daemon will exit gracefully.
|
||||||
|
|
||||||
|
apmd: http://worldvisions.ca/~apenwarr/apmd/
|
||||||
|
acpid: http://acpid.sf.net/
|
|
@ -1,257 +0,0 @@
|
||||||
Linux Power Management Support
|
|
||||||
|
|
||||||
This document briefly describes how to use power management with your
|
|
||||||
Linux system and how to add power management support to Linux drivers.
|
|
||||||
|
|
||||||
APM or ACPI?
|
|
||||||
------------
|
|
||||||
If you have a relatively recent x86 mobile, desktop, or server system,
|
|
||||||
odds are it supports either Advanced Power Management (APM) or
|
|
||||||
Advanced Configuration and Power Interface (ACPI). ACPI is the newer
|
|
||||||
of the two technologies and puts power management in the hands of the
|
|
||||||
operating system, allowing for more intelligent power management than
|
|
||||||
is possible with BIOS controlled APM.
|
|
||||||
|
|
||||||
The best way to determine which, if either, your system supports is to
|
|
||||||
build a kernel with both ACPI and APM enabled (as of 2.3.x ACPI is
|
|
||||||
enabled by default). If a working ACPI implementation is found, the
|
|
||||||
ACPI driver will override and disable APM, otherwise the APM driver
|
|
||||||
will be used.
|
|
||||||
|
|
||||||
No, sorry, you cannot have both ACPI and APM enabled and running at
|
|
||||||
once. Some people with broken ACPI or broken APM implementations
|
|
||||||
would like to use both to get a full set of working features, but you
|
|
||||||
simply cannot mix and match the two. Only one power management
|
|
||||||
interface can be in control of the machine at once. Think about it..
|
|
||||||
|
|
||||||
User-space Daemons
|
|
||||||
------------------
|
|
||||||
Both APM and ACPI rely on user-space daemons, apmd and acpid
|
|
||||||
respectively, to be completely functional. Obtain both of these
|
|
||||||
daemons from your Linux distribution or from the Internet (see below)
|
|
||||||
and be sure that they are started sometime in the system boot process.
|
|
||||||
Go ahead and start both. If ACPI or APM is not available on your
|
|
||||||
system the associated daemon will exit gracefully.
|
|
||||||
|
|
||||||
apmd: http://worldvisions.ca/~apenwarr/apmd/
|
|
||||||
acpid: http://acpid.sf.net/
|
|
||||||
|
|
||||||
Driver Interface -- OBSOLETE, DO NOT USE!
|
|
||||||
----------------*************************
|
|
||||||
|
|
||||||
Note: pm_register(), pm_access(), pm_dev_idle() and friends are
|
|
||||||
obsolete. Please do not use them. Instead you should properly hook
|
|
||||||
your driver into the driver model, and use its suspend()/resume()
|
|
||||||
callbacks to do this kind of stuff.
|
|
||||||
|
|
||||||
If you are writing a new driver or maintaining an old driver, it
|
|
||||||
should include power management support. Without power management
|
|
||||||
support, a single driver may prevent a system with power management
|
|
||||||
capabilities from ever being able to suspend (safely).
|
|
||||||
|
|
||||||
Overview:
|
|
||||||
1) Register each instance of a device with "pm_register"
|
|
||||||
2) Call "pm_access" before accessing the hardware.
|
|
||||||
(this will ensure that the hardware is awake and ready)
|
|
||||||
3) Your "pm_callback" is called before going into a
|
|
||||||
suspend state (ACPI D1-D3) or after resuming (ACPI D0)
|
|
||||||
from a suspend.
|
|
||||||
4) Call "pm_dev_idle" when the device is not being used
|
|
||||||
(optional but will improve device idle detection)
|
|
||||||
5) When unloaded, unregister the device with "pm_unregister"
|
|
||||||
|
|
||||||
/*
|
|
||||||
* Description: Register a device with the power-management subsystem
|
|
||||||
*
|
|
||||||
* Parameters:
|
|
||||||
* type - device type (PCI device, system device, ...)
|
|
||||||
* id - instance number or unique identifier
|
|
||||||
* cback - request handler callback (suspend, resume, ...)
|
|
||||||
*
|
|
||||||
* Returns: Registered PM device or NULL on error
|
|
||||||
*
|
|
||||||
* Examples:
|
|
||||||
* dev = pm_register(PM_SYS_DEV, PM_SYS_VGA, vga_callback);
|
|
||||||
*
|
|
||||||
* struct pci_dev *pci_dev = pci_find_dev(...);
|
|
||||||
* dev = pm_register(PM_PCI_DEV, PM_PCI_ID(pci_dev), callback);
|
|
||||||
*/
|
|
||||||
struct pm_dev *pm_register(pm_dev_t type, unsigned long id, pm_callback cback);
|
|
||||||
|
|
||||||
/*
|
|
||||||
* Description: Unregister a device with the power management subsystem
|
|
||||||
*
|
|
||||||
* Parameters:
|
|
||||||
* dev - PM device previously returned from pm_register
|
|
||||||
*/
|
|
||||||
void pm_unregister(struct pm_dev *dev);
|
|
||||||
|
|
||||||
/*
|
|
||||||
* Description: Unregister all devices with a matching callback function
|
|
||||||
*
|
|
||||||
* Parameters:
|
|
||||||
* cback - previously registered request callback
|
|
||||||
*
|
|
||||||
* Notes: Provided for easier porting from old APM interface
|
|
||||||
*/
|
|
||||||
void pm_unregister_all(pm_callback cback);
|
|
||||||
|
|
||||||
/*
|
|
||||||
* Power management request callback
|
|
||||||
*
|
|
||||||
* Parameters:
|
|
||||||
* dev - PM device previously returned from pm_register
|
|
||||||
* rqst - request type
|
|
||||||
* data - data, if any, associated with the request
|
|
||||||
*
|
|
||||||
* Returns: 0 if the request is successful
|
|
||||||
* EINVAL if the request is not supported
|
|
||||||
* EBUSY if the device is now busy and cannot handle the request
|
|
||||||
* ENOMEM if the device was unable to handle the request due to memory
|
|
||||||
*
|
|
||||||
* Details: The device request callback will be called before the
|
|
||||||
* device/system enters a suspend state (ACPI D1-D3) or
|
|
||||||
* or after the device/system resumes from suspend (ACPI D0).
|
|
||||||
* For PM_SUSPEND, the ACPI D-state being entered is passed
|
|
||||||
* as the "data" argument to the callback. The device
|
|
||||||
* driver should save (PM_SUSPEND) or restore (PM_RESUME)
|
|
||||||
* device context when the request callback is called.
|
|
||||||
*
|
|
||||||
* Once a driver returns 0 (success) from a suspend
|
|
||||||
* request, it should not process any further requests or
|
|
||||||
* access the device hardware until a call to "pm_access" is made.
|
|
||||||
*/
|
|
||||||
typedef int (*pm_callback)(struct pm_dev *dev, pm_request_t rqst, void *data);
|
|
||||||
|
|
||||||
Driver Details
|
|
||||||
--------------
|
|
||||||
This is just a quick Q&A as a stopgap until a real driver writers'
|
|
||||||
power management guide is available.
|
|
||||||
|
|
||||||
Q: When is a device suspended?
|
|
||||||
|
|
||||||
Devices can be suspended based on direct user request (eg. laptop lid
|
|
||||||
closes), system power policy (eg. sleep after 30 minutes of console
|
|
||||||
inactivity), or device power policy (eg. power down device after 5
|
|
||||||
minutes of inactivity)
|
|
||||||
|
|
||||||
Q: Must a driver honor a suspend request?
|
|
||||||
|
|
||||||
No, a driver can return -EBUSY from a suspend request and this
|
|
||||||
will stop the system from suspending. When a suspend request
|
|
||||||
fails, all suspended devices are resumed and the system continues
|
|
||||||
to run. Suspend can be retried at a later time.
|
|
||||||
|
|
||||||
Q: Can the driver block suspend/resume requests?
|
|
||||||
|
|
||||||
Yes, a driver can delay its return from a suspend or resume
|
|
||||||
request until the device is ready to handle requests. It
|
|
||||||
is advantageous to return as quickly as possible from a
|
|
||||||
request as suspend/resume are done serially.
|
|
||||||
|
|
||||||
Q: What context is a suspend/resume initiated from?
|
|
||||||
|
|
||||||
A suspend or resume is initiated from a kernel thread context.
|
|
||||||
It is safe to block, allocate memory, initiate requests
|
|
||||||
or anything else you can do within the kernel.
|
|
||||||
|
|
||||||
Q: Will requests continue to arrive after a suspend?
|
|
||||||
|
|
||||||
Possibly. It is the driver's responsibility to queue(*),
|
|
||||||
fail, or drop any requests that arrive after returning
|
|
||||||
success to a suspend request. It is important that the
|
|
||||||
driver not access its device until after it receives
|
|
||||||
a resume request as the device's bus may no longer
|
|
||||||
be active.
|
|
||||||
|
|
||||||
(*) If a driver queues requests for processing after
|
|
||||||
resume be aware that the device, network, etc.
|
|
||||||
might be in a different state than at suspend time.
|
|
||||||
It's probably better to drop requests unless
|
|
||||||
the driver is a storage device.
|
|
||||||
|
|
||||||
Q: Do I have to manage bus-specific power management registers
|
|
||||||
|
|
||||||
No. It is the responsibility of the bus driver to manage
|
|
||||||
PCI, USB, etc. power management registers. The bus driver
|
|
||||||
or the power management subsystem will also enable any
|
|
||||||
wake-on functionality that the device has.
|
|
||||||
|
|
||||||
Q: So, really, what do I need to do to support suspend/resume?
|
|
||||||
|
|
||||||
You need to save any device context that would
|
|
||||||
be lost if the device was powered off and then restore
|
|
||||||
it at resume time. When ACPI is active, there are
|
|
||||||
three levels of device suspend states; D1, D2, and D3.
|
|
||||||
(The suspend state is passed as the "data" argument
|
|
||||||
to the device callback.) With D3, the device is powered
|
|
||||||
off and loses all context, D1 and D2 are shallower power
|
|
||||||
states and require less device context to be saved. To
|
|
||||||
play it safe, just save everything at suspend and restore
|
|
||||||
everything at resume.
|
|
||||||
|
|
||||||
Q: Where do I store device context for suspend?
|
|
||||||
|
|
||||||
Anywhere in memory, kmalloc a buffer or store it
|
|
||||||
in the device descriptor. You are guaranteed that the
|
|
||||||
contents of memory will be restored and accessible
|
|
||||||
before resume, even when the system suspends to disk.
|
|
||||||
|
|
||||||
Q: What do I need to do for ACPI vs. APM vs. etc?
|
|
||||||
|
|
||||||
Drivers need not be aware of the specific power management
|
|
||||||
technology that is active. They just need to be aware
|
|
||||||
of when the overlying power management system requests
|
|
||||||
that they suspend or resume.
|
|
||||||
|
|
||||||
Q: What about device dependencies?
|
|
||||||
|
|
||||||
When a driver registers a device, the power management
|
|
||||||
subsystem uses the information provided to build a
|
|
||||||
tree of device dependencies (eg. USB device X is on
|
|
||||||
USB controller Y which is on PCI bus Z) When power
|
|
||||||
management wants to suspend a device, it first sends
|
|
||||||
a suspend request to its driver, then the bus driver,
|
|
||||||
and so on up to the system bus. Device resumes
|
|
||||||
proceed in the opposite direction.
|
|
||||||
|
|
||||||
Q: Who do I contact for additional information about
|
|
||||||
enabling power management for my specific driver/device?
|
|
||||||
|
|
||||||
ACPI Development mailing list: linux-acpi@vger.kernel.org
|
|
||||||
|
|
||||||
System Interface -- OBSOLETE, DO NOT USE!
|
|
||||||
----------------*************************
|
|
||||||
If you are providing new power management support to Linux (ie.
|
|
||||||
adding support for something like APM or ACPI), you should
|
|
||||||
communicate with drivers through the existing generic power
|
|
||||||
management interface.
|
|
||||||
|
|
||||||
/*
|
|
||||||
* Send a request to all devices
|
|
||||||
*
|
|
||||||
* Parameters:
|
|
||||||
* rqst - request type
|
|
||||||
* data - data, if any, associated with the request
|
|
||||||
*
|
|
||||||
* Returns: 0 if the request is successful
|
|
||||||
* See "pm_callback" return for errors
|
|
||||||
*
|
|
||||||
* Details: Walk list of registered devices and call pm_send
|
|
||||||
* for each until complete or an error is encountered.
|
|
||||||
* If an error is encountered for a suspend request,
|
|
||||||
* return all devices to the state they were in before
|
|
||||||
* the suspend request.
|
|
||||||
*/
|
|
||||||
int pm_send_all(pm_request_t rqst, void *data);
|
|
||||||
|
|
||||||
/*
|
|
||||||
* Find a matching device
|
|
||||||
*
|
|
||||||
* Parameters:
|
|
||||||
* type - device type (PCI device, system device, or 0 to match all devices)
|
|
||||||
* from - previous match or NULL to start from the beginning
|
|
||||||
*
|
|
||||||
* Returns: Matching device or NULL if none found
|
|
||||||
*/
|
|
||||||
struct pm_dev *pm_find(pm_dev_t type, struct pm_dev *from);
|
|
|
@ -59,6 +59,7 @@ Table of Contents
|
||||||
p) Freescale Synchronous Serial Interface
|
p) Freescale Synchronous Serial Interface
|
||||||
q) USB EHCI controllers
|
q) USB EHCI controllers
|
||||||
r) MDIO on GPIOs
|
r) MDIO on GPIOs
|
||||||
|
s) SPI busses
|
||||||
|
|
||||||
VII - Marvell Discovery mv64[345]6x System Controller chips
|
VII - Marvell Discovery mv64[345]6x System Controller chips
|
||||||
1) The /system-controller node
|
1) The /system-controller node
|
||||||
|
@ -89,10 +90,12 @@ Table of Contents
|
||||||
3) OpenPIC Interrupt Controllers
|
3) OpenPIC Interrupt Controllers
|
||||||
4) ISA Interrupt Controllers
|
4) ISA Interrupt Controllers
|
||||||
|
|
||||||
VIII - Specifying GPIO information for devices
|
IX - Specifying GPIO information for devices
|
||||||
1) gpios property
|
1) gpios property
|
||||||
2) gpio-controller nodes
|
2) gpio-controller nodes
|
||||||
|
|
||||||
|
X - Specifying device power management information (sleep property)
|
||||||
|
|
||||||
Appendix A - Sample SOC node for MPC8540
|
Appendix A - Sample SOC node for MPC8540
|
||||||
|
|
||||||
|
|
||||||
|
@ -705,7 +708,7 @@ device or bus to be described by the device tree.
|
||||||
In general, the format of an address for a device is defined by the
|
In general, the format of an address for a device is defined by the
|
||||||
parent bus type, based on the #address-cells and #size-cells
|
parent bus type, based on the #address-cells and #size-cells
|
||||||
properties. Note that the parent's parent definitions of #address-cells
|
properties. Note that the parent's parent definitions of #address-cells
|
||||||
and #size-cells are not inhereted so every node with children must specify
|
and #size-cells are not inherited so every node with children must specify
|
||||||
them. The kernel requires the root node to have those properties defining
|
them. The kernel requires the root node to have those properties defining
|
||||||
addresses format for devices directly mapped on the processor bus.
|
addresses format for devices directly mapped on the processor bus.
|
||||||
|
|
||||||
|
@ -1774,7 +1777,7 @@ platforms are moved over to use the flattened-device-tree model.
|
||||||
|
|
||||||
Xilinx uartlite devices are simple fixed speed serial ports.
|
Xilinx uartlite devices are simple fixed speed serial ports.
|
||||||
|
|
||||||
Requred properties:
|
Required properties:
|
||||||
- current-speed : Baud rate of uartlite
|
- current-speed : Baud rate of uartlite
|
||||||
|
|
||||||
v) Xilinx hwicap
|
v) Xilinx hwicap
|
||||||
|
@ -1796,7 +1799,7 @@ platforms are moved over to use the flattened-device-tree model.
|
||||||
Xilinx UART 16550 devices are very similar to the NS16550 but with
|
Xilinx UART 16550 devices are very similar to the NS16550 but with
|
||||||
different register spacing and an offset from the base address.
|
different register spacing and an offset from the base address.
|
||||||
|
|
||||||
Requred properties:
|
Required properties:
|
||||||
- clock-frequency : Frequency of the clock input
|
- clock-frequency : Frequency of the clock input
|
||||||
- reg-offset : A value of 3 is required
|
- reg-offset : A value of 3 is required
|
||||||
- reg-shift : A value of 2 is required
|
- reg-shift : A value of 2 is required
|
||||||
|
@ -1881,6 +1884,62 @@ platforms are moved over to use the flattened-device-tree model.
|
||||||
&qe_pio_c 6>;
|
&qe_pio_c 6>;
|
||||||
};
|
};
|
||||||
|
|
||||||
|
s) SPI (Serial Peripheral Interface) busses
|
||||||
|
|
||||||
|
SPI busses can be described with a node for the SPI master device
|
||||||
|
and a set of child nodes for each SPI slave on the bus. For this
|
||||||
|
discussion, it is assumed that the system's SPI controller is in
|
||||||
|
SPI master mode. This binding does not describe SPI controllers
|
||||||
|
in slave mode.
|
||||||
|
|
||||||
|
The SPI master node requires the following properties:
|
||||||
|
- #address-cells - number of cells required to define a chip select
|
||||||
|
address on the SPI bus.
|
||||||
|
- #size-cells - should be zero.
|
||||||
|
- compatible - name of SPI bus controller following generic names
|
||||||
|
recommended practice.
|
||||||
|
No other properties are required in the SPI bus node. It is assumed
|
||||||
|
that a driver for an SPI bus device will understand that it is an SPI bus.
|
||||||
|
However, the binding does not attempt to define the specific method for
|
||||||
|
assigning chip select numbers. Since SPI chip select configuration is
|
||||||
|
flexible and non-standardized, it is left out of this binding with the
|
||||||
|
assumption that board specific platform code will be used to manage
|
||||||
|
chip selects. Individual drivers can define additional properties to
|
||||||
|
support describing the chip select layout.
|
||||||
|
|
||||||
|
SPI slave nodes must be children of the SPI master node and can
|
||||||
|
contain the following properties.
|
||||||
|
- reg - (required) chip select address of device.
|
||||||
|
- compatible - (required) name of SPI device following generic names
|
||||||
|
recommended practice
|
||||||
|
- spi-max-frequency - (required) Maximum SPI clocking speed of device in Hz
|
||||||
|
- spi-cpol - (optional) Empty property indicating device requires
|
||||||
|
inverse clock polarity (CPOL) mode
|
||||||
|
- spi-cpha - (optional) Empty property indicating device requires
|
||||||
|
shifted clock phase (CPHA) mode
|
||||||
|
|
||||||
|
SPI example for an MPC5200 SPI bus:
|
||||||
|
spi@f00 {
|
||||||
|
#address-cells = <1>;
|
||||||
|
#size-cells = <0>;
|
||||||
|
compatible = "fsl,mpc5200b-spi","fsl,mpc5200-spi";
|
||||||
|
reg = <0xf00 0x20>;
|
||||||
|
interrupts = <2 13 0 2 14 0>;
|
||||||
|
interrupt-parent = <&mpc5200_pic>;
|
||||||
|
|
||||||
|
ethernet-switch@0 {
|
||||||
|
compatible = "micrel,ks8995m";
|
||||||
|
spi-max-frequency = <1000000>;
|
||||||
|
reg = <0>;
|
||||||
|
};
|
||||||
|
|
||||||
|
codec@1 {
|
||||||
|
compatible = "ti,tlv320aic26";
|
||||||
|
spi-max-frequency = <100000>;
|
||||||
|
reg = <1>;
|
||||||
|
};
|
||||||
|
};
|
||||||
|
|
||||||
VII - Marvell Discovery mv64[345]6x System Controller chips
|
VII - Marvell Discovery mv64[345]6x System Controller chips
|
||||||
===========================================================
|
===========================================================
|
||||||
|
|
||||||
|
@ -1894,7 +1953,7 @@ prefixed with the string "marvell,", for Marvell Technology Group Ltd.
|
||||||
1) The /system-controller node
|
1) The /system-controller node
|
||||||
|
|
||||||
This node is used to represent the system-controller and must be
|
This node is used to represent the system-controller and must be
|
||||||
present when the system uses a system contller chip. The top-level
|
present when the system uses a system controller chip. The top-level
|
||||||
system-controller node contains information that is global to all
|
system-controller node contains information that is global to all
|
||||||
devices within the system controller chip. The node name begins
|
devices within the system controller chip. The node name begins
|
||||||
with "system-controller" followed by the unit address, which is
|
with "system-controller" followed by the unit address, which is
|
||||||
|
@ -2488,8 +2547,8 @@ encodings listed below:
|
||||||
2 = high to low edge sensitive type enabled
|
2 = high to low edge sensitive type enabled
|
||||||
3 = low to high edge sensitive type enabled
|
3 = low to high edge sensitive type enabled
|
||||||
|
|
||||||
VIII - Specifying GPIO information for devices
|
IX - Specifying GPIO information for devices
|
||||||
==============================================
|
============================================
|
||||||
|
|
||||||
1) gpios property
|
1) gpios property
|
||||||
-----------------
|
-----------------
|
||||||
|
@ -2537,116 +2596,151 @@ Example of two SOC GPIO banks defined as gpio-controller nodes:
|
||||||
gpio-controller;
|
gpio-controller;
|
||||||
};
|
};
|
||||||
|
|
||||||
|
X - Specifying Device Power Management Information (sleep property)
|
||||||
|
===================================================================
|
||||||
|
|
||||||
|
Devices on SOCs often have mechanisms for placing devices into low-power
|
||||||
|
states that are decoupled from the devices' own register blocks. Sometimes,
|
||||||
|
this information is more complicated than a cell-index property can
|
||||||
|
reasonably describe. Thus, each device controlled in such a manner
|
||||||
|
may contain a "sleep" property which describes these connections.
|
||||||
|
|
||||||
|
The sleep property consists of one or more sleep resources, each of
|
||||||
|
which consists of a phandle to a sleep controller, followed by a
|
||||||
|
controller-specific sleep specifier of zero or more cells.
|
||||||
|
|
||||||
|
The semantics of what type of low power modes are possible are defined
|
||||||
|
by the sleep controller. Some examples of the types of low power modes
|
||||||
|
that may be supported are:
|
||||||
|
|
||||||
|
- Dynamic: The device may be disabled or enabled at any time.
|
||||||
|
- System Suspend: The device may request to be disabled or remain
|
||||||
|
awake during system suspend, but will not be disabled until then.
|
||||||
|
- Permanent: The device is disabled permanently (until the next hard
|
||||||
|
reset).
|
||||||
|
|
||||||
|
Some devices may share a clock domain with each other, such that they should
|
||||||
|
only be suspended when none of the devices are in use. Where reasonable,
|
||||||
|
such nodes should be placed on a virtual bus, where the bus has the sleep
|
||||||
|
property. If the clock domain is shared among devices that cannot be
|
||||||
|
reasonably grouped in this manner, then create a virtual sleep controller
|
||||||
|
(similar to an interrupt nexus, except that defining a standardized
|
||||||
|
sleep-map should wait until its necessity is demonstrated).
|
||||||
|
|
||||||
Appendix A - Sample SOC node for MPC8540
|
Appendix A - Sample SOC node for MPC8540
|
||||||
========================================
|
========================================
|
||||||
|
|
||||||
Note that the #address-cells and #size-cells for the SoC node
|
soc@e0000000 {
|
||||||
in this example have been explicitly listed; these are likely
|
|
||||||
not necessary as they are usually the same as the root node.
|
|
||||||
|
|
||||||
soc8540@e0000000 {
|
|
||||||
#address-cells = <1>;
|
#address-cells = <1>;
|
||||||
#size-cells = <1>;
|
#size-cells = <1>;
|
||||||
#interrupt-cells = <2>;
|
compatible = "fsl,mpc8540-ccsr", "simple-bus";
|
||||||
device_type = "soc";
|
device_type = "soc";
|
||||||
ranges = <00000000 e0000000 00100000>
|
ranges = <0x00000000 0xe0000000 0x00100000>
|
||||||
reg = <e0000000 00003000>;
|
|
||||||
bus-frequency = <0>;
|
bus-frequency = <0>;
|
||||||
|
interrupt-parent = <&pic>;
|
||||||
mdio@24520 {
|
|
||||||
reg = <24520 20>;
|
|
||||||
device_type = "mdio";
|
|
||||||
compatible = "gianfar";
|
|
||||||
|
|
||||||
ethernet-phy@0 {
|
|
||||||
linux,phandle = <2452000>
|
|
||||||
interrupt-parent = <40000>;
|
|
||||||
interrupts = <35 1>;
|
|
||||||
reg = <0>;
|
|
||||||
device_type = "ethernet-phy";
|
|
||||||
};
|
|
||||||
|
|
||||||
ethernet-phy@1 {
|
|
||||||
linux,phandle = <2452001>
|
|
||||||
interrupt-parent = <40000>;
|
|
||||||
interrupts = <35 1>;
|
|
||||||
reg = <1>;
|
|
||||||
device_type = "ethernet-phy";
|
|
||||||
};
|
|
||||||
|
|
||||||
ethernet-phy@3 {
|
|
||||||
linux,phandle = <2452002>
|
|
||||||
interrupt-parent = <40000>;
|
|
||||||
interrupts = <35 1>;
|
|
||||||
reg = <3>;
|
|
||||||
device_type = "ethernet-phy";
|
|
||||||
};
|
|
||||||
|
|
||||||
};
|
|
||||||
|
|
||||||
ethernet@24000 {
|
ethernet@24000 {
|
||||||
#size-cells = <0>;
|
#address-cells = <1>;
|
||||||
|
#size-cells = <1>;
|
||||||
device_type = "network";
|
device_type = "network";
|
||||||
model = "TSEC";
|
model = "TSEC";
|
||||||
compatible = "gianfar";
|
compatible = "gianfar", "simple-bus";
|
||||||
reg = <24000 1000>;
|
reg = <0x24000 0x1000>;
|
||||||
mac-address = [ 00 E0 0C 00 73 00 ];
|
local-mac-address = [ 00 E0 0C 00 73 00 ];
|
||||||
interrupts = <d 3 e 3 12 3>;
|
interrupts = <29 2 30 2 34 2>;
|
||||||
interrupt-parent = <40000>;
|
phy-handle = <&phy0>;
|
||||||
phy-handle = <2452000>;
|
sleep = <&pmc 00000080>;
|
||||||
|
ranges;
|
||||||
|
|
||||||
|
mdio@24520 {
|
||||||
|
reg = <0x24520 0x20>;
|
||||||
|
compatible = "fsl,gianfar-mdio";
|
||||||
|
|
||||||
|
phy0: ethernet-phy@0 {
|
||||||
|
interrupts = <5 1>;
|
||||||
|
reg = <0>;
|
||||||
|
device_type = "ethernet-phy";
|
||||||
|
};
|
||||||
|
|
||||||
|
phy1: ethernet-phy@1 {
|
||||||
|
interrupts = <5 1>;
|
||||||
|
reg = <1>;
|
||||||
|
device_type = "ethernet-phy";
|
||||||
|
};
|
||||||
|
|
||||||
|
phy3: ethernet-phy@3 {
|
||||||
|
interrupts = <7 1>;
|
||||||
|
reg = <3>;
|
||||||
|
device_type = "ethernet-phy";
|
||||||
|
};
|
||||||
|
};
|
||||||
};
|
};
|
||||||
|
|
||||||
ethernet@25000 {
|
ethernet@25000 {
|
||||||
#address-cells = <1>;
|
|
||||||
#size-cells = <0>;
|
|
||||||
device_type = "network";
|
device_type = "network";
|
||||||
model = "TSEC";
|
model = "TSEC";
|
||||||
compatible = "gianfar";
|
compatible = "gianfar";
|
||||||
reg = <25000 1000>;
|
reg = <0x25000 0x1000>;
|
||||||
mac-address = [ 00 E0 0C 00 73 01 ];
|
local-mac-address = [ 00 E0 0C 00 73 01 ];
|
||||||
interrupts = <13 3 14 3 18 3>;
|
interrupts = <13 2 14 2 18 2>;
|
||||||
interrupt-parent = <40000>;
|
phy-handle = <&phy1>;
|
||||||
phy-handle = <2452001>;
|
sleep = <&pmc 00000040>;
|
||||||
};
|
};
|
||||||
|
|
||||||
ethernet@26000 {
|
ethernet@26000 {
|
||||||
#address-cells = <1>;
|
|
||||||
#size-cells = <0>;
|
|
||||||
device_type = "network";
|
device_type = "network";
|
||||||
model = "FEC";
|
model = "FEC";
|
||||||
compatible = "gianfar";
|
compatible = "gianfar";
|
||||||
reg = <26000 1000>;
|
reg = <0x26000 0x1000>;
|
||||||
mac-address = [ 00 E0 0C 00 73 02 ];
|
local-mac-address = [ 00 E0 0C 00 73 02 ];
|
||||||
interrupts = <19 3>;
|
interrupts = <41 2>;
|
||||||
interrupt-parent = <40000>;
|
phy-handle = <&phy3>;
|
||||||
phy-handle = <2452002>;
|
sleep = <&pmc 00000020>;
|
||||||
};
|
};
|
||||||
|
|
||||||
serial@4500 {
|
serial@4500 {
|
||||||
device_type = "serial";
|
#address-cells = <1>;
|
||||||
compatible = "ns16550";
|
#size-cells = <1>;
|
||||||
reg = <4500 100>;
|
compatible = "fsl,mpc8540-duart", "simple-bus";
|
||||||
clock-frequency = <0>;
|
sleep = <&pmc 00000002>;
|
||||||
interrupts = <1a 3>;
|
ranges;
|
||||||
interrupt-parent = <40000>;
|
|
||||||
|
serial@4500 {
|
||||||
|
device_type = "serial";
|
||||||
|
compatible = "ns16550";
|
||||||
|
reg = <0x4500 0x100>;
|
||||||
|
clock-frequency = <0>;
|
||||||
|
interrupts = <42 2>;
|
||||||
|
};
|
||||||
|
|
||||||
|
serial@4600 {
|
||||||
|
device_type = "serial";
|
||||||
|
compatible = "ns16550";
|
||||||
|
reg = <0x4600 0x100>;
|
||||||
|
clock-frequency = <0>;
|
||||||
|
interrupts = <42 2>;
|
||||||
|
};
|
||||||
};
|
};
|
||||||
|
|
||||||
pic@40000 {
|
pic: pic@40000 {
|
||||||
linux,phandle = <40000>;
|
|
||||||
interrupt-controller;
|
interrupt-controller;
|
||||||
#address-cells = <0>;
|
#address-cells = <0>;
|
||||||
reg = <40000 40000>;
|
#interrupt-cells = <2>;
|
||||||
|
reg = <0x40000 0x40000>;
|
||||||
compatible = "chrp,open-pic";
|
compatible = "chrp,open-pic";
|
||||||
device_type = "open-pic";
|
device_type = "open-pic";
|
||||||
};
|
};
|
||||||
|
|
||||||
i2c@3000 {
|
i2c@3000 {
|
||||||
interrupt-parent = <40000>;
|
interrupts = <43 2>;
|
||||||
interrupts = <1b 3>;
|
reg = <0x3000 0x100>;
|
||||||
reg = <3000 18>;
|
|
||||||
device_type = "i2c";
|
|
||||||
compatible = "fsl-i2c";
|
compatible = "fsl-i2c";
|
||||||
dfsrr;
|
dfsrr;
|
||||||
|
sleep = <&pmc 00000004>;
|
||||||
};
|
};
|
||||||
|
|
||||||
|
pmc: power@e0070 {
|
||||||
|
compatible = "fsl,mpc8540-pmc", "fsl,mpc8548-pmc";
|
||||||
|
reg = <0xe0070 0x20>;
|
||||||
|
};
|
||||||
};
|
};
|
||||||
|
|
38
Documentation/powerpc/dts-bindings/fsl/cpm_qe/gpio.txt
Normal file
38
Documentation/powerpc/dts-bindings/fsl/cpm_qe/gpio.txt
Normal file
|
@ -0,0 +1,38 @@
|
||||||
|
Every GPIO controller node must have #gpio-cells property defined,
|
||||||
|
this information will be used to translate gpio-specifiers.
|
||||||
|
|
||||||
|
On CPM1 devices, all ports are using slightly different register layouts.
|
||||||
|
Ports A, C and D are 16bit ports and Ports B and E are 32bit ports.
|
||||||
|
|
||||||
|
On CPM2 devices, all ports are 32bit ports and use a common register layout.
|
||||||
|
|
||||||
|
Required properties:
|
||||||
|
- compatible : "fsl,cpm1-pario-bank-a", "fsl,cpm1-pario-bank-b",
|
||||||
|
"fsl,cpm1-pario-bank-c", "fsl,cpm1-pario-bank-d",
|
||||||
|
"fsl,cpm1-pario-bank-e", "fsl,cpm2-pario-bank"
|
||||||
|
- #gpio-cells : Should be two. The first cell is the pin number and the
|
||||||
|
second cell is used to specify optional paramters (currently unused).
|
||||||
|
- gpio-controller : Marks the port as GPIO controller.
|
||||||
|
|
||||||
|
Example of three SOC GPIO banks defined as gpio-controller nodes:
|
||||||
|
|
||||||
|
CPM1_PIO_A: gpio-controller@950 {
|
||||||
|
#gpio-cells = <2>;
|
||||||
|
compatible = "fsl,cpm1-pario-bank-a";
|
||||||
|
reg = <0x950 0x10>;
|
||||||
|
gpio-controller;
|
||||||
|
};
|
||||||
|
|
||||||
|
CPM1_PIO_B: gpio-controller@ab8 {
|
||||||
|
#gpio-cells = <2>;
|
||||||
|
compatible = "fsl,cpm1-pario-bank-b";
|
||||||
|
reg = <0xab8 0x10>;
|
||||||
|
gpio-controller;
|
||||||
|
};
|
||||||
|
|
||||||
|
CPM1_PIO_E: gpio-controller@ac8 {
|
||||||
|
#gpio-cells = <2>;
|
||||||
|
compatible = "fsl,cpm1-pario-bank-e";
|
||||||
|
reg = <0xac8 0x18>;
|
||||||
|
gpio-controller;
|
||||||
|
};
|
|
@ -1,22 +1,37 @@
|
||||||
* USB (Universal Serial Bus Controller)
|
Freescale QUICC Engine USB Controller
|
||||||
|
|
||||||
Required properties:
|
Required properties:
|
||||||
- compatible : could be "qe_udc" or "fhci-hcd".
|
- compatible : should be "fsl,<chip>-qe-usb", "fsl,mpc8323-qe-usb".
|
||||||
- mode : the could be "host" or "slave".
|
- reg : the first two cells should contain usb registers location and
|
||||||
- reg : Offset and length of the register set for the device
|
length, the next two two cells should contain PRAM location and
|
||||||
- interrupts : <a b> where a is the interrupt number and b is a
|
length.
|
||||||
field that represents an encoding of the sense and level
|
- interrupts : should contain USB interrupt.
|
||||||
information for the interrupt. This should be encoded based on
|
- interrupt-parent : interrupt source phandle.
|
||||||
the information in section 2) depending on the type of interrupt
|
- fsl,fullspeed-clock : specifies the full speed USB clock source:
|
||||||
controller you have.
|
"none": clock source is disabled
|
||||||
- interrupt-parent : the phandle for the interrupt controller that
|
"brg1" through "brg16": clock source is BRG1-BRG16, respectively
|
||||||
services interrupts for this device.
|
"clk1" through "clk24": clock source is CLK1-CLK24, respectively
|
||||||
|
- fsl,lowspeed-clock : specifies the low speed USB clock source:
|
||||||
|
"none": clock source is disabled
|
||||||
|
"brg1" through "brg16": clock source is BRG1-BRG16, respectively
|
||||||
|
"clk1" through "clk24": clock source is CLK1-CLK24, respectively
|
||||||
|
- hub-power-budget : USB power budget for the root hub, in mA.
|
||||||
|
- gpios : should specify GPIOs in this order: USBOE, USBTP, USBTN, USBRP,
|
||||||
|
USBRN, SPEED (optional), and POWER (optional).
|
||||||
|
|
||||||
Example(slave):
|
Example:
|
||||||
usb@6c0 {
|
|
||||||
compatible = "qe_udc";
|
usb@6c0 {
|
||||||
reg = <6c0 40>;
|
compatible = "fsl,mpc8360-qe-usb", "fsl,mpc8323-qe-usb";
|
||||||
interrupts = <8b 0>;
|
reg = <0x6c0 0x40 0x8b00 0x100>;
|
||||||
interrupt-parent = <700>;
|
interrupts = <11>;
|
||||||
mode = "slave";
|
interrupt-parent = <&qeic>;
|
||||||
};
|
fsl,fullspeed-clock = "clk21";
|
||||||
|
gpios = <&qe_pio_b 2 0 /* USBOE */
|
||||||
|
&qe_pio_b 3 0 /* USBTP */
|
||||||
|
&qe_pio_b 8 0 /* USBTN */
|
||||||
|
&qe_pio_b 9 0 /* USBRP */
|
||||||
|
&qe_pio_b 11 0 /* USBRN */
|
||||||
|
&qe_pio_e 20 0 /* SPEED */
|
||||||
|
&qe_pio_e 21 0 /* POWER */>;
|
||||||
|
};
|
||||||
|
|
17
Documentation/powerpc/dts-bindings/fsl/mcu-mpc8349emitx.txt
Normal file
17
Documentation/powerpc/dts-bindings/fsl/mcu-mpc8349emitx.txt
Normal file
|
@ -0,0 +1,17 @@
|
||||||
|
Freescale MPC8349E-mITX-compatible Power Management Micro Controller Unit (MCU)
|
||||||
|
|
||||||
|
Required properties:
|
||||||
|
- compatible : "fsl,<mcu-chip>-<board>", "fsl,mcu-mpc8349emitx".
|
||||||
|
- reg : should specify I2C address (0x0a).
|
||||||
|
- #gpio-cells : should be 2.
|
||||||
|
- gpio-controller : should be present.
|
||||||
|
|
||||||
|
Example:
|
||||||
|
|
||||||
|
mcu@0a {
|
||||||
|
#gpio-cells = <2>;
|
||||||
|
compatible = "fsl,mc9s08qg8-mpc8349emitx",
|
||||||
|
"fsl,mcu-mpc8349emitx";
|
||||||
|
reg = <0x0a>;
|
||||||
|
gpio-controller;
|
||||||
|
};
|
63
Documentation/powerpc/dts-bindings/fsl/pmc.txt
Normal file
63
Documentation/powerpc/dts-bindings/fsl/pmc.txt
Normal file
|
@ -0,0 +1,63 @@
|
||||||
|
* Power Management Controller
|
||||||
|
|
||||||
|
Properties:
|
||||||
|
- compatible: "fsl,<chip>-pmc".
|
||||||
|
|
||||||
|
"fsl,mpc8349-pmc" should be listed for any chip whose PMC is
|
||||||
|
compatible. "fsl,mpc8313-pmc" should also be listed for any chip
|
||||||
|
whose PMC is compatible, and implies deep-sleep capability.
|
||||||
|
|
||||||
|
"fsl,mpc8548-pmc" should be listed for any chip whose PMC is
|
||||||
|
compatible. "fsl,mpc8536-pmc" should also be listed for any chip
|
||||||
|
whose PMC is compatible, and implies deep-sleep capability.
|
||||||
|
|
||||||
|
"fsl,mpc8641d-pmc" should be listed for any chip whose PMC is
|
||||||
|
compatible; all statements below that apply to "fsl,mpc8548-pmc" also
|
||||||
|
apply to "fsl,mpc8641d-pmc".
|
||||||
|
|
||||||
|
Compatibility does not include bit assigments in SCCR/PMCDR/DEVDISR; these
|
||||||
|
bit assigments are indicated via the sleep specifier in each device's
|
||||||
|
sleep property.
|
||||||
|
|
||||||
|
- reg: For devices compatible with "fsl,mpc8349-pmc", the first resource
|
||||||
|
is the PMC block, and the second resource is the Clock Configuration
|
||||||
|
block.
|
||||||
|
|
||||||
|
For devices compatible with "fsl,mpc8548-pmc", the first resource
|
||||||
|
is a 32-byte block beginning with DEVDISR.
|
||||||
|
|
||||||
|
- interrupts: For "fsl,mpc8349-pmc"-compatible devices, the first
|
||||||
|
resource is the PMC block interrupt.
|
||||||
|
|
||||||
|
- fsl,mpc8313-wakeup-timer: For "fsl,mpc8313-pmc"-compatible devices,
|
||||||
|
this is a phandle to an "fsl,gtm" node on which timer 4 can be used as
|
||||||
|
a wakeup source from deep sleep.
|
||||||
|
|
||||||
|
Sleep specifiers:
|
||||||
|
|
||||||
|
fsl,mpc8349-pmc: Sleep specifiers consist of one cell. For each bit
|
||||||
|
that is set in the cell, the corresponding bit in SCCR will be saved
|
||||||
|
and cleared on suspend, and restored on resume. This sleep controller
|
||||||
|
supports disabling and resuming devices at any time.
|
||||||
|
|
||||||
|
fsl,mpc8536-pmc: Sleep specifiers consist of three cells, the third of
|
||||||
|
which will be ORed into PMCDR upon suspend, and cleared from PMCDR
|
||||||
|
upon resume. The first two cells are as described for fsl,mpc8578-pmc.
|
||||||
|
This sleep controller only supports disabling devices during system
|
||||||
|
sleep, or permanently.
|
||||||
|
|
||||||
|
fsl,mpc8548-pmc: Sleep specifiers consist of one or two cells, the
|
||||||
|
first of which will be ORed into DEVDISR (and the second into
|
||||||
|
DEVDISR2, if present -- this cell should be zero or absent if the
|
||||||
|
hardware does not have DEVDISR2) upon a request for permanent device
|
||||||
|
disabling. This sleep controller does not support configuring devices
|
||||||
|
to disable during system sleep (unless supported by another compatible
|
||||||
|
match), or dynamically.
|
||||||
|
|
||||||
|
Example:
|
||||||
|
|
||||||
|
power@b00 {
|
||||||
|
compatible = "fsl,mpc8313-pmc", "fsl,mpc8349-pmc";
|
||||||
|
reg = <0xb00 0x100 0xa00 0x100>;
|
||||||
|
interrupts = <80 8>;
|
||||||
|
};
|
|
@ -24,46 +24,39 @@ Example:
|
||||||
|
|
||||||
* Gianfar-compatible ethernet nodes
|
* Gianfar-compatible ethernet nodes
|
||||||
|
|
||||||
Required properties:
|
Properties:
|
||||||
|
|
||||||
- device_type : Should be "network"
|
- device_type : Should be "network"
|
||||||
- model : Model of the device. Can be "TSEC", "eTSEC", or "FEC"
|
- model : Model of the device. Can be "TSEC", "eTSEC", or "FEC"
|
||||||
- compatible : Should be "gianfar"
|
- compatible : Should be "gianfar"
|
||||||
- reg : Offset and length of the register set for the device
|
- reg : Offset and length of the register set for the device
|
||||||
- mac-address : List of bytes representing the ethernet address of
|
- local-mac-address : List of bytes representing the ethernet address of
|
||||||
this controller
|
this controller
|
||||||
- interrupts : <a b> where a is the interrupt number and b is a
|
- interrupts : For FEC devices, the first interrupt is the device's
|
||||||
field that represents an encoding of the sense and level
|
interrupt. For TSEC and eTSEC devices, the first interrupt is
|
||||||
information for the interrupt. This should be encoded based on
|
transmit, the second is receive, and the third is error.
|
||||||
the information in section 2) depending on the type of interrupt
|
|
||||||
controller you have.
|
|
||||||
- interrupt-parent : the phandle for the interrupt controller that
|
|
||||||
services interrupts for this device.
|
|
||||||
- phy-handle : The phandle for the PHY connected to this ethernet
|
- phy-handle : The phandle for the PHY connected to this ethernet
|
||||||
controller.
|
controller.
|
||||||
- fixed-link : <a b c d e> where a is emulated phy id - choose any,
|
- fixed-link : <a b c d e> where a is emulated phy id - choose any,
|
||||||
but unique to the all specified fixed-links, b is duplex - 0 half,
|
but unique to the all specified fixed-links, b is duplex - 0 half,
|
||||||
1 full, c is link speed - d#10/d#100/d#1000, d is pause - 0 no
|
1 full, c is link speed - d#10/d#100/d#1000, d is pause - 0 no
|
||||||
pause, 1 pause, e is asym_pause - 0 no asym_pause, 1 asym_pause.
|
pause, 1 pause, e is asym_pause - 0 no asym_pause, 1 asym_pause.
|
||||||
|
|
||||||
Recommended properties:
|
|
||||||
|
|
||||||
- phy-connection-type : a string naming the controller/PHY interface type,
|
- phy-connection-type : a string naming the controller/PHY interface type,
|
||||||
i.e., "mii" (default), "rmii", "gmii", "rgmii", "rgmii-id", "sgmii",
|
i.e., "mii" (default), "rmii", "gmii", "rgmii", "rgmii-id", "sgmii",
|
||||||
"tbi", or "rtbi". This property is only really needed if the connection
|
"tbi", or "rtbi". This property is only really needed if the connection
|
||||||
is of type "rgmii-id", as all other connection types are detected by
|
is of type "rgmii-id", as all other connection types are detected by
|
||||||
hardware.
|
hardware.
|
||||||
|
- fsl,magic-packet : If present, indicates that the hardware supports
|
||||||
|
waking up via magic packet.
|
||||||
|
|
||||||
Example:
|
Example:
|
||||||
ethernet@24000 {
|
ethernet@24000 {
|
||||||
#size-cells = <0>;
|
|
||||||
device_type = "network";
|
device_type = "network";
|
||||||
model = "TSEC";
|
model = "TSEC";
|
||||||
compatible = "gianfar";
|
compatible = "gianfar";
|
||||||
reg = <24000 1000>;
|
reg = <0x24000 0x1000>;
|
||||||
mac-address = [ 00 E0 0C 00 73 00 ];
|
local-mac-address = [ 00 E0 0C 00 73 00 ];
|
||||||
interrupts = <d 3 e 3 12 3>;
|
interrupts = <29 2 30 2 34 2>;
|
||||||
interrupt-parent = <40000>;
|
interrupt-parent = <&mpic>;
|
||||||
phy-handle = <2452000>
|
phy-handle = <&phy0>
|
||||||
};
|
};
|
||||||
|
|
28
Documentation/powerpc/dts-bindings/fsl/upm-nand.txt
Normal file
28
Documentation/powerpc/dts-bindings/fsl/upm-nand.txt
Normal file
|
@ -0,0 +1,28 @@
|
||||||
|
Freescale Localbus UPM programmed to work with NAND flash
|
||||||
|
|
||||||
|
Required properties:
|
||||||
|
- compatible : "fsl,upm-nand".
|
||||||
|
- reg : should specify localbus chip select and size used for the chip.
|
||||||
|
- fsl,upm-addr-offset : UPM pattern offset for the address latch.
|
||||||
|
- fsl,upm-cmd-offset : UPM pattern offset for the command latch.
|
||||||
|
- gpios : may specify optional GPIO connected to the Ready-Not-Busy pin.
|
||||||
|
|
||||||
|
Example:
|
||||||
|
|
||||||
|
upm@1,0 {
|
||||||
|
compatible = "fsl,upm-nand";
|
||||||
|
reg = <1 0 1>;
|
||||||
|
fsl,upm-addr-offset = <16>;
|
||||||
|
fsl,upm-cmd-offset = <8>;
|
||||||
|
gpios = <&qe_pio_e 18 0>;
|
||||||
|
|
||||||
|
flash {
|
||||||
|
#address-cells = <1>;
|
||||||
|
#size-cells = <1>;
|
||||||
|
compatible = "...";
|
||||||
|
|
||||||
|
partition@0 {
|
||||||
|
...
|
||||||
|
};
|
||||||
|
};
|
||||||
|
};
|
15
Documentation/powerpc/dts-bindings/gpio/led.txt
Normal file
15
Documentation/powerpc/dts-bindings/gpio/led.txt
Normal file
|
@ -0,0 +1,15 @@
|
||||||
|
LED connected to GPIO
|
||||||
|
|
||||||
|
Required properties:
|
||||||
|
- compatible : should be "gpio-led".
|
||||||
|
- label : (optional) the label for this LED. If omitted, the label is
|
||||||
|
taken from the node name (excluding the unit address).
|
||||||
|
- gpios : should specify LED GPIO.
|
||||||
|
|
||||||
|
Example:
|
||||||
|
|
||||||
|
led@0 {
|
||||||
|
compatible = "gpio-led";
|
||||||
|
label = "hdd";
|
||||||
|
gpios = <&mcu_pio 0 1>;
|
||||||
|
};
|
|
@ -217,7 +217,7 @@ Although it is not recommended, you can specify '0' in the soc.model
|
||||||
field to skip matching SOCs altogether.
|
field to skip matching SOCs altogether.
|
||||||
|
|
||||||
The 'model' field is a 16-bit number that matches the actual SOC. The
|
The 'model' field is a 16-bit number that matches the actual SOC. The
|
||||||
'major' and 'minor' fields are the major and minor revision numbrs,
|
'major' and 'minor' fields are the major and minor revision numbers,
|
||||||
respectively, of the SOC.
|
respectively, of the SOC.
|
||||||
|
|
||||||
For example, to match the 8323, revision 1.0:
|
For example, to match the 8323, revision 1.0:
|
||||||
|
|
|
@ -25,7 +25,7 @@ device 4711 via subchannel 1 in subchannel set 0, and subchannel 2 is a non-I/O
|
||||||
subchannel. Device 1234 is accessed via subchannel 0 in subchannel set 1.
|
subchannel. Device 1234 is accessed via subchannel 0 in subchannel set 1.
|
||||||
|
|
||||||
The subchannel named 'defunct' does not represent any real subchannel on the
|
The subchannel named 'defunct' does not represent any real subchannel on the
|
||||||
system; it is a pseudo subchannel where disconnnected ccw devices are moved to
|
system; it is a pseudo subchannel where disconnected ccw devices are moved to
|
||||||
if they are displaced by another ccw device becoming operational on their
|
if they are displaced by another ccw device becoming operational on their
|
||||||
former subchannel. The ccw devices will be moved again to a proper subchannel
|
former subchannel. The ccw devices will be moved again to a proper subchannel
|
||||||
if they become operational again on that subchannel.
|
if they become operational again on that subchannel.
|
||||||
|
|
|
@ -524,7 +524,7 @@
|
||||||
- Michael Lang
|
- Michael Lang
|
||||||
|
|
||||||
June 25 1997: (v1.8b)
|
June 25 1997: (v1.8b)
|
||||||
1) Some cosmetical changes for the handling of SCSI-device-types.
|
1) Some cosmetic changes for the handling of SCSI-device-types.
|
||||||
Now, also CD-Burners / WORMs and SCSI-scanners should work. For
|
Now, also CD-Burners / WORMs and SCSI-scanners should work. For
|
||||||
MO-drives I have no experience, therefore not yet supported.
|
MO-drives I have no experience, therefore not yet supported.
|
||||||
In logical_devices I changed from different type-variables to one
|
In logical_devices I changed from different type-variables to one
|
||||||
|
@ -914,7 +914,7 @@
|
||||||
in version 4.0. This was never really necessary, as all troubles were
|
in version 4.0. This was never really necessary, as all troubles were
|
||||||
based on non-command related reasons up to now, so bypassing commands
|
based on non-command related reasons up to now, so bypassing commands
|
||||||
did not help to avoid any bugs. It is kept in 3.2X for debugging reasons.
|
did not help to avoid any bugs. It is kept in 3.2X for debugging reasons.
|
||||||
5) Dynamical reassignment of ldns was again verified and analyzed to be
|
5) Dynamic reassignment of ldns was again verified and analyzed to be
|
||||||
completely inoperational. This is corrected and should work now.
|
completely inoperational. This is corrected and should work now.
|
||||||
6) All commands that get sent to the SCSI adapter were verified and
|
6) All commands that get sent to the SCSI adapter were verified and
|
||||||
completed in such a way, that they are now completely conform to the
|
completed in such a way, that they are now completely conform to the
|
||||||
|
@ -1386,7 +1386,7 @@
|
||||||
concerning the Linux-kernel in special, this SCSI-driver comes without any
|
concerning the Linux-kernel in special, this SCSI-driver comes without any
|
||||||
warranty. Its functionality is tested as good as possible on certain
|
warranty. Its functionality is tested as good as possible on certain
|
||||||
machines and combinations of computer hardware, which does not exclude,
|
machines and combinations of computer hardware, which does not exclude,
|
||||||
that dataloss or severe damage of hardware is possible while using this
|
that data loss or severe damage of hardware is possible while using this
|
||||||
part of software on some arbitrary computer hardware or in combination
|
part of software on some arbitrary computer hardware or in combination
|
||||||
with other software packages. It is highly recommended to make backup
|
with other software packages. It is highly recommended to make backup
|
||||||
copies of your data before using this software. Furthermore, personal
|
copies of your data before using this software. Furthermore, personal
|
||||||
|
|
|
@ -36,7 +36,7 @@ Cable pull and temporary device Loss:
|
||||||
being removed, a switch rebooting, or a device reboot), the driver could
|
being removed, a switch rebooting, or a device reboot), the driver could
|
||||||
hide the disappearance of the device from the midlayer. I/O's issued to
|
hide the disappearance of the device from the midlayer. I/O's issued to
|
||||||
the LLDD would simply be queued for a short duration, allowing the device
|
the LLDD would simply be queued for a short duration, allowing the device
|
||||||
to reappear or link come back alive, with no inadvertant side effects
|
to reappear or link come back alive, with no inadvertent side effects
|
||||||
to the system. If the driver did not hide these conditions, i/o would be
|
to the system. If the driver did not hide these conditions, i/o would be
|
||||||
errored by the driver, the mid-layer would exhaust its retries, and the
|
errored by the driver, the mid-layer would exhaust its retries, and the
|
||||||
device would be taken offline. Manual intervention would be required to
|
device would be taken offline. Manual intervention would be required to
|
||||||
|
|
|
@ -65,7 +65,7 @@ Overview:
|
||||||
discussion will concentrate on NPIV.
|
discussion will concentrate on NPIV.
|
||||||
|
|
||||||
Note: World Wide Name assignment (and uniqueness guarantees) are left
|
Note: World Wide Name assignment (and uniqueness guarantees) are left
|
||||||
up to an administrative entity controling the vport. For example,
|
up to an administrative entity controlling the vport. For example,
|
||||||
if vports are to be associated with virtual machines, a XEN mgmt
|
if vports are to be associated with virtual machines, a XEN mgmt
|
||||||
utility would be responsible for creating wwpn/wwnn's for the vport,
|
utility would be responsible for creating wwpn/wwnn's for the vport,
|
||||||
using it's own naming authority and OUI. (Note: it already does this
|
using it's own naming authority and OUI. (Note: it already does this
|
||||||
|
@ -91,7 +91,7 @@ Device Trees and Vport Objects:
|
||||||
Here's what to expect in the device tree :
|
Here's what to expect in the device tree :
|
||||||
The typical Physical Port's Scsi_Host:
|
The typical Physical Port's Scsi_Host:
|
||||||
/sys/devices/.../host17/
|
/sys/devices/.../host17/
|
||||||
and it has the typical decendent tree:
|
and it has the typical descendant tree:
|
||||||
/sys/devices/.../host17/rport-17:0-0/target17:0:0/17:0:0:0:
|
/sys/devices/.../host17/rport-17:0-0/target17:0:0/17:0:0:0:
|
||||||
and then the vport is created on the Physical Port:
|
and then the vport is created on the Physical Port:
|
||||||
/sys/devices/.../host17/vport-17:0-0
|
/sys/devices/.../host17/vport-17:0-0
|
||||||
|
@ -192,7 +192,7 @@ Vport States:
|
||||||
independent of the adapter's link state.
|
independent of the adapter's link state.
|
||||||
- Instantiation of the vport on the FC link via ELS traffic, etc.
|
- Instantiation of the vport on the FC link via ELS traffic, etc.
|
||||||
This is equivalent to a "link up" and successfull link initialization.
|
This is equivalent to a "link up" and successfull link initialization.
|
||||||
Futher information can be found in the interfaces section below for
|
Further information can be found in the interfaces section below for
|
||||||
Vport Creation.
|
Vport Creation.
|
||||||
|
|
||||||
Once a vport has been instantiated with the kernel/LLDD, a vport state
|
Once a vport has been instantiated with the kernel/LLDD, a vport state
|
||||||
|
|
|
@ -12,7 +12,7 @@ means no changes to adjanced clock
|
||||||
Internally, the clk_set_rate_ex forwards request to clk->ops->set_rate method,
|
Internally, the clk_set_rate_ex forwards request to clk->ops->set_rate method,
|
||||||
if it is present in ops structure. The method should set the clock rate and adjust
|
if it is present in ops structure. The method should set the clock rate and adjust
|
||||||
all needed clocks according to the passed algo_id.
|
all needed clocks according to the passed algo_id.
|
||||||
Exact values for algo_id are machine-dependend. For the sh7722, the following
|
Exact values for algo_id are machine-dependent. For the sh7722, the following
|
||||||
values are defined:
|
values are defined:
|
||||||
|
|
||||||
NO_CHANGE = 0,
|
NO_CHANGE = 0,
|
||||||
|
|
|
@ -1024,6 +1024,7 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
|
||||||
intel-mac-v3 Intel Mac Type 3
|
intel-mac-v3 Intel Mac Type 3
|
||||||
intel-mac-v4 Intel Mac Type 4
|
intel-mac-v4 Intel Mac Type 4
|
||||||
intel-mac-v5 Intel Mac Type 5
|
intel-mac-v5 Intel Mac Type 5
|
||||||
|
intel-mac-auto Intel Mac (detect type according to subsystem id)
|
||||||
macmini Intel Mac Mini (equivalent with type 3)
|
macmini Intel Mac Mini (equivalent with type 3)
|
||||||
macbook Intel Mac Book (eq. type 5)
|
macbook Intel Mac Book (eq. type 5)
|
||||||
macbook-pro-v1 Intel Mac Book Pro 1st generation (eq. type 3)
|
macbook-pro-v1 Intel Mac Book Pro 1st generation (eq. type 3)
|
||||||
|
|
|
@ -236,15 +236,15 @@ The parameter can be given:
|
||||||
alias snd-card-1 snd-usb-audio
|
alias snd-card-1 snd-usb-audio
|
||||||
options snd-usb-audio index=1 device_setup=0x09
|
options snd-usb-audio index=1 device_setup=0x09
|
||||||
|
|
||||||
CAUTION when initializaing the device
|
CAUTION when initializing the device
|
||||||
-------------------------------------
|
-------------------------------------
|
||||||
|
|
||||||
* Correct initialization on the device requires that device_setup is given to
|
* Correct initialization on the device requires that device_setup is given to
|
||||||
the module BEFORE the device is turned on. So, if you use the "manual probing"
|
the module BEFORE the device is turned on. So, if you use the "manual probing"
|
||||||
method described above, take care to power-on the device AFTER this initialization.
|
method described above, take care to power-on the device AFTER this initialization.
|
||||||
|
|
||||||
* Failing to respect this will lead in a misconfiguration of the device. In this case
|
* Failing to respect this will lead to a misconfiguration of the device. In this case
|
||||||
turn off the device, unproble the snd-usb-audio module, then probe it again with
|
turn off the device, unprobe the snd-usb-audio module, then probe it again with
|
||||||
correct device_setup parameter and then (and only then) turn on the device again.
|
correct device_setup parameter and then (and only then) turn on the device again.
|
||||||
|
|
||||||
* If you've correctly initialized the device in a valid mode and then want to switch
|
* If you've correctly initialized the device in a valid mode and then want to switch
|
||||||
|
@ -388,9 +388,9 @@ There are 2 main potential issues when using Jackd with the device:
|
||||||
|
|
||||||
Jack supports big endian devices only in recent versions (thanks to
|
Jack supports big endian devices only in recent versions (thanks to
|
||||||
Andreas Steinmetz for his first big-endian patch). I can't remember
|
Andreas Steinmetz for his first big-endian patch). I can't remember
|
||||||
extacly when this support was released into jackd, let's just say that
|
exactly when this support was released into jackd, let's just say that
|
||||||
with jackd version 0.103.0 it's almost ok (just a small bug is affecting
|
with jackd version 0.103.0 it's almost ok (just a small bug is affecting
|
||||||
16bits Big-Endian devices, but since you've read carefully the above
|
16bits Big-Endian devices, but since you've read carefully the above
|
||||||
paragraphs, you're now using kernel >= 2.6.23 and your 16bits devices
|
paragraphs, you're now using kernel >= 2.6.23 and your 16bits devices
|
||||||
are now Little Endians ;-) ).
|
are now Little Endians ;-) ).
|
||||||
|
|
||||||
|
|
|
@ -42,7 +42,7 @@
|
||||||
<sect1><title>Device Components</title>
|
<sect1><title>Device Components</title>
|
||||||
!Esound/core/device.c
|
!Esound/core/device.c
|
||||||
</sect1>
|
</sect1>
|
||||||
<sect1><title>KMOD and Device File Entries</title>
|
<sect1><title>Module requests and Device File Entries</title>
|
||||||
!Esound/core/sound.c
|
!Esound/core/sound.c
|
||||||
</sect1>
|
</sect1>
|
||||||
<sect1><title>Memory Management Helpers</title>
|
<sect1><title>Memory Management Helpers</title>
|
||||||
|
|
|
@ -67,7 +67,7 @@ CONFIG_SND_HDA_POWER_SAVE kconfig. It's called when the codec needs
|
||||||
to power up or may power down. The controller should check the all
|
to power up or may power down. The controller should check the all
|
||||||
belonging codecs on the bus whether they are actually powered off
|
belonging codecs on the bus whether they are actually powered off
|
||||||
(check codec->power_on), and optionally the driver may power down the
|
(check codec->power_on), and optionally the driver may power down the
|
||||||
contoller side, too.
|
controller side, too.
|
||||||
|
|
||||||
The bus instance is created via snd_hda_bus_new(). You need to pass
|
The bus instance is created via snd_hda_bus_new(). You need to pass
|
||||||
the card instance, the template, and the pointer to store the
|
the card instance, the template, and the pointer to store the
|
||||||
|
|
|
@ -68,7 +68,7 @@ Audio DAPM widgets fall into a number of types:-
|
||||||
(Widgets are defined in include/sound/soc-dapm.h)
|
(Widgets are defined in include/sound/soc-dapm.h)
|
||||||
|
|
||||||
Widgets are usually added in the codec driver and the machine driver. There are
|
Widgets are usually added in the codec driver and the machine driver. There are
|
||||||
convience macros defined in soc-dapm.h that can be used to quickly build a
|
convenience macros defined in soc-dapm.h that can be used to quickly build a
|
||||||
list of widgets of the codecs and machines DAPM widgets.
|
list of widgets of the codecs and machines DAPM widgets.
|
||||||
|
|
||||||
Most widgets have a name, register, shift and invert. Some widgets have extra
|
Most widgets have a name, register, shift and invert. Some widgets have extra
|
||||||
|
|
|
@ -73,10 +73,10 @@ recompiled, or use "make C=2" to run sparse on the files whether they need to
|
||||||
be recompiled or not. The latter is a fast way to check the whole tree if you
|
be recompiled or not. The latter is a fast way to check the whole tree if you
|
||||||
have already built it.
|
have already built it.
|
||||||
|
|
||||||
The optional make variable CHECKFLAGS can be used to pass arguments to sparse.
|
The optional make variable CF can be used to pass arguments to sparse. The
|
||||||
The build system passes -Wbitwise to sparse automatically. To perform
|
build system passes -Wbitwise to sparse automatically. To perform endianness
|
||||||
endianness checks, you may define __CHECK_ENDIAN__:
|
checks, you may define __CHECK_ENDIAN__:
|
||||||
|
|
||||||
make C=2 CHECKFLAGS="-D__CHECK_ENDIAN__"
|
make C=2 CF="-D__CHECK_ENDIAN__"
|
||||||
|
|
||||||
These checks are disabled by default as they generate a host of warnings.
|
These checks are disabled by default as they generate a host of warnings.
|
||||||
|
|
|
@ -270,8 +270,8 @@ The pinout of the connectors on the IO8+ is:
|
||||||
Hardware handshaking issues.
|
Hardware handshaking issues.
|
||||||
============================
|
============================
|
||||||
|
|
||||||
The driver can be compiled in two different ways. The default
|
The driver can be told to operate in two different ways. The default
|
||||||
("Specialix DTR/RTS pin is RTS" is off) the pin behaves as DTR when
|
behaviour is specialix.sx_rtscts = 0 where the pin behaves as DTR when
|
||||||
hardware handshaking is off. It behaves as the RTS hardware
|
hardware handshaking is off. It behaves as the RTS hardware
|
||||||
handshaking signal when hardware handshaking is selected.
|
handshaking signal when hardware handshaking is selected.
|
||||||
|
|
||||||
|
@ -280,7 +280,7 @@ cable will either be compatible with hardware handshaking or with
|
||||||
software handshaking. So switching on the fly is not really an
|
software handshaking. So switching on the fly is not really an
|
||||||
option.
|
option.
|
||||||
|
|
||||||
I actually prefer to use the "Specialix DTR/RTS pin is RTS" option.
|
I actually prefer to use the "specialix.sx_rtscts=1" option.
|
||||||
This makes the DTR/RTS pin always an RTS pin, and ioctls to
|
This makes the DTR/RTS pin always an RTS pin, and ioctls to
|
||||||
change DTR are always ignored. I have a cable that is configured
|
change DTR are always ignored. I have a cable that is configured
|
||||||
for this.
|
for this.
|
||||||
|
@ -379,7 +379,5 @@ it doesn't fit in your computer, bring back the card.
|
||||||
You have to WRITE to the address register to even
|
You have to WRITE to the address register to even
|
||||||
read-probe a CD186x register. Disable autodetection?
|
read-probe a CD186x register. Disable autodetection?
|
||||||
-- Specialix: any suggestions?
|
-- Specialix: any suggestions?
|
||||||
- Arbitrary baud rates are not implemented yet.
|
|
||||||
If you need this, bug me about it.
|
|
||||||
|
|
||||||
|
|
||||||
|
|
|
@ -116,7 +116,7 @@ of kilobytes free. The VM uses this number to compute a pages_min
|
||||||
value for each lowmem zone in the system. Each lowmem zone gets
|
value for each lowmem zone in the system. Each lowmem zone gets
|
||||||
a number of reserved free pages based proportionally on its size.
|
a number of reserved free pages based proportionally on its size.
|
||||||
|
|
||||||
Some minimal ammount of memory is needed to satisfy PF_MEMALLOC
|
Some minimal amount of memory is needed to satisfy PF_MEMALLOC
|
||||||
allocations; if you set this to lower than 1024KB, your system will
|
allocations; if you set this to lower than 1024KB, your system will
|
||||||
become subtly broken, and prone to deadlock under high loads.
|
become subtly broken, and prone to deadlock under high loads.
|
||||||
|
|
||||||
|
|
|
@ -3,9 +3,8 @@ Rules on how to access information in the Linux kernel sysfs
|
||||||
The kernel-exported sysfs exports internal kernel implementation details
|
The kernel-exported sysfs exports internal kernel implementation details
|
||||||
and depends on internal kernel structures and layout. It is agreed upon
|
and depends on internal kernel structures and layout. It is agreed upon
|
||||||
by the kernel developers that the Linux kernel does not provide a stable
|
by the kernel developers that the Linux kernel does not provide a stable
|
||||||
internal API. As sysfs is a direct export of kernel internal
|
internal API. Therefore, there are aspects of the sysfs interface that
|
||||||
structures, the sysfs interface cannot provide a stable interface either;
|
may not be stable across kernel releases.
|
||||||
it may always change along with internal kernel changes.
|
|
||||||
|
|
||||||
To minimize the risk of breaking users of sysfs, which are in most cases
|
To minimize the risk of breaking users of sysfs, which are in most cases
|
||||||
low-level userspace applications, with a new kernel release, the users
|
low-level userspace applications, with a new kernel release, the users
|
||||||
|
|
|
@ -305,21 +305,14 @@ driver, like this:
|
||||||
|
|
||||||
which will result in the needed drivers getting loaded automatically.
|
which will result in the needed drivers getting loaded automatically.
|
||||||
|
|
||||||
g. if you are planning on using kerneld to automatically load the
|
g. if you are planning on having the kernel automatically request
|
||||||
module for you, then you need to edit /etc/conf.modules and add the
|
the module for you, then you need to edit /etc/conf.modules and add the
|
||||||
following lines:
|
following lines:
|
||||||
|
|
||||||
options ixj dspio=0x340 xio=0x330 ixjdebug=0
|
options ixj dspio=0x340 xio=0x330 ixjdebug=0
|
||||||
|
|
||||||
If you do this, then when you execute an application that uses the
|
If you do this, then when you execute an application that uses the
|
||||||
module kerneld will load the module for you. Note that to do this,
|
module the kernel will request that it is loaded.
|
||||||
you need to have your kernel set to support kerneld. You can check
|
|
||||||
for this by looking at /usr/src/linux/.config and you should see this:
|
|
||||||
|
|
||||||
# Loadable module support
|
|
||||||
#
|
|
||||||
<snip>
|
|
||||||
CONFIG_KMOD=y
|
|
||||||
|
|
||||||
h. if you want non-root users to be able to read and write to the
|
h. if you want non-root users to be able to read and write to the
|
||||||
ixj devices (this is a good idea!) you should do the following:
|
ixj devices (this is a good idea!) you should do the following:
|
||||||
|
|
|
@ -125,7 +125,7 @@ increase of flexibility and the avoidance of duplicated code across
|
||||||
architectures justifies the slight increase of the binary size.
|
architectures justifies the slight increase of the binary size.
|
||||||
|
|
||||||
The conversion of an architecture has no functional impact, but allows to
|
The conversion of an architecture has no functional impact, but allows to
|
||||||
utilize the high resolution and dynamic tick functionalites without any change
|
utilize the high resolution and dynamic tick functionalities without any change
|
||||||
to the clock event device and timer interrupt code. After the conversion the
|
to the clock event device and timer interrupt code. After the conversion the
|
||||||
enabling of high resolution timers and dynamic ticks is simply provided by
|
enabling of high resolution timers and dynamic ticks is simply provided by
|
||||||
adding the kernel/time/Kconfig file to the architecture specific Kconfig and
|
adding the kernel/time/Kconfig file to the architecture specific Kconfig and
|
||||||
|
|
|
@ -218,9 +218,35 @@ If use of such macros is not convenient, another option is to use memcpy(),
|
||||||
where the source or destination (or both) are of type u8* or unsigned char*.
|
where the source or destination (or both) are of type u8* or unsigned char*.
|
||||||
Due to the byte-wise nature of this operation, unaligned accesses are avoided.
|
Due to the byte-wise nature of this operation, unaligned accesses are avoided.
|
||||||
|
|
||||||
--
|
|
||||||
Author: Daniel Drake <dsd@gentoo.org>
|
Alignment vs. Networking
|
||||||
With help from: Alan Cox, Avuton Olrich, Heikki Orsila, Jan Engelhardt,
|
========================
|
||||||
Johannes Berg, Kyle McMartin, Kyle Moffett, Randy Dunlap, Robert Hancock,
|
|
||||||
Uli Kunitz, Vadim Lobanov
|
On architectures that require aligned loads, networking requires that the IP
|
||||||
|
header is aligned on a four-byte boundary to optimise the IP stack. For
|
||||||
|
regular ethernet hardware, the constant NET_IP_ALIGN is used. On most
|
||||||
|
architectures this constant has the value 2 because the normal ethernet
|
||||||
|
header is 14 bytes long, so in order to get proper alignment one needs to
|
||||||
|
DMA to an address which can be expressed as 4*n + 2. One notable exception
|
||||||
|
here is powerpc which defines NET_IP_ALIGN to 0 because DMA to unaligned
|
||||||
|
addresses can be very expensive and dwarf the cost of unaligned loads.
|
||||||
|
|
||||||
|
For some ethernet hardware that cannot DMA to unaligned addresses like
|
||||||
|
4*n+2 or non-ethernet hardware, this can be a problem, and it is then
|
||||||
|
required to copy the incoming frame into an aligned buffer. Because this is
|
||||||
|
unnecessary on architectures that can do unaligned accesses, the code can be
|
||||||
|
made dependent on CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS like so:
|
||||||
|
|
||||||
|
#ifdef CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS
|
||||||
|
skb = original skb
|
||||||
|
#else
|
||||||
|
skb = copy skb
|
||||||
|
#endif
|
||||||
|
|
||||||
|
--
|
||||||
|
Authors: Daniel Drake <dsd@gentoo.org>,
|
||||||
|
Johannes Berg <johannes@sipsolutions.net>
|
||||||
|
With help from: Alan Cox, Avuton Olrich, Heikki Orsila, Jan Engelhardt,
|
||||||
|
Kyle McMartin, Kyle Moffett, Randy Dunlap, Robert Hancock, Uli Kunitz,
|
||||||
|
Vadim Lobanov
|
||||||
|
|
||||||
|
|
|
@ -8,7 +8,7 @@ not) in a system. This feature will allow you to implement a lock-down
|
||||||
of USB devices, fully controlled by user space.
|
of USB devices, fully controlled by user space.
|
||||||
|
|
||||||
As of now, when a USB device is connected it is configured and
|
As of now, when a USB device is connected it is configured and
|
||||||
it's interfaces inmediately made available to the users. With this
|
its interfaces are immediately made available to the users. With this
|
||||||
modification, only if root authorizes the device to be configured will
|
modification, only if root authorizes the device to be configured will
|
||||||
then it be possible to use it.
|
then it be possible to use it.
|
||||||
|
|
||||||
|
|
|
@ -1,6 +1,7 @@
|
||||||
|
|
||||||
Linux Gadget Serial Driver v2.0
|
Linux Gadget Serial Driver v2.0
|
||||||
11/20/2004
|
11/20/2004
|
||||||
|
(updated 8-May-2008 for v2.3)
|
||||||
|
|
||||||
|
|
||||||
License and Disclaimer
|
License and Disclaimer
|
||||||
|
@ -31,7 +32,7 @@ Prerequisites
|
||||||
-------------
|
-------------
|
||||||
Versions of the gadget serial driver are available for the
|
Versions of the gadget serial driver are available for the
|
||||||
2.4 Linux kernels, but this document assumes you are using
|
2.4 Linux kernels, but this document assumes you are using
|
||||||
version 2.0 or later of the gadget serial driver in a 2.6
|
version 2.3 or later of the gadget serial driver in a 2.6
|
||||||
Linux kernel.
|
Linux kernel.
|
||||||
|
|
||||||
This document assumes that you are familiar with Linux and
|
This document assumes that you are familiar with Linux and
|
||||||
|
@ -40,6 +41,12 @@ standard utilities, use minicom and HyperTerminal, and work with
|
||||||
USB and serial devices. It also assumes you configure the Linux
|
USB and serial devices. It also assumes you configure the Linux
|
||||||
gadget and usb drivers as modules.
|
gadget and usb drivers as modules.
|
||||||
|
|
||||||
|
With version 2.3 of the driver, major and minor device nodes are
|
||||||
|
no longer statically defined. Your Linux based system should mount
|
||||||
|
sysfs in /sys, and use "mdev" (in Busybox) or "udev" to make the
|
||||||
|
/dev nodes matching the sysfs /sys/class/tty files.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
Overview
|
Overview
|
||||||
--------
|
--------
|
||||||
|
@ -104,15 +111,8 @@ driver. All this are listed under "USB Gadget Support" when
|
||||||
configuring the kernel. Then rebuild and install the kernel or
|
configuring the kernel. Then rebuild and install the kernel or
|
||||||
modules.
|
modules.
|
||||||
|
|
||||||
The gadget serial driver uses major number 127, for now. So you
|
|
||||||
will need to create a device node for it, like this:
|
|
||||||
|
|
||||||
mknod /dev/ttygserial c 127 0
|
|
||||||
|
|
||||||
You only need to do this once.
|
|
||||||
|
|
||||||
Then you must load the gadget serial driver. To load it as an
|
Then you must load the gadget serial driver. To load it as an
|
||||||
ACM device, do this:
|
ACM device (recommended for interoperability), do this:
|
||||||
|
|
||||||
modprobe g_serial use_acm=1
|
modprobe g_serial use_acm=1
|
||||||
|
|
||||||
|
@ -125,6 +125,23 @@ controller driver. This must be done each time you reboot the gadget
|
||||||
side Linux system. You can add this to the start up scripts, if
|
side Linux system. You can add this to the start up scripts, if
|
||||||
desired.
|
desired.
|
||||||
|
|
||||||
|
Your system should use mdev (from busybox) or udev to make the
|
||||||
|
device nodes. After this gadget driver has been set up you should
|
||||||
|
then see a /dev/ttyGS0 node:
|
||||||
|
|
||||||
|
# ls -l /dev/ttyGS0 | cat
|
||||||
|
crw-rw---- 1 root root 253, 0 May 8 14:10 /dev/ttyGS0
|
||||||
|
#
|
||||||
|
|
||||||
|
Note that the major number (253, above) is system-specific. If
|
||||||
|
you need to create /dev nodes by hand, the right numbers to use
|
||||||
|
will be in the /sys/class/tty/ttyGS0/dev file.
|
||||||
|
|
||||||
|
When you link this gadget driver early, perhaps even statically,
|
||||||
|
you may want to set up an /etc/inittab entry to run "getty" on it.
|
||||||
|
The /dev/ttyGS0 line should work like most any other serial port.
|
||||||
|
|
||||||
|
|
||||||
If gadget serial is loaded as an ACM device you will want to use
|
If gadget serial is loaded as an ACM device you will want to use
|
||||||
either the Windows or Linux ACM driver on the host side. If gadget
|
either the Windows or Linux ACM driver on the host side. If gadget
|
||||||
serial is loaded as a bulk in/out device, you will want to use the
|
serial is loaded as a bulk in/out device, you will want to use the
|
||||||
|
|
|
@ -81,8 +81,11 @@ re-enumeration shows that the device now attached to that port has the
|
||||||
same descriptors as before, including the Vendor and Product IDs, then
|
same descriptors as before, including the Vendor and Product IDs, then
|
||||||
the kernel continues to use the same device structure. In effect, the
|
the kernel continues to use the same device structure. In effect, the
|
||||||
kernel treats the device as though it had merely been reset instead of
|
kernel treats the device as though it had merely been reset instead of
|
||||||
unplugged. The same thing happens if the host controller is in the
|
unplugged.
|
||||||
expected state but a USB device was unplugged and then replugged.
|
|
||||||
|
The same thing happens if the host controller is in the expected state
|
||||||
|
but a USB device was unplugged and then replugged, or if a USB device
|
||||||
|
fails to carry out a normal resume.
|
||||||
|
|
||||||
If no device is now attached to the port, or if the descriptors are
|
If no device is now attached to the port, or if the descriptors are
|
||||||
different from what the kernel remembers, then the treatment is what
|
different from what the kernel remembers, then the treatment is what
|
||||||
|
|
|
@ -1,165 +0,0 @@
|
||||||
Specification and Internals for the New UHCI Driver (Whitepaper...)
|
|
||||||
|
|
||||||
brought to you by
|
|
||||||
|
|
||||||
Georg Acher, acher@in.tum.de (executive slave) (base guitar)
|
|
||||||
Deti Fliegl, deti@fliegl.de (executive slave) (lead voice)
|
|
||||||
Thomas Sailer, sailer@ife.ee.ethz.ch (chief consultant) (cheer leader)
|
|
||||||
|
|
||||||
$Id: README.uhci,v 1.1 1999/12/14 14:03:02 fliegl Exp $
|
|
||||||
|
|
||||||
This document and the new uhci sources can be found on
|
|
||||||
http://hotswap.in.tum.de/usb
|
|
||||||
|
|
||||||
1. General issues
|
|
||||||
|
|
||||||
1.1 Why a new UHCI driver, we already have one?!?
|
|
||||||
|
|
||||||
Correct, but its internal structure got more and more mixed up by the (still
|
|
||||||
ongoing) efforts to get isochronous transfers (ISO) to work.
|
|
||||||
Since there is an increasing need for reliable ISO-transfers (especially
|
|
||||||
for USB-audio needed by TS and for a DAB-USB-Receiver build by GA and DF),
|
|
||||||
this state was a bit unsatisfying in our opinion, so we've decided (based
|
|
||||||
on knowledge and experiences with the old UHCI driver) to start
|
|
||||||
from scratch with a new approach, much simpler but at the same time more
|
|
||||||
powerful.
|
|
||||||
It is inspired by the way Win98/Win2000 handles USB requests via URBs,
|
|
||||||
but it's definitely 100% free of MS-code and doesn't crash while
|
|
||||||
unplugging an used ISO-device like Win98 ;-)
|
|
||||||
Some code for HW setup and root hub management was taken from the
|
|
||||||
original UHCI driver, but heavily modified to fit into the new code.
|
|
||||||
The invention of the basic concept, and major coding were completed in two
|
|
||||||
days (and nights) on the 16th and 17th of October 1999, now known as the
|
|
||||||
great USB-October-Revolution started by GA, DF, and TS ;-)
|
|
||||||
|
|
||||||
Since the concept is in no way UHCI dependent, we hope that it will also be
|
|
||||||
transferred to the OHCI-driver, so both drivers share a common API.
|
|
||||||
|
|
||||||
1.2. Advantages and disadvantages
|
|
||||||
|
|
||||||
+ All USB transfer types work now!
|
|
||||||
+ Asynchronous operation
|
|
||||||
+ Simple, but powerful interface (only two calls for start and cancel)
|
|
||||||
+ Easy migration to the new API, simplified by a compatibility API
|
|
||||||
+ Simple usage of ISO transfers
|
|
||||||
+ Automatic linking of requests
|
|
||||||
+ ISO transfers allow variable length for each frame and striping
|
|
||||||
+ No CPU dependent and non-portable atomic memory access, no asm()-inlines
|
|
||||||
+ Tested on x86 and Alpha
|
|
||||||
|
|
||||||
- Rewriting for ISO transfers needed
|
|
||||||
|
|
||||||
1.3. Is there some compatibility to the old API?
|
|
||||||
|
|
||||||
Yes, but only for control, bulk and interrupt transfers. We've implemented
|
|
||||||
some wrapper calls for these transfer types. The usbcore works fine with
|
|
||||||
these wrappers. For ISO there's no compatibility, because the old ISO-API
|
|
||||||
and its semantics were unnecessary complicated in our opinion.
|
|
||||||
|
|
||||||
1.4. What's really working?
|
|
||||||
|
|
||||||
As said above, CTRL and BULK already work fine even with the wrappers,
|
|
||||||
so legacy code wouldn't notice the change.
|
|
||||||
Regarding to Thomas, ISO transfers now run stable with USB audio.
|
|
||||||
INT transfers (e.g. mouse driver) work fine, too.
|
|
||||||
|
|
||||||
1.5. Are there any bugs?
|
|
||||||
|
|
||||||
No ;-)
|
|
||||||
Hm...
|
|
||||||
Well, of course this implementation needs extensive testing on all available
|
|
||||||
hardware, but we believe that any fixes shouldn't harm the overall concept.
|
|
||||||
|
|
||||||
1.6. What should be done next?
|
|
||||||
|
|
||||||
A large part of the request handling seems to be identical for UHCI and
|
|
||||||
OHCI, so it would be a good idea to extract the common parts and have only
|
|
||||||
the HW specific stuff in uhci.c. Furthermore, all other USB device drivers
|
|
||||||
should need URBification, if they use isochronous or interrupt transfers.
|
|
||||||
One thing missing in the current implementation (and the old UHCI driver)
|
|
||||||
is fair queueing for BULK transfers. Since this would need (in principle)
|
|
||||||
the alteration of already constructed TD chains (to switch from depth to
|
|
||||||
breadth execution), another way has to be found. Maybe some simple
|
|
||||||
heuristics work with the same effect.
|
|
||||||
|
|
||||||
---------------------------------------------------------------------------
|
|
||||||
|
|
||||||
2. Internal structure and mechanisms
|
|
||||||
|
|
||||||
To get quickly familiar with the internal structures, here's a short
|
|
||||||
description how the new UHCI driver works. However, the ultimate source of
|
|
||||||
truth is only uhci.c!
|
|
||||||
|
|
||||||
2.1. Descriptor structure (QHs and TDs)
|
|
||||||
|
|
||||||
During initialization, the following skeleton is allocated in init_skel:
|
|
||||||
|
|
||||||
framespecific | common chain
|
|
||||||
|
|
||||||
framelist[]
|
|
||||||
[ 0 ]-----> TD --> TD -------\
|
|
||||||
[ 1 ]-----> TD --> TD --------> TD ----> QH -------> QH -------> QH ---> NULL
|
|
||||||
... TD --> TD -------/
|
|
||||||
[1023]-----> TD --> TD ------/
|
|
||||||
|
|
||||||
^^ ^^ ^^ ^^ ^^ ^^
|
|
||||||
1024 TDs for 7 TDs for 1 TD for Start of Start of End Chain
|
|
||||||
ISO INT (2-128ms) 1ms-INT CTRL Chain BULK Chain
|
|
||||||
|
|
||||||
For each CTRL or BULK transfer a new QH is allocated and the containing data
|
|
||||||
transfers are appended as (vertical) TDs. After building the whole QH with its
|
|
||||||
dangling TDs, the QH is inserted before the BULK Chain QH (for CTRL) or
|
|
||||||
before the End Chain QH (for BULK). Since only the QH->next pointers are
|
|
||||||
affected, no atomic memory operation is required. The three QHs in the
|
|
||||||
common chain are never equipped with TDs!
|
|
||||||
|
|
||||||
For ISO or INT, the TD for each frame is simply inserted into the appropriate
|
|
||||||
ISO/INT-TD-chain for the desired frame. The 7 skeleton INT-TDs are scattered
|
|
||||||
among the 1024 frames similar to the old UHCI driver.
|
|
||||||
|
|
||||||
For CTRL/BULK/ISO, the last TD in the transfer has the IOC-bit set. For INT,
|
|
||||||
every TD (there is only one...) has the IOC-bit set.
|
|
||||||
|
|
||||||
Besides the data for the UHCI controller (2 or 4 32bit words), the descriptors
|
|
||||||
are double-linked through the .vertical and .horizontal elements in the
|
|
||||||
SW data of the descriptor (using the double-linked list structures and
|
|
||||||
operations), but SW-linking occurs only in closed domains, i.e. for each of
|
|
||||||
the 1024 ISO-chains and the 8 INT-chains there is a closed cycle. This
|
|
||||||
simplifies all insertions and unlinking operations and avoids costly
|
|
||||||
bus_to_virt()-calls.
|
|
||||||
|
|
||||||
2.2. URB structure and linking to QH/TDs
|
|
||||||
|
|
||||||
During assembly of the QH and TDs of the requested action, these descriptors
|
|
||||||
are stored in urb->urb_list, so the allocated QH/TD descriptors are bound to
|
|
||||||
this URB.
|
|
||||||
If the assembly was successful and the descriptors were added to the HW chain,
|
|
||||||
the corresponding URB is inserted into a global URB list for this controller.
|
|
||||||
This list stores all pending URBs.
|
|
||||||
|
|
||||||
2.3. Interrupt processing
|
|
||||||
|
|
||||||
Since UHCI provides no means to directly detect completed transactions, the
|
|
||||||
following is done in each UHCI interrupt (uhci_interrupt()):
|
|
||||||
|
|
||||||
For each URB in the pending queue (process_urb()), the ACTIVE-flag of the
|
|
||||||
associated TDs are processed (depending on the transfer type
|
|
||||||
process_{transfer|interrupt|iso}()). If the TDs are not active anymore,
|
|
||||||
they indicate the completion of the transaction and the status is calculated.
|
|
||||||
Inactive QH/TDs are removed from the HW chain (since the host controller
|
|
||||||
already removed the TDs from the QH, no atomic access is needed) and
|
|
||||||
eventually the URB is marked as completed (OK or errors) and removed from the
|
|
||||||
pending queue. Then the next linked URB is submitted. After (or immediately
|
|
||||||
before) that, the completion handler is called.
|
|
||||||
|
|
||||||
2.4. Unlinking URBs
|
|
||||||
|
|
||||||
First, all QH/TDs stored in the URB are unlinked from the HW chain.
|
|
||||||
To ensure that the host controller really left a vertical TD chain, we
|
|
||||||
wait for one frame. After that, the TDs are physically destroyed.
|
|
||||||
|
|
||||||
2.5. URB linking and the consequences
|
|
||||||
|
|
||||||
Since URBs can be linked and the corresponding submit_urb is called in
|
|
||||||
the UHCI-interrupt, all work associated with URB/QH/TD assembly has to be
|
|
||||||
interrupt save. This forces kmalloc to use GFP_ATOMIC in the interrupt.
|
|
|
@ -2,3 +2,4 @@
|
||||||
1 -> Hauppauge HVR950Q (au0828) [2040:7200,2040:7210,2040:7217,2040:721b,2040:721f,2040:7280,0fd9:0008]
|
1 -> Hauppauge HVR950Q (au0828) [2040:7200,2040:7210,2040:7217,2040:721b,2040:721f,2040:7280,0fd9:0008]
|
||||||
2 -> Hauppauge HVR850 (au0828) [2040:7240]
|
2 -> Hauppauge HVR850 (au0828) [2040:7240]
|
||||||
3 -> DViCO FusionHDTV USB (au0828) [0fe9:d620]
|
3 -> DViCO FusionHDTV USB (au0828) [0fe9:d620]
|
||||||
|
4 -> Hauppauge HVR950Q rev xxF8 (au0828) [2040:7201,2040:7211,2040:7281]
|
||||||
|
|
|
@ -1,11 +1,11 @@
|
||||||
0 -> Unknown EM2800 video grabber (em2800) [eb1a:2800]
|
0 -> Unknown EM2800 video grabber (em2800) [eb1a:2800]
|
||||||
1 -> Unknown EM2750/28xx video grabber (em2820/em2840) [eb1a:2750,eb1a:2820,eb1a:2821,eb1a:2860,eb1a:2861,eb1a:2870,eb1a:2881,eb1a:2883]
|
1 -> Unknown EM2750/28xx video grabber (em2820/em2840) [eb1a:2820,eb1a:2821,eb1a:2860,eb1a:2861,eb1a:2870,eb1a:2881,eb1a:2883]
|
||||||
2 -> Terratec Cinergy 250 USB (em2820/em2840) [0ccd:0036]
|
2 -> Terratec Cinergy 250 USB (em2820/em2840) [0ccd:0036]
|
||||||
3 -> Pinnacle PCTV USB 2 (em2820/em2840) [2304:0208]
|
3 -> Pinnacle PCTV USB 2 (em2820/em2840) [2304:0208]
|
||||||
4 -> Hauppauge WinTV USB 2 (em2820/em2840) [2040:4200,2040:4201]
|
4 -> Hauppauge WinTV USB 2 (em2820/em2840) [2040:4200,2040:4201]
|
||||||
5 -> MSI VOX USB 2.0 (em2820/em2840)
|
5 -> MSI VOX USB 2.0 (em2820/em2840)
|
||||||
6 -> Terratec Cinergy 200 USB (em2800)
|
6 -> Terratec Cinergy 200 USB (em2800)
|
||||||
7 -> Leadtek Winfast USB II (em2800)
|
7 -> Leadtek Winfast USB II (em2800) [0413:6023]
|
||||||
8 -> Kworld USB2800 (em2800)
|
8 -> Kworld USB2800 (em2800)
|
||||||
9 -> Pinnacle Dazzle DVC 90/DVC 100 (em2820/em2840) [2304:0207,2304:021a]
|
9 -> Pinnacle Dazzle DVC 90/DVC 100 (em2820/em2840) [2304:0207,2304:021a]
|
||||||
10 -> Hauppauge WinTV HVR 900 (em2880) [2040:6500]
|
10 -> Hauppauge WinTV HVR 900 (em2880) [2040:6500]
|
||||||
|
@ -14,7 +14,46 @@
|
||||||
13 -> Terratec Prodigy XS (em2880) [0ccd:0047]
|
13 -> Terratec Prodigy XS (em2880) [0ccd:0047]
|
||||||
14 -> Pixelview Prolink PlayTV USB 2.0 (em2820/em2840)
|
14 -> Pixelview Prolink PlayTV USB 2.0 (em2820/em2840)
|
||||||
15 -> V-Gear PocketTV (em2800)
|
15 -> V-Gear PocketTV (em2800)
|
||||||
16 -> Hauppauge WinTV HVR 950 (em2880) [2040:6513,2040:6517,2040:651b,2040:651f]
|
16 -> Hauppauge WinTV HVR 950 (em2883) [2040:6513,2040:6517,2040:651b,2040:651f]
|
||||||
17 -> Pinnacle PCTV HD Pro Stick (em2880) [2304:0227]
|
17 -> Pinnacle PCTV HD Pro Stick (em2880) [2304:0227]
|
||||||
18 -> Hauppauge WinTV HVR 900 (R2) (em2880) [2040:6502]
|
18 -> Hauppauge WinTV HVR 900 (R2) (em2880) [2040:6502]
|
||||||
19 -> PointNix Intra-Oral Camera (em2860)
|
19 -> PointNix Intra-Oral Camera (em2860)
|
||||||
|
20 -> AMD ATI TV Wonder HD 600 (em2880) [0438:b002]
|
||||||
|
21 -> eMPIA Technology, Inc. GrabBeeX+ Video Encoder (em2800) [eb1a:2801]
|
||||||
|
22 -> Unknown EM2750/EM2751 webcam grabber (em2750) [eb1a:2750,eb1a:2751]
|
||||||
|
23 -> Huaqi DLCW-130 (em2750)
|
||||||
|
24 -> D-Link DUB-T210 TV Tuner (em2820/em2840) [2001:f112]
|
||||||
|
25 -> Gadmei UTV310 (em2820/em2840)
|
||||||
|
26 -> Hercules Smart TV USB 2.0 (em2820/em2840)
|
||||||
|
27 -> Pinnacle PCTV USB 2 (Philips FM1216ME) (em2820/em2840)
|
||||||
|
28 -> Leadtek Winfast USB II Deluxe (em2820/em2840)
|
||||||
|
29 -> Pinnacle Dazzle DVC 100 (em2820/em2840)
|
||||||
|
30 -> Videology 20K14XUSB USB2.0 (em2820/em2840)
|
||||||
|
31 -> Usbgear VD204v9 (em2821)
|
||||||
|
32 -> Supercomp USB 2.0 TV (em2821)
|
||||||
|
33 -> SIIG AVTuner-PVR/Prolink PlayTV USB 2.0 (em2821)
|
||||||
|
34 -> Terratec Cinergy A Hybrid XS (em2860) [0ccd:004f]
|
||||||
|
35 -> Typhoon DVD Maker (em2860)
|
||||||
|
36 -> NetGMBH Cam (em2860)
|
||||||
|
37 -> Gadmei UTV330 (em2860)
|
||||||
|
38 -> Yakumo MovieMixer (em2861)
|
||||||
|
39 -> KWorld PVRTV 300U (em2861) [eb1a:e300]
|
||||||
|
40 -> Plextor ConvertX PX-TV100U (em2861) [093b:a005]
|
||||||
|
41 -> Kworld 350 U DVB-T (em2870) [eb1a:e350]
|
||||||
|
42 -> Kworld 355 U DVB-T (em2870) [eb1a:e355,eb1a:e357]
|
||||||
|
43 -> Terratec Cinergy T XS (em2870) [0ccd:0043]
|
||||||
|
44 -> Terratec Cinergy T XS (MT2060) (em2870)
|
||||||
|
45 -> Pinnacle PCTV DVB-T (em2870)
|
||||||
|
46 -> Compro, VideoMate U3 (em2870) [185b:2870]
|
||||||
|
47 -> KWorld DVB-T 305U (em2880) [eb1a:e305]
|
||||||
|
48 -> KWorld DVB-T 310U (em2880)
|
||||||
|
49 -> MSI DigiVox A/D (em2880) [eb1a:e310]
|
||||||
|
50 -> MSI DigiVox A/D II (em2880) [eb1a:e320]
|
||||||
|
51 -> Terratec Hybrid XS Secam (em2880) [0ccd:004c]
|
||||||
|
52 -> DNT DA2 Hybrid (em2881)
|
||||||
|
53 -> Pinnacle Hybrid Pro (em2881)
|
||||||
|
54 -> Kworld VS-DVB-T 323UR (em2882) [eb1a:e323]
|
||||||
|
55 -> Terratec Hybrid XS (em2882) (em2882) [0ccd:005e]
|
||||||
|
56 -> Pinnacle Hybrid Pro (2) (em2882) [2304:0226]
|
||||||
|
57 -> Kworld PlusTV HD Hybrid 330 (em2883) [eb1a:a316]
|
||||||
|
58 -> Compro VideoMate ForYou/Stereo (em2820/em2840) [185b:2041]
|
||||||
|
|
|
@ -1,4 +1,4 @@
|
||||||
List of the webcams know by gspca.
|
List of the webcams known by gspca.
|
||||||
|
|
||||||
The modules are:
|
The modules are:
|
||||||
gspca_main main driver
|
gspca_main main driver
|
||||||
|
|
|
@ -157,7 +157,7 @@ Loading can be done as shown below:
|
||||||
|
|
||||||
[root@localhost home]# modprobe sn9c102
|
[root@localhost home]# modprobe sn9c102
|
||||||
|
|
||||||
Note that the module is called "sn9c102" for historic reasons, althought it
|
Note that the module is called "sn9c102" for historic reasons, although it
|
||||||
does not just support the SN9C102.
|
does not just support the SN9C102.
|
||||||
|
|
||||||
At this point all the devices supported by the driver and connected to the USB
|
At this point all the devices supported by the driver and connected to the USB
|
||||||
|
|
|
@ -193,9 +193,6 @@ Description: Automatic 'ovcamchip' module loading: 0 disabled, 1 enabled.
|
||||||
loads that module automatically. This action is performed as
|
loads that module automatically. This action is performed as
|
||||||
once soon as the 'w9968cf' module is loaded into memory.
|
once soon as the 'w9968cf' module is loaded into memory.
|
||||||
Default: 1
|
Default: 1
|
||||||
Note: The kernel must be compiled with the CONFIG_KMOD option
|
|
||||||
enabled for the 'ovcamchip' module to be loaded and for
|
|
||||||
this parameter to be present.
|
|
||||||
-------------------------------------------------------------------------------
|
-------------------------------------------------------------------------------
|
||||||
Name: simcams
|
Name: simcams
|
||||||
Type: int
|
Type: int
|
||||||
|
|
|
@ -77,7 +77,7 @@ memory that is preset in system at this time. System administrators may want
|
||||||
to put this command in one of the local rc init files. This will enable the
|
to put this command in one of the local rc init files. This will enable the
|
||||||
kernel to request huge pages early in the boot process (when the possibility
|
kernel to request huge pages early in the boot process (when the possibility
|
||||||
of getting physical contiguous pages is still very high). In either
|
of getting physical contiguous pages is still very high). In either
|
||||||
case, adminstrators will want to verify the number of hugepages actually
|
case, administrators will want to verify the number of hugepages actually
|
||||||
allocated by checking the sysctl or meminfo.
|
allocated by checking the sysctl or meminfo.
|
||||||
|
|
||||||
/proc/sys/vm/nr_overcommit_hugepages indicates how large the pool of
|
/proc/sys/vm/nr_overcommit_hugepages indicates how large the pool of
|
||||||
|
@ -95,6 +95,29 @@ this condition holds, however, no more surplus huge pages will be
|
||||||
allowed on the system until one of the two sysctls are increased
|
allowed on the system until one of the two sysctls are increased
|
||||||
sufficiently, or the surplus huge pages go out of use and are freed.
|
sufficiently, or the surplus huge pages go out of use and are freed.
|
||||||
|
|
||||||
|
With support for multiple hugepage pools at run-time available, much of
|
||||||
|
the hugepage userspace interface has been duplicated in sysfs. The above
|
||||||
|
information applies to the default hugepage size (which will be
|
||||||
|
controlled by the proc interfaces for backwards compatibility). The root
|
||||||
|
hugepage control directory is
|
||||||
|
|
||||||
|
/sys/kernel/mm/hugepages
|
||||||
|
|
||||||
|
For each hugepage size supported by the running kernel, a subdirectory
|
||||||
|
will exist, of the form
|
||||||
|
|
||||||
|
hugepages-${size}kB
|
||||||
|
|
||||||
|
Inside each of these directories, the same set of files will exist:
|
||||||
|
|
||||||
|
nr_hugepages
|
||||||
|
nr_overcommit_hugepages
|
||||||
|
free_hugepages
|
||||||
|
resv_hugepages
|
||||||
|
surplus_hugepages
|
||||||
|
|
||||||
|
which function as described above for the default hugepage-sized case.
|
||||||
|
|
||||||
If the user applications are going to request hugepages using mmap system
|
If the user applications are going to request hugepages using mmap system
|
||||||
call, then it is required that system administrator mount a file system of
|
call, then it is required that system administrator mount a file system of
|
||||||
type hugetlbfs:
|
type hugetlbfs:
|
||||||
|
|
|
@ -58,7 +58,7 @@ most general to most specific:
|
||||||
the policy at the time they were allocated.
|
the policy at the time they were allocated.
|
||||||
|
|
||||||
VMA Policy: A "VMA" or "Virtual Memory Area" refers to a range of a task's
|
VMA Policy: A "VMA" or "Virtual Memory Area" refers to a range of a task's
|
||||||
virtual adddress space. A task may define a specific policy for a range
|
virtual address space. A task may define a specific policy for a range
|
||||||
of its virtual address space. See the MEMORY POLICIES APIS section,
|
of its virtual address space. See the MEMORY POLICIES APIS section,
|
||||||
below, for an overview of the mbind() system call used to set a VMA
|
below, for an overview of the mbind() system call used to set a VMA
|
||||||
policy.
|
policy.
|
||||||
|
@ -353,7 +353,7 @@ follows:
|
||||||
|
|
||||||
Because of this extra reference counting, and because we must lookup
|
Because of this extra reference counting, and because we must lookup
|
||||||
shared policies in a tree structure under spinlock, shared policies are
|
shared policies in a tree structure under spinlock, shared policies are
|
||||||
more expensive to use in the page allocation path. This is expecially
|
more expensive to use in the page allocation path. This is especially
|
||||||
true for shared policies on shared memory regions shared by tasks running
|
true for shared policies on shared memory regions shared by tasks running
|
||||||
on different NUMA nodes. This extra overhead can be avoided by always
|
on different NUMA nodes. This extra overhead can be avoided by always
|
||||||
falling back to task or system default policy for shared memory regions,
|
falling back to task or system default policy for shared memory regions,
|
||||||
|
|
|
@ -114,6 +114,6 @@ CREDITS
|
||||||
|
|
||||||
Original impetus and research by Randy Dunlap
|
Original impetus and research by Randy Dunlap
|
||||||
Written by Jonathan Corbet
|
Written by Jonathan Corbet
|
||||||
Improvements via coments from Satyam Sharma, Johannes Stezenbach, Jesper
|
Improvements via comments from Satyam Sharma, Johannes Stezenbach, Jesper
|
||||||
Juhl, Heikki Orsila, H. Peter Anvin, Philipp Hahn, and Stefan
|
Juhl, Heikki Orsila, H. Peter Anvin, Philipp Hahn, and Stefan
|
||||||
Richter.
|
Richter.
|
||||||
|
|
3
Kbuild
3
Kbuild
|
@ -43,7 +43,7 @@ $(obj)/$(bounds-file): kernel/bounds.s Kbuild
|
||||||
# 2) Generate asm-offsets.h
|
# 2) Generate asm-offsets.h
|
||||||
#
|
#
|
||||||
|
|
||||||
offsets-file := include/asm-$(SRCARCH)/asm-offsets.h
|
offsets-file := include/asm/asm-offsets.h
|
||||||
|
|
||||||
always += $(offsets-file)
|
always += $(offsets-file)
|
||||||
targets += $(offsets-file)
|
targets += $(offsets-file)
|
||||||
|
@ -81,7 +81,6 @@ arch/$(SRCARCH)/kernel/asm-offsets.s: arch/$(SRCARCH)/kernel/asm-offsets.c \
|
||||||
$(call if_changed_dep,cc_s_c)
|
$(call if_changed_dep,cc_s_c)
|
||||||
|
|
||||||
$(obj)/$(offsets-file): arch/$(SRCARCH)/kernel/asm-offsets.s Kbuild
|
$(obj)/$(offsets-file): arch/$(SRCARCH)/kernel/asm-offsets.s Kbuild
|
||||||
$(Q)mkdir -p $(dir $@)
|
|
||||||
$(call cmd,offsets)
|
$(call cmd,offsets)
|
||||||
|
|
||||||
#####
|
#####
|
||||||
|
|
Some files were not shown because too many files have changed in this diff Show more
Reference in a new issue