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/connector/Makefile5
-rw-r--r--Documentation/connector/cn_test.c33
-rw-r--r--Documentation/connector/connector.txt119
-rw-r--r--Documentation/connector/ucon.c62
-rw-r--r--Documentation/gcov.txt25
-rw-r--r--Documentation/kernel-parameters.txt14
-rw-r--r--Documentation/kmemleak.txt23
-rw-r--r--Documentation/leds-lp3944.txt50
-rw-r--r--Documentation/networking/00-INDEX2
-rw-r--r--Documentation/networking/ieee802154.txt2
-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/sound/alsa/HD-Audio-Models.txt1
-rw-r--r--Documentation/spi/spidev_test.c10
24 files changed, 1417 insertions, 1270 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/connector/Makefile b/Documentation/connector/Makefile
index 8df1a7285a06..d98e4df98e24 100644
--- a/Documentation/connector/Makefile
+++ b/Documentation/connector/Makefile
@@ -9,3 +9,8 @@ hostprogs-y := ucon
9always := $(hostprogs-y) 9always := $(hostprogs-y)
10 10
11HOSTCFLAGS_ucon.o += -I$(objtree)/usr/include 11HOSTCFLAGS_ucon.o += -I$(objtree)/usr/include
12
13all: modules
14
15modules clean:
16 $(MAKE) -C ../.. SUBDIRS=$(PWD) $@
diff --git a/Documentation/connector/cn_test.c b/Documentation/connector/cn_test.c
index 6a5be5d5c8e4..1711adc33373 100644
--- a/Documentation/connector/cn_test.c
+++ b/Documentation/connector/cn_test.c
@@ -19,6 +19,8 @@
19 * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA 19 * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
20 */ 20 */
21 21
22#define pr_fmt(fmt) "cn_test: " fmt
23
22#include <linux/kernel.h> 24#include <linux/kernel.h>
23#include <linux/module.h> 25#include <linux/module.h>
24#include <linux/moduleparam.h> 26#include <linux/moduleparam.h>
@@ -27,18 +29,17 @@
27 29
28#include <linux/connector.h> 30#include <linux/connector.h>
29 31
30static struct cb_id cn_test_id = { 0x123, 0x456 }; 32static struct cb_id cn_test_id = { CN_NETLINK_USERS + 3, 0x456 };
31static char cn_test_name[] = "cn_test"; 33static char cn_test_name[] = "cn_test";
32static struct sock *nls; 34static struct sock *nls;
33static struct timer_list cn_test_timer; 35static struct timer_list cn_test_timer;
34 36
35void cn_test_callback(void *data) 37static void cn_test_callback(struct cn_msg *msg)
36{ 38{
37 struct cn_msg *msg = (struct cn_msg *)data; 39 pr_info("%s: %lu: idx=%x, val=%x, seq=%u, ack=%u, len=%d: %s.\n",
38 40 __func__, jiffies, msg->id.idx, msg->id.val,
39 printk("%s: %lu: idx=%x, val=%x, seq=%u, ack=%u, len=%d: %s.\n", 41 msg->seq, msg->ack, msg->len,
40 __func__, jiffies, msg->id.idx, msg->id.val, 42 msg->len ? (char *)msg->data : "");
41 msg->seq, msg->ack, msg->len, (char *)msg->data);
42} 43}
43 44
44/* 45/*
@@ -63,9 +64,7 @@ static int cn_test_want_notify(void)
63 64
64 skb = alloc_skb(size, GFP_ATOMIC); 65 skb = alloc_skb(size, GFP_ATOMIC);
65 if (!skb) { 66 if (!skb) {
66 printk(KERN_ERR "Failed to allocate new skb with size=%u.\n", 67 pr_err("failed to allocate new skb with size=%u\n", size);
67 size);
68
69 return -ENOMEM; 68 return -ENOMEM;
70 } 69 }
71 70
@@ -114,12 +113,12 @@ static int cn_test_want_notify(void)
114 //netlink_broadcast(nls, skb, 0, ctl->group, GFP_ATOMIC); 113 //netlink_broadcast(nls, skb, 0, ctl->group, GFP_ATOMIC);
115 netlink_unicast(nls, skb, 0, 0); 114 netlink_unicast(nls, skb, 0, 0);
116 115
117 printk(KERN_INFO "Request was sent. Group=0x%x.\n", ctl->group); 116 pr_info("request was sent: group=0x%x\n", ctl->group);
118 117
119 return 0; 118 return 0;
120 119
121nlmsg_failure: 120nlmsg_failure:
122 printk(KERN_ERR "Failed to send %u.%u\n", msg->seq, msg->ack); 121 pr_err("failed to send %u.%u\n", msg->seq, msg->ack);
123 kfree_skb(skb); 122 kfree_skb(skb);
124 return -EINVAL; 123 return -EINVAL;
125} 124}
@@ -131,6 +130,8 @@ static void cn_test_timer_func(unsigned long __data)
131 struct cn_msg *m; 130 struct cn_msg *m;
132 char data[32]; 131 char data[32];
133 132
133 pr_debug("%s: timer fired with data %lu\n", __func__, __data);
134
134 m = kzalloc(sizeof(*m) + sizeof(data), GFP_ATOMIC); 135 m = kzalloc(sizeof(*m) + sizeof(data), GFP_ATOMIC);
135 if (m) { 136 if (m) {
136 137
@@ -150,7 +151,7 @@ static void cn_test_timer_func(unsigned long __data)
150 151
151 cn_test_timer_counter++; 152 cn_test_timer_counter++;
152 153
153 mod_timer(&cn_test_timer, jiffies + HZ); 154 mod_timer(&cn_test_timer, jiffies + msecs_to_jiffies(1000));
154} 155}
155 156
156static int cn_test_init(void) 157static int cn_test_init(void)
@@ -168,8 +169,10 @@ static int cn_test_init(void)
168 } 169 }
169 170
170 setup_timer(&cn_test_timer, cn_test_timer_func, 0); 171 setup_timer(&cn_test_timer, cn_test_timer_func, 0);
171 cn_test_timer.expires = jiffies + HZ; 172 mod_timer(&cn_test_timer, jiffies + msecs_to_jiffies(1000));
172 add_timer(&cn_test_timer); 173
174 pr_info("initialized with id={%u.%u}\n",
175 cn_test_id.idx, cn_test_id.val);
173 176
174 return 0; 177 return 0;
175 178
diff --git a/Documentation/connector/connector.txt b/Documentation/connector/connector.txt
index ad6e0ba7b38c..81e6bf6ead57 100644
--- a/Documentation/connector/connector.txt
+++ b/Documentation/connector/connector.txt
@@ -5,10 +5,10 @@ Kernel Connector.
5Kernel connector - new netlink based userspace <-> kernel space easy 5Kernel connector - new netlink based userspace <-> kernel space easy
6to use communication module. 6to use communication module.
7 7
8Connector driver adds possibility to connect various agents using 8The Connector driver makes it easy to connect various agents using a
9netlink based network. One must register callback and 9netlink based network. One must register a callback and an identifier.
10identifier. When driver receives special netlink message with 10When the driver receives a special netlink message with the appropriate
11appropriate identifier, appropriate callback will be called. 11identifier, the appropriate callback will be called.
12 12
13From the userspace point of view it's quite straightforward: 13From the userspace point of view it's quite straightforward:
14 14
@@ -17,10 +17,10 @@ From the userspace point of view it's quite straightforward:
17 send(); 17 send();
18 recv(); 18 recv();
19 19
20But if kernelspace want to use full power of such connections, driver 20But if kernelspace wants to use the full power of such connections, the
21writer must create special sockets, must know about struct sk_buff 21driver writer must create special sockets, must know about struct sk_buff
22handling... Connector allows any kernelspace agents to use netlink 22handling, etc... The Connector driver allows any kernelspace agents to use
23based networking for inter-process communication in a significantly 23netlink based networking for inter-process communication in a significantly
24easier way: 24easier way:
25 25
26int cn_add_callback(struct cb_id *id, char *name, void (*callback) (void *)); 26int cn_add_callback(struct cb_id *id, char *name, void (*callback) (void *));
@@ -32,15 +32,15 @@ struct cb_id
32 __u32 val; 32 __u32 val;
33}; 33};
34 34
35idx and val are unique identifiers which must be registered in 35idx and val are unique identifiers which must be registered in the
36connector.h for in-kernel usage. void (*callback) (void *) - is a 36connector.h header for in-kernel usage. void (*callback) (void *) is a
37callback function which will be called when message with above idx.val 37callback function which will be called when a message with above idx.val
38will be received by connector core. Argument for that function must 38is received by the connector core. The argument for that function must
39be dereferenced to struct cn_msg *. 39be dereferenced to struct cn_msg *.
40 40
41struct cn_msg 41struct cn_msg
42{ 42{
43 struct cb_id id; 43 struct cb_id id;
44 44
45 __u32 seq; 45 __u32 seq;
46 __u32 ack; 46 __u32 ack;
@@ -55,92 +55,95 @@ Connector interfaces.
55 55
56int cn_add_callback(struct cb_id *id, char *name, void (*callback) (void *)); 56int cn_add_callback(struct cb_id *id, char *name, void (*callback) (void *));
57 57
58Registers new callback with connector core. 58 Registers new callback with connector core.
59 59
60struct cb_id *id - unique connector's user identifier. 60 struct cb_id *id - unique connector's user identifier.
61 It must be registered in connector.h for legal in-kernel users. 61 It must be registered in connector.h for legal in-kernel users.
62char *name - connector's callback symbolic name. 62 char *name - connector's callback symbolic name.
63void (*callback) (void *) - connector's callback. 63 void (*callback) (void *) - connector's callback.
64 Argument must be dereferenced to struct cn_msg *. 64 Argument must be dereferenced to struct cn_msg *.
65 65
66
66void cn_del_callback(struct cb_id *id); 67void cn_del_callback(struct cb_id *id);
67 68
68Unregisters new callback with connector core. 69 Unregisters new callback with connector core.
70
71 struct cb_id *id - unique connector's user identifier.
69 72
70struct cb_id *id - unique connector's user identifier.
71 73
72int cn_netlink_send(struct cn_msg *msg, u32 __groups, int gfp_mask); 74int cn_netlink_send(struct cn_msg *msg, u32 __groups, int gfp_mask);
73 75
74Sends message to the specified groups. It can be safely called from 76 Sends message to the specified groups. It can be safely called from
75softirq context, but may silently fail under strong memory pressure. 77 softirq context, but may silently fail under strong memory pressure.
76If there are no listeners for given group -ESRCH can be returned. 78 If there are no listeners for given group -ESRCH can be returned.
77 79
78struct cn_msg * - message header(with attached data). 80 struct cn_msg * - message header(with attached data).
79u32 __group - destination group. 81 u32 __group - destination group.
80 If __group is zero, then appropriate group will 82 If __group is zero, then appropriate group will
81 be searched through all registered connector users, 83 be searched through all registered connector users,
82 and message will be delivered to the group which was 84 and message will be delivered to the group which was
83 created for user with the same ID as in msg. 85 created for user with the same ID as in msg.
84 If __group is not zero, then message will be delivered 86 If __group is not zero, then message will be delivered
85 to the specified group. 87 to the specified group.
86int gfp_mask - GFP mask. 88 int gfp_mask - GFP mask.
87 89
88Note: When registering new callback user, connector core assigns 90 Note: When registering new callback user, connector core assigns
89netlink group to the user which is equal to it's id.idx. 91 netlink group to the user which is equal to it's id.idx.
90 92
91/*****************************************/ 93/*****************************************/
92Protocol description. 94Protocol description.
93/*****************************************/ 95/*****************************************/
94 96
95Current offers transport layer with fixed header. Recommended 97The current framework offers a transport layer with fixed headers. The
96protocol which uses such header is following: 98recommended protocol which uses such a header is as following:
97 99
98msg->seq and msg->ack are used to determine message genealogy. When 100msg->seq and msg->ack are used to determine message genealogy. When
99someone sends message it puts there locally unique sequence and random 101someone sends a message, they use a locally unique sequence and random
100acknowledge numbers. Sequence number may be copied into 102acknowledge number. The sequence number may be copied into
101nlmsghdr->nlmsg_seq too. 103nlmsghdr->nlmsg_seq too.
102 104
103Sequence number is incremented with each message to be sent. 105The sequence number is incremented with each message sent.
104 106
105If we expect reply to our message, then sequence number in received 107If you expect a reply to the message, then the sequence number in the
106message MUST be the same as in original message, and acknowledge 108received message MUST be the same as in the original message, and the
107number MUST be the same + 1. 109acknowledge number MUST be the same + 1.
108 110
109If we receive message and it's sequence number is not equal to one we 111If we receive a message and its sequence number is not equal to one we
110are expecting, then it is new message. If we receive message and it's 112are expecting, then it is a new message. If we receive a message and
111sequence number is the same as one we are expecting, but it's 113its sequence number is the same as one we are expecting, but its
112acknowledge is not equal acknowledge number in original message + 1, 114acknowledge is not equal to the acknowledge number in the original
113then it is new message. 115message + 1, then it is a new message.
114 116
115Obviously, protocol header contains above id. 117Obviously, the protocol header contains the above id.
116 118
117connector allows event notification in the following form: kernel 119The connector allows event notification in the following form: kernel
118driver or userspace process can ask connector to notify it when 120driver or userspace process can ask connector to notify it when
119selected id's will be turned on or off(registered or unregistered it's 121selected ids will be turned on or off (registered or unregistered its
120callback). It is done by sending special command to connector 122callback). It is done by sending a special command to the connector
121driver(it also registers itself with id={-1, -1}). 123driver (it also registers itself with id={-1, -1}).
122 124
123As example of usage Documentation/connector now contains cn_test.c - 125As example of this usage can be found in the cn_test.c module which
124testing module which uses connector to request notification and to 126uses the connector to request notification and to send messages.
125send messages.
126 127
127/*****************************************/ 128/*****************************************/
128Reliability. 129Reliability.
129/*****************************************/ 130/*****************************************/
130 131
131Netlink itself is not reliable protocol, that means that messages can 132Netlink itself is not a reliable protocol. That means that messages can
132be lost due to memory pressure or process' receiving queue overflowed, 133be lost due to memory pressure or process' receiving queue overflowed,
133so caller is warned must be prepared. That is why struct cn_msg [main 134so caller is warned that it must be prepared. That is why the struct
134connector's message header] contains u32 seq and u32 ack fields. 135cn_msg [main connector's message header] contains u32 seq and u32 ack
136fields.
135 137
136/*****************************************/ 138/*****************************************/
137Userspace usage. 139Userspace usage.
138/*****************************************/ 140/*****************************************/
141
1392.6.14 has a new netlink socket implementation, which by default does not 1422.6.14 has a new netlink socket implementation, which by default does not
140allow to send data to netlink groups other than 1. 143allow people to send data to netlink groups other than 1.
141So, if to use netlink socket (for example using connector) 144So, if you wish to use a netlink socket (for example using connector)
142with different group number userspace application must subscribe to 145with a different group number, the userspace application must subscribe to
143that group. It can be achieved by following pseudocode: 146that group first. It can be achieved by the following pseudocode:
144 147
145s = socket(PF_NETLINK, SOCK_DGRAM, NETLINK_CONNECTOR); 148s = socket(PF_NETLINK, SOCK_DGRAM, NETLINK_CONNECTOR);
146 149
@@ -160,8 +163,8 @@ if (bind(s, (struct sockaddr *)&l_local, sizeof(struct sockaddr_nl)) == -1) {
160} 163}
161 164
162Where 270 above is SOL_NETLINK, and 1 is a NETLINK_ADD_MEMBERSHIP socket 165Where 270 above is SOL_NETLINK, and 1 is a NETLINK_ADD_MEMBERSHIP socket
163option. To drop multicast subscription one should call above socket option 166option. To drop a multicast subscription, one should call the above socket
164with NETLINK_DROP_MEMBERSHIP parameter which is defined as 0. 167option with the NETLINK_DROP_MEMBERSHIP parameter which is defined as 0.
165 168
1662.6.14 netlink code only allows to select a group which is less or equal to 1692.6.14 netlink code only allows to select a group which is less or equal to
167the maximum group number, which is used at netlink_kernel_create() time. 170the maximum group number, which is used at netlink_kernel_create() time.
diff --git a/Documentation/connector/ucon.c b/Documentation/connector/ucon.c
index c5092ad0ce4b..4848db8c71ff 100644
--- a/Documentation/connector/ucon.c
+++ b/Documentation/connector/ucon.c
@@ -30,18 +30,24 @@
30 30
31#include <arpa/inet.h> 31#include <arpa/inet.h>
32 32
33#include <stdbool.h>
33#include <stdio.h> 34#include <stdio.h>
34#include <stdlib.h> 35#include <stdlib.h>
35#include <unistd.h> 36#include <unistd.h>
36#include <string.h> 37#include <string.h>
37#include <errno.h> 38#include <errno.h>
38#include <time.h> 39#include <time.h>
40#include <getopt.h>
39 41
40#include <linux/connector.h> 42#include <linux/connector.h>
41 43
42#define DEBUG 44#define DEBUG
43#define NETLINK_CONNECTOR 11 45#define NETLINK_CONNECTOR 11
44 46
47/* Hopefully your userspace connector.h matches this kernel */
48#define CN_TEST_IDX CN_NETLINK_USERS + 3
49#define CN_TEST_VAL 0x456
50
45#ifdef DEBUG 51#ifdef DEBUG
46#define ulog(f, a...) fprintf(stdout, f, ##a) 52#define ulog(f, a...) fprintf(stdout, f, ##a)
47#else 53#else
@@ -83,6 +89,25 @@ static int netlink_send(int s, struct cn_msg *msg)
83 return err; 89 return err;
84} 90}
85 91
92static void usage(void)
93{
94 printf(
95 "Usage: ucon [options] [output file]\n"
96 "\n"
97 "\t-h\tthis help screen\n"
98 "\t-s\tsend buffers to the test module\n"
99 "\n"
100 "The default behavior of ucon is to subscribe to the test module\n"
101 "and wait for state messages. Any ones received are dumped to the\n"
102 "specified output file (or stdout). The test module is assumed to\n"
103 "have an id of {%u.%u}\n"
104 "\n"
105 "If you get no output, then verify the cn_test module id matches\n"
106 "the expected id above.\n"
107 , CN_TEST_IDX, CN_TEST_VAL
108 );
109}
110
86int main(int argc, char *argv[]) 111int main(int argc, char *argv[])
87{ 112{
88 int s; 113 int s;
@@ -94,17 +119,34 @@ int main(int argc, char *argv[])
94 FILE *out; 119 FILE *out;
95 time_t tm; 120 time_t tm;
96 struct pollfd pfd; 121 struct pollfd pfd;
122 bool send_msgs = false;
97 123
98 if (argc < 2) 124 while ((s = getopt(argc, argv, "hs")) != -1) {
99 out = stdout; 125 switch (s) {
100 else { 126 case 's':
101 out = fopen(argv[1], "a+"); 127 send_msgs = true;
128 break;
129
130 case 'h':
131 usage();
132 return 0;
133
134 default:
135 /* getopt() outputs an error for us */
136 usage();
137 return 1;
138 }
139 }
140
141 if (argc != optind) {
142 out = fopen(argv[optind], "a+");
102 if (!out) { 143 if (!out) {
103 ulog("Unable to open %s for writing: %s\n", 144 ulog("Unable to open %s for writing: %s\n",
104 argv[1], strerror(errno)); 145 argv[1], strerror(errno));
105 out = stdout; 146 out = stdout;
106 } 147 }
107 } 148 } else
149 out = stdout;
108 150
109 memset(buf, 0, sizeof(buf)); 151 memset(buf, 0, sizeof(buf));
110 152
@@ -115,9 +157,11 @@ int main(int argc, char *argv[])
115 } 157 }
116 158
117 l_local.nl_family = AF_NETLINK; 159 l_local.nl_family = AF_NETLINK;
118 l_local.nl_groups = 0x123; /* bitmask of requested groups */ 160 l_local.nl_groups = -1; /* bitmask of requested groups */
119 l_local.nl_pid = 0; 161 l_local.nl_pid = 0;
120 162
163 ulog("subscribing to %u.%u\n", CN_TEST_IDX, CN_TEST_VAL);
164
121 if (bind(s, (struct sockaddr *)&l_local, sizeof(struct sockaddr_nl)) == -1) { 165 if (bind(s, (struct sockaddr *)&l_local, sizeof(struct sockaddr_nl)) == -1) {
122 perror("bind"); 166 perror("bind");
123 close(s); 167 close(s);
@@ -130,15 +174,15 @@ int main(int argc, char *argv[])
130 setsockopt(s, SOL_NETLINK, NETLINK_ADD_MEMBERSHIP, &on, sizeof(on)); 174 setsockopt(s, SOL_NETLINK, NETLINK_ADD_MEMBERSHIP, &on, sizeof(on));
131 } 175 }
132#endif 176#endif
133 if (0) { 177 if (send_msgs) {
134 int i, j; 178 int i, j;
135 179
136 memset(buf, 0, sizeof(buf)); 180 memset(buf, 0, sizeof(buf));
137 181
138 data = (struct cn_msg *)buf; 182 data = (struct cn_msg *)buf;
139 183
140 data->id.idx = 0x123; 184 data->id.idx = CN_TEST_IDX;
141 data->id.val = 0x456; 185 data->id.val = CN_TEST_VAL;
142 data->seq = seq++; 186 data->seq = seq++;
143 data->ack = 0; 187 data->ack = 0;
144 data->len = 0; 188 data->len = 0;
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..9347f4ad4342 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -1531,6 +1531,11 @@ and is between 256 and 4096 characters. It is defined in the file
1531 symbolic names: lapic and ioapic 1531 symbolic names: lapic and ioapic
1532 Example: nmi_watchdog=2 or nmi_watchdog=panic,lapic 1532 Example: nmi_watchdog=2 or nmi_watchdog=panic,lapic
1533 1533
1534 netpoll.carrier_timeout=
1535 [NET] Specifies amount of time (in seconds) that
1536 netpoll should wait for a carrier. By default netpoll
1537 waits 4 seconds.
1538
1534 no387 [BUGS=X86-32] Tells the kernel to use the 387 maths 1539 no387 [BUGS=X86-32] Tells the kernel to use the 387 maths
1535 emulation library even if a 387 maths coprocessor 1540 emulation library even if a 387 maths coprocessor
1536 is present. 1541 is present.
@@ -1915,6 +1920,12 @@ and is between 256 and 4096 characters. It is defined in the file
1915 Format: { 0 | 1 } 1920 Format: { 0 | 1 }
1916 See arch/parisc/kernel/pdc_chassis.c 1921 See arch/parisc/kernel/pdc_chassis.c
1917 1922
1923 percpu_alloc= [X86] Select which percpu first chunk allocator to use.
1924 Allowed values are one of "lpage", "embed" and "4k".
1925 See comments in arch/x86/kernel/setup_percpu.c for
1926 details on each allocator. This parameter is primarily
1927 for debugging and performance comparison.
1928
1918 pf. [PARIDE] 1929 pf. [PARIDE]
1919 See Documentation/blockdev/paride.txt. 1930 See Documentation/blockdev/paride.txt.
1920 1931
@@ -2467,7 +2478,8 @@ and is between 256 and 4096 characters. It is defined in the file
2467 2478
2468 tp720= [HW,PS2] 2479 tp720= [HW,PS2]
2469 2480
2470 trace_buf_size=nn[KMG] [ftrace] will set tracing buffer size. 2481 trace_buf_size=nn[KMG]
2482 [FTRACE] will set tracing buffer size.
2471 2483
2472 trix= [HW,OSS] MediaTrix AudioTrix Pro 2484 trix= [HW,OSS] MediaTrix AudioTrix Pro
2473 Format: 2485 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/networking/00-INDEX b/Documentation/networking/00-INDEX
index 1634c6dcecae..50189bf07d53 100644
--- a/Documentation/networking/00-INDEX
+++ b/Documentation/networking/00-INDEX
@@ -60,6 +60,8 @@ framerelay.txt
60 - info on using Frame Relay/Data Link Connection Identifier (DLCI). 60 - info on using Frame Relay/Data Link Connection Identifier (DLCI).
61generic_netlink.txt 61generic_netlink.txt
62 - info on Generic Netlink 62 - info on Generic Netlink
63ieee802154.txt
64 - Linux IEEE 802.15.4 implementation, API and drivers
63ip-sysctl.txt 65ip-sysctl.txt
64 - /proc/sys/net/ipv4/* variables 66 - /proc/sys/net/ipv4/* variables
65ip_dynaddr.txt 67ip_dynaddr.txt
diff --git a/Documentation/networking/ieee802154.txt b/Documentation/networking/ieee802154.txt
index a0280ad2edc9..1d4ed66b1b1c 100644
--- a/Documentation/networking/ieee802154.txt
+++ b/Documentation/networking/ieee802154.txt
@@ -69,7 +69,7 @@ We provide an example of simple HardMAC driver at drivers/ieee802154/fakehard.c
69SoftMAC 69SoftMAC
70======= 70=======
71 71
72We are going to provide intermediate layer impelementing IEEE 802.15.4 MAC 72We are going to provide intermediate layer implementing IEEE 802.15.4 MAC
73in software. This is currently WIP. 73in software. This is currently WIP.
74 74
75See header include/net/ieee802154/mac802154.h and several drivers in 75See header include/net/ieee802154/mac802154.h and several drivers in
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/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;