mirror of
https://github.com/armbian/linux.git
synced 2026-01-06 10:13:00 -08:00
Merge branch 'sh/stable-updates'
This commit is contained in:
Paul Mundt
4
.mailmap
4
.mailmap
@@ -92,6 +92,7 @@ Rudolf Marek <R.Marek@sh.cvut.cz>
|
||||
Rui Saraiva <rmps@joel.ist.utl.pt>
|
||||
Sachin P Sant <ssant@in.ibm.com>
|
||||
Sam Ravnborg <sam@mars.ravnborg.org>
|
||||
Sascha Hauer <s.hauer@pengutronix.de>
|
||||
S.Çağlar Onur <caglar@pardus.org.tr>
|
||||
Simon Kelley <simon@thekelleys.org.uk>
|
||||
Stéphane Witzmann <stephane.witzmann@ubpmes.univ-bpclermont.fr>
|
||||
@@ -100,6 +101,7 @@ Tejun Heo <htejun@gmail.com>
|
||||
Thomas Graf <tgraf@suug.ch>
|
||||
Tony Luck <tony.luck@intel.com>
|
||||
Tsuneo Yoshioka <Tsuneo.Yoshioka@f-secure.com>
|
||||
Uwe Kleine-König <Uwe.Kleine-Koenig@digi.com>
|
||||
Uwe Kleine-König <ukleinek@informatik.uni-freiburg.de>
|
||||
Uwe Kleine-König <ukl@pengutronix.de>
|
||||
Uwe Kleine-König <Uwe.Kleine-Koenig@digi.com>
|
||||
Valdis Kletnieks <Valdis.Kletnieks@vt.edu>
|
||||
|
||||
@@ -33,10 +33,12 @@ o Gnu make 3.79.1 # make --version
|
||||
o binutils 2.12 # ld -v
|
||||
o util-linux 2.10o # fdformat --version
|
||||
o module-init-tools 0.9.10 # depmod -V
|
||||
o e2fsprogs 1.29 # tune2fs
|
||||
o e2fsprogs 1.41.4 # e2fsck -V
|
||||
o jfsutils 1.1.3 # fsck.jfs -V
|
||||
o reiserfsprogs 3.6.3 # reiserfsck -V 2>&1|grep reiserfsprogs
|
||||
o xfsprogs 2.6.0 # xfs_db -V
|
||||
o squashfs-tools 4.0 # mksquashfs -version
|
||||
o btrfs-progs 0.18 # btrfsck
|
||||
o pcmciautils 004 # pccardctl -V
|
||||
o quota-tools 3.09 # quota -V
|
||||
o PPP 2.4.0 # pppd --version
|
||||
|
||||
@@ -483,17 +483,25 @@ values. To do the latter, you can stick the following in your .emacs file:
|
||||
(* (max steps 1)
|
||||
c-basic-offset)))
|
||||
|
||||
(add-hook 'c-mode-common-hook
|
||||
(lambda ()
|
||||
;; Add kernel style
|
||||
(c-add-style
|
||||
"linux-tabs-only"
|
||||
'("linux" (c-offsets-alist
|
||||
(arglist-cont-nonempty
|
||||
c-lineup-gcc-asm-reg
|
||||
c-lineup-arglist-tabs-only))))))
|
||||
|
||||
(add-hook 'c-mode-hook
|
||||
(lambda ()
|
||||
(let ((filename (buffer-file-name)))
|
||||
;; Enable kernel mode for the appropriate files
|
||||
(when (and filename
|
||||
(string-match "~/src/linux-trees" filename))
|
||||
(string-match (expand-file-name "~/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))))))
|
||||
(c-set-style "linux-tabs-only")))))
|
||||
|
||||
This will make emacs go better with the kernel coding style for C
|
||||
files below ~/src/linux-trees.
|
||||
|
||||
@@ -5,7 +5,7 @@
|
||||
|
||||
This document describes the DMA API. For a more gentle introduction
|
||||
phrased in terms of the pci_ equivalents (and actual examples) see
|
||||
DMA-mapping.txt
|
||||
Documentation/PCI/PCI-DMA-mapping.txt.
|
||||
|
||||
This API is split into two pieces. Part I describes the API and the
|
||||
corresponding pci_ API. Part II describes the extensions to the API
|
||||
|
||||
@@ -41,6 +41,12 @@ GPL version 2.
|
||||
</abstract>
|
||||
|
||||
<revhistory>
|
||||
<revision>
|
||||
<revnumber>0.7</revnumber>
|
||||
<date>2008-12-23</date>
|
||||
<authorinitials>hjk</authorinitials>
|
||||
<revremark>Added generic platform drivers and offset attribute.</revremark>
|
||||
</revision>
|
||||
<revision>
|
||||
<revnumber>0.6</revnumber>
|
||||
<date>2008-12-05</date>
|
||||
@@ -312,6 +318,16 @@ interested in translating it, please email me
|
||||
pointed to by addr.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
<filename>offset</filename>: The offset, in bytes, that has to be
|
||||
added to the pointer returned by <function>mmap()</function> to get
|
||||
to the actual device memory. This is important if the device's memory
|
||||
is not page aligned. Remember that pointers returned by
|
||||
<function>mmap()</function> are always page aligned, so it is good
|
||||
style to always add this offset.
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<para>
|
||||
@@ -594,6 +610,78 @@ framework to set up sysfs files for this region. Simply leave it alone.
|
||||
</para>
|
||||
</sect1>
|
||||
|
||||
<sect1 id="using_uio_pdrv">
|
||||
<title>Using uio_pdrv for platform devices</title>
|
||||
<para>
|
||||
In many cases, UIO drivers for platform devices can be handled in a
|
||||
generic way. In the same place where you define your
|
||||
<varname>struct platform_device</varname>, you simply also implement
|
||||
your interrupt handler and fill your
|
||||
<varname>struct uio_info</varname>. A pointer to this
|
||||
<varname>struct uio_info</varname> is then used as
|
||||
<varname>platform_data</varname> for your platform device.
|
||||
</para>
|
||||
<para>
|
||||
You also need to set up an array of <varname>struct resource</varname>
|
||||
containing addresses and sizes of your memory mappings. This
|
||||
information is passed to the driver using the
|
||||
<varname>.resource</varname> and <varname>.num_resources</varname>
|
||||
elements of <varname>struct platform_device</varname>.
|
||||
</para>
|
||||
<para>
|
||||
You now have to set the <varname>.name</varname> element of
|
||||
<varname>struct platform_device</varname> to
|
||||
<varname>"uio_pdrv"</varname> to use the generic UIO platform device
|
||||
driver. This driver will fill the <varname>mem[]</varname> array
|
||||
according to the resources given, and register the device.
|
||||
</para>
|
||||
<para>
|
||||
The advantage of this approach is that you only have to edit a file
|
||||
you need to edit anyway. You do not have to create an extra driver.
|
||||
</para>
|
||||
</sect1>
|
||||
|
||||
<sect1 id="using_uio_pdrv_genirq">
|
||||
<title>Using uio_pdrv_genirq for platform devices</title>
|
||||
<para>
|
||||
Especially in embedded devices, you frequently find chips where the
|
||||
irq pin is tied to its own dedicated interrupt line. In such cases,
|
||||
where you can be really sure the interrupt is not shared, we can take
|
||||
the concept of <varname>uio_pdrv</varname> one step further and use a
|
||||
generic interrupt handler. That's what
|
||||
<varname>uio_pdrv_genirq</varname> does.
|
||||
</para>
|
||||
<para>
|
||||
The setup for this driver is the same as described above for
|
||||
<varname>uio_pdrv</varname>, except that you do not implement an
|
||||
interrupt handler. The <varname>.handler</varname> element of
|
||||
<varname>struct uio_info</varname> must remain
|
||||
<varname>NULL</varname>. The <varname>.irq_flags</varname> element
|
||||
must not contain <varname>IRQF_SHARED</varname>.
|
||||
</para>
|
||||
<para>
|
||||
You will set the <varname>.name</varname> element of
|
||||
<varname>struct platform_device</varname> to
|
||||
<varname>"uio_pdrv_genirq"</varname> to use this driver.
|
||||
</para>
|
||||
<para>
|
||||
The generic interrupt handler of <varname>uio_pdrv_genirq</varname>
|
||||
will simply disable the interrupt line using
|
||||
<function>disable_irq_nosync()</function>. After doing its work,
|
||||
userspace can reenable the interrupt by writing 0x00000001 to the UIO
|
||||
device file. The driver already implements an
|
||||
<function>irq_control()</function> to make this possible, you must not
|
||||
implement your own.
|
||||
</para>
|
||||
<para>
|
||||
Using <varname>uio_pdrv_genirq</varname> not only saves a few lines of
|
||||
interrupt handler code. You also do not need to know anything about
|
||||
the chip's internal registers to create the kernel part of the driver.
|
||||
All you need to know is the irq number of the pin the chip is
|
||||
connected to.
|
||||
</para>
|
||||
</sect1>
|
||||
|
||||
</chapter>
|
||||
|
||||
<chapter id="userspace_driver" xreflabel="Writing a driver in user space">
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
[ NOTE: The virt_to_bus() and bus_to_virt() functions have been
|
||||
superseded by the functionality provided by the PCI DMA
|
||||
interface (see Documentation/DMA-mapping.txt). They continue
|
||||
superseded by the functionality provided by the PCI DMA interface
|
||||
(see Documentation/PCI/PCI-DMA-mapping.txt). They continue
|
||||
to be documented below for historical purposes, but new code
|
||||
must not use them. --davidm 00/12/12 ]
|
||||
|
||||
|
||||
@@ -186,8 +186,9 @@ a virtual address mapping (unlike the earlier scheme of virtual address
|
||||
do not have a corresponding kernel virtual address space mapping) and
|
||||
low-memory pages.
|
||||
|
||||
Note: Please refer to DMA-mapping.txt for a discussion on PCI high mem DMA
|
||||
aspects and mapping of scatter gather lists, and support for 64 bit PCI.
|
||||
Note: Please refer to Documentation/PCI/PCI-DMA-mapping.txt for a discussion
|
||||
on PCI high mem DMA aspects and mapping of scatter gather lists, and support
|
||||
for 64 bit PCI.
|
||||
|
||||
Special handling is required only for cases where i/o needs to happen on
|
||||
pages at physical memory addresses beyond what the device can support. In these
|
||||
@@ -953,14 +954,14 @@ elevator_allow_merge_fn called whenever the block layer determines
|
||||
results in some sort of conflict internally,
|
||||
this hook allows it to do that.
|
||||
|
||||
elevator_dispatch_fn fills the dispatch queue with ready requests.
|
||||
elevator_dispatch_fn* fills the dispatch queue with ready requests.
|
||||
I/O schedulers are free to postpone requests by
|
||||
not filling the dispatch queue unless @force
|
||||
is non-zero. Once dispatched, I/O schedulers
|
||||
are not allowed to manipulate the requests -
|
||||
they belong to generic dispatch queue.
|
||||
|
||||
elevator_add_req_fn called to add a new request into the scheduler
|
||||
elevator_add_req_fn* called to add a new request into the scheduler
|
||||
|
||||
elevator_queue_empty_fn returns true if the merge queue is empty.
|
||||
Drivers shouldn't use this, but rather check
|
||||
@@ -990,7 +991,7 @@ elevator_activate_req_fn Called when device driver first sees a request.
|
||||
elevator_deactivate_req_fn Called when device driver decides to delay
|
||||
a request by requeueing it.
|
||||
|
||||
elevator_init_fn
|
||||
elevator_init_fn*
|
||||
elevator_exit_fn Allocate and free any elevator specific storage
|
||||
for a queue.
|
||||
|
||||
|
||||
63
Documentation/block/queue-sysfs.txt
Normal file
63
Documentation/block/queue-sysfs.txt
Normal file
@@ -0,0 +1,63 @@
|
||||
Queue sysfs files
|
||||
=================
|
||||
|
||||
This text file will detail the queue files that are located in the sysfs tree
|
||||
for each block device. Note that stacked devices typically do not export
|
||||
any settings, since their queue merely functions are a remapping target.
|
||||
These files are the ones found in the /sys/block/xxx/queue/ directory.
|
||||
|
||||
Files denoted with a RO postfix are readonly and the RW postfix means
|
||||
read-write.
|
||||
|
||||
hw_sector_size (RO)
|
||||
-------------------
|
||||
This is the hardware sector size of the device, in bytes.
|
||||
|
||||
max_hw_sectors_kb (RO)
|
||||
----------------------
|
||||
This is the maximum number of kilobytes supported in a single data transfer.
|
||||
|
||||
max_sectors_kb (RW)
|
||||
-------------------
|
||||
This is the maximum number of kilobytes that the block layer will allow
|
||||
for a filesystem request. Must be smaller than or equal to the maximum
|
||||
size allowed by the hardware.
|
||||
|
||||
nomerges (RW)
|
||||
-------------
|
||||
This enables the user to disable the lookup logic involved with IO merging
|
||||
requests in the block layer. Merging may still occur through a direct
|
||||
1-hit cache, since that comes for (almost) free. The IO scheduler will not
|
||||
waste cycles doing tree/hash lookups for merges if nomerges is 1. Defaults
|
||||
to 0, enabling all merges.
|
||||
|
||||
nr_requests (RW)
|
||||
----------------
|
||||
This controls how many requests may be allocated in the block layer for
|
||||
read or write requests. Note that the total allocated number may be twice
|
||||
this amount, since it applies only to reads or writes (not the accumulated
|
||||
sum).
|
||||
|
||||
read_ahead_kb (RW)
|
||||
------------------
|
||||
Maximum number of kilobytes to read-ahead for filesystems on this block
|
||||
device.
|
||||
|
||||
rq_affinity (RW)
|
||||
----------------
|
||||
If this option is enabled, the block layer will migrate request completions
|
||||
to the CPU that originally submitted the request. For some workloads
|
||||
this provides a significant reduction in CPU cycles due to caching effects.
|
||||
|
||||
scheduler (RW)
|
||||
--------------
|
||||
When read, this file will display the current and available IO schedulers
|
||||
for this block device. The currently active IO scheduler will be enclosed
|
||||
in [] brackets. Writing an IO scheduler name to this file will switch
|
||||
control of this block device to that new IO scheduler. Note that writing
|
||||
an IO scheduler name to this file will attempt to load that IO scheduler
|
||||
module, if it isn't already present in the system.
|
||||
|
||||
|
||||
|
||||
Jens Axboe <jens.axboe@oracle.com>, February 2009
|
||||
@@ -1,6 +1,6 @@
|
||||
Memory Resource Controller(Memcg) Implementation Memo.
|
||||
Last Updated: 2008/12/15
|
||||
Base Kernel Version: based on 2.6.28-rc8-mm.
|
||||
Last Updated: 2009/1/19
|
||||
Base Kernel Version: based on 2.6.29-rc2.
|
||||
|
||||
Because VM is getting complex (one of reasons is memcg...), memcg's behavior
|
||||
is complex. This is a document for memcg's internal behavior.
|
||||
@@ -340,3 +340,23 @@ Under below explanation, we assume CONFIG_MEM_RES_CTRL_SWAP=y.
|
||||
# mount -t cgroup none /cgroup -t cpuset,memory,cpu,devices
|
||||
|
||||
and do task move, mkdir, rmdir etc...under this.
|
||||
|
||||
9.7 swapoff.
|
||||
Besides management of swap is one of complicated parts of memcg,
|
||||
call path of swap-in at swapoff is not same as usual swap-in path..
|
||||
It's worth to be tested explicitly.
|
||||
|
||||
For example, test like following is good.
|
||||
(Shell-A)
|
||||
# mount -t cgroup none /cgroup -t memory
|
||||
# mkdir /cgroup/test
|
||||
# echo 40M > /cgroup/test/memory.limit_in_bytes
|
||||
# echo 0 > /cgroup/test/tasks
|
||||
Run malloc(100M) program under this. You'll see 60M of swaps.
|
||||
(Shell-B)
|
||||
# move all tasks in /cgroup/test to /cgroup
|
||||
# /sbin/swapoff -a
|
||||
# rmdir /test/cgroup
|
||||
# kill malloc task.
|
||||
|
||||
Of course, tmpfs v.s. swapoff test should be tested, too.
|
||||
|
||||
@@ -195,19 +195,3 @@ scaling_setspeed. By "echoing" a new frequency into this
|
||||
you can change the speed of the CPU,
|
||||
but only within the limits of
|
||||
scaling_min_freq and scaling_max_freq.
|
||||
|
||||
|
||||
3.2 Deprecated Interfaces
|
||||
-------------------------
|
||||
|
||||
Depending on your kernel configuration, you might find the following
|
||||
cpufreq-related files:
|
||||
/proc/cpufreq
|
||||
/proc/sys/cpu/*/speed
|
||||
/proc/sys/cpu/*/speed-min
|
||||
/proc/sys/cpu/*/speed-max
|
||||
|
||||
These are files for deprecated interfaces to cpufreq, which offer far
|
||||
less functionality. Because of this, these interfaces aren't described
|
||||
here.
|
||||
|
||||
|
||||
@@ -2027,6 +2027,34 @@ increase the likelihood of this process being killed by the oom-killer. Valid
|
||||
values are in the range -16 to +15, plus the special value -17, which disables
|
||||
oom-killing altogether for this process.
|
||||
|
||||
The process to be killed in an out-of-memory situation is selected among all others
|
||||
based on its badness score. This value equals the original memory size of the process
|
||||
and is then updated according to its CPU time (utime + stime) and the
|
||||
run time (uptime - start time). The longer it runs the smaller is the score.
|
||||
Badness score is divided by the square root of the CPU time and then by
|
||||
the double square root of the run time.
|
||||
|
||||
Swapped out tasks are killed first. Half of each child's memory size is added to
|
||||
the parent's score if they do not share the same memory. Thus forking servers
|
||||
are the prime candidates to be killed. Having only one 'hungry' child will make
|
||||
parent less preferable than the child.
|
||||
|
||||
/proc/<pid>/oom_score shows process' current badness score.
|
||||
|
||||
The following heuristics are then applied:
|
||||
* if the task was reniced, its score doubles
|
||||
* superuser or direct hardware access tasks (CAP_SYS_ADMIN, CAP_SYS_RESOURCE
|
||||
or CAP_SYS_RAWIO) have their score divided by 4
|
||||
* if oom condition happened in one cpuset and checked task does not belong
|
||||
to it, its score is divided by 8
|
||||
* the resulting score is multiplied by two to the power of oom_adj, i.e.
|
||||
points <<= oom_adj when it is positive and
|
||||
points >>= -(oom_adj) otherwise
|
||||
|
||||
The task with the highest badness score is then selected and its children
|
||||
are killed, process itself will be killed in an OOM situation when it does
|
||||
not have children or some of them disabled oom like described above.
|
||||
|
||||
2.13 /proc/<pid>/oom_score - Display current oom-killer score
|
||||
-------------------------------------------------------------
|
||||
|
||||
|
||||
@@ -9,6 +9,7 @@ that support it. For example, a given bus might look like this:
|
||||
| |-- class
|
||||
| |-- config
|
||||
| |-- device
|
||||
| |-- enable
|
||||
| |-- irq
|
||||
| |-- local_cpus
|
||||
| |-- resource
|
||||
@@ -32,6 +33,7 @@ files, each with their own function.
|
||||
class PCI class (ascii, ro)
|
||||
config PCI config space (binary, rw)
|
||||
device PCI device (ascii, ro)
|
||||
enable Whether the device is enabled (ascii, rw)
|
||||
irq IRQ number (ascii, ro)
|
||||
local_cpus nearby CPU mask (cpumask, ro)
|
||||
resource PCI resource host addresses (ascii, ro)
|
||||
@@ -57,10 +59,19 @@ used to do actual device programming from userspace. Note that some platforms
|
||||
don't support mmapping of certain resources, so be sure to check the return
|
||||
value from any attempted mmap.
|
||||
|
||||
The 'enable' file provides a counter that indicates how many times the device
|
||||
has been enabled. If the 'enable' file currently returns '4', and a '1' is
|
||||
echoed into it, it will then return '5'. Echoing a '0' into it will decrease
|
||||
the count. Even when it returns to 0, though, some of the initialisation
|
||||
may not be reversed.
|
||||
|
||||
The 'rom' file is special in that it provides read-only access to the device's
|
||||
ROM file, if available. It's disabled by default, however, so applications
|
||||
should write the string "1" to the file to enable it before attempting a read
|
||||
call, and disable it following the access by writing "0" to the file.
|
||||
call, and disable it following the access by writing "0" to the file. Note
|
||||
that the device must be enabled for a rom read to return data succesfully.
|
||||
In the event a driver is not bound to the device, it can be enabled using the
|
||||
'enable' file, documented above.
|
||||
|
||||
Accessing legacy resources through sysfs
|
||||
----------------------------------------
|
||||
|
||||
@@ -79,13 +79,6 @@ Mount options
|
||||
|
||||
(*) == default.
|
||||
|
||||
norm_unmount (*) commit on unmount; the journal is committed
|
||||
when the file-system is unmounted so that the
|
||||
next mount does not have to replay the journal
|
||||
and it becomes very fast;
|
||||
fast_unmount do not commit on unmount; this option makes
|
||||
unmount faster, but the next mount slower
|
||||
because of the need to replay the journal.
|
||||
bulk_read read more in one go to take advantage of flash
|
||||
media that read faster sequentially
|
||||
no_bulk_read (*) do not bulk-read
|
||||
|
||||
@@ -12,11 +12,11 @@ file at first.
|
||||
|
||||
==================================
|
||||
これは、
|
||||
linux-2.6.24/Documentation/stable_kernel_rules.txt
|
||||
linux-2.6.29/Documentation/stable_kernel_rules.txt
|
||||
の和訳です。
|
||||
|
||||
翻訳団体： JF プロジェクト < http://www.linux.or.jp/JF/ >
|
||||
翻訳日： 2007/12/30
|
||||
翻訳日： 2009/1/14
|
||||
翻訳者： Tsugikazu Shibata <tshibata at ab dot jp dot nec dot com>
|
||||
校正者： 武井伸光さん、<takei at webmasters dot gr dot jp>
|
||||
かねこさん (Seiji Kaneko) <skaneko at a2 dot mbn dot or dot jp>
|
||||
@@ -38,12 +38,15 @@ linux-2.6.24/Documentation/stable_kernel_rules.txt
|
||||
- ビルドエラー(CONFIG_BROKENになっているものを除く), oops, ハング、デー
|
||||
タ破壊、現実のセキュリティ問題、その他 "ああ、これはダメだね"という
|
||||
ようなものを修正しなければならない。短く言えば、重大な問題。
|
||||
- 新しい device ID とクオークも受け入れられる。
|
||||
- どのように競合状態が発生するかの説明も一緒に書かれていない限り、
|
||||
"理論的には競合状態になる"ようなものは不可。
|
||||
- いかなる些細な修正も含めることはできない。(スペルの修正、空白のクリー
|
||||
ンアップなど)
|
||||
- 対応するサブシステムメンテナが受け入れたものでなければならない。
|
||||
- Documentation/SubmittingPatches の規則に従ったものでなければならない。
|
||||
- パッチ自体か同等の修正が Linus のツリーに既に存在しなければならない。
|
||||
Linus のツリーでのコミットID を -stable へのパッチ投稿の際に引用す
|
||||
ること。
|
||||
|
||||
-stable ツリーにパッチを送付する手続き-
|
||||
|
||||
@@ -52,8 +55,10 @@ linux-2.6.24/Documentation/stable_kernel_rules.txt
|
||||
- 送信者はパッチがキューに受け付けられた際には ACK を、却下された場合
|
||||
には NAK を受け取る。この反応は開発者たちのスケジュールによって、数
|
||||
日かかる場合がある。
|
||||
- もし受け取られたら、パッチは他の開発者たちのレビューのために
|
||||
-stable キューに追加される。
|
||||
- もし受け取られたら、パッチは他の開発者たちと関連するサブシステムの
|
||||
メンテナーによるレビューのために -stable キューに追加される。
|
||||
- パッチに stable@kernel.org のアドレスが付加されているときには、それ
|
||||
が Linus のツリーに入る時に自動的に stable チームに email される。
|
||||
- セキュリティパッチはこのエイリアス (stable@kernel.org) に送られるべ
|
||||
きではなく、代わりに security@kernel.org のアドレスに送られる。
|
||||
|
||||
|
||||
@@ -43,7 +43,8 @@ Only comments so marked will be considered by the kernel-doc scripts,
|
||||
and any comment so marked must be in kernel-doc format. Do not use
|
||||
"/**" to be begin a comment block unless the comment block contains
|
||||
kernel-doc formatted comments. The closing comment marker for
|
||||
kernel-doc comments can be either "*/" or "**/".
|
||||
kernel-doc comments can be either "*/" or "**/", but "*/" is
|
||||
preferred in the Linux kernel tree.
|
||||
|
||||
Kernel-doc comments should be placed just before the function
|
||||
or data structure being described.
|
||||
@@ -63,7 +64,7 @@ Example kernel-doc function comment:
|
||||
* comment lines.
|
||||
*
|
||||
* The longer description can have multiple paragraphs.
|
||||
**/
|
||||
*/
|
||||
|
||||
The first line, with the short description, must be on a single line.
|
||||
|
||||
@@ -85,7 +86,7 @@ Example kernel-doc data structure comment.
|
||||
* perhaps with more lines and words.
|
||||
*
|
||||
* Longer description of this structure.
|
||||
**/
|
||||
*/
|
||||
|
||||
The kernel-doc function comments describe each parameter to the
|
||||
function, in order, with the @name lines.
|
||||
|
||||
@@ -937,6 +937,8 @@ and is between 256 and 4096 characters. It is defined in the file
|
||||
|
||||
|
||||
intel_iommu= [DMAR] Intel IOMMU driver (DMAR) option
|
||||
on
|
||||
Enable intel iommu driver.
|
||||
off
|
||||
Disable intel iommu driver.
|
||||
igfx_off [Default Off]
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
# This creates the demonstration utility "lguest" which runs a Linux guest.
|
||||
CFLAGS:=-Wall -Wmissing-declarations -Wmissing-prototypes -O3 -I../../include -I../../arch/x86/include
|
||||
CFLAGS:=-Wall -Wmissing-declarations -Wmissing-prototypes -O3 -I../../include -I../../arch/x86/include -U_FORTIFY_SOURCE
|
||||
LDLIBS:=-lz
|
||||
|
||||
all: lguest
|
||||
|
||||
@@ -2,14 +2,14 @@
|
||||
IP-Aliasing:
|
||||
============
|
||||
|
||||
IP-aliases are additional IP-addresses/masks hooked up to a base
|
||||
interface by adding a colon and a string when running ifconfig.
|
||||
IP-aliases are an obsolete way to manage multiple IP-addresses/masks
|
||||
per interface. Newer tools such as iproute2 support multiple
|
||||
address/prefixes per interface, but aliases are still supported
|
||||
for backwards compatibility.
|
||||
|
||||
An alias is formed by adding a colon and a string when running ifconfig.
|
||||
This string is usually numeric, but this is not a must.
|
||||
|
||||
IP-Aliases are avail if CONFIG_INET (`standard' IPv4 networking)
|
||||
is configured in the kernel.
|
||||
|
||||
|
||||
o Alias creation.
|
||||
Alias creation is done by 'magic' interface naming: eg. to create a
|
||||
200.1.1.1 alias for eth0 ...
|
||||
@@ -38,16 +38,3 @@ o Relationship with main device
|
||||
|
||||
If the base device is shut down the added aliases will be deleted
|
||||
too.
|
||||
|
||||
|
||||
Contact
|
||||
-------
|
||||
Please finger or e-mail me:
|
||||
Juan Jose Ciarlante <jjciarla@raiz.uncu.edu.ar>
|
||||
|
||||
Updated by Erik Schoenfelder <schoenfr@gaertner.DE>
|
||||
|
||||
; local variables:
|
||||
; mode: indented-text
|
||||
; mode: auto-fill
|
||||
; end:
|
||||
|
||||
180
Documentation/powerpc/dts-bindings/fsl/mpc5200.txt
Normal file
180
Documentation/powerpc/dts-bindings/fsl/mpc5200.txt
Normal file
@@ -0,0 +1,180 @@
|
||||
MPC5200 Device Tree Bindings
|
||||
----------------------------
|
||||
|
||||
(c) 2006-2009 Secret Lab Technologies Ltd
|
||||
Grant Likely <grant.likely@secretlab.ca>
|
||||
|
||||
Naming conventions
|
||||
------------------
|
||||
For mpc5200 on-chip devices, the format for each compatible value is
|
||||
<chip>-<device>[-<mode>]. The OS should be able to match a device driver
|
||||
to the device based solely on the compatible value. If two drivers
|
||||
match on the compatible list; the 'most compatible' driver should be
|
||||
selected.
|
||||
|
||||
The split between the MPC5200 and the MPC5200B leaves a bit of a
|
||||
conundrum. How should the compatible property be set up to provide
|
||||
maximum compatibility information; but still accurately describe the
|
||||
chip? For the MPC5200; the answer is easy. Most of the SoC devices
|
||||
originally appeared on the MPC5200. Since they didn't exist anywhere
|
||||
else; the 5200 compatible properties will contain only one item;
|
||||
"fsl,mpc5200-<device>".
|
||||
|
||||
The 5200B is almost the same as the 5200, but not quite. It fixes
|
||||
silicon bugs and it adds a small number of enhancements. Most of the
|
||||
devices either provide exactly the same interface as on the 5200. A few
|
||||
devices have extra functions but still have a backwards compatible mode.
|
||||
To express this information as completely as possible, 5200B device trees
|
||||
should have two items in the compatible list:
|
||||
compatible = "fsl,mpc5200b-<device>","fsl,mpc5200-<device>";
|
||||
|
||||
It is *strongly* recommended that 5200B device trees follow this convention
|
||||
(instead of only listing the base mpc5200 item).
|
||||
|
||||
ie. ethernet on mpc5200: compatible = "fsl,mpc5200-fec";
|
||||
ethernet on mpc5200b: compatible = "fsl,mpc5200b-fec", "fsl,mpc5200-fec";
|
||||
|
||||
Modal devices, like PSCs, also append the configured function to the
|
||||
end of the compatible field. ie. A PSC in i2s mode would specify
|
||||
"fsl,mpc5200-psc-i2s", not "fsl,mpc5200-i2s". This convention is chosen to
|
||||
avoid naming conflicts with non-psc devices providing the same
|
||||
function. For example, "fsl,mpc5200-spi" and "fsl,mpc5200-psc-spi" describe
|
||||
the mpc5200 simple spi device and a PSC spi mode respectively.
|
||||
|
||||
At the time of writing, exact chip may be either 'fsl,mpc5200' or
|
||||
'fsl,mpc5200b'.
|
||||
|
||||
The soc node
|
||||
------------
|
||||
This node describes the on chip SOC peripherals. Every mpc5200 based
|
||||
board will have this node, and as such there is a common naming
|
||||
convention for SOC devices.
|
||||
|
||||
Required properties:
|
||||
name description
|
||||
---- -----------
|
||||
ranges Memory range of the internal memory mapped registers.
|
||||
Should be <0 [baseaddr] 0xc000>
|
||||
reg Should be <[baseaddr] 0x100>
|
||||
compatible mpc5200: "fsl,mpc5200-immr"
|
||||
mpc5200b: "fsl,mpc5200b-immr"
|
||||
system-frequency 'fsystem' frequency in Hz; XLB, IPB, USB and PCI
|
||||
clocks are derived from the fsystem clock.
|
||||
bus-frequency IPB bus frequency in Hz. Clock rate
|
||||
used by most of the soc devices.
|
||||
|
||||
soc child nodes
|
||||
---------------
|
||||
Any on chip SOC devices available to Linux must appear as soc5200 child nodes.
|
||||
|
||||
Note: The tables below show the value for the mpc5200. A mpc5200b device
|
||||
tree should use the "fsl,mpc5200b-<device>","fsl,mpc5200-<device>" form.
|
||||
|
||||
Required soc5200 child nodes:
|
||||
name compatible Description
|
||||
---- ---------- -----------
|
||||
cdm@<addr> fsl,mpc5200-cdm Clock Distribution
|
||||
interrupt-controller@<addr> fsl,mpc5200-pic need an interrupt
|
||||
controller to boot
|
||||
bestcomm@<addr> fsl,mpc5200-bestcomm Bestcomm DMA controller
|
||||
|
||||
Recommended soc5200 child nodes; populate as needed for your board
|
||||
name compatible Description
|
||||
---- ---------- -----------
|
||||
timer@<addr> fsl,mpc5200-gpt General purpose timers
|
||||
gpio@<addr> fsl,mpc5200-gpio MPC5200 simple gpio controller
|
||||
gpio@<addr> fsl,mpc5200-gpio-wkup MPC5200 wakeup gpio controller
|
||||
rtc@<addr> fsl,mpc5200-rtc Real time clock
|
||||
mscan@<addr> fsl,mpc5200-mscan CAN bus controller
|
||||
pci@<addr> fsl,mpc5200-pci PCI bridge
|
||||
serial@<addr> fsl,mpc5200-psc-uart PSC in serial mode
|
||||
i2s@<addr> fsl,mpc5200-psc-i2s PSC in i2s mode
|
||||
ac97@<addr> fsl,mpc5200-psc-ac97 PSC in ac97 mode
|
||||
spi@<addr> fsl,mpc5200-psc-spi PSC in spi mode
|
||||
irda@<addr> fsl,mpc5200-psc-irda PSC in IrDA mode
|
||||
spi@<addr> fsl,mpc5200-spi MPC5200 spi device
|
||||
ethernet@<addr> fsl,mpc5200-fec MPC5200 ethernet device
|
||||
ata@<addr> fsl,mpc5200-ata IDE ATA interface
|
||||
i2c@<addr> fsl,mpc5200-i2c I2C controller
|
||||
usb@<addr> fsl,mpc5200-ohci,ohci-be USB controller
|
||||
xlb@<addr> fsl,mpc5200-xlb XLB arbitrator
|
||||
|
||||
fsl,mpc5200-gpt nodes
|
||||
---------------------
|
||||
On the mpc5200 and 5200b, GPT0 has a watchdog timer function. If the board
|
||||
design supports the internal wdt, then the device node for GPT0 should
|
||||
include the empty property 'fsl,has-wdt'.
|
||||
|
||||
An mpc5200-gpt can be used as a single line GPIO controller. To do so,
|
||||
add the following properties to the gpt node:
|
||||
gpio-controller;
|
||||
#gpio-cells = <2>;
|
||||
When referencing the GPIO line from another node, the first cell must always
|
||||
be zero and the second cell represents the gpio flags and described in the
|
||||
gpio device tree binding.
|
||||
|
||||
An mpc5200-gpt can be used as a single line edge sensitive interrupt
|
||||
controller. To do so, add the following properties to the gpt node:
|
||||
interrupt-controller;
|
||||
#interrupt-cells = <1>;
|
||||
When referencing the IRQ line from another node, the cell represents the
|
||||
sense mode; 1 for edge rising, 2 for edge falling.
|
||||
|
||||
fsl,mpc5200-psc nodes
|
||||
---------------------
|
||||
The PSCs should include a cell-index which is the index of the PSC in
|
||||
hardware. cell-index is used to determine which shared SoC registers to
|
||||
use when setting up PSC clocking. cell-index number starts at '0'. ie:
|
||||
PSC1 has 'cell-index = <0>'
|
||||
PSC4 has 'cell-index = <3>'
|
||||
|
||||
PSC in i2s mode: The mpc5200 and mpc5200b PSCs are not compatible when in
|
||||
i2s mode. An 'mpc5200b-psc-i2s' node cannot include 'mpc5200-psc-i2s' in the
|
||||
compatible field.
|
||||
|
||||
|
||||
fsl,mpc5200-gpio and fsl,mpc5200-gpio-wkup nodes
|
||||
------------------------------------------------
|
||||
Each GPIO controller node should have the empty property gpio-controller and
|
||||
#gpio-cells set to 2. First cell is the GPIO number which is interpreted
|
||||
according to the bit numbers in the GPIO control registers. The second cell
|
||||
is for flags which is currently unused.
|
||||
|
||||
fsl,mpc5200-fec nodes
|
||||
---------------------
|
||||
The FEC node can specify one of the following properties to configure
|
||||
the MII link:
|
||||
- fsl,7-wire-mode - An empty property that specifies the link uses 7-wire
|
||||
mode instead of MII
|
||||
- current-speed - Specifies that the MII should be configured for a fixed
|
||||
speed. This property should contain two cells. The
|
||||
first cell specifies the speed in Mbps and the second
|
||||
should be '0' for half duplex and '1' for full duplex
|
||||
- phy-handle - Contains a phandle to an Ethernet PHY.
|
||||
|
||||
Interrupt controller (fsl,mpc5200-pic) node
|
||||
-------------------------------------------
|
||||
The mpc5200 pic binding splits hardware IRQ numbers into two levels. The
|
||||
split reflects the layout of the PIC hardware itself, which groups
|
||||
interrupts into one of three groups; CRIT, MAIN or PERP. Also, the
|
||||
Bestcomm dma engine has it's own set of interrupt sources which are
|
||||
cascaded off of peripheral interrupt 0, which the driver interprets as a
|
||||
fourth group, SDMA.
|
||||
|
||||
The interrupts property for device nodes using the mpc5200 pic consists
|
||||
of three cells; <L1 L2 level>
|
||||
|
||||
L1 := [CRIT=0, MAIN=1, PERP=2, SDMA=3]
|
||||
L2 := interrupt number; directly mapped from the value in the
|
||||
"ICTL PerStat, MainStat, CritStat Encoded Register"
|
||||
level := [LEVEL_HIGH=0, EDGE_RISING=1, EDGE_FALLING=2, LEVEL_LOW=3]
|
||||
|
||||
For external IRQs, use the following interrupt property values (how to
|
||||
specify external interrupts is a frequently asked question):
|
||||
External interrupts:
|
||||
external irq0: interrupts = <0 0 n>;
|
||||
external irq1: interrupts = <1 1 n>;
|
||||
external irq2: interrupts = <1 2 n>;
|
||||
external irq3: interrupts = <1 3 n>;
|
||||
'n' is sense (0: level high, 1: edge rising, 2: edge falling 3: level low)
|
||||
|
||||
@@ -1,277 +0,0 @@
|
||||
MPC5200 Device Tree Bindings
|
||||
----------------------------
|
||||
|
||||
(c) 2006-2007 Secret Lab Technologies Ltd
|
||||
Grant Likely <grant.likely at secretlab.ca>
|
||||
|
||||
********** DRAFT ***********
|
||||
* WARNING: Do not depend on the stability of these bindings just yet.
|
||||
* The MPC5200 device tree conventions are still in flux
|
||||
* Keep an eye on the linuxppc-dev mailing list for more details
|
||||
********** DRAFT ***********
|
||||
|
||||
I - Introduction
|
||||
================
|
||||
Boards supported by the arch/powerpc architecture require device tree be
|
||||
passed by the boot loader to the kernel at boot time. The device tree
|
||||
describes what devices are present on the board and how they are
|
||||
connected. The device tree can either be passed as a binary blob (as
|
||||
described in Documentation/powerpc/booting-without-of.txt), or passed
|
||||
by Open Firmware (IEEE 1275) compatible firmware using an OF compatible
|
||||
client interface API.
|
||||
|
||||
This document specifies the requirements on the device-tree for mpc5200
|
||||
based boards. These requirements are above and beyond the details
|
||||
specified in either the Open Firmware spec or booting-without-of.txt
|
||||
|
||||
All new mpc5200-based boards are expected to match this document. In
|
||||
cases where this document is not sufficient to support a new board port,
|
||||
this document should be updated as part of adding the new board support.
|
||||
|
||||
II - Philosophy
|
||||
===============
|
||||
The core of this document is naming convention. The whole point of
|
||||
defining this convention is to reduce or eliminate the number of
|
||||
special cases required to support a 5200 board. If all 5200 boards
|
||||
follow the same convention, then generic 5200 support code will work
|
||||
rather than coding special cases for each new board.
|
||||
|
||||
This section tries to capture the thought process behind why the naming
|
||||
convention is what it is.
|
||||
|
||||
1. names
|
||||
---------
|
||||
There is strong convention/requirements already established for children
|
||||
of the root node. 'cpus' describes the processor cores, 'memory'
|
||||
describes memory, and 'chosen' provides boot configuration. Other nodes
|
||||
are added to describe devices attached to the processor local bus.
|
||||
|
||||
Following convention already established with other system-on-chip
|
||||
processors, 5200 device trees should use the name 'soc5200' for the
|
||||
parent node of on chip devices, and the root node should be its parent.
|
||||
|
||||
Child nodes are typically named after the configured function. ie.
|
||||
the FEC node is named 'ethernet', and a PSC in uart mode is named 'serial'.
|
||||
|
||||
2. device_type property
|
||||
-----------------------
|
||||
similar to the node name convention above; the device_type reflects the
|
||||
configured function of a device. ie. 'serial' for a uart and 'spi' for
|
||||
an spi controller. However, while node names *should* reflect the
|
||||
configured function, device_type *must* match the configured function
|
||||
exactly.
|
||||
|
||||
3. compatible property
|
||||
----------------------
|
||||
Since device_type isn't enough to match devices to drivers, there also
|
||||
needs to be a naming convention for the compatible property. Compatible
|
||||
is an list of device descriptions sorted from specific to generic. For
|
||||
the mpc5200, the required format for each compatible value is
|
||||
<chip>-<device>[-<mode>]. The OS should be able to match a device driver
|
||||
to the device based solely on the compatible value. If two drivers
|
||||
match on the compatible list; the 'most compatible' driver should be
|
||||
selected.
|
||||
|
||||
The split between the MPC5200 and the MPC5200B leaves a bit of a
|
||||
conundrum. How should the compatible property be set up to provide
|
||||
maximum compatibility information; but still accurately describe the
|
||||
chip? For the MPC5200; the answer is easy. Most of the SoC devices
|
||||
originally appeared on the MPC5200. Since they didn't exist anywhere
|
||||
else; the 5200 compatible properties will contain only one item;
|
||||
"mpc5200-<device>".
|
||||
|
||||
The 5200B is almost the same as the 5200, but not quite. It fixes
|
||||
silicon bugs and it adds a small number of enhancements. Most of the
|
||||
devices either provide exactly the same interface as on the 5200. A few
|
||||
devices have extra functions but still have a backwards compatible mode.
|
||||
To express this information as completely as possible, 5200B device trees
|
||||
should have two items in the compatible list;
|
||||
"mpc5200b-<device>\0mpc5200-<device>". It is *strongly* recommended
|
||||
that 5200B device trees follow this convention (instead of only listing
|
||||
the base mpc5200 item).
|
||||
|
||||
If another chip appear on the market with one of the mpc5200 SoC
|
||||
devices, then the compatible list should include mpc5200-<device>.
|
||||
|
||||
ie. ethernet on mpc5200: compatible = "mpc5200-ethernet"
|
||||
ethernet on mpc5200b: compatible = "mpc5200b-ethernet\0mpc5200-ethernet"
|
||||
|
||||
Modal devices, like PSCs, also append the configured function to the
|
||||
end of the compatible field. ie. A PSC in i2s mode would specify
|
||||
"mpc5200-psc-i2s", not "mpc5200-i2s". This convention is chosen to
|
||||
avoid naming conflicts with non-psc devices providing the same
|
||||
function. For example, "mpc5200-spi" and "mpc5200-psc-spi" describe
|
||||
the mpc5200 simple spi device and a PSC spi mode respectively.
|
||||
|
||||
If the soc device is more generic and present on other SOCs, the
|
||||
compatible property can specify the more generic device type also.
|
||||
|
||||
ie. mscan: compatible = "mpc5200-mscan\0fsl,mscan";
|
||||
|
||||
At the time of writing, exact chip may be either 'mpc5200' or
|
||||
'mpc5200b'.
|
||||
|
||||
Device drivers should always try to match as generically as possible.
|
||||
|
||||
III - Structure
|
||||
===============
|
||||
The device tree for an mpc5200 board follows the structure defined in
|
||||
booting-without-of.txt with the following additional notes:
|
||||
|
||||
0) the root node
|
||||
----------------
|
||||
Typical root description node; see booting-without-of
|
||||
|
||||
1) The cpus node
|
||||
----------------
|
||||
The cpus node follows the basic layout described in booting-without-of.
|
||||
The bus-frequency property holds the XLB bus frequency
|
||||
The clock-frequency property holds the core frequency
|
||||
|
||||
2) The memory node
|
||||
------------------
|
||||
Typical memory description node; see booting-without-of.
|
||||
|
||||
3) The soc5200 node
|
||||
-------------------
|
||||
This node describes the on chip SOC peripherals. Every mpc5200 based
|
||||
board will have this node, and as such there is a common naming
|
||||
convention for SOC devices.
|
||||
|
||||
Required properties:
|
||||
name type description
|
||||
---- ---- -----------
|
||||
device_type string must be "soc"
|
||||
ranges int should be <0 baseaddr baseaddr+10000>
|
||||
reg int must be <baseaddr 10000>
|
||||
compatible string mpc5200: "mpc5200-soc"
|
||||
mpc5200b: "mpc5200b-soc\0mpc5200-soc"
|
||||
system-frequency int Fsystem frequency; source of all
|
||||
other clocks.
|
||||
bus-frequency int IPB bus frequency in HZ. Clock rate
|
||||
used by most of the soc devices.
|
||||
#interrupt-cells int must be <3>.
|
||||
|
||||
Recommended properties:
|
||||
name type description
|
||||
---- ---- -----------
|
||||
model string Exact model of the chip;
|
||||
ie: model="fsl,mpc5200"
|
||||
revision string Silicon revision of chip
|
||||
ie: revision="M08A"
|
||||
|
||||
The 'model' and 'revision' properties are *strongly* recommended. Having
|
||||
them presence acts as a bit of a safety net for working around as yet
|
||||
undiscovered bugs on one version of silicon. For example, device drivers
|
||||
can use the model and revision properties to decide if a bug fix should
|
||||
be turned on.
|
||||
|
||||
4) soc5200 child nodes
|
||||
----------------------
|
||||
Any on chip SOC devices available to Linux must appear as soc5200 child nodes.
|
||||
|
||||
Note: The tables below show the value for the mpc5200. A mpc5200b device
|
||||
tree should use the "mpc5200b-<device>\0mpc5200-<device> form.
|
||||
|
||||
Required soc5200 child nodes:
|
||||
name device_type compatible Description
|
||||
---- ----------- ---------- -----------
|
||||
cdm@<addr> cdm mpc5200-cmd Clock Distribution
|
||||
pic@<addr> interrupt-controller mpc5200-pic need an interrupt
|
||||
controller to boot
|
||||
bestcomm@<addr> dma-controller mpc5200-bestcomm 5200 pic also requires
|
||||
the bestcomm device
|
||||
|
||||
Recommended soc5200 child nodes; populate as needed for your board
|
||||
name device_type compatible Description
|
||||
---- ----------- ---------- -----------
|
||||
gpt@<addr> gpt fsl,mpc5200-gpt General purpose timers
|
||||
gpt@<addr> gpt fsl,mpc5200-gpt-gpio General purpose
|
||||
timers in GPIO mode
|
||||
gpio@<addr> fsl,mpc5200-gpio MPC5200 simple gpio
|
||||
controller
|
||||
gpio@<addr> fsl,mpc5200-gpio-wkup MPC5200 wakeup gpio
|
||||
controller
|
||||
rtc@<addr> rtc mpc5200-rtc Real time clock
|
||||
mscan@<addr> mscan mpc5200-mscan CAN bus controller
|
||||
pci@<addr> pci mpc5200-pci PCI bridge
|
||||
serial@<addr> serial mpc5200-psc-uart PSC in serial mode
|
||||
i2s@<addr> sound mpc5200-psc-i2s PSC in i2s mode
|
||||
ac97@<addr> sound mpc5200-psc-ac97 PSC in ac97 mode
|
||||
spi@<addr> spi mpc5200-psc-spi PSC in spi mode
|
||||
irda@<addr> irda mpc5200-psc-irda PSC in IrDA mode
|
||||
spi@<addr> spi mpc5200-spi MPC5200 spi device
|
||||
ethernet@<addr> network mpc5200-fec MPC5200 ethernet device
|
||||
ata@<addr> ata mpc5200-ata IDE ATA interface
|
||||
i2c@<addr> i2c mpc5200-i2c I2C controller
|
||||
usb@<addr> usb-ohci-be mpc5200-ohci,ohci-be USB controller
|
||||
xlb@<addr> xlb mpc5200-xlb XLB arbitrator
|
||||
|
||||
Important child node properties
|
||||
name type description
|
||||
---- ---- -----------
|
||||
cell-index int When multiple devices are present, is the
|
||||
index of the device in the hardware (ie. There
|
||||
are 6 PSC on the 5200 numbered PSC1 to PSC6)
|
||||
PSC1 has 'cell-index = <0>'
|
||||
PSC4 has 'cell-index = <3>'
|
||||
|
||||
5) General Purpose Timer nodes (child of soc5200 node)
|
||||
On the mpc5200 and 5200b, GPT0 has a watchdog timer function. If the board
|
||||
design supports the internal wdt, then the device node for GPT0 should
|
||||
include the empty property 'fsl,has-wdt'.
|
||||
|
||||
6) PSC nodes (child of soc5200 node)
|
||||
PSC nodes can define the optional 'port-number' property to force assignment
|
||||
order of serial ports. For example, PSC5 might be physically connected to
|
||||
the port labeled 'COM1' and PSC1 wired to 'COM1'. In this case, PSC5 would
|
||||
have a "port-number = <0>" property, and PSC1 would have "port-number = <1>".
|
||||
|
||||
PSC in i2s mode: The mpc5200 and mpc5200b PSCs are not compatible when in
|
||||
i2s mode. An 'mpc5200b-psc-i2s' node cannot include 'mpc5200-psc-i2s' in the
|
||||
compatible field.
|
||||
|
||||
7) GPIO controller nodes
|
||||
Each GPIO controller node should have the empty property gpio-controller and
|
||||
#gpio-cells set to 2. First cell is the GPIO number which is interpreted
|
||||
according to the bit numbers in the GPIO control registers. The second cell
|
||||
is for flags which is currently unsused.
|
||||
|
||||
8) FEC nodes
|
||||
The FEC node can specify one of the following properties to configure
|
||||
the MII link:
|
||||
"fsl,7-wire-mode" - An empty property that specifies the link uses 7-wire
|
||||
mode instead of MII
|
||||
"current-speed" - Specifies that the MII should be configured for a fixed
|
||||
speed. This property should contain two cells. The
|
||||
first cell specifies the speed in Mbps and the second
|
||||
should be '0' for half duplex and '1' for full duplex
|
||||
"phy-handle" - Contains a phandle to an Ethernet PHY.
|
||||
|
||||
IV - Extra Notes
|
||||
================
|
||||
|
||||
1. Interrupt mapping
|
||||
--------------------
|
||||
The mpc5200 pic driver splits hardware IRQ numbers into two levels. The
|
||||
split reflects the layout of the PIC hardware itself, which groups
|
||||
interrupts into one of three groups; CRIT, MAIN or PERP. Also, the
|
||||
Bestcomm dma engine has it's own set of interrupt sources which are
|
||||
cascaded off of peripheral interrupt 0, which the driver interprets as a
|
||||
fourth group, SDMA.
|
||||
|
||||
The interrupts property for device nodes using the mpc5200 pic consists
|
||||
of three cells; <L1 L2 level>
|
||||
|
||||
L1 := [CRIT=0, MAIN=1, PERP=2, SDMA=3]
|
||||
L2 := interrupt number; directly mapped from the value in the
|
||||
"ICTL PerStat, MainStat, CritStat Encoded Register"
|
||||
level := [LEVEL_HIGH=0, EDGE_RISING=1, EDGE_FALLING=2, LEVEL_LOW=3]
|
||||
|
||||
2. Shared registers
|
||||
-------------------
|
||||
Some SoC devices share registers between them. ie. the i2c devices use
|
||||
a single clock control register, and almost all device are affected by
|
||||
the port_config register. Devices which need to manipulate shared regs
|
||||
should look to the parent SoC node. The soc node is responsible
|
||||
for arbitrating all shared register access.
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user