aboutsummaryrefslogtreecommitdiffstats
path: root/Documentation
diff options
context:
space:
mode:
Diffstat (limited to 'Documentation')
-rw-r--r--Documentation/block/data-integrity.txt4
-rw-r--r--Documentation/cgroups/cpusets.txt12
-rw-r--r--Documentation/driver-model/driver.txt4
-rw-r--r--Documentation/dvb/get_dvb_firmware53
-rw-r--r--Documentation/feature-removal-schedule.txt10
-rw-r--r--Documentation/gcov.txt25
-rw-r--r--Documentation/kernel-parameters.txt13
-rw-r--r--Documentation/kmemleak.txt23
-rw-r--r--Documentation/leds-lp3944.txt50
-rw-r--r--Documentation/powerpc/booting-without-of.txt1168
-rw-r--r--Documentation/powerpc/dts-bindings/4xx/emac.txt148
-rw-r--r--Documentation/powerpc/dts-bindings/gpio/gpio.txt50
-rw-r--r--Documentation/powerpc/dts-bindings/gpio/led.txt17
-rw-r--r--Documentation/powerpc/dts-bindings/gpio/mdio.txt19
-rw-r--r--Documentation/powerpc/dts-bindings/marvell.txt521
-rw-r--r--Documentation/powerpc/dts-bindings/phy.txt25
-rw-r--r--Documentation/powerpc/dts-bindings/spi-bus.txt57
-rw-r--r--Documentation/powerpc/dts-bindings/usb-ehci.txt25
-rw-r--r--Documentation/powerpc/dts-bindings/xilinx.txt295
-rw-r--r--Documentation/scheduler/sched-rt-group.txt13
-rw-r--r--Documentation/sound/alsa/HD-Audio-Models.txt1
-rw-r--r--Documentation/spi/spidev_test.c10
-rw-r--r--Documentation/video4linux/CARDLIST.em28xx1
-rw-r--r--Documentation/x86/00-INDEX2
-rw-r--r--Documentation/x86/exception-tables.txt (renamed from Documentation/exception.txt)202
25 files changed, 1449 insertions, 1299 deletions
diff --git a/Documentation/block/data-integrity.txt b/Documentation/block/data-integrity.txt
index e8ca040ba2cf..2d735b0ae383 100644
--- a/Documentation/block/data-integrity.txt
+++ b/Documentation/block/data-integrity.txt
@@ -50,7 +50,7 @@ encouraged them to allow separation of the data and integrity metadata
50scatter-gather lists. 50scatter-gather lists.
51 51
52The controller will interleave the buffers on write and split them on 52The controller will interleave the buffers on write and split them on
53read. This means that the Linux can DMA the data buffers to and from 53read. This means that Linux can DMA the data buffers to and from
54host memory without changes to the page cache. 54host memory without changes to the page cache.
55 55
56Also, the 16-bit CRC checksum mandated by both the SCSI and SATA specs 56Also, the 16-bit CRC checksum mandated by both the SCSI and SATA specs
@@ -66,7 +66,7 @@ software RAID5).
66 66
67The IP checksum is weaker than the CRC in terms of detecting bit 67The IP checksum is weaker than the CRC in terms of detecting bit
68errors. However, the strength is really in the separation of the data 68errors. However, the strength is really in the separation of the data
69buffers and the integrity metadata. These two distinct buffers much 69buffers and the integrity metadata. These two distinct buffers must
70match up for an I/O to complete. 70match up for an I/O to complete.
71 71
72The separation of the data and integrity metadata buffers as well as 72The separation of the data and integrity metadata buffers as well as
diff --git a/Documentation/cgroups/cpusets.txt b/Documentation/cgroups/cpusets.txt
index f9ca389dddf4..1d7e9784439a 100644
--- a/Documentation/cgroups/cpusets.txt
+++ b/Documentation/cgroups/cpusets.txt
@@ -777,6 +777,18 @@ in cpuset directories:
777# /bin/echo 1-4 > cpus -> set cpus list to cpus 1,2,3,4 777# /bin/echo 1-4 > cpus -> set cpus list to cpus 1,2,3,4
778# /bin/echo 1,2,3,4 > cpus -> set cpus list to cpus 1,2,3,4 778# /bin/echo 1,2,3,4 > cpus -> set cpus list to cpus 1,2,3,4
779 779
780To add a CPU to a cpuset, write the new list of CPUs including the
781CPU to be added. To add 6 to the above cpuset:
782
783# /bin/echo 1-4,6 > cpus -> set cpus list to cpus 1,2,3,4,6
784
785Similarly to remove a CPU from a cpuset, write the new list of CPUs
786without the CPU to be removed.
787
788To remove all the CPUs:
789
790# /bin/echo "" > cpus -> clear cpus list
791
7802.3 Setting flags 7922.3 Setting flags
781----------------- 793-----------------
782 794
diff --git a/Documentation/driver-model/driver.txt b/Documentation/driver-model/driver.txt
index 82132169d47a..60120fb3b961 100644
--- a/Documentation/driver-model/driver.txt
+++ b/Documentation/driver-model/driver.txt
@@ -207,8 +207,8 @@ Attributes
207~~~~~~~~~~ 207~~~~~~~~~~
208struct driver_attribute { 208struct driver_attribute {
209 struct attribute attr; 209 struct attribute attr;
210 ssize_t (*show)(struct device_driver *, char * buf, size_t count, loff_t off); 210 ssize_t (*show)(struct device_driver *driver, char *buf);
211 ssize_t (*store)(struct device_driver *, const char * buf, size_t count, loff_t off); 211 ssize_t (*store)(struct device_driver *, const char * buf, size_t count);
212}; 212};
213 213
214Device drivers can export attributes via their sysfs directories. 214Device drivers can export attributes via their sysfs directories.
diff --git a/Documentation/dvb/get_dvb_firmware b/Documentation/dvb/get_dvb_firmware
index a52adfc9a57f..3d1b0ab70c8e 100644
--- a/Documentation/dvb/get_dvb_firmware
+++ b/Documentation/dvb/get_dvb_firmware
@@ -25,7 +25,7 @@ use IO::Handle;
25 "tda10046lifeview", "av7110", "dec2000t", "dec2540t", 25 "tda10046lifeview", "av7110", "dec2000t", "dec2540t",
26 "dec3000s", "vp7041", "dibusb", "nxt2002", "nxt2004", 26 "dec3000s", "vp7041", "dibusb", "nxt2002", "nxt2004",
27 "or51211", "or51132_qam", "or51132_vsb", "bluebird", 27 "or51211", "or51132_qam", "or51132_vsb", "bluebird",
28 "opera1", "cx231xx", "cx18", "cx23885", "pvrusb2" ); 28 "opera1", "cx231xx", "cx18", "cx23885", "pvrusb2", "mpc718" );
29 29
30# Check args 30# Check args
31syntax() if (scalar(@ARGV) != 1); 31syntax() if (scalar(@ARGV) != 1);
@@ -381,6 +381,57 @@ sub cx18 {
381 $allfiles; 381 $allfiles;
382} 382}
383 383
384sub mpc718 {
385 my $archive = 'Yuan MPC718 TV Tuner Card 2.13.10.1016.zip';
386 my $url = "ftp://ftp.work.acer-euro.com/desktop/aspire_idea510/vista/Drivers/$archive";
387 my $fwfile = "dvb-cx18-mpc718-mt352.fw";
388 my $tmpdir = tempdir(DIR => "/tmp", CLEANUP => 1);
389
390 checkstandard();
391 wgetfile($archive, $url);
392 unzip($archive, $tmpdir);
393
394 my $sourcefile = "$tmpdir/Yuan MPC718 TV Tuner Card 2.13.10.1016/mpc718_32bit/yuanrap.sys";
395 my $found = 0;
396
397 open IN, '<', $sourcefile or die "Couldn't open $sourcefile to extract $fwfile data\n";
398 binmode IN;
399 open OUT, '>', $fwfile;
400 binmode OUT;
401 {
402 # Block scope because we change the line terminator variable $/
403 my $prevlen = 0;
404 my $currlen;
405
406 # Buried in the data segment are 3 runs of almost identical
407 # register-value pairs that end in 0x5d 0x01 which is a "TUNER GO"
408 # command for the MT352.
409 # Pull out the middle run (because it's easy) of register-value
410 # pairs to make the "firmware" file.
411
412 local $/ = "\x5d\x01"; # MT352 "TUNER GO"
413
414 while (<IN>) {
415 $currlen = length($_);
416 if ($prevlen == $currlen && $currlen <= 64) {
417 chop; chop; # Get rid of "TUNER GO"
418 s/^\0\0//; # get rid of leading 00 00 if it's there
419 printf OUT "$_";
420 $found = 1;
421 last;
422 }
423 $prevlen = $currlen;
424 }
425 }
426 close OUT;
427 close IN;
428 if (!$found) {
429 unlink $fwfile;
430 die "Couldn't find valid register-value sequence in $sourcefile for $fwfile\n";
431 }
432 $fwfile;
433}
434
384sub cx23885 { 435sub cx23885 {
385 my $url = "http://linuxtv.org/downloads/firmware/"; 436 my $url = "http://linuxtv.org/downloads/firmware/";
386 437
diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt
index f8cd450be9aa..09e031c55887 100644
--- a/Documentation/feature-removal-schedule.txt
+++ b/Documentation/feature-removal-schedule.txt
@@ -458,3 +458,13 @@ Why: Remove the old legacy 32bit machine check code. This has been
458 but the old version has been kept around for easier testing. Note this 458 but the old version has been kept around for easier testing. Note this
459 doesn't impact the old P5 and WinChip machine check handlers. 459 doesn't impact the old P5 and WinChip machine check handlers.
460Who: Andi Kleen <andi@firstfloor.org> 460Who: Andi Kleen <andi@firstfloor.org>
461
462----------------------------
463
464What: lock_policy_rwsem_* and unlock_policy_rwsem_* will not be
465 exported interface anymore.
466When: 2.6.33
467Why: cpu_policy_rwsem has a new cleaner definition making it local to
468 cpufreq core and contained inside cpufreq.c. Other dependent
469 drivers should not use it in order to safely avoid lockdep issues.
470Who: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
diff --git a/Documentation/gcov.txt b/Documentation/gcov.txt
index e716aadb3a33..40ec63352760 100644
--- a/Documentation/gcov.txt
+++ b/Documentation/gcov.txt
@@ -188,13 +188,18 @@ Solution: Exclude affected source files from profiling by specifying
188 GCOV_PROFILE := n or GCOV_PROFILE_basename.o := n in the 188 GCOV_PROFILE := n or GCOV_PROFILE_basename.o := n in the
189 corresponding Makefile. 189 corresponding Makefile.
190 190
191Problem: Files copied from sysfs appear empty or incomplete.
192Cause: Due to the way seq_file works, some tools such as cp or tar
193 may not correctly copy files from sysfs.
194Solution: Use 'cat' to read .gcda files and 'cp -d' to copy links.
195 Alternatively use the mechanism shown in Appendix B.
196
191 197
192Appendix A: gather_on_build.sh 198Appendix A: gather_on_build.sh
193============================== 199==============================
194 200
195Sample script to gather coverage meta files on the build machine 201Sample script to gather coverage meta files on the build machine
196(see 6a): 202(see 6a):
197
198#!/bin/bash 203#!/bin/bash
199 204
200KSRC=$1 205KSRC=$1
@@ -226,7 +231,7 @@ Appendix B: gather_on_test.sh
226Sample script to gather coverage data files on the test machine 231Sample script to gather coverage data files on the test machine
227(see 6b): 232(see 6b):
228 233
229#!/bin/bash 234#!/bin/bash -e
230 235
231DEST=$1 236DEST=$1
232GCDA=/sys/kernel/debug/gcov 237GCDA=/sys/kernel/debug/gcov
@@ -236,11 +241,13 @@ if [ -z "$DEST" ] ; then
236 exit 1 241 exit 1
237fi 242fi
238 243
239find $GCDA -name '*.gcno' -o -name '*.gcda' | tar cfz $DEST -T - 244TEMPDIR=$(mktemp -d)
245echo Collecting data..
246find $GCDA -type d -exec mkdir -p $TEMPDIR/\{\} \;
247find $GCDA -name '*.gcda' -exec sh -c 'cat < $0 > '$TEMPDIR'/$0' {} \;
248find $GCDA -name '*.gcno' -exec sh -c 'cp -d $0 '$TEMPDIR'/$0' {} \;
249tar czf $DEST -C $TEMPDIR sys
250rm -rf $TEMPDIR
240 251
241if [ $? -eq 0 ] ; then 252echo "$DEST successfully created, copy to build system and unpack with:"
242 echo "$DEST successfully created, copy to build system and unpack with:" 253echo " tar xfz $DEST"
243 echo " tar xfz $DEST"
244else
245 echo "Could not create file $DEST"
246fi
diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
index d08759aa0903..dd1a6d4bb747 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -1720,8 +1720,8 @@ and is between 256 and 4096 characters. It is defined in the file
1720 oprofile.cpu_type= Force an oprofile cpu type 1720 oprofile.cpu_type= Force an oprofile cpu type
1721 This might be useful if you have an older oprofile 1721 This might be useful if you have an older oprofile
1722 userland or if you want common events. 1722 userland or if you want common events.
1723 Format: { archperfmon } 1723 Format: { arch_perfmon }
1724 archperfmon: [X86] Force use of architectural 1724 arch_perfmon: [X86] Force use of architectural
1725 perfmon on Intel CPUs instead of the 1725 perfmon on Intel CPUs instead of the
1726 CPU specific event set. 1726 CPU specific event set.
1727 1727
@@ -1915,6 +1915,12 @@ and is between 256 and 4096 characters. It is defined in the file
1915 Format: { 0 | 1 } 1915 Format: { 0 | 1 }
1916 See arch/parisc/kernel/pdc_chassis.c 1916 See arch/parisc/kernel/pdc_chassis.c
1917 1917
1918 percpu_alloc= [X86] Select which percpu first chunk allocator to use.
1919 Allowed values are one of "lpage", "embed" and "4k".
1920 See comments in arch/x86/kernel/setup_percpu.c for
1921 details on each allocator. This parameter is primarily
1922 for debugging and performance comparison.
1923
1918 pf. [PARIDE] 1924 pf. [PARIDE]
1919 See Documentation/blockdev/paride.txt. 1925 See Documentation/blockdev/paride.txt.
1920 1926
@@ -2467,7 +2473,8 @@ and is between 256 and 4096 characters. It is defined in the file
2467 2473
2468 tp720= [HW,PS2] 2474 tp720= [HW,PS2]
2469 2475
2470 trace_buf_size=nn[KMG] [ftrace] will set tracing buffer size. 2476 trace_buf_size=nn[KMG]
2477 [FTRACE] will set tracing buffer size.
2471 2478
2472 trix= [HW,OSS] MediaTrix AudioTrix Pro 2479 trix= [HW,OSS] MediaTrix AudioTrix Pro
2473 Format: 2480 Format:
diff --git a/Documentation/kmemleak.txt b/Documentation/kmemleak.txt
index 0112da3b9ab8..89068030b01b 100644
--- a/Documentation/kmemleak.txt
+++ b/Documentation/kmemleak.txt
@@ -16,13 +16,17 @@ Usage
16----- 16-----
17 17
18CONFIG_DEBUG_KMEMLEAK in "Kernel hacking" has to be enabled. A kernel 18CONFIG_DEBUG_KMEMLEAK in "Kernel hacking" has to be enabled. A kernel
19thread scans the memory every 10 minutes (by default) and prints any new 19thread scans the memory every 10 minutes (by default) and prints the
20unreferenced objects found. To trigger an intermediate scan and display 20number of new unreferenced objects found. To display the details of all
21all the possible memory leaks: 21the possible memory leaks:
22 22
23 # mount -t debugfs nodev /sys/kernel/debug/ 23 # mount -t debugfs nodev /sys/kernel/debug/
24 # cat /sys/kernel/debug/kmemleak 24 # cat /sys/kernel/debug/kmemleak
25 25
26To trigger an intermediate memory scan:
27
28 # echo scan > /sys/kernel/debug/kmemleak
29
26Note that the orphan objects are listed in the order they were allocated 30Note that the orphan objects are listed in the order they were allocated
27and one object at the beginning of the list may cause other subsequent 31and one object at the beginning of the list may cause other subsequent
28objects to be reported as orphan. 32objects to be reported as orphan.
@@ -31,16 +35,21 @@ Memory scanning parameters can be modified at run-time by writing to the
31/sys/kernel/debug/kmemleak file. The following parameters are supported: 35/sys/kernel/debug/kmemleak file. The following parameters are supported:
32 36
33 off - disable kmemleak (irreversible) 37 off - disable kmemleak (irreversible)
34 stack=on - enable the task stacks scanning 38 stack=on - enable the task stacks scanning (default)
35 stack=off - disable the tasks stacks scanning 39 stack=off - disable the tasks stacks scanning
36 scan=on - start the automatic memory scanning thread 40 scan=on - start the automatic memory scanning thread (default)
37 scan=off - stop the automatic memory scanning thread 41 scan=off - stop the automatic memory scanning thread
38 scan=<secs> - set the automatic memory scanning period in seconds (0 42 scan=<secs> - set the automatic memory scanning period in seconds
39 to disable it) 43 (default 600, 0 to stop the automatic scanning)
44 scan - trigger a memory scan
40 45
41Kmemleak can also be disabled at boot-time by passing "kmemleak=off" on 46Kmemleak can also be disabled at boot-time by passing "kmemleak=off" on
42the kernel command line. 47the kernel command line.
43 48
49Memory may be allocated or freed before kmemleak is initialised and
50these actions are stored in an early log buffer. The size of this buffer
51is configured via the CONFIG_DEBUG_KMEMLEAK_EARLY_LOG_SIZE option.
52
44Basic Algorithm 53Basic Algorithm
45--------------- 54---------------
46 55
diff --git a/Documentation/leds-lp3944.txt b/Documentation/leds-lp3944.txt
new file mode 100644
index 000000000000..c6eda18b15ef
--- /dev/null
+++ b/Documentation/leds-lp3944.txt
@@ -0,0 +1,50 @@
1Kernel driver lp3944
2====================
3
4 * National Semiconductor LP3944 Fun-light Chip
5 Prefix: 'lp3944'
6 Addresses scanned: None (see the Notes section below)
7 Datasheet: Publicly available at the National Semiconductor website
8 http://www.national.com/pf/LP/LP3944.html
9
10Authors:
11 Antonio Ospite <ospite@studenti.unina.it>
12
13
14Description
15-----------
16The LP3944 is a helper chip that can drive up to 8 leds, with two programmable
17DIM modes; it could even be used as a gpio expander but this driver assumes it
18is used as a led controller.
19
20The DIM modes are used to set _blink_ patterns for leds, the pattern is
21specified supplying two parameters:
22 - period: from 0s to 1.6s
23 - duty cycle: percentage of the period the led is on, from 0 to 100
24
25Setting a led in DIM0 or DIM1 mode makes it blink according to the pattern.
26See the datasheet for details.
27
28LP3944 can be found on Motorola A910 smartphone, where it drives the rgb
29leds, the camera flash light and the lcds power.
30
31
32Notes
33-----
34The chip is used mainly in embedded contexts, so this driver expects it is
35registered using the i2c_board_info mechanism.
36
37To register the chip at address 0x60 on adapter 0, set the platform data
38according to include/linux/leds-lp3944.h, set the i2c board info:
39
40 static struct i2c_board_info __initdata a910_i2c_board_info[] = {
41 {
42 I2C_BOARD_INFO("lp3944", 0x60),
43 .platform_data = &a910_lp3944_leds,
44 },
45 };
46
47and register it in the platform init function
48
49 i2c_register_board_info(0, a910_i2c_board_info,
50 ARRAY_SIZE(a910_i2c_board_info));
diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/powerpc/booting-without-of.txt
index 8d999d862d0e..79f533f38c61 100644
--- a/Documentation/powerpc/booting-without-of.txt
+++ b/Documentation/powerpc/booting-without-of.txt
@@ -1238,1122 +1238,7 @@ descriptions for the SOC devices for which new nodes have been
1238defined; this list will expand as more and more SOC-containing 1238defined; this list will expand as more and more SOC-containing
1239platforms are moved over to use the flattened-device-tree model. 1239platforms are moved over to use the flattened-device-tree model.
1240 1240
1241 a) PHY nodes 1241VII - Specifying interrupt information for devices
1242
1243 Required properties:
1244
1245 - device_type : Should be "ethernet-phy"
1246 - interrupts : <a b> where a is the interrupt number and b is a
1247 field that represents an encoding of the sense and level
1248 information for the interrupt. This should be encoded based on
1249 the information in section 2) depending on the type of interrupt
1250 controller you have.
1251 - interrupt-parent : the phandle for the interrupt controller that
1252 services interrupts for this device.
1253 - reg : The ID number for the phy, usually a small integer
1254 - linux,phandle : phandle for this node; likely referenced by an
1255 ethernet controller node.
1256
1257
1258 Example:
1259
1260 ethernet-phy@0 {
1261 linux,phandle = <2452000>
1262 interrupt-parent = <40000>;
1263 interrupts = <35 1>;
1264 reg = <0>;
1265 device_type = "ethernet-phy";
1266 };
1267
1268
1269 b) Interrupt controllers
1270
1271 Some SOC devices contain interrupt controllers that are different
1272 from the standard Open PIC specification. The SOC device nodes for
1273 these types of controllers should be specified just like a standard
1274 OpenPIC controller. Sense and level information should be encoded
1275 as specified in section 2) of this chapter for each device that
1276 specifies an interrupt.
1277
1278 Example :
1279
1280 pic@40000 {
1281 linux,phandle = <40000>;
1282 interrupt-controller;
1283 #address-cells = <0>;
1284 reg = <40000 40000>;
1285 compatible = "chrp,open-pic";
1286 device_type = "open-pic";
1287 };
1288
1289 c) 4xx/Axon EMAC ethernet nodes
1290
1291 The EMAC ethernet controller in IBM and AMCC 4xx chips, and also
1292 the Axon bridge. To operate this needs to interact with a ths
1293 special McMAL DMA controller, and sometimes an RGMII or ZMII
1294 interface. In addition to the nodes and properties described
1295 below, the node for the OPB bus on which the EMAC sits must have a
1296 correct clock-frequency property.
1297
1298 i) The EMAC node itself
1299
1300 Required properties:
1301 - device_type : "network"
1302
1303 - compatible : compatible list, contains 2 entries, first is
1304 "ibm,emac-CHIP" where CHIP is the host ASIC (440gx,
1305 405gp, Axon) and second is either "ibm,emac" or
1306 "ibm,emac4". For Axon, thus, we have: "ibm,emac-axon",
1307 "ibm,emac4"
1308 - interrupts : <interrupt mapping for EMAC IRQ and WOL IRQ>
1309 - interrupt-parent : optional, if needed for interrupt mapping
1310 - reg : <registers mapping>
1311 - local-mac-address : 6 bytes, MAC address
1312 - mal-device : phandle of the associated McMAL node
1313 - mal-tx-channel : 1 cell, index of the tx channel on McMAL associated
1314 with this EMAC
1315 - mal-rx-channel : 1 cell, index of the rx channel on McMAL associated
1316 with this EMAC
1317 - cell-index : 1 cell, hardware index of the EMAC cell on a given
1318 ASIC (typically 0x0 and 0x1 for EMAC0 and EMAC1 on
1319 each Axon chip)
1320 - max-frame-size : 1 cell, maximum frame size supported in bytes
1321 - rx-fifo-size : 1 cell, Rx fifo size in bytes for 10 and 100 Mb/sec
1322 operations.
1323 For Axon, 2048
1324 - tx-fifo-size : 1 cell, Tx fifo size in bytes for 10 and 100 Mb/sec
1325 operations.
1326 For Axon, 2048.
1327 - fifo-entry-size : 1 cell, size of a fifo entry (used to calculate
1328 thresholds).
1329 For Axon, 0x00000010
1330 - mal-burst-size : 1 cell, MAL burst size (used to calculate thresholds)
1331 in bytes.
1332 For Axon, 0x00000100 (I think ...)
1333 - phy-mode : string, mode of operations of the PHY interface.
1334 Supported values are: "mii", "rmii", "smii", "rgmii",
1335 "tbi", "gmii", rtbi", "sgmii".
1336 For Axon on CAB, it is "rgmii"
1337 - mdio-device : 1 cell, required iff using shared MDIO registers
1338 (440EP). phandle of the EMAC to use to drive the
1339 MDIO lines for the PHY used by this EMAC.
1340 - zmii-device : 1 cell, required iff connected to a ZMII. phandle of
1341 the ZMII device node
1342 - zmii-channel : 1 cell, required iff connected to a ZMII. Which ZMII
1343 channel or 0xffffffff if ZMII is only used for MDIO.
1344 - rgmii-device : 1 cell, required iff connected to an RGMII. phandle
1345 of the RGMII device node.
1346 For Axon: phandle of plb5/plb4/opb/rgmii
1347 - rgmii-channel : 1 cell, required iff connected to an RGMII. Which
1348 RGMII channel is used by this EMAC.
1349 Fox Axon: present, whatever value is appropriate for each
1350 EMAC, that is the content of the current (bogus) "phy-port"
1351 property.
1352
1353 Optional properties:
1354 - phy-address : 1 cell, optional, MDIO address of the PHY. If absent,
1355 a search is performed.
1356 - phy-map : 1 cell, optional, bitmap of addresses to probe the PHY
1357 for, used if phy-address is absent. bit 0x00000001 is
1358 MDIO address 0.
1359 For Axon it can be absent, though my current driver
1360 doesn't handle phy-address yet so for now, keep
1361 0x00ffffff in it.
1362 - rx-fifo-size-gige : 1 cell, Rx fifo size in bytes for 1000 Mb/sec
1363 operations (if absent the value is the same as
1364 rx-fifo-size). For Axon, either absent or 2048.
1365 - tx-fifo-size-gige : 1 cell, Tx fifo size in bytes for 1000 Mb/sec
1366 operations (if absent the value is the same as
1367 tx-fifo-size). For Axon, either absent or 2048.
1368 - tah-device : 1 cell, optional. If connected to a TAH engine for
1369 offload, phandle of the TAH device node.
1370 - tah-channel : 1 cell, optional. If appropriate, channel used on the
1371 TAH engine.
1372
1373 Example:
1374
1375 EMAC0: ethernet@40000800 {
1376 device_type = "network";
1377 compatible = "ibm,emac-440gp", "ibm,emac";
1378 interrupt-parent = <&UIC1>;
1379 interrupts = <1c 4 1d 4>;
1380 reg = <40000800 70>;
1381 local-mac-address = [00 04 AC E3 1B 1E];
1382 mal-device = <&MAL0>;
1383 mal-tx-channel = <0 1>;
1384 mal-rx-channel = <0>;
1385 cell-index = <0>;
1386 max-frame-size = <5dc>;
1387 rx-fifo-size = <1000>;
1388 tx-fifo-size = <800>;
1389 phy-mode = "rmii";
1390 phy-map = <00000001>;
1391 zmii-device = <&ZMII0>;
1392 zmii-channel = <0>;
1393 };
1394
1395 ii) McMAL node
1396
1397 Required properties:
1398 - device_type : "dma-controller"
1399 - compatible : compatible list, containing 2 entries, first is
1400 "ibm,mcmal-CHIP" where CHIP is the host ASIC (like
1401 emac) and the second is either "ibm,mcmal" or
1402 "ibm,mcmal2".
1403 For Axon, "ibm,mcmal-axon","ibm,mcmal2"
1404 - interrupts : <interrupt mapping for the MAL interrupts sources:
1405 5 sources: tx_eob, rx_eob, serr, txde, rxde>.
1406 For Axon: This is _different_ from the current
1407 firmware. We use the "delayed" interrupts for txeob
1408 and rxeob. Thus we end up with mapping those 5 MPIC
1409 interrupts, all level positive sensitive: 10, 11, 32,
1410 33, 34 (in decimal)
1411 - dcr-reg : < DCR registers range >
1412 - dcr-parent : if needed for dcr-reg
1413 - num-tx-chans : 1 cell, number of Tx channels
1414 - num-rx-chans : 1 cell, number of Rx channels
1415
1416 iii) ZMII node
1417
1418 Required properties:
1419 - compatible : compatible list, containing 2 entries, first is
1420 "ibm,zmii-CHIP" where CHIP is the host ASIC (like
1421 EMAC) and the second is "ibm,zmii".
1422 For Axon, there is no ZMII node.
1423 - reg : <registers mapping>
1424
1425 iv) RGMII node
1426
1427 Required properties:
1428 - compatible : compatible list, containing 2 entries, first is
1429 "ibm,rgmii-CHIP" where CHIP is the host ASIC (like
1430 EMAC) and the second is "ibm,rgmii".
1431 For Axon, "ibm,rgmii-axon","ibm,rgmii"
1432 - reg : <registers mapping>
1433 - revision : as provided by the RGMII new version register if
1434 available.
1435 For Axon: 0x0000012a
1436
1437 d) Xilinx IP cores
1438
1439 The Xilinx EDK toolchain ships with a set of IP cores (devices) for use
1440 in Xilinx Spartan and Virtex FPGAs. The devices cover the whole range
1441 of standard device types (network, serial, etc.) and miscellaneous
1442 devices (gpio, LCD, spi, etc). Also, since these devices are
1443 implemented within the fpga fabric every instance of the device can be
1444 synthesised with different options that change the behaviour.
1445
1446 Each IP-core has a set of parameters which the FPGA designer can use to
1447 control how the core is synthesized. Historically, the EDK tool would
1448 extract the device parameters relevant to device drivers and copy them
1449 into an 'xparameters.h' in the form of #define symbols. This tells the
1450 device drivers how the IP cores are configured, but it requres the kernel
1451 to be recompiled every time the FPGA bitstream is resynthesized.
1452
1453 The new approach is to export the parameters into the device tree and
1454 generate a new device tree each time the FPGA bitstream changes. The
1455 parameters which used to be exported as #defines will now become
1456 properties of the device node. In general, device nodes for IP-cores
1457 will take the following form:
1458
1459 (name): (generic-name)@(base-address) {
1460 compatible = "xlnx,(ip-core-name)-(HW_VER)"
1461 [, (list of compatible devices), ...];
1462 reg = <(baseaddr) (size)>;
1463 interrupt-parent = <&interrupt-controller-phandle>;
1464 interrupts = < ... >;
1465 xlnx,(parameter1) = "(string-value)";
1466 xlnx,(parameter2) = <(int-value)>;
1467 };
1468
1469 (generic-name): an open firmware-style name that describes the
1470 generic class of device. Preferably, this is one word, such
1471 as 'serial' or 'ethernet'.
1472 (ip-core-name): the name of the ip block (given after the BEGIN
1473 directive in system.mhs). Should be in lowercase
1474 and all underscores '_' converted to dashes '-'.
1475 (name): is derived from the "PARAMETER INSTANCE" value.
1476 (parameter#): C_* parameters from system.mhs. The C_ prefix is
1477 dropped from the parameter name, the name is converted
1478 to lowercase and all underscore '_' characters are
1479 converted to dashes '-'.
1480 (baseaddr): the baseaddr parameter value (often named C_BASEADDR).
1481 (HW_VER): from the HW_VER parameter.
1482 (size): the address range size (often C_HIGHADDR - C_BASEADDR + 1).
1483
1484 Typically, the compatible list will include the exact IP core version
1485 followed by an older IP core version which implements the same
1486 interface or any other device with the same interface.
1487
1488 'reg', 'interrupt-parent' and 'interrupts' are all optional properties.
1489
1490 For example, the following block from system.mhs:
1491
1492 BEGIN opb_uartlite
1493 PARAMETER INSTANCE = opb_uartlite_0
1494 PARAMETER HW_VER = 1.00.b
1495 PARAMETER C_BAUDRATE = 115200
1496 PARAMETER C_DATA_BITS = 8
1497 PARAMETER C_ODD_PARITY = 0
1498 PARAMETER C_USE_PARITY = 0
1499 PARAMETER C_CLK_FREQ = 50000000
1500 PARAMETER C_BASEADDR = 0xEC100000
1501 PARAMETER C_HIGHADDR = 0xEC10FFFF
1502 BUS_INTERFACE SOPB = opb_7
1503 PORT OPB_Clk = CLK_50MHz
1504 PORT Interrupt = opb_uartlite_0_Interrupt
1505 PORT RX = opb_uartlite_0_RX
1506 PORT TX = opb_uartlite_0_TX
1507 PORT OPB_Rst = sys_bus_reset_0
1508 END
1509
1510 becomes the following device tree node:
1511
1512 opb_uartlite_0: serial@ec100000 {
1513 device_type = "serial";
1514 compatible = "xlnx,opb-uartlite-1.00.b";
1515 reg = <ec100000 10000>;
1516 interrupt-parent = <&opb_intc_0>;
1517 interrupts = <1 0>; // got this from the opb_intc parameters
1518 current-speed = <d#115200>; // standard serial device prop
1519 clock-frequency = <d#50000000>; // standard serial device prop
1520 xlnx,data-bits = <8>;
1521 xlnx,odd-parity = <0>;
1522 xlnx,use-parity = <0>;
1523 };
1524
1525 Some IP cores actually implement 2 or more logical devices. In
1526 this case, the device should still describe the whole IP core with
1527 a single node and add a child node for each logical device. The
1528 ranges property can be used to translate from parent IP-core to the
1529 registers of each device. In addition, the parent node should be
1530 compatible with the bus type 'xlnx,compound', and should contain
1531 #address-cells and #size-cells, as with any other bus. (Note: this
1532 makes the assumption that both logical devices have the same bus
1533 binding. If this is not true, then separate nodes should be used
1534 for each logical device). The 'cell-index' property can be used to
1535 enumerate logical devices within an IP core. For example, the
1536 following is the system.mhs entry for the dual ps2 controller found
1537 on the ml403 reference design.
1538
1539 BEGIN opb_ps2_dual_ref
1540 PARAMETER INSTANCE = opb_ps2_dual_ref_0
1541 PARAMETER HW_VER = 1.00.a
1542 PARAMETER C_BASEADDR = 0xA9000000
1543 PARAMETER C_HIGHADDR = 0xA9001FFF
1544 BUS_INTERFACE SOPB = opb_v20_0
1545 PORT Sys_Intr1 = ps2_1_intr
1546 PORT Sys_Intr2 = ps2_2_intr
1547 PORT Clkin1 = ps2_clk_rx_1
1548 PORT Clkin2 = ps2_clk_rx_2
1549 PORT Clkpd1 = ps2_clk_tx_1
1550 PORT Clkpd2 = ps2_clk_tx_2
1551 PORT Rx1 = ps2_d_rx_1
1552 PORT Rx2 = ps2_d_rx_2
1553 PORT Txpd1 = ps2_d_tx_1
1554 PORT Txpd2 = ps2_d_tx_2
1555 END
1556
1557 It would result in the following device tree nodes:
1558
1559 opb_ps2_dual_ref_0: opb-ps2-dual-ref@a9000000 {
1560 #address-cells = <1>;
1561 #size-cells = <1>;
1562 compatible = "xlnx,compound";
1563 ranges = <0 a9000000 2000>;
1564 // If this device had extra parameters, then they would
1565 // go here.
1566 ps2@0 {
1567 compatible = "xlnx,opb-ps2-dual-ref-1.00.a";
1568 reg = <0 40>;
1569 interrupt-parent = <&opb_intc_0>;
1570 interrupts = <3 0>;
1571 cell-index = <0>;
1572 };
1573 ps2@1000 {
1574 compatible = "xlnx,opb-ps2-dual-ref-1.00.a";
1575 reg = <1000 40>;
1576 interrupt-parent = <&opb_intc_0>;
1577 interrupts = <3 0>;
1578 cell-index = <0>;
1579 };
1580 };
1581
1582 Also, the system.mhs file defines bus attachments from the processor
1583 to the devices. The device tree structure should reflect the bus
1584 attachments. Again an example; this system.mhs fragment:
1585
1586 BEGIN ppc405_virtex4
1587 PARAMETER INSTANCE = ppc405_0
1588 PARAMETER HW_VER = 1.01.a
1589 BUS_INTERFACE DPLB = plb_v34_0
1590 BUS_INTERFACE IPLB = plb_v34_0
1591 END
1592
1593 BEGIN opb_intc
1594 PARAMETER INSTANCE = opb_intc_0
1595 PARAMETER HW_VER = 1.00.c
1596 PARAMETER C_BASEADDR = 0xD1000FC0
1597 PARAMETER C_HIGHADDR = 0xD1000FDF
1598 BUS_INTERFACE SOPB = opb_v20_0
1599 END
1600
1601 BEGIN opb_uart16550
1602 PARAMETER INSTANCE = opb_uart16550_0
1603 PARAMETER HW_VER = 1.00.d
1604 PARAMETER C_BASEADDR = 0xa0000000
1605 PARAMETER C_HIGHADDR = 0xa0001FFF
1606 BUS_INTERFACE SOPB = opb_v20_0
1607 END
1608
1609 BEGIN plb_v34
1610 PARAMETER INSTANCE = plb_v34_0
1611 PARAMETER HW_VER = 1.02.a
1612 END
1613
1614 BEGIN plb_bram_if_cntlr
1615 PARAMETER INSTANCE = plb_bram_if_cntlr_0
1616 PARAMETER HW_VER = 1.00.b
1617 PARAMETER C_BASEADDR = 0xFFFF0000
1618 PARAMETER C_HIGHADDR = 0xFFFFFFFF
1619 BUS_INTERFACE SPLB = plb_v34_0
1620 END
1621
1622 BEGIN plb2opb_bridge
1623 PARAMETER INSTANCE = plb2opb_bridge_0
1624 PARAMETER HW_VER = 1.01.a
1625 PARAMETER C_RNG0_BASEADDR = 0x20000000
1626 PARAMETER C_RNG0_HIGHADDR = 0x3FFFFFFF
1627 PARAMETER C_RNG1_BASEADDR = 0x60000000
1628 PARAMETER C_RNG1_HIGHADDR = 0x7FFFFFFF
1629 PARAMETER C_RNG2_BASEADDR = 0x80000000
1630 PARAMETER C_RNG2_HIGHADDR = 0xBFFFFFFF
1631 PARAMETER C_RNG3_BASEADDR = 0xC0000000
1632 PARAMETER C_RNG3_HIGHADDR = 0xDFFFFFFF
1633 BUS_INTERFACE SPLB = plb_v34_0
1634 BUS_INTERFACE MOPB = opb_v20_0
1635 END
1636
1637 Gives this device tree (some properties removed for clarity):
1638
1639 plb@0 {
1640 #address-cells = <1>;
1641 #size-cells = <1>;
1642 compatible = "xlnx,plb-v34-1.02.a";
1643 device_type = "ibm,plb";
1644 ranges; // 1:1 translation
1645
1646 plb_bram_if_cntrl_0: bram@ffff0000 {
1647 reg = <ffff0000 10000>;
1648 }
1649
1650 opb@20000000 {
1651 #address-cells = <1>;
1652 #size-cells = <1>;
1653 ranges = <20000000 20000000 20000000
1654 60000000 60000000 20000000
1655 80000000 80000000 40000000
1656 c0000000 c0000000 20000000>;
1657
1658 opb_uart16550_0: serial@a0000000 {
1659 reg = <a00000000 2000>;
1660 };
1661
1662 opb_intc_0: interrupt-controller@d1000fc0 {
1663 reg = <d1000fc0 20>;
1664 };
1665 };
1666 };
1667
1668 That covers the general approach to binding xilinx IP cores into the
1669 device tree. The following are bindings for specific devices:
1670
1671 i) Xilinx ML300 Framebuffer
1672
1673 Simple framebuffer device from the ML300 reference design (also on the
1674 ML403 reference design as well as others).
1675
1676 Optional properties:
1677 - resolution = <xres yres> : pixel resolution of framebuffer. Some
1678 implementations use a different resolution.
1679 Default is <d#640 d#480>
1680 - virt-resolution = <xvirt yvirt> : Size of framebuffer in memory.
1681 Default is <d#1024 d#480>.
1682 - rotate-display (empty) : rotate display 180 degrees.
1683
1684 ii) Xilinx SystemACE
1685
1686 The Xilinx SystemACE device is used to program FPGAs from an FPGA
1687 bitstream stored on a CF card. It can also be used as a generic CF
1688 interface device.
1689
1690 Optional properties:
1691 - 8-bit (empty) : Set this property for SystemACE in 8 bit mode
1692
1693 iii) Xilinx EMAC and Xilinx TEMAC
1694
1695 Xilinx Ethernet devices. In addition to general xilinx properties
1696 listed above, nodes for these devices should include a phy-handle
1697 property, and may include other common network device properties
1698 like local-mac-address.
1699
1700 iv) Xilinx Uartlite
1701
1702 Xilinx uartlite devices are simple fixed speed serial ports.
1703
1704 Required properties:
1705 - current-speed : Baud rate of uartlite
1706
1707 v) Xilinx hwicap
1708
1709 Xilinx hwicap devices provide access to the configuration logic
1710 of the FPGA through the Internal Configuration Access Port
1711 (ICAP). The ICAP enables partial reconfiguration of the FPGA,
1712 readback of the configuration information, and some control over
1713 'warm boots' of the FPGA fabric.
1714
1715 Required properties:
1716 - xlnx,family : The family of the FPGA, necessary since the
1717 capabilities of the underlying ICAP hardware
1718 differ between different families. May be
1719 'virtex2p', 'virtex4', or 'virtex5'.
1720
1721 vi) Xilinx Uart 16550
1722
1723 Xilinx UART 16550 devices are very similar to the NS16550 but with
1724 different register spacing and an offset from the base address.
1725
1726 Required properties:
1727 - clock-frequency : Frequency of the clock input
1728 - reg-offset : A value of 3 is required
1729 - reg-shift : A value of 2 is required
1730
1731 e) USB EHCI controllers
1732
1733 Required properties:
1734 - compatible : should be "usb-ehci".
1735 - reg : should contain at least address and length of the standard EHCI
1736 register set for the device. Optional platform-dependent registers
1737 (debug-port or other) can be also specified here, but only after
1738 definition of standard EHCI registers.
1739 - interrupts : one EHCI interrupt should be described here.
1740 If device registers are implemented in big endian mode, the device
1741 node should have "big-endian-regs" property.
1742 If controller implementation operates with big endian descriptors,
1743 "big-endian-desc" property should be specified.
1744 If both big endian registers and descriptors are used by the controller
1745 implementation, "big-endian" property can be specified instead of having
1746 both "big-endian-regs" and "big-endian-desc".
1747
1748 Example (Sequoia 440EPx):
1749 ehci@e0000300 {
1750 compatible = "ibm,usb-ehci-440epx", "usb-ehci";
1751 interrupt-parent = <&UIC0>;
1752 interrupts = <1a 4>;
1753 reg = <0 e0000300 90 0 e0000390 70>;
1754 big-endian;
1755 };
1756
1757 f) MDIO on GPIOs
1758
1759 Currently defined compatibles:
1760 - virtual,gpio-mdio
1761
1762 MDC and MDIO lines connected to GPIO controllers are listed in the
1763 gpios property as described in section VIII.1 in the following order:
1764
1765 MDC, MDIO.
1766
1767 Example:
1768
1769 mdio {
1770 compatible = "virtual,mdio-gpio";
1771 #address-cells = <1>;
1772 #size-cells = <0>;
1773 gpios = <&qe_pio_a 11
1774 &qe_pio_c 6>;
1775 };
1776
1777 g) SPI (Serial Peripheral Interface) busses
1778
1779 SPI busses can be described with a node for the SPI master device
1780 and a set of child nodes for each SPI slave on the bus. For this
1781 discussion, it is assumed that the system's SPI controller is in
1782 SPI master mode. This binding does not describe SPI controllers
1783 in slave mode.
1784
1785 The SPI master node requires the following properties:
1786 - #address-cells - number of cells required to define a chip select
1787 address on the SPI bus.
1788 - #size-cells - should be zero.
1789 - compatible - name of SPI bus controller following generic names
1790 recommended practice.
1791 No other properties are required in the SPI bus node. It is assumed
1792 that a driver for an SPI bus device will understand that it is an SPI bus.
1793 However, the binding does not attempt to define the specific method for
1794 assigning chip select numbers. Since SPI chip select configuration is
1795 flexible and non-standardized, it is left out of this binding with the
1796 assumption that board specific platform code will be used to manage
1797 chip selects. Individual drivers can define additional properties to
1798 support describing the chip select layout.
1799
1800 SPI slave nodes must be children of the SPI master node and can
1801 contain the following properties.
1802 - reg - (required) chip select address of device.
1803 - compatible - (required) name of SPI device following generic names
1804 recommended practice
1805 - spi-max-frequency - (required) Maximum SPI clocking speed of device in Hz
1806 - spi-cpol - (optional) Empty property indicating device requires
1807 inverse clock polarity (CPOL) mode
1808 - spi-cpha - (optional) Empty property indicating device requires
1809 shifted clock phase (CPHA) mode
1810 - spi-cs-high - (optional) Empty property indicating device requires
1811 chip select active high
1812
1813 SPI example for an MPC5200 SPI bus:
1814 spi@f00 {
1815 #address-cells = <1>;
1816 #size-cells = <0>;
1817 compatible = "fsl,mpc5200b-spi","fsl,mpc5200-spi";
1818 reg = <0xf00 0x20>;
1819 interrupts = <2 13 0 2 14 0>;
1820 interrupt-parent = <&mpc5200_pic>;
1821
1822 ethernet-switch@0 {
1823 compatible = "micrel,ks8995m";
1824 spi-max-frequency = <1000000>;
1825 reg = <0>;
1826 };
1827
1828 codec@1 {
1829 compatible = "ti,tlv320aic26";
1830 spi-max-frequency = <100000>;
1831 reg = <1>;
1832 };
1833 };
1834
1835VII - Marvell Discovery mv64[345]6x System Controller chips
1836===========================================================
1837
1838The Marvell mv64[345]60 series of system controller chips contain
1839many of the peripherals needed to implement a complete computer
1840system. In this section, we define device tree nodes to describe
1841the system controller chip itself and each of the peripherals
1842which it contains. Compatible string values for each node are
1843prefixed with the string "marvell,", for Marvell Technology Group Ltd.
1844
18451) The /system-controller node
1846
1847 This node is used to represent the system-controller and must be
1848 present when the system uses a system controller chip. The top-level
1849 system-controller node contains information that is global to all
1850 devices within the system controller chip. The node name begins
1851 with "system-controller" followed by the unit address, which is
1852 the base address of the memory-mapped register set for the system
1853 controller chip.
1854
1855 Required properties:
1856
1857 - ranges : Describes the translation of system controller addresses
1858 for memory mapped registers.
1859 - clock-frequency: Contains the main clock frequency for the system
1860 controller chip.
1861 - reg : This property defines the address and size of the
1862 memory-mapped registers contained within the system controller
1863 chip. The address specified in the "reg" property should match
1864 the unit address of the system-controller node.
1865 - #address-cells : Address representation for system controller
1866 devices. This field represents the number of cells needed to
1867 represent the address of the memory-mapped registers of devices
1868 within the system controller chip.
1869 - #size-cells : Size representation for for the memory-mapped
1870 registers within the system controller chip.
1871 - #interrupt-cells : Defines the width of cells used to represent
1872 interrupts.
1873
1874 Optional properties:
1875
1876 - model : The specific model of the system controller chip. Such
1877 as, "mv64360", "mv64460", or "mv64560".
1878 - compatible : A string identifying the compatibility identifiers
1879 of the system controller chip.
1880
1881 The system-controller node contains child nodes for each system
1882 controller device that the platform uses. Nodes should not be created
1883 for devices which exist on the system controller chip but are not used
1884
1885 Example Marvell Discovery mv64360 system-controller node:
1886
1887 system-controller@f1000000 { /* Marvell Discovery mv64360 */
1888 #address-cells = <1>;
1889 #size-cells = <1>;
1890 model = "mv64360"; /* Default */
1891 compatible = "marvell,mv64360";
1892 clock-frequency = <133333333>;
1893 reg = <0xf1000000 0x10000>;
1894 virtual-reg = <0xf1000000>;
1895 ranges = <0x88000000 0x88000000 0x1000000 /* PCI 0 I/O Space */
1896 0x80000000 0x80000000 0x8000000 /* PCI 0 MEM Space */
1897 0xa0000000 0xa0000000 0x4000000 /* User FLASH */
1898 0x00000000 0xf1000000 0x0010000 /* Bridge's regs */
1899 0xf2000000 0xf2000000 0x0040000>;/* Integrated SRAM */
1900
1901 [ child node definitions... ]
1902 }
1903
19042) Child nodes of /system-controller
1905
1906 a) Marvell Discovery MDIO bus
1907
1908 The MDIO is a bus to which the PHY devices are connected. For each
1909 device that exists on this bus, a child node should be created. See
1910 the definition of the PHY node below for an example of how to define
1911 a PHY.
1912
1913 Required properties:
1914 - #address-cells : Should be <1>
1915 - #size-cells : Should be <0>
1916 - device_type : Should be "mdio"
1917 - compatible : Should be "marvell,mv64360-mdio"
1918
1919 Example:
1920
1921 mdio {
1922 #address-cells = <1>;
1923 #size-cells = <0>;
1924 device_type = "mdio";
1925 compatible = "marvell,mv64360-mdio";
1926
1927 ethernet-phy@0 {
1928 ......
1929 };
1930 };
1931
1932
1933 b) Marvell Discovery ethernet controller
1934
1935 The Discover ethernet controller is described with two levels
1936 of nodes. The first level describes an ethernet silicon block
1937 and the second level describes up to 3 ethernet nodes within
1938 that block. The reason for the multiple levels is that the
1939 registers for the node are interleaved within a single set
1940 of registers. The "ethernet-block" level describes the
1941 shared register set, and the "ethernet" nodes describe ethernet
1942 port-specific properties.
1943
1944 Ethernet block node
1945
1946 Required properties:
1947 - #address-cells : <1>
1948 - #size-cells : <0>
1949 - compatible : "marvell,mv64360-eth-block"
1950 - reg : Offset and length of the register set for this block
1951
1952 Example Discovery Ethernet block node:
1953 ethernet-block@2000 {
1954 #address-cells = <1>;
1955 #size-cells = <0>;
1956 compatible = "marvell,mv64360-eth-block";
1957 reg = <0x2000 0x2000>;
1958 ethernet@0 {
1959 .......
1960 };
1961 };
1962
1963 Ethernet port node
1964
1965 Required properties:
1966 - device_type : Should be "network".
1967 - compatible : Should be "marvell,mv64360-eth".
1968 - reg : Should be <0>, <1>, or <2>, according to which registers
1969 within the silicon block the device uses.
1970 - interrupts : <a> where a is the interrupt number for the port.
1971 - interrupt-parent : the phandle for the interrupt controller
1972 that services interrupts for this device.
1973 - phy : the phandle for the PHY connected to this ethernet
1974 controller.
1975 - local-mac-address : 6 bytes, MAC address
1976
1977 Example Discovery Ethernet port node:
1978 ethernet@0 {
1979 device_type = "network";
1980 compatible = "marvell,mv64360-eth";
1981 reg = <0>;
1982 interrupts = <32>;
1983 interrupt-parent = <&PIC>;
1984 phy = <&PHY0>;
1985 local-mac-address = [ 00 00 00 00 00 00 ];
1986 };
1987
1988
1989
1990 c) Marvell Discovery PHY nodes
1991
1992 Required properties:
1993 - device_type : Should be "ethernet-phy"
1994 - interrupts : <a> where a is the interrupt number for this phy.
1995 - interrupt-parent : the phandle for the interrupt controller that
1996 services interrupts for this device.
1997 - reg : The ID number for the phy, usually a small integer
1998
1999 Example Discovery PHY node:
2000 ethernet-phy@1 {
2001 device_type = "ethernet-phy";
2002 compatible = "broadcom,bcm5421";
2003 interrupts = <76>; /* GPP 12 */
2004 interrupt-parent = <&PIC>;
2005 reg = <1>;
2006 };
2007
2008
2009 d) Marvell Discovery SDMA nodes
2010
2011 Represent DMA hardware associated with the MPSC (multiprotocol
2012 serial controllers).
2013
2014 Required properties:
2015 - compatible : "marvell,mv64360-sdma"
2016 - reg : Offset and length of the register set for this device
2017 - interrupts : <a> where a is the interrupt number for the DMA
2018 device.
2019 - interrupt-parent : the phandle for the interrupt controller
2020 that services interrupts for this device.
2021
2022 Example Discovery SDMA node:
2023 sdma@4000 {
2024 compatible = "marvell,mv64360-sdma";
2025 reg = <0x4000 0xc18>;
2026 virtual-reg = <0xf1004000>;
2027 interrupts = <36>;
2028 interrupt-parent = <&PIC>;
2029 };
2030
2031
2032 e) Marvell Discovery BRG nodes
2033
2034 Represent baud rate generator hardware associated with the MPSC
2035 (multiprotocol serial controllers).
2036
2037 Required properties:
2038 - compatible : "marvell,mv64360-brg"
2039 - reg : Offset and length of the register set for this device
2040 - clock-src : A value from 0 to 15 which selects the clock
2041 source for the baud rate generator. This value corresponds
2042 to the CLKS value in the BRGx configuration register. See
2043 the mv64x60 User's Manual.
2044 - clock-frequence : The frequency (in Hz) of the baud rate
2045 generator's input clock.
2046 - current-speed : The current speed setting (presumably by
2047 firmware) of the baud rate generator.
2048
2049 Example Discovery BRG node:
2050 brg@b200 {
2051 compatible = "marvell,mv64360-brg";
2052 reg = <0xb200 0x8>;
2053 clock-src = <8>;
2054 clock-frequency = <133333333>;
2055 current-speed = <9600>;
2056 };
2057
2058
2059 f) Marvell Discovery CUNIT nodes
2060
2061 Represent the Serial Communications Unit device hardware.
2062
2063 Required properties:
2064 - reg : Offset and length of the register set for this device
2065
2066 Example Discovery CUNIT node:
2067 cunit@f200 {
2068 reg = <0xf200 0x200>;
2069 };
2070
2071
2072 g) Marvell Discovery MPSCROUTING nodes
2073
2074 Represent the Discovery's MPSC routing hardware
2075
2076 Required properties:
2077 - reg : Offset and length of the register set for this device
2078
2079 Example Discovery CUNIT node:
2080 mpscrouting@b500 {
2081 reg = <0xb400 0xc>;
2082 };
2083
2084
2085 h) Marvell Discovery MPSCINTR nodes
2086
2087 Represent the Discovery's MPSC DMA interrupt hardware registers
2088 (SDMA cause and mask registers).
2089
2090 Required properties:
2091 - reg : Offset and length of the register set for this device
2092
2093 Example Discovery MPSCINTR node:
2094 mpsintr@b800 {
2095 reg = <0xb800 0x100>;
2096 };
2097
2098
2099 i) Marvell Discovery MPSC nodes
2100
2101 Represent the Discovery's MPSC (Multiprotocol Serial Controller)
2102 serial port.
2103
2104 Required properties:
2105 - device_type : "serial"
2106 - compatible : "marvell,mv64360-mpsc"
2107 - reg : Offset and length of the register set for this device
2108 - sdma : the phandle for the SDMA node used by this port
2109 - brg : the phandle for the BRG node used by this port
2110 - cunit : the phandle for the CUNIT node used by this port
2111 - mpscrouting : the phandle for the MPSCROUTING node used by this port
2112 - mpscintr : the phandle for the MPSCINTR node used by this port
2113 - cell-index : the hardware index of this cell in the MPSC core
2114 - max_idle : value needed for MPSC CHR3 (Maximum Frame Length)
2115 register
2116 - interrupts : <a> where a is the interrupt number for the MPSC.
2117 - interrupt-parent : the phandle for the interrupt controller
2118 that services interrupts for this device.
2119
2120 Example Discovery MPSCINTR node:
2121 mpsc@8000 {
2122 device_type = "serial";
2123 compatible = "marvell,mv64360-mpsc";
2124 reg = <0x8000 0x38>;
2125 virtual-reg = <0xf1008000>;
2126 sdma = <&SDMA0>;
2127 brg = <&BRG0>;
2128 cunit = <&CUNIT>;
2129 mpscrouting = <&MPSCROUTING>;
2130 mpscintr = <&MPSCINTR>;
2131 cell-index = <0>;
2132 max_idle = <40>;
2133 interrupts = <40>;
2134 interrupt-parent = <&PIC>;
2135 };
2136
2137
2138 j) Marvell Discovery Watch Dog Timer nodes
2139
2140 Represent the Discovery's watchdog timer hardware
2141
2142 Required properties:
2143 - compatible : "marvell,mv64360-wdt"
2144 - reg : Offset and length of the register set for this device
2145
2146 Example Discovery Watch Dog Timer node:
2147 wdt@b410 {
2148 compatible = "marvell,mv64360-wdt";
2149 reg = <0xb410 0x8>;
2150 };
2151
2152
2153 k) Marvell Discovery I2C nodes
2154
2155 Represent the Discovery's I2C hardware
2156
2157 Required properties:
2158 - device_type : "i2c"
2159 - compatible : "marvell,mv64360-i2c"
2160 - reg : Offset and length of the register set for this device
2161 - interrupts : <a> where a is the interrupt number for the I2C.
2162 - interrupt-parent : the phandle for the interrupt controller
2163 that services interrupts for this device.
2164
2165 Example Discovery I2C node:
2166 compatible = "marvell,mv64360-i2c";
2167 reg = <0xc000 0x20>;
2168 virtual-reg = <0xf100c000>;
2169 interrupts = <37>;
2170 interrupt-parent = <&PIC>;
2171 };
2172
2173
2174 l) Marvell Discovery PIC (Programmable Interrupt Controller) nodes
2175
2176 Represent the Discovery's PIC hardware
2177
2178 Required properties:
2179 - #interrupt-cells : <1>
2180 - #address-cells : <0>
2181 - compatible : "marvell,mv64360-pic"
2182 - reg : Offset and length of the register set for this device
2183 - interrupt-controller
2184
2185 Example Discovery PIC node:
2186 pic {
2187 #interrupt-cells = <1>;
2188 #address-cells = <0>;
2189 compatible = "marvell,mv64360-pic";
2190 reg = <0x0 0x88>;
2191 interrupt-controller;
2192 };
2193
2194
2195 m) Marvell Discovery MPP (Multipurpose Pins) multiplexing nodes
2196
2197 Represent the Discovery's MPP hardware
2198
2199 Required properties:
2200 - compatible : "marvell,mv64360-mpp"
2201 - reg : Offset and length of the register set for this device
2202
2203 Example Discovery MPP node:
2204 mpp@f000 {
2205 compatible = "marvell,mv64360-mpp";
2206 reg = <0xf000 0x10>;
2207 };
2208
2209
2210 n) Marvell Discovery GPP (General Purpose Pins) nodes
2211
2212 Represent the Discovery's GPP hardware
2213
2214 Required properties:
2215 - compatible : "marvell,mv64360-gpp"
2216 - reg : Offset and length of the register set for this device
2217
2218 Example Discovery GPP node:
2219 gpp@f000 {
2220 compatible = "marvell,mv64360-gpp";
2221 reg = <0xf100 0x20>;
2222 };
2223
2224
2225 o) Marvell Discovery PCI host bridge node
2226
2227 Represents the Discovery's PCI host bridge device. The properties
2228 for this node conform to Rev 2.1 of the PCI Bus Binding to IEEE
2229 1275-1994. A typical value for the compatible property is
2230 "marvell,mv64360-pci".
2231
2232 Example Discovery PCI host bridge node
2233 pci@80000000 {
2234 #address-cells = <3>;
2235 #size-cells = <2>;
2236 #interrupt-cells = <1>;
2237 device_type = "pci";
2238 compatible = "marvell,mv64360-pci";
2239 reg = <0xcf8 0x8>;
2240 ranges = <0x01000000 0x0 0x0
2241 0x88000000 0x0 0x01000000
2242 0x02000000 0x0 0x80000000
2243 0x80000000 0x0 0x08000000>;
2244 bus-range = <0 255>;
2245 clock-frequency = <66000000>;
2246 interrupt-parent = <&PIC>;
2247 interrupt-map-mask = <0xf800 0x0 0x0 0x7>;
2248 interrupt-map = <
2249 /* IDSEL 0x0a */
2250 0x5000 0 0 1 &PIC 80
2251 0x5000 0 0 2 &PIC 81
2252 0x5000 0 0 3 &PIC 91
2253 0x5000 0 0 4 &PIC 93
2254
2255 /* IDSEL 0x0b */
2256 0x5800 0 0 1 &PIC 91
2257 0x5800 0 0 2 &PIC 93
2258 0x5800 0 0 3 &PIC 80
2259 0x5800 0 0 4 &PIC 81
2260
2261 /* IDSEL 0x0c */
2262 0x6000 0 0 1 &PIC 91
2263 0x6000 0 0 2 &PIC 93
2264 0x6000 0 0 3 &PIC 80
2265 0x6000 0 0 4 &PIC 81
2266
2267 /* IDSEL 0x0d */
2268 0x6800 0 0 1 &PIC 93
2269 0x6800 0 0 2 &PIC 80
2270 0x6800 0 0 3 &PIC 81
2271 0x6800 0 0 4 &PIC 91
2272 >;
2273 };
2274
2275
2276 p) Marvell Discovery CPU Error nodes
2277
2278 Represent the Discovery's CPU error handler device.
2279
2280 Required properties:
2281 - compatible : "marvell,mv64360-cpu-error"
2282 - reg : Offset and length of the register set for this device
2283 - interrupts : the interrupt number for this device
2284 - interrupt-parent : the phandle for the interrupt controller
2285 that services interrupts for this device.
2286
2287 Example Discovery CPU Error node:
2288 cpu-error@0070 {
2289 compatible = "marvell,mv64360-cpu-error";
2290 reg = <0x70 0x10 0x128 0x28>;
2291 interrupts = <3>;
2292 interrupt-parent = <&PIC>;
2293 };
2294
2295
2296 q) Marvell Discovery SRAM Controller nodes
2297
2298 Represent the Discovery's SRAM controller device.
2299
2300 Required properties:
2301 - compatible : "marvell,mv64360-sram-ctrl"
2302 - reg : Offset and length of the register set for this device
2303 - interrupts : the interrupt number for this device
2304 - interrupt-parent : the phandle for the interrupt controller
2305 that services interrupts for this device.
2306
2307 Example Discovery SRAM Controller node:
2308 sram-ctrl@0380 {
2309 compatible = "marvell,mv64360-sram-ctrl";
2310 reg = <0x380 0x80>;
2311 interrupts = <13>;
2312 interrupt-parent = <&PIC>;
2313 };
2314
2315
2316 r) Marvell Discovery PCI Error Handler nodes
2317
2318 Represent the Discovery's PCI error handler device.
2319
2320 Required properties:
2321 - compatible : "marvell,mv64360-pci-error"
2322 - reg : Offset and length of the register set for this device
2323 - interrupts : the interrupt number for this device
2324 - interrupt-parent : the phandle for the interrupt controller
2325 that services interrupts for this device.
2326
2327 Example Discovery PCI Error Handler node:
2328 pci-error@1d40 {
2329 compatible = "marvell,mv64360-pci-error";
2330 reg = <0x1d40 0x40 0xc28 0x4>;
2331 interrupts = <12>;
2332 interrupt-parent = <&PIC>;
2333 };
2334
2335
2336 s) Marvell Discovery Memory Controller nodes
2337
2338 Represent the Discovery's memory controller device.
2339
2340 Required properties:
2341 - compatible : "marvell,mv64360-mem-ctrl"
2342 - reg : Offset and length of the register set for this device
2343 - interrupts : the interrupt number for this device
2344 - interrupt-parent : the phandle for the interrupt controller
2345 that services interrupts for this device.
2346
2347 Example Discovery Memory Controller node:
2348 mem-ctrl@1400 {
2349 compatible = "marvell,mv64360-mem-ctrl";
2350 reg = <0x1400 0x60>;
2351 interrupts = <17>;
2352 interrupt-parent = <&PIC>;
2353 };
2354
2355
2356VIII - Specifying interrupt information for devices
2357=================================================== 1242===================================================
2358 1243
2359The device tree represents the busses and devices of a hardware 1244The device tree represents the busses and devices of a hardware
@@ -2439,56 +1324,7 @@ encodings listed below:
2439 2 = high to low edge sensitive type enabled 1324 2 = high to low edge sensitive type enabled
2440 3 = low to high edge sensitive type enabled 1325 3 = low to high edge sensitive type enabled
2441 1326
2442IX - Specifying GPIO information for devices 1327VIII - Specifying Device Power Management Information (sleep property)
2443============================================
2444
24451) gpios property
2446-----------------
2447
2448Nodes that makes use of GPIOs should define them using `gpios' property,
2449format of which is: <&gpio-controller1-phandle gpio1-specifier
2450 &gpio-controller2-phandle gpio2-specifier
2451 0 /* holes are permitted, means no GPIO 3 */
2452 &gpio-controller4-phandle gpio4-specifier
2453 ...>;
2454
2455Note that gpio-specifier length is controller dependent.
2456
2457gpio-specifier may encode: bank, pin position inside the bank,
2458whether pin is open-drain and whether pin is logically inverted.
2459
2460Example of the node using GPIOs:
2461
2462 node {
2463 gpios = <&qe_pio_e 18 0>;
2464 };
2465
2466In this example gpio-specifier is "18 0" and encodes GPIO pin number,
2467and empty GPIO flags as accepted by the "qe_pio_e" gpio-controller.
2468
24692) gpio-controller nodes
2470------------------------
2471
2472Every GPIO controller node must have #gpio-cells property defined,
2473this information will be used to translate gpio-specifiers.
2474
2475Example of two SOC GPIO banks defined as gpio-controller nodes:
2476
2477 qe_pio_a: gpio-controller@1400 {
2478 #gpio-cells = <2>;
2479 compatible = "fsl,qe-pario-bank-a", "fsl,qe-pario-bank";
2480 reg = <0x1400 0x18>;
2481 gpio-controller;
2482 };
2483
2484 qe_pio_e: gpio-controller@1460 {
2485 #gpio-cells = <2>;
2486 compatible = "fsl,qe-pario-bank-e", "fsl,qe-pario-bank";
2487 reg = <0x1460 0x18>;
2488 gpio-controller;
2489 };
2490
2491X - Specifying Device Power Management Information (sleep property)
2492=================================================================== 1328===================================================================
2493 1329
2494Devices on SOCs often have mechanisms for placing devices into low-power 1330Devices on SOCs often have mechanisms for placing devices into low-power
diff --git a/Documentation/powerpc/dts-bindings/4xx/emac.txt b/Documentation/powerpc/dts-bindings/4xx/emac.txt
new file mode 100644
index 000000000000..2161334a7ca5
--- /dev/null
+++ b/Documentation/powerpc/dts-bindings/4xx/emac.txt
@@ -0,0 +1,148 @@
1 4xx/Axon EMAC ethernet nodes
2
3 The EMAC ethernet controller in IBM and AMCC 4xx chips, and also
4 the Axon bridge. To operate this needs to interact with a ths
5 special McMAL DMA controller, and sometimes an RGMII or ZMII
6 interface. In addition to the nodes and properties described
7 below, the node for the OPB bus on which the EMAC sits must have a
8 correct clock-frequency property.
9
10 i) The EMAC node itself
11
12 Required properties:
13 - device_type : "network"
14
15 - compatible : compatible list, contains 2 entries, first is
16 "ibm,emac-CHIP" where CHIP is the host ASIC (440gx,
17 405gp, Axon) and second is either "ibm,emac" or
18 "ibm,emac4". For Axon, thus, we have: "ibm,emac-axon",
19 "ibm,emac4"
20 - interrupts : <interrupt mapping for EMAC IRQ and WOL IRQ>
21 - interrupt-parent : optional, if needed for interrupt mapping
22 - reg : <registers mapping>
23 - local-mac-address : 6 bytes, MAC address
24 - mal-device : phandle of the associated McMAL node
25 - mal-tx-channel : 1 cell, index of the tx channel on McMAL associated
26 with this EMAC
27 - mal-rx-channel : 1 cell, index of the rx channel on McMAL associated
28 with this EMAC
29 - cell-index : 1 cell, hardware index of the EMAC cell on a given
30 ASIC (typically 0x0 and 0x1 for EMAC0 and EMAC1 on
31 each Axon chip)
32 - max-frame-size : 1 cell, maximum frame size supported in bytes
33 - rx-fifo-size : 1 cell, Rx fifo size in bytes for 10 and 100 Mb/sec
34 operations.
35 For Axon, 2048
36 - tx-fifo-size : 1 cell, Tx fifo size in bytes for 10 and 100 Mb/sec
37 operations.
38 For Axon, 2048.
39 - fifo-entry-size : 1 cell, size of a fifo entry (used to calculate
40 thresholds).
41 For Axon, 0x00000010
42 - mal-burst-size : 1 cell, MAL burst size (used to calculate thresholds)
43 in bytes.
44 For Axon, 0x00000100 (I think ...)
45 - phy-mode : string, mode of operations of the PHY interface.
46 Supported values are: "mii", "rmii", "smii", "rgmii",
47 "tbi", "gmii", rtbi", "sgmii".
48 For Axon on CAB, it is "rgmii"
49 - mdio-device : 1 cell, required iff using shared MDIO registers
50 (440EP). phandle of the EMAC to use to drive the
51 MDIO lines for the PHY used by this EMAC.
52 - zmii-device : 1 cell, required iff connected to a ZMII. phandle of
53 the ZMII device node
54 - zmii-channel : 1 cell, required iff connected to a ZMII. Which ZMII
55 channel or 0xffffffff if ZMII is only used for MDIO.
56 - rgmii-device : 1 cell, required iff connected to an RGMII. phandle
57 of the RGMII device node.
58 For Axon: phandle of plb5/plb4/opb/rgmii
59 - rgmii-channel : 1 cell, required iff connected to an RGMII. Which
60 RGMII channel is used by this EMAC.
61 Fox Axon: present, whatever value is appropriate for each
62 EMAC, that is the content of the current (bogus) "phy-port"
63 property.
64
65 Optional properties:
66 - phy-address : 1 cell, optional, MDIO address of the PHY. If absent,
67 a search is performed.
68 - phy-map : 1 cell, optional, bitmap of addresses to probe the PHY
69 for, used if phy-address is absent. bit 0x00000001 is
70 MDIO address 0.
71 For Axon it can be absent, though my current driver
72 doesn't handle phy-address yet so for now, keep
73 0x00ffffff in it.
74 - rx-fifo-size-gige : 1 cell, Rx fifo size in bytes for 1000 Mb/sec
75 operations (if absent the value is the same as
76 rx-fifo-size). For Axon, either absent or 2048.
77 - tx-fifo-size-gige : 1 cell, Tx fifo size in bytes for 1000 Mb/sec
78 operations (if absent the value is the same as
79 tx-fifo-size). For Axon, either absent or 2048.
80 - tah-device : 1 cell, optional. If connected to a TAH engine for
81 offload, phandle of the TAH device node.
82 - tah-channel : 1 cell, optional. If appropriate, channel used on the
83 TAH engine.
84
85 Example:
86
87 EMAC0: ethernet@40000800 {
88 device_type = "network";
89 compatible = "ibm,emac-440gp", "ibm,emac";
90 interrupt-parent = <&UIC1>;
91 interrupts = <1c 4 1d 4>;
92 reg = <40000800 70>;
93 local-mac-address = [00 04 AC E3 1B 1E];
94 mal-device = <&MAL0>;
95 mal-tx-channel = <0 1>;
96 mal-rx-channel = <0>;
97 cell-index = <0>;
98 max-frame-size = <5dc>;
99 rx-fifo-size = <1000>;
100 tx-fifo-size = <800>;
101 phy-mode = "rmii";
102 phy-map = <00000001>;
103 zmii-device = <&ZMII0>;
104 zmii-channel = <0>;
105 };
106
107 ii) McMAL node
108
109 Required properties:
110 - device_type : "dma-controller"
111 - compatible : compatible list, containing 2 entries, first is
112 "ibm,mcmal-CHIP" where CHIP is the host ASIC (like
113 emac) and the second is either "ibm,mcmal" or
114 "ibm,mcmal2".
115 For Axon, "ibm,mcmal-axon","ibm,mcmal2"
116 - interrupts : <interrupt mapping for the MAL interrupts sources:
117 5 sources: tx_eob, rx_eob, serr, txde, rxde>.
118 For Axon: This is _different_ from the current
119 firmware. We use the "delayed" interrupts for txeob
120 and rxeob. Thus we end up with mapping those 5 MPIC
121 interrupts, all level positive sensitive: 10, 11, 32,
122 33, 34 (in decimal)
123 - dcr-reg : < DCR registers range >
124 - dcr-parent : if needed for dcr-reg
125 - num-tx-chans : 1 cell, number of Tx channels
126 - num-rx-chans : 1 cell, number of Rx channels
127
128 iii) ZMII node
129
130 Required properties:
131 - compatible : compatible list, containing 2 entries, first is
132 "ibm,zmii-CHIP" where CHIP is the host ASIC (like
133 EMAC) and the second is "ibm,zmii".
134 For Axon, there is no ZMII node.
135 - reg : <registers mapping>
136
137 iv) RGMII node
138
139 Required properties:
140 - compatible : compatible list, containing 2 entries, first is
141 "ibm,rgmii-CHIP" where CHIP is the host ASIC (like
142 EMAC) and the second is "ibm,rgmii".
143 For Axon, "ibm,rgmii-axon","ibm,rgmii"
144 - reg : <registers mapping>
145 - revision : as provided by the RGMII new version register if
146 available.
147 For Axon: 0x0000012a
148
diff --git a/Documentation/powerpc/dts-bindings/gpio/gpio.txt b/Documentation/powerpc/dts-bindings/gpio/gpio.txt
new file mode 100644
index 000000000000..edaa84d288a1
--- /dev/null
+++ b/Documentation/powerpc/dts-bindings/gpio/gpio.txt
@@ -0,0 +1,50 @@
1Specifying GPIO information for devices
2============================================
3
41) gpios property
5-----------------
6
7Nodes that makes use of GPIOs should define them using `gpios' property,
8format of which is: <&gpio-controller1-phandle gpio1-specifier
9 &gpio-controller2-phandle gpio2-specifier
10 0 /* holes are permitted, means no GPIO 3 */
11 &gpio-controller4-phandle gpio4-specifier
12 ...>;
13
14Note that gpio-specifier length is controller dependent.
15
16gpio-specifier may encode: bank, pin position inside the bank,
17whether pin is open-drain and whether pin is logically inverted.
18
19Example of the node using GPIOs:
20
21 node {
22 gpios = <&qe_pio_e 18 0>;
23 };
24
25In this example gpio-specifier is "18 0" and encodes GPIO pin number,
26and empty GPIO flags as accepted by the "qe_pio_e" gpio-controller.
27
282) gpio-controller nodes
29------------------------
30
31Every GPIO controller node must have #gpio-cells property defined,
32this information will be used to translate gpio-specifiers.
33
34Example of two SOC GPIO banks defined as gpio-controller nodes:
35
36 qe_pio_a: gpio-controller@1400 {
37 #gpio-cells = <2>;
38 compatible = "fsl,qe-pario-bank-a", "fsl,qe-pario-bank";
39 reg = <0x1400 0x18>;
40 gpio-controller;
41 };
42
43 qe_pio_e: gpio-controller@1460 {
44 #gpio-cells = <2>;
45 compatible = "fsl,qe-pario-bank-e", "fsl,qe-pario-bank";
46 reg = <0x1460 0x18>;
47 gpio-controller;
48 };
49
50
diff --git a/Documentation/powerpc/dts-bindings/gpio/led.txt b/Documentation/powerpc/dts-bindings/gpio/led.txt
index 4fe14deedc0a..064db928c3c1 100644
--- a/Documentation/powerpc/dts-bindings/gpio/led.txt
+++ b/Documentation/powerpc/dts-bindings/gpio/led.txt
@@ -16,10 +16,17 @@ LED sub-node properties:
16 string defining the trigger assigned to the LED. Current triggers are: 16 string defining the trigger assigned to the LED. Current triggers are:
17 "backlight" - LED will act as a back-light, controlled by the framebuffer 17 "backlight" - LED will act as a back-light, controlled by the framebuffer
18 system 18 system
19 "default-on" - LED will turn on 19 "default-on" - LED will turn on, but see "default-state" below
20 "heartbeat" - LED "double" flashes at a load average based rate 20 "heartbeat" - LED "double" flashes at a load average based rate
21 "ide-disk" - LED indicates disk activity 21 "ide-disk" - LED indicates disk activity
22 "timer" - LED flashes at a fixed, configurable rate 22 "timer" - LED flashes at a fixed, configurable rate
23- default-state: (optional) The initial state of the LED. Valid
24 values are "on", "off", and "keep". If the LED is already on or off
25 and the default-state property is set the to same value, then no
26 glitch should be produced where the LED momentarily turns off (or
27 on). The "keep" setting will keep the LED at whatever its current
28 state is, without producing a glitch. The default is off if this
29 property is not present.
23 30
24Examples: 31Examples:
25 32
@@ -30,14 +37,22 @@ leds {
30 gpios = <&mcu_pio 0 1>; /* Active low */ 37 gpios = <&mcu_pio 0 1>; /* Active low */
31 linux,default-trigger = "ide-disk"; 38 linux,default-trigger = "ide-disk";
32 }; 39 };
40
41 fault {
42 gpios = <&mcu_pio 1 0>;
43 /* Keep LED on if BIOS detected hardware fault */
44 default-state = "keep";
45 };
33}; 46};
34 47
35run-control { 48run-control {
36 compatible = "gpio-leds"; 49 compatible = "gpio-leds";
37 red { 50 red {
38 gpios = <&mpc8572 6 0>; 51 gpios = <&mpc8572 6 0>;
52 default-state = "off";
39 }; 53 };
40 green { 54 green {
41 gpios = <&mpc8572 7 0>; 55 gpios = <&mpc8572 7 0>;
56 default-state = "on";
42 }; 57 };
43} 58}
diff --git a/Documentation/powerpc/dts-bindings/gpio/mdio.txt b/Documentation/powerpc/dts-bindings/gpio/mdio.txt
new file mode 100644
index 000000000000..bc9549529014
--- /dev/null
+++ b/Documentation/powerpc/dts-bindings/gpio/mdio.txt
@@ -0,0 +1,19 @@
1MDIO on GPIOs
2
3Currently defined compatibles:
4- virtual,gpio-mdio
5
6MDC and MDIO lines connected to GPIO controllers are listed in the
7gpios property as described in section VIII.1 in the following order:
8
9MDC, MDIO.
10
11Example:
12
13mdio {
14 compatible = "virtual,mdio-gpio";
15 #address-cells = <1>;
16 #size-cells = <0>;
17 gpios = <&qe_pio_a 11
18 &qe_pio_c 6>;
19};
diff --git a/Documentation/powerpc/dts-bindings/marvell.txt b/Documentation/powerpc/dts-bindings/marvell.txt
new file mode 100644
index 000000000000..3708a2fd4747
--- /dev/null
+++ b/Documentation/powerpc/dts-bindings/marvell.txt
@@ -0,0 +1,521 @@
1Marvell Discovery mv64[345]6x System Controller chips
2===========================================================
3
4The Marvell mv64[345]60 series of system controller chips contain
5many of the peripherals needed to implement a complete computer
6system. In this section, we define device tree nodes to describe
7the system controller chip itself and each of the peripherals
8which it contains. Compatible string values for each node are
9prefixed with the string "marvell,", for Marvell Technology Group Ltd.
10
111) The /system-controller node
12
13 This node is used to represent the system-controller and must be
14 present when the system uses a system controller chip. The top-level
15 system-controller node contains information that is global to all
16 devices within the system controller chip. The node name begins
17 with "system-controller" followed by the unit address, which is
18 the base address of the memory-mapped register set for the system
19 controller chip.
20
21 Required properties:
22
23 - ranges : Describes the translation of system controller addresses
24 for memory mapped registers.
25 - clock-frequency: Contains the main clock frequency for the system
26 controller chip.
27 - reg : This property defines the address and size of the
28 memory-mapped registers contained within the system controller
29 chip. The address specified in the "reg" property should match
30 the unit address of the system-controller node.
31 - #address-cells : Address representation for system controller
32 devices. This field represents the number of cells needed to
33 represent the address of the memory-mapped registers of devices
34 within the system controller chip.
35 - #size-cells : Size representation for for the memory-mapped
36 registers within the system controller chip.
37 - #interrupt-cells : Defines the width of cells used to represent
38 interrupts.
39
40 Optional properties:
41
42 - model : The specific model of the system controller chip. Such
43 as, "mv64360", "mv64460", or "mv64560".
44 - compatible : A string identifying the compatibility identifiers
45 of the system controller chip.
46
47 The system-controller node contains child nodes for each system
48 controller device that the platform uses. Nodes should not be created
49 for devices which exist on the system controller chip but are not used
50
51 Example Marvell Discovery mv64360 system-controller node:
52
53 system-controller@f1000000 { /* Marvell Discovery mv64360 */
54 #address-cells = <1>;
55 #size-cells = <1>;
56 model = "mv64360"; /* Default */
57 compatible = "marvell,mv64360";
58 clock-frequency = <133333333>;
59 reg = <0xf1000000 0x10000>;
60 virtual-reg = <0xf1000000>;
61 ranges = <0x88000000 0x88000000 0x1000000 /* PCI 0 I/O Space */
62 0x80000000 0x80000000 0x8000000 /* PCI 0 MEM Space */
63 0xa0000000 0xa0000000 0x4000000 /* User FLASH */
64 0x00000000 0xf1000000 0x0010000 /* Bridge's regs */
65 0xf2000000 0xf2000000 0x0040000>;/* Integrated SRAM */
66
67 [ child node definitions... ]
68 }
69
702) Child nodes of /system-controller
71
72 a) Marvell Discovery MDIO bus
73
74 The MDIO is a bus to which the PHY devices are connected. For each
75 device that exists on this bus, a child node should be created. See
76 the definition of the PHY node below for an example of how to define
77 a PHY.
78
79 Required properties:
80 - #address-cells : Should be <1>
81 - #size-cells : Should be <0>
82 - device_type : Should be "mdio"
83 - compatible : Should be "marvell,mv64360-mdio"
84
85 Example:
86
87 mdio {
88 #address-cells = <1>;
89 #size-cells = <0>;
90 device_type = "mdio";
91 compatible = "marvell,mv64360-mdio";
92
93 ethernet-phy@0 {
94 ......
95 };
96 };
97
98
99 b) Marvell Discovery ethernet controller
100
101 The Discover ethernet controller is described with two levels
102 of nodes. The first level describes an ethernet silicon block
103 and the second level describes up to 3 ethernet nodes within
104 that block. The reason for the multiple levels is that the
105 registers for the node are interleaved within a single set
106 of registers. The "ethernet-block" level describes the
107 shared register set, and the "ethernet" nodes describe ethernet
108 port-specific properties.
109
110 Ethernet block node
111
112 Required properties:
113 - #address-cells : <1>
114 - #size-cells : <0>
115 - compatible : "marvell,mv64360-eth-block"
116 - reg : Offset and length of the register set for this block
117
118 Example Discovery Ethernet block node:
119 ethernet-block@2000 {
120 #address-cells = <1>;
121 #size-cells = <0>;
122 compatible = "marvell,mv64360-eth-block";
123 reg = <0x2000 0x2000>;
124 ethernet@0 {
125 .......
126 };
127 };
128
129 Ethernet port node
130
131 Required properties:
132 - device_type : Should be "network".
133 - compatible : Should be "marvell,mv64360-eth".
134 - reg : Should be <0>, <1>, or <2>, according to which registers
135 within the silicon block the device uses.
136 - interrupts : <a> where a is the interrupt number for the port.
137 - interrupt-parent : the phandle for the interrupt controller
138 that services interrupts for this device.
139 - phy : the phandle for the PHY connected to this ethernet
140 controller.
141 - local-mac-address : 6 bytes, MAC address
142
143 Example Discovery Ethernet port node:
144 ethernet@0 {
145 device_type = "network";
146 compatible = "marvell,mv64360-eth";
147 reg = <0>;
148 interrupts = <32>;
149 interrupt-parent = <&PIC>;
150 phy = <&PHY0>;
151 local-mac-address = [ 00 00 00 00 00 00 ];
152 };
153
154
155
156 c) Marvell Discovery PHY nodes
157
158 Required properties:
159 - device_type : Should be "ethernet-phy"
160 - interrupts : <a> where a is the interrupt number for this phy.
161 - interrupt-parent : the phandle for the interrupt controller that
162 services interrupts for this device.
163 - reg : The ID number for the phy, usually a small integer
164
165 Example Discovery PHY node:
166 ethernet-phy@1 {
167 device_type = "ethernet-phy";
168 compatible = "broadcom,bcm5421";
169 interrupts = <76>; /* GPP 12 */
170 interrupt-parent = <&PIC>;
171 reg = <1>;
172 };
173
174
175 d) Marvell Discovery SDMA nodes
176
177 Represent DMA hardware associated with the MPSC (multiprotocol
178 serial controllers).
179
180 Required properties:
181 - compatible : "marvell,mv64360-sdma"
182 - reg : Offset and length of the register set for this device
183 - interrupts : <a> where a is the interrupt number for the DMA
184 device.
185 - interrupt-parent : the phandle for the interrupt controller
186 that services interrupts for this device.
187
188 Example Discovery SDMA node:
189 sdma@4000 {
190 compatible = "marvell,mv64360-sdma";
191 reg = <0x4000 0xc18>;
192 virtual-reg = <0xf1004000>;
193 interrupts = <36>;
194 interrupt-parent = <&PIC>;
195 };
196
197
198 e) Marvell Discovery BRG nodes
199
200 Represent baud rate generator hardware associated with the MPSC
201 (multiprotocol serial controllers).
202
203 Required properties:
204 - compatible : "marvell,mv64360-brg"
205 - reg : Offset and length of the register set for this device
206 - clock-src : A value from 0 to 15 which selects the clock
207 source for the baud rate generator. This value corresponds
208 to the CLKS value in the BRGx configuration register. See
209 the mv64x60 User's Manual.
210 - clock-frequence : The frequency (in Hz) of the baud rate
211 generator's input clock.
212 - current-speed : The current speed setting (presumably by
213 firmware) of the baud rate generator.
214
215 Example Discovery BRG node:
216 brg@b200 {
217 compatible = "marvell,mv64360-brg";
218 reg = <0xb200 0x8>;
219 clock-src = <8>;
220 clock-frequency = <133333333>;
221 current-speed = <9600>;
222 };
223
224
225 f) Marvell Discovery CUNIT nodes
226
227 Represent the Serial Communications Unit device hardware.
228
229 Required properties:
230 - reg : Offset and length of the register set for this device
231
232 Example Discovery CUNIT node:
233 cunit@f200 {
234 reg = <0xf200 0x200>;
235 };
236
237
238 g) Marvell Discovery MPSCROUTING nodes
239
240 Represent the Discovery's MPSC routing hardware
241
242 Required properties:
243 - reg : Offset and length of the register set for this device
244
245 Example Discovery CUNIT node:
246 mpscrouting@b500 {
247 reg = <0xb400 0xc>;
248 };
249
250
251 h) Marvell Discovery MPSCINTR nodes
252
253 Represent the Discovery's MPSC DMA interrupt hardware registers
254 (SDMA cause and mask registers).
255
256 Required properties:
257 - reg : Offset and length of the register set for this device
258
259 Example Discovery MPSCINTR node:
260 mpsintr@b800 {
261 reg = <0xb800 0x100>;
262 };
263
264
265 i) Marvell Discovery MPSC nodes
266
267 Represent the Discovery's MPSC (Multiprotocol Serial Controller)
268 serial port.
269
270 Required properties:
271 - device_type : "serial"
272 - compatible : "marvell,mv64360-mpsc"
273 - reg : Offset and length of the register set for this device
274 - sdma : the phandle for the SDMA node used by this port
275 - brg : the phandle for the BRG node used by this port
276 - cunit : the phandle for the CUNIT node used by this port
277 - mpscrouting : the phandle for the MPSCROUTING node used by this port
278 - mpscintr : the phandle for the MPSCINTR node used by this port
279 - cell-index : the hardware index of this cell in the MPSC core
280 - max_idle : value needed for MPSC CHR3 (Maximum Frame Length)
281 register
282 - interrupts : <a> where a is the interrupt number for the MPSC.
283 - interrupt-parent : the phandle for the interrupt controller
284 that services interrupts for this device.
285
286 Example Discovery MPSCINTR node:
287 mpsc@8000 {
288 device_type = "serial";
289 compatible = "marvell,mv64360-mpsc";
290 reg = <0x8000 0x38>;
291 virtual-reg = <0xf1008000>;
292 sdma = <&SDMA0>;
293 brg = <&BRG0>;
294 cunit = <&CUNIT>;
295 mpscrouting = <&MPSCROUTING>;
296 mpscintr = <&MPSCINTR>;
297 cell-index = <0>;
298 max_idle = <40>;
299 interrupts = <40>;
300 interrupt-parent = <&PIC>;
301 };
302
303
304 j) Marvell Discovery Watch Dog Timer nodes
305
306 Represent the Discovery's watchdog timer hardware
307
308 Required properties:
309 - compatible : "marvell,mv64360-wdt"
310 - reg : Offset and length of the register set for this device
311
312 Example Discovery Watch Dog Timer node:
313 wdt@b410 {
314 compatible = "marvell,mv64360-wdt";
315 reg = <0xb410 0x8>;
316 };
317
318
319 k) Marvell Discovery I2C nodes
320
321 Represent the Discovery's I2C hardware
322
323 Required properties:
324 - device_type : "i2c"
325 - compatible : "marvell,mv64360-i2c"
326 - reg : Offset and length of the register set for this device
327 - interrupts : <a> where a is the interrupt number for the I2C.
328 - interrupt-parent : the phandle for the interrupt controller
329 that services interrupts for this device.
330
331 Example Discovery I2C node:
332 compatible = "marvell,mv64360-i2c";
333 reg = <0xc000 0x20>;
334 virtual-reg = <0xf100c000>;
335 interrupts = <37>;
336 interrupt-parent = <&PIC>;
337 };
338
339
340 l) Marvell Discovery PIC (Programmable Interrupt Controller) nodes
341
342 Represent the Discovery's PIC hardware
343
344 Required properties:
345 - #interrupt-cells : <1>
346 - #address-cells : <0>
347 - compatible : "marvell,mv64360-pic"
348 - reg : Offset and length of the register set for this device
349 - interrupt-controller
350
351 Example Discovery PIC node:
352 pic {
353 #interrupt-cells = <1>;
354 #address-cells = <0>;
355 compatible = "marvell,mv64360-pic";
356 reg = <0x0 0x88>;
357 interrupt-controller;
358 };
359
360
361 m) Marvell Discovery MPP (Multipurpose Pins) multiplexing nodes
362
363 Represent the Discovery's MPP hardware
364
365 Required properties:
366 - compatible : "marvell,mv64360-mpp"
367 - reg : Offset and length of the register set for this device
368
369 Example Discovery MPP node:
370 mpp@f000 {
371 compatible = "marvell,mv64360-mpp";
372 reg = <0xf000 0x10>;
373 };
374
375
376 n) Marvell Discovery GPP (General Purpose Pins) nodes
377
378 Represent the Discovery's GPP hardware
379
380 Required properties:
381 - compatible : "marvell,mv64360-gpp"
382 - reg : Offset and length of the register set for this device
383
384 Example Discovery GPP node:
385 gpp@f000 {
386 compatible = "marvell,mv64360-gpp";
387 reg = <0xf100 0x20>;
388 };
389
390
391 o) Marvell Discovery PCI host bridge node
392
393 Represents the Discovery's PCI host bridge device. The properties
394 for this node conform to Rev 2.1 of the PCI Bus Binding to IEEE
395 1275-1994. A typical value for the compatible property is
396 "marvell,mv64360-pci".
397
398 Example Discovery PCI host bridge node
399 pci@80000000 {
400 #address-cells = <3>;
401 #size-cells = <2>;
402 #interrupt-cells = <1>;
403 device_type = "pci";
404 compatible = "marvell,mv64360-pci";
405 reg = <0xcf8 0x8>;
406 ranges = <0x01000000 0x0 0x0
407 0x88000000 0x0 0x01000000
408 0x02000000 0x0 0x80000000
409 0x80000000 0x0 0x08000000>;
410 bus-range = <0 255>;
411 clock-frequency = <66000000>;
412 interrupt-parent = <&PIC>;
413 interrupt-map-mask = <0xf800 0x0 0x0 0x7>;
414 interrupt-map = <
415 /* IDSEL 0x0a */
416 0x5000 0 0 1 &PIC 80
417 0x5000 0 0 2 &PIC 81
418 0x5000 0 0 3 &PIC 91
419 0x5000 0 0 4 &PIC 93
420
421 /* IDSEL 0x0b */
422 0x5800 0 0 1 &PIC 91
423 0x5800 0 0 2 &PIC 93
424 0x5800 0 0 3 &PIC 80
425 0x5800 0 0 4 &PIC 81
426
427 /* IDSEL 0x0c */
428 0x6000 0 0 1 &PIC 91
429 0x6000 0 0 2 &PIC 93
430 0x6000 0 0 3 &PIC 80
431 0x6000 0 0 4 &PIC 81
432
433 /* IDSEL 0x0d */
434 0x6800 0 0 1 &PIC 93
435 0x6800 0 0 2 &PIC 80
436 0x6800 0 0 3 &PIC 81
437 0x6800 0 0 4 &PIC 91
438 >;
439 };
440
441
442 p) Marvell Discovery CPU Error nodes
443
444 Represent the Discovery's CPU error handler device.
445
446 Required properties:
447 - compatible : "marvell,mv64360-cpu-error"
448 - reg : Offset and length of the register set for this device
449 - interrupts : the interrupt number for this device
450 - interrupt-parent : the phandle for the interrupt controller
451 that services interrupts for this device.
452
453 Example Discovery CPU Error node:
454 cpu-error@0070 {
455 compatible = "marvell,mv64360-cpu-error";
456 reg = <0x70 0x10 0x128 0x28>;
457 interrupts = <3>;
458 interrupt-parent = <&PIC>;
459 };
460
461
462 q) Marvell Discovery SRAM Controller nodes
463
464 Represent the Discovery's SRAM controller device.
465
466 Required properties:
467 - compatible : "marvell,mv64360-sram-ctrl"
468 - reg : Offset and length of the register set for this device
469 - interrupts : the interrupt number for this device
470 - interrupt-parent : the phandle for the interrupt controller
471 that services interrupts for this device.
472
473 Example Discovery SRAM Controller node:
474 sram-ctrl@0380 {
475 compatible = "marvell,mv64360-sram-ctrl";
476 reg = <0x380 0x80>;
477 interrupts = <13>;
478 interrupt-parent = <&PIC>;
479 };
480
481
482 r) Marvell Discovery PCI Error Handler nodes
483
484 Represent the Discovery's PCI error handler device.
485
486 Required properties:
487 - compatible : "marvell,mv64360-pci-error"
488 - reg : Offset and length of the register set for this device
489 - interrupts : the interrupt number for this device
490 - interrupt-parent : the phandle for the interrupt controller
491 that services interrupts for this device.
492
493 Example Discovery PCI Error Handler node:
494 pci-error@1d40 {
495 compatible = "marvell,mv64360-pci-error";
496 reg = <0x1d40 0x40 0xc28 0x4>;
497 interrupts = <12>;
498 interrupt-parent = <&PIC>;
499 };
500
501
502 s) Marvell Discovery Memory Controller nodes
503
504 Represent the Discovery's memory controller device.
505
506 Required properties:
507 - compatible : "marvell,mv64360-mem-ctrl"
508 - reg : Offset and length of the register set for this device
509 - interrupts : the interrupt number for this device
510 - interrupt-parent : the phandle for the interrupt controller
511 that services interrupts for this device.
512
513 Example Discovery Memory Controller node:
514 mem-ctrl@1400 {
515 compatible = "marvell,mv64360-mem-ctrl";
516 reg = <0x1400 0x60>;
517 interrupts = <17>;
518 interrupt-parent = <&PIC>;
519 };
520
521
diff --git a/Documentation/powerpc/dts-bindings/phy.txt b/Documentation/powerpc/dts-bindings/phy.txt
new file mode 100644
index 000000000000..bb8c742eb8c5
--- /dev/null
+++ b/Documentation/powerpc/dts-bindings/phy.txt
@@ -0,0 +1,25 @@
1PHY nodes
2
3Required properties:
4
5 - device_type : Should be "ethernet-phy"
6 - interrupts : <a b> where a is the interrupt number and b is a
7 field that represents an encoding of the sense and level
8 information for the interrupt. This should be encoded based on
9 the information in section 2) depending on the type of interrupt
10 controller you have.
11 - interrupt-parent : the phandle for the interrupt controller that
12 services interrupts for this device.
13 - reg : The ID number for the phy, usually a small integer
14 - linux,phandle : phandle for this node; likely referenced by an
15 ethernet controller node.
16
17Example:
18
19ethernet-phy@0 {
20 linux,phandle = <2452000>
21 interrupt-parent = <40000>;
22 interrupts = <35 1>;
23 reg = <0>;
24 device_type = "ethernet-phy";
25};
diff --git a/Documentation/powerpc/dts-bindings/spi-bus.txt b/Documentation/powerpc/dts-bindings/spi-bus.txt
new file mode 100644
index 000000000000..e782add2e457
--- /dev/null
+++ b/Documentation/powerpc/dts-bindings/spi-bus.txt
@@ -0,0 +1,57 @@
1SPI (Serial Peripheral Interface) busses
2
3SPI busses can be described with a node for the SPI master device
4and a set of child nodes for each SPI slave on the bus. For this
5discussion, it is assumed that the system's SPI controller is in
6SPI master mode. This binding does not describe SPI controllers
7in slave mode.
8
9The SPI master node requires the following properties:
10- #address-cells - number of cells required to define a chip select
11 address on the SPI bus.
12- #size-cells - should be zero.
13- compatible - name of SPI bus controller following generic names
14 recommended practice.
15No other properties are required in the SPI bus node. It is assumed
16that a driver for an SPI bus device will understand that it is an SPI bus.
17However, the binding does not attempt to define the specific method for
18assigning chip select numbers. Since SPI chip select configuration is
19flexible and non-standardized, it is left out of this binding with the
20assumption that board specific platform code will be used to manage
21chip selects. Individual drivers can define additional properties to
22support describing the chip select layout.
23
24SPI slave nodes must be children of the SPI master node and can
25contain the following properties.
26- reg - (required) chip select address of device.
27- compatible - (required) name of SPI device following generic names
28 recommended practice
29- spi-max-frequency - (required) Maximum SPI clocking speed of device in Hz
30- spi-cpol - (optional) Empty property indicating device requires
31 inverse clock polarity (CPOL) mode
32- spi-cpha - (optional) Empty property indicating device requires
33 shifted clock phase (CPHA) mode
34- spi-cs-high - (optional) Empty property indicating device requires
35 chip select active high
36
37SPI example for an MPC5200 SPI bus:
38 spi@f00 {
39 #address-cells = <1>;
40 #size-cells = <0>;
41 compatible = "fsl,mpc5200b-spi","fsl,mpc5200-spi";
42 reg = <0xf00 0x20>;
43 interrupts = <2 13 0 2 14 0>;
44 interrupt-parent = <&mpc5200_pic>;
45
46 ethernet-switch@0 {
47 compatible = "micrel,ks8995m";
48 spi-max-frequency = <1000000>;
49 reg = <0>;
50 };
51
52 codec@1 {
53 compatible = "ti,tlv320aic26";
54 spi-max-frequency = <100000>;
55 reg = <1>;
56 };
57 };
diff --git a/Documentation/powerpc/dts-bindings/usb-ehci.txt b/Documentation/powerpc/dts-bindings/usb-ehci.txt
new file mode 100644
index 000000000000..fa18612f757b
--- /dev/null
+++ b/Documentation/powerpc/dts-bindings/usb-ehci.txt
@@ -0,0 +1,25 @@
1USB EHCI controllers
2
3Required properties:
4 - compatible : should be "usb-ehci".
5 - reg : should contain at least address and length of the standard EHCI
6 register set for the device. Optional platform-dependent registers
7 (debug-port or other) can be also specified here, but only after
8 definition of standard EHCI registers.
9 - interrupts : one EHCI interrupt should be described here.
10If device registers are implemented in big endian mode, the device
11node should have "big-endian-regs" property.
12If controller implementation operates with big endian descriptors,
13"big-endian-desc" property should be specified.
14If both big endian registers and descriptors are used by the controller
15implementation, "big-endian" property can be specified instead of having
16both "big-endian-regs" and "big-endian-desc".
17
18Example (Sequoia 440EPx):
19 ehci@e0000300 {
20 compatible = "ibm,usb-ehci-440epx", "usb-ehci";
21 interrupt-parent = <&UIC0>;
22 interrupts = <1a 4>;
23 reg = <0 e0000300 90 0 e0000390 70>;
24 big-endian;
25 };
diff --git a/Documentation/powerpc/dts-bindings/xilinx.txt b/Documentation/powerpc/dts-bindings/xilinx.txt
new file mode 100644
index 000000000000..80339fe4300b
--- /dev/null
+++ b/Documentation/powerpc/dts-bindings/xilinx.txt
@@ -0,0 +1,295 @@
1 d) Xilinx IP cores
2
3 The Xilinx EDK toolchain ships with a set of IP cores (devices) for use
4 in Xilinx Spartan and Virtex FPGAs. The devices cover the whole range
5 of standard device types (network, serial, etc.) and miscellaneous
6 devices (gpio, LCD, spi, etc). Also, since these devices are
7 implemented within the fpga fabric every instance of the device can be
8 synthesised with different options that change the behaviour.
9
10 Each IP-core has a set of parameters which the FPGA designer can use to
11 control how the core is synthesized. Historically, the EDK tool would
12 extract the device parameters relevant to device drivers and copy them
13 into an 'xparameters.h' in the form of #define symbols. This tells the
14 device drivers how the IP cores are configured, but it requres the kernel
15 to be recompiled every time the FPGA bitstream is resynthesized.
16
17 The new approach is to export the parameters into the device tree and
18 generate a new device tree each time the FPGA bitstream changes. The
19 parameters which used to be exported as #defines will now become
20 properties of the device node. In general, device nodes for IP-cores
21 will take the following form:
22
23 (name): (generic-name)@(base-address) {
24 compatible = "xlnx,(ip-core-name)-(HW_VER)"
25 [, (list of compatible devices), ...];
26 reg = <(baseaddr) (size)>;
27 interrupt-parent = <&interrupt-controller-phandle>;
28 interrupts = < ... >;
29 xlnx,(parameter1) = "(string-value)";
30 xlnx,(parameter2) = <(int-value)>;
31 };
32
33 (generic-name): an open firmware-style name that describes the
34 generic class of device. Preferably, this is one word, such
35 as 'serial' or 'ethernet'.
36 (ip-core-name): the name of the ip block (given after the BEGIN
37 directive in system.mhs). Should be in lowercase
38 and all underscores '_' converted to dashes '-'.
39 (name): is derived from the "PARAMETER INSTANCE" value.
40 (parameter#): C_* parameters from system.mhs. The C_ prefix is
41 dropped from the parameter name, the name is converted
42 to lowercase and all underscore '_' characters are
43 converted to dashes '-'.
44 (baseaddr): the baseaddr parameter value (often named C_BASEADDR).
45 (HW_VER): from the HW_VER parameter.
46 (size): the address range size (often C_HIGHADDR - C_BASEADDR + 1).
47
48 Typically, the compatible list will include the exact IP core version
49 followed by an older IP core version which implements the same
50 interface or any other device with the same interface.
51
52 'reg', 'interrupt-parent' and 'interrupts' are all optional properties.
53
54 For example, the following block from system.mhs:
55
56 BEGIN opb_uartlite
57 PARAMETER INSTANCE = opb_uartlite_0
58 PARAMETER HW_VER = 1.00.b
59 PARAMETER C_BAUDRATE = 115200
60 PARAMETER C_DATA_BITS = 8
61 PARAMETER C_ODD_PARITY = 0
62 PARAMETER C_USE_PARITY = 0
63 PARAMETER C_CLK_FREQ = 50000000
64 PARAMETER C_BASEADDR = 0xEC100000
65 PARAMETER C_HIGHADDR = 0xEC10FFFF
66 BUS_INTERFACE SOPB = opb_7
67 PORT OPB_Clk = CLK_50MHz
68 PORT Interrupt = opb_uartlite_0_Interrupt
69 PORT RX = opb_uartlite_0_RX
70 PORT TX = opb_uartlite_0_TX
71 PORT OPB_Rst = sys_bus_reset_0
72 END
73
74 becomes the following device tree node:
75
76 opb_uartlite_0: serial@ec100000 {
77 device_type = "serial";
78 compatible = "xlnx,opb-uartlite-1.00.b";
79 reg = <ec100000 10000>;
80 interrupt-parent = <&opb_intc_0>;
81 interrupts = <1 0>; // got this from the opb_intc parameters
82 current-speed = <d#115200>; // standard serial device prop
83 clock-frequency = <d#50000000>; // standard serial device prop
84 xlnx,data-bits = <8>;
85 xlnx,odd-parity = <0>;
86 xlnx,use-parity = <0>;
87 };
88
89 Some IP cores actually implement 2 or more logical devices. In
90 this case, the device should still describe the whole IP core with
91 a single node and add a child node for each logical device. The
92 ranges property can be used to translate from parent IP-core to the
93 registers of each device. In addition, the parent node should be
94 compatible with the bus type 'xlnx,compound', and should contain
95 #address-cells and #size-cells, as with any other bus. (Note: this
96 makes the assumption that both logical devices have the same bus
97 binding. If this is not true, then separate nodes should be used
98 for each logical device). The 'cell-index' property can be used to
99 enumerate logical devices within an IP core. For example, the
100 following is the system.mhs entry for the dual ps2 controller found
101 on the ml403 reference design.
102
103 BEGIN opb_ps2_dual_ref
104 PARAMETER INSTANCE = opb_ps2_dual_ref_0
105 PARAMETER HW_VER = 1.00.a
106 PARAMETER C_BASEADDR = 0xA9000000
107 PARAMETER C_HIGHADDR = 0xA9001FFF
108 BUS_INTERFACE SOPB = opb_v20_0
109 PORT Sys_Intr1 = ps2_1_intr
110 PORT Sys_Intr2 = ps2_2_intr
111 PORT Clkin1 = ps2_clk_rx_1
112 PORT Clkin2 = ps2_clk_rx_2
113 PORT Clkpd1 = ps2_clk_tx_1
114 PORT Clkpd2 = ps2_clk_tx_2
115 PORT Rx1 = ps2_d_rx_1
116 PORT Rx2 = ps2_d_rx_2
117 PORT Txpd1 = ps2_d_tx_1
118 PORT Txpd2 = ps2_d_tx_2
119 END
120
121 It would result in the following device tree nodes:
122
123 opb_ps2_dual_ref_0: opb-ps2-dual-ref@a9000000 {
124 #address-cells = <1>;
125 #size-cells = <1>;
126 compatible = "xlnx,compound";
127 ranges = <0 a9000000 2000>;
128 // If this device had extra parameters, then they would
129 // go here.
130 ps2@0 {
131 compatible = "xlnx,opb-ps2-dual-ref-1.00.a";
132 reg = <0 40>;
133 interrupt-parent = <&opb_intc_0>;
134 interrupts = <3 0>;
135 cell-index = <0>;
136 };
137 ps2@1000 {
138 compatible = "xlnx,opb-ps2-dual-ref-1.00.a";
139 reg = <1000 40>;
140 interrupt-parent = <&opb_intc_0>;
141 interrupts = <3 0>;
142 cell-index = <0>;
143 };
144 };
145
146 Also, the system.mhs file defines bus attachments from the processor
147 to the devices. The device tree structure should reflect the bus
148 attachments. Again an example; this system.mhs fragment:
149
150 BEGIN ppc405_virtex4
151 PARAMETER INSTANCE = ppc405_0
152 PARAMETER HW_VER = 1.01.a
153 BUS_INTERFACE DPLB = plb_v34_0
154 BUS_INTERFACE IPLB = plb_v34_0
155 END
156
157 BEGIN opb_intc
158 PARAMETER INSTANCE = opb_intc_0
159 PARAMETER HW_VER = 1.00.c
160 PARAMETER C_BASEADDR = 0xD1000FC0
161 PARAMETER C_HIGHADDR = 0xD1000FDF
162 BUS_INTERFACE SOPB = opb_v20_0
163 END
164
165 BEGIN opb_uart16550
166 PARAMETER INSTANCE = opb_uart16550_0
167 PARAMETER HW_VER = 1.00.d
168 PARAMETER C_BASEADDR = 0xa0000000
169 PARAMETER C_HIGHADDR = 0xa0001FFF
170 BUS_INTERFACE SOPB = opb_v20_0
171 END
172
173 BEGIN plb_v34
174 PARAMETER INSTANCE = plb_v34_0
175 PARAMETER HW_VER = 1.02.a
176 END
177
178 BEGIN plb_bram_if_cntlr
179 PARAMETER INSTANCE = plb_bram_if_cntlr_0
180 PARAMETER HW_VER = 1.00.b
181 PARAMETER C_BASEADDR = 0xFFFF0000
182 PARAMETER C_HIGHADDR = 0xFFFFFFFF
183 BUS_INTERFACE SPLB = plb_v34_0
184 END
185
186 BEGIN plb2opb_bridge
187 PARAMETER INSTANCE = plb2opb_bridge_0
188 PARAMETER HW_VER = 1.01.a
189 PARAMETER C_RNG0_BASEADDR = 0x20000000
190 PARAMETER C_RNG0_HIGHADDR = 0x3FFFFFFF
191 PARAMETER C_RNG1_BASEADDR = 0x60000000
192 PARAMETER C_RNG1_HIGHADDR = 0x7FFFFFFF
193 PARAMETER C_RNG2_BASEADDR = 0x80000000
194 PARAMETER C_RNG2_HIGHADDR = 0xBFFFFFFF
195 PARAMETER C_RNG3_BASEADDR = 0xC0000000
196 PARAMETER C_RNG3_HIGHADDR = 0xDFFFFFFF
197 BUS_INTERFACE SPLB = plb_v34_0
198 BUS_INTERFACE MOPB = opb_v20_0
199 END
200
201 Gives this device tree (some properties removed for clarity):
202
203 plb@0 {
204 #address-cells = <1>;
205 #size-cells = <1>;
206 compatible = "xlnx,plb-v34-1.02.a";
207 device_type = "ibm,plb";
208 ranges; // 1:1 translation
209
210 plb_bram_if_cntrl_0: bram@ffff0000 {
211 reg = <ffff0000 10000>;
212 }
213
214 opb@20000000 {
215 #address-cells = <1>;
216 #size-cells = <1>;
217 ranges = <20000000 20000000 20000000
218 60000000 60000000 20000000
219 80000000 80000000 40000000
220 c0000000 c0000000 20000000>;
221
222 opb_uart16550_0: serial@a0000000 {
223 reg = <a00000000 2000>;
224 };
225
226 opb_intc_0: interrupt-controller@d1000fc0 {
227 reg = <d1000fc0 20>;
228 };
229 };
230 };
231
232 That covers the general approach to binding xilinx IP cores into the
233 device tree. The following are bindings for specific devices:
234
235 i) Xilinx ML300 Framebuffer
236
237 Simple framebuffer device from the ML300 reference design (also on the
238 ML403 reference design as well as others).
239
240 Optional properties:
241 - resolution = <xres yres> : pixel resolution of framebuffer. Some
242 implementations use a different resolution.
243 Default is <d#640 d#480>
244 - virt-resolution = <xvirt yvirt> : Size of framebuffer in memory.
245 Default is <d#1024 d#480>.
246 - rotate-display (empty) : rotate display 180 degrees.
247
248 ii) Xilinx SystemACE
249
250 The Xilinx SystemACE device is used to program FPGAs from an FPGA
251 bitstream stored on a CF card. It can also be used as a generic CF
252 interface device.
253
254 Optional properties:
255 - 8-bit (empty) : Set this property for SystemACE in 8 bit mode
256
257 iii) Xilinx EMAC and Xilinx TEMAC
258
259 Xilinx Ethernet devices. In addition to general xilinx properties
260 listed above, nodes for these devices should include a phy-handle
261 property, and may include other common network device properties
262 like local-mac-address.
263
264 iv) Xilinx Uartlite
265
266 Xilinx uartlite devices are simple fixed speed serial ports.
267
268 Required properties:
269 - current-speed : Baud rate of uartlite
270
271 v) Xilinx hwicap
272
273 Xilinx hwicap devices provide access to the configuration logic
274 of the FPGA through the Internal Configuration Access Port
275 (ICAP). The ICAP enables partial reconfiguration of the FPGA,
276 readback of the configuration information, and some control over
277 'warm boots' of the FPGA fabric.
278
279 Required properties:
280 - xlnx,family : The family of the FPGA, necessary since the
281 capabilities of the underlying ICAP hardware
282 differ between different families. May be
283 'virtex2p', 'virtex4', or 'virtex5'.
284
285 vi) Xilinx Uart 16550
286
287 Xilinx UART 16550 devices are very similar to the NS16550 but with
288 different register spacing and an offset from the base address.
289
290 Required properties:
291 - clock-frequency : Frequency of the clock input
292 - reg-offset : A value of 3 is required
293 - reg-shift : A value of 2 is required
294
295
diff --git a/Documentation/scheduler/sched-rt-group.txt b/Documentation/scheduler/sched-rt-group.txt
index 1df7f9cdab05..86eabe6c3419 100644
--- a/Documentation/scheduler/sched-rt-group.txt
+++ b/Documentation/scheduler/sched-rt-group.txt
@@ -73,7 +73,7 @@ The remaining CPU time will be used for user input and other tasks. Because
73realtime tasks have explicitly allocated the CPU time they need to perform 73realtime tasks have explicitly allocated the CPU time they need to perform
74their tasks, buffer underruns in the graphics or audio can be eliminated. 74their tasks, buffer underruns in the graphics or audio can be eliminated.
75 75
76NOTE: the above example is not fully implemented as of yet (2.6.25). We still 76NOTE: the above example is not fully implemented yet. We still
77lack an EDF scheduler to make non-uniform periods usable. 77lack an EDF scheduler to make non-uniform periods usable.
78 78
79 79
@@ -140,14 +140,15 @@ The other option is:
140 140
141.o CONFIG_CGROUP_SCHED (aka "Basis for grouping tasks" = "Control groups") 141.o CONFIG_CGROUP_SCHED (aka "Basis for grouping tasks" = "Control groups")
142 142
143This uses the /cgroup virtual file system and "/cgroup/<cgroup>/cpu.rt_runtime_us" 143This uses the /cgroup virtual file system and
144to control the CPU time reserved for each control group instead. 144"/cgroup/<cgroup>/cpu.rt_runtime_us" to control the CPU time reserved for each
145control group instead.
145 146
146For more information on working with control groups, you should read 147For more information on working with control groups, you should read
147Documentation/cgroups/cgroups.txt as well. 148Documentation/cgroups/cgroups.txt as well.
148 149
149Group settings are checked against the following limits in order to keep the configuration 150Group settings are checked against the following limits in order to keep the
150schedulable: 151configuration schedulable:
151 152
152 \Sum_{i} runtime_{i} / global_period <= global_runtime / global_period 153 \Sum_{i} runtime_{i} / global_period <= global_runtime / global_period
153 154
@@ -189,7 +190,7 @@ Implementing SCHED_EDF might take a while to complete. Priority Inheritance is
189the biggest challenge as the current linux PI infrastructure is geared towards 190the biggest challenge as the current linux PI infrastructure is geared towards
190the limited static priority levels 0-99. With deadline scheduling you need to 191the limited static priority levels 0-99. With deadline scheduling you need to
191do deadline inheritance (since priority is inversely proportional to the 192do deadline inheritance (since priority is inversely proportional to the
192deadline delta (deadline - now). 193deadline delta (deadline - now)).
193 194
194This means the whole PI machinery will have to be reworked - and that is one of 195This means the whole PI machinery will have to be reworked - and that is one of
195the most complex pieces of code we have. 196the most complex pieces of code we have.
diff --git a/Documentation/sound/alsa/HD-Audio-Models.txt b/Documentation/sound/alsa/HD-Audio-Models.txt
index 0d8d23581c44..939a3dd58148 100644
--- a/Documentation/sound/alsa/HD-Audio-Models.txt
+++ b/Documentation/sound/alsa/HD-Audio-Models.txt
@@ -240,6 +240,7 @@ AD1986A
240 laptop-automute 2-channel with EAPD and HP-automute (Lenovo N100) 240 laptop-automute 2-channel with EAPD and HP-automute (Lenovo N100)
241 ultra 2-channel with EAPD (Samsung Ultra tablet PC) 241 ultra 2-channel with EAPD (Samsung Ultra tablet PC)
242 samsung 2-channel with EAPD (Samsung R65) 242 samsung 2-channel with EAPD (Samsung R65)
243 samsung-p50 2-channel with HP-automute (Samsung P50)
243 244
244AD1988/AD1988B/AD1989A/AD1989B 245AD1988/AD1988B/AD1989A/AD1989B
245============================== 246==============================
diff --git a/Documentation/spi/spidev_test.c b/Documentation/spi/spidev_test.c
index cf0e3ce0d526..c1a5aad3c75a 100644
--- a/Documentation/spi/spidev_test.c
+++ b/Documentation/spi/spidev_test.c
@@ -99,11 +99,13 @@ void parse_opts(int argc, char *argv[])
99 { "lsb", 0, 0, 'L' }, 99 { "lsb", 0, 0, 'L' },
100 { "cs-high", 0, 0, 'C' }, 100 { "cs-high", 0, 0, 'C' },
101 { "3wire", 0, 0, '3' }, 101 { "3wire", 0, 0, '3' },
102 { "no-cs", 0, 0, 'N' },
103 { "ready", 0, 0, 'R' },
102 { NULL, 0, 0, 0 }, 104 { NULL, 0, 0, 0 },
103 }; 105 };
104 int c; 106 int c;
105 107
106 c = getopt_long(argc, argv, "D:s:d:b:lHOLC3", lopts, NULL); 108 c = getopt_long(argc, argv, "D:s:d:b:lHOLC3NR", lopts, NULL);
107 109
108 if (c == -1) 110 if (c == -1)
109 break; 111 break;
@@ -139,6 +141,12 @@ void parse_opts(int argc, char *argv[])
139 case '3': 141 case '3':
140 mode |= SPI_3WIRE; 142 mode |= SPI_3WIRE;
141 break; 143 break;
144 case 'N':
145 mode |= SPI_NO_CS;
146 break;
147 case 'R':
148 mode |= SPI_READY;
149 break;
142 default: 150 default:
143 print_usage(argv[0]); 151 print_usage(argv[0]);
144 break; 152 break;
diff --git a/Documentation/video4linux/CARDLIST.em28xx b/Documentation/video4linux/CARDLIST.em28xx
index 873630e7e53e..014d255231fc 100644
--- a/Documentation/video4linux/CARDLIST.em28xx
+++ b/Documentation/video4linux/CARDLIST.em28xx
@@ -66,3 +66,4 @@
66 68 -> Terratec AV350 (em2860) [0ccd:0084] 66 68 -> Terratec AV350 (em2860) [0ccd:0084]
67 69 -> KWorld ATSC 315U HDTV TV Box (em2882) [eb1a:a313] 67 69 -> KWorld ATSC 315U HDTV TV Box (em2882) [eb1a:a313]
68 70 -> Evga inDtube (em2882) 68 70 -> Evga inDtube (em2882)
69 71 -> Silvercrest Webcam 1.3mpix (em2820/em2840)
diff --git a/Documentation/x86/00-INDEX b/Documentation/x86/00-INDEX
index dbe3377754af..f37b46d34861 100644
--- a/Documentation/x86/00-INDEX
+++ b/Documentation/x86/00-INDEX
@@ -2,3 +2,5 @@
2 - this file 2 - this file
3mtrr.txt 3mtrr.txt
4 - how to use x86 Memory Type Range Registers to increase performance 4 - how to use x86 Memory Type Range Registers to increase performance
5exception-tables.txt
6 - why and how Linux kernel uses exception tables on x86
diff --git a/Documentation/exception.txt b/Documentation/x86/exception-tables.txt
index 2d5aded64247..32901aa36f0a 100644
--- a/Documentation/exception.txt
+++ b/Documentation/x86/exception-tables.txt
@@ -1,123 +1,123 @@
1 Kernel level exception handling in Linux 2.1.8 1 Kernel level exception handling in Linux
2 Commentary by Joerg Pommnitz <joerg@raleigh.ibm.com> 2 Commentary by Joerg Pommnitz <joerg@raleigh.ibm.com>
3 3
4When a process runs in kernel mode, it often has to access user 4When a process runs in kernel mode, it often has to access user
5mode memory whose address has been passed by an untrusted program. 5mode memory whose address has been passed by an untrusted program.
6To protect itself the kernel has to verify this address. 6To protect itself the kernel has to verify this address.
7 7
8In older versions of Linux this was done with the 8In older versions of Linux this was done with the
9int verify_area(int type, const void * addr, unsigned long size) 9int verify_area(int type, const void * addr, unsigned long size)
10function (which has since been replaced by access_ok()). 10function (which has since been replaced by access_ok()).
11 11
12This function verified that the memory area starting at address 12This function verified that the memory area starting at address
13'addr' and of size 'size' was accessible for the operation specified 13'addr' and of size 'size' was accessible for the operation specified
14in type (read or write). To do this, verify_read had to look up the 14in type (read or write). To do this, verify_read had to look up the
15virtual memory area (vma) that contained the address addr. In the 15virtual memory area (vma) that contained the address addr. In the
16normal case (correctly working program), this test was successful. 16normal case (correctly working program), this test was successful.
17It only failed for a few buggy programs. In some kernel profiling 17It only failed for a few buggy programs. In some kernel profiling
18tests, this normally unneeded verification used up a considerable 18tests, this normally unneeded verification used up a considerable
19amount of time. 19amount of time.
20 20
21To overcome this situation, Linus decided to let the virtual memory 21To overcome this situation, Linus decided to let the virtual memory
22hardware present in every Linux-capable CPU handle this test. 22hardware present in every Linux-capable CPU handle this test.
23 23
24How does this work? 24How does this work?
25 25
26Whenever the kernel tries to access an address that is currently not 26Whenever the kernel tries to access an address that is currently not
27accessible, the CPU generates a page fault exception and calls the 27accessible, the CPU generates a page fault exception and calls the
28page fault handler 28page fault handler
29 29
30void do_page_fault(struct pt_regs *regs, unsigned long error_code) 30void do_page_fault(struct pt_regs *regs, unsigned long error_code)
31 31
32in arch/i386/mm/fault.c. The parameters on the stack are set up by 32in arch/x86/mm/fault.c. The parameters on the stack are set up by
33the low level assembly glue in arch/i386/kernel/entry.S. The parameter 33the low level assembly glue in arch/x86/kernel/entry_32.S. The parameter
34regs is a pointer to the saved registers on the stack, error_code 34regs is a pointer to the saved registers on the stack, error_code
35contains a reason code for the exception. 35contains a reason code for the exception.
36 36
37do_page_fault first obtains the unaccessible address from the CPU 37do_page_fault first obtains the unaccessible address from the CPU
38control register CR2. If the address is within the virtual address 38control register CR2. If the address is within the virtual address
39space of the process, the fault probably occurred, because the page 39space of the process, the fault probably occurred, because the page
40was not swapped in, write protected or something similar. However, 40was not swapped in, write protected or something similar. However,
41we are interested in the other case: the address is not valid, there 41we are interested in the other case: the address is not valid, there
42is no vma that contains this address. In this case, the kernel jumps 42is no vma that contains this address. In this case, the kernel jumps
43to the bad_area label. 43to the bad_area label.
44 44
45There it uses the address of the instruction that caused the exception 45There it uses the address of the instruction that caused the exception
46(i.e. regs->eip) to find an address where the execution can continue 46(i.e. regs->eip) to find an address where the execution can continue
47(fixup). If this search is successful, the fault handler modifies the 47(fixup). If this search is successful, the fault handler modifies the
48return address (again regs->eip) and returns. The execution will 48return address (again regs->eip) and returns. The execution will
49continue at the address in fixup. 49continue at the address in fixup.
50 50
51Where does fixup point to? 51Where does fixup point to?
52 52
53Since we jump to the contents of fixup, fixup obviously points 53Since we jump to the contents of fixup, fixup obviously points
54to executable code. This code is hidden inside the user access macros. 54to executable code. This code is hidden inside the user access macros.
55I have picked the get_user macro defined in include/asm/uaccess.h as an 55I have picked the get_user macro defined in arch/x86/include/asm/uaccess.h
56example. The definition is somewhat hard to follow, so let's peek at 56as an example. The definition is somewhat hard to follow, so let's peek at
57the code generated by the preprocessor and the compiler. I selected 57the code generated by the preprocessor and the compiler. I selected
58the get_user call in drivers/char/console.c for a detailed examination. 58the get_user call in drivers/char/sysrq.c for a detailed examination.
59 59
60The original code in console.c line 1405: 60The original code in sysrq.c line 587:
61 get_user(c, buf); 61 get_user(c, buf);
62 62
63The preprocessor output (edited to become somewhat readable): 63The preprocessor output (edited to become somewhat readable):
64 64
65( 65(
66 { 66 {
67 long __gu_err = - 14 , __gu_val = 0; 67 long __gu_err = - 14 , __gu_val = 0;
68 const __typeof__(*( ( buf ) )) *__gu_addr = ((buf)); 68 const __typeof__(*( ( buf ) )) *__gu_addr = ((buf));
69 if (((((0 + current_set[0])->tss.segment) == 0x18 ) || 69 if (((((0 + current_set[0])->tss.segment) == 0x18 ) ||
70 (((sizeof(*(buf))) <= 0xC0000000UL) && 70 (((sizeof(*(buf))) <= 0xC0000000UL) &&
71 ((unsigned long)(__gu_addr ) <= 0xC0000000UL - (sizeof(*(buf))))))) 71 ((unsigned long)(__gu_addr ) <= 0xC0000000UL - (sizeof(*(buf)))))))
72 do { 72 do {
73 __gu_err = 0; 73 __gu_err = 0;
74 switch ((sizeof(*(buf)))) { 74 switch ((sizeof(*(buf)))) {
75 case 1: 75 case 1:
76 __asm__ __volatile__( 76 __asm__ __volatile__(
77 "1: mov" "b" " %2,%" "b" "1\n" 77 "1: mov" "b" " %2,%" "b" "1\n"
78 "2:\n" 78 "2:\n"
79 ".section .fixup,\"ax\"\n" 79 ".section .fixup,\"ax\"\n"
80 "3: movl %3,%0\n" 80 "3: movl %3,%0\n"
81 " xor" "b" " %" "b" "1,%" "b" "1\n" 81 " xor" "b" " %" "b" "1,%" "b" "1\n"
82 " jmp 2b\n" 82 " jmp 2b\n"
83 ".section __ex_table,\"a\"\n" 83 ".section __ex_table,\"a\"\n"
84 " .align 4\n" 84 " .align 4\n"
85 " .long 1b,3b\n" 85 " .long 1b,3b\n"
86 ".text" : "=r"(__gu_err), "=q" (__gu_val): "m"((*(struct __large_struct *) 86 ".text" : "=r"(__gu_err), "=q" (__gu_val): "m"((*(struct __large_struct *)
87 ( __gu_addr )) ), "i"(- 14 ), "0"( __gu_err )) ; 87 ( __gu_addr )) ), "i"(- 14 ), "0"( __gu_err )) ;
88 break; 88 break;
89 case 2: 89 case 2:
90 __asm__ __volatile__( 90 __asm__ __volatile__(
91 "1: mov" "w" " %2,%" "w" "1\n" 91 "1: mov" "w" " %2,%" "w" "1\n"
92 "2:\n" 92 "2:\n"
93 ".section .fixup,\"ax\"\n" 93 ".section .fixup,\"ax\"\n"
94 "3: movl %3,%0\n" 94 "3: movl %3,%0\n"
95 " xor" "w" " %" "w" "1,%" "w" "1\n" 95 " xor" "w" " %" "w" "1,%" "w" "1\n"
96 " jmp 2b\n" 96 " jmp 2b\n"
97 ".section __ex_table,\"a\"\n" 97 ".section __ex_table,\"a\"\n"
98 " .align 4\n" 98 " .align 4\n"
99 " .long 1b,3b\n" 99 " .long 1b,3b\n"
100 ".text" : "=r"(__gu_err), "=r" (__gu_val) : "m"((*(struct __large_struct *) 100 ".text" : "=r"(__gu_err), "=r" (__gu_val) : "m"((*(struct __large_struct *)
101 ( __gu_addr )) ), "i"(- 14 ), "0"( __gu_err )); 101 ( __gu_addr )) ), "i"(- 14 ), "0"( __gu_err ));
102 break; 102 break;
103 case 4: 103 case 4:
104 __asm__ __volatile__( 104 __asm__ __volatile__(
105 "1: mov" "l" " %2,%" "" "1\n" 105 "1: mov" "l" " %2,%" "" "1\n"
106 "2:\n" 106 "2:\n"
107 ".section .fixup,\"ax\"\n" 107 ".section .fixup,\"ax\"\n"
108 "3: movl %3,%0\n" 108 "3: movl %3,%0\n"
109 " xor" "l" " %" "" "1,%" "" "1\n" 109 " xor" "l" " %" "" "1,%" "" "1\n"
110 " jmp 2b\n" 110 " jmp 2b\n"
111 ".section __ex_table,\"a\"\n" 111 ".section __ex_table,\"a\"\n"
112 " .align 4\n" " .long 1b,3b\n" 112 " .align 4\n" " .long 1b,3b\n"
113 ".text" : "=r"(__gu_err), "=r" (__gu_val) : "m"((*(struct __large_struct *) 113 ".text" : "=r"(__gu_err), "=r" (__gu_val) : "m"((*(struct __large_struct *)
114 ( __gu_addr )) ), "i"(- 14 ), "0"(__gu_err)); 114 ( __gu_addr )) ), "i"(- 14 ), "0"(__gu_err));
115 break; 115 break;
116 default: 116 default:
117 (__gu_val) = __get_user_bad(); 117 (__gu_val) = __get_user_bad();
118 } 118 }
119 } while (0) ; 119 } while (0) ;
120 ((c)) = (__typeof__(*((buf))))__gu_val; 120 ((c)) = (__typeof__(*((buf))))__gu_val;
121 __gu_err; 121 __gu_err;
122 } 122 }
123); 123);
@@ -127,12 +127,12 @@ see what code gcc generates:
127 127
128 > xorl %edx,%edx 128 > xorl %edx,%edx
129 > movl current_set,%eax 129 > movl current_set,%eax
130 > cmpl $24,788(%eax) 130 > cmpl $24,788(%eax)
131 > je .L1424 131 > je .L1424
132 > cmpl $-1073741825,64(%esp) 132 > cmpl $-1073741825,64(%esp)
133 > ja .L1423 133 > ja .L1423
134 > .L1424: 134 > .L1424:
135 > movl %edx,%eax 135 > movl %edx,%eax
136 > movl 64(%esp),%ebx 136 > movl 64(%esp),%ebx
137 > #APP 137 > #APP
138 > 1: movb (%ebx),%dl /* this is the actual user access */ 138 > 1: movb (%ebx),%dl /* this is the actual user access */
@@ -149,17 +149,17 @@ see what code gcc generates:
149 > .L1423: 149 > .L1423:
150 > movzbl %dl,%esi 150 > movzbl %dl,%esi
151 151
152The optimizer does a good job and gives us something we can actually 152The optimizer does a good job and gives us something we can actually
153understand. Can we? The actual user access is quite obvious. Thanks 153understand. Can we? The actual user access is quite obvious. Thanks
154to the unified address space we can just access the address in user 154to the unified address space we can just access the address in user
155memory. But what does the .section stuff do????? 155memory. But what does the .section stuff do?????
156 156
157To understand this we have to look at the final kernel: 157To understand this we have to look at the final kernel:
158 158
159 > objdump --section-headers vmlinux 159 > objdump --section-headers vmlinux
160 > 160 >
161 > vmlinux: file format elf32-i386 161 > vmlinux: file format elf32-i386
162 > 162 >
163 > Sections: 163 > Sections:
164 > Idx Name Size VMA LMA File off Algn 164 > Idx Name Size VMA LMA File off Algn
165 > 0 .text 00098f40 c0100000 c0100000 00001000 2**4 165 > 0 .text 00098f40 c0100000 c0100000 00001000 2**4
@@ -198,18 +198,18 @@ final kernel executable:
198 198
199The whole user memory access is reduced to 10 x86 machine instructions. 199The whole user memory access is reduced to 10 x86 machine instructions.
200The instructions bracketed in the .section directives are no longer 200The instructions bracketed in the .section directives are no longer
201in the normal execution path. They are located in a different section 201in the normal execution path. They are located in a different section
202of the executable file: 202of the executable file:
203 203
204 > objdump --disassemble --section=.fixup vmlinux 204 > objdump --disassemble --section=.fixup vmlinux
205 > 205 >
206 > c0199ff5 <.fixup+10b5> movl $0xfffffff2,%eax 206 > c0199ff5 <.fixup+10b5> movl $0xfffffff2,%eax
207 > c0199ffa <.fixup+10ba> xorb %dl,%dl 207 > c0199ffa <.fixup+10ba> xorb %dl,%dl
208 > c0199ffc <.fixup+10bc> jmp c017e7a7 <do_con_write+e3> 208 > c0199ffc <.fixup+10bc> jmp c017e7a7 <do_con_write+e3>
209 209
210And finally: 210And finally:
211 > objdump --full-contents --section=__ex_table vmlinux 211 > objdump --full-contents --section=__ex_table vmlinux
212 > 212 >
213 > c01aa7c4 93c017c0 e09f19c0 97c017c0 99c017c0 ................ 213 > c01aa7c4 93c017c0 e09f19c0 97c017c0 99c017c0 ................
214 > c01aa7d4 f6c217c0 e99f19c0 a5e717c0 f59f19c0 ................ 214 > c01aa7d4 f6c217c0 e99f19c0 a5e717c0 f59f19c0 ................
215 > c01aa7e4 080a18c0 01a019c0 0a0a18c0 04a019c0 ................ 215 > c01aa7e4 080a18c0 01a019c0 0a0a18c0 04a019c0 ................
@@ -235,8 +235,8 @@ sections in the ELF object file. So the instructions
235ended up in the .fixup section of the object file and the addresses 235ended up in the .fixup section of the object file and the addresses
236 .long 1b,3b 236 .long 1b,3b
237ended up in the __ex_table section of the object file. 1b and 3b 237ended up in the __ex_table section of the object file. 1b and 3b
238are local labels. The local label 1b (1b stands for next label 1 238are local labels. The local label 1b (1b stands for next label 1
239backward) is the address of the instruction that might fault, i.e. 239backward) is the address of the instruction that might fault, i.e.
240in our case the address of the label 1 is c017e7a5: 240in our case the address of the label 1 is c017e7a5:
241the original assembly code: > 1: movb (%ebx),%dl 241the original assembly code: > 1: movb (%ebx),%dl
242and linked in vmlinux : > c017e7a5 <do_con_write+e1> movb (%ebx),%dl 242and linked in vmlinux : > c017e7a5 <do_con_write+e1> movb (%ebx),%dl
@@ -254,7 +254,7 @@ The assembly code
254becomes the value pair 254becomes the value pair
255 > c01aa7d4 c017c2f6 c0199fe9 c017e7a5 c0199ff5 ................ 255 > c01aa7d4 c017c2f6 c0199fe9 c017e7a5 c0199ff5 ................
256 ^this is ^this is 256 ^this is ^this is
257 1b 3b 257 1b 3b
258c017e7a5,c0199ff5 in the exception table of the kernel. 258c017e7a5,c0199ff5 in the exception table of the kernel.
259 259
260So, what actually happens if a fault from kernel mode with no suitable 260So, what actually happens if a fault from kernel mode with no suitable
@@ -266,9 +266,9 @@ vma occurs?
2663.) CPU calls do_page_fault 2663.) CPU calls do_page_fault
2674.) do page fault calls search_exception_table (regs->eip == c017e7a5); 2674.) do page fault calls search_exception_table (regs->eip == c017e7a5);
2685.) search_exception_table looks up the address c017e7a5 in the 2685.) search_exception_table looks up the address c017e7a5 in the
269 exception table (i.e. the contents of the ELF section __ex_table) 269 exception table (i.e. the contents of the ELF section __ex_table)
270 and returns the address of the associated fault handle code c0199ff5. 270 and returns the address of the associated fault handle code c0199ff5.
2716.) do_page_fault modifies its own return address to point to the fault 2716.) do_page_fault modifies its own return address to point to the fault
272 handle code and returns. 272 handle code and returns.
2737.) execution continues in the fault handling code. 2737.) execution continues in the fault handling code.
2748.) 8a) EAX becomes -EFAULT (== -14) 2748.) 8a) EAX becomes -EFAULT (== -14)
generated by cgit v1.2.2 (git 2.25.0) at 2024-11-20 08:06:28 -0500