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 commit 'v2.6.29-rc4' into core/percpu
Conflicts: arch/x86/mach-voyager/voyager_smp.c arch/x86/mm/fault.c
This commit is contained in:
Ingo Molnar
@@ -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>
|
||||
|
||||
@@ -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
|
||||
@@ -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.
|
||||
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -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.
|
||||
@@ -4,12 +4,21 @@
|
||||
*
|
||||
* Compile with:
|
||||
* gcc -s -Wall -Wstrict-prototypes v4lgrab.c -o v4lgrab
|
||||
* Use as:
|
||||
* v4lgrab >image.ppm
|
||||
* Use as:
|
||||
* v4lgrab >image.ppm
|
||||
*
|
||||
* Copyright (C) 1998-05-03, Phil Blundell <philb@gnu.org>
|
||||
* Copied from http://www.tazenda.demon.co.uk/phil/vgrabber.c
|
||||
* with minor modifications (Dave Forrest, drf5n@virginia.edu).
|
||||
* Copied from http://www.tazenda.demon.co.uk/phil/vgrabber.c
|
||||
* with minor modifications (Dave Forrest, drf5n@virginia.edu).
|
||||
*
|
||||
*
|
||||
* For some cameras you may need to pre-load libv4l to perform
|
||||
* the necessary decompression, e.g.:
|
||||
*
|
||||
* export LD_PRELOAD=/usr/lib/libv4l/v4l1compat.so
|
||||
* ./v4lgrab >image.ppm
|
||||
*
|
||||
* see http://hansdegoede.livejournal.com/3636.html for details.
|
||||
*
|
||||
*/
|
||||
|
||||
@@ -24,7 +33,7 @@
|
||||
#include <linux/types.h>
|
||||
#include <linux/videodev.h>
|
||||
|
||||
#define FILE "/dev/video0"
|
||||
#define VIDEO_DEV "/dev/video0"
|
||||
|
||||
/* Stole this from tvset.c */
|
||||
|
||||
@@ -90,7 +99,7 @@ int get_brightness_adj(unsigned char *image, long size, int *brightness) {
|
||||
|
||||
int main(int argc, char ** argv)
|
||||
{
|
||||
int fd = open(FILE, O_RDONLY), f;
|
||||
int fd = open(VIDEO_DEV, O_RDONLY), f;
|
||||
struct video_capability cap;
|
||||
struct video_window win;
|
||||
struct video_picture vpic;
|
||||
@@ -100,13 +109,13 @@ int main(int argc, char ** argv)
|
||||
unsigned int i, src_depth;
|
||||
|
||||
if (fd < 0) {
|
||||
perror(FILE);
|
||||
perror(VIDEO_DEV);
|
||||
exit(1);
|
||||
}
|
||||
|
||||
if (ioctl(fd, VIDIOCGCAP, &cap) < 0) {
|
||||
perror("VIDIOGCAP");
|
||||
fprintf(stderr, "(" FILE " not a video4linux device?)\n");
|
||||
fprintf(stderr, "(" VIDEO_DEV " not a video4linux device?)\n");
|
||||
close(fd);
|
||||
exit(1);
|
||||
}
|
||||
|
||||
+11
-2
@@ -911,7 +911,7 @@ S: Maintained
|
||||
BLACKFIN ARCHITECTURE
|
||||
P: Bryan Wu
|
||||
M: cooloney@kernel.org
|
||||
L: uclinux-dist-devel@blackfin.uclinux.org (subscribers-only)
|
||||
L: uclinux-dist-devel@blackfin.uclinux.org
|
||||
W: http://blackfin.uclinux.org
|
||||
S: Supported
|
||||
|
||||
@@ -1021,6 +1021,14 @@ M: mb@bu3sch.de
|
||||
W: http://bu3sch.de/btgpio.php
|
||||
S: Maintained
|
||||
|
||||
BTRFS FILE SYSTEM
|
||||
P: Chris Mason
|
||||
M: chris.mason@oracle.com
|
||||
L: linux-btrfs@vger.kernel.org
|
||||
W: http://btrfs.wiki.kernel.org/
|
||||
T: git kernel.org:/pub/scm/linux/kernel/git/mason/btrfs-unstable.git
|
||||
S: Maintained
|
||||
|
||||
BTTV VIDEO4LINUX DRIVER
|
||||
P: Mauro Carvalho Chehab
|
||||
M: mchehab@infradead.org
|
||||
@@ -2212,7 +2220,7 @@ P: Sean Hefty
|
||||
M: sean.hefty@intel.com
|
||||
P: Hal Rosenstock
|
||||
M: hal.rosenstock@gmail.com
|
||||
L: general@lists.openfabrics.org
|
||||
L: general@lists.openfabrics.org (moderated for non-subscribers)
|
||||
W: http://www.openib.org/
|
||||
T: git kernel.org:/pub/scm/linux/kernel/git/roland/infiniband.git
|
||||
S: Supported
|
||||
@@ -4841,6 +4849,7 @@ P: Ingo Molnar
|
||||
M: mingo@redhat.com
|
||||
P: H. Peter Anvin
|
||||
M: hpa@zytor.com
|
||||
M: x86@kernel.org
|
||||
L: linux-kernel@vger.kernel.org
|
||||
T: git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-x86.git
|
||||
S: Maintained
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
VERSION = 2
|
||||
PATCHLEVEL = 6
|
||||
SUBLEVEL = 29
|
||||
EXTRAVERSION = -rc3
|
||||
EXTRAVERSION = -rc4
|
||||
NAME = Erotic Pickled Herring
|
||||
|
||||
# *DOCUMENTATION*
|
||||
|
||||
@@ -8,12 +8,12 @@
|
||||
|
||||
/* ??? Would be nice to use .gprel32 here, but we can't be sure that the
|
||||
function loaded the GP, so this could fail in modules. */
|
||||
#define BUG() { \
|
||||
#define BUG() do { \
|
||||
__asm__ __volatile__( \
|
||||
"call_pal %0 # bugchk\n\t" \
|
||||
".long %1\n\t.8byte %2" \
|
||||
: : "i"(PAL_bugchk), "i"(__LINE__), "i"(__FILE__)); \
|
||||
for ( ; ; ); }
|
||||
for ( ; ; ); } while (0)
|
||||
|
||||
#define HAVE_ARCH_BUG
|
||||
#endif
|
||||
|
||||
@@ -650,6 +650,7 @@ ENTRY(fp_enter)
|
||||
no_fp: mov pc, lr
|
||||
|
||||
__und_usr_unknown:
|
||||
enable_irq
|
||||
mov r0, sp
|
||||
adr lr, ret_from_exception
|
||||
b do_undefinstr
|
||||
|
||||
@@ -136,7 +136,7 @@ ENTRY(mcount)
|
||||
ldmia sp!, {r0-r3, pc}
|
||||
|
||||
trace:
|
||||
ldr r1, [fp, #-4]
|
||||
ldr r1, [fp, #-4] @ lr of instrumented routine
|
||||
mov r0, lr
|
||||
sub r0, r0, #MCOUNT_INSN_SIZE
|
||||
mov lr, pc
|
||||
|
||||
@@ -101,7 +101,7 @@ unlock:
|
||||
/* Handle bad interrupts */
|
||||
static struct irq_desc bad_irq_desc = {
|
||||
.handle_irq = handle_bad_irq,
|
||||
.lock = SPIN_LOCK_UNLOCKED
|
||||
.lock = __SPIN_LOCK_UNLOCKED(bad_irq_desc.lock),
|
||||
};
|
||||
|
||||
#ifdef CONFIG_CPUMASK_OFFSTACK
|
||||
|
||||
@@ -27,6 +27,7 @@
|
||||
#include <asm/mach/map.h>
|
||||
#include <asm/mach/flash.h>
|
||||
|
||||
#include <mach/irqs.h>
|
||||
#include <mach/board.h>
|
||||
#include <mach/msm_iomap.h>
|
||||
|
||||
|
||||
@@ -181,7 +181,7 @@ void __init omap1_init_mmc(struct omap_mmc_platform_data **mmc_data,
|
||||
}
|
||||
size = OMAP1_MMC_SIZE;
|
||||
|
||||
omap_mmc_add(i, base, size, irq, mmc_data[i]);
|
||||
omap_mmc_add("mmci-omap", i, base, size, irq, mmc_data[i]);
|
||||
};
|
||||
}
|
||||
|
||||
|
||||
+10
-88
@@ -28,81 +28,8 @@
|
||||
#define DPS_RSTCT2_PER_EN (1 << 0)
|
||||
#define DSP_RSTCT2_WD_PER_EN (1 << 1)
|
||||
|
||||
struct mcbsp_internal_clk {
|
||||
struct clk clk;
|
||||
struct clk **childs;
|
||||
int n_childs;
|
||||
};
|
||||
|
||||
#if defined(CONFIG_ARCH_OMAP15XX) || defined(CONFIG_ARCH_OMAP16XX)
|
||||
static void omap_mcbsp_clk_init(struct mcbsp_internal_clk *mclk)
|
||||
{
|
||||
const char *clk_names[] = { "dsp_ck", "api_ck", "dspxor_ck" };
|
||||
int i;
|
||||
|
||||
mclk->n_childs = ARRAY_SIZE(clk_names);
|
||||
mclk->childs = kzalloc(mclk->n_childs * sizeof(struct clk *),
|
||||
GFP_KERNEL);
|
||||
|
||||
for (i = 0; i < mclk->n_childs; i++) {
|
||||
/* We fake a platform device to get correct device id */
|
||||
struct platform_device pdev;
|
||||
|
||||
pdev.dev.bus = &platform_bus_type;
|
||||
pdev.id = mclk->clk.id;
|
||||
mclk->childs[i] = clk_get(&pdev.dev, clk_names[i]);
|
||||
if (IS_ERR(mclk->childs[i]))
|
||||
printk(KERN_ERR "Could not get clock %s (%d).\n",
|
||||
clk_names[i], mclk->clk.id);
|
||||
}
|
||||
}
|
||||
|
||||
static int omap_mcbsp_clk_enable(struct clk *clk)
|
||||
{
|
||||
struct mcbsp_internal_clk *mclk = container_of(clk,
|
||||
struct mcbsp_internal_clk, clk);
|
||||
int i;
|
||||
|
||||
for (i = 0; i < mclk->n_childs; i++)
|
||||
clk_enable(mclk->childs[i]);
|
||||
return 0;
|
||||
}
|
||||
|
||||
static void omap_mcbsp_clk_disable(struct clk *clk)
|
||||
{
|
||||
struct mcbsp_internal_clk *mclk = container_of(clk,
|
||||
struct mcbsp_internal_clk, clk);
|
||||
int i;
|
||||
|
||||
for (i = 0; i < mclk->n_childs; i++)
|
||||
clk_disable(mclk->childs[i]);
|
||||
}
|
||||
|
||||
static struct mcbsp_internal_clk omap_mcbsp_clks[] = {
|
||||
{
|
||||
.clk = {
|
||||
.name = "mcbsp_clk",
|
||||
.id = 1,
|
||||
.enable = omap_mcbsp_clk_enable,
|
||||
.disable = omap_mcbsp_clk_disable,
|
||||
},
|
||||
},
|
||||
{
|
||||
.clk = {
|
||||
.name = "mcbsp_clk",
|
||||
.id = 3,
|
||||
.enable = omap_mcbsp_clk_enable,
|
||||
.disable = omap_mcbsp_clk_disable,
|
||||
},
|
||||
},
|
||||
};
|
||||
|
||||
#define omap_mcbsp_clks_size ARRAY_SIZE(omap_mcbsp_clks)
|
||||
#else
|
||||
#define omap_mcbsp_clks_size 0
|
||||
static struct mcbsp_internal_clk __initdata *omap_mcbsp_clks;
|
||||
static inline void omap_mcbsp_clk_init(struct mcbsp_internal_clk *mclk)
|
||||
{ }
|
||||
const char *clk_names[] = { "dsp_ck", "api_ck", "dspxor_ck" };
|
||||
#endif
|
||||
|
||||
static void omap1_mcbsp_request(unsigned int id)
|
||||
@@ -167,8 +94,9 @@ static struct omap_mcbsp_platform_data omap15xx_mcbsp_pdata[] = {
|
||||
.rx_irq = INT_McBSP1RX,
|
||||
.tx_irq = INT_McBSP1TX,
|
||||
.ops = &omap1_mcbsp_ops,
|
||||
.clk_name = "mcbsp_clk",
|
||||
},
|
||||
.clk_names = clk_names,
|
||||
.num_clks = 3,
|
||||
},
|
||||
{
|
||||
.phys_base = OMAP1510_MCBSP2_BASE,
|
||||
.dma_rx_sync = OMAP_DMA_MCBSP2_RX,
|
||||
@@ -184,7 +112,8 @@ static struct omap_mcbsp_platform_data omap15xx_mcbsp_pdata[] = {
|
||||
.rx_irq = INT_McBSP3RX,
|
||||
.tx_irq = INT_McBSP3TX,
|
||||
.ops = &omap1_mcbsp_ops,
|
||||
.clk_name = "mcbsp_clk",
|
||||
.clk_names = clk_names,
|
||||
.num_clks = 3,
|
||||
},
|
||||
};
|
||||
#define OMAP15XX_MCBSP_PDATA_SZ ARRAY_SIZE(omap15xx_mcbsp_pdata)
|
||||
@@ -202,7 +131,8 @@ static struct omap_mcbsp_platform_data omap16xx_mcbsp_pdata[] = {
|
||||
.rx_irq = INT_McBSP1RX,
|
||||
.tx_irq = INT_McBSP1TX,
|
||||
.ops = &omap1_mcbsp_ops,
|
||||
.clk_name = "mcbsp_clk",
|
||||
.clk_names = clk_names,
|
||||
.num_clks = 3,
|
||||
},
|
||||
{
|
||||
.phys_base = OMAP1610_MCBSP2_BASE,
|
||||
@@ -219,7 +149,8 @@ static struct omap_mcbsp_platform_data omap16xx_mcbsp_pdata[] = {
|
||||
.rx_irq = INT_McBSP3RX,
|
||||
.tx_irq = INT_McBSP3TX,
|
||||
.ops = &omap1_mcbsp_ops,
|
||||
.clk_name = "mcbsp_clk",
|
||||
.clk_names = clk_names,
|
||||
.num_clks = 3,
|
||||
},
|
||||
};
|
||||
#define OMAP16XX_MCBSP_PDATA_SZ ARRAY_SIZE(omap16xx_mcbsp_pdata)
|
||||
@@ -230,15 +161,6 @@ static struct omap_mcbsp_platform_data omap16xx_mcbsp_pdata[] = {
|
||||
|
||||
int __init omap1_mcbsp_init(void)
|
||||
{
|
||||
int i;
|
||||
|
||||
for (i = 0; i < omap_mcbsp_clks_size; i++) {
|
||||
if (cpu_is_omap15xx() || cpu_is_omap16xx()) {
|
||||
omap_mcbsp_clk_init(&omap_mcbsp_clks[i]);
|
||||
clk_register(&omap_mcbsp_clks[i].clk);
|
||||
}
|
||||
}
|
||||
|
||||
if (cpu_is_omap730())
|
||||
omap_mcbsp_count = OMAP730_MCBSP_PDATA_SZ;
|
||||
if (cpu_is_omap15xx())
|
||||
|
||||
@@ -421,6 +421,7 @@ void __init omap2_init_mmc(struct omap_mmc_platform_data **mmc_data,
|
||||
int nr_controllers)
|
||||
{
|
||||
int i;
|
||||
char *name;
|
||||
|
||||
for (i = 0; i < nr_controllers; i++) {
|
||||
unsigned long base, size;
|
||||
@@ -450,12 +451,14 @@ void __init omap2_init_mmc(struct omap_mmc_platform_data **mmc_data,
|
||||
continue;
|
||||
}
|
||||
|
||||
if (cpu_is_omap2420())
|
||||
if (cpu_is_omap2420()) {
|
||||
size = OMAP2420_MMC_SIZE;
|
||||
else
|
||||
name = "mmci-omap";
|
||||
} else {
|
||||
size = HSMMC_SIZE;
|
||||
|
||||
omap_mmc_add(i, base, size, irq, mmc_data[i]);
|
||||
name = "mmci-omap-hs";
|
||||
}
|
||||
omap_mmc_add(name, i, base, size, irq, mmc_data[i]);
|
||||
};
|
||||
}
|
||||
|
||||
|
||||
@@ -172,9 +172,13 @@ void __init omap34xx_check_revision(void)
|
||||
omap_revision = OMAP3430_REV_ES3_0;
|
||||
rev_name = "ES3.0";
|
||||
break;
|
||||
case 4:
|
||||
omap_revision = OMAP3430_REV_ES3_1;
|
||||
rev_name = "ES3.1";
|
||||
break;
|
||||
default:
|
||||
/* Use the latest known revision as default */
|
||||
omap_revision = OMAP3430_REV_ES3_0;
|
||||
omap_revision = OMAP3430_REV_ES3_1;
|
||||
rev_name = "Unknown revision\n";
|
||||
}
|
||||
}
|
||||
|
||||
@@ -134,6 +134,7 @@ static struct irq_chip omap_irq_chip = {
|
||||
.ack = omap_mask_ack_irq,
|
||||
.mask = omap_mask_irq,
|
||||
.unmask = omap_unmask_irq,
|
||||
.disable = omap_mask_irq,
|
||||
};
|
||||
|
||||
static void __init omap_irq_bank_init_one(struct omap_irq_bank *bank)
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user