diff options
Diffstat (limited to 'Documentation')
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 | |||
50 | scatter-gather lists. | 50 | scatter-gather lists. |
51 | 51 | ||
52 | The controller will interleave the buffers on write and split them on | 52 | The controller will interleave the buffers on write and split them on |
53 | read. This means that the Linux can DMA the data buffers to and from | 53 | read. This means that Linux can DMA the data buffers to and from |
54 | host memory without changes to the page cache. | 54 | host memory without changes to the page cache. |
55 | 55 | ||
56 | Also, the 16-bit CRC checksum mandated by both the SCSI and SATA specs | 56 | Also, the 16-bit CRC checksum mandated by both the SCSI and SATA specs |
@@ -66,7 +66,7 @@ software RAID5). | |||
66 | 66 | ||
67 | The IP checksum is weaker than the CRC in terms of detecting bit | 67 | The IP checksum is weaker than the CRC in terms of detecting bit |
68 | errors. However, the strength is really in the separation of the data | 68 | errors. However, the strength is really in the separation of the data |
69 | buffers and the integrity metadata. These two distinct buffers much | 69 | buffers and the integrity metadata. These two distinct buffers must |
70 | match up for an I/O to complete. | 70 | match up for an I/O to complete. |
71 | 71 | ||
72 | The separation of the data and integrity metadata buffers as well as | 72 | The 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 | ||
780 | To add a CPU to a cpuset, write the new list of CPUs including the | ||
781 | CPU 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 | |||
785 | Similarly to remove a CPU from a cpuset, write the new list of CPUs | ||
786 | without the CPU to be removed. | ||
787 | |||
788 | To remove all the CPUs: | ||
789 | |||
790 | # /bin/echo "" > cpus -> clear cpus list | ||
791 | |||
780 | 2.3 Setting flags | 792 | 2.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 | |||
9 | always := $(hostprogs-y) | 9 | always := $(hostprogs-y) |
10 | 10 | ||
11 | HOSTCFLAGS_ucon.o += -I$(objtree)/usr/include | 11 | HOSTCFLAGS_ucon.o += -I$(objtree)/usr/include |
12 | |||
13 | all: modules | ||
14 | |||
15 | modules 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 | ||
30 | static struct cb_id cn_test_id = { 0x123, 0x456 }; | 32 | static struct cb_id cn_test_id = { CN_NETLINK_USERS + 3, 0x456 }; |
31 | static char cn_test_name[] = "cn_test"; | 33 | static char cn_test_name[] = "cn_test"; |
32 | static struct sock *nls; | 34 | static struct sock *nls; |
33 | static struct timer_list cn_test_timer; | 35 | static struct timer_list cn_test_timer; |
34 | 36 | ||
35 | void cn_test_callback(void *data) | 37 | static 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 | ||
121 | nlmsg_failure: | 120 | nlmsg_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 | ||
156 | static int cn_test_init(void) | 157 | static 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. | |||
5 | Kernel connector - new netlink based userspace <-> kernel space easy | 5 | Kernel connector - new netlink based userspace <-> kernel space easy |
6 | to use communication module. | 6 | to use communication module. |
7 | 7 | ||
8 | Connector driver adds possibility to connect various agents using | 8 | The Connector driver makes it easy to connect various agents using a |
9 | netlink based network. One must register callback and | 9 | netlink based network. One must register a callback and an identifier. |
10 | identifier. When driver receives special netlink message with | 10 | When the driver receives a special netlink message with the appropriate |
11 | appropriate identifier, appropriate callback will be called. | 11 | identifier, the appropriate callback will be called. |
12 | 12 | ||
13 | From the userspace point of view it's quite straightforward: | 13 | From 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 | ||
20 | But if kernelspace want to use full power of such connections, driver | 20 | But if kernelspace wants to use the full power of such connections, the |
21 | writer must create special sockets, must know about struct sk_buff | 21 | driver writer must create special sockets, must know about struct sk_buff |
22 | handling... Connector allows any kernelspace agents to use netlink | 22 | handling, etc... The Connector driver allows any kernelspace agents to use |
23 | based networking for inter-process communication in a significantly | 23 | netlink based networking for inter-process communication in a significantly |
24 | easier way: | 24 | easier way: |
25 | 25 | ||
26 | int cn_add_callback(struct cb_id *id, char *name, void (*callback) (void *)); | 26 | int 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 | ||
35 | idx and val are unique identifiers which must be registered in | 35 | idx and val are unique identifiers which must be registered in the |
36 | connector.h for in-kernel usage. void (*callback) (void *) - is a | 36 | connector.h header for in-kernel usage. void (*callback) (void *) is a |
37 | callback function which will be called when message with above idx.val | 37 | callback function which will be called when a message with above idx.val |
38 | will be received by connector core. Argument for that function must | 38 | is received by the connector core. The argument for that function must |
39 | be dereferenced to struct cn_msg *. | 39 | be dereferenced to struct cn_msg *. |
40 | 40 | ||
41 | struct cn_msg | 41 | struct 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 | ||
56 | int cn_add_callback(struct cb_id *id, char *name, void (*callback) (void *)); | 56 | int cn_add_callback(struct cb_id *id, char *name, void (*callback) (void *)); |
57 | 57 | ||
58 | Registers new callback with connector core. | 58 | Registers new callback with connector core. |
59 | 59 | ||
60 | struct 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. |
62 | char *name - connector's callback symbolic name. | 62 | char *name - connector's callback symbolic name. |
63 | void (*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 | |||
66 | void cn_del_callback(struct cb_id *id); | 67 | void cn_del_callback(struct cb_id *id); |
67 | 68 | ||
68 | Unregisters 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 | ||
70 | struct cb_id *id - unique connector's user identifier. | ||
71 | 73 | ||
72 | int cn_netlink_send(struct cn_msg *msg, u32 __groups, int gfp_mask); | 74 | int cn_netlink_send(struct cn_msg *msg, u32 __groups, int gfp_mask); |
73 | 75 | ||
74 | Sends message to the specified groups. It can be safely called from | 76 | Sends message to the specified groups. It can be safely called from |
75 | softirq context, but may silently fail under strong memory pressure. | 77 | softirq context, but may silently fail under strong memory pressure. |
76 | If 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 | ||
78 | struct cn_msg * - message header(with attached data). | 80 | struct cn_msg * - message header(with attached data). |
79 | u32 __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. |
86 | int gfp_mask - GFP mask. | 88 | int gfp_mask - GFP mask. |
87 | 89 | ||
88 | Note: When registering new callback user, connector core assigns | 90 | Note: When registering new callback user, connector core assigns |
89 | netlink 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 | /*****************************************/ |
92 | Protocol description. | 94 | Protocol description. |
93 | /*****************************************/ | 95 | /*****************************************/ |
94 | 96 | ||
95 | Current offers transport layer with fixed header. Recommended | 97 | The current framework offers a transport layer with fixed headers. The |
96 | protocol which uses such header is following: | 98 | recommended protocol which uses such a header is as following: |
97 | 99 | ||
98 | msg->seq and msg->ack are used to determine message genealogy. When | 100 | msg->seq and msg->ack are used to determine message genealogy. When |
99 | someone sends message it puts there locally unique sequence and random | 101 | someone sends a message, they use a locally unique sequence and random |
100 | acknowledge numbers. Sequence number may be copied into | 102 | acknowledge number. The sequence number may be copied into |
101 | nlmsghdr->nlmsg_seq too. | 103 | nlmsghdr->nlmsg_seq too. |
102 | 104 | ||
103 | Sequence number is incremented with each message to be sent. | 105 | The sequence number is incremented with each message sent. |
104 | 106 | ||
105 | If we expect reply to our message, then sequence number in received | 107 | If you expect a reply to the message, then the sequence number in the |
106 | message MUST be the same as in original message, and acknowledge | 108 | received message MUST be the same as in the original message, and the |
107 | number MUST be the same + 1. | 109 | acknowledge number MUST be the same + 1. |
108 | 110 | ||
109 | If we receive message and it's sequence number is not equal to one we | 111 | If we receive a message and its sequence number is not equal to one we |
110 | are expecting, then it is new message. If we receive message and it's | 112 | are expecting, then it is a new message. If we receive a message and |
111 | sequence number is the same as one we are expecting, but it's | 113 | its sequence number is the same as one we are expecting, but its |
112 | acknowledge is not equal acknowledge number in original message + 1, | 114 | acknowledge is not equal to the acknowledge number in the original |
113 | then it is new message. | 115 | message + 1, then it is a new message. |
114 | 116 | ||
115 | Obviously, protocol header contains above id. | 117 | Obviously, the protocol header contains the above id. |
116 | 118 | ||
117 | connector allows event notification in the following form: kernel | 119 | The connector allows event notification in the following form: kernel |
118 | driver or userspace process can ask connector to notify it when | 120 | driver or userspace process can ask connector to notify it when |
119 | selected id's will be turned on or off(registered or unregistered it's | 121 | selected ids will be turned on or off (registered or unregistered its |
120 | callback). It is done by sending special command to connector | 122 | callback). It is done by sending a special command to the connector |
121 | driver(it also registers itself with id={-1, -1}). | 123 | driver (it also registers itself with id={-1, -1}). |
122 | 124 | ||
123 | As example of usage Documentation/connector now contains cn_test.c - | 125 | As example of this usage can be found in the cn_test.c module which |
124 | testing module which uses connector to request notification and to | 126 | uses the connector to request notification and to send messages. |
125 | send messages. | ||
126 | 127 | ||
127 | /*****************************************/ | 128 | /*****************************************/ |
128 | Reliability. | 129 | Reliability. |
129 | /*****************************************/ | 130 | /*****************************************/ |
130 | 131 | ||
131 | Netlink itself is not reliable protocol, that means that messages can | 132 | Netlink itself is not a reliable protocol. That means that messages can |
132 | be lost due to memory pressure or process' receiving queue overflowed, | 133 | be lost due to memory pressure or process' receiving queue overflowed, |
133 | so caller is warned must be prepared. That is why struct cn_msg [main | 134 | so caller is warned that it must be prepared. That is why the struct |
134 | connector's message header] contains u32 seq and u32 ack fields. | 135 | cn_msg [main connector's message header] contains u32 seq and u32 ack |
136 | fields. | ||
135 | 137 | ||
136 | /*****************************************/ | 138 | /*****************************************/ |
137 | Userspace usage. | 139 | Userspace usage. |
138 | /*****************************************/ | 140 | /*****************************************/ |
141 | |||
139 | 2.6.14 has a new netlink socket implementation, which by default does not | 142 | 2.6.14 has a new netlink socket implementation, which by default does not |
140 | allow to send data to netlink groups other than 1. | 143 | allow people to send data to netlink groups other than 1. |
141 | So, if to use netlink socket (for example using connector) | 144 | So, if you wish to use a netlink socket (for example using connector) |
142 | with different group number userspace application must subscribe to | 145 | with a different group number, the userspace application must subscribe to |
143 | that group. It can be achieved by following pseudocode: | 146 | that group first. It can be achieved by the following pseudocode: |
144 | 147 | ||
145 | s = socket(PF_NETLINK, SOCK_DGRAM, NETLINK_CONNECTOR); | 148 | s = 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 | ||
162 | Where 270 above is SOL_NETLINK, and 1 is a NETLINK_ADD_MEMBERSHIP socket | 165 | Where 270 above is SOL_NETLINK, and 1 is a NETLINK_ADD_MEMBERSHIP socket |
163 | option. To drop multicast subscription one should call above socket option | 166 | option. To drop a multicast subscription, one should call the above socket |
164 | with NETLINK_DROP_MEMBERSHIP parameter which is defined as 0. | 167 | option with the NETLINK_DROP_MEMBERSHIP parameter which is defined as 0. |
165 | 168 | ||
166 | 2.6.14 netlink code only allows to select a group which is less or equal to | 169 | 2.6.14 netlink code only allows to select a group which is less or equal to |
167 | the maximum group number, which is used at netlink_kernel_create() time. | 170 | the 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 | ||
92 | static 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 | |||
86 | int main(int argc, char *argv[]) | 111 | int 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 | ||
191 | Problem: Files copied from sysfs appear empty or incomplete. | ||
192 | Cause: Due to the way seq_file works, some tools such as cp or tar | ||
193 | may not correctly copy files from sysfs. | ||
194 | Solution: Use 'cat' to read .gcda files and 'cp -d' to copy links. | ||
195 | Alternatively use the mechanism shown in Appendix B. | ||
196 | |||
191 | 197 | ||
192 | Appendix A: gather_on_build.sh | 198 | Appendix A: gather_on_build.sh |
193 | ============================== | 199 | ============================== |
194 | 200 | ||
195 | Sample script to gather coverage meta files on the build machine | 201 | Sample 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 | ||
200 | KSRC=$1 | 205 | KSRC=$1 |
@@ -226,7 +231,7 @@ Appendix B: gather_on_test.sh | |||
226 | Sample script to gather coverage data files on the test machine | 231 | Sample 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 | ||
231 | DEST=$1 | 236 | DEST=$1 |
232 | GCDA=/sys/kernel/debug/gcov | 237 | GCDA=/sys/kernel/debug/gcov |
@@ -236,11 +241,13 @@ if [ -z "$DEST" ] ; then | |||
236 | exit 1 | 241 | exit 1 |
237 | fi | 242 | fi |
238 | 243 | ||
239 | find $GCDA -name '*.gcno' -o -name '*.gcda' | tar cfz $DEST -T - | 244 | TEMPDIR=$(mktemp -d) |
245 | echo Collecting data.. | ||
246 | find $GCDA -type d -exec mkdir -p $TEMPDIR/\{\} \; | ||
247 | find $GCDA -name '*.gcda' -exec sh -c 'cat < $0 > '$TEMPDIR'/$0' {} \; | ||
248 | find $GCDA -name '*.gcno' -exec sh -c 'cp -d $0 '$TEMPDIR'/$0' {} \; | ||
249 | tar czf $DEST -C $TEMPDIR sys | ||
250 | rm -rf $TEMPDIR | ||
240 | 251 | ||
241 | if [ $? -eq 0 ] ; then | 252 | echo "$DEST successfully created, copy to build system and unpack with:" |
242 | echo "$DEST successfully created, copy to build system and unpack with:" | 253 | echo " tar xfz $DEST" |
243 | echo " tar xfz $DEST" | ||
244 | else | ||
245 | echo "Could not create file $DEST" | ||
246 | fi | ||
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 | ||
18 | CONFIG_DEBUG_KMEMLEAK in "Kernel hacking" has to be enabled. A kernel | 18 | CONFIG_DEBUG_KMEMLEAK in "Kernel hacking" has to be enabled. A kernel |
19 | thread scans the memory every 10 minutes (by default) and prints any new | 19 | thread scans the memory every 10 minutes (by default) and prints the |
20 | unreferenced objects found. To trigger an intermediate scan and display | 20 | number of new unreferenced objects found. To display the details of all |
21 | all the possible memory leaks: | 21 | the 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 | ||
26 | To trigger an intermediate memory scan: | ||
27 | |||
28 | # echo scan > /sys/kernel/debug/kmemleak | ||
29 | |||
26 | Note that the orphan objects are listed in the order they were allocated | 30 | Note that the orphan objects are listed in the order they were allocated |
27 | and one object at the beginning of the list may cause other subsequent | 31 | and one object at the beginning of the list may cause other subsequent |
28 | objects to be reported as orphan. | 32 | objects 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 | ||
41 | Kmemleak can also be disabled at boot-time by passing "kmemleak=off" on | 46 | Kmemleak can also be disabled at boot-time by passing "kmemleak=off" on |
42 | the kernel command line. | 47 | the kernel command line. |
43 | 48 | ||
49 | Memory may be allocated or freed before kmemleak is initialised and | ||
50 | these actions are stored in an early log buffer. The size of this buffer | ||
51 | is configured via the CONFIG_DEBUG_KMEMLEAK_EARLY_LOG_SIZE option. | ||
52 | |||
44 | Basic Algorithm | 53 | Basic 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 @@ | |||
1 | Kernel 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 | |||
10 | Authors: | ||
11 | Antonio Ospite <ospite@studenti.unina.it> | ||
12 | |||
13 | |||
14 | Description | ||
15 | ----------- | ||
16 | The LP3944 is a helper chip that can drive up to 8 leds, with two programmable | ||
17 | DIM modes; it could even be used as a gpio expander but this driver assumes it | ||
18 | is used as a led controller. | ||
19 | |||
20 | The DIM modes are used to set _blink_ patterns for leds, the pattern is | ||
21 | specified 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 | |||
25 | Setting a led in DIM0 or DIM1 mode makes it blink according to the pattern. | ||
26 | See the datasheet for details. | ||
27 | |||
28 | LP3944 can be found on Motorola A910 smartphone, where it drives the rgb | ||
29 | leds, the camera flash light and the lcds power. | ||
30 | |||
31 | |||
32 | Notes | ||
33 | ----- | ||
34 | The chip is used mainly in embedded contexts, so this driver expects it is | ||
35 | registered using the i2c_board_info mechanism. | ||
36 | |||
37 | To register the chip at address 0x60 on adapter 0, set the platform data | ||
38 | according 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 | |||
47 | and 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). |
61 | generic_netlink.txt | 61 | generic_netlink.txt |
62 | - info on Generic Netlink | 62 | - info on Generic Netlink |
63 | ieee802154.txt | ||
64 | - Linux IEEE 802.15.4 implementation, API and drivers | ||
63 | ip-sysctl.txt | 65 | ip-sysctl.txt |
64 | - /proc/sys/net/ipv4/* variables | 66 | - /proc/sys/net/ipv4/* variables |
65 | ip_dynaddr.txt | 67 | ip_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 | |||
69 | SoftMAC | 69 | SoftMAC |
70 | ======= | 70 | ======= |
71 | 71 | ||
72 | We are going to provide intermediate layer impelementing IEEE 802.15.4 MAC | 72 | We are going to provide intermediate layer implementing IEEE 802.15.4 MAC |
73 | in software. This is currently WIP. | 73 | in software. This is currently WIP. |
74 | 74 | ||
75 | See header include/net/ieee802154/mac802154.h and several drivers in | 75 | See 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 | |||
1238 | defined; this list will expand as more and more SOC-containing | 1238 | defined; this list will expand as more and more SOC-containing |
1239 | platforms are moved over to use the flattened-device-tree model. | 1239 | platforms are moved over to use the flattened-device-tree model. |
1240 | 1240 | ||
1241 | a) PHY nodes | 1241 | VII - 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 | |||
1835 | VII - Marvell Discovery mv64[345]6x System Controller chips | ||
1836 | =========================================================== | ||
1837 | |||
1838 | The Marvell mv64[345]60 series of system controller chips contain | ||
1839 | many of the peripherals needed to implement a complete computer | ||
1840 | system. In this section, we define device tree nodes to describe | ||
1841 | the system controller chip itself and each of the peripherals | ||
1842 | which it contains. Compatible string values for each node are | ||
1843 | prefixed with the string "marvell,", for Marvell Technology Group Ltd. | ||
1844 | |||
1845 | 1) 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 | |||
1904 | 2) 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 | |||
2356 | VIII - Specifying interrupt information for devices | ||
2357 | =================================================== | 1242 | =================================================== |
2358 | 1243 | ||
2359 | The device tree represents the busses and devices of a hardware | 1244 | The 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 | ||
2442 | IX - Specifying GPIO information for devices | 1327 | VIII - Specifying Device Power Management Information (sleep property) |
2443 | ============================================ | ||
2444 | |||
2445 | 1) gpios property | ||
2446 | ----------------- | ||
2447 | |||
2448 | Nodes that makes use of GPIOs should define them using `gpios' property, | ||
2449 | format 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 | |||
2455 | Note that gpio-specifier length is controller dependent. | ||
2456 | |||
2457 | gpio-specifier may encode: bank, pin position inside the bank, | ||
2458 | whether pin is open-drain and whether pin is logically inverted. | ||
2459 | |||
2460 | Example of the node using GPIOs: | ||
2461 | |||
2462 | node { | ||
2463 | gpios = <&qe_pio_e 18 0>; | ||
2464 | }; | ||
2465 | |||
2466 | In this example gpio-specifier is "18 0" and encodes GPIO pin number, | ||
2467 | and empty GPIO flags as accepted by the "qe_pio_e" gpio-controller. | ||
2468 | |||
2469 | 2) gpio-controller nodes | ||
2470 | ------------------------ | ||
2471 | |||
2472 | Every GPIO controller node must have #gpio-cells property defined, | ||
2473 | this information will be used to translate gpio-specifiers. | ||
2474 | |||
2475 | Example 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 | |||
2491 | X - Specifying Device Power Management Information (sleep property) | ||
2492 | =================================================================== | 1328 | =================================================================== |
2493 | 1329 | ||
2494 | Devices on SOCs often have mechanisms for placing devices into low-power | 1330 | Devices 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 @@ | |||
1 | Specifying GPIO information for devices | ||
2 | ============================================ | ||
3 | |||
4 | 1) gpios property | ||
5 | ----------------- | ||
6 | |||
7 | Nodes that makes use of GPIOs should define them using `gpios' property, | ||
8 | format 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 | |||
14 | Note that gpio-specifier length is controller dependent. | ||
15 | |||
16 | gpio-specifier may encode: bank, pin position inside the bank, | ||
17 | whether pin is open-drain and whether pin is logically inverted. | ||
18 | |||
19 | Example of the node using GPIOs: | ||
20 | |||
21 | node { | ||
22 | gpios = <&qe_pio_e 18 0>; | ||
23 | }; | ||
24 | |||
25 | In this example gpio-specifier is "18 0" and encodes GPIO pin number, | ||
26 | and empty GPIO flags as accepted by the "qe_pio_e" gpio-controller. | ||
27 | |||
28 | 2) gpio-controller nodes | ||
29 | ------------------------ | ||
30 | |||
31 | Every GPIO controller node must have #gpio-cells property defined, | ||
32 | this information will be used to translate gpio-specifiers. | ||
33 | |||
34 | Example 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 | ||
24 | Examples: | 31 | Examples: |
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 | ||
35 | run-control { | 48 | run-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 @@ | |||
1 | MDIO on GPIOs | ||
2 | |||
3 | Currently defined compatibles: | ||
4 | - virtual,gpio-mdio | ||
5 | |||
6 | MDC and MDIO lines connected to GPIO controllers are listed in the | ||
7 | gpios property as described in section VIII.1 in the following order: | ||
8 | |||
9 | MDC, MDIO. | ||
10 | |||
11 | Example: | ||
12 | |||
13 | mdio { | ||
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 @@ | |||
1 | Marvell Discovery mv64[345]6x System Controller chips | ||
2 | =========================================================== | ||
3 | |||
4 | The Marvell mv64[345]60 series of system controller chips contain | ||
5 | many of the peripherals needed to implement a complete computer | ||
6 | system. In this section, we define device tree nodes to describe | ||
7 | the system controller chip itself and each of the peripherals | ||
8 | which it contains. Compatible string values for each node are | ||
9 | prefixed with the string "marvell,", for Marvell Technology Group Ltd. | ||
10 | |||
11 | 1) 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 | |||
70 | 2) 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 @@ | |||
1 | PHY nodes | ||
2 | |||
3 | Required 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 | |||
17 | Example: | ||
18 | |||
19 | ethernet-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 @@ | |||
1 | SPI (Serial Peripheral Interface) busses | ||
2 | |||
3 | SPI busses can be described with a node for the SPI master device | ||
4 | and a set of child nodes for each SPI slave on the bus. For this | ||
5 | discussion, it is assumed that the system's SPI controller is in | ||
6 | SPI master mode. This binding does not describe SPI controllers | ||
7 | in slave mode. | ||
8 | |||
9 | The 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. | ||
15 | No other properties are required in the SPI bus node. It is assumed | ||
16 | that a driver for an SPI bus device will understand that it is an SPI bus. | ||
17 | However, the binding does not attempt to define the specific method for | ||
18 | assigning chip select numbers. Since SPI chip select configuration is | ||
19 | flexible and non-standardized, it is left out of this binding with the | ||
20 | assumption that board specific platform code will be used to manage | ||
21 | chip selects. Individual drivers can define additional properties to | ||
22 | support describing the chip select layout. | ||
23 | |||
24 | SPI slave nodes must be children of the SPI master node and can | ||
25 | contain 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 | |||
37 | SPI 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 @@ | |||
1 | USB EHCI controllers | ||
2 | |||
3 | Required 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. | ||
10 | If device registers are implemented in big endian mode, the device | ||
11 | node should have "big-endian-regs" property. | ||
12 | If controller implementation operates with big endian descriptors, | ||
13 | "big-endian-desc" property should be specified. | ||
14 | If both big endian registers and descriptors are used by the controller | ||
15 | implementation, "big-endian" property can be specified instead of having | ||
16 | both "big-endian-regs" and "big-endian-desc". | ||
17 | |||
18 | Example (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 | ||
244 | AD1988/AD1988B/AD1989A/AD1989B | 245 | AD1988/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; |