You've already forked linux-apfs
mirror of
https://github.com/linux-apfs/linux-apfs.git
synced 2026-05-01 15:00:59 -07:00
Merge branch 'master' of ../mmc
This commit is contained in:
Pierre Ossman
@@ -316,12 +316,10 @@ reduce current DMA mapping usage or delay and try again later).
|
||||
pci_map_sg(struct pci_dev *hwdev, struct scatterlist *sg,
|
||||
int nents, int direction)
|
||||
|
||||
Maps a scatter gather list from the block layer.
|
||||
|
||||
Returns: the number of physical segments mapped (this may be shorter
|
||||
than <nents> passed in if the block layer determines that some
|
||||
elements of the scatter/gather list are physically adjacent and thus
|
||||
may be mapped with a single entry).
|
||||
than <nents> passed in if some elements of the scatter/gather list are
|
||||
physically or virtually adjacent and an IOMMU maps them with a single
|
||||
entry).
|
||||
|
||||
Please note that the sg cannot be mapped again if it has been mapped once.
|
||||
The mapping process is allowed to destroy information in the sg.
|
||||
|
||||
@@ -6,7 +6,7 @@
|
||||
# To add a new book the only step required is to add the book to the
|
||||
# list of DOCBOOKS.
|
||||
|
||||
DOCBOOKS := wanbook.xml z8530book.xml mcabook.xml \
|
||||
DOCBOOKS := z8530book.xml mcabook.xml \
|
||||
kernel-hacking.xml kernel-locking.xml deviceiobook.xml \
|
||||
procfs-guide.xml writing_usb_driver.xml networking.xml \
|
||||
kernel-api.xml filesystems.xml lsm.xml usb.xml kgdb.xml \
|
||||
|
||||
@@ -98,9 +98,6 @@
|
||||
X!Enet/core/wireless.c
|
||||
</sect1>
|
||||
-->
|
||||
<sect1><title>Synchronous PPP</title>
|
||||
!Edrivers/net/wan/syncppp.c
|
||||
</sect1>
|
||||
</chapter>
|
||||
|
||||
</book>
|
||||
|
||||
@@ -1,99 +0,0 @@
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN"
|
||||
"http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd" []>
|
||||
|
||||
<book id="WANGuide">
|
||||
<bookinfo>
|
||||
<title>Synchronous PPP and Cisco HDLC Programming Guide</title>
|
||||
|
||||
<authorgroup>
|
||||
<author>
|
||||
<firstname>Alan</firstname>
|
||||
<surname>Cox</surname>
|
||||
<affiliation>
|
||||
<address>
|
||||
<email>alan@lxorguk.ukuu.org.uk</email>
|
||||
</address>
|
||||
</affiliation>
|
||||
</author>
|
||||
</authorgroup>
|
||||
|
||||
<copyright>
|
||||
<year>2000</year>
|
||||
<holder>Alan Cox</holder>
|
||||
</copyright>
|
||||
|
||||
<legalnotice>
|
||||
<para>
|
||||
This documentation is free software; you can redistribute
|
||||
it and/or modify it under the terms of the GNU General Public
|
||||
License as published by the Free Software Foundation; either
|
||||
version 2 of the License, or (at your option) any later
|
||||
version.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
This program is distributed in the hope that it will be
|
||||
useful, but WITHOUT ANY WARRANTY; without even the implied
|
||||
warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
|
||||
See the GNU General Public License for more details.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
You should have received a copy of the GNU General Public
|
||||
License along with this program; if not, write to the Free
|
||||
Software Foundation, Inc., 59 Temple Place, Suite 330, Boston,
|
||||
MA 02111-1307 USA
|
||||
</para>
|
||||
|
||||
<para>
|
||||
For more details see the file COPYING in the source
|
||||
distribution of Linux.
|
||||
</para>
|
||||
</legalnotice>
|
||||
</bookinfo>
|
||||
|
||||
<toc></toc>
|
||||
|
||||
<chapter id="intro">
|
||||
<title>Introduction</title>
|
||||
<para>
|
||||
The syncppp drivers in Linux provide a fairly complete
|
||||
implementation of Cisco HDLC and a minimal implementation of
|
||||
PPP. The longer term goal is to switch the PPP layer to the
|
||||
generic PPP interface that is new in Linux 2.3.x. The API should
|
||||
remain unchanged when this is done, but support will then be
|
||||
available for IPX, compression and other PPP features
|
||||
</para>
|
||||
</chapter>
|
||||
<chapter id="bugs">
|
||||
<title>Known Bugs And Assumptions</title>
|
||||
<para>
|
||||
<variablelist>
|
||||
<varlistentry><term>PPP is minimal</term>
|
||||
<listitem>
|
||||
<para>
|
||||
The current PPP implementation is very basic, although sufficient
|
||||
for most wan usages.
|
||||
</para>
|
||||
</listitem></varlistentry>
|
||||
|
||||
<varlistentry><term>Cisco HDLC Quirks</term>
|
||||
<listitem>
|
||||
<para>
|
||||
Currently we do not end all packets with the correct Cisco multicast
|
||||
or unicast flags. Nothing appears to mind too much but this should
|
||||
be corrected.
|
||||
</para>
|
||||
</listitem></varlistentry>
|
||||
</variablelist>
|
||||
|
||||
</para>
|
||||
</chapter>
|
||||
|
||||
<chapter id="pubfunctions">
|
||||
<title>Public Functions Provided</title>
|
||||
!Edrivers/net/wan/syncppp.c
|
||||
</chapter>
|
||||
|
||||
</book>
|
||||
@@ -16,6 +16,8 @@ RTFP.txt
|
||||
- List of RCU papers (bibliography) going back to 1980.
|
||||
torture.txt
|
||||
- RCU Torture Test Operation (CONFIG_RCU_TORTURE_TEST)
|
||||
trace.txt
|
||||
- CONFIG_RCU_TRACE debugfs files and formats
|
||||
UP.txt
|
||||
- RCU on Uniprocessor Systems
|
||||
whatisRCU.txt
|
||||
|
||||
@@ -0,0 +1,167 @@
|
||||
Using hlist_nulls to protect read-mostly linked lists and
|
||||
objects using SLAB_DESTROY_BY_RCU allocations.
|
||||
|
||||
Please read the basics in Documentation/RCU/listRCU.txt
|
||||
|
||||
Using special makers (called 'nulls') is a convenient way
|
||||
to solve following problem :
|
||||
|
||||
A typical RCU linked list managing objects which are
|
||||
allocated with SLAB_DESTROY_BY_RCU kmem_cache can
|
||||
use following algos :
|
||||
|
||||
1) Lookup algo
|
||||
--------------
|
||||
rcu_read_lock()
|
||||
begin:
|
||||
obj = lockless_lookup(key);
|
||||
if (obj) {
|
||||
if (!try_get_ref(obj)) // might fail for free objects
|
||||
goto begin;
|
||||
/*
|
||||
* Because a writer could delete object, and a writer could
|
||||
* reuse these object before the RCU grace period, we
|
||||
* must check key after geting the reference on object
|
||||
*/
|
||||
if (obj->key != key) { // not the object we expected
|
||||
put_ref(obj);
|
||||
goto begin;
|
||||
}
|
||||
}
|
||||
rcu_read_unlock();
|
||||
|
||||
Beware that lockless_lookup(key) cannot use traditional hlist_for_each_entry_rcu()
|
||||
but a version with an additional memory barrier (smp_rmb())
|
||||
|
||||
lockless_lookup(key)
|
||||
{
|
||||
struct hlist_node *node, *next;
|
||||
for (pos = rcu_dereference((head)->first);
|
||||
pos && ({ next = pos->next; smp_rmb(); prefetch(next); 1; }) &&
|
||||
({ tpos = hlist_entry(pos, typeof(*tpos), member); 1; });
|
||||
pos = rcu_dereference(next))
|
||||
if (obj->key == key)
|
||||
return obj;
|
||||
return NULL;
|
||||
|
||||
And note the traditional hlist_for_each_entry_rcu() misses this smp_rmb() :
|
||||
|
||||
struct hlist_node *node;
|
||||
for (pos = rcu_dereference((head)->first);
|
||||
pos && ({ prefetch(pos->next); 1; }) &&
|
||||
({ tpos = hlist_entry(pos, typeof(*tpos), member); 1; });
|
||||
pos = rcu_dereference(pos->next))
|
||||
if (obj->key == key)
|
||||
return obj;
|
||||
return NULL;
|
||||
}
|
||||
|
||||
Quoting Corey Minyard :
|
||||
|
||||
"If the object is moved from one list to another list in-between the
|
||||
time the hash is calculated and the next field is accessed, and the
|
||||
object has moved to the end of a new list, the traversal will not
|
||||
complete properly on the list it should have, since the object will
|
||||
be on the end of the new list and there's not a way to tell it's on a
|
||||
new list and restart the list traversal. I think that this can be
|
||||
solved by pre-fetching the "next" field (with proper barriers) before
|
||||
checking the key."
|
||||
|
||||
2) Insert algo :
|
||||
----------------
|
||||
|
||||
We need to make sure a reader cannot read the new 'obj->obj_next' value
|
||||
and previous value of 'obj->key'. Or else, an item could be deleted
|
||||
from a chain, and inserted into another chain. If new chain was empty
|
||||
before the move, 'next' pointer is NULL, and lockless reader can
|
||||
not detect it missed following items in original chain.
|
||||
|
||||
/*
|
||||
* Please note that new inserts are done at the head of list,
|
||||
* not in the middle or end.
|
||||
*/
|
||||
obj = kmem_cache_alloc(...);
|
||||
lock_chain(); // typically a spin_lock()
|
||||
obj->key = key;
|
||||
atomic_inc(&obj->refcnt);
|
||||
/*
|
||||
* we need to make sure obj->key is updated before obj->next
|
||||
*/
|
||||
smp_wmb();
|
||||
hlist_add_head_rcu(&obj->obj_node, list);
|
||||
unlock_chain(); // typically a spin_unlock()
|
||||
|
||||
|
||||
3) Remove algo
|
||||
--------------
|
||||
Nothing special here, we can use a standard RCU hlist deletion.
|
||||
But thanks to SLAB_DESTROY_BY_RCU, beware a deleted object can be reused
|
||||
very very fast (before the end of RCU grace period)
|
||||
|
||||
if (put_last_reference_on(obj) {
|
||||
lock_chain(); // typically a spin_lock()
|
||||
hlist_del_init_rcu(&obj->obj_node);
|
||||
unlock_chain(); // typically a spin_unlock()
|
||||
kmem_cache_free(cachep, obj);
|
||||
}
|
||||
|
||||
|
||||
|
||||
--------------------------------------------------------------------------
|
||||
With hlist_nulls we can avoid extra smp_rmb() in lockless_lookup()
|
||||
and extra smp_wmb() in insert function.
|
||||
|
||||
For example, if we choose to store the slot number as the 'nulls'
|
||||
end-of-list marker for each slot of the hash table, we can detect
|
||||
a race (some writer did a delete and/or a move of an object
|
||||
to another chain) checking the final 'nulls' value if
|
||||
the lookup met the end of chain. If final 'nulls' value
|
||||
is not the slot number, then we must restart the lookup at
|
||||
the begining. If the object was moved to same chain,
|
||||
then the reader doesnt care : It might eventually
|
||||
scan the list again without harm.
|
||||
|
||||
|
||||
1) lookup algo
|
||||
|
||||
head = &table[slot];
|
||||
rcu_read_lock();
|
||||
begin:
|
||||
hlist_nulls_for_each_entry_rcu(obj, node, head, member) {
|
||||
if (obj->key == key) {
|
||||
if (!try_get_ref(obj)) // might fail for free objects
|
||||
goto begin;
|
||||
if (obj->key != key) { // not the object we expected
|
||||
put_ref(obj);
|
||||
goto begin;
|
||||
}
|
||||
goto out;
|
||||
}
|
||||
/*
|
||||
* if the nulls value we got at the end of this lookup is
|
||||
* not the expected one, we must restart lookup.
|
||||
* We probably met an item that was moved to another chain.
|
||||
*/
|
||||
if (get_nulls_value(node) != slot)
|
||||
goto begin;
|
||||
obj = NULL;
|
||||
|
||||
out:
|
||||
rcu_read_unlock();
|
||||
|
||||
2) Insert function :
|
||||
--------------------
|
||||
|
||||
/*
|
||||
* Please note that new inserts are done at the head of list,
|
||||
* not in the middle or end.
|
||||
*/
|
||||
obj = kmem_cache_alloc(cachep);
|
||||
lock_chain(); // typically a spin_lock()
|
||||
obj->key = key;
|
||||
atomic_set(&obj->refcnt, 1);
|
||||
/*
|
||||
* insert obj in RCU way (readers might be traversing chain)
|
||||
*/
|
||||
hlist_nulls_add_head_rcu(&obj->obj_node, list);
|
||||
unlock_chain(); // typically a spin_unlock()
|
||||
@@ -0,0 +1,413 @@
|
||||
CONFIG_RCU_TRACE debugfs Files and Formats
|
||||
|
||||
|
||||
The rcupreempt and rcutree implementations of RCU provide debugfs trace
|
||||
output that summarizes counters and state. This information is useful for
|
||||
debugging RCU itself, and can sometimes also help to debug abuses of RCU.
|
||||
Note that the rcuclassic implementation of RCU does not provide debugfs
|
||||
trace output.
|
||||
|
||||
The following sections describe the debugfs files and formats for
|
||||
preemptable RCU (rcupreempt) and hierarchical RCU (rcutree).
|
||||
|
||||
|
||||
Preemptable RCU debugfs Files and Formats
|
||||
|
||||
This implementation of RCU provides three debugfs files under the
|
||||
top-level directory RCU: rcu/rcuctrs (which displays the per-CPU
|
||||
counters used by preemptable RCU) rcu/rcugp (which displays grace-period
|
||||
counters), and rcu/rcustats (which internal counters for debugging RCU).
|
||||
|
||||
The output of "cat rcu/rcuctrs" looks as follows:
|
||||
|
||||
CPU last cur F M
|
||||
0 5 -5 0 0
|
||||
1 -1 0 0 0
|
||||
2 0 1 0 0
|
||||
3 0 1 0 0
|
||||
4 0 1 0 0
|
||||
5 0 1 0 0
|
||||
6 0 2 0 0
|
||||
7 0 -1 0 0
|
||||
8 0 1 0 0
|
||||
ggp = 26226, state = waitzero
|
||||
|
||||
The per-CPU fields are as follows:
|
||||
|
||||
o "CPU" gives the CPU number. Offline CPUs are not displayed.
|
||||
|
||||
o "last" gives the value of the counter that is being decremented
|
||||
for the current grace period phase. In the example above,
|
||||
the counters sum to 4, indicating that there are still four
|
||||
RCU read-side critical sections still running that started
|
||||
before the last counter flip.
|
||||
|
||||
o "cur" gives the value of the counter that is currently being
|
||||
both incremented (by rcu_read_lock()) and decremented (by
|
||||
rcu_read_unlock()). In the example above, the counters sum to
|
||||
1, indicating that there is only one RCU read-side critical section
|
||||
still running that started after the last counter flip.
|
||||
|
||||
o "F" indicates whether RCU is waiting for this CPU to acknowledge
|
||||
a counter flip. In the above example, RCU is not waiting on any,
|
||||
which is consistent with the state being "waitzero" rather than
|
||||
"waitack".
|
||||
|
||||
o "M" indicates whether RCU is waiting for this CPU to execute a
|
||||
memory barrier. In the above example, RCU is not waiting on any,
|
||||
which is consistent with the state being "waitzero" rather than
|
||||
"waitmb".
|
||||
|
||||
o "ggp" is the global grace-period counter.
|
||||
|
||||
o "state" is the RCU state, which can be one of the following:
|
||||
|
||||
o "idle": there is no grace period in progress.
|
||||
|
||||
o "waitack": RCU just incremented the global grace-period
|
||||
counter, which has the effect of reversing the roles of
|
||||
the "last" and "cur" counters above, and is waiting for
|
||||
all the CPUs to acknowledge the flip. Once the flip has
|
||||
been acknowledged, CPUs will no longer be incrementing
|
||||
what are now the "last" counters, so that their sum will
|
||||
decrease monotonically down to zero.
|
||||
|
||||
o "waitzero": RCU is waiting for the sum of the "last" counters
|
||||
to decrease to zero.
|
||||
|
||||
o "waitmb": RCU is waiting for each CPU to execute a memory
|
||||
barrier, which ensures that instructions from a given CPU's
|
||||
last RCU read-side critical section cannot be reordered
|
||||
with instructions following the memory-barrier instruction.
|
||||
|
||||
The output of "cat rcu/rcugp" looks as follows:
|
||||
|
||||
oldggp=48870 newggp=48873
|
||||
|
||||
Note that reading from this file provokes a synchronize_rcu(). The
|
||||
"oldggp" value is that of "ggp" from rcu/rcuctrs above, taken before
|
||||
executing the synchronize_rcu(), and the "newggp" value is also the
|
||||
"ggp" value, but taken after the synchronize_rcu() command returns.
|
||||
|
||||
|
||||
The output of "cat rcu/rcugp" looks as follows:
|
||||
|
||||
na=1337955 nl=40 wa=1337915 wl=44 da=1337871 dl=0 dr=1337871 di=1337871
|
||||
1=50989 e1=6138 i1=49722 ie1=82 g1=49640 a1=315203 ae1=265563 a2=49640
|
||||
z1=1401244 ze1=1351605 z2=49639 m1=5661253 me1=5611614 m2=49639
|
||||
|
||||
These are counters tracking internal preemptable-RCU events, however,
|
||||
some of them may be useful for debugging algorithms using RCU. In
|
||||
particular, the "nl", "wl", and "dl" values track the number of RCU
|
||||
callbacks in various states. The fields are as follows:
|
||||
|
||||
o "na" is the total number of RCU callbacks that have been enqueued
|
||||
since boot.
|
||||
|
||||
o "nl" is the number of RCU callbacks waiting for the previous
|
||||
grace period to end so that they can start waiting on the next
|
||||
grace period.
|
||||
|
||||
o "wa" is the total number of RCU callbacks that have started waiting
|
||||
for a grace period since boot. "na" should be roughly equal to
|
||||
"nl" plus "wa".
|
||||
|
||||
o "wl" is the number of RCU callbacks currently waiting for their
|
||||
grace period to end.
|
||||
|
||||
o "da" is the total number of RCU callbacks whose grace periods
|
||||
have completed since boot. "wa" should be roughly equal to
|
||||
"wl" plus "da".
|
||||
|
||||
o "dr" is the total number of RCU callbacks that have been removed
|
||||
from the list of callbacks ready to invoke. "dr" should be roughly
|
||||
equal to "da".
|
||||
|
||||
o "di" is the total number of RCU callbacks that have been invoked
|
||||
since boot. "di" should be roughly equal to "da", though some
|
||||
early versions of preemptable RCU had a bug so that only the
|
||||
last CPU's count of invocations was displayed, rather than the
|
||||
sum of all CPU's counts.
|
||||
|
||||
o "1" is the number of calls to rcu_try_flip(). This should be
|
||||
roughly equal to the sum of "e1", "i1", "a1", "z1", and "m1"
|
||||
described below. In other words, the number of times that
|
||||
the state machine is visited should be equal to the sum of the
|
||||
number of times that each state is visited plus the number of
|
||||
times that the state-machine lock acquisition failed.
|
||||
|
||||
o "e1" is the number of times that rcu_try_flip() was unable to
|
||||
acquire the fliplock.
|
||||
|
||||
o "i1" is the number of calls to rcu_try_flip_idle().
|
||||
|
||||
o "ie1" is the number of times rcu_try_flip_idle() exited early
|
||||
due to the calling CPU having no work for RCU.
|
||||
|
||||
o "g1" is the number of times that rcu_try_flip_idle() decided
|
||||
to start a new grace period. "i1" should be roughly equal to
|
||||
"ie1" plus "g1".
|
||||
|
||||
o "a1" is the number of calls to rcu_try_flip_waitack().
|
||||
|
||||
o "ae1" is the number of times that rcu_try_flip_waitack() found
|
||||
that at least one CPU had not yet acknowledge the new grace period
|
||||
(AKA "counter flip").
|
||||
|
||||
o "a2" is the number of time rcu_try_flip_waitack() found that
|
||||
all CPUs had acknowledged. "a1" should be roughly equal to
|
||||
"ae1" plus "a2". (This particular output was collected on
|
||||
a 128-CPU machine, hence the smaller-than-usual fraction of
|
||||
calls to rcu_try_flip_waitack() finding all CPUs having already
|
||||
acknowledged.)
|
||||
|
||||
o "z1" is the number of calls to rcu_try_flip_waitzero().
|
||||
|
||||
o "ze1" is the number of times that rcu_try_flip_waitzero() found
|
||||
that not all of the old RCU read-side critical sections had
|
||||
completed.
|
||||
|
||||
o "z2" is the number of times that rcu_try_flip_waitzero() finds
|
||||
the sum of the counters equal to zero, in other words, that
|
||||
all of the old RCU read-side critical sections had completed.
|
||||
The value of "z1" should be roughly equal to "ze1" plus
|
||||
"z2".
|
||||
|
||||
o "m1" is the number of calls to rcu_try_flip_waitmb().
|
||||
|
||||
o "me1" is the number of times that rcu_try_flip_waitmb() finds
|
||||
that at least one CPU has not yet executed a memory barrier.
|
||||
|
||||
o "m2" is the number of times that rcu_try_flip_waitmb() finds that
|
||||
all CPUs have executed a memory barrier.
|
||||
|
||||
|
||||
Hierarchical RCU debugfs Files and Formats
|
||||
|
||||
This implementation of RCU provides three debugfs files under the
|
||||
top-level directory RCU: rcu/rcudata (which displays fields in struct
|
||||
rcu_data), rcu/rcugp (which displays grace-period counters), and
|
||||
rcu/rcuhier (which displays the struct rcu_node hierarchy).
|
||||
|
||||
The output of "cat rcu/rcudata" looks as follows:
|
||||
|
||||
rcu:
|
||||
0 c=4011 g=4012 pq=1 pqc=4011 qp=0 rpfq=1 rp=3c2a dt=23301/73 dn=2 df=1882 of=0 ri=2126 ql=2 b=10
|
||||
1 c=4011 g=4012 pq=1 pqc=4011 qp=0 rpfq=3 rp=39a6 dt=78073/1 dn=2 df=1402 of=0 ri=1875 ql=46 b=10
|
||||
2 c=4010 g=4010 pq=1 pqc=4010 qp=0 rpfq=-5 rp=1d12 dt=16646/0 dn=2 df=3140 of=0 ri=2080 ql=0 b=10
|
||||
3 c=4012 g=4013 pq=1 pqc=4012 qp=1 rpfq=3 rp=2b50 dt=21159/1 dn=2 df=2230 of=0 ri=1923 ql=72 b=10
|
||||
4 c=4012 g=4013 pq=1 pqc=4012 qp=1 rpfq=3 rp=1644 dt=5783/1 dn=2 df=3348 of=0 ri=2805 ql=7 b=10
|
||||
5 c=4012 g=4013 pq=0 pqc=4011 qp=1 rpfq=3 rp=1aac dt=5879/1 dn=2 df=3140 of=0 ri=2066 ql=10 b=10
|
||||
6 c=4012 g=4013 pq=1 pqc=4012 qp=1 rpfq=3 rp=ed8 dt=5847/1 dn=2 df=3797 of=0 ri=1266 ql=10 b=10
|
||||
7 c=4012 g=4013 pq=1 pqc=4012 qp=1 rpfq=3 rp=1fa2 dt=6199/1 dn=2 df=2795 of=0 ri=2162 ql=28 b=10
|
||||
rcu_bh:
|
||||
0 c=-268 g=-268 pq=1 pqc=-268 qp=0 rpfq=-145 rp=21d6 dt=23301/73 dn=2 df=0 of=0 ri=0 ql=0 b=10
|
||||
1 c=-268 g=-268 pq=1 pqc=-268 qp=1 rpfq=-170 rp=20ce dt=78073/1 dn=2 df=26 of=0 ri=5 ql=0 b=10
|
||||
2 c=-268 g=-268 pq=1 pqc=-268 qp=1 rpfq=-83 rp=fbd dt=16646/0 dn=2 df=28 of=0 ri=4 ql=0 b=10
|
||||
3 c=-268 g=-268 pq=1 pqc=-268 qp=0 rpfq=-105 rp=178c dt=21159/1 dn=2 df=28 of=0 ri=2 ql=0 b=10
|
||||
4 c=-268 g=-268 pq=1 pqc=-268 qp=1 rpfq=-30 rp=b54 dt=5783/1 dn=2 df=32 of=0 ri=0 ql=0 b=10
|
||||
5 c=-268 g=-268 pq=1 pqc=-268 qp=1 rpfq=-29 rp=df5 dt=5879/1 dn=2 df=30 of=0 ri=3 ql=0 b=10
|
||||
6 c=-268 g=-268 pq=1 pqc=-268 qp=1 rpfq=-28 rp=788 dt=5847/1 dn=2 df=32 of=0 ri=0 ql=0 b=10
|
||||
7 c=-268 g=-268 pq=1 pqc=-268 qp=1 rpfq=-53 rp=1098 dt=6199/1 dn=2 df=30 of=0 ri=3 ql=0 b=10
|
||||
|
||||
The first section lists the rcu_data structures for rcu, the second for
|
||||
rcu_bh. Each section has one line per CPU, or eight for this 8-CPU system.
|
||||
The fields are as follows:
|
||||
|
||||
o The number at the beginning of each line is the CPU number.
|
||||
CPUs numbers followed by an exclamation mark are offline,
|
||||
but have been online at least once since boot. There will be
|
||||
no output for CPUs that have never been online, which can be
|
||||
a good thing in the surprisingly common case where NR_CPUS is
|
||||
substantially larger than the number of actual CPUs.
|
||||
|
||||
o "c" is the count of grace periods that this CPU believes have
|
||||
completed. CPUs in dynticks idle mode may lag quite a ways
|
||||
behind, for example, CPU 4 under "rcu" above, which has slept
|
||||
through the past 25 RCU grace periods. It is not unusual to
|
||||
see CPUs lagging by thousands of grace periods.
|
||||
|
||||
o "g" is the count of grace periods that this CPU believes have
|
||||
started. Again, CPUs in dynticks idle mode may lag behind.
|
||||
If the "c" and "g" values are equal, this CPU has already
|
||||
reported a quiescent state for the last RCU grace period that
|
||||
it is aware of, otherwise, the CPU believes that it owes RCU a
|
||||
quiescent state.
|
||||
|
||||
o "pq" indicates that this CPU has passed through a quiescent state
|
||||
for the current grace period. It is possible for "pq" to be
|
||||
"1" and "c" different than "g", which indicates that although
|
||||
the CPU has passed through a quiescent state, either (1) this
|
||||
CPU has not yet reported that fact, (2) some other CPU has not
|
||||
yet reported for this grace period, or (3) both.
|
||||
|
||||
o "pqc" indicates which grace period the last-observed quiescent
|
||||
state for this CPU corresponds to. This is important for handling
|
||||
the race between CPU 0 reporting an extended dynticks-idle
|
||||
quiescent state for CPU 1 and CPU 1 suddenly waking up and
|
||||
reporting its own quiescent state. If CPU 1 was the last CPU
|
||||
for the current grace period, then the CPU that loses this race
|
||||
will attempt to incorrectly mark CPU 1 as having checked in for
|
||||
the next grace period!
|
||||
|
||||
o "qp" indicates that RCU still expects a quiescent state from
|
||||
this CPU.
|
||||
|
||||
o "rpfq" is the number of rcu_pending() calls on this CPU required
|
||||
to induce this CPU to invoke force_quiescent_state().
|
||||
|
||||
o "rp" is low-order four hex digits of the count of how many times
|
||||
rcu_pending() has been invoked on this CPU.
|
||||
|
||||
o "dt" is the current value of the dyntick counter that is incremented
|
||||
when entering or leaving dynticks idle state, either by the
|
||||
scheduler or by irq. The number after the "/" is the interrupt
|
||||
nesting depth when in dyntick-idle state, or one greater than
|
||||
the interrupt-nesting depth otherwise.
|
||||
|
||||
This field is displayed only for CONFIG_NO_HZ kernels.
|
||||
|
||||
o "dn" is the current value of the dyntick counter that is incremented
|
||||
when entering or leaving dynticks idle state via NMI. If both
|
||||
the "dt" and "dn" values are even, then this CPU is in dynticks
|
||||
idle mode and may be ignored by RCU. If either of these two
|
||||
counters is odd, then RCU must be alert to the possibility of
|
||||
an RCU read-side critical section running on this CPU.
|
||||
|
||||
This field is displayed only for CONFIG_NO_HZ kernels.
|
||||
|
||||
o "df" is the number of times that some other CPU has forced a
|
||||
quiescent state on behalf of this CPU due to this CPU being in
|
||||
dynticks-idle state.
|
||||
|
||||
This field is displayed only for CONFIG_NO_HZ kernels.
|
||||
|
||||
o "of" is the number of times that some other CPU has forced a
|
||||
quiescent state on behalf of this CPU due to this CPU being
|
||||
offline. In a perfect world, this might neve happen, but it
|
||||
turns out that offlining and onlining a CPU can take several grace
|
||||
periods, and so there is likely to be an extended period of time
|
||||
when RCU believes that the CPU is online when it really is not.
|
||||
Please note that erring in the other direction (RCU believing a
|
||||
CPU is offline when it is really alive and kicking) is a fatal
|
||||
error, so it makes sense to err conservatively.
|
||||
|
||||
o "ri" is the number of times that RCU has seen fit to send a
|
||||
reschedule IPI to this CPU in order to get it to report a
|
||||
quiescent state.
|
||||
|
||||
o "ql" is the number of RCU callbacks currently residing on
|
||||
this CPU. This is the total number of callbacks, regardless
|
||||
of what state they are in (new, waiting for grace period to
|
||||
start, waiting for grace period to end, ready to invoke).
|
||||
|
||||
o "b" is the batch limit for this CPU. If more than this number
|
||||
of RCU callbacks is ready to invoke, then the remainder will
|
||||
be deferred.
|
||||
|
||||
|
||||
The output of "cat rcu/rcugp" looks as follows:
|
||||
|
||||
rcu: completed=33062 gpnum=33063
|
||||
rcu_bh: completed=464 gpnum=464
|
||||
|
||||
Again, this output is for both "rcu" and "rcu_bh". The fields are
|
||||
taken from the rcu_state structure, and are as follows:
|
||||
|
||||
o "completed" is the number of grace periods that have completed.
|
||||
It is comparable to the "c" field from rcu/rcudata in that a
|
||||
CPU whose "c" field matches the value of "completed" is aware
|
||||
that the corresponding RCU grace period has completed.
|
||||
|
||||
o "gpnum" is the number of grace periods that have started. It is
|
||||
comparable to the "g" field from rcu/rcudata in that a CPU
|
||||
whose "g" field matches the value of "gpnum" is aware that the
|
||||
corresponding RCU grace period has started.
|
||||
|
||||
If these two fields are equal (as they are for "rcu_bh" above),
|
||||
then there is no grace period in progress, in other words, RCU
|
||||
is idle. On the other hand, if the two fields differ (as they
|
||||
do for "rcu" above), then an RCU grace period is in progress.
|
||||
|
||||
|
||||
The output of "cat rcu/rcuhier" looks as follows, with very long lines:
|
||||
|
||||
c=6902 g=6903 s=2 jfq=3 j=72c7 nfqs=13142/nfqsng=0(13142) fqlh=6
|
||||
1/1 0:127 ^0
|
||||
3/3 0:35 ^0 0/0 36:71 ^1 0/0 72:107 ^2 0/0 108:127 ^3
|
||||
3/3f 0:5 ^0 2/3 6:11 ^1 0/0 12:17 ^2 0/0 18:23 ^3 0/0 24:29 ^4 0/0 30:35 ^5 0/0 36:41 ^0 0/0 42:47 ^1 0/0 48:53 ^2 0/0 54:59 ^3 0/0 60:65 ^4 0/0 66:71 ^5 0/0 72:77 ^0 0/0 78:83 ^1 0/0 84:89 ^2 0/0 90:95 ^3 0/0 96:101 ^4 0/0 102:107 ^5 0/0 108:113 ^0 0/0 114:119 ^1 0/0 120:125 ^2 0/0 126:127 ^3
|
||||
rcu_bh:
|
||||
c=-226 g=-226 s=1 jfq=-5701 j=72c7 nfqs=88/nfqsng=0(88) fqlh=0
|
||||
0/1 0:127 ^0
|
||||
0/3 0:35 ^0 0/0 36:71 ^1 0/0 72:107 ^2 0/0 108:127 ^3
|
||||
0/3f 0:5 ^0 0/3 6:11 ^1 0/0 12:17 ^2 0/0 18:23 ^3 0/0 24:29 ^4 0/0 30:35 ^5 0/0 36:41 ^0 0/0 42:47 ^1 0/0 48:53 ^2 0/0 54:59 ^3 0/0 60:65 ^4 0/0 66:71 ^5 0/0 72:77 ^0 0/0 78:83 ^1 0/0 84:89 ^2 0/0 90:95 ^3 0/0 96:101 ^4 0/0 102:107 ^5 0/0 108:113 ^0 0/0 114:119 ^1 0/0 120:125 ^2 0/0 126:127 ^3
|
||||
|
||||
This is once again split into "rcu" and "rcu_bh" portions. The fields are
|
||||
as follows:
|
||||
|
||||
o "c" is exactly the same as "completed" under rcu/rcugp.
|
||||
|
||||
o "g" is exactly the same as "gpnum" under rcu/rcugp.
|
||||
|
||||
o "s" is the "signaled" state that drives force_quiescent_state()'s
|
||||
state machine.
|
||||
|
||||
o "jfq" is the number of jiffies remaining for this grace period
|
||||
before force_quiescent_state() is invoked to help push things
|
||||
along. Note that CPUs in dyntick-idle mode thoughout the grace
|
||||
period will not report on their own, but rather must be check by
|
||||
some other CPU via force_quiescent_state().
|
||||
|
||||
o "j" is the low-order four hex digits of the jiffies counter.
|
||||
Yes, Paul did run into a number of problems that turned out to
|
||||
be due to the jiffies counter no longer counting. Why do you ask?
|
||||
|
||||
o "nfqs" is the number of calls to force_quiescent_state() since
|
||||
boot.
|
||||
|
||||
o "nfqsng" is the number of useless calls to force_quiescent_state(),
|
||||
where there wasn't actually a grace period active. This can
|
||||
happen due to races. The number in parentheses is the difference
|
||||
between "nfqs" and "nfqsng", or the number of times that
|
||||
force_quiescent_state() actually did some real work.
|
||||
|
||||
o "fqlh" is the number of calls to force_quiescent_state() that
|
||||
exited immediately (without even being counted in nfqs above)
|
||||
due to contention on ->fqslock.
|
||||
|
||||
o Each element of the form "1/1 0:127 ^0" represents one struct
|
||||
rcu_node. Each line represents one level of the hierarchy, from
|
||||
root to leaves. It is best to think of the rcu_data structures
|
||||
as forming yet another level after the leaves. Note that there
|
||||
might be either one, two, or three levels of rcu_node structures,
|
||||
depending on the relationship between CONFIG_RCU_FANOUT and
|
||||
CONFIG_NR_CPUS.
|
||||
|
||||
o The numbers separated by the "/" are the qsmask followed
|
||||
by the qsmaskinit. The qsmask will have one bit
|
||||
set for each entity in the next lower level that
|
||||
has not yet checked in for the current grace period.
|
||||
The qsmaskinit will have one bit for each entity that is
|
||||
currently expected to check in during each grace period.
|
||||
The value of qsmaskinit is assigned to that of qsmask
|
||||
at the beginning of each grace period.
|
||||
|
||||
For example, for "rcu", the qsmask of the first entry
|
||||
of the lowest level is 0x14, meaning that we are still
|
||||
waiting for CPUs 2 and 4 to check in for the current
|
||||
grace period.
|
||||
|
||||
o The numbers separated by the ":" are the range of CPUs
|
||||
served by this struct rcu_node. This can be helpful
|
||||
in working out how the hierarchy is wired together.
|
||||
|
||||
For example, the first entry at the lowest level shows
|
||||
"0:5", indicating that it covers CPUs 0 through 5.
|
||||
|
||||
o The number after the "^" indicates the bit in the
|
||||
next higher level rcu_node structure that this
|
||||
rcu_node structure corresponds to.
|
||||
|
||||
For example, the first entry at the lowest level shows
|
||||
"^0", indicating that it corresponds to bit zero in
|
||||
the first entry at the middle level.
|
||||
@@ -24,7 +24,7 @@ real bad - it changes the behaviour of all unaligned instructions in user
|
||||
space, and might cause programs to fail unexpectedly.
|
||||
|
||||
To change the alignment trap behavior, simply echo a number into
|
||||
/proc/sys/debug/alignment. The number is made up from various bits:
|
||||
/proc/cpu/alignment. The number is made up from various bits:
|
||||
|
||||
bit behavior when set
|
||||
--- -----------------
|
||||
|
||||
@@ -0,0 +1,286 @@
|
||||
MFP Configuration for PXA2xx/PXA3xx Processors
|
||||
|
||||
Eric Miao <eric.miao@marvell.com>
|
||||
|
||||
MFP stands for Multi-Function Pin, which is the pin-mux logic on PXA3xx and
|
||||
later PXA series processors. This document describes the existing MFP API,
|
||||
and how board/platform driver authors could make use of it.
|
||||
|
||||
Basic Concept
|
||||
===============
|
||||
|
||||
Unlike the GPIO alternate function settings on PXA25x and PXA27x, a new MFP
|
||||
mechanism is introduced from PXA3xx to completely move the pin-mux functions
|
||||
out of the GPIO controller. In addition to pin-mux configurations, the MFP
|
||||
also controls the low power state, driving strength, pull-up/down and event
|
||||
detection of each pin. Below is a diagram of internal connections between
|
||||
the MFP logic and the remaining SoC peripherals:
|
||||
|
||||
+--------+
|
||||
| |--(GPIO19)--+
|
||||
| GPIO | |
|
||||
| |--(GPIO...) |
|
||||
+--------+ |
|
||||
| +---------+
|
||||
+--------+ +------>| |
|
||||
| PWM2 |--(PWM_OUT)-------->| MFP |
|
||||
+--------+ +------>| |-------> to external PAD
|
||||
| +---->| |
|
||||
+--------+ | | +-->| |
|
||||
| SSP2 |---(TXD)----+ | | +---------+
|
||||
+--------+ | |
|
||||
| |
|
||||
+--------+ | |
|
||||
| Keypad |--(MKOUT4)----+ |
|
||||
+--------+ |
|
||||
|
|
||||
+--------+ |
|
||||
| UART2 |---(TXD)--------+
|
||||
+--------+
|
||||
|
||||
NOTE: the external pad is named as MFP_PIN_GPIO19, it doesn't necessarily
|
||||
mean it's dedicated for GPIO19, only as a hint that internally this pin
|
||||
can be routed from GPIO19 of the GPIO controller.
|
||||
|
||||
To better understand the change from PXA25x/PXA27x GPIO alternate function
|
||||
to this new MFP mechanism, here are several key points:
|
||||
|
||||
1. GPIO controller on PXA3xx is now a dedicated controller, same as other
|
||||
internal controllers like PWM, SSP and UART, with 128 internal signals
|
||||
which can be routed to external through one or more MFPs (e.g. GPIO<0>
|
||||
can be routed through either MFP_PIN_GPIO0 as well as MFP_PIN_GPIO0_2,
|
||||
see arch/arm/mach-pxa/mach/include/mfp-pxa300.h)
|
||||
|
||||
2. Alternate function configuration is removed from this GPIO controller,
|
||||
the remaining functions are pure GPIO-specific, i.e.
|
||||
|
||||
- GPIO signal level control
|
||||
- GPIO direction control
|
||||
- GPIO level change detection
|
||||
|
||||
3. Low power state for each pin is now controlled by MFP, this means the
|
||||
PGSRx registers on PXA2xx are now useless on PXA3xx
|
||||
|
||||
4. Wakeup detection is now controlled by MFP, PWER does not control the
|
||||
wakeup from GPIO(s) any more, depending on the sleeping state, ADxER
|
||||
(as defined in pxa3xx-regs.h) controls the wakeup from MFP
|
||||
|
||||
NOTE: with such a clear separation of MFP and GPIO, by GPIO<xx> we normally
|
||||
mean it is a GPIO signal, and by MFP<xxx> or pin xxx, we mean a physical
|
||||
pad (or ball).
|
||||
|
||||
MFP API Usage
|
||||
===============
|
||||
|
||||
For board code writers, here are some guidelines:
|
||||
|
||||
1. include ONE of the following header files in your <board>.c:
|
||||
|
||||
- #include <mach/mfp-pxa25x.h>
|
||||
- #include <mach/mfp-pxa27x.h>
|
||||
- #include <mach/mfp-pxa300.h>
|
||||
- #include <mach/mfp-pxa320.h>
|
||||
- #include <mach/mfp-pxa930.h>
|
||||
|
||||
NOTE: only one file in your <board>.c, depending on the processors used,
|
||||
because pin configuration definitions may conflict in these file (i.e.
|
||||
same name, different meaning and settings on different processors). E.g.
|
||||
for zylonite platform, which support both PXA300/PXA310 and PXA320, two
|
||||
separate files are introduced: zylonite_pxa300.c and zylonite_pxa320.c
|
||||
(in addition to handle MFP configuration differences, they also handle
|
||||
the other differences between the two combinations).
|
||||
|
||||
NOTE: PXA300 and PXA310 are almost identical in pin configurations (with
|
||||
PXA310 supporting some additional ones), thus the difference is actually
|
||||
covered in a single mfp-pxa300.h.
|
||||
|
||||
2. prepare an array for the initial pin configurations, e.g.:
|
||||
|
||||
static unsigned long mainstone_pin_config[] __initdata = {
|
||||
/* Chip Select */
|
||||
GPIO15_nCS_1,
|
||||
|
||||
/* LCD - 16bpp Active TFT */
|
||||
GPIOxx_TFT_LCD_16BPP,
|
||||
GPIO16_PWM0_OUT, /* Backlight */
|
||||
|
||||
/* MMC */
|
||||
GPIO32_MMC_CLK,
|
||||
GPIO112_MMC_CMD,
|
||||
GPIO92_MMC_DAT_0,
|
||||
GPIO109_MMC_DAT_1,
|
||||
GPIO110_MMC_DAT_2,
|
||||
GPIO111_MMC_DAT_3,
|
||||
|
||||
...
|
||||
|
||||
/* GPIO */
|
||||
GPIO1_GPIO | WAKEUP_ON_EDGE_BOTH,
|
||||
};
|
||||
|
||||
a) once the pin configurations are passed to pxa{2xx,3xx}_mfp_config(),
|
||||
and written to the actual registers, they are useless and may discard,
|
||||
adding '__initdata' will help save some additional bytes here.
|
||||
|
||||
b) when there is only one possible pin configurations for a component,
|
||||
some simplified definitions can be used, e.g. GPIOxx_TFT_LCD_16BPP on
|
||||
PXA25x and PXA27x processors
|
||||
|
||||
c) if by board design, a pin can be configured to wake up the system
|
||||
from low power state, it can be 'OR'ed with any of:
|
||||
|
||||
WAKEUP_ON_EDGE_BOTH
|
||||
WAKEUP_ON_EDGE_RISE
|
||||
WAKEUP_ON_EDGE_FALL
|
||||
WAKEUP_ON_LEVEL_HIGH - specifically for enabling of keypad GPIOs,
|
||||
|
||||
to indicate that this pin has the capability of wake-up the system,
|
||||
and on which edge(s). This, however, doesn't necessarily mean the
|
||||
pin _will_ wakeup the system, it will only when set_irq_wake() is
|
||||
invoked with the corresponding GPIO IRQ (GPIO_IRQ(xx) or gpio_to_irq())
|
||||
and eventually calls gpio_set_wake() for the actual register setting.
|
||||
|
||||
d) although PXA3xx MFP supports edge detection on each pin, the
|
||||
internal logic will only wakeup the system when those specific bits
|
||||
in ADxER registers are set, which can be well mapped to the
|
||||
corresponding peripheral, thus set_irq_wake() can be called with
|
||||
the peripheral IRQ to enable the wakeup.
|
||||
|
||||
|
||||
MFP on PXA3xx
|
||||
===============
|
||||
|
||||
Every external I/O pad on PXA3xx (excluding those for special purpose) has
|
||||
one MFP logic associated, and is controlled by one MFP register (MFPR).
|
||||
|
||||
The MFPR has the following bit definitions (for PXA300/PXA310/PXA320):
|
||||
|
||||
31 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
|
||||
+-------------------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|
||||
| RESERVED |PS|PU|PD| DRIVE |SS|SD|SO|EC|EF|ER|--| AF_SEL |
|
||||
+-------------------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|
||||
|
||||
Bit 3: RESERVED
|
||||
Bit 4: EDGE_RISE_EN - enable detection of rising edge on this pin
|
||||
Bit 5: EDGE_FALL_EN - enable detection of falling edge on this pin
|
||||
Bit 6: EDGE_CLEAR - disable edge detection on this pin
|
||||
Bit 7: SLEEP_OE_N - enable outputs during low power modes
|
||||
Bit 8: SLEEP_DATA - output data on the pin during low power modes
|
||||
Bit 9: SLEEP_SEL - selection control for low power modes signals
|
||||
Bit 13: PULLDOWN_EN - enable the internal pull-down resistor on this pin
|
||||
Bit 14: PULLUP_EN - enable the internal pull-up resistor on this pin
|
||||
Bit 15: PULL_SEL - pull state controlled by selected alternate function
|
||||
(0) or by PULL{UP,DOWN}_EN bits (1)
|
||||
|
||||
Bit 0 - 2: AF_SEL - alternate function selection, 8 possibilities, from 0-7
|
||||
Bit 10-12: DRIVE - drive strength and slew rate
|
||||
0b000 - fast 1mA
|
||||
0b001 - fast 2mA
|
||||
0b002 - fast 3mA
|
||||
0b003 - fast 4mA
|
||||
0b004 - slow 6mA
|
||||
0b005 - fast 6mA
|
||||
0b006 - slow 10mA
|
||||
0b007 - fast 10mA
|
||||
|
||||
MFP Design for PXA2xx/PXA3xx
|
||||
==============================
|
||||
|
||||
Due to the difference of pin-mux handling between PXA2xx and PXA3xx, a unified
|
||||
MFP API is introduced to cover both series of processors.
|
||||
|
||||
The basic idea of this design is to introduce definitions for all possible pin
|
||||
configurations, these definitions are processor and platform independent, and
|
||||
the actual API invoked to convert these definitions into register settings and
|
||||
make them effective there-after.
|
||||
|
||||
Files Involved
|
||||
--------------
|
||||
|
||||
- arch/arm/mach-pxa/include/mach/mfp.h
|
||||
|
||||
for
|
||||
1. Unified pin definitions - enum constants for all configurable pins
|
||||
2. processor-neutral bit definitions for a possible MFP configuration
|
||||
|
||||
- arch/arm/mach-pxa/include/mach/mfp-pxa3xx.h
|
||||
|
||||
for PXA3xx specific MFPR register bit definitions and PXA3xx common pin
|
||||
configurations
|
||||
|
||||
- arch/arm/mach-pxa/include/mach/mfp-pxa2xx.h
|
||||
|
||||
for PXA2xx specific definitions and PXA25x/PXA27x common pin configurations
|
||||
|
||||
- arch/arm/mach-pxa/include/mach/mfp-pxa25x.h
|
||||
arch/arm/mach-pxa/include/mach/mfp-pxa27x.h
|
||||
arch/arm/mach-pxa/include/mach/mfp-pxa300.h
|
||||
arch/arm/mach-pxa/include/mach/mfp-pxa320.h
|
||||
arch/arm/mach-pxa/include/mach/mfp-pxa930.h
|
||||
|
||||
for processor specific definitions
|
||||
|
||||
- arch/arm/mach-pxa/mfp-pxa3xx.c
|
||||
- arch/arm/mach-pxa/mfp-pxa2xx.c
|
||||
|
||||
for implementation of the pin configuration to take effect for the actual
|
||||
processor.
|
||||
|
||||
Pin Configuration
|
||||
-----------------
|
||||
|
||||
The following comments are copied from mfp.h (see the actual source code
|
||||
for most updated info)
|
||||
|
||||
/*
|
||||
* a possible MFP configuration is represented by a 32-bit integer
|
||||
*
|
||||
* bit 0.. 9 - MFP Pin Number (1024 Pins Maximum)
|
||||
* bit 10..12 - Alternate Function Selection
|
||||
* bit 13..15 - Drive Strength
|
||||
* bit 16..18 - Low Power Mode State
|
||||
* bit 19..20 - Low Power Mode Edge Detection
|
||||
* bit 21..22 - Run Mode Pull State
|
||||
*
|
||||
* to facilitate the definition, the following macros are provided
|
||||
*
|
||||
* MFP_CFG_DEFAULT - default MFP configuration value, with
|
||||
* alternate function = 0,
|
||||
* drive strength = fast 3mA (MFP_DS03X)
|
||||
* low power mode = default
|
||||
* edge detection = none
|
||||
*
|
||||
* MFP_CFG - default MFPR value with alternate function
|
||||
* MFP_CFG_DRV - default MFPR value with alternate function and
|
||||
* pin drive strength
|
||||
* MFP_CFG_LPM - default MFPR value with alternate function and
|
||||
* low power mode
|
||||
* MFP_CFG_X - default MFPR value with alternate function,
|
||||
* pin drive strength and low power mode
|
||||
*/
|
||||
|
||||
Examples of pin configurations are:
|
||||
|
||||
#define GPIO94_SSP3_RXD MFP_CFG_X(GPIO94, AF1, DS08X, FLOAT)
|
||||
|
||||
which reads GPIO94 can be configured as SSP3_RXD, with alternate function
|
||||
selection of 1, driving strength of 0b101, and a float state in low power
|
||||
modes.
|
||||
|
||||
NOTE: this is the default setting of this pin being configured as SSP3_RXD
|
||||
which can be modified a bit in board code, though it is not recommended to
|
||||
do so, simply because this default setting is usually carefully encoded,
|
||||
and is supposed to work in most cases.
|
||||
|
||||
Register Settings
|
||||
-----------------
|
||||
|
||||
Register settings on PXA3xx for a pin configuration is actually very
|
||||
straight-forward, most bits can be converted directly into MFPR value
|
||||
in a easier way. Two sets of MFPR values are calculated: the run-time
|
||||
ones and the low power mode ones, to allow different settings.
|
||||
|
||||
The conversion from a generic pin configuration to the actual register
|
||||
settings on PXA2xx is a bit complicated: many registers are involved,
|
||||
including GAFRx, GPDRx, PGSRx, PWER, PKWR, PFER and PRER. Please see
|
||||
mfp-pxa2xx.c for how the conversion is made.
|
||||
@@ -914,7 +914,7 @@ I/O scheduler, a.k.a. elevator, is implemented in two layers. Generic dispatch
|
||||
queue and specific I/O schedulers. Unless stated otherwise, elevator is used
|
||||
to refer to both parts and I/O scheduler to specific I/O schedulers.
|
||||
|
||||
Block layer implements generic dispatch queue in ll_rw_blk.c and elevator.c.
|
||||
Block layer implements generic dispatch queue in block/*.c.
|
||||
The generic dispatch queue is responsible for properly ordering barrier
|
||||
requests, requeueing, handling non-fs requests and all other subtleties.
|
||||
|
||||
@@ -926,8 +926,8 @@ be built inside the kernel. Each queue can choose different one and can also
|
||||
change to another one dynamically.
|
||||
|
||||
A block layer call to the i/o scheduler follows the convention elv_xxx(). This
|
||||
calls elevator_xxx_fn in the elevator switch (drivers/block/elevator.c). Oh,
|
||||
xxx and xxx might not match exactly, but use your imagination. If an elevator
|
||||
calls elevator_xxx_fn in the elevator switch (block/elevator.c). Oh, xxx
|
||||
and xxx might not match exactly, but use your imagination. If an elevator
|
||||
doesn't implement a function, the switch does nothing or some minimal house
|
||||
keeping work.
|
||||
|
||||
|
||||
@@ -0,0 +1,32 @@
|
||||
CPU Accounting Controller
|
||||
-------------------------
|
||||
|
||||
The CPU accounting controller is used to group tasks using cgroups and
|
||||
account the CPU usage of these groups of tasks.
|
||||
|
||||
The CPU accounting controller supports multi-hierarchy groups. An accounting
|
||||
group accumulates the CPU usage of all of its child groups and the tasks
|
||||
directly present in its group.
|
||||
|
||||
Accounting groups can be created by first mounting the cgroup filesystem.
|
||||
|
||||
# mkdir /cgroups
|
||||
# mount -t cgroup -ocpuacct none /cgroups
|
||||
|
||||
With the above step, the initial or the parent accounting group
|
||||
becomes visible at /cgroups. At bootup, this group includes all the
|
||||
tasks in the system. /cgroups/tasks lists the tasks in this cgroup.
|
||||
/cgroups/cpuacct.usage gives the CPU time (in nanoseconds) obtained by
|
||||
this group which is essentially the CPU time obtained by all the tasks
|
||||
in the system.
|
||||
|
||||
New accounting groups can be created under the parent group /cgroups.
|
||||
|
||||
# cd /cgroups
|
||||
# mkdir g1
|
||||
# echo $$ > g1
|
||||
|
||||
The above steps create a new group g1 and move the current shell
|
||||
process (bash) into it. CPU time consumed by this bash and its children
|
||||
can be obtained from g1/cpuacct.usage and the same is accumulated in
|
||||
/cgroups/cpuacct.usage also.
|
||||
@@ -23,6 +23,7 @@ Contents:
|
||||
1.3 sparc64
|
||||
1.4 ppc
|
||||
1.5 SuperH
|
||||
1.6 Blackfin
|
||||
|
||||
2. "Policy" / "Governor"?
|
||||
2.1 Policy
|
||||
@@ -92,10 +93,19 @@ Several "PowerBook" and "iBook2" notebooks are supported.
|
||||
1.5 SuperH
|
||||
----------
|
||||
|
||||
The following SuperH processors are supported by cpufreq:
|
||||
All SuperH processors supporting rate rounding through the clock
|
||||
framework are supported by cpufreq.
|
||||
|
||||
SH-3
|
||||
SH-4
|
||||
1.6 Blackfin
|
||||
------------
|
||||
|
||||
The following Blackfin processors are supported by cpufreq:
|
||||
|
||||
BF522, BF523, BF524, BF525, BF526, BF527, Rev 0.1 or higher
|
||||
BF531, BF532, BF533, Rev 0.3 or higher
|
||||
BF534, BF536, BF537, Rev 0.2 or higher
|
||||
BF561, Rev 0.3 or higher
|
||||
BF542, BF544, BF547, BF548, BF549, Rev 0.1 or higher
|
||||
|
||||
|
||||
2. "Policy" / "Governor" ?
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
@@ -0,0 +1,69 @@
|
||||
How to set up the Technisat devices
|
||||
===================================
|
||||
|
||||
1) Find out what device you have
|
||||
================================
|
||||
|
||||
First start your linux box with a shipped kernel:
|
||||
lspci -vvv for a PCI device (lsusb -vvv for an USB device) will show you for example:
|
||||
02:0b.0 Network controller: Techsan Electronics Co Ltd B2C2 FlexCopII DVB chip / Technisat SkyStar2 DVB card (rev 02)
|
||||
|
||||
dmesg | grep frontend may show you for example:
|
||||
DVB: registering frontend 0 (Conexant CX24123/CX24109)...
|
||||
|
||||
2) Kernel compilation:
|
||||
======================
|
||||
|
||||
If the Technisat is the only TV device in your box get rid of unnecessary modules and check this one:
|
||||
"Multimedia devices" => "Customise analog and hybrid tuner modules to build"
|
||||
In this directory uncheck every driver which is activated there.
|
||||
|
||||
Then please activate:
|
||||
2a) Main module part:
|
||||
|
||||
a.)"Multimedia devices" => "DVB/ATSC adapters" => "Technisat/B2C2 FlexcopII(b) and FlexCopIII adapters"
|
||||
b.)"Multimedia devices" => "DVB/ATSC adapters" => "Technisat/B2C2 FlexcopII(b) and FlexCopIII adapters" => "Technisat/B2C2 Air/Sky/Cable2PC PCI" in case of a PCI card OR
|
||||
c.)"Multimedia devices" => "DVB/ATSC adapters" => "Technisat/B2C2 FlexcopII(b) and FlexCopIII adapters" => "Technisat/B2C2 Air/Sky/Cable2PC USB" in case of an USB 1.1 adapter
|
||||
d.)"Multimedia devices" => "DVB/ATSC adapters" => "Technisat/B2C2 FlexcopII(b) and FlexCopIII adapters" => "Enable debug for the B2C2 FlexCop drivers"
|
||||
Notice: d.) is helpful for troubleshooting
|
||||
|
||||
2b) Frontend module part:
|
||||
|
||||
1.) Revision 2.3:
|
||||
a.)"Multimedia devices" => "Customise DVB frontends" => "Customise the frontend modules to build"
|
||||
b.)"Multimedia devices" => "Customise DVB frontends" => "Zarlink VP310/MT312/ZL10313 based"
|
||||
|
||||
2.) Revision 2.6:
|
||||
a.)"Multimedia devices" => "Customise DVB frontends" => "Customise the frontend modules to build"
|
||||
b.)"Multimedia devices" => "Customise DVB frontends" => "ST STV0299 based"
|
||||
|
||||
3.) Revision 2.7:
|
||||
a.)"Multimedia devices" => "Customise DVB frontends" => "Customise the frontend modules to build"
|
||||
b.)"Multimedia devices" => "Customise DVB frontends" => "Samsung S5H1420 based"
|
||||
c.)"Multimedia devices" => "Customise DVB frontends" => "Integrant ITD1000 Zero IF tuner for DVB-S/DSS"
|
||||
d.)"Multimedia devices" => "Customise DVB frontends" => "ISL6421 SEC controller"
|
||||
|
||||
4.) Revision 2.8:
|
||||
a.)"Multimedia devices" => "Customise DVB frontends" => "Customise the frontend modules to build"
|
||||
b.)"Multimedia devices" => "Customise DVB frontends" => "Conexant CX24113/CX24128 tuner for DVB-S/DSS"
|
||||
c.)"Multimedia devices" => "Customise DVB frontends" => "Conexant CX24123 based"
|
||||
d.)"Multimedia devices" => "Customise DVB frontends" => "ISL6421 SEC controller"
|
||||
|
||||
5.) DVB-T card:
|
||||
a.)"Multimedia devices" => "Customise DVB frontends" => "Customise the frontend modules to build"
|
||||
b.)"Multimedia devices" => "Customise DVB frontends" => "Zarlink MT352 based"
|
||||
|
||||
6.) DVB-C card:
|
||||
a.)"Multimedia devices" => "Customise DVB frontends" => "Customise the frontend modules to build"
|
||||
b.)"Multimedia devices" => "Customise DVB frontends" => "ST STV0297 based"
|
||||
|
||||
7.) ATSC card 1st generation:
|
||||
a.)"Multimedia devices" => "Customise DVB frontends" => "Customise the frontend modules to build"
|
||||
b.)"Multimedia devices" => "Customise DVB frontends" => "Broadcom BCM3510"
|
||||
|
||||
8.) ATSC card 2nd generation:
|
||||
a.)"Multimedia devices" => "Customise DVB frontends" => "Customise the frontend modules to build"
|
||||
b.)"Multimedia devices" => "Customise DVB frontends" => "NxtWave Communications NXT2002/NXT2004 based"
|
||||
c.)"Multimedia devices" => "Customise DVB frontends" => "LG Electronics LGDT3302/LGDT3303 based"
|
||||
|
||||
Author: Uwe Bugla <uwe.bugla@gmx.de> December 2008
|
||||
@@ -5,9 +5,13 @@ The driver supports the following options, either via
|
||||
options=<OPTIONS> when modular or video=pxafb:<OPTIONS> when built in.
|
||||
|
||||
For example:
|
||||
modprobe pxafb options=mode:640x480-8,passive
|
||||
modprobe pxafb options=vmem:2M,mode:640x480-8,passive
|
||||
or on the kernel command line
|
||||
video=pxafb:mode:640x480-8,passive
|
||||
video=pxafb:vmem:2M,mode:640x480-8,passive
|
||||
|
||||
vmem: VIDEO_MEM_SIZE
|
||||
Amount of video memory to allocate (can be suffixed with K or M
|
||||
for kilobytes or megabytes)
|
||||
|
||||
mode:XRESxYRES[-BPP]
|
||||
XRES == LCCR1_PPL + 1
|
||||
@@ -52,3 +56,87 @@ outputen:POLARITY
|
||||
pixclockpol:POLARITY
|
||||
pixel clock polarity
|
||||
0 => falling edge, 1 => rising edge
|
||||
|
||||
|
||||
Overlay Support for PXA27x and later LCD controllers
|
||||
====================================================
|
||||
|
||||
PXA27x and later processors support overlay1 and overlay2 on-top of the
|
||||
base framebuffer (although under-neath the base is also possible). They
|
||||
support palette and no-palette RGB formats, as well as YUV formats (only
|
||||
available on overlay2). These overlays have dedicated DMA channels and
|
||||
behave in a similar way as a framebuffer.
|
||||
|
||||
However, there are some differences between these overlay framebuffers
|
||||
and normal framebuffers, as listed below:
|
||||
|
||||
1. overlay can start at a 32-bit word aligned position within the base
|
||||
framebuffer, which means they have a start (x, y). This information
|
||||
is encoded into var->nonstd (no, var->xoffset and var->yoffset are
|
||||
not for such purpose).
|
||||
|
||||
2. overlay framebuffer is allocated dynamically according to specified
|
||||
'struct fb_var_screeninfo', the amount is decided by:
|
||||
|
||||
var->xres_virtual * var->yres_virtual * bpp
|
||||
|
||||
bpp = 16 -- for RGB565 or RGBT555
|
||||
= 24 -- for YUV444 packed
|
||||
= 24 -- for YUV444 planar
|
||||
= 16 -- for YUV422 planar (1 pixel = 1 Y + 1/2 Cb + 1/2 Cr)
|
||||
= 12 -- for YUV420 planar (1 pixel = 1 Y + 1/4 Cb + 1/4 Cr)
|
||||
|
||||
NOTE:
|
||||
|
||||
a. overlay does not support panning in x-direction, thus
|
||||
var->xres_virtual will always be equal to var->xres
|
||||
|
||||
b. line length of overlay(s) must be on a 32-bit word boundary,
|
||||
for YUV planar modes, it is a requirement for the component
|
||||
with minimum bits per pixel, e.g. for YUV420, Cr component
|
||||
for one pixel is actually 2-bits, it means the line length
|
||||
should be a multiple of 16-pixels
|
||||
|
||||
c. starting horizontal position (XPOS) should start on a 32-bit
|
||||
word boundary, otherwise the fb_check_var() will just fail.
|
||||
|
||||
d. the rectangle of the overlay should be within the base plane,
|
||||
otherwise fail
|
||||
|
||||
Applications should follow the sequence below to operate an overlay
|
||||
framebuffer:
|
||||
|
||||
a. open("/dev/fb[1-2]", ...)
|
||||
b. ioctl(fd, FBIOGET_VSCREENINFO, ...)
|
||||
c. modify 'var' with desired parameters:
|
||||
1) var->xres and var->yres
|
||||
2) larger var->yres_virtual if more memory is required,
|
||||
usually for double-buffering
|
||||
3) var->nonstd for starting (x, y) and color format
|
||||
4) var->{red, green, blue, transp} if RGB mode is to be used
|
||||
d. ioctl(fd, FBIOPUT_VSCREENINFO, ...)
|
||||
e. ioctl(fd, FBIOGET_FSCREENINFO, ...)
|
||||
f. mmap
|
||||
g. ...
|
||||
|
||||
3. for YUV planar formats, these are actually not supported within the
|
||||
framebuffer framework, application has to take care of the offsets
|
||||
and lengths of each component within the framebuffer.
|
||||
|
||||
4. var->nonstd is used to pass starting (x, y) position and color format,
|
||||
the detailed bit fields are shown below:
|
||||
|
||||
31 23 20 10 0
|
||||
+-----------------+---+----------+----------+
|
||||
| ... unused ... |FOR| XPOS | YPOS |
|
||||
+-----------------+---+----------+----------+
|
||||
|
||||
FOR - color format, as defined by OVERLAY_FORMAT_* in pxafb.h
|
||||
0 - RGB
|
||||
1 - YUV444 PACKED
|
||||
2 - YUV444 PLANAR
|
||||
3 - YUV422 PLANAR
|
||||
4 - YUR420 PLANAR
|
||||
|
||||
XPOS - starting horizontal position
|
||||
YPOS - starting vertical position
|
||||
|
||||
@@ -120,13 +120,6 @@ Who: Christoph Hellwig <hch@lst.de>
|
||||
|
||||
---------------------------
|
||||
|
||||
What: eepro100 network driver
|
||||
When: January 2007
|
||||
Why: replaced by the e100 driver
|
||||
Who: Adrian Bunk <bunk@stusta.de>
|
||||
|
||||
---------------------------
|
||||
|
||||
What: Unused EXPORT_SYMBOL/EXPORT_SYMBOL_GPL exports
|
||||
(temporary transition config option provided until then)
|
||||
The transition config option will also be removed at the same time.
|
||||
@@ -244,18 +237,6 @@ Who: Michael Buesch <mb@bu3sch.de>
|
||||
|
||||
---------------------------
|
||||
|
||||
What: init_mm export
|
||||
When: 2.6.26
|
||||
Why: Not used in-tree. The current out-of-tree users used it to
|
||||
work around problems in the CPA code which should be resolved
|
||||
by now. One usecase was described to provide verification code
|
||||
of the CPA operation. That's a good idea in general, but such
|
||||
code / infrastructure should be in the kernel and not in some
|
||||
out-of-tree driver.
|
||||
Who: Thomas Gleixner <tglx@linutronix.de>
|
||||
|
||||
----------------------------
|
||||
|
||||
What: usedac i386 kernel parameter
|
||||
When: 2.6.27
|
||||
Why: replaced by allowdac and no dac combination
|
||||
|
||||
@@ -28,10 +28,7 @@ Manish Singh <manish.singh@oracle.com>
|
||||
Caveats
|
||||
=======
|
||||
Features which OCFS2 does not support yet:
|
||||
- extended attributes
|
||||
- quotas
|
||||
- cluster aware flock
|
||||
- cluster aware lockf
|
||||
- Directory change notification (F_NOTIFY)
|
||||
- Distributed Caching (F_SETLEASE/F_GETLEASE/break_lease)
|
||||
- POSIX ACLs
|
||||
|
||||
@@ -44,6 +44,7 @@ Table of Contents
|
||||
2.14 /proc/<pid>/io - Display the IO accounting fields
|
||||
2.15 /proc/<pid>/coredump_filter - Core dump filtering settings
|
||||
2.16 /proc/<pid>/mountinfo - Information about mounts
|
||||
2.17 /proc/sys/fs/epoll - Configuration options for the epoll interface
|
||||
|
||||
------------------------------------------------------------------------------
|
||||
Preface
|
||||
@@ -1338,10 +1339,13 @@ nmi_watchdog
|
||||
|
||||
Enables/Disables the NMI watchdog on x86 systems. When the value is non-zero
|
||||
the NMI watchdog is enabled and will continuously test all online cpus to
|
||||
determine whether or not they are still functioning properly.
|
||||
determine whether or not they are still functioning properly. Currently,
|
||||
passing "nmi_watchdog=" parameter at boot time is required for this function
|
||||
to work.
|
||||
|
||||
Because the NMI watchdog shares registers with oprofile, by disabling the NMI
|
||||
watchdog, oprofile may have more registers to utilize.
|
||||
If LAPIC NMI watchdog method is in use (nmi_watchdog=2 kernel parameter), the
|
||||
NMI watchdog shares registers with oprofile. By disabling the NMI watchdog,
|
||||
oprofile may have more registers to utilize.
|
||||
|
||||
msgmni
|
||||
------
|
||||
@@ -2483,4 +2487,30 @@ For more information on mount propagation see:
|
||||
|
||||
Documentation/filesystems/sharedsubtree.txt
|
||||
|
||||
2.17 /proc/sys/fs/epoll - Configuration options for the epoll interface
|
||||
--------------------------------------------------------
|
||||
|
||||
This directory contains configuration options for the epoll(7) interface.
|
||||
|
||||
max_user_instances
|
||||
------------------
|
||||
|
||||
This is the maximum number of epoll file descriptors that a single user can
|
||||
have open at a given time. The default value is 128, and should be enough
|
||||
for normal users.
|
||||
|
||||
max_user_watches
|
||||
----------------
|
||||
|
||||
Every epoll file descriptor can store a number of files to be monitored
|
||||
for event readiness. Each one of these monitored files constitutes a "watch".
|
||||
This configuration option sets the maximum number of "watches" that are
|
||||
allowed for each user.
|
||||
Each "watch" costs roughly 90 bytes on a 32bit kernel, and roughly 160 bytes
|
||||
on a 64bit one.
|
||||
The current default value for max_user_watches is the 1/32 of the available
|
||||
low memory, divided for the "watch" cost in bytes.
|
||||
|
||||
|
||||
------------------------------------------------------------------------------
|
||||
|
||||
|
||||
@@ -130,12 +130,12 @@ The 2.6 kernel build process always creates a gzipped cpio format initramfs
|
||||
archive and links it into the resulting kernel binary. By default, this
|
||||
archive is empty (consuming 134 bytes on x86).
|
||||
|
||||
The config option CONFIG_INITRAMFS_SOURCE (for some reason buried under
|
||||
devices->block devices in menuconfig, and living in usr/Kconfig) can be used
|
||||
to specify a source for the initramfs archive, which will automatically be
|
||||
incorporated into the resulting binary. This option can point to an existing
|
||||
gzipped cpio archive, a directory containing files to be archived, or a text
|
||||
file specification such as the following example:
|
||||
The config option CONFIG_INITRAMFS_SOURCE (in General Setup in menuconfig,
|
||||
and living in usr/Kconfig) can be used to specify a source for the
|
||||
initramfs archive, which will automatically be incorporated into the
|
||||
resulting binary. This option can point to an existing gzipped cpio
|
||||
archive, a directory containing files to be archived, or a text file
|
||||
specification such as the following example:
|
||||
|
||||
dir /dev 755 0 0
|
||||
nod /dev/console 644 0 0 c 5 1
|
||||
|
||||
@@ -229,10 +229,6 @@ The following sysctls are available for the XFS filesystem:
|
||||
ISGID bit is cleared if the irix_sgid_inherit compatibility sysctl
|
||||
is set.
|
||||
|
||||
fs.xfs.restrict_chown (Min: 0 Default: 1 Max: 1)
|
||||
Controls whether unprivileged users can use chown to "give away"
|
||||
a file to another user.
|
||||
|
||||
fs.xfs.inherit_sync (Min: 0 Default: 1 Max: 1)
|
||||
Setting this to "1" will cause the "sync" flag set
|
||||
by the xfs_io(8) chattr command on a directory to be
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user