diff options
Diffstat (limited to 'Documentation')
-rw-r--r-- | Documentation/ABI/testing/sysfs-bus-pci | 10 | ||||
-rw-r--r-- | Documentation/DocBook/uio-howto.tmpl | 163 | ||||
-rw-r--r-- | Documentation/PCI/pci-error-recovery.txt | 119 | ||||
-rw-r--r-- | Documentation/arm/OMAP/omap_pm | 129 | ||||
-rw-r--r-- | Documentation/cpu-freq/user-guide.txt | 9 | ||||
-rw-r--r-- | Documentation/dontdiff | 1 | ||||
-rw-r--r-- | Documentation/feature-removal-schedule.txt | 10 | ||||
-rw-r--r-- | Documentation/hwmon/pcf8591 | 28 | ||||
-rw-r--r-- | Documentation/hwmon/tmp421 | 36 | ||||
-rw-r--r-- | Documentation/hwmon/wm831x | 37 | ||||
-rw-r--r-- | Documentation/hwmon/wm8350 | 26 | ||||
-rw-r--r-- | Documentation/kernel-parameters.txt | 4 | ||||
-rw-r--r-- | Documentation/trace/events.txt | 208 | ||||
-rw-r--r-- | Documentation/trace/ftrace-design.txt | 233 | ||||
-rw-r--r-- | Documentation/trace/ftrace.txt | 6 | ||||
-rw-r--r-- | Documentation/vgaarbiter.txt | 194 |
16 files changed, 1132 insertions, 81 deletions
diff --git a/Documentation/ABI/testing/sysfs-bus-pci b/Documentation/ABI/testing/sysfs-bus-pci index 6bf68053e4b8..25be3250f7d6 100644 --- a/Documentation/ABI/testing/sysfs-bus-pci +++ b/Documentation/ABI/testing/sysfs-bus-pci | |||
@@ -84,6 +84,16 @@ Description: | |||
84 | from this part of the device tree. | 84 | from this part of the device tree. |
85 | Depends on CONFIG_HOTPLUG. | 85 | Depends on CONFIG_HOTPLUG. |
86 | 86 | ||
87 | What: /sys/bus/pci/devices/.../reset | ||
88 | Date: July 2009 | ||
89 | Contact: Michael S. Tsirkin <mst@redhat.com> | ||
90 | Description: | ||
91 | Some devices allow an individual function to be reset | ||
92 | without affecting other functions in the same device. | ||
93 | For devices that have this support, a file named reset | ||
94 | will be present in sysfs. Writing 1 to this file | ||
95 | will perform reset. | ||
96 | |||
87 | What: /sys/bus/pci/devices/.../vpd | 97 | What: /sys/bus/pci/devices/.../vpd |
88 | Date: February 2008 | 98 | Date: February 2008 |
89 | Contact: Ben Hutchings <bhutchings@solarflare.com> | 99 | Contact: Ben Hutchings <bhutchings@solarflare.com> |
diff --git a/Documentation/DocBook/uio-howto.tmpl b/Documentation/DocBook/uio-howto.tmpl index 8f6e3b2403c7..4d4ce0e61e42 100644 --- a/Documentation/DocBook/uio-howto.tmpl +++ b/Documentation/DocBook/uio-howto.tmpl | |||
@@ -25,6 +25,10 @@ | |||
25 | <year>2006-2008</year> | 25 | <year>2006-2008</year> |
26 | <holder>Hans-Jürgen Koch.</holder> | 26 | <holder>Hans-Jürgen Koch.</holder> |
27 | </copyright> | 27 | </copyright> |
28 | <copyright> | ||
29 | <year>2009</year> | ||
30 | <holder>Red Hat Inc, Michael S. Tsirkin (mst@redhat.com)</holder> | ||
31 | </copyright> | ||
28 | 32 | ||
29 | <legalnotice> | 33 | <legalnotice> |
30 | <para> | 34 | <para> |
@@ -42,6 +46,13 @@ GPL version 2. | |||
42 | 46 | ||
43 | <revhistory> | 47 | <revhistory> |
44 | <revision> | 48 | <revision> |
49 | <revnumber>0.9</revnumber> | ||
50 | <date>2009-07-16</date> | ||
51 | <authorinitials>mst</authorinitials> | ||
52 | <revremark>Added generic pci driver | ||
53 | </revremark> | ||
54 | </revision> | ||
55 | <revision> | ||
45 | <revnumber>0.8</revnumber> | 56 | <revnumber>0.8</revnumber> |
46 | <date>2008-12-24</date> | 57 | <date>2008-12-24</date> |
47 | <authorinitials>hjk</authorinitials> | 58 | <authorinitials>hjk</authorinitials> |
@@ -809,6 +820,158 @@ framework to set up sysfs files for this region. Simply leave it alone. | |||
809 | 820 | ||
810 | </chapter> | 821 | </chapter> |
811 | 822 | ||
823 | <chapter id="uio_pci_generic" xreflabel="Using Generic driver for PCI cards"> | ||
824 | <?dbhtml filename="uio_pci_generic.html"?> | ||
825 | <title>Generic PCI UIO driver</title> | ||
826 | <para> | ||
827 | The generic driver is a kernel module named uio_pci_generic. | ||
828 | It can work with any device compliant to PCI 2.3 (circa 2002) and | ||
829 | any compliant PCI Express device. Using this, you only need to | ||
830 | write the userspace driver, removing the need to write | ||
831 | a hardware-specific kernel module. | ||
832 | </para> | ||
833 | |||
834 | <sect1 id="uio_pci_generic_binding"> | ||
835 | <title>Making the driver recognize the device</title> | ||
836 | <para> | ||
837 | Since the driver does not declare any device ids, it will not get loaded | ||
838 | automatically and will not automatically bind to any devices, you must load it | ||
839 | and allocate id to the driver yourself. For example: | ||
840 | <programlisting> | ||
841 | modprobe uio_pci_generic | ||
842 | echo "8086 10f5" > /sys/bus/pci/drivers/uio_pci_generic/new_id | ||
843 | </programlisting> | ||
844 | </para> | ||
845 | <para> | ||
846 | If there already is a hardware specific kernel driver for your device, the | ||
847 | generic driver still won't bind to it, in this case if you want to use the | ||
848 | generic driver (why would you?) you'll have to manually unbind the hardware | ||
849 | specific driver and bind the generic driver, like this: | ||
850 | <programlisting> | ||
851 | echo -n 0000:00:19.0 > /sys/bus/pci/drivers/e1000e/unbind | ||
852 | echo -n 0000:00:19.0 > /sys/bus/pci/drivers/uio_pci_generic/bind | ||
853 | </programlisting> | ||
854 | </para> | ||
855 | <para> | ||
856 | You can verify that the device has been bound to the driver | ||
857 | by looking for it in sysfs, for example like the following: | ||
858 | <programlisting> | ||
859 | ls -l /sys/bus/pci/devices/0000:00:19.0/driver | ||
860 | </programlisting> | ||
861 | Which if successful should print | ||
862 | <programlisting> | ||
863 | .../0000:00:19.0/driver -> ../../../bus/pci/drivers/uio_pci_generic | ||
864 | </programlisting> | ||
865 | Note that the generic driver will not bind to old PCI 2.2 devices. | ||
866 | If binding the device failed, run the following command: | ||
867 | <programlisting> | ||
868 | dmesg | ||
869 | </programlisting> | ||
870 | and look in the output for failure reasons | ||
871 | </para> | ||
872 | </sect1> | ||
873 | |||
874 | <sect1 id="uio_pci_generic_internals"> | ||
875 | <title>Things to know about uio_pci_generic</title> | ||
876 | <para> | ||
877 | Interrupts are handled using the Interrupt Disable bit in the PCI command | ||
878 | register and Interrupt Status bit in the PCI status register. All devices | ||
879 | compliant to PCI 2.3 (circa 2002) and all compliant PCI Express devices should | ||
880 | support these bits. uio_pci_generic detects this support, and won't bind to | ||
881 | devices which do not support the Interrupt Disable Bit in the command register. | ||
882 | </para> | ||
883 | <para> | ||
884 | On each interrupt, uio_pci_generic sets the Interrupt Disable bit. | ||
885 | This prevents the device from generating further interrupts | ||
886 | until the bit is cleared. The userspace driver should clear this | ||
887 | bit before blocking and waiting for more interrupts. | ||
888 | </para> | ||
889 | </sect1> | ||
890 | <sect1 id="uio_pci_generic_userspace"> | ||
891 | <title>Writing userspace driver using uio_pci_generic</title> | ||
892 | <para> | ||
893 | Userspace driver can use pci sysfs interface, or the | ||
894 | libpci libray that wraps it, to talk to the device and to | ||
895 | re-enable interrupts by writing to the command register. | ||
896 | </para> | ||
897 | </sect1> | ||
898 | <sect1 id="uio_pci_generic_example"> | ||
899 | <title>Example code using uio_pci_generic</title> | ||
900 | <para> | ||
901 | Here is some sample userspace driver code using uio_pci_generic: | ||
902 | <programlisting> | ||
903 | #include <stdlib.h> | ||
904 | #include <stdio.h> | ||
905 | #include <unistd.h> | ||
906 | #include <sys/types.h> | ||
907 | #include <sys/stat.h> | ||
908 | #include <fcntl.h> | ||
909 | #include <errno.h> | ||
910 | |||
911 | int main() | ||
912 | { | ||
913 | int uiofd; | ||
914 | int configfd; | ||
915 | int err; | ||
916 | int i; | ||
917 | unsigned icount; | ||
918 | unsigned char command_high; | ||
919 | |||
920 | uiofd = open("/dev/uio0", O_RDONLY); | ||
921 | if (uiofd < 0) { | ||
922 | perror("uio open:"); | ||
923 | return errno; | ||
924 | } | ||
925 | configfd = open("/sys/class/uio/uio0/device/config", O_RDWR); | ||
926 | if (uiofd < 0) { | ||
927 | perror("config open:"); | ||
928 | return errno; | ||
929 | } | ||
930 | |||
931 | /* Read and cache command value */ | ||
932 | err = pread(configfd, &command_high, 1, 5); | ||
933 | if (err != 1) { | ||
934 | perror("command config read:"); | ||
935 | return errno; | ||
936 | } | ||
937 | command_high &= ~0x4; | ||
938 | |||
939 | for(i = 0;; ++i) { | ||
940 | /* Print out a message, for debugging. */ | ||
941 | if (i == 0) | ||
942 | fprintf(stderr, "Started uio test driver.\n"); | ||
943 | else | ||
944 | fprintf(stderr, "Interrupts: %d\n", icount); | ||
945 | |||
946 | /****************************************/ | ||
947 | /* Here we got an interrupt from the | ||
948 | device. Do something to it. */ | ||
949 | /****************************************/ | ||
950 | |||
951 | /* Re-enable interrupts. */ | ||
952 | err = pwrite(configfd, &command_high, 1, 5); | ||
953 | if (err != 1) { | ||
954 | perror("config write:"); | ||
955 | break; | ||
956 | } | ||
957 | |||
958 | /* Wait for next interrupt. */ | ||
959 | err = read(uiofd, &icount, 4); | ||
960 | if (err != 4) { | ||
961 | perror("uio read:"); | ||
962 | break; | ||
963 | } | ||
964 | |||
965 | } | ||
966 | return errno; | ||
967 | } | ||
968 | |||
969 | </programlisting> | ||
970 | </para> | ||
971 | </sect1> | ||
972 | |||
973 | </chapter> | ||
974 | |||
812 | <appendix id="app1"> | 975 | <appendix id="app1"> |
813 | <title>Further information</title> | 976 | <title>Further information</title> |
814 | <itemizedlist> | 977 | <itemizedlist> |
diff --git a/Documentation/PCI/pci-error-recovery.txt b/Documentation/PCI/pci-error-recovery.txt index 6650af432523..e83f2ea76415 100644 --- a/Documentation/PCI/pci-error-recovery.txt +++ b/Documentation/PCI/pci-error-recovery.txt | |||
@@ -4,15 +4,17 @@ | |||
4 | February 2, 2006 | 4 | February 2, 2006 |
5 | 5 | ||
6 | Current document maintainer: | 6 | Current document maintainer: |
7 | Linas Vepstas <linas@austin.ibm.com> | 7 | Linas Vepstas <linasvepstas@gmail.com> |
8 | updated by Richard Lary <rlary@us.ibm.com> | ||
9 | and Mike Mason <mmlnx@us.ibm.com> on 27-Jul-2009 | ||
8 | 10 | ||
9 | 11 | ||
10 | Many PCI bus controllers are able to detect a variety of hardware | 12 | Many PCI bus controllers are able to detect a variety of hardware |
11 | PCI errors on the bus, such as parity errors on the data and address | 13 | PCI errors on the bus, such as parity errors on the data and address |
12 | busses, as well as SERR and PERR errors. Some of the more advanced | 14 | busses, as well as SERR and PERR errors. Some of the more advanced |
13 | chipsets are able to deal with these errors; these include PCI-E chipsets, | 15 | chipsets are able to deal with these errors; these include PCI-E chipsets, |
14 | and the PCI-host bridges found on IBM Power4 and Power5-based pSeries | 16 | and the PCI-host bridges found on IBM Power4, Power5 and Power6-based |
15 | boxes. A typical action taken is to disconnect the affected device, | 17 | pSeries boxes. A typical action taken is to disconnect the affected device, |
16 | halting all I/O to it. The goal of a disconnection is to avoid system | 18 | halting all I/O to it. The goal of a disconnection is to avoid system |
17 | corruption; for example, to halt system memory corruption due to DMA's | 19 | corruption; for example, to halt system memory corruption due to DMA's |
18 | to "wild" addresses. Typically, a reconnection mechanism is also | 20 | to "wild" addresses. Typically, a reconnection mechanism is also |
@@ -37,10 +39,11 @@ is forced by the need to handle multi-function devices, that is, | |||
37 | devices that have multiple device drivers associated with them. | 39 | devices that have multiple device drivers associated with them. |
38 | In the first stage, each driver is allowed to indicate what type | 40 | In the first stage, each driver is allowed to indicate what type |
39 | of reset it desires, the choices being a simple re-enabling of I/O | 41 | of reset it desires, the choices being a simple re-enabling of I/O |
40 | or requesting a hard reset (a full electrical #RST of the PCI card). | 42 | or requesting a slot reset. |
41 | If any driver requests a full reset, that is what will be done. | ||
42 | 43 | ||
43 | After a full reset and/or a re-enabling of I/O, all drivers are | 44 | If any driver requests a slot reset, that is what will be done. |
45 | |||
46 | After a reset and/or a re-enabling of I/O, all drivers are | ||
44 | again notified, so that they may then perform any device setup/config | 47 | again notified, so that they may then perform any device setup/config |
45 | that may be required. After these have all completed, a final | 48 | that may be required. After these have all completed, a final |
46 | "resume normal operations" event is sent out. | 49 | "resume normal operations" event is sent out. |
@@ -101,7 +104,7 @@ if it implements any, it must implement error_detected(). If a callback | |||
101 | is not implemented, the corresponding feature is considered unsupported. | 104 | is not implemented, the corresponding feature is considered unsupported. |
102 | For example, if mmio_enabled() and resume() aren't there, then it | 105 | For example, if mmio_enabled() and resume() aren't there, then it |
103 | is assumed that the driver is not doing any direct recovery and requires | 106 | is assumed that the driver is not doing any direct recovery and requires |
104 | a reset. If link_reset() is not implemented, the card is assumed as | 107 | a slot reset. If link_reset() is not implemented, the card is assumed to |
105 | not care about link resets. Typically a driver will want to know about | 108 | not care about link resets. Typically a driver will want to know about |
106 | a slot_reset(). | 109 | a slot_reset(). |
107 | 110 | ||
@@ -111,7 +114,7 @@ sequence described below. | |||
111 | 114 | ||
112 | STEP 0: Error Event | 115 | STEP 0: Error Event |
113 | ------------------- | 116 | ------------------- |
114 | PCI bus error is detect by the PCI hardware. On powerpc, the slot | 117 | A PCI bus error is detected by the PCI hardware. On powerpc, the slot |
115 | is isolated, in that all I/O is blocked: all reads return 0xffffffff, | 118 | is isolated, in that all I/O is blocked: all reads return 0xffffffff, |
116 | all writes are ignored. | 119 | all writes are ignored. |
117 | 120 | ||
@@ -139,7 +142,7 @@ The driver must return one of the following result codes: | |||
139 | a chance to extract some diagnostic information (see | 142 | a chance to extract some diagnostic information (see |
140 | mmio_enable, below). | 143 | mmio_enable, below). |
141 | - PCI_ERS_RESULT_NEED_RESET: | 144 | - PCI_ERS_RESULT_NEED_RESET: |
142 | Driver returns this if it can't recover without a hard | 145 | Driver returns this if it can't recover without a |
143 | slot reset. | 146 | slot reset. |
144 | - PCI_ERS_RESULT_DISCONNECT: | 147 | - PCI_ERS_RESULT_DISCONNECT: |
145 | Driver returns this if it doesn't want to recover at all. | 148 | Driver returns this if it doesn't want to recover at all. |
@@ -169,11 +172,11 @@ is STEP 6 (Permanent Failure). | |||
169 | 172 | ||
170 | >>> The current powerpc implementation doesn't much care if the device | 173 | >>> The current powerpc implementation doesn't much care if the device |
171 | >>> attempts I/O at this point, or not. I/O's will fail, returning | 174 | >>> attempts I/O at this point, or not. I/O's will fail, returning |
172 | >>> a value of 0xff on read, and writes will be dropped. If the device | 175 | >>> a value of 0xff on read, and writes will be dropped. If more than |
173 | >>> driver attempts more than 10K I/O's to a frozen adapter, it will | 176 | >>> EEH_MAX_FAILS I/O's are attempted to a frozen adapter, EEH |
174 | >>> assume that the device driver has gone into an infinite loop, and | 177 | >>> assumes that the device driver has gone into an infinite loop |
175 | >>> it will panic the kernel. There doesn't seem to be any other | 178 | >>> and prints an error to syslog. A reboot is then required to |
176 | >>> way of stopping a device driver that insists on spinning on I/O. | 179 | >>> get the device working again. |
177 | 180 | ||
178 | STEP 2: MMIO Enabled | 181 | STEP 2: MMIO Enabled |
179 | ------------------- | 182 | ------------------- |
@@ -182,15 +185,14 @@ DMA), and then calls the mmio_enabled() callback on all affected | |||
182 | device drivers. | 185 | device drivers. |
183 | 186 | ||
184 | This is the "early recovery" call. IOs are allowed again, but DMA is | 187 | This is the "early recovery" call. IOs are allowed again, but DMA is |
185 | not (hrm... to be discussed, I prefer not), with some restrictions. This | 188 | not, with some restrictions. This is NOT a callback for the driver to |
186 | is NOT a callback for the driver to start operations again, only to | 189 | start operations again, only to peek/poke at the device, extract diagnostic |
187 | peek/poke at the device, extract diagnostic information, if any, and | 190 | information, if any, and eventually do things like trigger a device local |
188 | eventually do things like trigger a device local reset or some such, | 191 | reset or some such, but not restart operations. This callback is made if |
189 | but not restart operations. This is callback is made if all drivers on | 192 | all drivers on a segment agree that they can try to recover and if no automatic |
190 | a segment agree that they can try to recover and if no automatic link reset | 193 | link reset was performed by the HW. If the platform can't just re-enable IOs |
191 | was performed by the HW. If the platform can't just re-enable IOs without | 194 | without a slot reset or a link reset, it will not call this callback, and |
192 | a slot reset or a link reset, it wont call this callback, and instead | 195 | instead will have gone directly to STEP 3 (Link Reset) or STEP 4 (Slot Reset) |
193 | will have gone directly to STEP 3 (Link Reset) or STEP 4 (Slot Reset) | ||
194 | 196 | ||
195 | >>> The following is proposed; no platform implements this yet: | 197 | >>> The following is proposed; no platform implements this yet: |
196 | >>> Proposal: All I/O's should be done _synchronously_ from within | 198 | >>> Proposal: All I/O's should be done _synchronously_ from within |
@@ -228,9 +230,6 @@ proceeds to either STEP3 (Link Reset) or to STEP 5 (Resume Operations). | |||
228 | If any driver returned PCI_ERS_RESULT_NEED_RESET, then the platform | 230 | If any driver returned PCI_ERS_RESULT_NEED_RESET, then the platform |
229 | proceeds to STEP 4 (Slot Reset) | 231 | proceeds to STEP 4 (Slot Reset) |
230 | 232 | ||
231 | >>> The current powerpc implementation does not implement this callback. | ||
232 | |||
233 | |||
234 | STEP 3: Link Reset | 233 | STEP 3: Link Reset |
235 | ------------------ | 234 | ------------------ |
236 | The platform resets the link, and then calls the link_reset() callback | 235 | The platform resets the link, and then calls the link_reset() callback |
@@ -253,16 +252,33 @@ The platform then proceeds to either STEP 4 (Slot Reset) or STEP 5 | |||
253 | 252 | ||
254 | >>> The current powerpc implementation does not implement this callback. | 253 | >>> The current powerpc implementation does not implement this callback. |
255 | 254 | ||
256 | |||
257 | STEP 4: Slot Reset | 255 | STEP 4: Slot Reset |
258 | ------------------ | 256 | ------------------ |
259 | The platform performs a soft or hard reset of the device, and then | ||
260 | calls the slot_reset() callback. | ||
261 | 257 | ||
262 | A soft reset consists of asserting the adapter #RST line and then | 258 | In response to a return value of PCI_ERS_RESULT_NEED_RESET, the |
259 | the platform will peform a slot reset on the requesting PCI device(s). | ||
260 | The actual steps taken by a platform to perform a slot reset | ||
261 | will be platform-dependent. Upon completion of slot reset, the | ||
262 | platform will call the device slot_reset() callback. | ||
263 | |||
264 | Powerpc platforms implement two levels of slot reset: | ||
265 | soft reset(default) and fundamental(optional) reset. | ||
266 | |||
267 | Powerpc soft reset consists of asserting the adapter #RST line and then | ||
263 | restoring the PCI BAR's and PCI configuration header to a state | 268 | restoring the PCI BAR's and PCI configuration header to a state |
264 | that is equivalent to what it would be after a fresh system | 269 | that is equivalent to what it would be after a fresh system |
265 | power-on followed by power-on BIOS/system firmware initialization. | 270 | power-on followed by power-on BIOS/system firmware initialization. |
271 | Soft reset is also known as hot-reset. | ||
272 | |||
273 | Powerpc fundamental reset is supported by PCI Express cards only | ||
274 | and results in device's state machines, hardware logic, port states and | ||
275 | configuration registers to initialize to their default conditions. | ||
276 | |||
277 | For most PCI devices, a soft reset will be sufficient for recovery. | ||
278 | Optional fundamental reset is provided to support a limited number | ||
279 | of PCI Express PCI devices for which a soft reset is not sufficient | ||
280 | for recovery. | ||
281 | |||
266 | If the platform supports PCI hotplug, then the reset might be | 282 | If the platform supports PCI hotplug, then the reset might be |
267 | performed by toggling the slot electrical power off/on. | 283 | performed by toggling the slot electrical power off/on. |
268 | 284 | ||
@@ -274,10 +290,12 @@ may result in hung devices, kernel panics, or silent data corruption. | |||
274 | 290 | ||
275 | This call gives drivers the chance to re-initialize the hardware | 291 | This call gives drivers the chance to re-initialize the hardware |
276 | (re-download firmware, etc.). At this point, the driver may assume | 292 | (re-download firmware, etc.). At this point, the driver may assume |
277 | that he card is in a fresh state and is fully functional. In | 293 | that the card is in a fresh state and is fully functional. The slot |
278 | particular, interrupt generation should work normally. | 294 | is unfrozen and the driver has full access to PCI config space, |
295 | memory mapped I/O space and DMA. Interrupts (Legacy, MSI, or MSI-X) | ||
296 | will also be available. | ||
279 | 297 | ||
280 | Drivers should not yet restart normal I/O processing operations | 298 | Drivers should not restart normal I/O processing operations |
281 | at this point. If all device drivers report success on this | 299 | at this point. If all device drivers report success on this |
282 | callback, the platform will call resume() to complete the sequence, | 300 | callback, the platform will call resume() to complete the sequence, |
283 | and let the driver restart normal I/O processing. | 301 | and let the driver restart normal I/O processing. |
@@ -302,11 +320,21 @@ driver performs device init only from PCI function 0: | |||
302 | - PCI_ERS_RESULT_DISCONNECT | 320 | - PCI_ERS_RESULT_DISCONNECT |
303 | Same as above. | 321 | Same as above. |
304 | 322 | ||
323 | Drivers for PCI Express cards that require a fundamental reset must | ||
324 | set the needs_freset bit in the pci_dev structure in their probe function. | ||
325 | For example, the QLogic qla2xxx driver sets the needs_freset bit for certain | ||
326 | PCI card types: | ||
327 | |||
328 | + /* Set EEH reset type to fundamental if required by hba */ | ||
329 | + if (IS_QLA24XX(ha) || IS_QLA25XX(ha) || IS_QLA81XX(ha)) | ||
330 | + pdev->needs_freset = 1; | ||
331 | + | ||
332 | |||
305 | Platform proceeds either to STEP 5 (Resume Operations) or STEP 6 (Permanent | 333 | Platform proceeds either to STEP 5 (Resume Operations) or STEP 6 (Permanent |
306 | Failure). | 334 | Failure). |
307 | 335 | ||
308 | >>> The current powerpc implementation does not currently try a | 336 | >>> The current powerpc implementation does not try a power-cycle |
309 | >>> power-cycle reset if the driver returned PCI_ERS_RESULT_DISCONNECT. | 337 | >>> reset if the driver returned PCI_ERS_RESULT_DISCONNECT. |
310 | >>> However, it probably should. | 338 | >>> However, it probably should. |
311 | 339 | ||
312 | 340 | ||
@@ -348,7 +376,7 @@ software errors. | |||
348 | 376 | ||
349 | Conclusion; General Remarks | 377 | Conclusion; General Remarks |
350 | --------------------------- | 378 | --------------------------- |
351 | The way those callbacks are called is platform policy. A platform with | 379 | The way the callbacks are called is platform policy. A platform with |
352 | no slot reset capability may want to just "ignore" drivers that can't | 380 | no slot reset capability may want to just "ignore" drivers that can't |
353 | recover (disconnect them) and try to let other cards on the same segment | 381 | recover (disconnect them) and try to let other cards on the same segment |
354 | recover. Keep in mind that in most real life cases, though, there will | 382 | recover. Keep in mind that in most real life cases, though, there will |
@@ -361,8 +389,8 @@ That is, the recovery API only requires that: | |||
361 | 389 | ||
362 | - There is no guarantee that interrupt delivery can proceed from any | 390 | - There is no guarantee that interrupt delivery can proceed from any |
363 | device on the segment starting from the error detection and until the | 391 | device on the segment starting from the error detection and until the |
364 | resume callback is sent, at which point interrupts are expected to be | 392 | slot_reset callback is called, at which point interrupts are expected |
365 | fully operational. | 393 | to be fully operational. |
366 | 394 | ||
367 | - There is no guarantee that interrupt delivery is stopped, that is, | 395 | - There is no guarantee that interrupt delivery is stopped, that is, |
368 | a driver that gets an interrupt after detecting an error, or that detects | 396 | a driver that gets an interrupt after detecting an error, or that detects |
@@ -381,16 +409,23 @@ anyway :) | |||
381 | >>> Implementation details for the powerpc platform are discussed in | 409 | >>> Implementation details for the powerpc platform are discussed in |
382 | >>> the file Documentation/powerpc/eeh-pci-error-recovery.txt | 410 | >>> the file Documentation/powerpc/eeh-pci-error-recovery.txt |
383 | 411 | ||
384 | >>> As of this writing, there are six device drivers with patches | 412 | >>> As of this writing, there is a growing list of device drivers with |
385 | >>> implementing error recovery. Not all of these patches are in | 413 | >>> patches implementing error recovery. Not all of these patches are in |
386 | >>> mainline yet. These may be used as "examples": | 414 | >>> mainline yet. These may be used as "examples": |
387 | >>> | 415 | >>> |
388 | >>> drivers/scsi/ipr.c | 416 | >>> drivers/scsi/ipr |
389 | >>> drivers/scsi/sym53cxx_2 | 417 | >>> drivers/scsi/sym53c8xx_2 |
418 | >>> drivers/scsi/qla2xxx | ||
419 | >>> drivers/scsi/lpfc | ||
420 | >>> drivers/next/bnx2.c | ||
390 | >>> drivers/next/e100.c | 421 | >>> drivers/next/e100.c |
391 | >>> drivers/net/e1000 | 422 | >>> drivers/net/e1000 |
423 | >>> drivers/net/e1000e | ||
392 | >>> drivers/net/ixgb | 424 | >>> drivers/net/ixgb |
425 | >>> drivers/net/ixgbe | ||
426 | >>> drivers/net/cxgb3 | ||
393 | >>> drivers/net/s2io.c | 427 | >>> drivers/net/s2io.c |
428 | >>> drivers/net/qlge | ||
394 | 429 | ||
395 | The End | 430 | The End |
396 | ------- | 431 | ------- |
diff --git a/Documentation/arm/OMAP/omap_pm b/Documentation/arm/OMAP/omap_pm new file mode 100644 index 000000000000..5389440aade3 --- /dev/null +++ b/Documentation/arm/OMAP/omap_pm | |||
@@ -0,0 +1,129 @@ | |||
1 | |||
2 | The OMAP PM interface | ||
3 | ===================== | ||
4 | |||
5 | This document describes the temporary OMAP PM interface. Driver | ||
6 | authors use these functions to communicate minimum latency or | ||
7 | throughput constraints to the kernel power management code. | ||
8 | Over time, the intention is to merge features from the OMAP PM | ||
9 | interface into the Linux PM QoS code. | ||
10 | |||
11 | Drivers need to express PM parameters which: | ||
12 | |||
13 | - support the range of power management parameters present in the TI SRF; | ||
14 | |||
15 | - separate the drivers from the underlying PM parameter | ||
16 | implementation, whether it is the TI SRF or Linux PM QoS or Linux | ||
17 | latency framework or something else; | ||
18 | |||
19 | - specify PM parameters in terms of fundamental units, such as | ||
20 | latency and throughput, rather than units which are specific to OMAP | ||
21 | or to particular OMAP variants; | ||
22 | |||
23 | - allow drivers which are shared with other architectures (e.g., | ||
24 | DaVinci) to add these constraints in a way which won't affect non-OMAP | ||
25 | systems, | ||
26 | |||
27 | - can be implemented immediately with minimal disruption of other | ||
28 | architectures. | ||
29 | |||
30 | |||
31 | This document proposes the OMAP PM interface, including the following | ||
32 | five power management functions for driver code: | ||
33 | |||
34 | 1. Set the maximum MPU wakeup latency: | ||
35 | (*pdata->set_max_mpu_wakeup_lat)(struct device *dev, unsigned long t) | ||
36 | |||
37 | 2. Set the maximum device wakeup latency: | ||
38 | (*pdata->set_max_dev_wakeup_lat)(struct device *dev, unsigned long t) | ||
39 | |||
40 | 3. Set the maximum system DMA transfer start latency (CORE pwrdm): | ||
41 | (*pdata->set_max_sdma_lat)(struct device *dev, long t) | ||
42 | |||
43 | 4. Set the minimum bus throughput needed by a device: | ||
44 | (*pdata->set_min_bus_tput)(struct device *dev, u8 agent_id, unsigned long r) | ||
45 | |||
46 | 5. Return the number of times the device has lost context | ||
47 | (*pdata->get_dev_context_loss_count)(struct device *dev) | ||
48 | |||
49 | |||
50 | Further documentation for all OMAP PM interface functions can be | ||
51 | found in arch/arm/plat-omap/include/mach/omap-pm.h. | ||
52 | |||
53 | |||
54 | The OMAP PM layer is intended to be temporary | ||
55 | --------------------------------------------- | ||
56 | |||
57 | The intention is that eventually the Linux PM QoS layer should support | ||
58 | the range of power management features present in OMAP3. As this | ||
59 | happens, existing drivers using the OMAP PM interface can be modified | ||
60 | to use the Linux PM QoS code; and the OMAP PM interface can disappear. | ||
61 | |||
62 | |||
63 | Driver usage of the OMAP PM functions | ||
64 | ------------------------------------- | ||
65 | |||
66 | As the 'pdata' in the above examples indicates, these functions are | ||
67 | exposed to drivers through function pointers in driver .platform_data | ||
68 | structures. The function pointers are initialized by the board-*.c | ||
69 | files to point to the corresponding OMAP PM functions: | ||
70 | .set_max_dev_wakeup_lat will point to | ||
71 | omap_pm_set_max_dev_wakeup_lat(), etc. Other architectures which do | ||
72 | not support these functions should leave these function pointers set | ||
73 | to NULL. Drivers should use the following idiom: | ||
74 | |||
75 | if (pdata->set_max_dev_wakeup_lat) | ||
76 | (*pdata->set_max_dev_wakeup_lat)(dev, t); | ||
77 | |||
78 | The most common usage of these functions will probably be to specify | ||
79 | the maximum time from when an interrupt occurs, to when the device | ||
80 | becomes accessible. To accomplish this, driver writers should use the | ||
81 | set_max_mpu_wakeup_lat() function to to constrain the MPU wakeup | ||
82 | latency, and the set_max_dev_wakeup_lat() function to constrain the | ||
83 | device wakeup latency (from clk_enable() to accessibility). For | ||
84 | example, | ||
85 | |||
86 | /* Limit MPU wakeup latency */ | ||
87 | if (pdata->set_max_mpu_wakeup_lat) | ||
88 | (*pdata->set_max_mpu_wakeup_lat)(dev, tc); | ||
89 | |||
90 | /* Limit device powerdomain wakeup latency */ | ||
91 | if (pdata->set_max_dev_wakeup_lat) | ||
92 | (*pdata->set_max_dev_wakeup_lat)(dev, td); | ||
93 | |||
94 | /* total wakeup latency in this example: (tc + td) */ | ||
95 | |||
96 | The PM parameters can be overwritten by calling the function again | ||
97 | with the new value. The settings can be removed by calling the | ||
98 | function with a t argument of -1 (except in the case of | ||
99 | set_max_bus_tput(), which should be called with an r argument of 0). | ||
100 | |||
101 | The fifth function above, omap_pm_get_dev_context_loss_count(), | ||
102 | is intended as an optimization to allow drivers to determine whether the | ||
103 | device has lost its internal context. If context has been lost, the | ||
104 | driver must restore its internal context before proceeding. | ||
105 | |||
106 | |||
107 | Other specialized interface functions | ||
108 | ------------------------------------- | ||
109 | |||
110 | The five functions listed above are intended to be usable by any | ||
111 | device driver. DSPBridge and CPUFreq have a few special requirements. | ||
112 | DSPBridge expresses target DSP performance levels in terms of OPP IDs. | ||
113 | CPUFreq expresses target MPU performance levels in terms of MPU | ||
114 | frequency. The OMAP PM interface contains functions for these | ||
115 | specialized cases to convert that input information (OPPs/MPU | ||
116 | frequency) into the form that the underlying power management | ||
117 | implementation needs: | ||
118 | |||
119 | 6. (*pdata->dsp_get_opp_table)(void) | ||
120 | |||
121 | 7. (*pdata->dsp_set_min_opp)(u8 opp_id) | ||
122 | |||
123 | 8. (*pdata->dsp_get_opp)(void) | ||
124 | |||
125 | 9. (*pdata->cpu_get_freq_table)(void) | ||
126 | |||
127 | 10. (*pdata->cpu_set_freq)(unsigned long f) | ||
128 | |||
129 | 11. (*pdata->cpu_get_freq)(void) | ||
diff --git a/Documentation/cpu-freq/user-guide.txt b/Documentation/cpu-freq/user-guide.txt index 5d5f5fadd1c2..2a5b850847c0 100644 --- a/Documentation/cpu-freq/user-guide.txt +++ b/Documentation/cpu-freq/user-guide.txt | |||
@@ -176,7 +176,9 @@ scaling_governor, and by "echoing" the name of another | |||
176 | work on some specific architectures or | 176 | work on some specific architectures or |
177 | processors. | 177 | processors. |
178 | 178 | ||
179 | cpuinfo_cur_freq : Current speed of the CPU, in KHz. | 179 | cpuinfo_cur_freq : Current frequency of the CPU as obtained from |
180 | the hardware, in KHz. This is the frequency | ||
181 | the CPU actually runs at. | ||
180 | 182 | ||
181 | scaling_available_frequencies : List of available frequencies, in KHz. | 183 | scaling_available_frequencies : List of available frequencies, in KHz. |
182 | 184 | ||
@@ -196,7 +198,10 @@ related_cpus : List of CPUs that need some sort of frequency | |||
196 | 198 | ||
197 | scaling_driver : Hardware driver for cpufreq. | 199 | scaling_driver : Hardware driver for cpufreq. |
198 | 200 | ||
199 | scaling_cur_freq : Current frequency of the CPU, in KHz. | 201 | scaling_cur_freq : Current frequency of the CPU as determined by |
202 | the governor and cpufreq core, in KHz. This is | ||
203 | the frequency the kernel thinks the CPU runs | ||
204 | at. | ||
200 | 205 | ||
201 | If you have selected the "userspace" governor which allows you to | 206 | If you have selected the "userspace" governor which allows you to |
202 | set the CPU operating frequency to a specific value, you can read out | 207 | set the CPU operating frequency to a specific value, you can read out |
diff --git a/Documentation/dontdiff b/Documentation/dontdiff index 88519daab6e9..e1efc400bed6 100644 --- a/Documentation/dontdiff +++ b/Documentation/dontdiff | |||
@@ -152,7 +152,6 @@ piggy.gz | |||
152 | piggyback | 152 | piggyback |
153 | pnmtologo | 153 | pnmtologo |
154 | ppc_defs.h* | 154 | ppc_defs.h* |
155 | promcon_tbl.c | ||
156 | pss_boot.h | 155 | pss_boot.h |
157 | qconf | 156 | qconf |
158 | raid6altivec*.c | 157 | raid6altivec*.c |
diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt index 503d21216d58..fa75220f8d34 100644 --- a/Documentation/feature-removal-schedule.txt +++ b/Documentation/feature-removal-schedule.txt | |||
@@ -428,16 +428,6 @@ Who: Johannes Berg <johannes@sipsolutions.net> | |||
428 | 428 | ||
429 | ---------------------------- | 429 | ---------------------------- |
430 | 430 | ||
431 | What: CONFIG_X86_OLD_MCE | ||
432 | When: 2.6.32 | ||
433 | Why: Remove the old legacy 32bit machine check code. This has been | ||
434 | superseded by the newer machine check code from the 64bit port, | ||
435 | but the old version has been kept around for easier testing. Note this | ||
436 | doesn't impact the old P5 and WinChip machine check handlers. | ||
437 | Who: Andi Kleen <andi@firstfloor.org> | ||
438 | |||
439 | ---------------------------- | ||
440 | |||
441 | What: lock_policy_rwsem_* and unlock_policy_rwsem_* will not be | 431 | What: lock_policy_rwsem_* and unlock_policy_rwsem_* will not be |
442 | exported interface anymore. | 432 | exported interface anymore. |
443 | When: 2.6.33 | 433 | When: 2.6.33 |
diff --git a/Documentation/hwmon/pcf8591 b/Documentation/hwmon/pcf8591 index 5628fcf4207f..e76a7892f68e 100644 --- a/Documentation/hwmon/pcf8591 +++ b/Documentation/hwmon/pcf8591 | |||
@@ -2,11 +2,11 @@ Kernel driver pcf8591 | |||
2 | ===================== | 2 | ===================== |
3 | 3 | ||
4 | Supported chips: | 4 | Supported chips: |
5 | * Philips PCF8591 | 5 | * Philips/NXP PCF8591 |
6 | Prefix: 'pcf8591' | 6 | Prefix: 'pcf8591' |
7 | Addresses scanned: I2C 0x48 - 0x4f | 7 | Addresses scanned: I2C 0x48 - 0x4f |
8 | Datasheet: Publicly available at the Philips Semiconductor website | 8 | Datasheet: Publicly available at the NXP website |
9 | http://www.semiconductors.philips.com/pip/PCF8591P.html | 9 | http://www.nxp.com/pip/PCF8591_6.html |
10 | 10 | ||
11 | Authors: | 11 | Authors: |
12 | Aurelien Jarno <aurelien@aurel32.net> | 12 | Aurelien Jarno <aurelien@aurel32.net> |
@@ -16,9 +16,10 @@ Authors: | |||
16 | 16 | ||
17 | Description | 17 | Description |
18 | ----------- | 18 | ----------- |
19 | |||
19 | The PCF8591 is an 8-bit A/D and D/A converter (4 analog inputs and one | 20 | The PCF8591 is an 8-bit A/D and D/A converter (4 analog inputs and one |
20 | analog output) for the I2C bus produced by Philips Semiconductors. It | 21 | analog output) for the I2C bus produced by Philips Semiconductors (now NXP). |
21 | is designed to provide a byte I2C interface to up to 4 separate devices. | 22 | It is designed to provide a byte I2C interface to up to 4 separate devices. |
22 | 23 | ||
23 | The PCF8591 has 4 analog inputs programmable as single-ended or | 24 | The PCF8591 has 4 analog inputs programmable as single-ended or |
24 | differential inputs : | 25 | differential inputs : |
@@ -58,8 +59,8 @@ Accessing PCF8591 via /sys interface | |||
58 | ------------------------------------- | 59 | ------------------------------------- |
59 | 60 | ||
60 | ! Be careful ! | 61 | ! Be careful ! |
61 | The PCF8591 is plainly impossible to detect ! Stupid chip. | 62 | The PCF8591 is plainly impossible to detect! Stupid chip. |
62 | So every chip with address in the interval [48..4f] is | 63 | So every chip with address in the interval [0x48..0x4f] is |
63 | detected as PCF8591. If you have other chips in this address | 64 | detected as PCF8591. If you have other chips in this address |
64 | range, the workaround is to load this module after the one | 65 | range, the workaround is to load this module after the one |
65 | for your others chips. | 66 | for your others chips. |
@@ -67,19 +68,20 @@ for your others chips. | |||
67 | On detection (i.e. insmod, modprobe et al.), directories are being | 68 | On detection (i.e. insmod, modprobe et al.), directories are being |
68 | created for each detected PCF8591: | 69 | created for each detected PCF8591: |
69 | 70 | ||
70 | /sys/bus/devices/<0>-<1>/ | 71 | /sys/bus/i2c/devices/<0>-<1>/ |
71 | where <0> is the bus the chip was detected on (e. g. i2c-0) | 72 | where <0> is the bus the chip was detected on (e. g. i2c-0) |
72 | and <1> the chip address ([48..4f]) | 73 | and <1> the chip address ([48..4f]) |
73 | 74 | ||
74 | Inside these directories, there are such files: | 75 | Inside these directories, there are such files: |
75 | in0, in1, in2, in3, out0_enable, out0_output, name | 76 | in0_input, in1_input, in2_input, in3_input, out0_enable, out0_output, name |
76 | 77 | ||
77 | Name contains chip name. | 78 | Name contains chip name. |
78 | 79 | ||
79 | The in0, in1, in2 and in3 files are RO. Reading gives the value of the | 80 | The in0_input, in1_input, in2_input and in3_input files are RO. Reading gives |
80 | corresponding channel. Depending on the current analog inputs configuration, | 81 | the value of the corresponding channel. Depending on the current analog inputs |
81 | files in2 and/or in3 do not exist. Values range are from 0 to 255 for single | 82 | configuration, files in2_input and in3_input may not exist. Values range |
82 | ended inputs and -128 to +127 for differential inputs (8-bit ADC). | 83 | from 0 to 255 for single ended inputs and -128 to +127 for differential inputs |
84 | (8-bit ADC). | ||
83 | 85 | ||
84 | The out0_enable file is RW. Reading gives "1" for analog output enabled and | 86 | The out0_enable file is RW. Reading gives "1" for analog output enabled and |
85 | "0" for analog output disabled. Writing accepts "0" and "1" accordingly. | 87 | "0" for analog output disabled. Writing accepts "0" and "1" accordingly. |
diff --git a/Documentation/hwmon/tmp421 b/Documentation/hwmon/tmp421 new file mode 100644 index 000000000000..0cf07f824741 --- /dev/null +++ b/Documentation/hwmon/tmp421 | |||
@@ -0,0 +1,36 @@ | |||
1 | Kernel driver tmp421 | ||
2 | ==================== | ||
3 | |||
4 | Supported chips: | ||
5 | * Texas Instruments TMP421 | ||
6 | Prefix: 'tmp421' | ||
7 | Addresses scanned: I2C 0x2a, 0x4c, 0x4d, 0x4e and 0x4f | ||
8 | Datasheet: http://focus.ti.com/docs/prod/folders/print/tmp421.html | ||
9 | * Texas Instruments TMP422 | ||
10 | Prefix: 'tmp422' | ||
11 | Addresses scanned: I2C 0x2a, 0x4c, 0x4d, 0x4e and 0x4f | ||
12 | Datasheet: http://focus.ti.com/docs/prod/folders/print/tmp421.html | ||
13 | * Texas Instruments TMP423 | ||
14 | Prefix: 'tmp423' | ||
15 | Addresses scanned: I2C 0x2a, 0x4c, 0x4d, 0x4e and 0x4f | ||
16 | Datasheet: http://focus.ti.com/docs/prod/folders/print/tmp421.html | ||
17 | |||
18 | Authors: | ||
19 | Andre Prendel <andre.prendel@gmx.de> | ||
20 | |||
21 | Description | ||
22 | ----------- | ||
23 | |||
24 | This driver implements support for Texas Instruments TMP421, TMP422 | ||
25 | and TMP423 temperature sensor chips. These chips implement one local | ||
26 | and up to one (TMP421), up to two (TMP422) or up to three (TMP423) | ||
27 | remote sensors. Temperature is measured in degrees Celsius. The chips | ||
28 | are wired over I2C/SMBus and specified over a temperature range of -40 | ||
29 | to +125 degrees Celsius. Resolution for both the local and remote | ||
30 | channels is 0.0625 degree C. | ||
31 | |||
32 | The chips support only temperature measurement. The driver exports | ||
33 | the temperature values via the following sysfs files: | ||
34 | |||
35 | temp[1-4]_input | ||
36 | temp[2-4]_fault | ||
diff --git a/Documentation/hwmon/wm831x b/Documentation/hwmon/wm831x new file mode 100644 index 000000000000..24f47d8f6a42 --- /dev/null +++ b/Documentation/hwmon/wm831x | |||
@@ -0,0 +1,37 @@ | |||
1 | Kernel driver wm831x-hwmon | ||
2 | ========================== | ||
3 | |||
4 | Supported chips: | ||
5 | * Wolfson Microelectronics WM831x PMICs | ||
6 | Prefix: 'wm831x' | ||
7 | Datasheet: | ||
8 | http://www.wolfsonmicro.com/products/WM8310 | ||
9 | http://www.wolfsonmicro.com/products/WM8311 | ||
10 | http://www.wolfsonmicro.com/products/WM8312 | ||
11 | |||
12 | Authors: Mark Brown <broonie@opensource.wolfsonmicro.com> | ||
13 | |||
14 | Description | ||
15 | ----------- | ||
16 | |||
17 | The WM831x series of PMICs include an AUXADC which can be used to | ||
18 | monitor a range of system operating parameters, including the voltages | ||
19 | of the major supplies within the system. Currently the driver provides | ||
20 | reporting of all the input values but does not provide any alarms. | ||
21 | |||
22 | Voltage Monitoring | ||
23 | ------------------ | ||
24 | |||
25 | Voltages are sampled by a 12 bit ADC. Voltages in milivolts are 1.465 | ||
26 | times the ADC value. | ||
27 | |||
28 | Temperature Monitoring | ||
29 | ---------------------- | ||
30 | |||
31 | Temperatures are sampled by a 12 bit ADC. Chip and battery temperatures | ||
32 | are available. The chip temperature is calculated as: | ||
33 | |||
34 | Degrees celsius = (512.18 - data) / 1.0983 | ||
35 | |||
36 | while the battery temperature calculation will depend on the NTC | ||
37 | thermistor component. | ||
diff --git a/Documentation/hwmon/wm8350 b/Documentation/hwmon/wm8350 new file mode 100644 index 000000000000..98f923bd2e92 --- /dev/null +++ b/Documentation/hwmon/wm8350 | |||
@@ -0,0 +1,26 @@ | |||
1 | Kernel driver wm8350-hwmon | ||
2 | ========================== | ||
3 | |||
4 | Supported chips: | ||
5 | * Wolfson Microelectronics WM835x PMICs | ||
6 | Prefix: 'wm8350' | ||
7 | Datasheet: | ||
8 | http://www.wolfsonmicro.com/products/WM8350 | ||
9 | http://www.wolfsonmicro.com/products/WM8351 | ||
10 | http://www.wolfsonmicro.com/products/WM8352 | ||
11 | |||
12 | Authors: Mark Brown <broonie@opensource.wolfsonmicro.com> | ||
13 | |||
14 | Description | ||
15 | ----------- | ||
16 | |||
17 | The WM835x series of PMICs include an AUXADC which can be used to | ||
18 | monitor a range of system operating parameters, including the voltages | ||
19 | of the major supplies within the system. Currently the driver provides | ||
20 | simple access to these major supplies. | ||
21 | |||
22 | Voltage Monitoring | ||
23 | ------------------ | ||
24 | |||
25 | Voltages are sampled by a 12 bit ADC. For the internal supplies the ADC | ||
26 | is referenced to the system VRTC. | ||
diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index 574ee67b6181..0f17d16dc101 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt | |||
@@ -1286,6 +1286,10 @@ and is between 256 and 4096 characters. It is defined in the file | |||
1286 | (machvec) in a generic kernel. | 1286 | (machvec) in a generic kernel. |
1287 | Example: machvec=hpzx1_swiotlb | 1287 | Example: machvec=hpzx1_swiotlb |
1288 | 1288 | ||
1289 | machtype= [Loongson] Share the same kernel image file between different | ||
1290 | yeeloong laptop. | ||
1291 | Example: machtype=lemote-yeeloong-2f-7inch | ||
1292 | |||
1289 | max_addr=nn[KMG] [KNL,BOOT,ia64] All physical memory greater | 1293 | max_addr=nn[KMG] [KNL,BOOT,ia64] All physical memory greater |
1290 | than or equal to this physical address is ignored. | 1294 | than or equal to this physical address is ignored. |
1291 | 1295 | ||
diff --git a/Documentation/trace/events.txt b/Documentation/trace/events.txt index 2bcc8d4dea29..78c45a87be57 100644 --- a/Documentation/trace/events.txt +++ b/Documentation/trace/events.txt | |||
@@ -1,7 +1,7 @@ | |||
1 | Event Tracing | 1 | Event Tracing |
2 | 2 | ||
3 | Documentation written by Theodore Ts'o | 3 | Documentation written by Theodore Ts'o |
4 | Updated by Li Zefan | 4 | Updated by Li Zefan and Tom Zanussi |
5 | 5 | ||
6 | 1. Introduction | 6 | 1. Introduction |
7 | =============== | 7 | =============== |
@@ -22,12 +22,12 @@ tracing information should be printed. | |||
22 | --------------------------------- | 22 | --------------------------------- |
23 | 23 | ||
24 | The events which are available for tracing can be found in the file | 24 | The events which are available for tracing can be found in the file |
25 | /debug/tracing/available_events. | 25 | /sys/kernel/debug/tracing/available_events. |
26 | 26 | ||
27 | To enable a particular event, such as 'sched_wakeup', simply echo it | 27 | To enable a particular event, such as 'sched_wakeup', simply echo it |
28 | to /debug/tracing/set_event. For example: | 28 | to /sys/kernel/debug/tracing/set_event. For example: |
29 | 29 | ||
30 | # echo sched_wakeup >> /debug/tracing/set_event | 30 | # echo sched_wakeup >> /sys/kernel/debug/tracing/set_event |
31 | 31 | ||
32 | [ Note: '>>' is necessary, otherwise it will firstly disable | 32 | [ Note: '>>' is necessary, otherwise it will firstly disable |
33 | all the events. ] | 33 | all the events. ] |
@@ -35,15 +35,15 @@ to /debug/tracing/set_event. For example: | |||
35 | To disable an event, echo the event name to the set_event file prefixed | 35 | To disable an event, echo the event name to the set_event file prefixed |
36 | with an exclamation point: | 36 | with an exclamation point: |
37 | 37 | ||
38 | # echo '!sched_wakeup' >> /debug/tracing/set_event | 38 | # echo '!sched_wakeup' >> /sys/kernel/debug/tracing/set_event |
39 | 39 | ||
40 | To disable all events, echo an empty line to the set_event file: | 40 | To disable all events, echo an empty line to the set_event file: |
41 | 41 | ||
42 | # echo > /debug/tracing/set_event | 42 | # echo > /sys/kernel/debug/tracing/set_event |
43 | 43 | ||
44 | To enable all events, echo '*:*' or '*:' to the set_event file: | 44 | To enable all events, echo '*:*' or '*:' to the set_event file: |
45 | 45 | ||
46 | # echo *:* > /debug/tracing/set_event | 46 | # echo *:* > /sys/kernel/debug/tracing/set_event |
47 | 47 | ||
48 | The events are organized into subsystems, such as ext4, irq, sched, | 48 | The events are organized into subsystems, such as ext4, irq, sched, |
49 | etc., and a full event name looks like this: <subsystem>:<event>. The | 49 | etc., and a full event name looks like this: <subsystem>:<event>. The |
@@ -52,29 +52,29 @@ file. All of the events in a subsystem can be specified via the syntax | |||
52 | "<subsystem>:*"; for example, to enable all irq events, you can use the | 52 | "<subsystem>:*"; for example, to enable all irq events, you can use the |
53 | command: | 53 | command: |
54 | 54 | ||
55 | # echo 'irq:*' > /debug/tracing/set_event | 55 | # echo 'irq:*' > /sys/kernel/debug/tracing/set_event |
56 | 56 | ||
57 | 2.2 Via the 'enable' toggle | 57 | 2.2 Via the 'enable' toggle |
58 | --------------------------- | 58 | --------------------------- |
59 | 59 | ||
60 | The events available are also listed in /debug/tracing/events/ hierarchy | 60 | The events available are also listed in /sys/kernel/debug/tracing/events/ hierarchy |
61 | of directories. | 61 | of directories. |
62 | 62 | ||
63 | To enable event 'sched_wakeup': | 63 | To enable event 'sched_wakeup': |
64 | 64 | ||
65 | # echo 1 > /debug/tracing/events/sched/sched_wakeup/enable | 65 | # echo 1 > /sys/kernel/debug/tracing/events/sched/sched_wakeup/enable |
66 | 66 | ||
67 | To disable it: | 67 | To disable it: |
68 | 68 | ||
69 | # echo 0 > /debug/tracing/events/sched/sched_wakeup/enable | 69 | # echo 0 > /sys/kernel/debug/tracing/events/sched/sched_wakeup/enable |
70 | 70 | ||
71 | To enable all events in sched subsystem: | 71 | To enable all events in sched subsystem: |
72 | 72 | ||
73 | # echo 1 > /debug/tracing/events/sched/enable | 73 | # echo 1 > /sys/kernel/debug/tracing/events/sched/enable |
74 | 74 | ||
75 | To eanble all events: | 75 | To eanble all events: |
76 | 76 | ||
77 | # echo 1 > /debug/tracing/events/enable | 77 | # echo 1 > /sys/kernel/debug/tracing/events/enable |
78 | 78 | ||
79 | When reading one of these enable files, there are four results: | 79 | When reading one of these enable files, there are four results: |
80 | 80 | ||
@@ -97,3 +97,185 @@ The format of this boot option is the same as described in section 2.1. | |||
97 | 97 | ||
98 | See The example provided in samples/trace_events | 98 | See The example provided in samples/trace_events |
99 | 99 | ||
100 | 4. Event formats | ||
101 | ================ | ||
102 | |||
103 | Each trace event has a 'format' file associated with it that contains | ||
104 | a description of each field in a logged event. This information can | ||
105 | be used to parse the binary trace stream, and is also the place to | ||
106 | find the field names that can be used in event filters (see section 5). | ||
107 | |||
108 | It also displays the format string that will be used to print the | ||
109 | event in text mode, along with the event name and ID used for | ||
110 | profiling. | ||
111 | |||
112 | Every event has a set of 'common' fields associated with it; these are | ||
113 | the fields prefixed with 'common_'. The other fields vary between | ||
114 | events and correspond to the fields defined in the TRACE_EVENT | ||
115 | definition for that event. | ||
116 | |||
117 | Each field in the format has the form: | ||
118 | |||
119 | field:field-type field-name; offset:N; size:N; | ||
120 | |||
121 | where offset is the offset of the field in the trace record and size | ||
122 | is the size of the data item, in bytes. | ||
123 | |||
124 | For example, here's the information displayed for the 'sched_wakeup' | ||
125 | event: | ||
126 | |||
127 | # cat /debug/tracing/events/sched/sched_wakeup/format | ||
128 | |||
129 | name: sched_wakeup | ||
130 | ID: 60 | ||
131 | format: | ||
132 | field:unsigned short common_type; offset:0; size:2; | ||
133 | field:unsigned char common_flags; offset:2; size:1; | ||
134 | field:unsigned char common_preempt_count; offset:3; size:1; | ||
135 | field:int common_pid; offset:4; size:4; | ||
136 | field:int common_tgid; offset:8; size:4; | ||
137 | |||
138 | field:char comm[TASK_COMM_LEN]; offset:12; size:16; | ||
139 | field:pid_t pid; offset:28; size:4; | ||
140 | field:int prio; offset:32; size:4; | ||
141 | field:int success; offset:36; size:4; | ||
142 | field:int cpu; offset:40; size:4; | ||
143 | |||
144 | print fmt: "task %s:%d [%d] success=%d [%03d]", REC->comm, REC->pid, | ||
145 | REC->prio, REC->success, REC->cpu | ||
146 | |||
147 | This event contains 10 fields, the first 5 common and the remaining 5 | ||
148 | event-specific. All the fields for this event are numeric, except for | ||
149 | 'comm' which is a string, a distinction important for event filtering. | ||
150 | |||
151 | 5. Event filtering | ||
152 | ================== | ||
153 | |||
154 | Trace events can be filtered in the kernel by associating boolean | ||
155 | 'filter expressions' with them. As soon as an event is logged into | ||
156 | the trace buffer, its fields are checked against the filter expression | ||
157 | associated with that event type. An event with field values that | ||
158 | 'match' the filter will appear in the trace output, and an event whose | ||
159 | values don't match will be discarded. An event with no filter | ||
160 | associated with it matches everything, and is the default when no | ||
161 | filter has been set for an event. | ||
162 | |||
163 | 5.1 Expression syntax | ||
164 | --------------------- | ||
165 | |||
166 | A filter expression consists of one or more 'predicates' that can be | ||
167 | combined using the logical operators '&&' and '||'. A predicate is | ||
168 | simply a clause that compares the value of a field contained within a | ||
169 | logged event with a constant value and returns either 0 or 1 depending | ||
170 | on whether the field value matched (1) or didn't match (0): | ||
171 | |||
172 | field-name relational-operator value | ||
173 | |||
174 | Parentheses can be used to provide arbitrary logical groupings and | ||
175 | double-quotes can be used to prevent the shell from interpreting | ||
176 | operators as shell metacharacters. | ||
177 | |||
178 | The field-names available for use in filters can be found in the | ||
179 | 'format' files for trace events (see section 4). | ||
180 | |||
181 | The relational-operators depend on the type of the field being tested: | ||
182 | |||
183 | The operators available for numeric fields are: | ||
184 | |||
185 | ==, !=, <, <=, >, >= | ||
186 | |||
187 | And for string fields they are: | ||
188 | |||
189 | ==, != | ||
190 | |||
191 | Currently, only exact string matches are supported. | ||
192 | |||
193 | Currently, the maximum number of predicates in a filter is 16. | ||
194 | |||
195 | 5.2 Setting filters | ||
196 | ------------------- | ||
197 | |||
198 | A filter for an individual event is set by writing a filter expression | ||
199 | to the 'filter' file for the given event. | ||
200 | |||
201 | For example: | ||
202 | |||
203 | # cd /debug/tracing/events/sched/sched_wakeup | ||
204 | # echo "common_preempt_count > 4" > filter | ||
205 | |||
206 | A slightly more involved example: | ||
207 | |||
208 | # cd /debug/tracing/events/sched/sched_signal_send | ||
209 | # echo "((sig >= 10 && sig < 15) || sig == 17) && comm != bash" > filter | ||
210 | |||
211 | If there is an error in the expression, you'll get an 'Invalid | ||
212 | argument' error when setting it, and the erroneous string along with | ||
213 | an error message can be seen by looking at the filter e.g.: | ||
214 | |||
215 | # cd /debug/tracing/events/sched/sched_signal_send | ||
216 | # echo "((sig >= 10 && sig < 15) || dsig == 17) && comm != bash" > filter | ||
217 | -bash: echo: write error: Invalid argument | ||
218 | # cat filter | ||
219 | ((sig >= 10 && sig < 15) || dsig == 17) && comm != bash | ||
220 | ^ | ||
221 | parse_error: Field not found | ||
222 | |||
223 | Currently the caret ('^') for an error always appears at the beginning of | ||
224 | the filter string; the error message should still be useful though | ||
225 | even without more accurate position info. | ||
226 | |||
227 | 5.3 Clearing filters | ||
228 | -------------------- | ||
229 | |||
230 | To clear the filter for an event, write a '0' to the event's filter | ||
231 | file. | ||
232 | |||
233 | To clear the filters for all events in a subsystem, write a '0' to the | ||
234 | subsystem's filter file. | ||
235 | |||
236 | 5.3 Subsystem filters | ||
237 | --------------------- | ||
238 | |||
239 | For convenience, filters for every event in a subsystem can be set or | ||
240 | cleared as a group by writing a filter expression into the filter file | ||
241 | at the root of the subsytem. Note however, that if a filter for any | ||
242 | event within the subsystem lacks a field specified in the subsystem | ||
243 | filter, or if the filter can't be applied for any other reason, the | ||
244 | filter for that event will retain its previous setting. This can | ||
245 | result in an unintended mixture of filters which could lead to | ||
246 | confusing (to the user who might think different filters are in | ||
247 | effect) trace output. Only filters that reference just the common | ||
248 | fields can be guaranteed to propagate successfully to all events. | ||
249 | |||
250 | Here are a few subsystem filter examples that also illustrate the | ||
251 | above points: | ||
252 | |||
253 | Clear the filters on all events in the sched subsytem: | ||
254 | |||
255 | # cd /sys/kernel/debug/tracing/events/sched | ||
256 | # echo 0 > filter | ||
257 | # cat sched_switch/filter | ||
258 | none | ||
259 | # cat sched_wakeup/filter | ||
260 | none | ||
261 | |||
262 | Set a filter using only common fields for all events in the sched | ||
263 | subsytem (all events end up with the same filter): | ||
264 | |||
265 | # cd /sys/kernel/debug/tracing/events/sched | ||
266 | # echo common_pid == 0 > filter | ||
267 | # cat sched_switch/filter | ||
268 | common_pid == 0 | ||
269 | # cat sched_wakeup/filter | ||
270 | common_pid == 0 | ||
271 | |||
272 | Attempt to set a filter using a non-common field for all events in the | ||
273 | sched subsytem (all events but those that have a prev_pid field retain | ||
274 | their old filters): | ||
275 | |||
276 | # cd /sys/kernel/debug/tracing/events/sched | ||
277 | # echo prev_pid == 0 > filter | ||
278 | # cat sched_switch/filter | ||
279 | prev_pid == 0 | ||
280 | # cat sched_wakeup/filter | ||
281 | common_pid == 0 | ||
diff --git a/Documentation/trace/ftrace-design.txt b/Documentation/trace/ftrace-design.txt new file mode 100644 index 000000000000..7003e10f10f5 --- /dev/null +++ b/Documentation/trace/ftrace-design.txt | |||
@@ -0,0 +1,233 @@ | |||
1 | function tracer guts | ||
2 | ==================== | ||
3 | |||
4 | Introduction | ||
5 | ------------ | ||
6 | |||
7 | Here we will cover the architecture pieces that the common function tracing | ||
8 | code relies on for proper functioning. Things are broken down into increasing | ||
9 | complexity so that you can start simple and at least get basic functionality. | ||
10 | |||
11 | Note that this focuses on architecture implementation details only. If you | ||
12 | want more explanation of a feature in terms of common code, review the common | ||
13 | ftrace.txt file. | ||
14 | |||
15 | |||
16 | Prerequisites | ||
17 | ------------- | ||
18 | |||
19 | Ftrace relies on these features being implemented: | ||
20 | STACKTRACE_SUPPORT - implement save_stack_trace() | ||
21 | TRACE_IRQFLAGS_SUPPORT - implement include/asm/irqflags.h | ||
22 | |||
23 | |||
24 | HAVE_FUNCTION_TRACER | ||
25 | -------------------- | ||
26 | |||
27 | You will need to implement the mcount and the ftrace_stub functions. | ||
28 | |||
29 | The exact mcount symbol name will depend on your toolchain. Some call it | ||
30 | "mcount", "_mcount", or even "__mcount". You can probably figure it out by | ||
31 | running something like: | ||
32 | $ echo 'main(){}' | gcc -x c -S -o - - -pg | grep mcount | ||
33 | call mcount | ||
34 | We'll make the assumption below that the symbol is "mcount" just to keep things | ||
35 | nice and simple in the examples. | ||
36 | |||
37 | Keep in mind that the ABI that is in effect inside of the mcount function is | ||
38 | *highly* architecture/toolchain specific. We cannot help you in this regard, | ||
39 | sorry. Dig up some old documentation and/or find someone more familiar than | ||
40 | you to bang ideas off of. Typically, register usage (argument/scratch/etc...) | ||
41 | is a major issue at this point, especially in relation to the location of the | ||
42 | mcount call (before/after function prologue). You might also want to look at | ||
43 | how glibc has implemented the mcount function for your architecture. It might | ||
44 | be (semi-)relevant. | ||
45 | |||
46 | The mcount function should check the function pointer ftrace_trace_function | ||
47 | to see if it is set to ftrace_stub. If it is, there is nothing for you to do, | ||
48 | so return immediately. If it isn't, then call that function in the same way | ||
49 | the mcount function normally calls __mcount_internal -- the first argument is | ||
50 | the "frompc" while the second argument is the "selfpc" (adjusted to remove the | ||
51 | size of the mcount call that is embedded in the function). | ||
52 | |||
53 | For example, if the function foo() calls bar(), when the bar() function calls | ||
54 | mcount(), the arguments mcount() will pass to the tracer are: | ||
55 | "frompc" - the address bar() will use to return to foo() | ||
56 | "selfpc" - the address bar() (with _mcount() size adjustment) | ||
57 | |||
58 | Also keep in mind that this mcount function will be called *a lot*, so | ||
59 | optimizing for the default case of no tracer will help the smooth running of | ||
60 | your system when tracing is disabled. So the start of the mcount function is | ||
61 | typically the bare min with checking things before returning. That also means | ||
62 | the code flow should usually kept linear (i.e. no branching in the nop case). | ||
63 | This is of course an optimization and not a hard requirement. | ||
64 | |||
65 | Here is some pseudo code that should help (these functions should actually be | ||
66 | implemented in assembly): | ||
67 | |||
68 | void ftrace_stub(void) | ||
69 | { | ||
70 | return; | ||
71 | } | ||
72 | |||
73 | void mcount(void) | ||
74 | { | ||
75 | /* save any bare state needed in order to do initial checking */ | ||
76 | |||
77 | extern void (*ftrace_trace_function)(unsigned long, unsigned long); | ||
78 | if (ftrace_trace_function != ftrace_stub) | ||
79 | goto do_trace; | ||
80 | |||
81 | /* restore any bare state */ | ||
82 | |||
83 | return; | ||
84 | |||
85 | do_trace: | ||
86 | |||
87 | /* save all state needed by the ABI (see paragraph above) */ | ||
88 | |||
89 | unsigned long frompc = ...; | ||
90 | unsigned long selfpc = <return address> - MCOUNT_INSN_SIZE; | ||
91 | ftrace_trace_function(frompc, selfpc); | ||
92 | |||
93 | /* restore all state needed by the ABI */ | ||
94 | } | ||
95 | |||
96 | Don't forget to export mcount for modules ! | ||
97 | extern void mcount(void); | ||
98 | EXPORT_SYMBOL(mcount); | ||
99 | |||
100 | |||
101 | HAVE_FUNCTION_TRACE_MCOUNT_TEST | ||
102 | ------------------------------- | ||
103 | |||
104 | This is an optional optimization for the normal case when tracing is turned off | ||
105 | in the system. If you do not enable this Kconfig option, the common ftrace | ||
106 | code will take care of doing the checking for you. | ||
107 | |||
108 | To support this feature, you only need to check the function_trace_stop | ||
109 | variable in the mcount function. If it is non-zero, there is no tracing to be | ||
110 | done at all, so you can return. | ||
111 | |||
112 | This additional pseudo code would simply be: | ||
113 | void mcount(void) | ||
114 | { | ||
115 | /* save any bare state needed in order to do initial checking */ | ||
116 | |||
117 | + if (function_trace_stop) | ||
118 | + return; | ||
119 | |||
120 | extern void (*ftrace_trace_function)(unsigned long, unsigned long); | ||
121 | if (ftrace_trace_function != ftrace_stub) | ||
122 | ... | ||
123 | |||
124 | |||
125 | HAVE_FUNCTION_GRAPH_TRACER | ||
126 | -------------------------- | ||
127 | |||
128 | Deep breath ... time to do some real work. Here you will need to update the | ||
129 | mcount function to check ftrace graph function pointers, as well as implement | ||
130 | some functions to save (hijack) and restore the return address. | ||
131 | |||
132 | The mcount function should check the function pointers ftrace_graph_return | ||
133 | (compare to ftrace_stub) and ftrace_graph_entry (compare to | ||
134 | ftrace_graph_entry_stub). If either of those are not set to the relevant stub | ||
135 | function, call the arch-specific function ftrace_graph_caller which in turn | ||
136 | calls the arch-specific function prepare_ftrace_return. Neither of these | ||
137 | function names are strictly required, but you should use them anyways to stay | ||
138 | consistent across the architecture ports -- easier to compare & contrast | ||
139 | things. | ||
140 | |||
141 | The arguments to prepare_ftrace_return are slightly different than what are | ||
142 | passed to ftrace_trace_function. The second argument "selfpc" is the same, | ||
143 | but the first argument should be a pointer to the "frompc". Typically this is | ||
144 | located on the stack. This allows the function to hijack the return address | ||
145 | temporarily to have it point to the arch-specific function return_to_handler. | ||
146 | That function will simply call the common ftrace_return_to_handler function and | ||
147 | that will return the original return address with which, you can return to the | ||
148 | original call site. | ||
149 | |||
150 | Here is the updated mcount pseudo code: | ||
151 | void mcount(void) | ||
152 | { | ||
153 | ... | ||
154 | if (ftrace_trace_function != ftrace_stub) | ||
155 | goto do_trace; | ||
156 | |||
157 | +#ifdef CONFIG_FUNCTION_GRAPH_TRACER | ||
158 | + extern void (*ftrace_graph_return)(...); | ||
159 | + extern void (*ftrace_graph_entry)(...); | ||
160 | + if (ftrace_graph_return != ftrace_stub || | ||
161 | + ftrace_graph_entry != ftrace_graph_entry_stub) | ||
162 | + ftrace_graph_caller(); | ||
163 | +#endif | ||
164 | |||
165 | /* restore any bare state */ | ||
166 | ... | ||
167 | |||
168 | Here is the pseudo code for the new ftrace_graph_caller assembly function: | ||
169 | #ifdef CONFIG_FUNCTION_GRAPH_TRACER | ||
170 | void ftrace_graph_caller(void) | ||
171 | { | ||
172 | /* save all state needed by the ABI */ | ||
173 | |||
174 | unsigned long *frompc = &...; | ||
175 | unsigned long selfpc = <return address> - MCOUNT_INSN_SIZE; | ||
176 | prepare_ftrace_return(frompc, selfpc); | ||
177 | |||
178 | /* restore all state needed by the ABI */ | ||
179 | } | ||
180 | #endif | ||
181 | |||
182 | For information on how to implement prepare_ftrace_return(), simply look at | ||
183 | the x86 version. The only architecture-specific piece in it is the setup of | ||
184 | the fault recovery table (the asm(...) code). The rest should be the same | ||
185 | across architectures. | ||
186 | |||
187 | Here is the pseudo code for the new return_to_handler assembly function. Note | ||
188 | that the ABI that applies here is different from what applies to the mcount | ||
189 | code. Since you are returning from a function (after the epilogue), you might | ||
190 | be able to skimp on things saved/restored (usually just registers used to pass | ||
191 | return values). | ||
192 | |||
193 | #ifdef CONFIG_FUNCTION_GRAPH_TRACER | ||
194 | void return_to_handler(void) | ||
195 | { | ||
196 | /* save all state needed by the ABI (see paragraph above) */ | ||
197 | |||
198 | void (*original_return_point)(void) = ftrace_return_to_handler(); | ||
199 | |||
200 | /* restore all state needed by the ABI */ | ||
201 | |||
202 | /* this is usually either a return or a jump */ | ||
203 | original_return_point(); | ||
204 | } | ||
205 | #endif | ||
206 | |||
207 | |||
208 | HAVE_FTRACE_NMI_ENTER | ||
209 | --------------------- | ||
210 | |||
211 | If you can't trace NMI functions, then skip this option. | ||
212 | |||
213 | <details to be filled> | ||
214 | |||
215 | |||
216 | HAVE_FTRACE_SYSCALLS | ||
217 | --------------------- | ||
218 | |||
219 | <details to be filled> | ||
220 | |||
221 | |||
222 | HAVE_FTRACE_MCOUNT_RECORD | ||
223 | ------------------------- | ||
224 | |||
225 | See scripts/recordmcount.pl for more info. | ||
226 | |||
227 | <details to be filled> | ||
228 | |||
229 | |||
230 | HAVE_DYNAMIC_FTRACE | ||
231 | --------------------- | ||
232 | |||
233 | <details to be filled> | ||
diff --git a/Documentation/trace/ftrace.txt b/Documentation/trace/ftrace.txt index 355d0f1f8c50..1b6292bbdd6d 100644 --- a/Documentation/trace/ftrace.txt +++ b/Documentation/trace/ftrace.txt | |||
@@ -26,6 +26,12 @@ disabled, and more (ftrace allows for tracer plugins, which | |||
26 | means that the list of tracers can always grow). | 26 | means that the list of tracers can always grow). |
27 | 27 | ||
28 | 28 | ||
29 | Implementation Details | ||
30 | ---------------------- | ||
31 | |||
32 | See ftrace-design.txt for details for arch porters and such. | ||
33 | |||
34 | |||
29 | The File System | 35 | The File System |
30 | --------------- | 36 | --------------- |
31 | 37 | ||
diff --git a/Documentation/vgaarbiter.txt b/Documentation/vgaarbiter.txt new file mode 100644 index 000000000000..987f9b0a5ece --- /dev/null +++ b/Documentation/vgaarbiter.txt | |||
@@ -0,0 +1,194 @@ | |||
1 | |||
2 | VGA Arbiter | ||
3 | =========== | ||
4 | |||
5 | Graphic devices are accessed through ranges in I/O or memory space. While most | ||
6 | modern devices allow relocation of such ranges, some "Legacy" VGA devices | ||
7 | implemented on PCI will typically have the same "hard-decoded" addresses as | ||
8 | they did on ISA. For more details see "PCI Bus Binding to IEEE Std 1275-1994 | ||
9 | Standard for Boot (Initialization Configuration) Firmware Revision 2.1" | ||
10 | Section 7, Legacy Devices. | ||
11 | |||
12 | The Resource Access Control (RAC) module inside the X server [0] existed for | ||
13 | the legacy VGA arbitration task (besides other bus management tasks) when more | ||
14 | than one legacy device co-exists on the same machine. But the problem happens | ||
15 | when these devices are trying to be accessed by different userspace clients | ||
16 | (e.g. two server in parallel). Their address assignments conflict. Moreover, | ||
17 | ideally, being an userspace application, it is not the role of the the X | ||
18 | server to control bus resources. Therefore an arbitration scheme outside of | ||
19 | the X server is needed to control the sharing of these resources. This | ||
20 | document introduces the operation of the VGA arbiter implemented for Linux | ||
21 | kernel. | ||
22 | |||
23 | ---------------------------------------------------------------------------- | ||
24 | |||
25 | I. Details and Theory of Operation | ||
26 | I.1 vgaarb | ||
27 | I.2 libpciaccess | ||
28 | I.3 xf86VGAArbiter (X server implementation) | ||
29 | II. Credits | ||
30 | III.References | ||
31 | |||
32 | |||
33 | I. Details and Theory of Operation | ||
34 | ================================== | ||
35 | |||
36 | I.1 vgaarb | ||
37 | ---------- | ||
38 | |||
39 | The vgaarb is a module of the Linux Kernel. When it is initially loaded, it | ||
40 | scans all PCI devices and adds the VGA ones inside the arbitration. The | ||
41 | arbiter then enables/disables the decoding on different devices of the VGA | ||
42 | legacy instructions. Device which do not want/need to use the arbiter may | ||
43 | explicitly tell it by calling vga_set_legacy_decoding(). | ||
44 | |||
45 | The kernel exports a char device interface (/dev/vga_arbiter) to the clients, | ||
46 | which has the following semantics: | ||
47 | |||
48 | open : open user instance of the arbiter. By default, it's attached to | ||
49 | the default VGA device of the system. | ||
50 | |||
51 | close : close user instance. Release locks made by the user | ||
52 | |||
53 | read : return a string indicating the status of the target like: | ||
54 | |||
55 | "<card_ID>,decodes=<io_state>,owns=<io_state>,locks=<io_state> (ic,mc)" | ||
56 | |||
57 | An IO state string is of the form {io,mem,io+mem,none}, mc and | ||
58 | ic are respectively mem and io lock counts (for debugging/ | ||
59 | diagnostic only). "decodes" indicate what the card currently | ||
60 | decodes, "owns" indicates what is currently enabled on it, and | ||
61 | "locks" indicates what is locked by this card. If the card is | ||
62 | unplugged, we get "invalid" then for card_ID and an -ENODEV | ||
63 | error is returned for any command until a new card is targeted. | ||
64 | |||
65 | |||
66 | write : write a command to the arbiter. List of commands: | ||
67 | |||
68 | target <card_ID> : switch target to card <card_ID> (see below) | ||
69 | lock <io_state> : acquires locks on target ("none" is an invalid io_state) | ||
70 | trylock <io_state> : non-blocking acquire locks on target (returns EBUSY if | ||
71 | unsuccessful) | ||
72 | unlock <io_state> : release locks on target | ||
73 | unlock all : release all locks on target held by this user (not | ||
74 | implemented yet) | ||
75 | decodes <io_state> : set the legacy decoding attributes for the card | ||
76 | |||
77 | poll : event if something changes on any card (not just the | ||
78 | target) | ||
79 | |||
80 | card_ID is of the form "PCI:domain:bus:dev.fn". It can be set to "default" | ||
81 | to go back to the system default card (TODO: not implemented yet). Currently, | ||
82 | only PCI is supported as a prefix, but the userland API may support other bus | ||
83 | types in the future, even if the current kernel implementation doesn't. | ||
84 | |||
85 | Note about locks: | ||
86 | |||
87 | The driver keeps track of which user has which locks on which card. It | ||
88 | supports stacking, like the kernel one. This complexifies the implementation | ||
89 | a bit, but makes the arbiter more tolerant to user space problems and able | ||
90 | to properly cleanup in all cases when a process dies. | ||
91 | Currently, a max of 16 cards can have locks simultaneously issued from | ||
92 | user space for a given user (file descriptor instance) of the arbiter. | ||
93 | |||
94 | In the case of devices hot-{un,}plugged, there is a hook - pci_notify() - to | ||
95 | notify them being added/removed in the system and automatically added/removed | ||
96 | in the arbiter. | ||
97 | |||
98 | There's also a in-kernel API of the arbiter in the case of DRM, vgacon and | ||
99 | others which may use the arbiter. | ||
100 | |||
101 | |||
102 | I.2 libpciaccess | ||
103 | ---------------- | ||
104 | |||
105 | To use the vga arbiter char device it was implemented an API inside the | ||
106 | libpciaccess library. One fieldd was added to struct pci_device (each device | ||
107 | on the system): | ||
108 | |||
109 | /* the type of resource decoded by the device */ | ||
110 | int vgaarb_rsrc; | ||
111 | |||
112 | Besides it, in pci_system were added: | ||
113 | |||
114 | int vgaarb_fd; | ||
115 | int vga_count; | ||
116 | struct pci_device *vga_target; | ||
117 | struct pci_device *vga_default_dev; | ||
118 | |||
119 | |||
120 | The vga_count is usually need to keep informed how many cards are being | ||
121 | arbitrated, so for instance if there's only one then it can totally escape the | ||
122 | scheme. | ||
123 | |||
124 | |||
125 | These functions below acquire VGA resources for the given card and mark those | ||
126 | resources as locked. If the resources requested are "normal" (and not legacy) | ||
127 | resources, the arbiter will first check whether the card is doing legacy | ||
128 | decoding for that type of resource. If yes, the lock is "converted" into a | ||
129 | legacy resource lock. The arbiter will first look for all VGA cards that | ||
130 | might conflict and disable their IOs and/or Memory access, including VGA | ||
131 | forwarding on P2P bridges if necessary, so that the requested resources can | ||
132 | be used. Then, the card is marked as locking these resources and the IO and/or | ||
133 | Memory access is enabled on the card (including VGA forwarding on parent | ||
134 | P2P bridges if any). In the case of vga_arb_lock(), the function will block | ||
135 | if some conflicting card is already locking one of the required resources (or | ||
136 | any resource on a different bus segment, since P2P bridges don't differentiate | ||
137 | VGA memory and IO afaik). If the card already owns the resources, the function | ||
138 | succeeds. vga_arb_trylock() will return (-EBUSY) instead of blocking. Nested | ||
139 | calls are supported (a per-resource counter is maintained). | ||
140 | |||
141 | |||
142 | Set the target device of this client. | ||
143 | int pci_device_vgaarb_set_target (struct pci_device *dev); | ||
144 | |||
145 | |||
146 | For instance, in x86 if two devices on the same bus want to lock different | ||
147 | resources, both will succeed (lock). If devices are in different buses and | ||
148 | trying to lock different resources, only the first who tried succeeds. | ||
149 | int pci_device_vgaarb_lock (void); | ||
150 | int pci_device_vgaarb_trylock (void); | ||
151 | |||
152 | Unlock resources of device. | ||
153 | int pci_device_vgaarb_unlock (void); | ||
154 | |||
155 | Indicates to the arbiter if the card decodes legacy VGA IOs, legacy VGA | ||
156 | Memory, both, or none. All cards default to both, the card driver (fbdev for | ||
157 | example) should tell the arbiter if it has disabled legacy decoding, so the | ||
158 | card can be left out of the arbitration process (and can be safe to take | ||
159 | interrupts at any time. | ||
160 | int pci_device_vgaarb_decodes (int new_vgaarb_rsrc); | ||
161 | |||
162 | Connects to the arbiter device, allocates the struct | ||
163 | int pci_device_vgaarb_init (void); | ||
164 | |||
165 | Close the connection | ||
166 | void pci_device_vgaarb_fini (void); | ||
167 | |||
168 | |||
169 | I.3 xf86VGAArbiter (X server implementation) | ||
170 | -------------------------------------------- | ||
171 | |||
172 | (TODO) | ||
173 | |||
174 | X server basically wraps all the functions that touch VGA registers somehow. | ||
175 | |||
176 | |||
177 | II. Credits | ||
178 | =========== | ||
179 | |||
180 | Benjamin Herrenschmidt (IBM?) started this work when he discussed such design | ||
181 | with the Xorg community in 2005 [1, 2]. In the end of 2007, Paulo Zanoni and | ||
182 | Tiago Vignatti (both of C3SL/Federal University of Paraná) proceeded his work | ||
183 | enhancing the kernel code to adapt as a kernel module and also did the | ||
184 | implementation of the user space side [3]. Now (2009) Tiago Vignatti and Dave | ||
185 | Airlie finally put this work in shape and queued to Jesse Barnes' PCI tree. | ||
186 | |||
187 | |||
188 | III. References | ||
189 | ============== | ||
190 | |||
191 | [0] http://cgit.freedesktop.org/xorg/xserver/commit/?id=4b42448a2388d40f257774fbffdccaea87bd0347 | ||
192 | [1] http://lists.freedesktop.org/archives/xorg/2005-March/006663.html | ||
193 | [2] http://lists.freedesktop.org/archives/xorg/2005-March/006745.html | ||
194 | [3] http://lists.freedesktop.org/archives/xorg/2007-October/029507.html | ||