Conflicts: kernel/sysctl.c
Unified · Split
| @@ -823,8 +823,8 @@ S: D-69231 Rauenberg · 822 unmodified lines | ||
| 823 | 823 | S: Germany |
| 824 | 824 | |
| 825 | 825 | N: Jean Delvare |
| 826 | −E: khali@linux-fr.org | |
| 827 | −W: http://khali.linux-fr.org/ | |
| 826 | +E: jdelvare@suse.de | |
| 827 | +W: http://jdelvare.nerim.net/ | |
| 828 | 828 | D: Several hardware monitoring drivers |
| 829 | 829 | S: France |
| 830 | 830 | |
| @@ -1,13 +1,13 @@ | ||
| 1 | 1 | What: /config/usb-gadget |
| 2 | 2 | Date: Jun 2013 |
| 3 | −KenelVersion: 3.11 | |
| 3 | +KernelVersion: 3.11 | |
| 4 | 4 | Description: |
| 5 | 5 | This group contains sub-groups corresponding to created |
| 6 | 6 | USB gadgets. |
| 7 | 7 | |
| 8 | 8 | What: /config/usb-gadget/gadget |
| 9 | 9 | Date: Jun 2013 |
| 10 | −KenelVersion: 3.11 | |
| 10 | +KernelVersion: 3.11 | |
| 11 | 11 | Description: |
| 12 | 12 | |
| 13 | 13 | The attributes of a gadget: |
| @@ -27,7 +27,7 @@ Description: · 13 unmodified lines | ||
| 27 | 27 | |
| 28 | 28 | What: /config/usb-gadget/gadget/configs |
| 29 | 29 | Date: Jun 2013 |
| 30 | −KenelVersion: 3.11 | |
| 30 | +KernelVersion: 3.11 | |
| 31 | 31 | Description: |
| 32 | 32 | This group contains a USB gadget's configurations |
| 33 | 33 | |
| @@ -58,20 +58,20 @@ Description: · 24 unmodified lines | ||
| 58 | 58 | |
| 59 | 59 | What: /config/usb-gadget/gadget/functions |
| 60 | 60 | Date: Jun 2013 |
| 61 | −KenelVersion: 3.11 | |
| 61 | +KernelVersion: 3.11 | |
| 62 | 62 | Description: |
| 63 | 63 | This group contains functions available to this USB gadget. |
| 64 | 64 | |
| 65 | 65 | What: /config/usb-gadget/gadget/strings |
| 66 | 66 | Date: Jun 2013 |
| 67 | −KenelVersion: 3.11 | |
| 67 | +KernelVersion: 3.11 | |
| 68 | 68 | Description: |
| 69 | 69 | This group contains subdirectories for language-specific |
| 70 | 70 | strings for this gadget. |
| 71 | 71 | |
| 72 | 72 | What: /config/usb-gadget/gadget/strings/language |
| 73 | 73 | Date: Jun 2013 |
| 74 | −KenelVersion: 3.11 | |
| 74 | +KernelVersion: 3.11 | |
| 75 | 75 | Description: |
| 76 | 76 | The attributes: |
| 77 | 77 | |
| @@ -1,6 +1,6 @@ | ||
| 1 | 1 | What: /config/usb-gadget/gadget/functions/acm.name |
| 2 | 2 | Date: Jun 2013 |
| 3 | −KenelVersion: 3.11 | |
| 3 | +KernelVersion: 3.11 | |
| 4 | 4 | Description: |
| 5 | 5 | |
| 6 | 6 | This item contains just one readonly attribute: port_num. |
| @@ -1,6 +1,6 @@ | ||
| 1 | 1 | What: /config/usb-gadget/gadget/functions/ecm.name |
| 2 | 2 | Date: Jun 2013 |
| 3 | −KenelVersion: 3.11 | |
| 3 | +KernelVersion: 3.11 | |
| 4 | 4 | Description: |
| 5 | 5 | The attributes: |
| 6 | 6 | |
| @@ -1,6 +1,6 @@ | ||
| 1 | 1 | What: /config/usb-gadget/gadget/functions/eem.name |
| 2 | 2 | Date: Jun 2013 |
| 3 | −KenelVersion: 3.11 | |
| 3 | +KernelVersion: 3.11 | |
| 4 | 4 | Description: |
| 5 | 5 | The attributes: |
| 6 | 6 | |
| @@ -0,0 +1,9 @@ | ||
| 1 | +What: /config/usb-gadget/gadget/functions/ffs.name | |
| 2 | +Date: Nov 2013 | |
| 3 | +KernelVersion: 3.13 | |
| 4 | +Description: The purpose of this directory is to create and remove it. | |
| 5 | + | |
| 6 | + A corresponding USB function instance is created/removed. | |
| 7 | + There are no attributes here. | |
| 8 | + | |
| 9 | + All parameters are set through FunctionFS. | |
| @@ -0,0 +1,8 @@ | ||
| 1 | +What: /config/usb-gadget/gadget/functions/Loopback.name | |
| 2 | +Date: Nov 2013 | |
| 3 | +KernelVersion: 3.13 | |
| 4 | +Description: | |
| 5 | + The attributes: | |
| 6 | + | |
| 7 | + qlen - depth of loopback queue | |
| 8 | + bulk_buflen - buffer length | |
| @@ -1,6 +1,6 @@ | ||
| 1 | 1 | What: /config/usb-gadget/gadget/functions/mass_storage.name |
| 2 | 2 | Date: Oct 2013 |
| 3 | −KenelVersion: 3.13 | |
| 3 | +KernelVersion: 3.13 | |
| 4 | 4 | Description: |
| 5 | 5 | The attributes: |
| 6 | 6 | |
| @@ -13,7 +13,7 @@ Description: · 6 unmodified lines | ||
| 13 | 13 | |
| 14 | 14 | What: /config/usb-gadget/gadget/functions/mass_storage.name/lun.name |
| 15 | 15 | Date: Oct 2013 |
| 16 | −KenelVersion: 3.13 | |
| 16 | +KernelVersion: 3.13 | |
| 17 | 17 | Description: |
| 18 | 18 | The attributes: |
| 19 | 19 | |
| @@ -1,6 +1,6 @@ | ||
| 1 | 1 | What: /config/usb-gadget/gadget/functions/ncm.name |
| 2 | 2 | Date: Jun 2013 |
| 3 | −KenelVersion: 3.11 | |
| 3 | +KernelVersion: 3.11 | |
| 4 | 4 | Description: |
| 5 | 5 | The attributes: |
| 6 | 6 | |
| @@ -1,6 +1,6 @@ | ||
| 1 | 1 | What: /config/usb-gadget/gadget/functions/obex.name |
| 2 | 2 | Date: Jun 2013 |
| 3 | −KenelVersion: 3.11 | |
| 3 | +KernelVersion: 3.11 | |
| 4 | 4 | Description: |
| 5 | 5 | |
| 6 | 6 | This item contains just one readonly attribute: port_num. |
| @@ -1,6 +1,6 @@ | ||
| 1 | 1 | What: /config/usb-gadget/gadget/functions/phonet.name |
| 2 | 2 | Date: Jun 2013 |
| 3 | −KenelVersion: 3.11 | |
| 3 | +KernelVersion: 3.11 | |
| 4 | 4 | Description: |
| 5 | 5 | |
| 6 | 6 | This item contains just one readonly attribute: ifname. |
| @@ -1,6 +1,6 @@ | ||
| 1 | 1 | What: /config/usb-gadget/gadget/functions/rndis.name |
| 2 | 2 | Date: Jun 2013 |
| 3 | −KenelVersion: 3.11 | |
| 3 | +KernelVersion: 3.11 | |
| 4 | 4 | Description: |
| 5 | 5 | The attributes: |
| 6 | 6 | |
| @@ -1,6 +1,6 @@ | ||
| 1 | 1 | What: /config/usb-gadget/gadget/functions/gser.name |
| 2 | 2 | Date: Jun 2013 |
| 3 | −KenelVersion: 3.11 | |
| 3 | +KernelVersion: 3.11 | |
| 4 | 4 | Description: |
| 5 | 5 | |
| 6 | 6 | This item contains just one readonly attribute: port_num. |
| @@ -0,0 +1,12 @@ | ||
| 1 | +What: /config/usb-gadget/gadget/functions/SourceSink.name | |
| 2 | +Date: Nov 2013 | |
| 3 | +KernelVersion: 3.13 | |
| 4 | +Description: | |
| 5 | + The attributes: | |
| 6 | + | |
| 7 | + pattern - 0 (all zeros), 1 (mod63), 2 (none) | |
| 8 | + isoc_interval - 1..16 | |
| 9 | + isoc_maxpacket - 0 - 1023 (fs), 0 - 1024 (hs/ss) | |
| 10 | + isoc_mult - 0..2 (hs/ss only) | |
| 11 | + isoc_maxburst - 0..15 (ss only) | |
| 12 | + qlen - buffer length | |
| @@ -1,6 +1,6 @@ | ||
| 1 | 1 | What: /config/usb-gadget/gadget/functions/geth.name |
| 2 | 2 | Date: Jun 2013 |
| 3 | −KenelVersion: 3.11 | |
| 3 | +KernelVersion: 3.11 | |
| 4 | 4 | Description: |
| 5 | 5 | The attributes: |
| 6 | 6 | |
| @@ -0,0 +1,91 @@ | ||
| 1 | +What: /sys/kernel/debug/genwqe/genwqe<n>_card/ddcb_info | |
| 2 | +Date: Oct 2013 | |
| 3 | +Contact: haver@linux.vnet.ibm.com | |
| 4 | +Description: DDCB queue dump used for debugging queueing problems. | |
| 5 | + | |
| 6 | +What: /sys/kernel/debug/genwqe/genwqe<n>_card/curr_regs | |
| 7 | +Date: Oct 2013 | |
| 8 | +Contact: haver@linux.vnet.ibm.com | |
| 9 | +Description: Dump of the current error registers. | |
| 10 | + Only available for PF. | |
| 11 | + | |
| 12 | +What: /sys/kernel/debug/genwqe/genwqe<n>_card/curr_dbg_uid0 | |
| 13 | +Date: Oct 2013 | |
| 14 | +Contact: haver@linux.vnet.ibm.com | |
| 15 | +Description: Internal chip state of UID0 (unit id 0). | |
| 16 | + Only available for PF. | |
| 17 | + | |
| 18 | +What: /sys/kernel/debug/genwqe/genwqe<n>_card/curr_dbg_uid1 | |
| 19 | +Date: Oct 2013 | |
| 20 | +Contact: haver@linux.vnet.ibm.com | |
| 21 | +Description: Internal chip state of UID1. | |
| 22 | + Only available for PF. | |
| 23 | + | |
| 24 | +What: /sys/kernel/debug/genwqe/genwqe<n>_card/curr_dbg_uid2 | |
| 25 | +Date: Oct 2013 | |
| 26 | +Contact: haver@linux.vnet.ibm.com | |
| 27 | +Description: Internal chip state of UID2. | |
| 28 | + Only available for PF. | |
| 29 | + | |
| 30 | +What: /sys/kernel/debug/genwqe/genwqe<n>_card/prev_regs | |
| 31 | +Date: Oct 2013 | |
| 32 | +Contact: haver@linux.vnet.ibm.com | |
| 33 | +Description: Dump of the error registers before the last reset of | |
| 34 | + the card occured. | |
| 35 | + Only available for PF. | |
| 36 | + | |
| 37 | +What: /sys/kernel/debug/genwqe/genwqe<n>_card/prev_dbg_uid0 | |
| 38 | +Date: Oct 2013 | |
| 39 | +Contact: haver@linux.vnet.ibm.com | |
| 40 | +Description: Internal chip state of UID0 before card was reset. | |
| 41 | + Only available for PF. | |
| 42 | + | |
| 43 | +What: /sys/kernel/debug/genwqe/genwqe<n>_card/prev_dbg_uid1 | |
| 44 | +Date: Oct 2013 | |
| 45 | +Contact: haver@linux.vnet.ibm.com | |
| 46 | +Description: Internal chip state of UID1 before card was reset. | |
| 47 | + Only available for PF. | |
| 48 | + | |
| 49 | +What: /sys/kernel/debug/genwqe/genwqe<n>_card/prev_dbg_uid2 | |
| 50 | +Date: Oct 2013 | |
| 51 | +Contact: haver@linux.vnet.ibm.com | |
| 52 | +Description: Internal chip state of UID2 before card was reset. | |
| 53 | + Only available for PF. | |
| 54 | + | |
| 55 | +What: /sys/kernel/debug/genwqe/genwqe<n>_card/info | |
| 56 | +Date: Oct 2013 | |
| 57 | +Contact: haver@linux.vnet.ibm.com | |
| 58 | +Description: Comprehensive summary of bitstream version and software | |
| 59 | + version. Used bitstream and bitstream clocking information. | |
| 60 | + | |
| 61 | +What: /sys/kernel/debug/genwqe/genwqe<n>_card/err_inject | |
| 62 | +Date: Oct 2013 | |
| 63 | +Contact: haver@linux.vnet.ibm.com | |
| 64 | +Description: Possibility to inject error cases to ensure that the drivers | |
| 65 | + error handling code works well. | |
| 66 | + | |
| 67 | +What: /sys/kernel/debug/genwqe/genwqe<n>_card/vf<0..14>_jobtimeout_msec | |
| 68 | +Date: Oct 2013 | |
| 69 | +Contact: haver@linux.vnet.ibm.com | |
| 70 | +Description: Default VF timeout 250ms. Testing might require 1000ms. | |
| 71 | + Using 0 will use the cards default value (whatever that is). | |
| 72 | + | |
| 73 | + The timeout depends on the max number of available cards | |
| 74 | + in the system and the maximum allowed queue size. | |
| 75 | + | |
| 76 | + The driver ensures that the settings are done just before | |
| 77 | + the VFs get enabled. Changing the timeouts in flight is not | |
| 78 | + possible. | |
| 79 | + Only available for PF. | |
| 80 | + | |
| 81 | +What: /sys/kernel/debug/genwqe/genwqe<n>_card/jobtimer | |
| 82 | +Date: Oct 2013 | |
| 83 | +Contact: haver@linux.vnet.ibm.com | |
| 84 | +Description: Dump job timeout register values for PF and VFs. | |
| 85 | + Only available for PF. | |
| 86 | + | |
| 87 | +What: /sys/kernel/debug/genwqe/genwqe<n>_card/queue_working_time | |
| 88 | +Date: Dec 2013 | |
| 89 | +Contact: haver@linux.vnet.ibm.com | |
| 90 | +Description: Dump queue working time register values for PF and VFs. | |
| 91 | + Only available for PF. | |
| @@ -197,6 +197,19 @@ Description: · 196 unmodified lines | ||
| 197 | 197 | Raw pressure measurement from channel Y. Units after |
| 198 | 198 | application of scale and offset are kilopascal. |
| 199 | 199 | |
| 200 | +What: /sys/bus/iio/devices/iio:deviceX/in_humidityrelative_raw | |
| 201 | +KernelVersion: 3.14 | |
| 202 | +Contact: linux-iio@vger.kernel.org | |
| 203 | +Description: | |
| 204 | + Raw humidity measurement of air. Units after application of | |
| 205 | + scale and offset are milli percent. | |
| 206 | + | |
| 207 | +What: /sys/bus/iio/devices/iio:deviceX/in_humidityrelative_input | |
| 208 | +KernelVersion: 3.14 | |
| 209 | +Contact: linux-iio@vger.kernel.org | |
| 210 | +Description: | |
| 211 | + Scaled humidity measurement in milli percent. | |
| 212 | + | |
| 200 | 213 | What: /sys/bus/iio/devices/iio:deviceX/in_accel_offset |
| 201 | 214 | What: /sys/bus/iio/devices/iio:deviceX/in_accel_x_offset |
| 202 | 215 | What: /sys/bus/iio/devices/iio:deviceX/in_accel_y_offset |
| @@ -70,18 +70,15 @@ Date: September, 2011 · 69 unmodified lines | ||
| 70 | 70 | Contact: Neil Horman <nhorman@tuxdriver.com> |
| 71 | 71 | Description: |
| 72 | 72 | The /sys/devices/.../msi_irqs directory contains a variable set |
| 73 | − of sub-directories, with each sub-directory being named after a | |
| 74 | − corresponding msi irq vector allocated to that device. Each | |
| 75 | − numbered sub-directory N contains attributes of that irq. | |
| 76 | − Note that this directory is not created for device drivers which | |
| 77 | − do not support msi irqs | |
| 73 | + of files, with each file being named after a corresponding msi | |
| 74 | + irq vector allocated to that device. | |
| 78 | 75 | |
| 79 | −What: /sys/bus/pci/devices/.../msi_irqs/<N>/mode | |
| 76 | +What: /sys/bus/pci/devices/.../msi_irqs/<N> | |
| 80 | 77 | Date: September 2011 |
| 81 | 78 | Contact: Neil Horman <nhorman@tuxdriver.com> |
| 82 | 79 | Description: |
| 83 | 80 | This attribute indicates the mode that the irq vector named by |
| 84 | − the parent directory is in (msi vs. msix) | |
| 81 | + the file is in (msi vs. msix) | |
| 85 | 82 | |
| 86 | 83 | What: /sys/bus/pci/devices/.../remove |
| 87 | 84 | Date: January 2009 |
| @@ -18,6 +18,28 @@ Removal of a device: · 17 unmodified lines | ||
| 18 | 18 | |
| 19 | 19 | $ echo <dev-id> > /sys/bus/rbd/remove |
| 20 | 20 | |
| 21 | +What: /sys/bus/rbd/add_single_major | |
| 22 | +Date: December 2013 | |
| 23 | +KernelVersion: 3.14 | |
| 24 | +Contact: Sage Weil <sage@inktank.com> | |
| 25 | +Description: Available only if rbd module is inserted with single_major | |
| 26 | + parameter set to true. | |
| 27 | + Usage is the same as for /sys/bus/rbd/add. If present, | |
| 28 | + should be used instead of the latter: any attempts to use | |
| 29 | + /sys/bus/rbd/add if /sys/bus/rbd/add_single_major is | |
| 30 | + available will fail for backwards compatibility reasons. | |
| 31 | + | |
| 32 | +What: /sys/bus/rbd/remove_single_major | |
| 33 | +Date: December 2013 | |
| 34 | +KernelVersion: 3.14 | |
| 35 | +Contact: Sage Weil <sage@inktank.com> | |
| 36 | +Description: Available only if rbd module is inserted with single_major | |
| 37 | + parameter set to true. | |
| 38 | + Usage is the same as for /sys/bus/rbd/remove. If present, | |
| 39 | + should be used instead of the latter: any attempts to use | |
| 40 | + /sys/bus/rbd/remove if /sys/bus/rbd/remove_single_major is | |
| 41 | + available will fail for backwards compatibility reasons. | |
| 42 | + | |
| 21 | 43 | Entries under /sys/bus/rbd/devices/<dev-id>/ |
| 22 | 44 | -------------------------------------------- |
| 23 | 45 | |
| @@ -33,6 +55,10 @@ major · 9 unmodified lines | ||
| 33 | 55 | |
| 34 | 56 | The block device major number. |
| 35 | 57 | |
| 58 | +minor | |
| 59 | + | |
| 60 | + The block device minor number. (December 2013, since 3.14.) | |
| 61 | + | |
| 36 | 62 | name |
| 37 | 63 | |
| 38 | 64 | The name of the rbd image. |
| @@ -50,13 +50,19 @@ Description: · 49 unmodified lines | ||
| 50 | 50 | This may allow the driver to support more hardware than |
| 51 | 51 | was included in the driver's static device ID support |
| 52 | 52 | table at compile time. The format for the device ID is: |
| 53 | − idVendor idProduct bInterfaceClass. | |
| 53 | + idVendor idProduct bInterfaceClass RefIdVendor RefIdProduct | |
| 54 | 54 | The vendor ID and device ID fields are required, the |
| 55 | − interface class is optional. | |
| 55 | + rest is optional. The Ref* tuple can be used to tell the | |
| 56 | + driver to use the same driver_data for the new device as | |
| 57 | + it is used for the reference device. | |
| 56 | 58 | Upon successfully adding an ID, the driver will probe |
| 57 | 59 | for the device and attempt to bind to it. For example: |
| 58 | 60 | # echo "8086 10f5" > /sys/bus/usb/drivers/foo/new_id |
| 59 | 61 | |
| 62 | + Here add a new device (0458:7045) using driver_data from | |
| 63 | + an already supported device (0458:704c): | |
| 64 | + # echo "0458 7045 0 0458 704c" > /sys/bus/usb/drivers/foo/new_id | |
| 65 | + | |
| 60 | 66 | Reading from this file will list all dynamically added |
| 61 | 67 | device IDs in the same format, with one entry per |
| 62 | 68 | line. For example: |
| @@ -68,6 +68,14 @@ Description: · 67 unmodified lines | ||
| 68 | 68 | Defines the penalty which will be applied to an |
| 69 | 69 | originator message's tq-field on every hop. |
| 70 | 70 | |
| 71 | +What: /sys/class/net/<mesh_iface>/mesh/isolation_mark | |
| 72 | +Date: Nov 2013 | |
| 73 | +Contact: Antonio Quartulli <antonio@meshcoding.com> | |
| 74 | +Description: | |
| 75 | + Defines the isolation mark (and its bitmask) which | |
| 76 | + is used to classify clients as "isolated" by the | |
| 77 | + Extended Isolation feature. | |
| 78 | + | |
| 71 | 79 | What: /sys/class/net/<mesh_iface>/mesh/network_coding |
| 72 | 80 | Date: Nov 2012 |
| 73 | 81 | Contact: Martin Hundeboll <martin@hundeboll.net> |
| @@ -200,3 +200,27 @@ Description: address and size of the percpu note. · 199 unmodified lines | ||
| 200 | 200 | note of cpu#. |
| 201 | 201 | |
| 202 | 202 | crash_notes_size: size of the note of cpu#. |
| 203 | + | |
| 204 | + | |
| 205 | +What: /sys/devices/system/cpu/intel_pstate/max_perf_pct | |
| 206 | + /sys/devices/system/cpu/intel_pstate/min_perf_pct | |
| 207 | + /sys/devices/system/cpu/intel_pstate/no_turbo | |
| 208 | +Date: February 2013 | |
| 209 | +Contact: linux-pm@vger.kernel.org | |
| 210 | +Description: Parameters for the Intel P-state driver | |
| 211 | + | |
| 212 | + Logic for selecting the current P-state in Intel | |
| 213 | + Sandybridge+ processors. The three knobs control | |
| 214 | + limits for the P-state that will be requested by the | |
| 215 | + driver. | |
| 216 | + | |
| 217 | + max_perf_pct: limits the maximum P state that will be requested by | |
| 218 | + the driver stated as a percentage of the available performance. | |
| 219 | + | |
| 220 | + min_perf_pct: limits the minimum P state that will be requested by | |
| 221 | + the driver stated as a percentage of the available performance. | |
| 222 | + | |
| 223 | + no_turbo: limits the driver to selecting P states below the turbo | |
| 224 | + frequency range. | |
| 225 | + | |
| 226 | + More details can be found in Documentation/cpu-freq/intel-pstate.txt | |
| @@ -0,0 +1,62 @@ | ||
| 1 | +What: /sys/class/genwqe/genwqe<n>_card/version | |
| 2 | +Date: Oct 2013 | |
| 3 | +Contact: haver@linux.vnet.ibm.com | |
| 4 | +Description: Unique bitstream identification e.g. | |
| 5 | + '0000000330336283.00000000475a4950'. | |
| 6 | + | |
| 7 | +What: /sys/class/genwqe/genwqe<n>_card/appid | |
| 8 | +Date: Oct 2013 | |
| 9 | +Contact: haver@linux.vnet.ibm.com | |
| 10 | +Description: Identifies the currently active card application e.g. 'GZIP' | |
| 11 | + for compression/decompression. | |
| 12 | + | |
| 13 | +What: /sys/class/genwqe/genwqe<n>_card/type | |
| 14 | +Date: Oct 2013 | |
| 15 | +Contact: haver@linux.vnet.ibm.com | |
| 16 | +Description: Type of the card e.g. 'GenWQE5-A7'. | |
| 17 | + | |
| 18 | +What: /sys/class/genwqe/genwqe<n>_card/curr_bitstream | |
| 19 | +Date: Oct 2013 | |
| 20 | +Contact: haver@linux.vnet.ibm.com | |
| 21 | +Description: Currently active bitstream. 1 is default, 0 is backup. | |
| 22 | + | |
| 23 | +What: /sys/class/genwqe/genwqe<n>_card/next_bitstream | |
| 24 | +Date: Oct 2013 | |
| 25 | +Contact: haver@linux.vnet.ibm.com | |
| 26 | +Description: Interface to set the next bitstream to be used. | |
| 27 | + | |
| 28 | +What: /sys/class/genwqe/genwqe<n>_card/tempsens | |
| 29 | +Date: Oct 2013 | |
| 30 | +Contact: haver@linux.vnet.ibm.com | |
| 31 | +Description: Interface to read the cards temperature sense register. | |
| 32 | + | |
| 33 | +What: /sys/class/genwqe/genwqe<n>_card/freerunning_timer | |
| 34 | +Date: Oct 2013 | |
| 35 | +Contact: haver@linux.vnet.ibm.com | |
| 36 | +Description: Interface to read the cards free running timer. | |
| 37 | + Used for performance and utilization measurements. | |
| 38 | + | |
| 39 | +What: /sys/class/genwqe/genwqe<n>_card/queue_working_time | |
| 40 | +Date: Oct 2013 | |
| 41 | +Contact: haver@linux.vnet.ibm.com | |
| 42 | +Description: Interface to read queue working time. | |
| 43 | + Used for performance and utilization measurements. | |
| 44 | + | |
| 45 | +What: /sys/class/genwqe/genwqe<n>_card/state | |
| 46 | +Date: Oct 2013 | |
| 47 | +Contact: haver@linux.vnet.ibm.com | |
| 48 | +Description: State of the card: "unused", "used", "error". | |
| 49 | + | |
| 50 | +What: /sys/class/genwqe/genwqe<n>_card/base_clock | |
| 51 | +Date: Oct 2013 | |
| 52 | +Contact: haver@linux.vnet.ibm.com | |
| 53 | +Description: Base clock frequency of the card. | |
| 54 | + | |
| 55 | +What: /sys/class/genwqe/genwqe<n>_card/device/sriov_numvfs | |
| 56 | +Date: Oct 2013 | |
| 57 | +Contact: haver@linux.vnet.ibm.com | |
| 58 | +Description: Enable VFs (1..15): | |
| 59 | + sudo sh -c 'echo 15 > \ | |
| 60 | + /sys/bus/pci/devices/0000\:1b\:00.0/sriov_numvfs' | |
| 61 | + Disable VFs: | |
| 62 | + Write a 0 into the same sysfs entry. | |
| @@ -24,3 +24,34 @@ Date: July 2013 · 23 unmodified lines | ||
| 24 | 24 | Contact: "Namjae Jeon" <namjae.jeon@samsung.com> |
| 25 | 25 | Description: |
| 26 | 26 | Controls the victim selection policy for garbage collection. |
| 27 | + | |
| 28 | +What: /sys/fs/f2fs/<disk>/reclaim_segments | |
| 29 | +Date: October 2013 | |
| 30 | +Contact: "Jaegeuk Kim" <jaegeuk.kim@samsung.com> | |
| 31 | +Description: | |
| 32 | + Controls the issue rate of segment discard commands. | |
| 33 | + | |
| 34 | +What: /sys/fs/f2fs/<disk>/ipu_policy | |
| 35 | +Date: November 2013 | |
| 36 | +Contact: "Jaegeuk Kim" <jaegeuk.kim@samsung.com> | |
| 37 | +Description: | |
| 38 | + Controls the in-place-update policy. | |
| 39 | + | |
| 40 | +What: /sys/fs/f2fs/<disk>/min_ipu_util | |
| 41 | +Date: November 2013 | |
| 42 | +Contact: "Jaegeuk Kim" <jaegeuk.kim@samsung.com> | |
| 43 | +Description: | |
| 44 | + Controls the FS utilization condition for the in-place-update | |
| 45 | + policies. | |
| 46 | + | |
| 47 | +What: /sys/fs/f2fs/<disk>/max_small_discards | |
| 48 | +Date: November 2013 | |
| 49 | +Contact: "Jaegeuk Kim" <jaegeuk.kim@samsung.com> | |
| 50 | +Description: | |
| 51 | + Controls the issue rate of small discard commands. | |
| 52 | + | |
| 53 | +What: /sys/fs/f2fs/<disk>/max_victim_search | |
| 54 | +Date: January 2014 | |
| 55 | +Contact: "Jaegeuk Kim" <jaegeuk.kim@samsung.com> | |
| 56 | +Description: | |
| 57 | + Controls the number of trials to find a victim segment. | |
| @@ -0,0 +1,14 @@ | ||
| 1 | +What: /sys/kernel/vmcoreinfo | |
| 2 | +Date: October 2007 | |
| 3 | +KernelVersion: 2.6.24 | |
| 4 | +Contact: Ken'ichi Ohmichi <oomichi@mxs.nes.nec.co.jp> | |
| 5 | + Kexec Mailing List <kexec@lists.infradead.org> | |
| 6 | + Vivek Goyal <vgoyal@redhat.com> | |
| 7 | +Description | |
| 8 | + Shows physical address and size of vmcoreinfo ELF note. | |
| 9 | + First value contains physical address of note in hex and | |
| 10 | + second value contains the size of note in hex. This ELF | |
| 11 | + note info is parsed by second kernel and exported to user | |
| 12 | + space as part of ELF note in /proc/vmcore file. This note | |
| 13 | + contains various information like struct size, symbol | |
| 14 | + values, page size etc. | |
| @@ -0,0 +1,16 @@ | ||
| 1 | +What: /sys/bus/platform/devices/tahvo-usb/otg_mode | |
| 2 | +Date: December 2013 | |
| 3 | +Contact: Aaro Koskinen <aaro.koskinen@iki.fi> | |
| 4 | +Description: | |
| 5 | + Set or read the current OTG mode. Valid values are "host" and | |
| 6 | + "peripheral". | |
| 7 | + | |
| 8 | + Reading: returns the current mode. | |
| 9 | + | |
| 10 | +What: /sys/bus/platform/devices/tahvo-usb/vbus | |
| 11 | +Date: December 2013 | |
| 12 | +Contact: Aaro Koskinen <aaro.koskinen@iki.fi> | |
| 13 | +Description: | |
| 14 | + Read the current VBUS state. | |
| 15 | + | |
| 16 | + Reading: returns "on" or "off". | |
| @@ -10,5 +10,6 @@ · 9 unmodified lines | ||
| 10 | 10 | *.out |
| 11 | 11 | *.png |
| 12 | 12 | *.gif |
| 13 | +*.svg | |
| 13 | 14 | media-indices.tmpl |
| 14 | 15 | media-entities.tmpl |
| @@ -54,6 +54,7 @@ htmldocs: $(HTML) · 53 unmodified lines | ||
| 54 | 54 | |
| 55 | 55 | MAN := $(patsubst %.xml, %.9, $(BOOKS)) |
| 56 | 56 | mandocs: $(MAN) |
| 57 | + $(if $(wildcard $(obj)/man/*.9),gzip -f $(obj)/man/*.9) | |
| 57 | 58 | |
| 58 | 59 | installmandocs: mandocs |
| 59 | 60 | mkdir -p /usr/local/man/man9/ |
| @@ -145,7 +146,7 @@ build_main_index = rm -rf $(main_idx); \ · 85 unmodified lines | ||
| 145 | 146 | cat $(HTML) >> $(main_idx) |
| 146 | 147 | |
| 147 | 148 | quiet_cmd_db2html = HTML $@ |
| 148 | − cmd_db2html = xmlto xhtml $(XMLTOFLAGS) -o $(patsubst %.html,%,$@) $< && \ | |
| 149 | + cmd_db2html = xmlto html $(XMLTOFLAGS) -o $(patsubst %.html,%,$@) $< && \ | |
| 149 | 150 | echo '<a HREF="$(patsubst %.html,%,$(notdir $@))/index.html"> \ |
| 150 | 151 | $(patsubst %.html,%,$(notdir $@))</a><p>' > $@ |
| 151 | 152 | |
| @@ -159,7 +160,7 @@ quiet_cmd_db2html = HTML $@ · 7 unmodified lines | ||
| 159 | 160 | cp $(PNG-$(basename $(notdir $@))) $(patsubst %.html,%,$@); fi |
| 160 | 161 | |
| 161 | 162 | quiet_cmd_db2man = MAN $@ |
| 162 | − cmd_db2man = if grep -q refentry $<; then xmlto man $(XMLTOFLAGS) -o $(obj)/man $< ; gzip -f $(obj)/man/*.9; fi | |
| 163 | + cmd_db2man = if grep -q refentry $<; then xmlto man $(XMLTOFLAGS) -o $(obj)/man $< ; fi | |
| 163 | 164 | %.9 : %.xml |
| 164 | 165 | @(which xmlto > /dev/null 2>&1) || \ |
| 165 | 166 | (echo "*** You need to install xmlto ***"; \ |
| @@ -109,6 +109,7 @@ X!Ilib/string.c · 108 unmodified lines | ||
| 109 | 109 | <sect1><title>The Slab Cache</title> |
| 110 | 110 | !Iinclude/linux/slab.h |
| 111 | 111 | !Emm/slab.c |
| 112 | +!Emm/util.c | |
| 112 | 113 | </sect1> |
| 113 | 114 | <sect1><title>User Space Memory Access</title> |
| 114 | 115 | !Iarch/x86/include/asm/uaccess_32.h |
| @@ -2523,6 +2523,18 @@ that used it. It was originally scheduled for removal in 2.6.35. · 2522 unmodified lines | ||
| 2523 | 2523 | </orderedlist> |
| 2524 | 2524 | </section> |
| 2525 | 2525 | |
| 2526 | + <section> | |
| 2527 | + <title>V4L2 in Linux 3.14</title> | |
| 2528 | + <orderedlist> | |
| 2529 | + <listitem> | |
| 2530 | + <para> In struct <structname>v4l2_rect</structname>, the type | |
| 2531 | +of <structfield>width</structfield> and <structfield>height</structfield> | |
| 2532 | +fields changed from _s32 to _u32. | |
| 2533 | + </para> | |
| 2534 | + </listitem> | |
| 2535 | + </orderedlist> | |
| 2536 | + </section> | |
| 2537 | + | |
| 2526 | 2538 | <section id="other"> |
| 2527 | 2539 | <title>Relation of V4L2 to other Linux multimedia APIs</title> |
| 2528 | 2540 | |
| @@ -3161,6 +3161,47 @@ V4L2_CID_MPEG_VIDEO_VPX_GOLDEN_FRAME_REF_PERIOD as a golden frame.</entry> · 3160 unmodified lines | ||
| 3161 | 3161 | </entrytbl> |
| 3162 | 3162 | </row> |
| 3163 | 3163 | |
| 3164 | + <row><entry></entry></row> | |
| 3165 | + <row> | |
| 3166 | + <entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_VPX_MIN_QP</constant></entry> | |
| 3167 | + <entry>integer</entry> | |
| 3168 | + </row> | |
| 3169 | + <row><entry spanname="descr">Minimum quantization parameter for VP8.</entry> | |
| 3170 | + </row> | |
| 3171 | + | |
| 3172 | + <row><entry></entry></row> | |
| 3173 | + <row> | |
| 3174 | + <entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_VPX_MAX_QP</constant></entry> | |
| 3175 | + <entry>integer</entry> | |
| 3176 | + </row> | |
| 3177 | + <row><entry spanname="descr">Maximum quantization parameter for VP8.</entry> | |
| 3178 | + </row> | |
| 3179 | + | |
| 3180 | + <row><entry></entry></row> | |
| 3181 | + <row> | |
| 3182 | + <entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_VPX_I_FRAME_QP</constant> </entry> | |
| 3183 | + <entry>integer</entry> | |
| 3184 | + </row> | |
| 3185 | + <row><entry spanname="descr">Quantization parameter for an I frame for VP8.</entry> | |
| 3186 | + </row> | |
| 3187 | + | |
| 3188 | + <row><entry></entry></row> | |
| 3189 | + <row> | |
| 3190 | + <entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_VPX_P_FRAME_QP</constant> </entry> | |
| 3191 | + <entry>integer</entry> | |
| 3192 | + </row> | |
| 3193 | + <row><entry spanname="descr">Quantization parameter for a P frame for VP8.</entry> | |
| 3194 | + </row> | |
| 3195 | + | |
| 3196 | + <row><entry></entry></row> | |
| 3197 | + <row> | |
| 3198 | + <entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_VPX_PROFILE</constant> </entry> | |
| 3199 | + <entry>integer</entry> | |
| 3200 | + </row> | |
| 3201 | + <row><entry spanname="descr">Select the desired profile for VPx encoder. | |
| 3202 | +Acceptable values are 0, 1, 2 and 3 corresponding to encoder profiles 0, 1, 2 and 3.</entry> | |
| 3203 | + </row> | |
| 3204 | + | |
| 3164 | 3205 | <row><entry></entry></row> |
| 3165 | 3206 | </tbody> |
| 3166 | 3207 | </tgroup> |
| @@ -346,17 +346,14 @@ rectangle, in pixels.</entry> · 345 unmodified lines | ||
| 346 | 346 | rectangle, in pixels. Offsets increase to the right and down.</entry> |
| 347 | 347 | </row> |
| 348 | 348 | <row> |
| 349 | − <entry>__s32</entry> | |
| 349 | + <entry>__u32</entry> | |
| 350 | 350 | <entry><structfield>width</structfield></entry> |
| 351 | 351 | <entry>Width of the rectangle, in pixels.</entry> |
| 352 | 352 | </row> |
| 353 | 353 | <row> |
| 354 | − <entry>__s32</entry> | |
| 354 | + <entry>__u32</entry> | |
| 355 | 355 | <entry><structfield>height</structfield></entry> |
| 356 | − <entry>Height of the rectangle, in pixels. Width and | |
| 357 | −height cannot be negative, the fields are signed for hysterical | |
| 358 | −reasons. <!-- video4linux-list@redhat.com on 22 Oct 2002 subject | |
| 359 | −"Re:[V4L][patches!] Re:v4l2/kernel-2.5" --></entry> | |
| 356 | + <entry>Height of the rectangle, in pixels.</entry> | |
| 360 | 357 | </row> |
| 361 | 358 | </tbody> |
| 362 | 359 | </tgroup> |
| @@ -134,6 +134,15 @@ · 133 unmodified lines | ||
| 134 | 134 | <entry>Output pad, relative to the entity. Output pads source data |
| 135 | 135 | and are origins of links.</entry> |
| 136 | 136 | </row> |
| 137 | + <row> | |
| 138 | + <entry><constant>MEDIA_PAD_FL_MUST_CONNECT</constant></entry> | |
| 139 | + <entry>If this flag is set and the pad is linked to any other | |
| 140 | + pad, then at least one of those links must be enabled for the | |
| 141 | + entity to be able to stream. There could be temporary reasons | |
| 142 | + (e.g. device configuration dependent) for the pad to need | |
| 143 | + enabled links even when this flag isn't set; the absence of the | |
| 144 | + flag doesn't imply there is none.</entry> | |
| 145 | + </row> | |
| 137 | 146 | </tbody> |
| 138 | 147 | </tgroup> |
| 139 | 148 | </table> |
| @@ -89,7 +89,7 @@ · 88 unmodified lines | ||
| 89 | 89 | <constant>V4L2_MBUS_FMT_RGB555_2X8_PADHI_BE</constant>. |
| 90 | 90 | </para> |
| 91 | 91 | |
| 92 | − <para>The following tables list existing packet RGB formats.</para> | |
| 92 | + <para>The following tables list existing packed RGB formats.</para> | |
| 93 | 93 | |
| 94 | 94 | <table pgwide="0" frame="none" id="v4l2-mbus-pixelcode-rgb"> |
| 95 | 95 | <title>RGB formats</title> |
| @@ -615,7 +615,7 @@ · 519 unmodified lines | ||
| 615 | 615 | </mediaobject> |
| 616 | 616 | </figure> |
| 617 | 617 | |
| 618 | − <para>The following table lists existing packet Bayer formats. The data | |
| 618 | + <para>The following table lists existing packed Bayer formats. The data | |
| 619 | 619 | organization is given as an example for the first pixel only.</para> |
| 620 | 620 | |
| 621 | 621 | <table pgwide="0" frame="none" id="v4l2-mbus-pixelcode-bayer"> |
| @@ -1178,7 +1178,7 @@ · 556 unmodified lines | ||
| 1178 | 1178 | U, Y, V, Y order will be named <constant>V4L2_MBUS_FMT_UYVY8_2X8</constant>. |
| 1179 | 1179 | </para> |
| 1180 | 1180 | |
| 1181 | − <para><xref linkend="v4l2-mbus-pixelcode-yuv8"/> list existing packet YUV | |
| 1181 | + <para><xref linkend="v4l2-mbus-pixelcode-yuv8"/> lists existing packed YUV | |
| 1182 | 1182 | formats and describes the organization of each pixel data in each sample. |
| 1183 | 1183 | When a format pattern is split across multiple samples each of the samples |
| 1184 | 1184 | in the pattern is described.</para> |
| @@ -2491,6 +2491,163 @@ · 1306 unmodified lines | ||
| 2491 | 2491 | </table> |
| 2492 | 2492 | </section> |
| 2493 | 2493 | |
| 2494 | + <section> | |
| 2495 | + <title>HSV/HSL Formats</title> | |
| 2496 | + | |
| 2497 | + <para>Those formats transfer pixel data as RGB values in a cylindrical-coordinate | |
| 2498 | + system using Hue-Saturation-Value or Hue-Saturation-Lightness components. The | |
| 2499 | + format code is made of the following information. | |
| 2500 | + <itemizedlist> | |
| 2501 | + <listitem><para>The hue, saturation, value or lightness and optional alpha | |
| 2502 | + components order code, as encoded in a pixel sample. The only currently | |
| 2503 | + supported value is AHSV. | |
| 2504 | + </para></listitem> | |
| 2505 | + <listitem><para>The number of bits per component, for each component. The values | |
| 2506 | + can be different for all components. The only currently supported value is 8888. | |
| 2507 | + </para></listitem> | |
| 2508 | + <listitem><para>The number of bus samples per pixel. Pixels that are wider than | |
| 2509 | + the bus width must be transferred in multiple samples. The only currently | |
| 2510 | + supported value is 1.</para></listitem> | |
| 2511 | + <listitem><para>The bus width.</para></listitem> | |
| 2512 | + <listitem><para>For formats where the total number of bits per pixel is smaller | |
| 2513 | + than the number of bus samples per pixel times the bus width, a padding | |
| 2514 | + value stating if the bytes are padded in their most high order bits | |
| 2515 | + (PADHI) or low order bits (PADLO).</para></listitem> | |
| 2516 | + <listitem><para>For formats where the number of bus samples per pixel is larger | |
| 2517 | + than 1, an endianness value stating if the pixel is transferred MSB first | |
| 2518 | + (BE) or LSB first (LE).</para></listitem> | |
| 2519 | + </itemizedlist> | |
| 2520 | + </para> | |
| 2521 | + | |
| 2522 | + <para>The following table lists existing HSV/HSL formats.</para> | |
| 2523 | + | |
| 2524 | + <table pgwide="0" frame="none" id="v4l2-mbus-pixelcode-hsv"> | |
| 2525 | + <title>HSV/HSL formats</title> | |
| 2526 | + <tgroup cols="27"> | |
| 2527 | + <colspec colname="id" align="left" /> | |
| 2528 | + <colspec colname="code" align="center"/> | |
| 2529 | + <colspec colname="bit" /> | |
| 2530 | + <colspec colnum="4" colname="b31" align="center" /> | |
| 2531 | + <colspec colnum="5" colname="b20" align="center" /> | |
| 2532 | + <colspec colnum="6" colname="b29" align="center" /> | |
| 2533 | + <colspec colnum="7" colname="b28" align="center" /> | |
| 2534 | + <colspec colnum="8" colname="b27" align="center" /> | |
| 2535 | + <colspec colnum="9" colname="b26" align="center" /> | |
| 2536 | + <colspec colnum="10" colname="b25" align="center" /> | |
| 2537 | + <colspec colnum="11" colname="b24" align="center" /> | |
| 2538 | + <colspec colnum="12" colname="b23" align="center" /> | |
| 2539 | + <colspec colnum="13" colname="b22" align="center" /> | |
| 2540 | + <colspec colnum="14" colname="b21" align="center" /> | |
| 2541 | + <colspec colnum="15" colname="b20" align="center" /> | |
| 2542 | + <colspec colnum="16" colname="b19" align="center" /> | |
| 2543 | + <colspec colnum="17" colname="b18" align="center" /> | |
| 2544 | + <colspec colnum="18" colname="b17" align="center" /> | |
| 2545 | + <colspec colnum="19" colname="b16" align="center" /> | |
| 2546 | + <colspec colnum="20" colname="b15" align="center" /> | |
| 2547 | + <colspec colnum="21" colname="b14" align="center" /> | |
| 2548 | + <colspec colnum="22" colname="b13" align="center" /> | |
| 2549 | + <colspec colnum="23" colname="b12" align="center" /> | |
| 2550 | + <colspec colnum="24" colname="b11" align="center" /> | |
| 2551 | + <colspec colnum="25" colname="b10" align="center" /> | |
| 2552 | + <colspec colnum="26" colname="b09" align="center" /> | |
| 2553 | + <colspec colnum="27" colname="b08" align="center" /> | |
| 2554 | + <colspec colnum="28" colname="b07" align="center" /> | |
| 2555 | + <colspec colnum="29" colname="b06" align="center" /> | |
| 2556 | + <colspec colnum="30" colname="b05" align="center" /> | |
| 2557 | + <colspec colnum="31" colname="b04" align="center" /> | |
| 2558 | + <colspec colnum="32" colname="b03" align="center" /> | |
| 2559 | + <colspec colnum="33" colname="b02" align="center" /> | |
| 2560 | + <colspec colnum="34" colname="b01" align="center" /> | |
| 2561 | + <colspec colnum="35" colname="b00" align="center" /> | |
| 2562 | + <spanspec namest="b31" nameend="b00" spanname="b0" /> | |
| 2563 | + <thead> | |
| 2564 | + <row> | |
| 2565 | + <entry>Identifier</entry> | |
| 2566 | + <entry>Code</entry> | |
| 2567 | + <entry></entry> | |
| 2568 | + <entry spanname="b0">Data organization</entry> | |
| 2569 | + </row> | |
| 2570 | + <row> | |
| 2571 | + <entry></entry> | |
| 2572 | + <entry></entry> | |
| 2573 | + <entry>Bit</entry> | |
| 2574 | + <entry>31</entry> | |
| 2575 | + <entry>30</entry> | |
| 2576 | + <entry>29</entry> | |
| 2577 | + <entry>28</entry> | |
| 2578 | + <entry>27</entry> | |
| 2579 | + <entry>26</entry> | |
| 2580 | + <entry>25</entry> | |
| 2581 | + <entry>24</entry> | |
| 2582 | + <entry>23</entry> | |
| 2583 | + <entry>22</entry> | |
| 2584 | + <entry>21</entry> | |
| 2585 | + <entry>20</entry> | |
| 2586 | + <entry>19</entry> | |
| 2587 | + <entry>18</entry> | |
| 2588 | + <entry>17</entry> | |
| 2589 | + <entry>16</entry> | |
| 2590 | + <entry>15</entry> | |
| 2591 | + <entry>14</entry> | |
| 2592 | + <entry>13</entry> | |
| 2593 | + <entry>12</entry> | |
| 2594 | + <entry>11</entry> | |
| 2595 | + <entry>10</entry> | |
| 2596 | + <entry>9</entry> | |
| 2597 | + <entry>8</entry> | |
| 2598 | + <entry>7</entry> | |
| 2599 | + <entry>6</entry> | |
| 2600 | + <entry>5</entry> | |
| 2601 | + <entry>4</entry> | |
| 2602 | + <entry>3</entry> | |
| 2603 | + <entry>2</entry> | |
| 2604 | + <entry>1</entry> | |
| 2605 | + <entry>0</entry> | |
| 2606 | + </row> | |
| 2607 | + </thead> | |
| 2608 | + <tbody valign="top"> | |
| 2609 | + <row id="V4L2-MBUS-FMT-AHSV8888-1X32"> | |
| 2610 | + <entry>V4L2_MBUS_FMT_AHSV8888_1X32</entry> | |
| 2611 | + <entry>0x6001</entry> | |
| 2612 | + <entry></entry> | |
| 2613 | + <entry>a<subscript>7</subscript></entry> | |
| 2614 | + <entry>a<subscript>6</subscript></entry> | |
| 2615 | + <entry>a<subscript>5</subscript></entry> | |
| 2616 | + <entry>a<subscript>4</subscript></entry> | |
| 2617 | + <entry>a<subscript>3</subscript></entry> | |
| 2618 | + <entry>a<subscript>2</subscript></entry> | |
| 2619 | + <entry>a<subscript>1</subscript></entry> | |
| 2620 | + <entry>a<subscript>0</subscript></entry> | |
| 2621 | + <entry>h<subscript>7</subscript></entry> | |
| 2622 | + <entry>h<subscript>6</subscript></entry> | |
| 2623 | + <entry>h<subscript>5</subscript></entry> | |
| 2624 | + <entry>h<subscript>4</subscript></entry> | |
| 2625 | + <entry>h<subscript>3</subscript></entry> | |
| 2626 | + <entry>h<subscript>2</subscript></entry> | |
| 2627 | + <entry>h<subscript>1</subscript></entry> | |
| 2628 | + <entry>h<subscript>0</subscript></entry> | |
| 2629 | + <entry>s<subscript>7</subscript></entry> | |
| 2630 | + <entry>s<subscript>6</subscript></entry> | |
| 2631 | + <entry>s<subscript>5</subscript></entry> | |
| 2632 | + <entry>s<subscript>4</subscript></entry> | |
| 2633 | + <entry>s<subscript>3</subscript></entry> | |
| 2634 | + <entry>s<subscript>2</subscript></entry> | |
| 2635 | + <entry>s<subscript>1</subscript></entry> | |
| 2636 | + <entry>s<subscript>0</subscript></entry> | |
| 2637 | + <entry>v<subscript>7</subscript></entry> | |
| 2638 | + <entry>v<subscript>6</subscript></entry> | |
| 2639 | + <entry>v<subscript>5</subscript></entry> | |
| 2640 | + <entry>v<subscript>4</subscript></entry> | |
| 2641 | + <entry>v<subscript>3</subscript></entry> | |
| 2642 | + <entry>v<subscript>2</subscript></entry> | |
| 2643 | + <entry>v<subscript>1</subscript></entry> | |
| 2644 | + <entry>v<subscript>0</subscript></entry> | |
| 2645 | + </row> | |
| 2646 | + </tbody> | |
| 2647 | + </tgroup> | |
| 2648 | + </table> | |
| 2649 | + </section> | |
| 2650 | + | |
| 2494 | 2651 | <section> |
| 2495 | 2652 | <title>JPEG Compressed Formats</title> |
| 2496 | 2653 | |
| @@ -140,6 +140,14 @@ structs, ioctls) must be noted in more detail in the history chapter · 139 unmodified lines | ||
| 140 | 140 | (compat.xml), along with the possible impact on existing drivers and |
| 141 | 141 | applications. --> |
| 142 | 142 | |
| 143 | + <revision> | |
| 144 | + <revnumber>3.14</revnumber> | |
| 145 | + <date>2013-11-25</date> | |
| 146 | + <authorinitials>rr</authorinitials> | |
| 147 | + <revremark>Set width and height as unsigned on v4l2_rect. | |
| 148 | + </revremark> | |
| 149 | + </revision> | |
| 150 | + | |
| 143 | 151 | <revision> |
| 144 | 152 | <revnumber>3.11</revnumber> |
| 145 | 153 | <date>2013-05-26</date> |
| @@ -501,7 +509,7 @@ and discussions on the V4L mailing list.</revremark> · 355 unmodified lines | ||
| 501 | 509 | </partinfo> |
| 502 | 510 | |
| 503 | 511 | <title>Video for Linux Two API Specification</title> |
| 504 | − <subtitle>Revision 3.11</subtitle> | |
| 512 | + <subtitle>Revision 3.14</subtitle> | |
| 505 | 513 | |
| 506 | 514 | <chapter id="common"> |
| 507 | 515 | &sub-common; |
| @@ -133,18 +133,14 @@ rectangle, in pixels.</entry> · 132 unmodified lines | ||
| 133 | 133 | rectangle, in pixels.</entry> |
| 134 | 134 | </row> |
| 135 | 135 | <row> |
| 136 | − <entry>__s32</entry> | |
| 136 | + <entry>__u32</entry> | |
| 137 | 137 | <entry><structfield>width</structfield></entry> |
| 138 | 138 | <entry>Width of the rectangle, in pixels.</entry> |
| 139 | 139 | </row> |
| 140 | 140 | <row> |
| 141 | − <entry>__s32</entry> | |
| 141 | + <entry>__u32</entry> | |
| 142 | 142 | <entry><structfield>height</structfield></entry> |
| 143 | − <entry>Height of the rectangle, in pixels. Width | |
| 144 | −and height cannot be negative, the fields are signed for | |
| 145 | −hysterical reasons. <!-- video4linux-list@redhat.com | |
| 146 | −on 22 Oct 2002 subject "Re:[V4L][patches!] Re:v4l2/kernel-2.5" --> | |
| 147 | −</entry> | |
| 143 | + <entry>Height of the rectangle, in pixels.</entry> | |
| 148 | 144 | </row> |
| 149 | 145 | </tbody> |
| 150 | 146 | </tgroup> |
| @@ -59,7 +59,7 @@ buffers are filled (if there are any empty buffers in the incoming · 58 unmodified lines | ||
| 59 | 59 | queue) until <constant>VIDIOC_STREAMON</constant> has been called. |
| 60 | 60 | Accordingly the output hardware is disabled, no video signal is |
| 61 | 61 | produced until <constant>VIDIOC_STREAMON</constant> has been called. |
| 62 | −The ioctl will succeed only when at least one output buffer is in the | |
| 62 | +The ioctl will succeed when at least one output buffer is in the | |
| 63 | 63 | incoming queue.</para> |
| 64 | 64 | |
| 65 | 65 | <para>The <constant>VIDIOC_STREAMOFF</constant> ioctl, apart of |
| @@ -112,7 +112,7 @@ required reading: · 111 unmodified lines | ||
| 112 | 112 | |
| 113 | 113 | Other excellent descriptions of how to create patches properly are: |
| 114 | 114 | "The Perfect Patch" |
| 115 | − http://kerneltrap.org/node/3737 | |
| 115 | + http://www.ozlabs.org/~akpm/stuff/tpp.txt | |
| 116 | 116 | "Linux kernel patch submission format" |
| 117 | 117 | http://linux.yyz.us/patch-format.html |
| 118 | 118 | |
| @@ -579,7 +579,7 @@ all time. It should describe the patch completely, containing: · 460 unmodified lines | ||
| 579 | 579 | For more details on what this should all look like, please see the |
| 580 | 580 | ChangeLog section of the document: |
| 581 | 581 | "The Perfect Patch" |
| 582 | − http://userweb.kernel.org/~akpm/stuff/tpp.txt | |
| 582 | + http://www.ozlabs.org/~akpm/stuff/tpp.txt | |
| 583 | 583 | |
| 584 | 584 | |
| 585 | 585 | |
| @@ -141,7 +141,7 @@ will use a legacy domain only if an IRQ range is supplied by the · 140 unmodified lines | ||
| 141 | 141 | system and will otherwise use a linear domain mapping. The semantics |
| 142 | 142 | of this call are such that if an IRQ range is specified then |
| 143 | 143 | descriptors will be allocated on-the-fly for it, and if no range is |
| 144 | −specified it will fall through to irq_domain_add_linear() which meand | |
| 144 | +specified it will fall through to irq_domain_add_linear() which means | |
| 145 | 145 | *no* irq descriptors will be allocated. |
| 146 | 146 | |
| 147 | 147 | A typical use case for simple domains is where an irqchip provider |
| @@ -2,12 +2,12 @@ · 1 unmodified line | ||
| 2 | 2 | - this file |
| 3 | 3 | MSI-HOWTO.txt |
| 4 | 4 | - the Message Signaled Interrupts (MSI) Driver Guide HOWTO and FAQ. |
| 5 | −PCI-DMA-mapping.txt | |
| 6 | − - info for PCI drivers using DMA portably across all platforms | |
| 7 | 5 | PCIEBUS-HOWTO.txt |
| 8 | 6 | - a guide describing the PCI Express Port Bus driver |
| 9 | 7 | pci-error-recovery.txt |
| 10 | 8 | - info on PCI error recovery |
| 9 | +pci-iov-howto.txt | |
| 10 | + - the PCI Express I/O Virtualization HOWTO | |
| 11 | 11 | pci.txt |
| 12 | 12 | - info on the PCI subsystem for device driver authors |
| 13 | 13 | pcieaer-howto.txt |
| @@ -82,93 +82,111 @@ Most of the hard work is done for the driver in the PCI layer. It simply · 81 unmodified lines | ||
| 82 | 82 | has to request that the PCI layer set up the MSI capability for this |
| 83 | 83 | device. |
| 84 | 84 | |
| 85 | −4.2.1 pci_enable_msi | |
| 85 | +4.2.1 pci_enable_msi_range | |
| 86 | 86 | |
| 87 | −int pci_enable_msi(struct pci_dev *dev) | |
| 87 | +int pci_enable_msi_range(struct pci_dev *dev, int minvec, int maxvec) | |
| 88 | 88 | |
| 89 | −A successful call allocates ONE interrupt to the device, regardless | |
| 90 | −of how many MSIs the device supports. The device is switched from | |
| 91 | −pin-based interrupt mode to MSI mode. The dev->irq number is changed | |
| 92 | −to a new number which represents the message signaled interrupt; | |
| 93 | −consequently, this function should be called before the driver calls | |
| 94 | −request_irq(), because an MSI is delivered via a vector that is | |
| 95 | −different from the vector of a pin-based interrupt. | |
| 89 | +This function allows a device driver to request any number of MSI | |
| 90 | +interrupts within specified range from 'minvec' to 'maxvec'. | |
| 96 | 91 | |
| 97 | −4.2.2 pci_enable_msi_block | |
| 92 | +If this function returns a positive number it indicates the number of | |
| 93 | +MSI interrupts that have been successfully allocated. In this case | |
| 94 | +the device is switched from pin-based interrupt mode to MSI mode and | |
| 95 | +updates dev->irq to be the lowest of the new interrupts assigned to it. | |
| 96 | +The other interrupts assigned to the device are in the range dev->irq | |
| 97 | +to dev->irq + returned value - 1. Device driver can use the returned | |
| 98 | +number of successfully allocated MSI interrupts to further allocate | |
| 99 | +and initialize device resources. | |
| 98 | 100 | |
| 99 | −int pci_enable_msi_block(struct pci_dev *dev, int count) | |
| 101 | +If this function returns a negative number, it indicates an error and | |
| 102 | +the driver should not attempt to request any more MSI interrupts for | |
| 103 | +this device. | |
| 100 | 104 | |
| 101 | −This variation on the above call allows a device driver to request multiple | |
| 102 | −MSIs. The MSI specification only allows interrupts to be allocated in | |
| 103 | −powers of two, up to a maximum of 2^5 (32). | |
| 105 | +This function should be called before the driver calls request_irq(), | |
| 106 | +because MSI interrupts are delivered via vectors that are different | |
| 107 | +from the vector of a pin-based interrupt. | |
| 104 | 108 | |
| 105 | −If this function returns 0, it has succeeded in allocating at least as many | |
| 106 | −interrupts as the driver requested (it may have allocated more in order | |
| 107 | −to satisfy the power-of-two requirement). In this case, the function | |
| 108 | −enables MSI on this device and updates dev->irq to be the lowest of | |
| 109 | −the new interrupts assigned to it. The other interrupts assigned to | |
| 110 | −the device are in the range dev->irq to dev->irq + count - 1. | |
| 109 | +It is ideal if drivers can cope with a variable number of MSI interrupts; | |
| 110 | +there are many reasons why the platform may not be able to provide the | |
| 111 | +exact number that a driver asks for. | |
| 111 | 112 | |
| 112 | −If this function returns a negative number, it indicates an error and | |
| 113 | −the driver should not attempt to request any more MSI interrupts for | |
| 114 | −this device. If this function returns a positive number, it is | |
| 115 | −less than 'count' and indicates the number of interrupts that could have | |
| 116 | −been allocated. In neither case is the irq value updated or the device | |
| 117 | −switched into MSI mode. | |
| 118 | − | |
| 119 | −The device driver must decide what action to take if | |
| 120 | −pci_enable_msi_block() returns a value less than the number requested. | |
| 121 | −For instance, the driver could still make use of fewer interrupts; | |
| 122 | −in this case the driver should call pci_enable_msi_block() | |
| 123 | −again. Note that it is not guaranteed to succeed, even when the | |
| 124 | −'count' has been reduced to the value returned from a previous call to | |
| 125 | −pci_enable_msi_block(). This is because there are multiple constraints | |
| 126 | −on the number of vectors that can be allocated; pci_enable_msi_block() | |
| 127 | −returns as soon as it finds any constraint that doesn't allow the | |
| 128 | −call to succeed. | |
| 129 | − | |
| 130 | −4.2.3 pci_enable_msi_block_auto | |
| 131 | − | |
| 132 | −int pci_enable_msi_block_auto(struct pci_dev *dev, unsigned int *count) | |
| 133 | − | |
| 134 | −This variation on pci_enable_msi() call allows a device driver to request | |
| 135 | −the maximum possible number of MSIs. The MSI specification only allows | |
| 136 | −interrupts to be allocated in powers of two, up to a maximum of 2^5 (32). | |
| 137 | − | |
| 138 | −If this function returns a positive number, it indicates that it has | |
| 139 | −succeeded and the returned value is the number of allocated interrupts. In | |
| 140 | −this case, the function enables MSI on this device and updates dev->irq to | |
| 141 | −be the lowest of the new interrupts assigned to it. The other interrupts | |
| 142 | −assigned to the device are in the range dev->irq to dev->irq + returned | |
| 143 | −value - 1. | |
| 113 | +There could be devices that can not operate with just any number of MSI | |
| 114 | +interrupts within a range. See chapter 4.3.1.3 to get the idea how to | |
| 115 | +handle such devices for MSI-X - the same logic applies to MSI. | |
| 144 | 116 | |
| 145 | −If this function returns a negative number, it indicates an error and | |
| 146 | −the driver should not attempt to request any more MSI interrupts for | |
| 147 | −this device. | |
| 117 | +4.2.1.1 Maximum possible number of MSI interrupts | |
| 118 | + | |
| 119 | +The typical usage of MSI interrupts is to allocate as many vectors as | |
| 120 | +possible, likely up to the limit returned by pci_msi_vec_count() function: | |
| 121 | + | |
| 122 | +static int foo_driver_enable_msi(struct pci_dev *pdev, int nvec) | |
| 123 | +{ | |
| 124 | + return pci_enable_msi_range(pdev, 1, nvec); | |
| 125 | +} | |
| 126 | + | |
| 127 | +Note the value of 'minvec' parameter is 1. As 'minvec' is inclusive, | |
| 128 | +the value of 0 would be meaningless and could result in error. | |
| 148 | 129 | |
| 149 | −If the device driver needs to know the number of interrupts the device | |
| 150 | −supports it can pass the pointer count where that number is stored. The | |
| 151 | −device driver must decide what action to take if pci_enable_msi_block_auto() | |
| 152 | −succeeds, but returns a value less than the number of interrupts supported. | |
| 153 | −If the device driver does not need to know the number of interrupts | |
| 154 | −supported, it can set the pointer count to NULL. | |
| 130 | +Some devices have a minimal limit on number of MSI interrupts. | |
| 131 | +In this case the function could look like this: | |
| 155 | 132 | |
| 156 | −4.2.4 pci_disable_msi | |
| 133 | +static int foo_driver_enable_msi(struct pci_dev *pdev, int nvec) | |
| 134 | +{ | |
| 135 | + return pci_enable_msi_range(pdev, FOO_DRIVER_MINIMUM_NVEC, nvec); | |
| 136 | +} | |
| 137 | + | |
| 138 | +4.2.1.2 Exact number of MSI interrupts | |
| 139 | + | |
| 140 | +If a driver is unable or unwilling to deal with a variable number of MSI | |
| 141 | +interrupts it could request a particular number of interrupts by passing | |
| 142 | +that number to pci_enable_msi_range() function as both 'minvec' and 'maxvec' | |
| 143 | +parameters: | |
| 144 | + | |
| 145 | +static int foo_driver_enable_msi(struct pci_dev *pdev, int nvec) | |
| 146 | +{ | |
| 147 | + return pci_enable_msi_range(pdev, nvec, nvec); | |
| 148 | +} | |
| 149 | + | |
| 150 | +4.2.1.3 Single MSI mode | |
| 151 | + | |
| 152 | +The most notorious example of the request type described above is | |
| 153 | +enabling the single MSI mode for a device. It could be done by passing | |
| 154 | +two 1s as 'minvec' and 'maxvec': | |
| 155 | + | |
| 156 | +static int foo_driver_enable_single_msi(struct pci_dev *pdev) | |
| 157 | +{ | |
| 158 | + return pci_enable_msi_range(pdev, 1, 1); | |
| 159 | +} | |
| 160 | + | |
| 161 | +4.2.2 pci_disable_msi | |
| 157 | 162 | |
| 158 | 163 | void pci_disable_msi(struct pci_dev *dev) |
| 159 | 164 | |
| 160 | −This function should be used to undo the effect of pci_enable_msi() or | |
| 161 | −pci_enable_msi_block() or pci_enable_msi_block_auto(). Calling it restores | |
| 162 | −dev->irq to the pin-based interrupt number and frees the previously | |
| 163 | −allocated message signaled interrupt(s). The interrupt may subsequently be | |
| 164 | −assigned to another device, so drivers should not cache the value of | |
| 165 | −dev->irq. | |
| 165 | +This function should be used to undo the effect of pci_enable_msi_range(). | |
| 166 | +Calling it restores dev->irq to the pin-based interrupt number and frees | |
| 167 | +the previously allocated MSIs. The interrupts may subsequently be assigned | |
| 168 | +to another device, so drivers should not cache the value of dev->irq. | |
| 166 | 169 | |
| 167 | 170 | Before calling this function, a device driver must always call free_irq() |
| 168 | 171 | on any interrupt for which it previously called request_irq(). |
| 169 | 172 | Failure to do so results in a BUG_ON(), leaving the device with |
| 170 | 173 | MSI enabled and thus leaking its vector. |
| 171 | 174 | |
| 175 | +4.2.3 pci_msi_vec_count | |
| 176 | + | |
| 177 | +int pci_msi_vec_count(struct pci_dev *dev) | |
| 178 | + | |
| 179 | +This function could be used to retrieve the number of MSI vectors the | |
| 180 | +device requested (via the Multiple Message Capable register). The MSI | |
| 181 | +specification only allows the returned value to be a power of two, | |
| 182 | +up to a maximum of 2^5 (32). | |
| 183 | + | |
| 184 | +If this function returns a negative number, it indicates the device is | |
| 185 | +not capable of sending MSIs. | |
| 186 | + | |
| 187 | +If this function returns a positive number, it indicates the maximum | |
| 188 | +number of MSI interrupt vectors that could be allocated. | |
| 189 | + | |
| 172 | 190 | 4.3 Using MSI-X |
| 173 | 191 | |
| 174 | 192 | The MSI-X capability is much more flexible than the MSI capability. |
| @@ -188,26 +206,31 @@ in each element of the array to indicate for which entries the kernel · 13 unmodified lines | ||
| 188 | 206 | should assign interrupts; it is invalid to fill in two entries with the |
| 189 | 207 | same number. |
| 190 | 208 | |
| 191 | −4.3.1 pci_enable_msix | |
| 209 | +4.3.1 pci_enable_msix_range | |
| 192 | 210 | |
| 193 | −int pci_enable_msix(struct pci_dev *dev, struct msix_entry *entries, int nvec) | |
| 211 | +int pci_enable_msix_range(struct pci_dev *dev, struct msix_entry *entries, | |
| 212 | + int minvec, int maxvec) | |
| 194 | 213 | |
| 195 | −Calling this function asks the PCI subsystem to allocate 'nvec' MSIs. | |
| 214 | +Calling this function asks the PCI subsystem to allocate any number of | |
| 215 | +MSI-X interrupts within specified range from 'minvec' to 'maxvec'. | |
| 196 | 216 | The 'entries' argument is a pointer to an array of msix_entry structs |
| 197 | −which should be at least 'nvec' entries in size. On success, the | |
| 198 | −device is switched into MSI-X mode and the function returns 0. | |
| 199 | −The 'vector' member in each entry is populated with the interrupt number; | |
| 217 | +which should be at least 'maxvec' entries in size. | |
| 218 | + | |
| 219 | +On success, the device is switched into MSI-X mode and the function | |
| 220 | +returns the number of MSI-X interrupts that have been successfully | |
| 221 | +allocated. In this case the 'vector' member in entries numbered from | |
| 222 | +0 to the returned value - 1 is populated with the interrupt number; | |
| 200 | 223 | the driver should then call request_irq() for each 'vector' that it |
| 201 | 224 | decides to use. The device driver is responsible for keeping track of the |
| 202 | 225 | interrupts assigned to the MSI-X vectors so it can free them again later. |
| 226 | +Device driver can use the returned number of successfully allocated MSI-X | |
| 227 | +interrupts to further allocate and initialize device resources. | |
| 203 | 228 | |
| 204 | 229 | If this function returns a negative number, it indicates an error and |
| 205 | 230 | the driver should not attempt to allocate any more MSI-X interrupts for |
| 206 | −this device. If it returns a positive number, it indicates the maximum | |
| 207 | −number of interrupt vectors that could have been allocated. See example | |
| 208 | −below. | |
| 231 | +this device. | |
| 209 | 232 | |
| 210 | −This function, in contrast with pci_enable_msi(), does not adjust | |
| 233 | +This function, in contrast with pci_enable_msi_range(), does not adjust | |
| 211 | 234 | dev->irq. The device will not generate interrupts for this interrupt |
| 212 | 235 | number once MSI-X is enabled. |
| 213 | 236 | |
| @@ -218,28 +241,103 @@ It is ideal if drivers can cope with a variable number of MSI-X interrupts; · 4 unmodified lines | ||
| 218 | 241 | there are many reasons why the platform may not be able to provide the |
| 219 | 242 | exact number that a driver asks for. |
| 220 | 243 | |
| 221 | −A request loop to achieve that might look like: | |
| 244 | +There could be devices that can not operate with just any number of MSI-X | |
| 245 | +interrupts within a range. E.g., an network adapter might need let's say | |
| 246 | +four vectors per each queue it provides. Therefore, a number of MSI-X | |
| 247 | +interrupts allocated should be a multiple of four. In this case interface | |
| 248 | +pci_enable_msix_range() can not be used alone to request MSI-X interrupts | |
| 249 | +(since it can allocate any number within the range, without any notion of | |
| 250 | +the multiple of four) and the device driver should master a custom logic | |
| 251 | +to request the required number of MSI-X interrupts. | |
| 252 | + | |
| 253 | +4.3.1.1 Maximum possible number of MSI-X interrupts | |
| 254 | + | |
| 255 | +The typical usage of MSI-X interrupts is to allocate as many vectors as | |
| 256 | +possible, likely up to the limit returned by pci_msix_vec_count() function: | |
| 222 | 257 | |
| 223 | 258 | static int foo_driver_enable_msix(struct foo_adapter *adapter, int nvec) |
| 224 | 259 | { |
| 225 | − while (nvec >= FOO_DRIVER_MINIMUM_NVEC) { | |
| 226 | − rc = pci_enable_msix(adapter->pdev, | |
| 227 | − adapter->msix_entries, nvec); | |
| 228 | − if (rc > 0) | |
| 229 | − nvec = rc; | |
| 230 | − else | |
| 231 | − return rc; | |
| 260 | + return pci_enable_msi_range(adapter->pdev, adapter->msix_entries, | |
| 261 | + 1, nvec); | |
| 262 | +} | |
| 263 | + | |
| 264 | +Note the value of 'minvec' parameter is 1. As 'minvec' is inclusive, | |
| 265 | +the value of 0 would be meaningless and could result in error. | |
| 266 | + | |
| 267 | +Some devices have a minimal limit on number of MSI-X interrupts. | |
| 268 | +In this case the function could look like this: | |
| 269 | + | |
| 270 | +static int foo_driver_enable_msix(struct foo_adapter *adapter, int nvec) | |
| 271 | +{ | |
| 272 | + return pci_enable_msi_range(adapter->pdev, adapter->msix_entries, | |
| 273 | + FOO_DRIVER_MINIMUM_NVEC, nvec); | |
| 274 | +} | |
| 275 | + | |
| 276 | +4.3.1.2 Exact number of MSI-X interrupts | |
| 277 | + | |
| 278 | +If a driver is unable or unwilling to deal with a variable number of MSI-X | |
| 279 | +interrupts it could request a particular number of interrupts by passing | |
| 280 | +that number to pci_enable_msix_range() function as both 'minvec' and 'maxvec' | |
| 281 | +parameters: | |
| 282 | + | |
| 283 | +static int foo_driver_enable_msix(struct foo_adapter *adapter, int nvec) | |
| 284 | +{ | |
| 285 | + return pci_enable_msi_range(adapter->pdev, adapter->msix_entries, | |
| 286 | + nvec, nvec); | |
| 287 | +} | |
| 288 | + | |
| 289 | +4.3.1.3 Specific requirements to the number of MSI-X interrupts | |
| 290 | + | |
| 291 | +As noted above, there could be devices that can not operate with just any | |
| 292 | +number of MSI-X interrupts within a range. E.g., let's assume a device that | |
| 293 | +is only capable sending the number of MSI-X interrupts which is a power of | |
| 294 | +two. A routine that enables MSI-X mode for such device might look like this: | |
| 295 | + | |
| 296 | +/* | |
| 297 | + * Assume 'minvec' and 'maxvec' are non-zero | |
| 298 | + */ | |
| 299 | +static int foo_driver_enable_msix(struct foo_adapter *adapter, | |
| 300 | + int minvec, int maxvec) | |
| 301 | +{ | |
| 302 | + int rc; | |
| 303 | + | |
| 304 | + minvec = roundup_pow_of_two(minvec); | |
| 305 | + maxvec = rounddown_pow_of_two(maxvec); | |
| 306 | + | |
| 307 | + if (minvec > maxvec) | |
| 308 | + return -ERANGE; | |
| 309 | + | |
| 310 | +retry: | |
| 311 | + rc = pci_enable_msix_range(adapter->pdev, adapter->msix_entries, | |
| 312 | + maxvec, maxvec); | |
| 313 | + /* | |
| 314 | + * -ENOSPC is the only error code allowed to be analized | |
| 315 | + */ | |
| 316 | + if (rc == -ENOSPC) { | |
| 317 | + if (maxvec == 1) | |
| 318 | + return -ENOSPC; | |
| 319 | + | |
| 320 | + maxvec /= 2; | |
| 321 | + | |
| 322 | + if (minvec > maxvec) | |
| 323 | + return -ENOSPC; | |
| 324 | + | |
| 325 | + goto retry; | |
| 232 | 326 | } |
| 233 | 327 | |
| 234 | − return -ENOSPC; | |
| 328 | + return rc; | |
| 235 | 329 | } |
| 236 | 330 | |
| 331 | +Note how pci_enable_msix_range() return value is analized for a fallback - | |
| 332 | +any error code other than -ENOSPC indicates a fatal error and should not | |
| 333 | +be retried. | |
| 334 | + | |
| 237 | 335 | 4.3.2 pci_disable_msix |
| 238 | 336 | |
| 239 | 337 | void pci_disable_msix(struct pci_dev *dev) |
| 240 | 338 | |
| 241 | −This function should be used to undo the effect of pci_enable_msix(). It frees | |
| 242 | −the previously allocated message signaled interrupts. The interrupts may | |
| 339 | +This function should be used to undo the effect of pci_enable_msix_range(). | |
| 340 | +It frees the previously allocated MSI-X interrupts. The interrupts may | |
| 243 | 341 | subsequently be assigned to another device, so drivers should not cache |
| 244 | 342 | the value of the 'vector' elements over a call to pci_disable_msix(). |
| 245 | 343 | |
| @@ -255,18 +353,32 @@ MSI-X Table. This address is mapped by the PCI subsystem, and should not · 9 unmodified lines | ||
| 255 | 353 | be accessed directly by the device driver. If the driver wishes to |
| 256 | 354 | mask or unmask an interrupt, it should call disable_irq() / enable_irq(). |
| 257 | 355 | |
| 356 | +4.3.4 pci_msix_vec_count | |
| 357 | + | |
| 358 | +int pci_msix_vec_count(struct pci_dev *dev) | |
| 359 | + | |
| 360 | +This function could be used to retrieve number of entries in the device | |
| 361 | +MSI-X table. | |
| 362 | + | |
| 363 | +If this function returns a negative number, it indicates the device is | |
| 364 | +not capable of sending MSI-Xs. | |
| 365 | + | |
| 366 | +If this function returns a positive number, it indicates the maximum | |
| 367 | +number of MSI-X interrupt vectors that could be allocated. | |
| 368 | + | |
| 258 | 369 | 4.4 Handling devices implementing both MSI and MSI-X capabilities |
| 259 | 370 | |
| 260 | 371 | If a device implements both MSI and MSI-X capabilities, it can |
| 261 | 372 | run in either MSI mode or MSI-X mode, but not both simultaneously. |
| 262 | 373 | This is a requirement of the PCI spec, and it is enforced by the |
| 263 | −PCI layer. Calling pci_enable_msi() when MSI-X is already enabled or | |
| 264 | −pci_enable_msix() when MSI is already enabled results in an error. | |
| 265 | −If a device driver wishes to switch between MSI and MSI-X at runtime, | |
| 266 | −it must first quiesce the device, then switch it back to pin-interrupt | |
| 267 | −mode, before calling pci_enable_msi() or pci_enable_msix() and resuming | |
| 268 | −operation. This is not expected to be a common operation but may be | |
| 269 | −useful for debugging or testing during development. | |
| 374 | +PCI layer. Calling pci_enable_msi_range() when MSI-X is already | |
| 375 | +enabled or pci_enable_msix_range() when MSI is already enabled | |
| 376 | +results in an error. If a device driver wishes to switch between MSI | |
| 377 | +and MSI-X at runtime, it must first quiesce the device, then switch | |
| 378 | +it back to pin-interrupt mode, before calling pci_enable_msi_range() | |
| 379 | +or pci_enable_msix_range() and resuming operation. This is not expected | |
| 380 | +to be a common operation but may be useful for debugging or testing | |
| 381 | +during development. | |
| 270 | 382 | |
| 271 | 383 | 4.5 Considerations when using MSIs |
| 272 | 384 | |
| @@ -381,5 +493,5 @@ or disabled (0). If 0 is found in any of the msi_bus files belonging · 108 unmodified lines | ||
| 381 | 493 | to bridges between the PCI root and the device, MSIs are disabled. |
| 382 | 494 | |
| 383 | 495 | It is also worth checking the device driver to see whether it supports MSIs. |
| 384 | −For example, it may contain calls to pci_enable_msi(), pci_enable_msix() or | |
| 385 | −pci_enable_msi_block(). | |
| 496 | +For example, it may contain calls to pci_enable_msi_range() or | |
| 497 | +pci_enable_msix_range(). | |
| @@ -123,8 +123,10 @@ initialization with a pointer to a structure describing the driver · 122 unmodified lines | ||
| 123 | 123 | |
| 124 | 124 | |
| 125 | 125 | The ID table is an array of struct pci_device_id entries ending with an |
| 126 | −all-zero entry; use of the macro DEFINE_PCI_DEVICE_TABLE is the preferred | |
| 127 | −method of declaring the table. Each entry consists of: | |
| 126 | +all-zero entry. Definitions with static const are generally preferred. | |
| 127 | +Use of the deprecated macro DEFINE_PCI_DEVICE_TABLE should be avoided. | |
| 128 | + | |
| 129 | +Each entry consists of: | |
| 128 | 130 | |
| 129 | 131 | vendor,device Vendor and device ID to match (or PCI_ANY_ID) |
| 130 | 132 | |
| @@ -293,36 +293,13 @@ the device to the driver. For example: · 292 unmodified lines | ||
| 293 | 293 | |
| 294 | 294 | These GPIO numbers are controller relative and path "\\_SB.PCI0.GPI0" |
| 295 | 295 | specifies the path to the controller. In order to use these GPIOs in Linux |
| 296 | −we need to translate them to the Linux GPIO numbers. | |
| 296 | +we need to translate them to the corresponding Linux GPIO descriptors. | |
| 297 | 297 | |
| 298 | −In a simple case of just getting the Linux GPIO number from device | |
| 299 | −resources one can use acpi_get_gpio_by_index() helper function. It takes | |
| 300 | −pointer to the device and index of the GpioIo/GpioInt descriptor in the | |
| 301 | −device resources list. For example: | |
| 298 | +There is a standard GPIO API for that and is documented in | |
| 299 | +Documentation/gpio.txt. | |
| 302 | 300 | |
| 303 | − int gpio_irq, gpio_power; | |
| 304 | − int ret; | |
| 305 | − | |
| 306 | − gpio_irq = acpi_get_gpio_by_index(dev, 1, NULL); | |
| 307 | − if (gpio_irq < 0) | |
| 308 | − /* handle error */ | |
| 309 | − | |
| 310 | − gpio_power = acpi_get_gpio_by_index(dev, 0, NULL); | |
| 311 | − if (gpio_power < 0) | |
| 312 | − /* handle error */ | |
| 313 | − | |
| 314 | − /* Now we can use the GPIO numbers */ | |
| 315 | − | |
| 316 | −Other GpioIo parameters must be converted first by the driver to be | |
| 317 | −suitable to the gpiolib before passing them. | |
| 318 | − | |
| 319 | −In case of GpioInt resource an additional call to gpio_to_irq() must be | |
| 320 | −done before calling request_irq(). | |
| 321 | − | |
| 322 | −Note that the above API is ACPI specific and not recommended for drivers | |
| 323 | −that need to support non-ACPI systems. The recommended way is to use | |
| 324 | −the descriptor based GPIO interfaces. The above example looks like this | |
| 325 | −when converted to the GPIO desc: | |
| 301 | +In the above example we can get the corresponding two GPIO descriptors with | |
| 302 | +a code like this: | |
| 326 | 303 | |
| 327 | 304 | #include <linux/gpio/consumer.h> |
| 328 | 305 | ... |
| @@ -339,4 +316,5 @@ when converted to the GPIO desc: · 10 unmodified lines | ||
| 339 | 316 | |
| 340 | 317 | /* Now we can use the GPIO descriptors */ |
| 341 | 318 | |
| 342 | −See also Documentation/gpio.txt. | |
| 319 | +There are also devm_* versions of these functions which release the | |
| 320 | +descriptors once the device is released. | |
| @@ -235,10 +235,6 @@ Wysocki <rafael.j.wysocki@intel.com>. · 234 unmodified lines | ||
| 235 | 235 | named object's type in the second column). In that case the object's |
| 236 | 236 | directory in sysfs will contain the 'path' attribute whose value is |
| 237 | 237 | the full path to the node from the namespace root. |
| 238 | − struct acpi_device objects are created for the ACPI namespace nodes | |
| 239 | − whose _STA control methods return PRESENT or FUNCTIONING. The power | |
| 240 | − resource nodes or nodes without _STA are assumed to be both PRESENT | |
| 241 | − and FUNCTIONING. | |
| 242 | 238 | F: |
| 243 | 239 | The struct acpi_device object is created for a fixed hardware |
| 244 | 240 | feature (as indicated by the fixed feature flag's name in the second |
| @@ -340,7 +336,7 @@ Wysocki <rafael.j.wysocki@intel.com>. · 95 unmodified lines | ||
| 340 | 336 | | +-------------+-------+----------------+ |
| 341 | 337 | | | |
| 342 | 338 | | | +- - - - - - - +- - - - - - +- - - - - - - -+ |
| 343 | − | +-| * PNP0C0D:00 | \_SB_.LID0 | acpi:PNP0C0D: | | |
| 339 | + | +-| PNP0C0D:00 | \_SB_.LID0 | acpi:PNP0C0D: | | |
| 344 | 340 | | | +- - - - - - - +- - - - - - +- - - - - - - -+ |
| 345 | 341 | | | |
| 346 | 342 | | | +------------+------------+-----------------------+ |
| @@ -390,6 +386,3 @@ Wysocki <rafael.j.wysocki@intel.com>. · 43 unmodified lines | ||
| 390 | 386 | attribute (as described earlier in this document). |
| 391 | 387 | NOTE: N/A indicates the device object does not have the 'path' or the |
| 392 | 388 | 'modalias' attribute. |
| 393 | − NOTE: The PNP0C0D device listed above is highlighted (marked by "*") | |
| 394 | − to indicate it will be created only when its _STA methods return | |
| 395 | − PRESENT or FUNCTIONING. | |
| @@ -211,6 +211,30 @@ MMP/MMP2 family (communication processor) · 210 unmodified lines | ||
| 211 | 211 | Linux kernel mach directory: arch/arm/mach-mmp |
| 212 | 212 | Linux kernel plat directory: arch/arm/plat-pxa |
| 213 | 213 | |
| 214 | +Berlin family (Digital Entertainment) | |
| 215 | +------------------------------------- | |
| 216 | + | |
| 217 | + Flavors: | |
| 218 | + 88DE3005, Armada 1500-mini | |
| 219 | + Design name: BG2CD | |
| 220 | + Core: ARM Cortex-A9, PL310 L2CC | |
| 221 | + Homepage: http://www.marvell.com/digital-entertainment/armada-1500-mini/ | |
| 222 | + 88DE3100, Armada 1500 | |
| 223 | + Design name: BG2 | |
| 224 | + Core: Marvell PJ4B (ARMv7), Tauros3 L2CC | |
| 225 | + Homepage: http://www.marvell.com/digital-entertainment/armada-1500/ | |
| 226 | + Product Brief: http://www.marvell.com/digital-entertainment/armada-1500/assets/Marvell-ARMADA-1500-Product-Brief.pdf | |
| 227 | + 88DE???? | |
| 228 | + Design name: BG3 | |
| 229 | + Core: ARM Cortex-A15, CA15 integrated L2CC | |
| 230 | + | |
| 231 | + Homepage: http://www.marvell.com/digital-entertainment/ | |
| 232 | + Directory: arch/arm/mach-berlin | |
| 233 | + | |
| 234 | + Comments: | |
| 235 | + * This line of SoCs is based on Marvell Sheeva or ARM Cortex CPUs | |
| 236 | + with Synopsys DesignWare (IRQ, GPIO, Timers, ...) and PXA IP (SDHCI, USB, ETH, ...). | |
| 237 | + | |
| 214 | 238 | Long-term plans |
| 215 | 239 | --------------- |
| 216 | 240 | |
| @@ -85,21 +85,10 @@ between the calls. · 84 unmodified lines | ||
| 85 | 85 | Headers |
| 86 | 86 | ------- |
| 87 | 87 | |
| 88 | − See arch/arm/mach-s3c2410/include/mach/regs-gpio.h for the list | |
| 88 | + See arch/arm/mach-s3c24xx/include/mach/regs-gpio.h for the list | |
| 89 | 89 | of GPIO pins, and the configuration values for them. This |
| 90 | 90 | is included by using #include <mach/regs-gpio.h> |
| 91 | 91 | |
| 92 | − The GPIO management functions are defined in the hardware | |
| 93 | − header arch/arm/mach-s3c2410/include/mach/hardware.h which can be | |
| 94 | − included by #include <mach/hardware.h> | |
| 95 | − | |
| 96 | − A useful amount of documentation can be found in the hardware | |
| 97 | − header on how the GPIO functions (and others) work. | |
| 98 | − | |
| 99 | − Whilst a number of these functions do make some checks on what | |
| 100 | − is passed to them, for speed of use, they may not always ensure | |
| 101 | − that the user supplied data to them is correct. | |
| 102 | − | |
| 103 | 92 | |
| 104 | 93 | PIN Numbers |
| 105 | 94 | ----------- |
| @@ -447,14 +447,13 @@ struct bio_vec { · 446 unmodified lines | ||
| 447 | 447 | * main unit of I/O for the block layer and lower layers (ie drivers) |
| 448 | 448 | */ |
| 449 | 449 | struct bio { |
| 450 | − sector_t bi_sector; | |
| 451 | 450 | struct bio *bi_next; /* request queue link */ |
| 452 | 451 | struct block_device *bi_bdev; /* target device */ |
| 453 | 452 | unsigned long bi_flags; /* status, command, etc */ |
| 454 | 453 | unsigned long bi_rw; /* low bits: r/w, high: priority */ |
| 455 | 454 | |
| 456 | 455 | unsigned int bi_vcnt; /* how may bio_vec's */ |
| 457 | − unsigned int bi_idx; /* current index into bio_vec array */ | |
| 456 | + struct bvec_iter bi_iter; /* current index into bio_vec array */ | |
| 458 | 457 | |
| 459 | 458 | unsigned int bi_size; /* total size in bytes */ |
| 460 | 459 | unsigned short bi_phys_segments; /* segments after physaddr coalesce*/ |
| @@ -480,7 +479,7 @@ With this multipage bio design: · 19 unmodified lines | ||
| 480 | 479 | - Code that traverses the req list can find all the segments of a bio |
| 481 | 480 | by using rq_for_each_segment. This handles the fact that a request |
| 482 | 481 | has multiple bios, each of which can have multiple segments. |
| 483 | −- Drivers which can't process a large bio in one shot can use the bi_idx | |
| 482 | +- Drivers which can't process a large bio in one shot can use the bi_iter | |
| 484 | 483 | field to keep track of the next bio_vec entry to process. |
| 485 | 484 | (e.g a 1MB bio_vec needs to be handled in max 128kB chunks for IDE) |
| 486 | 485 | [TBD: Should preferably also have a bi_voffset and bi_vlen to avoid modifying |
| @@ -589,7 +588,7 @@ driver should not modify these values. The block layer sets up the · 102 unmodified lines | ||
| 589 | 588 | nr_sectors and current_nr_sectors fields (based on the corresponding |
| 590 | 589 | hard_xxx values and the number of bytes transferred) and updates it on |
| 591 | 590 | every transfer that invokes end_that_request_first. It does the same for the |
| 592 | −buffer, bio, bio->bi_idx fields too. | |
| 591 | +buffer, bio, bio->bi_iter fields too. | |
| 593 | 592 | |
| 594 | 593 | The buffer field is just a virtual address mapping of the current segment |
| 595 | 594 | of the i/o buffer in cases where the buffer resides in low-memory. For high |
| @@ -0,0 +1,111 @@ | ||
| 1 | + | |
| 2 | +Immutable biovecs and biovec iterators: | |
| 3 | +======================================= | |
| 4 | + | |
| 5 | +Kent Overstreet <kmo@daterainc.com> | |
| 6 | + | |
| 7 | +As of 3.13, biovecs should never be modified after a bio has been submitted. | |
| 8 | +Instead, we have a new struct bvec_iter which represents a range of a biovec - | |
| 9 | +the iterator will be modified as the bio is completed, not the biovec. | |
| 10 | + | |
| 11 | +More specifically, old code that needed to partially complete a bio would | |
| 12 | +update bi_sector and bi_size, and advance bi_idx to the next biovec. If it | |
| 13 | +ended up partway through a biovec, it would increment bv_offset and decrement | |
| 14 | +bv_len by the number of bytes completed in that biovec. | |
| 15 | + | |
| 16 | +In the new scheme of things, everything that must be mutated in order to | |
| 17 | +partially complete a bio is segregated into struct bvec_iter: bi_sector, | |
| 18 | +bi_size and bi_idx have been moved there; and instead of modifying bv_offset | |
| 19 | +and bv_len, struct bvec_iter has bi_bvec_done, which represents the number of | |
| 20 | +bytes completed in the current bvec. | |
| 21 | + | |
| 22 | +There are a bunch of new helper macros for hiding the gory details - in | |
| 23 | +particular, presenting the illusion of partially completed biovecs so that | |
| 24 | +normal code doesn't have to deal with bi_bvec_done. | |
| 25 | + | |
| 26 | + * Driver code should no longer refer to biovecs directly; we now have | |
| 27 | + bio_iovec() and bio_iovec_iter() macros that return literal struct biovecs, | |
| 28 | + constructed from the raw biovecs but taking into account bi_bvec_done and | |
| 29 | + bi_size. | |
| 30 | + | |
| 31 | + bio_for_each_segment() has been updated to take a bvec_iter argument | |
| 32 | + instead of an integer (that corresponded to bi_idx); for a lot of code the | |
| 33 | + conversion just required changing the types of the arguments to | |
| 34 | + bio_for_each_segment(). | |
| 35 | + | |
| 36 | + * Advancing a bvec_iter is done with bio_advance_iter(); bio_advance() is a | |
| 37 | + wrapper around bio_advance_iter() that operates on bio->bi_iter, and also | |
| 38 | + advances the bio integrity's iter if present. | |
| 39 | + | |
| 40 | + There is a lower level advance function - bvec_iter_advance() - which takes | |
| 41 | + a pointer to a biovec, not a bio; this is used by the bio integrity code. | |
| 42 | + | |
| 43 | +What's all this get us? | |
| 44 | +======================= | |
| 45 | + | |
| 46 | +Having a real iterator, and making biovecs immutable, has a number of | |
| 47 | +advantages: | |
| 48 | + | |
| 49 | + * Before, iterating over bios was very awkward when you weren't processing | |
| 50 | + exactly one bvec at a time - for example, bio_copy_data() in fs/bio.c, | |
| 51 | + which copies the contents of one bio into another. Because the biovecs | |
| 52 | + wouldn't necessarily be the same size, the old code was tricky convoluted - | |
| 53 | + it had to walk two different bios at the same time, keeping both bi_idx and | |
| 54 | + and offset into the current biovec for each. | |
| 55 | + | |
| 56 | + The new code is much more straightforward - have a look. This sort of | |
| 57 | + pattern comes up in a lot of places; a lot of drivers were essentially open | |
| 58 | + coding bvec iterators before, and having common implementation considerably | |
| 59 | + simplifies a lot of code. | |
| 60 | + | |
| 61 | + * Before, any code that might need to use the biovec after the bio had been | |
| 62 | + completed (perhaps to copy the data somewhere else, or perhaps to resubmit | |
| 63 | + it somewhere else if there was an error) had to save the entire bvec array | |
| 64 | + - again, this was being done in a fair number of places. | |
| 65 | + | |
| 66 | + * Biovecs can be shared between multiple bios - a bvec iter can represent an | |
| 67 | + arbitrary range of an existing biovec, both starting and ending midway | |
| 68 | + through biovecs. This is what enables efficient splitting of arbitrary | |
| 69 | + bios. Note that this means we _only_ use bi_size to determine when we've | |
| 70 | + reached the end of a bio, not bi_vcnt - and the bio_iovec() macro takes | |
| 71 | + bi_size into account when constructing biovecs. | |
| 72 | + | |
| 73 | + * Splitting bios is now much simpler. The old bio_split() didn't even work on | |
| 74 | + bios with more than a single bvec! Now, we can efficiently split arbitrary | |
| 75 | + size bios - because the new bio can share the old bio's biovec. | |
| 76 | + | |
| 77 | + Care must be taken to ensure the biovec isn't freed while the split bio is | |
| 78 | + still using it, in case the original bio completes first, though. Using | |
| 79 | + bio_chain() when splitting bios helps with this. | |
| 80 | + | |
| 81 | + * Submitting partially completed bios is now perfectly fine - this comes up | |
| 82 | + occasionally in stacking block drivers and various code (e.g. md and | |
| 83 | + bcache) had some ugly workarounds for this. | |
| 84 | + | |
| 85 | + It used to be the case that submitting a partially completed bio would work | |
| 86 | + fine to _most_ devices, but since accessing the raw bvec array was the | |
| 87 | + norm, not all drivers would respect bi_idx and those would break. Now, | |
| 88 | + since all drivers _must_ go through the bvec iterator - and have been | |
| 89 | + audited to make sure they are - submitting partially completed bios is | |
| 90 | + perfectly fine. | |
| 91 | + | |
| 92 | +Other implications: | |
| 93 | +=================== | |
| 94 | + | |
| 95 | + * Almost all usage of bi_idx is now incorrect and has been removed; instead, | |
| 96 | + where previously you would have used bi_idx you'd now use a bvec_iter, | |
| 97 | + probably passing it to one of the helper macros. | |
| 98 | + | |
| 99 | + I.e. instead of using bio_iovec_idx() (or bio->bi_iovec[bio->bi_idx]), you | |
| 100 | + now use bio_iter_iovec(), which takes a bvec_iter and returns a | |
| 101 | + literal struct bio_vec - constructed on the fly from the raw biovec but | |
| 102 | + taking into account bi_bvec_done (and bi_size). | |
| 103 | + | |
| 104 | + * bi_vcnt can't be trusted or relied upon by driver code - i.e. anything that | |
| 105 | + doesn't actually own the bio. The reason is twofold: firstly, it's not | |
| 106 | + actually needed for iterating over the bio anymore - we only use bi_size. | |
| 107 | + Secondly, when cloning a bio and reusing (a portion of) the original bio's | |
| 108 | + biovec, in order to calculate bi_vcnt for the new bio we'd have to iterate | |
| 109 | + over all the biovecs in the new bio - which is silly as it's not needed. | |
| 110 | + | |
| 111 | + So, don't use bi_vcnt anymore. | |
| @@ -36,21 +36,30 @@ allowing one to squeeze more programs onto an average installation or · 35 unmodified lines | ||
| 36 | 36 | rescue floppy disk. |
| 37 | 37 | |
| 38 | 38 | |
| 39 | −2) Kernel Command Line Parameters | |
| 39 | +2) Parameters | |
| 40 | 40 | --------------------------------- |
| 41 | 41 | |
| 42 | +2a) Kernel Command Line Parameters | |
| 43 | + | |
| 42 | 44 | ramdisk_size=N |
| 43 | 45 | ============== |
| 44 | 46 | |
| 45 | 47 | This parameter tells the RAM disk driver to set up RAM disks of N k size. The |
| 46 | −default is 4096 (4 MB) (8192 (8 MB) on S390). | |
| 48 | +default is 4096 (4 MB). | |
| 49 | + | |
| 50 | +2b) Module parameters | |
| 47 | 51 | |
| 48 | − ramdisk_blocksize=N | |
| 49 | − =================== | |
| 52 | + rd_nr | |
| 53 | + ===== | |
| 54 | + /dev/ramX devices created. | |
| 50 | 55 | |
| 51 | −This parameter tells the RAM disk driver how many bytes to use per block. The | |
| 52 | −default is 1024 (BLOCK_SIZE). | |
| 56 | + max_part | |
| 57 | + ======== | |
| 58 | + Maximum partition number. | |
| 53 | 59 | |
| 60 | + rd_size | |
| 61 | + ======= | |
| 62 | + See ramdisk_size. | |
| 54 | 63 | |
| 55 | 64 | 3) Using "rdev -r" |
| 56 | 65 | ------------------ |
| @@ -1,8 +1,6 @@ | ||
| 1 | 1 | zram: Compressed RAM based block devices |
| 2 | 2 | ---------------------------------------- |
| 3 | 3 | |
| 4 | −Project home: http://compcache.googlecode.com/ | |
| 5 | − | |
| 6 | 4 | * Introduction |
| 7 | 5 | |
| 8 | 6 | The zram module creates RAM based block devices named /dev/zram<id> |
| @@ -69,9 +67,5 @@ Following shows a typical sequence of steps for using zram. · 60 unmodified lines | ||
| 69 | 67 | resets the disksize to zero. You must set the disksize again |
| 70 | 68 | before reusing the device. |
| 71 | 69 | |
| 72 | −Please report any problems at: | |
| 73 | − - Mailing list: linux-mm-cc at laptop dot org | |
| 74 | − - Issue tracker: http://code.google.com/p/compcache/issues/list | |
| 75 | − | |
| 76 | 70 | Nitin Gupta |
| 77 | 71 | ngupta@vflare.org |
| @@ -24,7 +24,6 @@ CONTENTS: · 23 unmodified lines | ||
| 24 | 24 | 2.1 Basic Usage |
| 25 | 25 | 2.2 Attaching processes |
| 26 | 26 | 2.3 Mounting hierarchies by name |
| 27 | − 2.4 Notification API | |
| 28 | 27 | 3. Kernel API |
| 29 | 28 | 3.1 Overview |
| 30 | 29 | 3.2 Synchronization |
| @@ -472,25 +471,6 @@ you give a subsystem a name. · 441 unmodified lines | ||
| 472 | 471 | The name of the subsystem appears as part of the hierarchy description |
| 473 | 472 | in /proc/mounts and /proc/<pid>/cgroups. |
| 474 | 473 | |
| 475 | −2.4 Notification API | |
| 476 | −-------------------- | |
| 477 | − | |
| 478 | −There is mechanism which allows to get notifications about changing | |
| 479 | −status of a cgroup. | |
| 480 | − | |
| 481 | −To register a new notification handler you need to: | |
| 482 | − - create a file descriptor for event notification using eventfd(2); | |
| 483 | − - open a control file to be monitored (e.g. memory.usage_in_bytes); | |
| 484 | − - write "<event_fd> <control_fd> <args>" to cgroup.event_control. | |
| 485 | − Interpretation of args is defined by control file implementation; | |
| 486 | − | |
| 487 | −eventfd will be woken up by control file implementation or when the | |
| 488 | −cgroup is removed. | |
| 489 | − | |
| 490 | −To unregister a notification handler just close eventfd. | |
| 491 | − | |
| 492 | −NOTE: Support of notifications should be implemented for the control | |
| 493 | −file. See documentation for the subsystem. | |
| 494 | 474 | |
| 495 | 475 | 3. Kernel API |
| 496 | 476 | ============= |
| @@ -577,7 +577,7 @@ Each memcg's numa_stat file includes "total", "file", "anon" and "unevictable" · 576 unmodified lines | ||
| 577 | 577 | per-node page counts including "hierarchical_<counter>" which sums up all |
| 578 | 578 | hierarchical children's values in addition to the memcg's own value. |
| 579 | 579 | |
| 580 | −The ouput format of memory.numa_stat is: | |
| 580 | +The output format of memory.numa_stat is: | |
| 581 | 581 | |
| 582 | 582 | total=<total pages> N0=<node 0 pages> N1=<node 1 pages> ... |
| 583 | 583 | file=<total file pages> N0=<node 0 pages> N1=<node 1 pages> ... |
| @@ -670,7 +670,7 @@ page tables. · 86 unmodified lines | ||
| 670 | 670 | |
| 671 | 671 | 8.1 Interface |
| 672 | 672 | |
| 673 | −This feature is disabled by default. It can be enabledi (and disabled again) by | |
| 673 | +This feature is disabled by default. It can be enabled (and disabled again) by | |
| 674 | 674 | writing to memory.move_charge_at_immigrate of the destination cgroup. |
| 675 | 675 | |
| 676 | 676 | If you want to enable it: |
| @@ -6,6 +6,8 @@ tag network packets with a class identifier (classid). · 5 unmodified lines | ||
| 6 | 6 | |
| 7 | 7 | The Traffic Controller (tc) can be used to assign |
| 8 | 8 | different priorities to packets from different cgroups. |
| 9 | +Also, Netfilter (iptables) can use this tag to perform | |
| 10 | +actions on such packets. | |
| 9 | 11 | |
| 10 | 12 | Creating a net_cls cgroups instance creates a net_cls.classid file. |
| 11 | 13 | This net_cls.classid value is initialized to 0. |
| @@ -32,3 +34,6 @@ tc class add dev eth0 parent 10: classid 10:1 htb rate 40mbit · 20 unmodified lines | ||
| 32 | 34 | - creating traffic class 10:1 |
| 33 | 35 | |
| 34 | 36 | tc filter add dev eth0 parent 10: protocol ip prio 10 handle 1: cgroup |
| 37 | + | |
| 38 | +configuring iptables, basic example: | |
| 39 | +iptables -A OUTPUT -m cgroup ! --cgroup 0x100001 -j DROP | |
| @@ -95,10 +95,10 @@ to work with it. · 94 unmodified lines | ||
| 95 | 95 | |
| 96 | 96 | f. u64 res_counter_uncharge_until |
| 97 | 97 | (struct res_counter *rc, struct res_counter *top, |
| 98 | − unsinged long val) | |
| 98 | + unsigned long val) | |
| 99 | 99 | |
| 100 | − Almost same as res_cunter_uncharge() but propagation of uncharge | |
| 101 | − stops when rc == top. This is useful when kill a res_coutner in | |
| 100 | + Almost same as res_counter_uncharge() but propagation of uncharge | |
| 101 | + stops when rc == top. This is useful when kill a res_counter in | |
| 102 | 102 | child cgroup. |
| 103 | 103 | |
| 104 | 104 | 2.1 Other accounting routines |
| @@ -77,6 +77,11 @@ the operations defined in clk.h: · 76 unmodified lines | ||
| 77 | 77 | int (*set_parent)(struct clk_hw *hw, u8 index); |
| 78 | 78 | u8 (*get_parent)(struct clk_hw *hw); |
| 79 | 79 | int (*set_rate)(struct clk_hw *hw, unsigned long); |
| 80 | + int (*set_rate_and_parent)(struct clk_hw *hw, | |
| 81 | + unsigned long rate, | |
| 82 | + unsigned long parent_rate, u8 index); | |
| 83 | + unsigned long (*recalc_accuracy)(struct clk_hw *hw, | |
| 84 | + unsigned long parent_accuracy); | |
| 80 | 85 | void (*init)(struct clk_hw *hw); |
| 81 | 86 | }; |
| 82 | 87 | |
| @@ -202,6 +207,8 @@ optional or must be evaluated on a case-by-case basis. · 119 unmodified lines | ||
| 202 | 207 | .set_parent | | | n | y | n | |
| 203 | 208 | .get_parent | | | n | y | n | |
| 204 | 209 | | | | | | | |
| 210 | +.recalc_accuracy| | | | | | | |
| 211 | + | | | | | | | |
| 205 | 212 | .init | | | | | | |
| 206 | 213 | ----------------------------------------------------------- |
| 207 | 214 | [1] either one of round_rate or determine_rate is required. |
| @@ -17,8 +17,8 @@ Introduction · 16 unmodified lines | ||
| 17 | 17 | Some CPUs support a functionality to raise the operating frequency of |
| 18 | 18 | some cores in a multi-core package if certain conditions apply, mostly |
| 19 | 19 | if the whole chip is not fully utilized and below it's intended thermal |
| 20 | −budget. This is done without operating system control by a combination | |
| 21 | −of hardware and firmware. | |
| 20 | +budget. The decision about boost disable/enable is made either at hardware | |
| 21 | +(e.g. x86) or software (e.g ARM). | |
| 22 | 22 | On Intel CPUs this is called "Turbo Boost", AMD calls it "Turbo-Core", |
| 23 | 23 | in technical documentation "Core performance boost". In Linux we use |
| 24 | 24 | the term "boost" for convenience. |
| @@ -48,24 +48,24 @@ be desirable: · 23 unmodified lines | ||
| 48 | 48 | User controlled switch |
| 49 | 49 | ---------------------- |
| 50 | 50 | |
| 51 | −To allow the user to toggle the boosting functionality, the acpi-cpufreq | |
| 52 | −driver exports a sysfs knob to disable it. There is a file: | |
| 51 | +To allow the user to toggle the boosting functionality, the cpufreq core | |
| 52 | +driver exports a sysfs knob to enable or disable it. There is a file: | |
| 53 | 53 | /sys/devices/system/cpu/cpufreq/boost |
| 54 | 54 | which can either read "0" (boosting disabled) or "1" (boosting enabled). |
| 55 | −Reading the file is always supported, even if the processor does not | |
| 56 | −support boosting. In this case the file will be read-only and always | |
| 57 | −reads as "0". Explicitly changing the permissions and writing to that | |
| 58 | −file anyway will return EINVAL. | |
| 55 | +The file is exported only when cpufreq driver supports boosting. | |
| 56 | +Explicitly changing the permissions and writing to that file anyway will | |
| 57 | +return EINVAL. | |
| 59 | 58 | |
| 60 | 59 | On supported CPUs one can write either a "0" or a "1" into this file. |
| 61 | 60 | This will either disable the boost functionality on all cores in the |
| 62 | −whole system (0) or will allow the hardware to boost at will (1). | |
| 61 | +whole system (0) or will allow the software or hardware to boost at will | |
| 62 | +(1). | |
| 63 | 63 | |
| 64 | 64 | Writing a "1" does not explicitly boost the system, but just allows the |
| 65 | −CPU (and the firmware) to boost at their discretion. Some implementations | |
| 66 | −take external factors like the chip's temperature into account, so | |
| 67 | −boosting once does not necessarily mean that it will occur every time | |
| 68 | −even using the exact same software setup. | |
| 65 | +CPU to boost at their discretion. Some implementations take external | |
| 66 | +factors like the chip's temperature into account, so boosting once does | |
| 67 | +not necessarily mean that it will occur every time even using the exact | |
| 68 | +same software setup. | |
| 69 | 69 | |
| 70 | 70 | |
| 71 | 71 | AMD legacy cpb switch |
| @@ -0,0 +1,40 @@ | ||
| 1 | +Intel P-state driver | |
| 2 | +-------------------- | |
| 3 | + | |
| 4 | +This driver implements a scaling driver with an internal governor for | |
| 5 | +Intel Core processors. The driver follows the same model as the | |
| 6 | +Transmeta scaling driver (longrun.c) and implements the setpolicy() | |
| 7 | +instead of target(). Scaling drivers that implement setpolicy() are | |
| 8 | +assumed to implement internal governors by the cpufreq core. All the | |
| 9 | +logic for selecting the current P state is contained within the | |
| 10 | +driver; no external governor is used by the cpufreq core. | |
| 11 | + | |
| 12 | +Intel SandyBridge+ processors are supported. | |
| 13 | + | |
| 14 | +New sysfs files for controlling P state selection have been added to | |
| 15 | +/sys/devices/system/cpu/intel_pstate/ | |
| 16 | + | |
| 17 | + max_perf_pct: limits the maximum P state that will be requested by | |
| 18 | + the driver stated as a percentage of the available performance. | |
| 19 | + | |
| 20 | + min_perf_pct: limits the minimum P state that will be requested by | |
| 21 | + the driver stated as a percentage of the available performance. | |
| 22 | + | |
| 23 | + no_turbo: limits the driver to selecting P states below the turbo | |
| 24 | + frequency range. | |
| 25 | + | |
| 26 | +For contemporary Intel processors, the frequency is controlled by the | |
| 27 | +processor itself and the P-states exposed to software are related to | |
| 28 | +performance levels. The idea that frequency can be set to a single | |
| 29 | +frequency is fiction for Intel Core processors. Even if the scaling | |
| 30 | +driver selects a single P state the actual frequency the processor | |
| 31 | +will run at is selected by the processor itself. | |
| 32 | + | |
| 33 | +New debugfs files have also been added to /sys/kernel/debug/pstate_snb/ | |
| 34 | + | |
| 35 | + deadband | |
| 36 | + d_gain_pct | |
| 37 | + i_gain_pct | |
| 38 | + p_gain_pct | |
| 39 | + sample_rate_ms | |
| 40 | + setpoint | |
| @@ -285,7 +285,7 @@ A: This is what you would need in your kernel code to receive notifications. · 284 unmodified lines | ||
| 285 | 285 | return NOTIFY_OK; |
| 286 | 286 | } |
| 287 | 287 | |
| 288 | − static struct notifier_block foobar_cpu_notifer = | |
| 288 | + static struct notifier_block foobar_cpu_notifier = | |
| 289 | 289 | { |
| 290 | 290 | .notifier_call = foobar_cpu_callback, |
| 291 | 291 | }; |
| @@ -22,10 +22,12 @@ locations such as buffers like the printk buffer or the process table. · 21 unmodified lines | ||
| 22 | 22 | Retrieving a full system memory dump is also possible over the FireWire, |
| 23 | 23 | using data transfer rates in the order of 10MB/s or more. |
| 24 | 24 | |
| 25 | −Memory access is currently limited to the low 4G of physical address | |
| 26 | −space which can be a problem on IA64 machines where memory is located | |
| 27 | −mostly above that limit, but it is rarely a problem on more common | |
| 28 | −hardware such as hardware based on x86, x86-64 and PowerPC. | |
| 25 | +With most FireWire controllers, memory access is limited to the low 4 GB | |
| 26 | +of physical address space. This can be a problem on IA64 machines where | |
| 27 | +memory is located mostly above that limit, but it is rarely a problem on | |
| 28 | +more common hardware such as x86, x86-64 and PowerPC. However, at least | |
| 29 | +Agere/LSI FW643e and FW643e2 controllers are known to support access to | |
| 30 | +physical addresses above 4 GB. | |
| 29 | 31 | |
| 30 | 32 | Together with a early initialization of the OHCI-1394 controller for debugging, |
| 31 | 33 | this facility proved most useful for examining long debugs logs in the printk |
| @@ -36,17 +38,11 @@ available (notebooks) or too slow for extensive debug information (like ACPI). · 4 unmodified lines | ||
| 36 | 38 | Drivers |
| 37 | 39 | ------- |
| 38 | 40 | |
| 39 | −The ohci1394 driver in drivers/ieee1394 initializes the OHCI-1394 controllers | |
| 40 | −to a working state and enables physical DMA by default for all remote nodes. | |
| 41 | −This can be turned off by ohci1394's module parameter phys_dma=0. | |
| 42 | − | |
| 43 | −The alternative firewire-ohci driver in drivers/firewire uses filtered physical | |
| 41 | +The firewire-ohci driver in drivers/firewire uses filtered physical | |
| 44 | 42 | DMA by default, which is more secure but not suitable for remote debugging. |
| 45 | −Compile the driver with CONFIG_FIREWIRE_OHCI_REMOTE_DMA (Kernel hacking menu: | |
| 46 | −Remote debugging over FireWire with firewire-ohci) to get unfiltered physical | |
| 47 | −DMA. | |
| 43 | +Pass the remote_dma=1 parameter to the driver to get unfiltered physical DMA. | |
| 48 | 44 | |
| 49 | −Because ohci1394 and firewire-ohci depend on the PCI enumeration to be | |
| 45 | +Because the firewire-ohci driver depends on the PCI enumeration to be | |
| 50 | 46 | completed, an initialization routine which runs pretty early has been |
| 51 | 47 | implemented for x86. This routine runs long before console_init() can be |
| 52 | 48 | called, i.e. before the printk buffer appears on the console. |
| @@ -64,7 +60,7 @@ be used to view the printk buffer of a remote machine, even with live update. · 11 unmodified lines | ||
| 64 | 60 | |
| 65 | 61 | Bernhard Kaindl enhanced firescope to support accessing 64-bit machines |
| 66 | 62 | from 32-bit firescope and vice versa: |
| 67 | −- http://halobates.de/firewire/firescope-0.2.2.tar.bz2 | |
| 63 | +- http://v3.sk/~lkundrak/firescope/ | |
| 68 | 64 | |
| 69 | 65 | and he implemented fast system dump (alpha version - read README.txt): |
| 70 | 66 | - http://halobates.de/firewire/firedump-0.1.tar.bz2 |
| @@ -92,11 +88,11 @@ Step-by-step instructions for using firescope with early OHCI initialization: · 21 unmodified lines | ||
| 92 | 88 | |
| 93 | 89 | 1) Verify that your hardware is supported: |
| 94 | 90 | |
| 95 | − Load the ohci1394 or the fw-ohci module and check your kernel logs. | |
| 91 | + Load the firewire-ohci module and check your kernel logs. | |
| 96 | 92 | You should see a line similar to |
| 97 | 93 | |
| 98 | − ohci1394: fw-host0: OHCI-1394 1.1 (PCI): IRQ=[18] MMIO=[fe9ff800-fe9fffff] | |
| 99 | − ... Max Packet=[2048] IR/IT contexts=[4/8] | |
| 94 | + firewire_ohci 0000:15:00.1: added OHCI v1.0 device as card 2, 4 IR + 4 IT | |
| 95 | + ... contexts, quirks 0x11 | |
| 100 | 96 | |
| 101 | 97 | when loading the driver. If you have no supported controller, many PCI, |
| 102 | 98 | CardBus and even some Express cards which are fully compliant to OHCI-1394 |
| @@ -105,6 +101,9 @@ Step-by-step instructions for using firescope with early OHCI initialization: · 2 unmodified lines | ||
| 105 | 101 | compliant, they are based on TI PCILynx chips and require drivers for Win- |
| 106 | 102 | dows operating systems. |
| 107 | 103 | |
| 104 | + The mentioned kernel log message contains ">4 GB phys DMA" in case of | |
| 105 | + OHCI-1394 controllers which support accesses above this limit. | |
| 106 | + | |
| 108 | 107 | 2) Establish a working FireWire cable connection: |
| 109 | 108 | |
| 110 | 109 | Any FireWire cable, as long at it provides electrically and mechanically |
| @@ -113,20 +112,18 @@ Step-by-step instructions for using firescope with early OHCI initialization: · 2 unmodified lines | ||
| 113 | 112 | |
| 114 | 113 | If an driver is running on both machines you should see a line like |
| 115 | 114 | |
| 116 | − ieee1394: Node added: ID:BUS[0-01:1023] GUID[0090270001b84bba] | |
| 115 | + firewire_core 0000:15:00.1: created device fw1: GUID 00061b0020105917, S400 | |
| 117 | 116 | |
| 118 | 117 | on both machines in the kernel log when the cable is plugged in |
| 119 | 118 | and connects the two machines. |
| 120 | 119 | |
| 121 | 120 | 3) Test physical DMA using firescope: |
| 122 | 121 | |
| 123 | − On the debug host, | |
| 124 | − - load the raw1394 module, | |
| 125 | − - make sure that /dev/raw1394 is accessible, | |
| 122 | + On the debug host, make sure that /dev/fw* is accessible, | |
| 126 | 123 | then start firescope: |
| 127 | 124 | |
| 128 | 125 | $ firescope |
| 129 | − Port 0 (ohci1394) opened, 2 nodes detected | |
| 126 | + Port 0 (/dev/fw1) opened, 2 nodes detected | |
| 130 | 127 | |
| 131 | 128 | FireScope |
| 132 | 129 | --------- |
| @@ -40,8 +40,11 @@ on hit count on entry. The policy aims to take different cache miss · 39 unmodified lines | ||
| 40 | 40 | costs into account and to adjust to varying load patterns automatically. |
| 41 | 41 | |
| 42 | 42 | Message and constructor argument pairs are: |
| 43 | − 'sequential_threshold <#nr_sequential_ios>' and | |
| 44 | − 'random_threshold <#nr_random_ios>'. | |
| 43 | + 'sequential_threshold <#nr_sequential_ios>' | |
| 44 | + 'random_threshold <#nr_random_ios>' | |
| 45 | + 'read_promote_adjustment <value>' | |
| 46 | + 'write_promote_adjustment <value>' | |
| 47 | + 'discard_promote_adjustment <value>' | |
| 45 | 48 | |
| 46 | 49 | The sequential threshold indicates the number of contiguous I/Os |
| 47 | 50 | required before a stream is treated as sequential. The random threshold |
| @@ -55,6 +58,15 @@ since spindles tend to have good bandwidth. The io_tracker counts · 7 unmodified lines | ||
| 55 | 58 | contiguous I/Os to try to spot when the io is in one of these sequential |
| 56 | 59 | modes. |
| 57 | 60 | |
| 61 | +Internally the mq policy maintains a promotion threshold variable. If | |
| 62 | +the hit count of a block not in the cache goes above this threshold it | |
| 63 | +gets promoted to the cache. The read, write and discard promote adjustment | |
| 64 | +tunables allow you to tweak the promotion threshold by adding a small | |
| 65 | +value based on the io type. They default to 4, 8 and 1 respectively. | |
| 66 | +If you're trying to quickly warm a new cache device you may wish to | |
| 67 | +reduce these to encourage promotion. Remember to switch them back to | |
| 68 | +their defaults after the cache fills though. | |
| 69 | + | |
| 58 | 70 | cleaner |
| 59 | 71 | ------- |
| 60 | 72 | |
| @@ -217,36 +217,43 @@ the characteristics of a specific policy, always request it by name. · 216 unmodified lines | ||
| 217 | 217 | Status |
| 218 | 218 | ------ |
| 219 | 219 | |
| 220 | −<#used metadata blocks>/<#total metadata blocks> <#read hits> <#read misses> | |
| 221 | −<#write hits> <#write misses> <#demotions> <#promotions> <#blocks in cache> | |
| 222 | −<#dirty> <#features> <features>* <#core args> <core args>* <#policy args> | |
| 223 | −<policy args>* | |
| 224 | − | |
| 225 | −#used metadata blocks : Number of metadata blocks used | |
| 226 | −#total metadata blocks : Total number of metadata blocks | |
| 227 | −#read hits : Number of times a READ bio has been mapped | |
| 220 | +<metadata block size> <#used metadata blocks>/<#total metadata blocks> | |
| 221 | +<cache block size> <#used cache blocks>/<#total cache blocks> | |
| 222 | +<#read hits> <#read misses> <#write hits> <#write misses> | |
| 223 | +<#demotions> <#promotions> <#dirty> <#features> <features>* | |
| 224 | +<#core args> <core args>* <policy name> <#policy args> <policy args>* | |
| 225 | + | |
| 226 | +metadata block size : Fixed block size for each metadata block in | |
| 227 | + sectors | |
| 228 | +#used metadata blocks : Number of metadata blocks used | |
| 229 | +#total metadata blocks : Total number of metadata blocks | |
| 230 | +cache block size : Configurable block size for the cache device | |
| 231 | + in sectors | |
| 232 | +#used cache blocks : Number of blocks resident in the cache | |
| 233 | +#total cache blocks : Total number of cache blocks | |
| 234 | +#read hits : Number of times a READ bio has been mapped | |
| 228 | 235 | to the cache |
| 229 | −#read misses : Number of times a READ bio has been mapped | |
| 236 | +#read misses : Number of times a READ bio has been mapped | |
| 230 | 237 | to the origin |
| 231 | −#write hits : Number of times a WRITE bio has been mapped | |
| 238 | +#write hits : Number of times a WRITE bio has been mapped | |
| 232 | 239 | to the cache |
| 233 | −#write misses : Number of times a WRITE bio has been | |
| 240 | +#write misses : Number of times a WRITE bio has been | |
| 234 | 241 | mapped to the origin |
| 235 | −#demotions : Number of times a block has been removed | |
| 242 | +#demotions : Number of times a block has been removed | |
| 236 | 243 | from the cache |
| 237 | −#promotions : Number of times a block has been moved to | |
| 244 | +#promotions : Number of times a block has been moved to | |
| 238 | 245 | the cache |
| 239 | −#blocks in cache : Number of blocks resident in the cache | |
| 240 | −#dirty : Number of blocks in the cache that differ | |
| 246 | +#dirty : Number of blocks in the cache that differ | |
| 241 | 247 | from the origin |
| 242 | −#feature args : Number of feature args to follow | |
| 243 | −feature args : 'writethrough' (optional) | |
| 244 | −#core args : Number of core arguments (must be even) | |
| 245 | −core args : Key/value pairs for tuning the core | |
| 248 | +#feature args : Number of feature args to follow | |
| 249 | +feature args : 'writethrough' (optional) | |
| 250 | +#core args : Number of core arguments (must be even) | |
| 251 | +core args : Key/value pairs for tuning the core | |
| 246 | 252 | e.g. migration_threshold |
| 247 | −#policy args : Number of policy arguments to follow (must be even) | |
| 248 | −policy args : Key/value pairs | |
| 249 | − e.g. 'sequential_threshold 1024 | |
| 253 | +policy name : Name of the policy | |
| 254 | +#policy args : Number of policy arguments to follow (must be even) | |
| 255 | +policy args : Key/value pairs | |
| 256 | + e.g. sequential_threshold | |
| 250 | 257 | |
| 251 | 258 | Messages |
| 252 | 259 | -------- |
| @@ -235,6 +235,8 @@ i) Constructor · 234 unmodified lines | ||
| 235 | 235 | read_only: Don't allow any changes to be made to the pool |
| 236 | 236 | metadata. |
| 237 | 237 | |
| 238 | + error_if_no_space: Error IOs, instead of queueing, if no space. | |
| 239 | + | |
| 238 | 240 | Data block size must be between 64KB (128 sectors) and 1GB |
| 239 | 241 | (2097152 sectors) inclusive. |
| 240 | 242 | |
| @@ -276,6 +278,11 @@ ii) Status · 35 unmodified lines | ||
| 276 | 278 | contain the string 'Fail'. The userspace recovery tools |
| 277 | 279 | should then be used. |
| 278 | 280 | |
| 281 | + error_if_no_space|queue_if_no_space | |
| 282 | + If the pool runs out of data or metadata space, the pool will | |
| 283 | + either queue or error the IO destined to the data device. The | |
| 284 | + default is to queue the IO until more space is added. | |
| 285 | + | |
| 279 | 286 | iii) Messages |
| 280 | 287 | |
| 281 | 288 | create_thin <dev id> |
| @@ -409,6 +409,7 @@ Your cooperation is appreciated. · 408 unmodified lines | ||
| 409 | 409 | 193 = /dev/d7s SPARC 7-segment display |
| 410 | 410 | 194 = /dev/zkshim Zero-Knowledge network shim control |
| 411 | 411 | 195 = /dev/elographics/e2201 Elographics touchscreen E271-2201 |
| 412 | + 196 = /dev/vfio/vfio VFIO userspace driver interface | |
| 412 | 413 | 198 = /dev/sexec Signed executable interface |
| 413 | 414 | 199 = /dev/scanners/cuecat :CueCat barcode scanner |
| 414 | 415 | 200 = /dev/net/tun TAP/TUN network device |
| @@ -0,0 +1,39 @@ | ||
| 1 | + | |
| 2 | + Devicetree (DT) ABI | |
| 3 | + | |
| 4 | +I. Regarding stable bindings/ABI, we quote from the 2013 ARM mini-summit | |
| 5 | + summary document: | |
| 6 | + | |
| 7 | + "That still leaves the question of, what does a stable binding look | |
| 8 | + like? Certainly a stable binding means that a newer kernel will not | |
| 9 | + break on an older device tree, but that doesn't mean the binding is | |
| 10 | + frozen for all time. Grant said there are ways to change bindings that | |
| 11 | + don't result in breakage. For instance, if a new property is added, | |
| 12 | + then default to the previous behaviour if it is missing. If a binding | |
| 13 | + truly needs an incompatible change, then change the compatible string | |
| 14 | + at the same time. The driver can bind against both the old and the | |
| 15 | + new. These guidelines aren't new, but they desperately need to be | |
| 16 | + documented." | |
| 17 | + | |
| 18 | +II. General binding rules | |
| 19 | + | |
| 20 | + 1) Maintainers, don't let perfect be the enemy of good. Don't hold up a | |
| 21 | + binding because it isn't perfect. | |
| 22 | + | |
| 23 | + 2) Use specific compatible strings so that if we need to add a feature (DMA) | |
| 24 | + in the future, we can create a new compatible string. See I. | |
| 25 | + | |
| 26 | + 3) Bindings can be augmented, but the driver shouldn't break when given | |
| 27 | + the old binding. ie. add additional properties, but don't change the | |
| 28 | + meaning of an existing property. For drivers, default to the original | |
| 29 | + behaviour when a newly added property is missing. | |
| 30 | + | |
| 31 | + 4) Don't submit bindings for staging or unstable. That will be decided by | |
| 32 | + the devicetree maintainers *after* discussion on the mailinglist. | |
| 33 | + | |
| 34 | +III. Notes | |
| 35 | + | |
| 36 | + 1) This document is intended as a general familiarization with the process as | |
| 37 | + decided at the 2013 Kernel Summit. When in doubt, the current word of the | |
| 38 | + devicetree maintainers overrules this document. In that situation, a patch | |
| 39 | + updating this document would be appreciated. | |
| @@ -14,6 +14,9 @@ Required nodes: · 13 unmodified lines | ||
| 14 | 14 | - core-module: the root node to the Integrator platforms must have |
| 15 | 15 | a core-module with regs and the compatible string |
| 16 | 16 | "arm,core-module-integrator" |
| 17 | +- external-bus-interface: the root node to the Integrator platforms | |
| 18 | + must have an external bus interface with regs and the | |
| 19 | + compatible-string "arm,external-bus-interface" | |
| 17 | 20 | |
| 18 | 21 | Required properties for the core module: |
| 19 | 22 | - regs: the location and size of the core module registers, one |
| @@ -48,6 +51,11 @@ Required nodes: · 28 unmodified lines | ||
| 48 | 51 | reg = <0x10000000 0x200>; |
| 49 | 52 | }; |
| 50 | 53 | |
| 54 | + ebi@12000000 { | |
| 55 | + compatible = "arm,external-bus-interface"; | |
| 56 | + reg = <0x12000000 0x100>; | |
| 57 | + }; | |
| 58 | + | |
| 51 | 59 | syscon { |
| 52 | 60 | compatible = "arm,integrator-ap-syscon"; |
| 53 | 61 | reg = <0x11000000 0x100>; |
| @@ -2,6 +2,7 @@ · 1 unmodified line | ||
| 2 | 2 | |
| 3 | 3 | Required properties: |
| 4 | 4 | - compatible: Should be "atmel,<chip>-aic" |
| 5 | + <chip> can be "at91rm9200" or "sama5d3" | |
| 5 | 6 | - interrupt-controller: Identifies the node as an interrupt controller. |
| 6 | 7 | - interrupt-parent: For single AIC system, it is an empty property. |
| 7 | 8 | - #interrupt-cells: The number of cells to define the interrupts. It should be 3. |
| @@ -20,6 +20,10 @@ TC/TCLIB Timer required properties: · 19 unmodified lines | ||
| 20 | 20 | - interrupts: Should contain all interrupts for the TC block |
| 21 | 21 | Note that you can specify several interrupt cells if the TC |
| 22 | 22 | block has one interrupt per channel. |
| 23 | +- clock-names: tuple listing input clock names. | |
| 24 | + Required elements: "t0_clk" | |
| 25 | + Optional elements: "t1_clk", "t2_clk" | |
| 26 | +- clocks: phandles to input clocks. | |
| 23 | 27 | |
| 24 | 28 | Examples: |
| 25 | 29 | |
| @@ -28,6 +32,8 @@ One interrupt per TC block: · 2 unmodified lines | ||
| 28 | 32 | compatible = "atmel,at91rm9200-tcb"; |
| 29 | 33 | reg = <0xfff7c000 0x100>; |
| 30 | 34 | interrupts = <18 4>; |
| 35 | + clocks = <&tcb0_clk>; | |
| 36 | + clock-names = "t0_clk"; | |
| 31 | 37 | }; |
| 32 | 38 | |
| 33 | 39 | One interrupt per TC channel in a TC block: |
| @@ -35,6 +41,8 @@ One interrupt per TC channel in a TC block: · 1 unmodified line | ||
| 35 | 41 | compatible = "atmel,at91rm9200-tcb"; |
| 36 | 42 | reg = <0xfffdc000 0x100>; |
| 37 | 43 | interrupts = <26 4 27 4 28 4>; |
| 44 | + clocks = <&tcb1_clk>; | |
| 45 | + clock-names = "t0_clk"; | |
| 38 | 46 | }; |
| 39 | 47 | |
| 40 | 48 | RSTC Reset Controller required properties: |
| @@ -50,7 +58,8 @@ Example: · 9 unmodified lines | ||
| 50 | 58 | }; |
| 51 | 59 | |
| 52 | 60 | RAMC SDRAM/DDR Controller required properties: |
| 53 | −- compatible: Should be "atmel,at91sam9260-sdramc", | |
| 61 | +- compatible: Should be "atmel,at91rm9200-sdramc", | |
| 62 | + "atmel,at91sam9260-sdramc", | |
| 54 | 63 | "atmel,at91sam9g45-ddramc", |
| 55 | 64 | - reg: Should contain registers location and length |
| 56 | 65 | For at91sam9263 and at91sam9g45 you must specify 2 entries. |
| @@ -8,13 +8,18 @@ Required properties: · 7 unmodified lines | ||
| 8 | 8 | - DEPRECATED: compatible : "bcm,kona-timer" |
| 9 | 9 | - reg : Register range for the timer |
| 10 | 10 | - interrupts : interrupt for the timer |
| 11 | +- clocks: phandle + clock specifier pair of the external clock | |
| 11 | 12 | - clock-frequency: frequency that the clock operates |
| 12 | 13 | |
| 14 | +Only one of clocks or clock-frequency should be specified. | |
| 15 | + | |
| 16 | +Refer to clocks/clock-bindings.txt for generic clock consumer properties. | |
| 17 | + | |
| 13 | 18 | Example: |
| 14 | 19 | timer@35006000 { |
| 15 | 20 | compatible = "brcm,kona-timer"; |
| 16 | 21 | reg = <0x35006000 0x1000>; |
| 17 | 22 | interrupts = <0x0 7 0x4>; |
| 18 | − clock-frequency = <32768>; | |
| 23 | + clocks = <&hub_timer_clk>; | |
| 19 | 24 | }; |
| 20 | 25 | |
| @@ -1,46 +0,0 @@ | ||
| 1 | −* Texas Instruments Davinci NAND | |
| 2 | − | |
| 3 | −This file provides information, what the device node for the | |
| 4 | −davinci nand interface contain. | |
| 5 | − | |
| 6 | −Required properties: | |
| 7 | −- compatible: "ti,davinci-nand"; | |
| 8 | −- reg : contain 2 offset/length values: | |
| 9 | − - offset and length for the access window | |
| 10 | − - offset and length for accessing the aemif control registers | |
| 11 | −- ti,davinci-chipselect: Indicates on the davinci_nand driver which | |
| 12 | − chipselect is used for accessing the nand. | |
| 13 | − | |
| 14 | −Recommended properties : | |
| 15 | −- ti,davinci-mask-ale: mask for ale | |
| 16 | −- ti,davinci-mask-cle: mask for cle | |
| 17 | −- ti,davinci-mask-chipsel: mask for chipselect | |
| 18 | −- ti,davinci-ecc-mode: ECC mode valid values for davinci driver: | |
| 19 | − - "none" | |
| 20 | − - "soft" | |
| 21 | − - "hw" | |
| 22 | −- ti,davinci-ecc-bits: used ECC bits, currently supported 1 or 4. | |
| 23 | −- ti,davinci-nand-buswidth: buswidth 8 or 16 | |
| 24 | −- ti,davinci-nand-use-bbt: use flash based bad block table support. | |
| 25 | − | |
| 26 | −nand device bindings may contain additional sub-nodes describing | |
| 27 | −partitions of the address space. See partition.txt for more detail. | |
| 28 | − | |
| 29 | −Example(da850 EVM ): | |
| 30 | −nand_cs3@62000000 { | |
| 31 | − compatible = "ti,davinci-nand"; | |
| 32 | − reg = <0x62000000 0x807ff | |
| 33 | − 0x68000000 0x8000>; | |
| 34 | − ti,davinci-chipselect = <1>; | |
| 35 | − ti,davinci-mask-ale = <0>; | |
| 36 | − ti,davinci-mask-cle = <0>; | |
| 37 | − ti,davinci-mask-chipsel = <0>; | |
| 38 | − ti,davinci-ecc-mode = "hw"; | |
| 39 | − ti,davinci-ecc-bits = <4>; | |
| 40 | − ti,davinci-nand-use-bbt; | |
| 41 | − | |
| 42 | − partition@180000 { | |
| 43 | − label = "ubifs"; | |
| 44 | − reg = <0x180000 0x7e80000>; | |
| 45 | − }; | |
| 46 | −}; | |
| @@ -0,0 +1,20 @@ | ||
| 1 | +Trusted Foundations | |
| 2 | +------------------- | |
| 3 | + | |
| 4 | +Boards that use the Trusted Foundations secure monitor can signal its | |
| 5 | +presence by declaring a node compatible with "tlm,trusted-foundations" | |
| 6 | +under the /firmware/ node | |
| 7 | + | |
| 8 | +Required properties: | |
| 9 | +- compatible: "tlm,trusted-foundations" | |
| 10 | +- tlm,version-major: major version number of Trusted Foundations firmware | |
| 11 | +- tlm,version-minor: minor version number of Trusted Foundations firmware | |
| 12 | + | |
| 13 | +Example: | |
| 14 | + firmware { | |
| 15 | + trusted-foundations { | |
| 16 | + compatible = "tlm,trusted-foundations"; | |
| 17 | + tlm,version-major = <2>; | |
| 18 | + tlm,version-minor = <8>; | |
| 19 | + }; | |
| 20 | + }; | |
| @@ -11,6 +11,7 @@ have PPIs or SGIs. · 10 unmodified lines | ||
| 11 | 11 | Main node required properties: |
| 12 | 12 | |
| 13 | 13 | - compatible : should be one of: |
| 14 | + "arm,gic-400" | |
| 14 | 15 | "arm,cortex-a15-gic" |
| 15 | 16 | "arm,cortex-a9-gic" |
| 16 | 17 | "arm,cortex-a7-gic" |
| @@ -0,0 +1,32 @@ | ||
| 1 | +Hisilicon Platforms Device Tree Bindings | |
| 2 | +---------------------------------------------------- | |
| 3 | + | |
| 4 | +Hi4511 Board | |
| 5 | +Required root node properties: | |
| 6 | + - compatible = "hisilicon,hi3620-hi4511"; | |
| 7 | + | |
| 8 | +Hisilicon system controller | |
| 9 | + | |
| 10 | +Required properties: | |
| 11 | +- compatible : "hisilicon,sysctrl" | |
| 12 | +- reg : Register address and size | |
| 13 | + | |
| 14 | +Optional properties: | |
| 15 | +- smp-offset : offset in sysctrl for notifying slave cpu booting | |
| 16 | + cpu 1, reg; | |
| 17 | + cpu 2, reg + 0x4; | |
| 18 | + cpu 3, reg + 0x8; | |
| 19 | + If reg value is not zero, cpun exit wfi and go | |
| 20 | +- resume-offset : offset in sysctrl for notifying cpu0 when resume | |
| 21 | +- reboot-offset : offset in sysctrl for system reboot | |
| 22 | + | |
| 23 | +Example: | |
| 24 | + | |
| 25 | + /* for Hi3620 */ | |
| 26 | + sysctrl: system-controller@fc802000 { | |
| 27 | + compatible = "hisilicon,sysctrl"; | |
| 28 | + reg = <0xfc802000 0x1000>; | |
| 29 | + smp-offset = <0x31c>; | |
| 30 | + resume-offset = <0x308>; | |
| 31 | + reboot-offset = <0x4>; | |
| 32 | + }; | |
| @@ -7,20 +7,21 @@ The ARM L2 cache representation in the device tree should be done as follows: · 6 unmodified lines | ||
| 7 | 7 | Required properties: |
| 8 | 8 | |
| 9 | 9 | - compatible : should be one of: |
| 10 | − "arm,pl310-cache" | |
| 11 | − "arm,l220-cache" | |
| 12 | − "arm,l210-cache" | |
| 13 | − "marvell,aurora-system-cache": Marvell Controller designed to be | |
| 10 | + "arm,pl310-cache" | |
| 11 | + "arm,l220-cache" | |
| 12 | + "arm,l210-cache" | |
| 13 | + "bcm,bcm11351-a2-pl310-cache": DEPRECATED by "brcm,bcm11351-a2-pl310-cache" | |
| 14 | + "brcm,bcm11351-a2-pl310-cache": For Broadcom bcm11351 chipset where an | |
| 15 | + offset needs to be added to the address before passing down to the L2 | |
| 16 | + cache controller | |
| 17 | + "marvell,aurora-system-cache": Marvell Controller designed to be | |
| 14 | 18 | compatible with the ARM one, with system cache mode (meaning |
| 15 | 19 | maintenance operations on L1 are broadcasted to the L2 and L2 |
| 16 | 20 | performs the same operation). |
| 17 | − "marvell,"aurora-outer-cache: Marvell Controller designed to be | |
| 18 | − compatible with the ARM one with outer cache mode. | |
| 19 | − "brcm,bcm11351-a2-pl310-cache": For Broadcom bcm11351 chipset where an | |
| 20 | − offset needs to be added to the address before passing down to the L2 | |
| 21 | − cache controller | |
| 22 | − "bcm,bcm11351-a2-pl310-cache": DEPRECATED by | |
| 23 | − "brcm,bcm11351-a2-pl310-cache" | |
| 21 | + "marvell,aurora-outer-cache": Marvell Controller designed to be | |
| 22 | + compatible with the ARM one with outer cache mode. | |
| 23 | + "marvell,tauros3-cache": Marvell Tauros3 cache controller, compatible | |
| 24 | + with arm,pl310-cache controller. | |
| 24 | 25 | - cache-unified : Specifies the cache is a unified cache. |
| 25 | 26 | - cache-level : Should be set to 2 for a level 2 cache. |
| 26 | 27 | - reg : Physical base address and size of cache controller's memory mapped |
| @@ -0,0 +1,24 @@ | ||
| 1 | +Marvell Berlin SoC Family Device Tree Bindings | |
| 2 | +--------------------------------------------------------------- | |
| 3 | + | |
| 4 | +Boards with a SoC of the Marvell Berlin family, e.g. Armada 1500 | |
| 5 | +shall have the following properties: | |
| 6 | + | |
| 7 | +* Required root node properties: | |
| 8 | +compatible: must contain "marvell,berlin" | |
| 9 | + | |
| 10 | +In addition, the above compatible shall be extended with the specific | |
| 11 | +SoC and board used. Currently known SoC compatibles are: | |
| 12 | + "marvell,berlin2" for Marvell Armada 1500 (BG2, 88DE3100), | |
| 13 | + "marvell,berlin2cd" for Marvell Armada 1500-mini (BG2CD, 88DE3005) | |
| 14 | + "marvell,berlin2ct" for Marvell Armada ? (BG2CT, 88DE????) | |
| 15 | + "marvell,berlin3" for Marvell Armada ? (BG3, 88DE????) | |
| 16 | + | |
| 17 | +* Example: | |
| 18 | + | |
| 19 | +/ { | |
| 20 | + model = "Sony NSZ-GS7"; | |
| 21 | + compatible = "sony,nsz-gs7", "marvell,berlin2", "marvell,berlin"; | |
| 22 | + | |
| 23 | + ... | |
| 24 | +} | |
| @@ -0,0 +1,12 @@ | ||
| 1 | +MOXA ART device tree bindings | |
| 2 | + | |
| 3 | +Boards with the MOXA ART SoC shall have the following properties: | |
| 4 | + | |
| 5 | +Required root node property: | |
| 6 | + | |
| 7 | +compatible = "moxa,moxart"; | |
| 8 | + | |
| 9 | +Boards: | |
| 10 | + | |
| 11 | +- UC-7112-LX: embedded computer | |
| 12 | + compatible = "moxa,moxart-uc-7112-lx", "moxa,moxart" | |
| @@ -31,6 +31,59 @@ spinlock@1 { · 30 unmodified lines | ||
| 31 | 31 | ti,hwmods = "spinlock"; |
| 32 | 32 | }; |
| 33 | 33 | |
| 34 | +SoC Type (optional): | |
| 35 | + | |
| 36 | +- General Purpose devices | |
| 37 | + compatible = "ti,gp" | |
| 38 | +- High Security devices | |
| 39 | + compatible = "ti,hs" | |
| 40 | + | |
| 41 | +SoC Families: | |
| 42 | + | |
| 43 | +- OMAP2 generic - defaults to OMAP2420 | |
| 44 | + compatible = "ti,omap2" | |
| 45 | +- OMAP3 generic - defaults to OMAP3430 | |
| 46 | + compatible = "ti,omap3" | |
| 47 | +- OMAP4 generic - defaults to OMAP4430 | |
| 48 | + compatible = "ti,omap4" | |
| 49 | +- OMAP5 generic - defaults to OMAP5430 | |
| 50 | + compatible = "ti,omap5" | |
| 51 | +- DRA7 generic - defaults to DRA742 | |
| 52 | + compatible = "ti,dra7" | |
| 53 | +- AM43x generic - defaults to AM4372 | |
| 54 | + compatible = "ti,am43" | |
| 55 | + | |
| 56 | +SoCs: | |
| 57 | + | |
| 58 | +- OMAP2420 | |
| 59 | + compatible = "ti,omap2420", "ti,omap2" | |
| 60 | +- OMAP2430 | |
| 61 | + compatible = "ti,omap2430", "ti,omap2" | |
| 62 | + | |
| 63 | +- OMAP3430 | |
| 64 | + compatible = "ti,omap3430", "ti,omap3" | |
| 65 | +- AM3517 | |
| 66 | + compatible = "ti,am3517", "ti,omap3" | |
| 67 | +- OMAP3630 | |
| 68 | + compatible = "ti,omap36xx", "ti,omap3" | |
| 69 | +- AM33xx | |
| 70 | + compatible = "ti,am33xx", "ti,omap3" | |
| 71 | + | |
| 72 | +- OMAP4430 | |
| 73 | + compatible = "ti,omap4430", "ti,omap4" | |
| 74 | +- OMAP4460 | |
| 75 | + compatible = "ti,omap4460", "ti,omap4" | |
| 76 | + | |
| 77 | +- OMAP5430 | |
| 78 | + compatible = "ti,omap5430", "ti,omap5" | |
| 79 | +- OMAP5432 | |
| 80 | + compatible = "ti,omap5432", "ti,omap5" | |
| 81 | + | |
| 82 | +- DRA742 | |
| 83 | + compatible = "ti,dra7xx", "ti,dra7" | |
| 84 | + | |
| 85 | +- AM4372 | |
| 86 | + compatible = "ti,am4372", "ti,am43" | |
| 34 | 87 | |
| 35 | 88 | Boards: |
| 36 | 89 | |
| @@ -1,7 +1,12 @@ | ||
| 1 | 1 | SAMSUNG S5P/Exynos SoC series System Registers (SYSREG) |
| 2 | 2 | |
| 3 | 3 | Properties: |
| 4 | − - name : should be 'sysreg'; | |
| 5 | 4 | - compatible : should contain "samsung,<chip name>-sysreg", "syscon"; |
| 6 | 5 | For Exynos4 SoC series it should be "samsung,exynos4-sysreg", "syscon"; |
| 7 | 6 | - reg : offset and length of the register set. |
| 7 | + | |
| 8 | +Example: | |
| 9 | + syscon@10010000 { | |
| 10 | + compatible = "samsung,exynos4-sysreg", "syscon"; | |
| 11 | + reg = <0x10010000 0x400>; | |
| 12 | + }; | |
| @@ -32,3 +32,8 @@ board-specific compatible values: · 31 unmodified lines | ||
| 32 | 32 | nvidia,whistler |
| 33 | 33 | toradex,colibri_t20-512 |
| 34 | 34 | toradex,iris |
| 35 | + | |
| 36 | +Trusted Foundations | |
| 37 | +------------------------------------------- | |
| 38 | +Tegra supports the Trusted Foundation secure monitor. See the | |
| 39 | +"tlm,trusted-foundations" binding's documentation for more details. | |
| @@ -9,6 +9,7 @@ Required properties: · 8 unmodified lines | ||
| 9 | 9 | - compatible : Should contain "nvidia,tegra<chip>-pmc". |
| 10 | 10 | - reg : Offset and length of the register set for the device |
| 11 | 11 | - clocks : Must contain an entry for each entry in clock-names. |
| 12 | + See ../clocks/clock-bindings.txt for details. | |
| 12 | 13 | - clock-names : Must include the following entries: |
| 13 | 14 | "pclk" (The Tegra clock of that name), |
| 14 | 15 | "clk32k_in" (The 32KHz clock input to Tegra). |
| @@ -29,3 +29,8 @@ pic: pic@14000000 { · 28 unmodified lines | ||
| 29 | 29 | clear-mask = <0xffffffff>; |
| 30 | 30 | valid-mask = <0x003fffff>; |
| 31 | 31 | }; |
| 32 | + | |
| 33 | +Optional properties: | |
| 34 | +- interrupts: if the FPGA IRQ controller is cascaded, i.e. if its IRQ | |
| 35 | + output is simply connected to the input of another IRQ controller, | |
| 36 | + then the parent IRQ shall be specified in this property. | |
| @@ -1,7 +1,7 @@ | ||
| 1 | 1 | * Marvell Orion SATA |
| 2 | 2 | |
| 3 | 3 | Required Properties: |
| 4 | −- compatibility : "marvell,orion-sata" | |
| 4 | +- compatibility : "marvell,orion-sata" or "marvell,armada-370-sata" | |
| 5 | 5 | - reg : Address range of controller |
| 6 | 6 | - interrupts : Interrupt controller is using |
| 7 | 7 | - nr-ports : Number of SATA ports in use. |
| @@ -0,0 +1,18 @@ | ||
| 1 | +* Renesas R-Car SATA | |
| 2 | + | |
| 3 | +Required properties: | |
| 4 | +- compatible : should contain one of the following: | |
| 5 | + - "renesas,sata-r8a7779" for R-Car H1 | |
| 6 | + - "renesas,sata-r8a7790" for R-Car H2 | |
| 7 | + - "renesas,sata-r8a7791" for R-Car M2 | |
| 8 | +- reg : address and length of the SATA registers; | |
| 9 | +- interrupts : must consist of one interrupt specifier. | |
| 10 | + | |
| 11 | +Example: | |
| 12 | + | |
| 13 | +sata: sata@fc600000 { | |
| 14 | + compatible = "renesas,sata-r8a7779"; | |
| 15 | + reg = <0xfc600000 0x2000>; | |
| 16 | + interrupt-parent = <&gic>; | |
| 17 | + interrupts = <0 100 IRQ_TYPE_LEVEL_HIGH>; | |
| 18 | +}; | |
| @@ -0,0 +1,339 @@ | ||
| 1 | +Device Tree Clock bindings for arch-at91 | |
| 2 | + | |
| 3 | +This binding uses the common clock binding[1]. | |
| 4 | + | |
| 5 | +[1] Documentation/devicetree/bindings/clock/clock-bindings.txt | |
| 6 | + | |
| 7 | +Required properties: | |
| 8 | +- compatible : shall be one of the following: | |
| 9 | + "atmel,at91rm9200-pmc" or | |
| 10 | + "atmel,at91sam9g45-pmc" or | |
| 11 | + "atmel,at91sam9n12-pmc" or | |
| 12 | + "atmel,at91sam9x5-pmc" or | |
| 13 | + "atmel,sama5d3-pmc": | |
| 14 | + at91 PMC (Power Management Controller) | |
| 15 | + All at91 specific clocks (clocks defined below) must be child | |
| 16 | + node of the PMC node. | |
| 17 | + | |
| 18 | + "atmel,at91rm9200-clk-main": | |
| 19 | + at91 main oscillator | |
| 20 | + | |
| 21 | + "atmel,at91rm9200-clk-master" or | |
| 22 | + "atmel,at91sam9x5-clk-master": | |
| 23 | + at91 master clock | |
| 24 | + | |
| 25 | + "atmel,at91sam9x5-clk-peripheral" or | |
| 26 | + "atmel,at91rm9200-clk-peripheral": | |
| 27 | + at91 peripheral clocks | |
| 28 | + | |
| 29 | + "atmel,at91rm9200-clk-pll" or | |
| 30 | + "atmel,at91sam9g45-clk-pll" or | |
| 31 | + "atmel,at91sam9g20-clk-pllb" or | |
| 32 | + "atmel,sama5d3-clk-pll": | |
| 33 | + at91 pll clocks | |
| 34 | + | |
| 35 | + "atmel,at91sam9x5-clk-plldiv": | |
| 36 | + at91 plla divisor | |
| 37 | + | |
| 38 | + "atmel,at91rm9200-clk-programmable" or | |
| 39 | + "atmel,at91sam9g45-clk-programmable" or | |
| 40 | + "atmel,at91sam9x5-clk-programmable": | |
| 41 | + at91 programmable clocks | |
| 42 | + | |
| 43 | + "atmel,at91sam9x5-clk-smd": | |
| 44 | + at91 SMD (Soft Modem) clock | |
| 45 | + | |
| 46 | + "atmel,at91rm9200-clk-system": | |
| 47 | + at91 system clocks | |
| 48 | + | |
| 49 | + "atmel,at91rm9200-clk-usb" or | |
| 50 | + "atmel,at91sam9x5-clk-usb" or | |
| 51 | + "atmel,at91sam9n12-clk-usb": | |
| 52 | + at91 usb clock | |
| 53 | + | |
| 54 | + "atmel,at91sam9x5-clk-utmi": | |
| 55 | + at91 utmi clock | |
| 56 | + | |
| 57 | +Required properties for PMC node: | |
| 58 | +- reg : defines the IO memory reserved for the PMC. | |
| 59 | +- #size-cells : shall be 0 (reg is used to encode clk id). | |
| 60 | +- #address-cells : shall be 1 (reg is used to encode clk id). | |
| 61 | +- interrupts : shall be set to PMC interrupt line. | |
| 62 | +- interrupt-controller : tell that the PMC is an interrupt controller. | |
| 63 | +- #interrupt-cells : must be set to 1. The first cell encodes the interrupt id, | |
| 64 | + and reflect the bit position in the PMC_ER/DR/SR registers. | |
| 65 | + You can use the dt macros defined in dt-bindings/clk/at91.h. | |
| 66 | + 0 (AT91_PMC_MOSCS) -> main oscillator ready | |
| 67 | + 1 (AT91_PMC_LOCKA) -> PLL A ready | |
| 68 | + 2 (AT91_PMC_LOCKB) -> PLL B ready | |
| 69 | + 3 (AT91_PMC_MCKRDY) -> master clock ready | |
| 70 | + 6 (AT91_PMC_LOCKU) -> UTMI PLL clock ready | |
| 71 | + 8 .. 15 (AT91_PMC_PCKRDY(id)) -> programmable clock ready | |
| 72 | + 16 (AT91_PMC_MOSCSELS) -> main oscillator selected | |
| 73 | + 17 (AT91_PMC_MOSCRCS) -> RC main oscillator stabilized | |
| 74 | + 18 (AT91_PMC_CFDEV) -> clock failure detected | |
| 75 | + | |
| 76 | +For example: | |
| 77 | + pmc: pmc@fffffc00 { | |
| 78 | + compatible = "atmel,sama5d3-pmc"; | |
| 79 | + interrupts = <1 4 7>; | |
| 80 | + interrupt-controller; | |
| 81 | + #interrupt-cells = <2>; | |
| 82 | + #size-cells = <0>; | |
| 83 | + #address-cells = <1>; | |
| 84 | + | |
| 85 | + /* put at91 clocks here */ | |
| 86 | + }; | |
| 87 | + | |
| 88 | +Required properties for main clock: | |
| 89 | +- interrupt-parent : must reference the PMC node. | |
| 90 | +- interrupts : shall be set to "<0>". | |
| 91 | +- #clock-cells : from common clock binding; shall be set to 0. | |
| 92 | +- clocks (optional if clock-frequency is provided) : shall be the slow clock | |
| 93 | + phandle. This clock is used to calculate the main clock rate if | |
| 94 | + "clock-frequency" is not provided. | |
| 95 | +- clock-frequency : the main oscillator frequency.Prefer the use of | |
| 96 | + "clock-frequency" over automatic clock rate calculation. | |
| 97 | + | |
| 98 | +For example: | |
| 99 | + main: mainck { | |
| 100 | + compatible = "atmel,at91rm9200-clk-main"; | |
| 101 | + interrupt-parent = <&pmc>; | |
| 102 | + interrupts = <0>; | |
| 103 | + #clock-cells = <0>; | |
| 104 | + clocks = <&ck32k>; | |
| 105 | + clock-frequency = <18432000>; | |
| 106 | + }; | |
| 107 | + | |
| 108 | +Required properties for master clock: | |
| 109 | +- interrupt-parent : must reference the PMC node. | |
| 110 | +- interrupts : shall be set to "<3>". | |
| 111 | +- #clock-cells : from common clock binding; shall be set to 0. | |
| 112 | +- clocks : shall be the master clock sources (see atmel datasheet) phandles. | |
| 113 | + e.g. "<&ck32k>, <&main>, <&plla>, <&pllb>". | |
| 114 | +- atmel,clk-output-range : minimum and maximum clock frequency (two u32 | |
| 115 | + fields). | |
| 116 | + e.g. output = <0 133000000>; <=> 0 to 133MHz. | |
| 117 | +- atmel,clk-divisors : master clock divisors table (four u32 fields). | |
| 118 | + 0 <=> reserved value. | |
| 119 | + e.g. divisors = <1 2 4 6>; | |
| 120 | +- atmel,master-clk-have-div3-pres : some SoC use the reserved value 7 in the | |
| 121 | + PRES field as CLOCK_DIV3 (e.g sam9x5). | |
| 122 | + | |
| 123 | +For example: | |
| 124 | + mck: mck { | |
| 125 | + compatible = "atmel,at91rm9200-clk-master"; | |
| 126 | + interrupt-parent = <&pmc>; | |
| 127 | + interrupts = <3>; | |
| 128 | + #clock-cells = <0>; | |
| 129 | + atmel,clk-output-range = <0 133000000>; | |
| 130 | + atmel,clk-divisors = <1 2 4 0>; | |
| 131 | + }; | |
| 132 | + | |
| 133 | +Required properties for peripheral clocks: | |
| 134 | +- #size-cells : shall be 0 (reg is used to encode clk id). | |
| 135 | +- #address-cells : shall be 1 (reg is used to encode clk id). | |
| 136 | +- clocks : shall be the master clock phandle. | |
| 137 | + e.g. clocks = <&mck>; | |
| 138 | +- name: device tree node describing a specific system clock. | |
| 139 | + * #clock-cells : from common clock binding; shall be set to 0. | |
| 140 | + * reg: peripheral id. See Atmel's datasheets to get a full | |
| 141 | + list of peripheral ids. | |
| 142 | + * atmel,clk-output-range : minimum and maximum clock frequency | |
| 143 | + (two u32 fields). Only valid on at91sam9x5-clk-peripheral | |
| 144 | + compatible IPs. | |
| 145 | + | |
| 146 | +For example: | |
| 147 | + periph: periphck { | |
| 148 | + compatible = "atmel,at91sam9x5-clk-peripheral"; | |
| 149 | + #size-cells = <0>; | |
| 150 | + #address-cells = <1>; | |
| 151 | + clocks = <&mck>; | |
| 152 | + | |
| 153 | + ssc0_clk { | |
| 154 | + #clock-cells = <0>; | |
| 155 | + reg = <2>; | |
| 156 | + atmel,clk-output-range = <0 133000000>; | |
| 157 | + }; | |
| 158 | + | |
| 159 | + usart0_clk { | |
| 160 | + #clock-cells = <0>; | |
| 161 | + reg = <3>; | |
| 162 | + atmel,clk-output-range = <0 66000000>; | |
| 163 | + }; | |
| 164 | + }; | |
| 165 | + | |
| 166 | + | |
| 167 | +Required properties for pll clocks: | |
| 168 | +- interrupt-parent : must reference the PMC node. | |
| 169 | +- interrupts : shall be set to "<1>". | |
| 170 | +- #clock-cells : from common clock binding; shall be set to 0. | |
| 171 | +- clocks : shall be the main clock phandle. | |
| 172 | +- reg : pll id. | |
| 173 | + 0 -> PLL A | |
| 174 | + 1 -> PLL B | |
| 175 | +- atmel,clk-input-range : minimum and maximum source clock frequency (two u32 | |
| 176 | + fields). | |
| 177 | + e.g. input = <1 32000000>; <=> 1 to 32MHz. | |
| 178 | +- #atmel,pll-clk-output-range-cells : number of cells reserved for pll output | |
| 179 | + range description. Sould be set to 2, 3 | |
| 180 | + or 4. | |
| 181 | + * 1st and 2nd cells represent the frequency range (min-max). | |
| 182 | + * 3rd cell is optional and represents the OUT field value for the given | |
| 183 | + range. | |
| 184 | + * 4th cell is optional and represents the ICPLL field (PLLICPR | |
| 185 | + register) | |
| 186 | +- atmel,pll-clk-output-ranges : pll output frequency ranges + optional parameter | |
| 187 | + depending on #atmel,pll-output-range-cells | |
| 188 | + property value. | |
| 189 | + | |
| 190 | +For example: | |
| 191 | + plla: pllack { | |
| 192 | + compatible = "atmel,at91sam9g45-clk-pll"; | |
| 193 | + interrupt-parent = <&pmc>; | |
| 194 | + interrupts = <1>; | |
| 195 | + #clock-cells = <0>; | |
| 196 | + clocks = <&main>; | |
| 197 | + reg = <0>; | |
| 198 | + atmel,clk-input-range = <2000000 32000000>; | |
| 199 | + #atmel,pll-clk-output-range-cells = <4>; | |
| 200 | + atmel,pll-clk-output-ranges = <74500000 800000000 0 0 | |
| 201 | + 69500000 750000000 1 0 | |
| 202 | + 64500000 700000000 2 0 | |
| 203 | + 59500000 650000000 3 0 | |
| 204 | + 54500000 600000000 0 1 | |
| 205 | + 49500000 550000000 1 1 | |
| 206 | + 44500000 500000000 2 1 | |
| 207 | + 40000000 450000000 3 1>; | |
| 208 | + }; | |
| 209 | + | |
| 210 | +Required properties for plldiv clocks (plldiv = pll / 2): | |
| 211 | +- #clock-cells : from common clock binding; shall be set to 0. | |
| 212 | +- clocks : shall be the plla clock phandle. | |
| 213 | + | |
| 214 | +The pll divisor is equal to 2 and cannot be changed. | |
| 215 | + | |
| 216 | +For example: | |
| 217 | + plladiv: plladivck { | |
| 218 | + compatible = "atmel,at91sam9x5-clk-plldiv"; | |
| 219 | + #clock-cells = <0>; | |
| 220 | + clocks = <&plla>; | |
| 221 | + }; | |
| 222 | + | |
| 223 | +Required properties for programmable clocks: | |
| 224 | +- interrupt-parent : must reference the PMC node. | |
| 225 | +- #size-cells : shall be 0 (reg is used to encode clk id). | |
| 226 | +- #address-cells : shall be 1 (reg is used to encode clk id). | |
| 227 | +- clocks : shall be the programmable clock source phandles. | |
| 228 | + e.g. clocks = <&clk32k>, <&main>, <&plla>, <&pllb>; | |
| 229 | +- name: device tree node describing a specific prog clock. | |
| 230 | + * #clock-cells : from common clock binding; shall be set to 0. | |
| 231 | + * reg : programmable clock id (register offset from PCKx | |
| 232 | + register). | |
| 233 | + * interrupts : shall be set to "<(8 + id)>". | |
| 234 | + | |
| 235 | +For example: | |
| 236 | + prog: progck { | |
| 237 | + compatible = "atmel,at91sam9g45-clk-programmable"; | |
| 238 | + #size-cells = <0>; | |
| 239 | + #address-cells = <1>; | |
| 240 | + interrupt-parent = <&pmc>; | |
| 241 | + clocks = <&clk32k>, <&main>, <&plladiv>, <&utmi>, <&mck>; | |
| 242 | + | |
| 243 | + prog0 { | |
| 244 | + #clock-cells = <0>; | |
| 245 | + reg = <0>; | |
| 246 | + interrupts = <8>; | |
| 247 | + }; | |
| 248 | + | |
| 249 | + prog1 { | |
| 250 | + #clock-cells = <0>; | |
| 251 | + reg = <1>; | |
| 252 | + interrupts = <9>; | |
| 253 | + }; | |
| 254 | + }; | |
| 255 | + | |
| 256 | + | |
| 257 | +Required properties for smd clock: | |
| 258 | +- #clock-cells : from common clock binding; shall be set to 0. | |
| 259 | +- clocks : shall be the smd clock source phandles. | |
| 260 | + e.g. clocks = <&plladiv>, <&utmi>; | |
| 261 | + | |
| 262 | +For example: | |
| 263 | + smd: smdck { | |
| 264 | + compatible = "atmel,at91sam9x5-clk-smd"; | |
| 265 | + #clock-cells = <0>; | |
| 266 | + clocks = <&plladiv>, <&utmi>; | |
| 267 | + }; | |
| 268 | + | |
| 269 | +Required properties for system clocks: | |
| 270 | +- #size-cells : shall be 0 (reg is used to encode clk id). | |
| 271 | +- #address-cells : shall be 1 (reg is used to encode clk id). | |
| 272 | +- name: device tree node describing a specific system clock. | |
| 273 | + * #clock-cells : from common clock binding; shall be set to 0. | |
| 274 | + * reg: system clock id (bit position in SCER/SCDR/SCSR registers). | |
| 275 | + See Atmel's datasheet to get a full list of system clock ids. | |
| 276 | + | |
| 277 | +For example: | |
| 278 | + system: systemck { | |
| 279 | + compatible = "atmel,at91rm9200-clk-system"; | |
| 280 | + #address-cells = <1>; | |
| 281 | + #size-cells = <0>; | |
| 282 | + | |
| 283 | + ddrck { | |
| 284 | + #clock-cells = <0>; | |
| 285 | + reg = <2>; | |
| 286 | + clocks = <&mck>; | |
| 287 | + }; | |
| 288 | + | |
| 289 | + uhpck { | |
| 290 | + #clock-cells = <0>; | |
| 291 | + reg = <6>; | |
| 292 | + clocks = <&usb>; | |
| 293 | + }; | |
| 294 | + | |
| 295 | + udpck { | |
| 296 | + #clock-cells = <0>; | |
| 297 | + reg = <7>; | |
| 298 | + clocks = <&usb>; | |
| 299 | + }; | |
| 300 | + }; | |
| 301 | + | |
| 302 | + | |
| 303 | +Required properties for usb clock: | |
| 304 | +- #clock-cells : from common clock binding; shall be set to 0. | |
| 305 | +- clocks : shall be the smd clock source phandles. | |
| 306 | + e.g. clocks = <&pllb>; | |
| 307 | +- atmel,clk-divisors (only available for "atmel,at91rm9200-clk-usb"): | |
| 308 | + usb clock divisor table. | |
| 309 | + e.g. divisors = <1 2 4 0>; | |
| 310 | + | |
| 311 | +For example: | |
| 312 | + usb: usbck { | |
| 313 | + compatible = "atmel,at91sam9x5-clk-usb"; | |
| 314 | + #clock-cells = <0>; | |
| 315 | + clocks = <&plladiv>, <&utmi>; | |
| 316 | + }; | |
| 317 | + | |
| 318 | + usb: usbck { | |
| 319 | + compatible = "atmel,at91rm9200-clk-usb"; | |
| 320 | + #clock-cells = <0>; | |
| 321 | + clocks = <&pllb>; | |
| 322 | + atmel,clk-divisors = <1 2 4 0>; | |
| 323 | + }; | |
| 324 | + | |
| 325 | + | |
| 326 | +Required properties for utmi clock: | |
| 327 | +- interrupt-parent : must reference the PMC node. | |
| 328 | +- interrupts : shall be set to "<AT91_PMC_LOCKU IRQ_TYPE_LEVEL_HIGH>". | |
| 329 | +- #clock-cells : from common clock binding; shall be set to 0. | |
| 330 | +- clocks : shall be the main clock source phandle. | |
| 331 | + | |
| 332 | +For example: | |
| 333 | + utmi: utmick { | |
| 334 | + compatible = "atmel,at91sam9x5-clk-utmi"; | |
| 335 | + interrupt-parent = <&pmc>; | |
| 336 | + interrupts = <AT91_PMC_LOCKU IRQ_TYPE_LEVEL_HIGH>; | |
| 337 | + #clock-cells = <0>; | |
| 338 | + clocks = <&main>; | |
| 339 | + }; | |
| @@ -0,0 +1,93 @@ | ||
| 1 | +Broadcom Kona Family Clocks | |
| 2 | + | |
| 3 | +This binding is associated with Broadcom SoCs having "Kona" style | |
| 4 | +clock control units (CCUs). A CCU is a clock provider that manages | |
| 5 | +a set of clock signals. Each CCU is represented by a node in the | |
| 6 | +device tree. | |
| 7 | + | |
| 8 | +This binding uses the common clock binding: | |
| 9 | + Documentation/devicetree/bindings/clock/clock-bindings.txt | |
| 10 | + | |
| 11 | +Required properties: | |
| 12 | +- compatible | |
| 13 | + Shall have one of the following values: | |
| 14 | + - "brcm,bcm11351-root-ccu" | |
| 15 | + - "brcm,bcm11351-aon-ccu" | |
| 16 | + - "brcm,bcm11351-hub-ccu" | |
| 17 | + - "brcm,bcm11351-master-ccu" | |
| 18 | + - "brcm,bcm11351-slave-ccu" | |
| 19 | +- reg | |
| 20 | + Shall define the base and range of the address space | |
| 21 | + containing clock control registers | |
| 22 | +- #clock-cells | |
| 23 | + Shall have value <1>. The permitted clock-specifier values | |
| 24 | + are defined below. | |
| 25 | +- clock-output-names | |
| 26 | + Shall be an ordered list of strings defining the names of | |
| 27 | + the clocks provided by the CCU. | |
| 28 | + | |
| 29 | + | |
| 30 | +BCM281XX family SoCs use Kona CCUs. The following table defines | |
| 31 | +the set of CCUs and clock specifiers for BCM281XX clocks. When | |
| 32 | +a clock consumer references a clocks, its symbolic specifier | |
| 33 | +(rather than its numeric index value) should be used. These | |
| 34 | +specifiers are defined in "include/dt-bindings/clock/bcm281xx.h". | |
| 35 | + | |
| 36 | + CCU Clock Type Index Specifier | |
| 37 | + --- ----- ---- ----- --------- | |
| 38 | + root frac_1m peri 0 BCM281XX_ROOT_CCU_FRAC_1M | |
| 39 | + | |
| 40 | + aon hub_timer peri 0 BCM281XX_AON_CCU_HUB_TIMER | |
| 41 | + aon pmu_bsc peri 1 BCM281XX_AON_CCU_PMU_BSC | |
| 42 | + aon pmu_bsc_var peri 2 BCM281XX_AON_CCU_PMU_BSC_VAR | |
| 43 | + | |
| 44 | + hub tmon_1m peri 0 BCM281XX_HUB_CCU_TMON_1M | |
| 45 | + | |
| 46 | + master sdio1 peri 0 BCM281XX_MASTER_CCU_SDIO1 | |
| 47 | + master sdio2 peri 1 BCM281XX_MASTER_CCU_SDIO2 | |
| 48 | + master sdio3 peri 2 BCM281XX_MASTER_CCU_SDIO3 | |
| 49 | + master sdio4 peri 3 BCM281XX_MASTER_CCU_SDIO4 | |
| 50 | + master dmac peri 4 BCM281XX_MASTER_CCU_DMAC | |
| 51 | + master usb_ic peri 5 BCM281XX_MASTER_CCU_USB_IC | |
| 52 | + master hsic2_48m peri 6 BCM281XX_MASTER_CCU_HSIC_48M | |
| 53 | + master hsic2_12m peri 7 BCM281XX_MASTER_CCU_HSIC_12M | |
| 54 | + | |
| 55 | + slave uartb peri 0 BCM281XX_SLAVE_CCU_UARTB | |
| 56 | + slave uartb2 peri 1 BCM281XX_SLAVE_CCU_UARTB2 | |
| 57 | + slave uartb3 peri 2 BCM281XX_SLAVE_CCU_UARTB3 | |
| 58 | + slave uartb4 peri 3 BCM281XX_SLAVE_CCU_UARTB4 | |
| 59 | + slave ssp0 peri 4 BCM281XX_SLAVE_CCU_SSP0 | |
| 60 | + slave ssp2 peri 5 BCM281XX_SLAVE_CCU_SSP2 | |
| 61 | + slave bsc1 peri 6 BCM281XX_SLAVE_CCU_BSC1 | |
| 62 | + slave bsc2 peri 7 BCM281XX_SLAVE_CCU_BSC2 | |
| 63 | + slave bsc3 peri 8 BCM281XX_SLAVE_CCU_BSC3 | |
| 64 | + slave pwm peri 9 BCM281XX_SLAVE_CCU_PWM | |
| 65 | + | |
| 66 | + | |
| 67 | +Device tree example: | |
| 68 | + | |
| 69 | + slave_ccu: slave_ccu { | |
| 70 | + compatible = "brcm,bcm11351-slave-ccu"; | |
| 71 | + reg = <0x3e011000 0x0f00>; | |
| 72 | + #clock-cells = <1>; | |
| 73 | + clock-output-names = "uartb", | |
| 74 | + "uartb2", | |
| 75 | + "uartb3", | |
| 76 | + "uartb4"; | |
| 77 | + }; | |
| 78 | + | |
| 79 | + ref_crystal_clk: ref_crystal { | |
| 80 | + #clock-cells = <0>; | |
| 81 | + compatible = "fixed-clock"; | |
| 82 | + clock-frequency = <26000000>; | |
| 83 | + }; | |
| 84 | + | |
| 85 | + uart@3e002000 { | |
| 86 | + compatible = "brcm,bcm11351-dw-apb-uart", "snps,dw-apb-uart"; | |
| 87 | + status = "disabled"; | |
| 88 | + reg = <0x3e002000 0x1000>; | |
| 89 | + clocks = <&slave_ccu BCM281XX_SLAVE_CCU_UARTB3>; | |
| 90 | + interrupts = <GIC_SPI 65 IRQ_TYPE_LEVEL_HIGH>; | |
| 91 | + reg-shift = <2>; | |
| 92 | + reg-io-width = <4>; | |
| 93 | + }; | |
| @@ -8,12 +8,29 @@ Required Properties: · 7 unmodified lines | ||
| 8 | 8 | |
| 9 | 9 | - compatible: should be one of the following: |
| 10 | 10 | - "samsung,exynos4210-audss-clock" - controller compatible with all Exynos4 SoCs. |
| 11 | − - "samsung,exynos5250-audss-clock" - controller compatible with all Exynos5 SoCs. | |
| 12 | − | |
| 11 | + - "samsung,exynos5250-audss-clock" - controller compatible with Exynos5250 | |
| 12 | + SoCs. | |
| 13 | + - "samsung,exynos5420-audss-clock" - controller compatible with Exynos5420 | |
| 14 | + SoCs. | |
| 13 | 15 | - reg: physical base address and length of the controller's register set. |
| 14 | 16 | |
| 15 | 17 | - #clock-cells: should be 1. |
| 16 | 18 | |
| 19 | +- clocks: | |
| 20 | + - pll_ref: Fixed rate PLL reference clock, parent of mout_audss. "fin_pll" | |
| 21 | + is used if not specified. | |
| 22 | + - pll_in: Input PLL to the AudioSS block, parent of mout_audss. "fout_epll" | |
| 23 | + is used if not specified. | |
| 24 | + - cdclk: External i2s clock, parent of mout_i2s. "cdclk0" is used if not | |
| 25 | + specified. | |
| 26 | + - sclk_audio: Audio bus clock, parent of mout_i2s. "sclk_audio0" is used if | |
| 27 | + not specified. | |
| 28 | + - sclk_pcm_in: PCM clock, parent of sclk_pcm. "sclk_pcm0" is used if not | |
| 29 | + specified. | |
| 30 | + | |
| 31 | +- clock-names: Aliases for the above clocks. They should be "pll_ref", | |
| 32 | + "pll_in", "cdclk", "sclk_audio", and "sclk_pcm_in" respectively. | |
| 33 | + | |
| 17 | 34 | The following is the list of clocks generated by the controller. Each clock is |
| 18 | 35 | assigned an identifier and client nodes use this identifier to specify the |
| 19 | 36 | clock which they consume. Some of the clocks are available only on a particular |
| @@ -34,16 +51,30 @@ i2s_bus 6 · 14 unmodified lines | ||
| 34 | 51 | sclk_i2s 7 |
| 35 | 52 | pcm_bus 8 |
| 36 | 53 | sclk_pcm 9 |
| 54 | +adma 10 Exynos5420 | |
| 55 | + | |
| 56 | +Example 1: An example of a clock controller node using the default input | |
| 57 | + clock names is listed below. | |
| 58 | + | |
| 59 | +clock_audss: audss-clock-controller@3810000 { | |
| 60 | + compatible = "samsung,exynos5250-audss-clock"; | |
| 61 | + reg = <0x03810000 0x0C>; | |
| 62 | + #clock-cells = <1>; | |
| 63 | +}; | |
| 37 | 64 | |
| 38 | −Example 1: An example of a clock controller node is listed below. | |
| 65 | +Example 2: An example of a clock controller node with the input clocks | |
| 66 | + specified. | |
| 39 | 67 | |
| 40 | 68 | clock_audss: audss-clock-controller@3810000 { |
| 41 | 69 | compatible = "samsung,exynos5250-audss-clock"; |
| 42 | 70 | reg = <0x03810000 0x0C>; |
| 43 | 71 | #clock-cells = <1>; |
| 72 | + clocks = <&clock 1>, <&clock 7>, <&clock 138>, <&clock 160>, | |
| 73 | + <&ext_i2s_clk>; | |
| 74 | + clock-names = "pll_ref", "pll_in", "sclk_audio", "sclk_pcm_in", "cdclk"; | |
| 44 | 75 | }; |
| 45 | 76 | |
| 46 | −Example 2: I2S controller node that consumes the clock generated by the clock | |
| 77 | +Example 3: I2S controller node that consumes the clock generated by the clock | |
| 47 | 78 | controller. Refer to the standard clock bindings for information |
| 48 | 79 | about 'clocks' and 'clock-names' property. |
| 49 | 80 | |
| @@ -5,7 +5,7 @@ Sources of clock signal can be represented by any node in the device · 4 unmodified lines | ||
| 5 | 5 | tree. Those nodes are designated as clock providers. Clock consumer |
| 6 | 6 | nodes use a phandle and clock specifier pair to connect clock provider |
| 7 | 7 | outputs to clock inputs. Similar to the gpio specifiers, a clock |
| 8 | −specifier is an array of one more more cells identifying the clock | |
| 8 | +specifier is an array of zero, one or more cells identifying the clock | |
| 9 | 9 | output on a device. The length of a clock specifier is defined by the |
| 10 | 10 | value of a #clock-cells property in the clock provider node. |
| 11 | 11 | |
| @@ -0,0 +1,134 @@ | ||
| 1 | +* Clock Block on Freescale CoreNet Platforms | |
| 2 | + | |
| 3 | +Freescale CoreNet chips take primary clocking input from the external | |
| 4 | +SYSCLK signal. The SYSCLK input (frequency) is multiplied using | |
| 5 | +multiple phase locked loops (PLL) to create a variety of frequencies | |
| 6 | +which can then be passed to a variety of internal logic, including | |
| 7 | +cores and peripheral IP blocks. | |
| 8 | +Please refer to the Reference Manual for details. | |
| 9 | + | |
| 10 | +1. Clock Block Binding | |
| 11 | + | |
| 12 | +Required properties: | |
| 13 | +- compatible: Should contain a specific clock block compatible string | |
| 14 | + and a single chassis clock compatible string. | |
| 15 | + Clock block strings include, but not limited to, one of the: | |
| 16 | + * "fsl,p2041-clockgen" | |
| 17 | + * "fsl,p3041-clockgen" | |
| 18 | + * "fsl,p4080-clockgen" | |
| 19 | + * "fsl,p5020-clockgen" | |
| 20 | + * "fsl,p5040-clockgen" | |
| 21 | + * "fsl,t4240-clockgen" | |
| 22 | + * "fsl,b4420-clockgen" | |
| 23 | + * "fsl,b4860-clockgen" | |
| 24 | + Chassis clock strings include: | |
| 25 | + * "fsl,qoriq-clockgen-1.0": for chassis 1.0 clocks | |
| 26 | + * "fsl,qoriq-clockgen-2.0": for chassis 2.0 clocks | |
| 27 | +- reg: Describes the address of the device's resources within the | |
| 28 | + address space defined by its parent bus, and resource zero | |
| 29 | + represents the clock register set | |
| 30 | +- clock-frequency: Input system clock frequency | |
| 31 | + | |
| 32 | +Recommended properties: | |
| 33 | +- ranges: Allows valid translation between child's address space and | |
| 34 | + parent's. Must be present if the device has sub-nodes. | |
| 35 | +- #address-cells: Specifies the number of cells used to represent | |
| 36 | + physical base addresses. Must be present if the device has | |
| 37 | + sub-nodes and set to 1 if present | |
| 38 | +- #size-cells: Specifies the number of cells used to represent | |
| 39 | + the size of an address. Must be present if the device has | |
| 40 | + sub-nodes and set to 1 if present | |
| 41 | + | |
| 42 | +2. Clock Provider/Consumer Binding | |
| 43 | + | |
| 44 | +Most of the bindings are from the common clock binding[1]. | |
| 45 | + [1] Documentation/devicetree/bindings/clock/clock-bindings.txt | |
| 46 | + | |
| 47 | +Required properties: | |
| 48 | +- compatible : Should include one of the following: | |
| 49 | + * "fsl,qoriq-core-pll-1.0" for core PLL clocks (v1.0) | |
| 50 | + * "fsl,qoriq-core-pll-2.0" for core PLL clocks (v2.0) | |
| 51 | + * "fsl,qoriq-core-mux-1.0" for core mux clocks (v1.0) | |
| 52 | + * "fsl,qoriq-core-mux-2.0" for core mux clocks (v2.0) | |
| 53 | + * "fsl,qoriq-sysclk-1.0": for input system clock (v1.0). | |
| 54 | + It takes parent's clock-frequency as its clock. | |
| 55 | + * "fsl,qoriq-sysclk-2.0": for input system clock (v2.0). | |
| 56 | + It takes parent's clock-frequency as its clock. | |
| 57 | +- #clock-cells: From common clock binding. The number of cells in a | |
| 58 | + clock-specifier. Should be <0> for "fsl,qoriq-sysclk-[1,2].0" | |
| 59 | + clocks, or <1> for "fsl,qoriq-core-pll-[1,2].0" clocks. | |
| 60 | + For "fsl,qoriq-core-pll-[1,2].0" clocks, the single | |
| 61 | + clock-specifier cell may take the following values: | |
| 62 | + * 0 - equal to the PLL frequency | |
| 63 | + * 1 - equal to the PLL frequency divided by 2 | |
| 64 | + * 2 - equal to the PLL frequency divided by 4 | |
| 65 | + | |
| 66 | +Recommended properties: | |
| 67 | +- clocks: Should be the phandle of input parent clock | |
| 68 | +- clock-names: From common clock binding, indicates the clock name | |
| 69 | +- clock-output-names: From common clock binding, indicates the names of | |
| 70 | + output clocks | |
| 71 | +- reg: Should be the offset and length of clock block base address. | |
| 72 | + The length should be 4. | |
| 73 | + | |
| 74 | +Example for clock block and clock provider: | |
| 75 | +/ { | |
| 76 | + clockgen: global-utilities@e1000 { | |
| 77 | + compatible = "fsl,p5020-clockgen", "fsl,qoriq-clockgen-1.0"; | |
| 78 | + ranges = <0x0 0xe1000 0x1000>; | |
| 79 | + clock-frequency = <133333333>; | |
| 80 | + reg = <0xe1000 0x1000>; | |
| 81 | + #address-cells = <1>; | |
| 82 | + #size-cells = <1>; | |
| 83 | + | |
| 84 | + sysclk: sysclk { | |
| 85 | + #clock-cells = <0>; | |
| 86 | + compatible = "fsl,qoriq-sysclk-1.0"; | |
| 87 | + clock-output-names = "sysclk"; | |
| 88 | + } | |
| 89 | + | |
| 90 | + pll0: pll0@800 { | |
| 91 | + #clock-cells = <1>; | |
| 92 | + reg = <0x800 0x4>; | |
| 93 | + compatible = "fsl,qoriq-core-pll-1.0"; | |
| 94 | + clocks = <&sysclk>; | |
| 95 | + clock-output-names = "pll0", "pll0-div2"; | |
| 96 | + }; | |
| 97 | + | |
| 98 | + pll1: pll1@820 { | |
| 99 | + #clock-cells = <1>; | |
| 100 | + reg = <0x820 0x4>; | |
| 101 | + compatible = "fsl,qoriq-core-pll-1.0"; | |
| 102 | + clocks = <&sysclk>; | |
| 103 | + clock-output-names = "pll1", "pll1-div2"; | |
| 104 | + }; | |
| 105 | + | |
| 106 | + mux0: mux0@0 { | |
| 107 | + #clock-cells = <0>; | |
| 108 | + reg = <0x0 0x4>; | |
| 109 | + compatible = "fsl,qoriq-core-mux-1.0"; | |
| 110 | + clocks = <&pll0 0>, <&pll0 1>, <&pll1 0>, <&pll1 1>; | |
| 111 | + clock-names = "pll0", "pll0-div2", "pll1", "pll1-div2"; | |
| 112 | + clock-output-names = "cmux0"; | |
| 113 | + }; | |
| 114 | + | |
| 115 | + mux1: mux1@20 { | |
| 116 | + #clock-cells = <0>; | |
| 117 | + reg = <0x20 0x4>; | |
| 118 | + compatible = "fsl,qoriq-core-mux-1.0"; | |
| 119 | + clocks = <&pll0 0>, <&pll0 1>, <&pll1 0>, <&pll1 1>; | |
| 120 | + clock-names = "pll0", "pll0-div2", "pll1", "pll1-div2"; | |
| 121 | + clock-output-names = "cmux1"; | |
| 122 | + }; | |
| 123 | + }; | |
| 124 | + } | |
| 125 | + | |
| 126 | +Example for clock consumer: | |
| 127 | + | |
| 128 | +/ { | |
| 129 | + cpu0: PowerPC,e5500@0 { | |
| 130 | + ... | |
| 131 | + clocks = <&mux0>; | |
| 132 | + ... | |
| 133 | + }; | |
| 134 | + } | |
| @@ -0,0 +1,98 @@ | ||
| 1 | +Device tree Clock bindings for Renesas EMMA Mobile EV2 | |
| 2 | + | |
| 3 | +This binding uses the common clock binding. | |
| 4 | + | |
| 5 | +* SMU | |
| 6 | +System Management Unit described in user's manual R19UH0037EJ1000_SMU. | |
| 7 | +This is not a clock provider, but clocks under SMU depend on it. | |
| 8 | + | |
| 9 | +Required properties: | |
| 10 | +- compatible: Should be "renesas,emev2-smu" | |
| 11 | +- reg: Address and Size of SMU registers | |
| 12 | + | |
| 13 | +* SMU_CLKDIV | |
| 14 | +Function block with an input mux and a divider, which corresponds to | |
| 15 | +"Serial clock generator" in fig."Clock System Overview" of the manual, | |
| 16 | +and "xxx frequency division setting register" (XXXCLKDIV) registers. | |
| 17 | +This makes internal (neither input nor output) clock that is provided | |
| 18 | +to input of xxxGCLK block. | |
| 19 | + | |
| 20 | +Required properties: | |
| 21 | +- compatible: Should be "renesas,emev2-smu-clkdiv" | |
| 22 | +- reg: Byte offset from SMU base and Bit position in the register | |
| 23 | +- clocks: Parent clocks. Input clocks as described in clock-bindings.txt | |
| 24 | +- #clock-cells: Should be <0> | |
| 25 | + | |
| 26 | +* SMU_GCLK | |
| 27 | +Clock gating node shown as "Clock stop processing block" in the | |
| 28 | +fig."Clock System Overview" of the manual. | |
| 29 | +Registers are "xxx clock gate control register" (XXXGCLKCTRL). | |
| 30 | + | |
| 31 | +Required properties: | |
| 32 | +- compatible: Should be "renesas,emev2-smu-gclk" | |
| 33 | +- reg: Byte offset from SMU base and Bit position in the register | |
| 34 | +- clocks: Input clock as described in clock-bindings.txt | |
| 35 | +- #clock-cells: Should be <0> | |
| 36 | + | |
| 37 | +Example of provider: | |
| 38 | + | |
| 39 | +usia_u0_sclkdiv: usia_u0_sclkdiv { | |
| 40 | + compatible = "renesas,emev2-smu-clkdiv"; | |
| 41 | + reg = <0x610 0>; | |
| 42 | + clocks = <&pll3_fo>, <&pll4_fo>, <&pll1_fo>, <&osc1_fo>; | |
| 43 | + #clock-cells = <0>; | |
| 44 | +}; | |
| 45 | + | |
| 46 | +usia_u0_sclk: usia_u0_sclk { | |
| 47 | + compatible = "renesas,emev2-smu-gclk"; | |
| 48 | + reg = <0x4a0 1>; | |
| 49 | + clocks = <&usia_u0_sclkdiv>; | |
| 50 | + #clock-cells = <0>; | |
| 51 | +}; | |
| 52 | + | |
| 53 | +Example of consumer: | |
| 54 | + | |
| 55 | +uart@e1020000 { | |
| 56 | + compatible = "renesas,em-uart"; | |
| 57 | + reg = <0xe1020000 0x38>; | |
| 58 | + interrupts = <0 8 0>; | |
| 59 | + clocks = <&usia_u0_sclk>; | |
| 60 | + clock-names = "sclk"; | |
| 61 | +}; | |
| 62 | + | |
| 63 | +Example of clock-tree description: | |
| 64 | + | |
| 65 | + This describes a clock path in the clock tree | |
| 66 | + c32ki -> pll3_fo -> usia_u0_sclkdiv -> usia_u0_sclk | |
| 67 | + | |
| 68 | +smu@e0110000 { | |
| 69 | + compatible = "renesas,emev2-smu"; | |
| 70 | + reg = <0xe0110000 0x10000>; | |
| 71 | + #address-cells = <2>; | |
| 72 | + #size-cells = <0>; | |
| 73 | + | |
| 74 | + c32ki: c32ki { | |
| 75 | + compatible = "fixed-clock"; | |
| 76 | + clock-frequency = <32768>; | |
| 77 | + #clock-cells = <0>; | |
| 78 | + }; | |
| 79 | + pll3_fo: pll3_fo { | |
| 80 | + compatible = "fixed-factor-clock"; | |
| 81 | + clocks = <&c32ki>; | |
| 82 | + clock-div = <1>; | |
| 83 | + clock-mult = <7000>; | |
| 84 | + #clock-cells = <0>; | |
| 85 | + }; | |
| 86 | + usia_u0_sclkdiv: usia_u0_sclkdiv { | |
| 87 | + compatible = "renesas,emev2-smu-clkdiv"; | |
| 88 | + reg = <0x610 0>; | |
| 89 | + clocks = <&pll3_fo>; | |
| 90 | + #clock-cells = <0>; | |
| 91 | + }; | |
| 92 | + usia_u0_sclk: usia_u0_sclk { | |
| 93 | + compatible = "renesas,emev2-smu-gclk"; | |
| 94 | + reg = <0x4a0 1>; | |
| 95 | + clocks = <&usia_u0_sclkdiv>; | |
| 96 | + #clock-cells = <0>; | |
| 97 | + }; | |
| 98 | +}; | |
| @@ -62,6 +62,7 @@ clock which they consume. · 61 unmodified lines | ||
| 62 | 62 | div_i2s1 157 |
| 63 | 63 | div_i2s2 158 |
| 64 | 64 | sclk_hdmiphy 159 |
| 65 | + div_pcm0 160 | |
| 65 | 66 | |
| 66 | 67 | |
| 67 | 68 | [Peripheral Clock Gates] |
| @@ -10,6 +10,8 @@ Required properties: · 9 unmodified lines | ||
| 10 | 10 | - clock-frequency : frequency of clock in Hz. Should be a single cell. |
| 11 | 11 | |
| 12 | 12 | Optional properties: |
| 13 | +- clock-accuracy : accuracy of clock in ppb (parts per billion). | |
| 14 | + Should be a single cell. | |
| 13 | 15 | - gpios : From common gpio binding; gpio connection to clock enable pin. |
| 14 | 16 | - clock-output-names : From common clock binding. |
| 15 | 17 | |
| @@ -18,4 +20,5 @@ Example: · 2 unmodified lines | ||
| 18 | 20 | compatible = "fixed-clock"; |
| 19 | 21 | #clock-cells = <0>; |
| 20 | 22 | clock-frequency = <1000000000>; |
| 23 | + clock-accuracy = <100>; | |
| 21 | 24 | }; |
| @@ -19,6 +19,6 @@ Example: · 18 unmodified lines | ||
| 19 | 19 | compatible = "fixed-factor-clock"; |
| 20 | 20 | clocks = <&parentclk>; |
| 21 | 21 | #clock-cells = <0>; |
| 22 | − div = <2>; | |
| 23 | − mult = <1>; | |
| 22 | + clock-div = <2>; | |
| 23 | + clock-mult = <1>; | |
| 24 | 24 | }; |
| @@ -0,0 +1,19 @@ | ||
| 1 | +* Hisilicon Hi3620 Clock Controller | |
| 2 | + | |
| 3 | +The Hi3620 clock controller generates and supplies clock to various | |
| 4 | +controllers within the Hi3620 SoC. | |
| 5 | + | |
| 6 | +Required Properties: | |
| 7 | + | |
| 8 | +- compatible: should be one of the following. | |
| 9 | + - "hisilicon,hi3620-clock" - controller compatible with Hi3620 SoC. | |
| 10 | + | |
| 11 | +- reg: physical base address of the controller and length of memory mapped | |
| 12 | + region. | |
| 13 | + | |
| 14 | +- #clock-cells: should be 1. | |
| 15 | + | |
| 16 | +Each clock is assigned an identifier and client nodes use this identifier | |
| 17 | +to specify the clock which they consume. | |
| 18 | + | |
| 19 | +All these identifier could be found in <dt-bindings/clock/hi3620-clock.h>. | |
| @@ -0,0 +1,113 @@ | ||
| 1 | +* Clock bindings for Freescale i.MX35 | |
| 2 | + | |
| 3 | +Required properties: | |
| 4 | +- compatible: Should be "fsl,imx35-ccm" | |
| 5 | +- reg: Address and length of the register set | |
| 6 | +- interrupts: Should contain CCM interrupt | |
| 7 | +- #clock-cells: Should be <1> | |
| 8 | + | |
| 9 | +The clock consumer should specify the desired clock by having the clock | |
| 10 | +ID in its "clocks" phandle cell. The following is a full list of i.MX35 | |
| 11 | +clocks and IDs. | |
| 12 | + | |
| 13 | + Clock ID | |
| 14 | + --------------------------- | |
| 15 | + ckih 0 | |
| 16 | + mpll 1 | |
| 17 | + ppll 2 | |
| 18 | + mpll_075 3 | |
| 19 | + arm 4 | |
| 20 | + hsp 5 | |
| 21 | + hsp_div 6 | |
| 22 | + hsp_sel 7 | |
| 23 | + ahb 8 | |
| 24 | + ipg 9 | |
| 25 | + arm_per_div 10 | |
| 26 | + ahb_per_div 11 | |
| 27 | + ipg_per 12 | |
| 28 | + uart_sel 13 | |
| 29 | + uart_div 14 | |
| 30 | + esdhc_sel 15 | |
| 31 | + esdhc1_div 16 | |
| 32 | + esdhc2_div 17 | |
| 33 | + esdhc3_div 18 | |
| 34 | + spdif_sel 19 | |
| 35 | + spdif_div_pre 20 | |
| 36 | + spdif_div_post 21 | |
| 37 | + ssi_sel 22 | |
| 38 | + ssi1_div_pre 23 | |
| 39 | + ssi1_div_post 24 | |
| 40 | + ssi2_div_pre 25 | |
| 41 | + ssi2_div_post 26 | |
| 42 | + usb_sel 27 | |
| 43 | + usb_div 28 | |
| 44 | + nfc_div 29 | |
| 45 | + asrc_gate 30 | |
| 46 | + pata_gate 31 | |
| 47 | + audmux_gate 32 | |
| 48 | + can1_gate 33 | |
| 49 | + can2_gate 34 | |
| 50 | + cspi1_gate 35 | |
| 51 | + cspi2_gate 36 | |
| 52 | + ect_gate 37 | |
| 53 | + edio_gate 38 | |
| 54 | + emi_gate 39 | |
| 55 | + epit1_gate 40 | |
| 56 | + epit2_gate 41 | |
| 57 | + esai_gate 42 | |
| 58 | + esdhc1_gate 43 | |
| 59 | + esdhc2_gate 44 | |
| 60 | + esdhc3_gate 45 | |
| 61 | + fec_gate 46 | |
| 62 | + gpio1_gate 47 | |
| 63 | + gpio2_gate 48 | |
| 64 | + gpio3_gate 49 | |
| 65 | + gpt_gate 50 | |
| 66 | + i2c1_gate 51 | |
| 67 | + i2c2_gate 52 | |
| 68 | + i2c3_gate 53 | |
| 69 | + iomuxc_gate 54 | |
| 70 | + ipu_gate 55 | |
| 71 | + kpp_gate 56 | |
| 72 | + mlb_gate 57 | |
| 73 | + mshc_gate 58 | |
| 74 | + owire_gate 59 | |
| 75 | + pwm_gate 60 | |
| 76 | + rngc_gate 61 | |
| 77 | + rtc_gate 62 | |
| 78 | + rtic_gate 63 | |
| 79 | + scc_gate 64 | |
| 80 | + sdma_gate 65 | |
| 81 | + spba_gate 66 | |
| 82 | + spdif_gate 67 | |
| 83 | + ssi1_gate 68 | |
| 84 | + ssi2_gate 69 | |
| 85 | + uart1_gate 70 | |
| 86 | + uart2_gate 71 | |
| 87 | + uart3_gate 72 | |
| 88 | + usbotg_gate 73 | |
| 89 | + wdog_gate 74 | |
| 90 | + max_gate 75 | |
| 91 | + admux_gate 76 | |
| 92 | + csi_gate 77 | |
| 93 | + csi_div 78 | |
| 94 | + csi_sel 79 | |
| 95 | + iim_gate 80 | |
| 96 | + gpu2d_gate 81 | |
| 97 | + | |
| 98 | +Examples: | |
| 99 | + | |
| 100 | +clks: ccm@53f80000 { | |
| 101 | + compatible = "fsl,imx35-ccm"; | |
| 102 | + reg = <0x53f80000 0x4000>; | |
| 103 | + interrupts = <31>; | |
| 104 | + #clock-cells = <1>; | |
| 105 | +}; | |
| 106 | + | |
| 107 | +esdhc1: esdhc@53fb4000 { | |
| 108 | + compatible = "fsl,imx35-esdhc"; | |
| 109 | + reg = <0x53fb4000 0x4000>; | |
| 110 | + interrupts = <7>; | |
| 111 | + clocks = <&clks 9>, <&clks 8>, <&clks 43>; | |
| 112 | + clock-names = "ipg", "ahb", "per"; | |
| 113 | +}; | |
| @@ -7,197 +7,8 @@ Required properties: · 6 unmodified lines | ||
| 7 | 7 | - #clock-cells: Should be <1> |
| 8 | 8 | |
| 9 | 9 | The clock consumer should specify the desired clock by having the clock |
| 10 | −ID in its "clocks" phandle cell. The following is a full list of i.MX5 | |
| 11 | −clocks and IDs. | |
| 12 | − | |
| 13 | − Clock ID | |
| 14 | − --------------------------- | |
| 15 | − dummy 0 | |
| 16 | − ckil 1 | |
| 17 | − osc 2 | |
| 18 | − ckih1 3 | |
| 19 | − ckih2 4 | |
| 20 | − ahb 5 | |
| 21 | − ipg 6 | |
| 22 | − axi_a 7 | |
| 23 | − axi_b 8 | |
| 24 | − uart_pred 9 | |
| 25 | − uart_root 10 | |
| 26 | − esdhc_a_pred 11 | |
| 27 | − esdhc_b_pred 12 | |
| 28 | − esdhc_c_s 13 | |
| 29 | − esdhc_d_s 14 | |
| 30 | − emi_sel 15 | |
| 31 | − emi_slow_podf 16 | |
| 32 | − nfc_podf 17 | |
| 33 | − ecspi_pred 18 | |
| 34 | − ecspi_podf 19 | |
| 35 | − usboh3_pred 20 | |
| 36 | − usboh3_podf 21 | |
| 37 | − usb_phy_pred 22 | |
| 38 | − usb_phy_podf 23 | |
| 39 | − cpu_podf 24 | |
| 40 | − di_pred 25 | |
| 41 | − tve_s 27 | |
| 42 | − uart1_ipg_gate 28 | |
| 43 | − uart1_per_gate 29 | |
| 44 | − uart2_ipg_gate 30 | |
| 45 | − uart2_per_gate 31 | |
| 46 | − uart3_ipg_gate 32 | |
| 47 | − uart3_per_gate 33 | |
| 48 | − i2c1_gate 34 | |
| 49 | − i2c2_gate 35 | |
| 50 | − gpt_ipg_gate 36 | |
| 51 | − pwm1_ipg_gate 37 | |
| 52 | − pwm1_hf_gate 38 | |
| 53 | − pwm2_ipg_gate 39 | |
| 54 | − pwm2_hf_gate 40 | |
| 55 | − gpt_hf_gate 41 | |
| 56 | − fec_gate 42 | |
| 57 | − usboh3_per_gate 43 | |
| 58 | − esdhc1_ipg_gate 44 | |
| 59 | − esdhc2_ipg_gate 45 | |
| 60 | − esdhc3_ipg_gate 46 | |
| 61 | − esdhc4_ipg_gate 47 | |
| 62 | − ssi1_ipg_gate 48 | |
| 63 | − ssi2_ipg_gate 49 | |
| 64 | − ssi3_ipg_gate 50 | |
| 65 | − ecspi1_ipg_gate 51 | |
| 66 | − ecspi1_per_gate 52 | |
| 67 | − ecspi2_ipg_gate 53 | |
| 68 | − ecspi2_per_gate 54 | |
| 69 | − cspi_ipg_gate 55 | |
| 70 | − sdma_gate 56 | |
| 71 | − emi_slow_gate 57 | |
| 72 | − ipu_s 58 | |
| 73 | − ipu_gate 59 | |
| 74 | − nfc_gate 60 | |
| 75 | − ipu_di1_gate 61 | |
| 76 | − vpu_s 62 | |
| 77 | − vpu_gate 63 | |
| 78 | − vpu_reference_gate 64 | |
| 79 | − uart4_ipg_gate 65 | |
| 80 | − uart4_per_gate 66 | |
| 81 | − uart5_ipg_gate 67 | |
| 82 | − uart5_per_gate 68 | |
| 83 | − tve_gate 69 | |
| 84 | − tve_pred 70 | |
| 85 | − esdhc1_per_gate 71 | |
| 86 | − esdhc2_per_gate 72 | |
| 87 | − esdhc3_per_gate 73 | |
| 88 | − esdhc4_per_gate 74 | |
| 89 | − usb_phy_gate 75 | |
| 90 | − hsi2c_gate 76 | |
| 91 | − mipi_hsc1_gate 77 | |
| 92 | − mipi_hsc2_gate 78 | |
| 93 | − mipi_esc_gate 79 | |
| 94 | − mipi_hsp_gate 80 | |
| 95 | − ldb_di1_div_3_5 81 | |
| 96 | − ldb_di1_div 82 | |
| 97 | − ldb_di0_div_3_5 83 | |
| 98 | − ldb_di0_div 84 | |
| 99 | − ldb_di1_gate 85 | |
| 100 | − can2_serial_gate 86 | |
| 101 | − can2_ipg_gate 87 | |
| 102 | − i2c3_gate 88 | |
| 103 | − lp_apm 89 | |
| 104 | − periph_apm 90 | |
| 105 | − main_bus 91 | |
| 106 | − ahb_max 92 | |
| 107 | − aips_tz1 93 | |
| 108 | − aips_tz2 94 | |
| 109 | − tmax1 95 | |
| 110 | − tmax2 96 | |
| 111 | − tmax3 97 | |
| 112 | − spba 98 | |
| 113 | − uart_sel 99 | |
| 114 | − esdhc_a_sel 100 | |
| 115 | − esdhc_b_sel 101 | |
| 116 | − esdhc_a_podf 102 | |
| 117 | − esdhc_b_podf 103 | |
| 118 | − ecspi_sel 104 | |
| 119 | − usboh3_sel 105 | |
| 120 | − usb_phy_sel 106 | |
| 121 | − iim_gate 107 | |
| 122 | − usboh3_gate 108 | |
| 123 | − emi_fast_gate 109 | |
| 124 | − ipu_di0_gate 110 | |
| 125 | − gpc_dvfs 111 | |
| 126 | − pll1_sw 112 | |
| 127 | − pll2_sw 113 | |
| 128 | − pll3_sw 114 | |
| 129 | − ipu_di0_sel 115 | |
| 130 | − ipu_di1_sel 116 | |
| 131 | − tve_ext_sel 117 | |
| 132 | − mx51_mipi 118 | |
| 133 | − pll4_sw 119 | |
| 134 | − ldb_di1_sel 120 | |
| 135 | − di_pll4_podf 121 | |
| 136 | − ldb_di0_sel 122 | |
| 137 | − ldb_di0_gate 123 | |
| 138 | − usb_phy1_gate 124 | |
| 139 | − usb_phy2_gate 125 | |
| 140 | − per_lp_apm 126 | |
| 141 | − per_pred1 127 | |
| 142 | − per_pred2 128 | |
| 143 | − per_podf 129 | |
| 144 | − per_root 130 | |
| 145 | − ssi_apm 131 | |
| 146 | − ssi1_root_sel 132 | |
| 147 | − ssi2_root_sel 133 | |
| 148 | − ssi3_root_sel 134 | |
| 149 | − ssi_ext1_sel 135 | |
| 150 | − ssi_ext2_sel 136 | |
| 151 | − ssi_ext1_com_sel 137 | |
| 152 | − ssi_ext2_com_sel 138 | |
| 153 | − ssi1_root_pred 139 | |
| 154 | − ssi1_root_podf 140 | |
| 155 | − ssi2_root_pred 141 | |
| 156 | − ssi2_root_podf 142 | |
| 157 | − ssi_ext1_pred 143 | |
| 158 | − ssi_ext1_podf 144 | |
| 159 | − ssi_ext2_pred 145 | |
| 160 | − ssi_ext2_podf 146 | |
| 161 | − ssi1_root_gate 147 | |
| 162 | − ssi2_root_gate 148 | |
| 163 | − ssi3_root_gate 149 | |
| 164 | − ssi_ext1_gate 150 | |
| 165 | − ssi_ext2_gate 151 | |
| 166 | − epit1_ipg_gate 152 | |
| 167 | − epit1_hf_gate 153 | |
| 168 | − epit2_ipg_gate 154 | |
| 169 | − epit2_hf_gate 155 | |
| 170 | − can_sel 156 | |
| 171 | − can1_serial_gate 157 | |
| 172 | − can1_ipg_gate 158 | |
| 173 | − owire_gate 159 | |
| 174 | − gpu3d_s 160 | |
| 175 | − gpu2d_s 161 | |
| 176 | − gpu3d_gate 162 | |
| 177 | − gpu2d_gate 163 | |
| 178 | − garb_gate 164 | |
| 179 | − cko1_sel 165 | |
| 180 | − cko1_podf 166 | |
| 181 | − cko1 167 | |
| 182 | − cko2_sel 168 | |
| 183 | − cko2_podf 169 | |
| 184 | − cko2 170 | |
| 185 | − srtc_gate 171 | |
| 186 | − pata_gate 172 | |
| 187 | − sata_gate 173 | |
| 188 | − spdif_xtal_sel 174 | |
| 189 | − spdif0_sel 175 | |
| 190 | − spdif1_sel 176 | |
| 191 | − spdif0_pred 177 | |
| 192 | − spdif0_podf 178 | |
| 193 | − spdif1_pred 179 | |
| 194 | − spdif1_podf 180 | |
| 195 | − spdif0_com_sel 181 | |
| 196 | − spdif1_com_sel 182 | |
| 197 | − spdif0_gate 183 | |
| 198 | − spdif1_gate 184 | |
| 199 | − spdif_ipg_gate 185 | |
| 200 | − ocram 186 | |
| 10 | +ID in its "clocks" phandle cell. See include/dt-bindings/clock/imx5-clock.h | |
| 11 | +for the full list of i.MX5 clock IDs. | |
| 201 | 12 | |
| 202 | 13 | Examples (for mx53): |
| 203 | 14 | |
| @@ -212,7 +23,7 @@ can1: can@53fc8000 { · 8 unmodified lines | ||
| 212 | 23 | compatible = "fsl,imx53-flexcan", "fsl,p1010-flexcan"; |
| 213 | 24 | reg = <0x53fc8000 0x4000>; |
| 214 | 25 | interrupts = <82>; |
| 215 | − clocks = <&clks 158>, <&clks 157>; | |
| 26 | + clocks = <&clks IMX5_CLK_CAN1_IPG_GATE>, <&clks IMX5_CLK_CAN1_SERIAL_GATE>; | |
| 216 | 27 | clock-names = "ipg", "per"; |
| 217 | 28 | status = "disabled"; |
| 218 | 29 | }; |
| @@ -17,13 +17,14 @@ Required properties: · 16 unmodified lines | ||
| 17 | 17 | - reg - pll control0 and pll multipler registers |
| 18 | 18 | - reg-names : control and multiplier. The multiplier is applicable only for |
| 19 | 19 | main pll clock |
| 20 | −- fixed-postdiv : fixed post divider value | |
| 20 | +- fixed-postdiv : fixed post divider value. If absent, use clkod register bits | |
| 21 | + for postdiv | |
| 21 | 22 | |
| 22 | 23 | Example: |
| 23 | 24 | mainpllclk: mainpllclk@2310110 { |
| 24 | 25 | #clock-cells = <0>; |
| 25 | 26 | compatible = "ti,keystone,main-pll-clock"; |
| 26 | − clocks = <&refclkmain>; | |
| 27 | + clocks = <&refclksys>; | |
| 27 | 28 | reg = <0x02620350 4>, <0x02310110 4>; |
| 28 | 29 | reg-names = "control", "multiplier"; |
| 29 | 30 | fixed-postdiv = <2>; |
| @@ -32,11 +33,10 @@ Example: · 2 unmodified lines | ||
| 32 | 33 | papllclk: papllclk@2620358 { |
| 33 | 34 | #clock-cells = <0>; |
| 34 | 35 | compatible = "ti,keystone,pll-clock"; |
| 35 | − clocks = <&refclkmain>; | |
| 36 | + clocks = <&refclkpass>; | |
| 36 | 37 | clock-output-names = "pa-pll-clk"; |
| 37 | 38 | reg = <0x02620358 4>; |
| 38 | 39 | reg-names = "control"; |
| 39 | − fixed-postdiv = <6>; | |
| 40 | 40 | }; |
| 41 | 41 | |
| 42 | 42 | Required properties: |
| @@ -0,0 +1,38 @@ | ||
| 1 | +Binding for Maxim MAX77686 32k clock generator block | |
| 2 | + | |
| 3 | +This is a part of device tree bindings of MAX77686 multi-function device. | |
| 4 | +More information can be found in bindings/mfd/max77686.txt file. | |
| 5 | + | |
| 6 | +The MAX77686 contains three 32.768khz clock outputs that can be controlled | |
| 7 | +(gated/ungated) over I2C. | |
| 8 | + | |
| 9 | +Following properties should be presend in main device node of the MFD chip. | |
| 10 | + | |
| 11 | +Required properties: | |
| 12 | +- #clock-cells: simple one-cell clock specifier format is used, where the | |
| 13 | + only cell is used as an index of the clock inside the provider. Following | |
| 14 | + indices are allowed: | |
| 15 | + - 0: 32khz_ap clock, | |
| 16 | + - 1: 32khz_cp clock, | |
| 17 | + - 2: 32khz_pmic clock. | |
| 18 | + | |
| 19 | +Example: Node of the MFD chip | |
| 20 | + | |
| 21 | + max77686: max77686@09 { | |
| 22 | + compatible = "maxim,max77686"; | |
| 23 | + interrupt-parent = <&wakeup_eint>; | |
| 24 | + interrupts = <26 0>; | |
| 25 | + reg = <0x09>; | |
| 26 | + #clock-cells = <1>; | |
| 27 | + | |
| 28 | + /* ... */ | |
| 29 | + }; | |
| 30 | + | |
| 31 | +Example: Clock consumer node | |
| 32 | + | |
| 33 | + foo@0 { | |
| 34 | + compatible = "bar,foo"; | |
| 35 | + /* ... */ | |
| 36 | + clock-names = "my-clock"; | |
| 37 | + clocks = <&max77686 2>; | |
| 38 | + }; | |
| @@ -15,6 +15,9 @@ Required properties : · 14 unmodified lines | ||
| 15 | 15 | In clock consumers, this cell represents the clock ID exposed by the |
| 16 | 16 | CAR. The assignments may be found in header file |
| 17 | 17 | <dt-bindings/clock/tegra114-car.h>. |
| 18 | +- #reset-cells : Should be 1. | |
| 19 | + In clock consumers, this cell represents the bit number in the CAR's | |
| 20 | + array of CLK_RST_CONTROLLER_RST_DEVICES_* registers. | |
| 18 | 21 | |
| 19 | 22 | Example SoC include file: |
| 20 | 23 | |
| @@ -23,6 +26,7 @@ Example SoC include file: · 2 unmodified lines | ||
| 23 | 26 | compatible = "nvidia,tegra114-car"; |
| 24 | 27 | reg = <0x60006000 0x1000>; |
| 25 | 28 | #clock-cells = <1>; |
| 29 | + #reset-cells = <1>; | |
| 26 | 30 | }; |
| 27 | 31 | |
| 28 | 32 | usb@c5004000 { |
| @@ -0,0 +1,63 @@ | ||
| 1 | +NVIDIA Tegra124 Clock And Reset Controller | |
| 2 | + | |
| 3 | +This binding uses the common clock binding: | |
| 4 | +Documentation/devicetree/bindings/clock/clock-bindings.txt | |
| 5 | + | |
| 6 | +The CAR (Clock And Reset) Controller on Tegra is the HW module responsible | |
| 7 | +for muxing and gating Tegra's clocks, and setting their rates. | |
| 8 | + | |
| 9 | +Required properties : | |
| 10 | +- compatible : Should be "nvidia,tegra124-car" | |
| 11 | +- reg : Should contain CAR registers location and length | |
| 12 | +- clocks : Should contain phandle and clock specifiers for two clocks: | |
| 13 | + the 32 KHz "32k_in", and the board-specific oscillator "osc". | |
| 14 | +- #clock-cells : Should be 1. | |
| 15 | + In clock consumers, this cell represents the clock ID exposed by the | |
| 16 | + CAR. The assignments may be found in header file | |
| 17 | + <dt-bindings/clock/tegra124-car.h>. | |
| 18 | +- #reset-cells : Should be 1. | |
| 19 | + In clock consumers, this cell represents the bit number in the CAR's | |
| 20 | + array of CLK_RST_CONTROLLER_RST_DEVICES_* registers. | |
| 21 | + | |
| 22 | +Example SoC include file: | |
| 23 | + | |
| 24 | +/ { | |
| 25 | + tegra_car: clock { | |
| 26 | + compatible = "nvidia,tegra124-car"; | |
| 27 | + reg = <0x60006000 0x1000>; | |
| 28 | + #clock-cells = <1>; | |
| 29 | + #reset-cells = <1>; | |
| 30 | + }; | |
| 31 | + | |
| 32 | + usb@c5004000 { | |
| 33 | + clocks = <&tegra_car TEGRA124_CLK_USB2>; | |
| 34 | + }; | |
| 35 | +}; | |
| 36 | + | |
| 37 | +Example board file: | |
| 38 | + | |
| 39 | +/ { | |
| 40 | + clocks { | |
| 41 | + compatible = "simple-bus"; | |
| 42 | + #address-cells = <1>; | |
| 43 | + #size-cells = <0>; | |
| 44 | + | |
| 45 | + osc: clock@0 { | |
| 46 | + compatible = "fixed-clock"; | |
| 47 | + reg = <0>; | |
| 48 | + #clock-cells = <0>; | |
| 49 | + clock-frequency = <112400000>; | |
| 50 | + }; | |
| 51 | + | |
| 52 | + clk_32k: clock@1 { | |
| 53 | + compatible = "fixed-clock"; | |
| 54 | + reg = <1>; | |
| 55 | + #clock-cells = <0>; | |
| 56 | + clock-frequency = <32768>; | |
| 57 | + }; | |
| 58 | + }; | |
| 59 | + | |
| 60 | + &tegra_car { | |
| 61 | + clocks = <&clk_32k> <&osc>; | |
| 62 | + }; | |
| 63 | +}; | |
| @@ -15,6 +15,9 @@ Required properties : · 14 unmodified lines | ||
| 15 | 15 | In clock consumers, this cell represents the clock ID exposed by the |
| 16 | 16 | CAR. The assignments may be found in header file |
| 17 | 17 | <dt-bindings/clock/tegra20-car.h>. |
| 18 | +- #reset-cells : Should be 1. | |
| 19 | + In clock consumers, this cell represents the bit number in the CAR's | |
| 20 | + array of CLK_RST_CONTROLLER_RST_DEVICES_* registers. | |
| 18 | 21 | |
| 19 | 22 | Example SoC include file: |
| 20 | 23 | |
| @@ -23,6 +26,7 @@ Example SoC include file: · 2 unmodified lines | ||
| 23 | 26 | compatible = "nvidia,tegra20-car"; |
| 24 | 27 | reg = <0x60006000 0x1000>; |
| 25 | 28 | #clock-cells = <1>; |
| 29 | + #reset-cells = <1>; | |
| 26 | 30 | }; |
| 27 | 31 | |
| 28 | 32 | usb@c5004000 { |
| @@ -15,6 +15,9 @@ Required properties : · 14 unmodified lines | ||
| 15 | 15 | In clock consumers, this cell represents the clock ID exposed by the |
| 16 | 16 | CAR. The assignments may be found in header file |
| 17 | 17 | <dt-bindings/clock/tegra30-car.h>. |
| 18 | +- #reset-cells : Should be 1. | |
| 19 | + In clock consumers, this cell represents the bit number in the CAR's | |
| 20 | + array of CLK_RST_CONTROLLER_RST_DEVICES_* registers. | |
| 18 | 21 | |
| 19 | 22 | Example SoC include file: |
| 20 | 23 | |
| @@ -23,6 +26,7 @@ Example SoC include file: · 2 unmodified lines | ||
| 23 | 26 | compatible = "nvidia,tegra30-car"; |
| 24 | 27 | reg = <0x60006000 0x1000>; |
| 25 | 28 | #clock-cells = <1>; |
| 29 | + #reset-cells = <1>; | |
| 26 | 30 | }; |
| 27 | 31 | |
| 28 | 32 | usb@c5004000 { |
| @@ -0,0 +1,21 @@ | ||
| 1 | +Qualcomm Global Clock & Reset Controller Binding | |
| 2 | +------------------------------------------------ | |
| 3 | + | |
| 4 | +Required properties : | |
| 5 | +- compatible : shall contain only one of the following: | |
| 6 | + | |
| 7 | + "qcom,gcc-msm8660" | |
| 8 | + "qcom,gcc-msm8960" | |
| 9 | + "qcom,gcc-msm8974" | |
| 10 | + | |
| 11 | +- reg : shall contain base register location and length | |
| 12 | +- #clock-cells : shall contain 1 | |
| 13 | +- #reset-cells : shall contain 1 | |
| 14 | + | |
| 15 | +Example: | |
| 16 | + clock-controller@900000 { | |
| 17 | + compatible = "qcom,gcc-msm8960"; | |
| 18 | + reg = <0x900000 0x4000>; | |
| 19 | + #clock-cells = <1>; | |
| 20 | + #reset-cells = <1>; | |
| 21 | + }; | |
| @@ -0,0 +1,21 @@ | ||
| 1 | +Qualcomm Multimedia Clock & Reset Controller Binding | |
| 2 | +---------------------------------------------------- | |
| 3 | + | |
| 4 | +Required properties : | |
| 5 | +- compatible : shall contain only one of the following: | |
| 6 | + | |
| 7 | + "qcom,mmcc-msm8660" | |
| 8 | + "qcom,mmcc-msm8960" | |
| 9 | + "qcom,mmcc-msm8974" | |
| 10 | + | |
| 11 | +- reg : shall contain base register location and length | |
| 12 | +- #clock-cells : shall contain 1 | |
| 13 | +- #reset-cells : shall contain 1 | |
| 14 | + | |
| 15 | +Example: | |
| 16 | + clock-controller@4000000 { | |
| 17 | + compatible = "qcom,mmcc-msm8960"; | |
| 18 | + reg = <0x4000000 0x1000>; | |
| 19 | + #clock-cells = <1>; | |
| 20 | + #reset-cells = <1>; | |
| 21 | + }; | |
| @@ -0,0 +1,28 @@ | ||
| 1 | +* Renesas CPG DIV6 Clock | |
| 2 | + | |
| 3 | +The CPG DIV6 clocks are variable factor clocks provided by the Clock Pulse | |
| 4 | +Generator (CPG). They clock input is divided by a configurable factor from 1 | |
| 5 | +to 64. | |
| 6 | + | |
| 7 | +Required Properties: | |
| 8 | + | |
| 9 | + - compatible: Must be one of the following | |
| 10 | + - "renesas,r8a7790-div6-clock" for R8A7790 (R-Car H2) DIV6 clocks | |
| 11 | + - "renesas,r8a7791-div6-clock" for R8A7791 (R-Car M2) DIV6 clocks | |
| 12 | + - "renesas,cpg-div6-clock" for generic DIV6 clocks | |
| 13 | + - reg: Base address and length of the memory resource used by the DIV6 clock | |
| 14 | + - clocks: Reference to the parent clock | |
| 15 | + - #clock-cells: Must be 0 | |
| 16 | + - clock-output-names: The name of the clock as a free-form string | |
| 17 | + | |
| 18 | + | |
| 19 | +Example | |
| 20 | +------- | |
| 21 | + | |
| 22 | + sd2_clk: sd2_clk@e6150078 { | |
| 23 | + compatible = "renesas,r8a7790-div6-clock", "renesas,cpg-div6-clock"; | |
| 24 | + reg = <0 0xe6150078 0 4>; | |
| 25 | + clocks = <&pll1_div2_clk>; | |
| 26 | + #clock-cells = <0>; | |
| 27 | + clock-output-names = "sd2"; | |
| 28 | + }; | |
| @@ -0,0 +1,51 @@ | ||
| 1 | +* Renesas CPG Module Stop (MSTP) Clocks | |
| 2 | + | |
| 3 | +The CPG can gate SoC device clocks. The gates are organized in groups of up to | |
| 4 | +32 gates. | |
| 5 | + | |
| 6 | +This device tree binding describes a single 32 gate clocks group per node. | |
| 7 | +Clocks are referenced by user nodes by the MSTP node phandle and the clock | |
| 8 | +index in the group, from 0 to 31. | |
| 9 | + | |
| 10 | +Required Properties: | |
| 11 | + | |
| 12 | + - compatible: Must be one of the following | |
| 13 | + - "renesas,r8a7790-mstp-clocks" for R8A7790 (R-Car H2) MSTP gate clocks | |
| 14 | + - "renesas,r8a7791-mstp-clocks" for R8A7791 (R-Car M2) MSTP gate clocks | |
| 15 | + - "renesas,cpg-mstp-clock" for generic MSTP gate clocks | |
| 16 | + - reg: Base address and length of the I/O mapped registers used by the MSTP | |
| 17 | + clocks. The first register is the clock control register and is mandatory. | |
| 18 | + The second register is the clock status register and is optional when not | |
| 19 | + implemented in hardware. | |
| 20 | + - clocks: Reference to the parent clocks, one per output clock. The parents | |
| 21 | + must appear in the same order as the output clocks. | |
| 22 | + - #clock-cells: Must be 1 | |
| 23 | + - clock-output-names: The name of the clocks as free-form strings | |
| 24 | + - renesas,indices: Indices of the gate clocks into the group (0 to 31) | |
| 25 | + | |
| 26 | +The clocks, clock-output-names and renesas,indices properties contain one | |
| 27 | +entry per gate clock. The MSTP groups are sparsely populated. Unimplemented | |
| 28 | +gate clocks must not be declared. | |
| 29 | + | |
| 30 | + | |
| 31 | +Example | |
| 32 | +------- | |
| 33 | + | |
| 34 | + #include <dt-bindings/clock/r8a7790-clock.h> | |
| 35 | + | |
| 36 | + mstp3_clks: mstp3_clks@e615013c { | |
| 37 | + compatible = "renesas,r8a7790-mstp-clocks", "renesas,cpg-mstp-clocks"; | |
| 38 | + reg = <0 0xe615013c 0 4>, <0 0xe6150048 0 4>; | |
| 39 | + clocks = <&cp_clk>, <&mmc1_clk>, <&sd3_clk>, <&sd2_clk>, | |
| 40 | + <&cpg_clocks R8A7790_CLK_SD1>, <&cpg_clocks R8A7790_CLK_SD0>, | |
| 41 | + <&mmc0_clk>; | |
| 42 | + #clock-cells = <1>; | |
| 43 | + clock-output-names = | |
| 44 | + "tpu0", "mmcif1", "sdhi3", "sdhi2", | |
| 45 | + "sdhi1", "sdhi0", "mmcif0"; | |
| 46 | + renesas,clock-indices = < | |
| 47 | + R8A7790_CLK_TPU0 R8A7790_CLK_MMCIF1 R8A7790_CLK_SDHI3 | |
| 48 | + R8A7790_CLK_SDHI2 R8A7790_CLK_SDHI1 R8A7790_CLK_SDHI0 | |
| 49 | + R8A7790_CLK_MMCIF0 | |
| 50 | + >; | |
| 51 | + }; | |
| @@ -0,0 +1,32 @@ | ||
| 1 | +* Renesas R-Car Gen2 Clock Pulse Generator (CPG) | |
| 2 | + | |
| 3 | +The CPG generates core clocks for the R-Car Gen2 SoCs. It includes three PLLs | |
| 4 | +and several fixed ratio dividers. | |
| 5 | + | |
| 6 | +Required Properties: | |
| 7 | + | |
| 8 | + - compatible: Must be one of | |
| 9 | + - "renesas,r8a7790-cpg-clocks" for the r8a7790 CPG | |
| 10 | + - "renesas,r8a7791-cpg-clocks" for the r8a7791 CPG | |
| 11 | + - "renesas,rcar-gen2-cpg-clocks" for the generic R-Car Gen2 CPG | |
| 12 | + | |
| 13 | + - reg: Base address and length of the memory resource used by the CPG | |
| 14 | + | |
| 15 | + - clocks: Reference to the parent clock | |
| 16 | + - #clock-cells: Must be 1 | |
| 17 | + - clock-output-names: The names of the clocks. Supported clocks are "main", | |
| 18 | + "pll0", "pll1", "pll3", "lb", "qspi", "sdh", "sd0", "sd1" and "z" | |
| 19 | + | |
| 20 | + | |
| 21 | +Example | |
| 22 | +------- | |
| 23 | + | |
| 24 | + cpg_clocks: cpg_clocks@e6150000 { | |
| 25 | + compatible = "renesas,r8a7790-cpg-clocks", | |
| 26 | + "renesas,rcar-gen2-cpg-clocks"; | |
| 27 | + reg = <0 0xe6150000 0 0x1000>; | |
| 28 | + clocks = <&extal_clk>; | |
| 29 | + #clock-cells = <1>; | |
| 30 | + clock-output-names = "main", "pll0, "pll1", "pll3", | |
| 31 | + "lb", "qspi", "sdh", "sd0", "sd1", "z"; | |
| 32 | + }; | |
| @@ -0,0 +1,39 @@ | ||
| 1 | +Binding for Silicon Labs 570, 571, 598 and 599 programmable | |
| 2 | +I2C clock generators. | |
| 3 | + | |
| 4 | +Reference | |
| 5 | +This binding uses the common clock binding[1]. Details about the devices can be | |
| 6 | +found in the data sheets[2][3]. | |
| 7 | + | |
| 8 | +[1] Documentation/devicetree/bindings/clock/clock-bindings.txt | |
| 9 | +[2] Si570/571 Data Sheet | |
| 10 | + http://www.silabs.com/Support%20Documents/TechnicalDocs/si570.pdf | |
| 11 | +[3] Si598/599 Data Sheet | |
| 12 | + http://www.silabs.com/Support%20Documents/TechnicalDocs/si598-99.pdf | |
| 13 | + | |
| 14 | +Required properties: | |
| 15 | + - compatible: Shall be one of "silabs,si570", "silabs,si571", | |
| 16 | + "silabs,si598", "silabs,si599" | |
| 17 | + - reg: I2C device address. | |
| 18 | + - #clock-cells: From common clock bindings: Shall be 0. | |
| 19 | + - factory-fout: Factory set default frequency. This frequency is part specific. | |
| 20 | + The correct frequency for the part used has to be provided in | |
| 21 | + order to generate the correct output frequencies. For more | |
| 22 | + details, please refer to the data sheet. | |
| 23 | + - temperature-stability: Temperature stability of the device in PPM. Should be | |
| 24 | + one of: 7, 20, 50 or 100. | |
| 25 | + | |
| 26 | +Optional properties: | |
| 27 | + - clock-output-names: From common clock bindings. Recommended to be "si570". | |
| 28 | + - clock-frequency: Output frequency to generate. This defines the output | |
| 29 | + frequency set during boot. It can be reprogrammed during | |
| 30 | + runtime through the common clock framework. | |
| 31 | + | |
| 32 | +Example: | |
| 33 | + si570: clock-generator@5d { | |
| 34 | + #clock-cells = <0>; | |
| 35 | + compatible = "silabs,si570"; | |
| 36 | + temperature-stability = <50>; | |
| 37 | + reg = <0x5d>; | |
| 38 | + factory-fout = <156250000>; | |
| 39 | + }; | |
| @@ -7,8 +7,10 @@ This binding uses the common clock binding[1]. · 6 unmodified lines | ||
| 7 | 7 | Required properties: |
| 8 | 8 | - compatible : shall be one of the following: |
| 9 | 9 | "allwinner,sun4i-osc-clk" - for a gatable oscillator |
| 10 | − "allwinner,sun4i-pll1-clk" - for the main PLL clock | |
| 10 | + "allwinner,sun4i-pll1-clk" - for the main PLL clock and PLL4 | |
| 11 | 11 | "allwinner,sun6i-a31-pll1-clk" - for the main PLL clock on A31 |
| 12 | + "allwinner,sun4i-pll5-clk" - for the PLL5 clock | |
| 13 | + "allwinner,sun4i-pll6-clk" - for the PLL6 clock | |
| 12 | 14 | "allwinner,sun4i-cpu-clk" - for the CPU multiplexer clock |
| 13 | 15 | "allwinner,sun4i-axi-clk" - for the AXI clock |
| 14 | 16 | "allwinner,sun4i-axi-gates-clk" - for the AXI gates |
| @@ -33,10 +35,14 @@ Required properties: · 18 unmodified lines | ||
| 33 | 35 | "allwinner,sun7i-a20-apb1-gates-clk" - for the APB1 gates on A20 |
| 34 | 36 | "allwinner,sun6i-a31-apb2-div-clk" - for the APB2 gates on A31 |
| 35 | 37 | "allwinner,sun6i-a31-apb2-gates-clk" - for the APB2 gates on A31 |
| 38 | + "allwinner,sun4i-mod0-clk" - for the module 0 family of clocks | |
| 39 | + "allwinner,sun7i-a20-out-clk" - for the external output clocks | |
| 36 | 40 | |
| 37 | 41 | Required properties for all clocks: |
| 38 | 42 | - reg : shall be the control register address for the clock. |
| 39 | −- clocks : shall be the input parent clock(s) phandle for the clock | |
| 43 | +- clocks : shall be the input parent clock(s) phandle for the clock. For | |
| 44 | + multiplexed clocks, the list order must match the hardware | |
| 45 | + programming order. | |
| 40 | 46 | - #clock-cells : from common clock binding; shall be set to 0 except for |
| 41 | 47 | "allwinner,*-gates-clk" where it shall be set to 1 |
| 42 | 48 | |
| @@ -0,0 +1,31 @@ | ||
| 1 | +Binding for Texas Instruments APLL clock. | |
| 2 | + | |
| 3 | +Binding status: Unstable - ABI compatibility may be broken in the future | |
| 4 | + | |
| 5 | +This binding uses the common clock binding[1]. It assumes a | |
| 6 | +register-mapped APLL with usually two selectable input clocks | |
| 7 | +(reference clock and bypass clock), with analog phase locked | |
| 8 | +loop logic for multiplying the input clock to a desired output | |
| 9 | +clock. This clock also typically supports different operation | |
| 10 | +modes (locked, low power stop etc.) APLL mostly behaves like | |
| 11 | +a subtype of a DPLL [2], although a simplified one at that. | |
| 12 | + | |
| 13 | +[1] Documentation/devicetree/bindings/clock/clock-bindings.txt | |
| 14 | +[2] Documentation/devicetree/bindings/clock/ti/dpll.txt | |
| 15 | + | |
| 16 | +Required properties: | |
| 17 | +- compatible : shall be "ti,dra7-apll-clock" | |
| 18 | +- #clock-cells : from common clock binding; shall be set to 0. | |
| 19 | +- clocks : link phandles of parent clocks (clk-ref and clk-bypass) | |
| 20 | +- reg : address and length of the register set for controlling the APLL. | |
| 21 | + It contains the information of registers in the following order: | |
| 22 | + "control" - contains the control register base address | |
| 23 | + "idlest" - contains the idlest register base address | |
| 24 | + | |
| 25 | +Examples: | |
| 26 | + apll_pcie_ck: apll_pcie_ck@4a008200 { | |
| 27 | + #clock-cells = <0>; | |
| 28 | + clocks = <&apll_pcie_in_clk_mux>, <&dpll_pcie_ref_ck>; | |
| 29 | + reg = <0x4a00821c 0x4>, <0x4a008220 0x4>; | |
| 30 | + compatible = "ti,dra7-apll-clock"; | |
| 31 | + }; | |
| @@ -0,0 +1,39 @@ | ||
| 1 | +Binding for Texas Instruments autoidle clock. | |
| 2 | + | |
| 3 | +Binding status: Unstable - ABI compatibility may be broken in the future | |
| 4 | + | |
| 5 | +This binding uses the common clock binding[1]. It assumes a register mapped | |
| 6 | +clock which can be put to idle automatically by hardware based on the usage | |
| 7 | +and a configuration bit setting. Autoidle clock is never an individual | |
| 8 | +clock, it is always a derivative of some basic clock like a gate, divider, | |
| 9 | +or fixed-factor. | |
| 10 | + | |
| 11 | +[1] Documentation/devicetree/bindings/clock/clock-bindings.txt | |
| 12 | + | |
| 13 | +Required properties: | |
| 14 | +- reg : offset for the register controlling the autoidle | |
| 15 | +- ti,autoidle-shift : bit shift of the autoidle enable bit | |
| 16 | +- ti,invert-autoidle-bit : autoidle is enabled by setting the bit to 0 | |
| 17 | + | |
| 18 | +Examples: | |
| 19 | + dpll_core_m4_ck: dpll_core_m4_ck { | |
| 20 | + #clock-cells = <0>; | |
| 21 | + compatible = "ti,divider-clock"; | |
| 22 | + clocks = <&dpll_core_x2_ck>; | |
| 23 | + ti,max-div = <31>; | |
| 24 | + ti,autoidle-shift = <8>; | |
| 25 | + reg = <0x2d38>; | |
| 26 | + ti,index-starts-at-one; | |
| 27 | + ti,invert-autoidle-bit; | |
| 28 | + }; | |
| 29 | + | |
| 30 | + dpll_usb_clkdcoldo_ck: dpll_usb_clkdcoldo_ck { | |
| 31 | + #clock-cells = <0>; | |
| 32 | + compatible = "ti,fixed-factor-clock"; | |
| 33 | + clocks = <&dpll_usb_ck>; | |
| 34 | + ti,clock-div = <1>; | |
| 35 | + ti,autoidle-shift = <8>; | |
| 36 | + reg = <0x01b4>; | |
| 37 | + ti,clock-mult = <1>; | |
| 38 | + ti,invert-autoidle-bit; | |
| 39 | + }; | |
| @@ -0,0 +1,24 @@ | ||
| 1 | +Binding for Texas Instruments clockdomain. | |
| 2 | + | |
| 3 | +Binding status: Unstable - ABI compatibility may be broken in the future | |
| 4 | + | |
| 5 | +This binding uses the common clock binding[1] in consumer role. | |
| 6 | +Every clock on TI SoC belongs to one clockdomain, but software | |
| 7 | +only needs this information for specific clocks which require | |
| 8 | +their parent clockdomain to be controlled when the clock is | |
| 9 | +enabled/disabled. This binding doesn't define a new clock | |
| 10 | +binding type, it is used to group existing clock nodes under | |
| 11 | +hardware hierarchy. | |
| 12 | + | |
| 13 | +[1] Documentation/devicetree/bindings/clock/clock-bindings.txt | |
| 14 | + | |
| 15 | +Required properties: | |
| 16 | +- compatible : shall be "ti,clockdomain" | |
| 17 | +- #clock-cells : from common clock binding; shall be set to 0. | |
| 18 | +- clocks : link phandles of clocks within this domain | |
| 19 | + | |
| 20 | +Examples: | |
| 21 | + dss_clkdm: dss_clkdm { | |
| 22 | + compatible = "ti,clockdomain"; | |
| 23 | + clocks = <&dss1_alwon_fck_3430es2>, <&dss_ick_3430es2>; | |
| 24 | + }; | |
| @@ -0,0 +1,54 @@ | ||
| 1 | +Binding for TI composite clock. | |
| 2 | + | |
| 3 | +Binding status: Unstable - ABI compatibility may be broken in the future | |
| 4 | + | |
| 5 | +This binding uses the common clock binding[1]. It assumes a | |
| 6 | +register-mapped composite clock with multiple different sub-types; | |
| 7 | + | |
| 8 | +a multiplexer clock with multiple input clock signals or parents, one | |
| 9 | +of which can be selected as output, this behaves exactly as [2] | |
| 10 | + | |
| 11 | +an adjustable clock rate divider, this behaves exactly as [3] | |
| 12 | + | |
| 13 | +a gating function which can be used to enable and disable the output | |
| 14 | +clock, this behaves exactly as [4] | |
| 15 | + | |
| 16 | +The binding must provide a list of the component clocks that shall be | |
| 17 | +merged to this clock. The component clocks shall be of one of the | |
| 18 | +"ti,*composite*-clock" types. | |
| 19 | + | |
| 20 | +[1] Documentation/devicetree/bindings/clock/clock-bindings.txt | |
| 21 | +[2] Documentation/devicetree/bindings/clock/ti/mux.txt | |
| 22 | +[3] Documentation/devicetree/bindings/clock/ti/divider.txt | |
| 23 | +[4] Documentation/devicetree/bindings/clock/ti/gate.txt | |
| 24 | + | |
| 25 | +Required properties: | |
| 26 | +- compatible : shall be: "ti,composite-clock" | |
| 27 | +- clocks : link phandles of component clocks | |
| 28 | +- #clock-cells : from common clock binding; shall be set to 0. | |
| 29 | + | |
| 30 | +Examples: | |
| 31 | + | |
| 32 | +usb_l4_gate_ick: usb_l4_gate_ick { | |
| 33 | + #clock-cells = <0>; | |
| 34 | + compatible = "ti,composite-interface-clock"; | |
| 35 | + clocks = <&l4_ick>; | |
| 36 | + ti,bit-shift = <5>; | |
| 37 | + reg = <0x0a10>; | |
| 38 | +}; | |
| 39 | + | |
| 40 | +usb_l4_div_ick: usb_l4_div_ick { | |
| 41 | + #clock-cells = <0>; | |
| 42 | + compatible = "ti,composite-divider-clock"; | |
| 43 | + clocks = <&l4_ick>; | |
| 44 | + ti,bit-shift = <4>; | |
| 45 | + ti,max-div = <1>; | |
| 46 | + reg = <0x0a40>; | |
| 47 | + ti,index-starts-at-one; | |
| 48 | +}; | |
| 49 | + | |
| 50 | +usb_l4_ick: usb_l4_ick { | |
| 51 | + #clock-cells = <0>; | |
| 52 | + compatible = "ti,composite-clock"; | |
| 53 | + clocks = <&usb_l4_gate_ick>, <&usb_l4_div_ick>; | |
| 54 | +}; | |
| @@ -0,0 +1,114 @@ | ||
| 1 | +Binding for TI divider clock | |
| 2 | + | |
| 3 | +Binding status: Unstable - ABI compatibility may be broken in the future | |
| 4 | + | |
| 5 | +This binding uses the common clock binding[1]. It assumes a | |
| 6 | +register-mapped adjustable clock rate divider that does not gate and has | |
| 7 | +only one input clock or parent. By default the value programmed into | |
| 8 | +the register is one less than the actual divisor value. E.g: | |
| 9 | + | |
| 10 | +register value actual divisor value | |
| 11 | +0 1 | |
| 12 | +1 2 | |
| 13 | +2 3 | |
| 14 | + | |
| 15 | +This assumption may be modified by the following optional properties: | |
| 16 | + | |
| 17 | +ti,index-starts-at-one - valid divisor values start at 1, not the default | |
| 18 | +of 0. E.g: | |
| 19 | +register value actual divisor value | |
| 20 | +1 1 | |
| 21 | +2 2 | |
| 22 | +3 3 | |
| 23 | + | |
| 24 | +ti,index-power-of-two - valid divisor values are powers of two. E.g: | |
| 25 | +register value actual divisor value | |
| 26 | +0 1 | |
| 27 | +1 2 | |
| 28 | +2 4 | |
| 29 | + | |
| 30 | +Additionally an array of valid dividers may be supplied like so: | |
| 31 | + | |
| 32 | + ti,dividers = <4>, <8>, <0>, <16>; | |
| 33 | + | |
| 34 | +Which will map the resulting values to a divisor table by their index: | |
| 35 | +register value actual divisor value | |
| 36 | +0 4 | |
| 37 | +1 8 | |
| 38 | +2 <invalid divisor, skipped> | |
| 39 | +3 16 | |
| 40 | + | |
| 41 | +Any zero value in this array means the corresponding bit-value is invalid | |
| 42 | +and must not be used. | |
| 43 | + | |
| 44 | +The binding must also provide the register to control the divider and | |
| 45 | +unless the divider array is provided, min and max dividers. Optionally | |
| 46 | +the number of bits to shift that mask, if necessary. If the shift value | |
| 47 | +is missing it is the same as supplying a zero shift. | |
| 48 | + | |
| 49 | +This binding can also optionally provide support to the hardware autoidle | |
| 50 | +feature, see [2]. | |
| 51 | + | |
| 52 | +[1] Documentation/devicetree/bindings/clock/clock-bindings.txt | |
| 53 | +[2] Documentation/devicetree/bindings/clock/ti/autoidle.txt | |
| 54 | + | |
| 55 | +Required properties: | |
| 56 | +- compatible : shall be "ti,divider-clock" or "ti,composite-divider-clock". | |
| 57 | +- #clock-cells : from common clock binding; shall be set to 0. | |
| 58 | +- clocks : link to phandle of parent clock | |
| 59 | +- reg : offset for register controlling adjustable divider | |
| 60 | + | |
| 61 | +Optional properties: | |
| 62 | +- clock-output-names : from common clock binding. | |
| 63 | +- ti,dividers : array of integers defining divisors | |
| 64 | +- ti,bit-shift : number of bits to shift the divider value, defaults to 0 | |
| 65 | +- ti,min-div : min divisor for dividing the input clock rate, only | |
| 66 | + needed if the first divisor is offset from the default value (1) | |
| 67 | +- ti,max-div : max divisor for dividing the input clock rate, only needed | |
| 68 | + if ti,dividers is not defined. | |
| 69 | +- ti,index-starts-at-one : valid divisor programming starts at 1, not zero, | |
| 70 | + only valid if ti,dividers is not defined. | |
| 71 | +- ti,index-power-of-two : valid divisor programming must be a power of two, | |
| 72 | + only valid if ti,dividers is not defined. | |
| 73 | +- ti,autoidle-shift : bit shift of the autoidle enable bit for the clock, | |
| 74 | + see [2] | |
| 75 | +- ti,invert-autoidle-bit : autoidle is enabled by setting the bit to 0, | |
| 76 | + see [2] | |
| 77 | +- ti,set-rate-parent : clk_set_rate is propagated to parent | |
| 78 | + | |
| 79 | +Examples: | |
| 80 | +dpll_usb_m2_ck: dpll_usb_m2_ck@4a008190 { | |
| 81 | + #clock-cells = <0>; | |
| 82 | + compatible = "ti,divider-clock"; | |
| 83 | + clocks = <&dpll_usb_ck>; | |
| 84 | + ti,max-div = <127>; | |
| 85 | + reg = <0x190>; | |
| 86 | + ti,index-starts-at-one; | |
| 87 | +}; | |
| 88 | + | |
| 89 | +aess_fclk: aess_fclk@4a004528 { | |
| 90 | + #clock-cells = <0>; | |
| 91 | + compatible = "ti,divider-clock"; | |
| 92 | + clocks = <&abe_clk>; | |
| 93 | + ti,bit-shift = <24>; | |
| 94 | + reg = <0x528>; | |
| 95 | + ti,max-div = <2>; | |
| 96 | +}; | |
| 97 | + | |
| 98 | +dpll_core_m3x2_div_ck: dpll_core_m3x2_div_ck { | |
| 99 | + #clock-cells = <0>; | |
| 100 | + compatible = "ti,composite-divider-clock"; | |
| 101 | + clocks = <&dpll_core_x2_ck>; | |
| 102 | + ti,max-div = <31>; | |
| 103 | + reg = <0x0134>; | |
| 104 | + ti,index-starts-at-one; | |
| 105 | +}; | |
| 106 | + | |
| 107 | +ssi_ssr_div_fck_3430es2: ssi_ssr_div_fck_3430es2 { | |
| 108 | + #clock-cells = <0>; | |
| 109 | + compatible = "ti,composite-divider-clock"; | |
| 110 | + clocks = <&corex2_fck>; | |
| 111 | + ti,bit-shift = <8>; | |
| 112 | + reg = <0x0a40>; | |
| 113 | + ti,dividers = <0>, <1>, <2>, <3>, <4>, <0>, <6>, <0>, <8>; | |
| 114 | +}; | |
| @@ -0,0 +1,75 @@ | ||
| 1 | +Binding for Texas Instruments DPLL clock. | |
| 2 | + | |
| 3 | +Binding status: Unstable - ABI compatibility may be broken in the future | |
| 4 | + | |
| 5 | +This binding uses the common clock binding[1]. It assumes a | |
| 6 | +register-mapped DPLL with usually two selectable input clocks | |
| 7 | +(reference clock and bypass clock), with digital phase locked | |
| 8 | +loop logic for multiplying the input clock to a desired output | |
| 9 | +clock. This clock also typically supports different operation | |
| 10 | +modes (locked, low power stop etc.) This binding has several | |
| 11 | +sub-types, which effectively result in slightly different setup | |
| 12 | +for the actual DPLL clock. | |
| 13 | + | |
| 14 | +[1] Documentation/devicetree/bindings/clock/clock-bindings.txt | |
| 15 | + | |
| 16 | +Required properties: | |
| 17 | +- compatible : shall be one of: | |
| 18 | + "ti,omap3-dpll-clock", | |
| 19 | + "ti,omap3-dpll-core-clock", | |
| 20 | + "ti,omap3-dpll-per-clock", | |
| 21 | + "ti,omap3-dpll-per-j-type-clock", | |
| 22 | + "ti,omap4-dpll-clock", | |
| 23 | + "ti,omap4-dpll-x2-clock", | |
| 24 | + "ti,omap4-dpll-core-clock", | |
| 25 | + "ti,omap4-dpll-m4xen-clock", | |
| 26 | + "ti,omap4-dpll-j-type-clock", | |
| 27 | + "ti,am3-dpll-no-gate-clock", | |
| 28 | + "ti,am3-dpll-j-type-clock", | |
| 29 | + "ti,am3-dpll-no-gate-j-type-clock", | |
| 30 | + "ti,am3-dpll-clock", | |
| 31 | + "ti,am3-dpll-core-clock", | |
| 32 | + "ti,am3-dpll-x2-clock", | |
| 33 | + | |
| 34 | +- #clock-cells : from common clock binding; shall be set to 0. | |
| 35 | +- clocks : link phandles of parent clocks, first entry lists reference clock | |
| 36 | + and second entry bypass clock | |
| 37 | +- reg : offsets for the register set for controlling the DPLL. | |
| 38 | + Registers are listed in following order: | |
| 39 | + "control" - contains the control register base address | |
| 40 | + "idlest" - contains the idle status register base address | |
| 41 | + "mult-div1" - contains the multiplier / divider register base address | |
| 42 | + "autoidle" - contains the autoidle register base address (optional) | |
| 43 | + ti,am3-* dpll types do not have autoidle register | |
| 44 | + | |
| 45 | +Optional properties: | |
| 46 | +- DPLL mode setting - defining any one or more of the following overrides | |
| 47 | + default setting. | |
| 48 | + - ti,low-power-stop : DPLL supports low power stop mode, gating output | |
| 49 | + - ti,low-power-bypass : DPLL output matches rate of parent bypass clock | |
| 50 | + - ti,lock : DPLL locks in programmed rate | |
| 51 | + | |
| 52 | +Examples: | |
| 53 | + dpll_core_ck: dpll_core_ck@44e00490 { | |
| 54 | + #clock-cells = <0>; | |
| 55 | + compatible = "ti,omap4-dpll-core-clock"; | |
| 56 | + clocks = <&sys_clkin_ck>, <&sys_clkin_ck>; | |
| 57 | + reg = <0x490>, <0x45c>, <0x488>, <0x468>; | |
| 58 | + }; | |
| 59 | + | |
| 60 | + dpll2_ck: dpll2_ck@48004004 { | |
| 61 | + #clock-cells = <0>; | |
| 62 | + compatible = "ti,omap3-dpll-clock"; | |
| 63 | + clocks = <&sys_ck>, <&dpll2_fck>; | |
| 64 | + ti,low-power-stop; | |
| 65 | + ti,low-power-bypass; | |
| 66 | + ti,lock; | |
| 67 | + reg = <0x4>, <0x24>, <0x34>, <0x40>; | |
| 68 | + }; | |
| 69 | + | |
| 70 | + dpll_core_ck: dpll_core_ck@44e00490 { | |
| 71 | + #clock-cells = <0>; | |
| 72 | + compatible = "ti,am3-dpll-core-clock"; | |
| 73 | + clocks = <&sys_clkin_ck>, <&sys_clkin_ck>; | |
| 74 | + reg = <0x90>, <0x5c>, <0x68>; | |
| 75 | + }; | |
| @@ -0,0 +1,43 @@ | ||
| 1 | +Binding for TI fixed factor rate clock sources. | |
| 2 | + | |
| 3 | +Binding status: Unstable - ABI compatibility may be broken in the future | |
| 4 | + | |
| 5 | +This binding uses the common clock binding[1], and also uses the autoidle | |
| 6 | +support from TI autoidle clock [2]. | |
| 7 | + | |
| 8 | +[1] Documentation/devicetree/bindings/clock/clock-bindings.txt | |
| 9 | +[2] Documentation/devicetree/bindings/clock/ti/autoidle.txt | |
| 10 | + | |
| 11 | +Required properties: | |
| 12 | +- compatible : shall be "ti,fixed-factor-clock". | |
| 13 | +- #clock-cells : from common clock binding; shall be set to 0. | |
| 14 | +- ti,clock-div: fixed divider. | |
| 15 | +- ti,clock-mult: fixed multiplier. | |
| 16 | +- clocks: parent clock. | |
| 17 | + | |
| 18 | +Optional properties: | |
| 19 | +- ti,autoidle-shift: bit shift of the autoidle enable bit for the clock, | |
| 20 | + see [2] | |
| 21 | +- reg: offset for the autoidle register of this clock, see [2] | |
| 22 | +- ti,invert-autoidle-bit: autoidle is enabled by setting the bit to 0, see [2] | |
| 23 | +- ti,set-rate-parent: clk_set_rate is propagated to parent | |
| 24 | + | |
| 25 | +Example: | |
| 26 | + clock { | |
| 27 | + compatible = "ti,fixed-factor-clock"; | |
| 28 | + clocks = <&parentclk>; | |
| 29 | + #clock-cells = <0>; | |
| 30 | + ti,clock-div = <2>; | |
| 31 | + ti,clock-mult = <1>; | |
| 32 | + }; | |
| 33 | + | |
| 34 | + dpll_usb_clkdcoldo_ck: dpll_usb_clkdcoldo_ck { | |
| 35 | + #clock-cells = <0>; | |
| 36 | + compatible = "ti,fixed-factor-clock"; | |
| 37 | + clocks = <&dpll_usb_ck>; | |
| 38 | + ti,clock-div = <1>; | |
| 39 | + ti,autoidle-shift = <8>; | |
| 40 | + reg = <0x01b4>; | |
| 41 | + ti,clock-mult = <1>; | |
| 42 | + ti,invert-autoidle-bit; | |
| 43 | + }; | |
| @@ -0,0 +1,85 @@ | ||
| 1 | +Binding for Texas Instruments gate clock. | |
| 2 | + | |
| 3 | +Binding status: Unstable - ABI compatibility may be broken in the future | |
| 4 | + | |
| 5 | +This binding uses the common clock binding[1]. This clock is | |
| 6 | +quite much similar to the basic gate-clock [2], however, | |
| 7 | +it supports a number of additional features. If no register | |
| 8 | +is provided for this clock, the code assumes that a clockdomain | |
| 9 | +will be controlled instead and the corresponding hw-ops for | |
| 10 | +that is used. | |
| 11 | + | |
| 12 | +[1] Documentation/devicetree/bindings/clock/clock-bindings.txt | |
| 13 | +[2] Documentation/devicetree/bindings/clock/gate-clock.txt | |
| 14 | +[3] Documentation/devicetree/bindings/clock/ti/clockdomain.txt | |
| 15 | + | |
| 16 | +Required properties: | |
| 17 | +- compatible : shall be one of: | |
| 18 | + "ti,gate-clock" - basic gate clock | |
| 19 | + "ti,wait-gate-clock" - gate clock which waits until clock is active before | |
| 20 | + returning from clk_enable() | |
| 21 | + "ti,dss-gate-clock" - gate clock with DSS specific hardware handling | |
| 22 | + "ti,am35xx-gate-clock" - gate clock with AM35xx specific hardware handling | |
| 23 | + "ti,clkdm-gate-clock" - clockdomain gate clock, which derives its functional | |
| 24 | + clock directly from a clockdomain, see [3] how | |
| 25 | + to map clockdomains properly | |
| 26 | + "ti,hsdiv-gate-clock" - gate clock with OMAP36xx specific hardware handling, | |
| 27 | + required for a hardware errata | |
| 28 | +- #clock-cells : from common clock binding; shall be set to 0 | |
| 29 | +- clocks : link to phandle of parent clock | |
| 30 | +- reg : offset for register controlling adjustable gate, not needed for | |
| 31 | + ti,clkdm-gate-clock type | |
| 32 | + | |
| 33 | +Optional properties: | |
| 34 | +- ti,bit-shift : bit shift for programming the clock gate, invalid for | |
| 35 | + ti,clkdm-gate-clock type | |
| 36 | +- ti,set-bit-to-disable : inverts default gate programming. Setting the bit | |
| 37 | + gates the clock and clearing the bit ungates the clock. | |
| 38 | + | |
| 39 | +Examples: | |
| 40 | + mmchs2_fck: mmchs2_fck@48004a00 { | |
| 41 | + #clock-cells = <0>; | |
| 42 | + compatible = "ti,gate-clock"; | |
| 43 | + clocks = <&core_96m_fck>; | |
| 44 | + reg = <0x48004a00 0x4>; | |
| 45 | + ti,bit-shift = <25>; | |
| 46 | + }; | |
| 47 | + | |
| 48 | + uart4_fck_am35xx: uart4_fck_am35xx { | |
| 49 | + #clock-cells = <0>; | |
| 50 | + compatible = "ti,wait-gate-clock"; | |
| 51 | + clocks = <&core_48m_fck>; | |
| 52 | + reg = <0x0a00>; | |
| 53 | + ti,bit-shift = <23>; | |
| 54 | + }; | |
| 55 | + | |
| 56 | + dss1_alwon_fck_3430es2: dss1_alwon_fck_3430es2@48004e00 { | |
| 57 | + #clock-cells = <0>; | |
| 58 | + compatible = "ti,dss-gate-clock"; | |
| 59 | + clocks = <&dpll4_m4x2_ck>; | |
| 60 | + reg = <0x48004e00 0x4>; | |
| 61 | + ti,bit-shift = <0>; | |
| 62 | + }; | |
| 63 | + | |
| 64 | + emac_ick: emac_ick@4800259c { | |
| 65 | + #clock-cells = <0>; | |
| 66 | + compatible = "ti,am35xx-gate-clock"; | |
| 67 | + clocks = <&ipss_ick>; | |
| 68 | + reg = <0x4800259c 0x4>; | |
| 69 | + ti,bit-shift = <1>; | |
| 70 | + }; | |
| 71 | + | |
| 72 | + emu_src_ck: emu_src_ck { | |
| 73 | + #clock-cells = <0>; | |
| 74 | + compatible = "ti,clkdm-gate-clock"; | |
| 75 | + clocks = <&emu_src_mux_ck>; | |
| 76 | + }; | |
| 77 | + | |
| 78 | + dpll4_m2x2_ck: dpll4_m2x2_ck@48004d00 { | |
| 79 | + #clock-cells = <0>; | |
| 80 | + compatible = "ti,hsdiv-gate-clock"; | |
| 81 | + clocks = <&dpll4_m2x2_mul_ck>; | |
| 82 | + ti,bit-shift = <0x1b>; | |
| 83 | + reg = <0x48004d00 0x4>; | |
| 84 | + ti,set-bit-to-disable; | |
| 85 | + }; | |
| @@ -0,0 +1,54 @@ | ||
| 1 | +Binding for Texas Instruments interface clock. | |
| 2 | + | |
| 3 | +Binding status: Unstable - ABI compatibility may be broken in the future | |
| 4 | + | |
| 5 | +This binding uses the common clock binding[1]. This clock is | |
| 6 | +quite much similar to the basic gate-clock [2], however, | |
| 7 | +it supports a number of additional features, including | |
| 8 | +companion clock finding (match corresponding functional gate | |
| 9 | +clock) and hardware autoidle enable / disable. | |
| 10 | + | |
| 11 | +[1] Documentation/devicetree/bindings/clock/clock-bindings.txt | |
| 12 | +[2] Documentation/devicetree/bindings/clock/gate-clock.txt | |
| 13 | + | |
| 14 | +Required properties: | |
| 15 | +- compatible : shall be one of: | |
| 16 | + "ti,omap3-interface-clock" - basic OMAP3 interface clock | |
| 17 | + "ti,omap3-no-wait-interface-clock" - interface clock which has no hardware | |
| 18 | + capability for waiting clock to be ready | |
| 19 | + "ti,omap3-hsotgusb-interface-clock" - interface clock with USB specific HW | |
| 20 | + handling | |
| 21 | + "ti,omap3-dss-interface-clock" - interface clock with DSS specific HW handling | |
| 22 | + "ti,omap3-ssi-interface-clock" - interface clock with SSI specific HW handling | |
| 23 | + "ti,am35xx-interface-clock" - interface clock with AM35xx specific HW handling | |
| 24 | +- #clock-cells : from common clock binding; shall be set to 0 | |
| 25 | +- clocks : link to phandle of parent clock | |
| 26 | +- reg : base address for the control register | |
| 27 | + | |
| 28 | +Optional properties: | |
| 29 | +- ti,bit-shift : bit shift for the bit enabling/disabling the clock (default 0) | |
| 30 | + | |
| 31 | +Examples: | |
| 32 | + aes1_ick: aes1_ick@48004a14 { | |
| 33 | + #clock-cells = <0>; | |
| 34 | + compatible = "ti,omap3-interface-clock"; | |
| 35 | + clocks = <&security_l4_ick2>; | |
| 36 | + reg = <0x48004a14 0x4>; | |
| 37 | + ti,bit-shift = <3>; | |
| 38 | + }; | |
| 39 | + | |
| 40 | + cam_ick: cam_ick@48004f10 { | |
| 41 | + #clock-cells = <0>; | |
| 42 | + compatible = "ti,omap3-no-wait-interface-clock"; | |
| 43 | + clocks = <&l4_ick>; | |
| 44 | + reg = <0x48004f10 0x4>; | |
| 45 | + ti,bit-shift = <0>; | |
| 46 | + }; | |
| 47 | + | |
| 48 | + ssi_ick_3430es2: ssi_ick_3430es2@48004a10 { | |
| 49 | + #clock-cells = <0>; | |
| 50 | + compatible = "ti,omap3-ssi-interface-clock"; | |
| 51 | + clocks = <&ssi_l4_ick>; | |
| 52 | + reg = <0x48004a10 0x4>; | |
| 53 | + ti,bit-shift = <0>; | |
| 54 | + }; | |
| @@ -0,0 +1,76 @@ | ||
| 1 | +Binding for TI mux clock. | |
| 2 | + | |
| 3 | +Binding status: Unstable - ABI compatibility may be broken in the future | |
| 4 | + | |
| 5 | +This binding uses the common clock binding[1]. It assumes a | |
| 6 | +register-mapped multiplexer with multiple input clock signals or | |
| 7 | +parents, one of which can be selected as output. This clock does not | |
| 8 | +gate or adjust the parent rate via a divider or multiplier. | |
| 9 | + | |
| 10 | +By default the "clocks" property lists the parents in the same order | |
| 11 | +as they are programmed into the regster. E.g: | |
| 12 | + | |
| 13 | + clocks = <&foo_clock>, <&bar_clock>, <&baz_clock>; | |
| 14 | + | |
| 15 | +results in programming the register as follows: | |
| 16 | + | |
| 17 | +register value selected parent clock | |
| 18 | +0 foo_clock | |
| 19 | +1 bar_clock | |
| 20 | +2 baz_clock | |
| 21 | + | |
| 22 | +Some clock controller IPs do not allow a value of zero to be programmed | |
| 23 | +into the register, instead indexing begins at 1. The optional property | |
| 24 | +"index-starts-at-one" modified the scheme as follows: | |
| 25 | + | |
| 26 | +register value selected clock parent | |
| 27 | +1 foo_clock | |
| 28 | +2 bar_clock | |
| 29 | +3 baz_clock | |
| 30 | + | |
| 31 | +The binding must provide the register to control the mux. Optionally | |
| 32 | +the number of bits to shift the control field in the register can be | |
| 33 | +supplied. If the shift value is missing it is the same as supplying | |
| 34 | +a zero shift. | |
| 35 | + | |
| 36 | +[1] Documentation/devicetree/bindings/clock/clock-bindings.txt | |
| 37 | + | |
| 38 | +Required properties: | |
| 39 | +- compatible : shall be "ti,mux-clock" or "ti,composite-mux-clock". | |
| 40 | +- #clock-cells : from common clock binding; shall be set to 0. | |
| 41 | +- clocks : link phandles of parent clocks | |
| 42 | +- reg : register offset for register controlling adjustable mux | |
| 43 | + | |
| 44 | +Optional properties: | |
| 45 | +- ti,bit-shift : number of bits to shift the bit-mask, defaults to | |
| 46 | + 0 if not present | |
| 47 | +- ti,index-starts-at-one : valid input select programming starts at 1, not | |
| 48 | + zero | |
| 49 | +- ti,set-rate-parent : clk_set_rate is propagated to parent clock, | |
| 50 | + not supported by the composite-mux-clock subtype | |
| 51 | + | |
| 52 | +Examples: | |
| 53 | + | |
| 54 | +sys_clkin_ck: sys_clkin_ck@4a306110 { | |
| 55 | + #clock-cells = <0>; | |
| 56 | + compatible = "ti,mux-clock"; | |
| 57 | + clocks = <&virt_12000000_ck>, <&virt_13000000_ck>, <&virt_16800000_ck>, <&virt_19200000_ck>, <&virt_26000000_ck>, <&virt_27000000_ck>, <&virt_38400000_ck>; | |
| 58 | + reg = <0x0110>; | |
| 59 | + ti,index-starts-at-one; | |
| 60 | +}; | |
| 61 | + | |
| 62 | +abe_dpll_bypass_clk_mux_ck: abe_dpll_bypass_clk_mux_ck@4a306108 { | |
| 63 | + #clock-cells = <0>; | |
| 64 | + compatible = "ti,mux-clock"; | |
| 65 | + clocks = <&sys_clkin_ck>, <&sys_32k_ck>; | |
| 66 | + ti,bit-shift = <24>; | |
| 67 | + reg = <0x0108>; | |
| 68 | +}; | |
| 69 | + | |
| 70 | +mcbsp5_mux_fck: mcbsp5_mux_fck { | |
| 71 | + #clock-cells = <0>; | |
| 72 | + compatible = "ti,composite-mux-clock"; | |
| 73 | + clocks = <&core_96m_fck>, <&mcbsp_clks>; | |
| 74 | + ti,bit-shift = <4>; | |
| 75 | + reg = <0x02d8>; | |
| 76 | +}; | |
| @@ -22,6 +22,10 @@ Required properties: · 21 unmodified lines | ||
| 22 | 22 | Optional properties: |
| 23 | 23 | - clocks : as described in the clock bindings |
| 24 | 24 | - clock-names : as described in the clock bindings |
| 25 | + - fclk-enable : Bit mask to enable FCLKs statically at boot time. | |
| 26 | + Bit [0..3] correspond to FCLK0..FCLK3. The corresponding | |
| 27 | + FCLK will only be enabled if it is actually running at | |
| 28 | + boot time. | |
| 25 | 29 | |
| 26 | 30 | Clock inputs: |
| 27 | 31 | The following strings are optional parameters to the 'clock-names' property in |
| @@ -15,6 +15,10 @@ Optional properties: · 14 unmodified lines | ||
| 15 | 15 | - clock-latency: Specify the possible maximum transition latency for clock, |
| 16 | 16 | in unit of nanoseconds. |
| 17 | 17 | - voltage-tolerance: Specify the CPU voltage tolerance in percentage. |
| 18 | +- #cooling-cells: | |
| 19 | +- cooling-min-level: | |
| 20 | +- cooling-max-level: | |
| 21 | + Please refer to Documentation/devicetree/bindings/thermal/thermal.txt. | |
| 18 | 22 | |
| 19 | 23 | Examples: |
| 20 | 24 | |
| @@ -33,6 +37,9 @@ cpus { · 12 unmodified lines | ||
| 33 | 37 | 198000 850000 |
| 34 | 38 | >; |
| 35 | 39 | clock-latency = <61036>; /* two CLK32 periods */ |
| 40 | + #cooling-cells = <2>; | |
| 41 | + cooling-min-level = <0>; | |
| 42 | + cooling-max-level = <2>; | |
| 36 | 43 | }; |
| 37 | 44 | |
| 38 | 45 | cpu@1 { |
| @@ -0,0 +1,68 @@ | ||
| 1 | +* Atmel HW cryptographic accelerators | |
| 2 | + | |
| 3 | +These are the HW cryptographic accelerators found on some Atmel products. | |
| 4 | + | |
| 5 | +* Advanced Encryption Standard (AES) | |
| 6 | + | |
| 7 | +Required properties: | |
| 8 | +- compatible : Should be "atmel,at91sam9g46-aes". | |
| 9 | +- reg: Should contain AES registers location and length. | |
| 10 | +- interrupts: Should contain the IRQ line for the AES. | |
| 11 | +- dmas: List of two DMA specifiers as described in | |
| 12 | + atmel-dma.txt and dma.txt files. | |
| 13 | +- dma-names: Contains one identifier string for each DMA specifier | |
| 14 | + in the dmas property. | |
| 15 | + | |
| 16 | +Example: | |
| 17 | +aes@f8038000 { | |
| 18 | + compatible = "atmel,at91sam9g46-aes"; | |
| 19 | + reg = <0xf8038000 0x100>; | |
| 20 | + interrupts = <43 4 0>; | |
| 21 | + dmas = <&dma1 2 18>, | |
| 22 | + <&dma1 2 19>; | |
| 23 | + dma-names = "tx", "rx"; | |
| 24 | + | |
| 25 | +* Triple Data Encryption Standard (Triple DES) | |
| 26 | + | |
| 27 | +Required properties: | |
| 28 | +- compatible : Should be "atmel,at91sam9g46-tdes". | |
| 29 | +- reg: Should contain TDES registers location and length. | |
| 30 | +- interrupts: Should contain the IRQ line for the TDES. | |
| 31 | + | |
| 32 | +Optional properties: | |
| 33 | +- dmas: List of two DMA specifiers as described in | |
| 34 | + atmel-dma.txt and dma.txt files. | |
| 35 | +- dma-names: Contains one identifier string for each DMA specifier | |
| 36 | + in the dmas property. | |
| 37 | + | |
| 38 | +Example: | |
| 39 | +tdes@f803c000 { | |
| 40 | + compatible = "atmel,at91sam9g46-tdes"; | |
| 41 | + reg = <0xf803c000 0x100>; | |
| 42 | + interrupts = <44 4 0>; | |
| 43 | + dmas = <&dma1 2 20>, | |
| 44 | + <&dma1 2 21>; | |
| 45 | + dma-names = "tx", "rx"; | |
| 46 | +}; | |
| 47 | + | |
| 48 | +* Secure Hash Algorithm (SHA) | |
| 49 | + | |
| 50 | +Required properties: | |
| 51 | +- compatible : Should be "atmel,at91sam9g46-sha". | |
| 52 | +- reg: Should contain SHA registers location and length. | |
| 53 | +- interrupts: Should contain the IRQ line for the SHA. | |
| 54 | + | |
| 55 | +Optional properties: | |
| 56 | +- dmas: One DMA specifiers as described in | |
| 57 | + atmel-dma.txt and dma.txt files. | |
| 58 | +- dma-names: Contains one identifier string for each DMA specifier | |
| 59 | + in the dmas property. Only one "tx" string needed. | |
| 60 | + | |
| 61 | +Example: | |
| 62 | +sha@f8034000 { | |
| 63 | + compatible = "atmel,at91sam9g46-sha"; | |
| 64 | + reg = <0xf8034000 0x100>; | |
| 65 | + interrupts = <42 4 0>; | |
| 66 | + dmas = <&dma1 2 17>; | |
| 67 | + dma-names = "tx"; | |
| 68 | +}; | |
| @@ -0,0 +1,17 @@ | ||
| 1 | +Freescale DCP (Data Co-Processor) found on i.MX23/i.MX28 . | |
| 2 | + | |
| 3 | +Required properties: | |
| 4 | +- compatible : Should be "fsl,<soc>-dcp" | |
| 5 | +- reg : Should contain MXS DCP registers location and length | |
| 6 | +- interrupts : Should contain MXS DCP interrupt numbers, VMI IRQ and DCP IRQ | |
| 7 | + must be supplied, optionally Secure IRQ can be present, but | |
| 8 | + is currently not implemented and not used. | |
| 9 | + | |
| 10 | +Example: | |
| 11 | + | |
| 12 | +dcp@80028000 { | |
| 13 | + compatible = "fsl,imx28-dcp", "fsl,imx23-dcp"; | |
| 14 | + reg = <0x80028000 0x2000>; | |
| 15 | + interrupts = <52 53>; | |
| 16 | + status = "okay"; | |
| 17 | +}; | |
| @@ -0,0 +1,57 @@ | ||
| 1 | +* BCM2835 DMA controller | |
| 2 | + | |
| 3 | +The BCM2835 DMA controller has 16 channels in total. | |
| 4 | +Only the lower 13 channels have an associated IRQ. | |
| 5 | +Some arbitrary channels are used by the firmware | |
| 6 | +(1,3,6,7 in the current firmware version). | |
| 7 | +The channels 0,2 and 3 have special functionality | |
| 8 | +and should not be used by the driver. | |
| 9 | + | |
| 10 | +Required properties: | |
| 11 | +- compatible: Should be "brcm,bcm2835-dma". | |
| 12 | +- reg: Should contain DMA registers location and length. | |
| 13 | +- interrupts: Should contain the DMA interrupts associated | |
| 14 | + to the DMA channels in ascending order. | |
| 15 | +- #dma-cells: Must be <1>, the cell in the dmas property of the | |
| 16 | + client device represents the DREQ number. | |
| 17 | +- brcm,dma-channel-mask: Bit mask representing the channels | |
| 18 | + not used by the firmware in ascending order, | |
| 19 | + i.e. first channel corresponds to LSB. | |
| 20 | + | |
| 21 | +Example: | |
| 22 | + | |
| 23 | +dma: dma@7e007000 { | |
| 24 | + compatible = "brcm,bcm2835-dma"; | |
| 25 | + reg = <0x7e007000 0xf00>; | |
| 26 | + interrupts = <1 16>, | |
| 27 | + <1 17>, | |
| 28 | + <1 18>, | |
| 29 | + <1 19>, | |
| 30 | + <1 20>, | |
| 31 | + <1 21>, | |
| 32 | + <1 22>, | |
| 33 | + <1 23>, | |
| 34 | + <1 24>, | |
| 35 | + <1 25>, | |
| 36 | + <1 26>, | |
| 37 | + <1 27>, | |
| 38 | + <1 28>; | |
| 39 | + | |
| 40 | + #dma-cells = <1>; | |
| 41 | + brcm,dma-channel-mask = <0x7f35>; | |
| 42 | +}; | |
| 43 | + | |
| 44 | +DMA clients connected to the BCM2835 DMA controller must use the format | |
| 45 | +described in the dma.txt file, using a two-cell specifier for each channel. | |
| 46 | + | |
| 47 | +Example: | |
| 48 | + | |
| 49 | +bcm2835_i2s: i2s@7e203000 { | |
| 50 | + compatible = "brcm,bcm2835-i2s"; | |
| 51 | + reg = < 0x7e203000 0x20>, | |
| 52 | + < 0x7e101098 0x02>; | |
| 53 | + | |
| 54 | + dmas = <&dma 2>, | |
| 55 | + <&dma 3>; | |
| 56 | + dma-names = "tx", "rx"; | |
| 57 | +}; | |
| @@ -42,6 +42,7 @@ The full ID of peripheral types can be found below. · 41 unmodified lines | ||
| 42 | 42 | 19 IPU Memory |
| 43 | 43 | 20 ASRC |
| 44 | 44 | 21 ESAI |
| 45 | + 22 SSI Dual FIFO (needs firmware ver >= 2) | |
| 45 | 46 | |
| 46 | 47 | The third cell specifies the transfer priority as below. |
| 47 | 48 | |
| @@ -0,0 +1,45 @@ | ||
| 1 | +MOXA ART DMA Controller | |
| 2 | + | |
| 3 | +See dma.txt first | |
| 4 | + | |
| 5 | +Required properties: | |
| 6 | + | |
| 7 | +- compatible : Must be "moxa,moxart-dma" | |
| 8 | +- reg : Should contain registers location and length | |
| 9 | +- interrupts : Should contain an interrupt-specifier for the sole | |
| 10 | + interrupt generated by the device | |
| 11 | +- #dma-cells : Should be 1, a single cell holding a line request number | |
| 12 | + | |
| 13 | +Example: | |
| 14 | + | |
| 15 | + dma: dma@90500000 { | |
| 16 | + compatible = "moxa,moxart-dma"; | |
| 17 | + reg = <0x90500080 0x40>; | |
| 18 | + interrupts = <24 0>; | |
| 19 | + #dma-cells = <1>; | |
| 20 | + }; | |
| 21 | + | |
| 22 | + | |
| 23 | +Clients: | |
| 24 | + | |
| 25 | +DMA clients connected to the MOXA ART DMA controller must use the format | |
| 26 | +described in the dma.txt file, using a two-cell specifier for each channel: | |
| 27 | +a phandle plus one integer cells. | |
| 28 | +The two cells in order are: | |
| 29 | + | |
| 30 | +1. A phandle pointing to the DMA controller. | |
| 31 | +2. Peripheral identifier for the hardware handshaking interface. | |
| 32 | + | |
| 33 | +Example: | |
| 34 | +Use specific request line passing from dma | |
| 35 | +For example, MMC request line is 5 | |
| 36 | + | |
| 37 | + sdhci: sdhci@98e00000 { | |
| 38 | + compatible = "moxa,moxart-sdhci"; | |
| 39 | + reg = <0x98e00000 0x5C>; | |
| 40 | + interrupts = <5 0>; | |
| 41 | + clocks = <&clk_apb>; | |
| 42 | + dmas = <&dma 5>, | |
| 43 | + <&dma 5>; | |
| 44 | + dma-names = "tx", "rx"; | |
| 45 | + }; | |
| @@ -50,6 +50,9 @@ Each dmas request consists of 4 cells: · 49 unmodified lines | ||
| 50 | 50 | 0x00000008: Use fixed channel: |
| 51 | 51 | Use automatic channel selection when unset |
| 52 | 52 | Use DMA request line number when set |
| 53 | + 0x00000010: Set channel as high priority: | |
| 54 | + Normal priority when unset | |
| 55 | + High priority when set | |
| 53 | 56 | |
| 54 | 57 | Example: |
| 55 | 58 | |
| @@ -5,6 +5,16 @@ Required properties: · 4 unmodified lines | ||
| 5 | 5 | - reg: Should contain DMA registers location and length. This shuld include |
| 6 | 6 | all of the per-channel registers. |
| 7 | 7 | - interrupts: Should contain all of the per-channel DMA interrupts. |
| 8 | +- clocks: Must contain one entry, for the module clock. | |
| 9 | + See ../clocks/clock-bindings.txt for details. | |
| 10 | +- resets : Must contain an entry for each entry in reset-names. | |
| 11 | + See ../reset/reset.txt for details. | |
| 12 | +- reset-names : Must include the following entries: | |
| 13 | + - dma | |
| 14 | +- #dma-cells : Must be <1>. This dictates the length of DMA specifiers in | |
| 15 | + client nodes' dmas properties. The specifier represents the DMA request | |
| 16 | + select value for the peripheral. For more details, consult the Tegra TRM's | |
| 17 | + documentation of the APB DMA channel control register REQ_SEL field. | |
| 8 | 18 | |
| 9 | 19 | Examples: |
| 10 | 20 | |
| @@ -27,4 +37,8 @@ apbdma: dma@6000a000 { · 16 unmodified lines | ||
| 27 | 37 | 0 149 0x04 |
| 28 | 38 | 0 150 0x04 |
| 29 | 39 | 0 151 0x04 >; |
| 40 | + clocks = <&tegra_car 34>; | |
| 41 | + resets = <&tegra_car 34>; | |
| 42 | + reset-names = "dma"; | |
| 43 | + #dma-cells = <1>; | |
| 30 | 44 | }; |
| @@ -2,7 +2,11 @@ EXTCON FOR PALMAS/TWL CHIPS · 1 unmodified line | ||
| 2 | 2 | |
| 3 | 3 | PALMAS USB COMPARATOR |
| 4 | 4 | Required Properties: |
| 5 | − - compatible : Should be "ti,palmas-usb" or "ti,twl6035-usb" | |
| 5 | + - compatible: should contain one of: | |
| 6 | + * "ti,palmas-usb-vid". | |
| 7 | + * "ti,twl6035-usb-vid". | |
| 8 | + * "ti,palmas-usb" (DEPRECATED - use "ti,palmas-usb-vid"). | |
| 9 | + * "ti,twl6035-usb" (DEPRECATED - use "ti,twl6035-usb-vid"). | |
| 6 | 10 | |
| 7 | 11 | Optional Properties: |
| 8 | 12 | - ti,wakeup : To enable the wakeup comparator in probe |
| @@ -0,0 +1,41 @@ | ||
| 1 | +Davinci GPIO controller bindings | |
| 2 | + | |
| 3 | +Required Properties: | |
| 4 | +- compatible: should be "ti,dm6441-gpio" | |
| 5 | + | |
| 6 | +- reg: Physical base address of the controller and the size of memory mapped | |
| 7 | + registers. | |
| 8 | + | |
| 9 | +- gpio-controller : Marks the device node as a gpio controller. | |
| 10 | + | |
| 11 | +- interrupt-parent: phandle of the parent interrupt controller. | |
| 12 | + | |
| 13 | +- interrupts: Array of GPIO interrupt number. Only banked or unbanked IRQs are | |
| 14 | + supported at a time. | |
| 15 | + | |
| 16 | +- ti,ngpio: The number of GPIO pins supported. | |
| 17 | + | |
| 18 | +- ti,davinci-gpio-unbanked: The number of GPIOs that have an individual interrupt | |
| 19 | + line to processor. | |
| 20 | + | |
| 21 | +The GPIO controller also acts as an interrupt controller. It uses the default | |
| 22 | +two cells specifier as described in Documentation/devicetree/bindings/ | |
| 23 | +interrupt-controller/interrupts.txt. | |
| 24 | + | |
| 25 | +Example: | |
| 26 | + | |
| 27 | +gpio: gpio@1e26000 { | |
| 28 | + compatible = "ti,dm6441-gpio"; | |
| 29 | + gpio-controller; | |
| 30 | + reg = <0x226000 0x1000>; | |
| 31 | + interrupt-parent = <&intc>; | |
| 32 | + interrupts = <42 IRQ_TYPE_EDGE_BOTH 43 IRQ_TYPE_EDGE_BOTH | |
| 33 | + 44 IRQ_TYPE_EDGE_BOTH 45 IRQ_TYPE_EDGE_BOTH | |
| 34 | + 46 IRQ_TYPE_EDGE_BOTH 47 IRQ_TYPE_EDGE_BOTH | |
| 35 | + 48 IRQ_TYPE_EDGE_BOTH 49 IRQ_TYPE_EDGE_BOTH | |
| 36 | + 50 IRQ_TYPE_EDGE_BOTH>; | |
| 37 | + ti,ngpio = <144>; | |
| 38 | + ti,davinci-gpio-unbanked = <0>; | |
| 39 | + interrupt-controller; | |
| 40 | + #interrupt-cells = <2>; | |
| 41 | +}; | |
| @@ -0,0 +1,37 @@ | ||
| 1 | +TI/National Semiconductor LP3943 GPIO controller | |
| 2 | + | |
| 3 | +Required properties: | |
| 4 | + - compatible: "ti,lp3943-gpio" | |
| 5 | + - gpio-controller: Marks the device node as a GPIO controller. | |
| 6 | + - #gpio-cells: Should be 2. See gpio.txt in this directory for a | |
| 7 | + description of the cells format. | |
| 8 | + | |
| 9 | +Example: | |
| 10 | +Simple LED controls with LP3943 GPIO controller | |
| 11 | + | |
| 12 | +&i2c4 { | |
| 13 | + lp3943@60 { | |
| 14 | + compatible = "ti,lp3943"; | |
| 15 | + reg = <0x60>; | |
| 16 | + | |
| 17 | + gpioex: gpio { | |
| 18 | + compatible = "ti,lp3943-gpio"; | |
| 19 | + gpio-controller; | |
| 20 | + #gpio-cells = <2>; | |
| 21 | + }; | |
| 22 | + }; | |
| 23 | +}; | |
| 24 | + | |
| 25 | +leds { | |
| 26 | + compatible = "gpio-leds"; | |
| 27 | + indicator1 { | |
| 28 | + label = "indi1"; | |
| 29 | + gpios = <&gpioex 9 GPIO_ACTIVE_LOW>; | |
| 30 | + }; | |
| 31 | + | |
| 32 | + indicator2 { | |
| 33 | + label = "indi2"; | |
| 34 | + gpios = <&gpioex 10 GPIO_ACTIVE_LOW>; | |
| 35 | + default-state = "off"; | |
| 36 | + }; | |
| 37 | +}; | |
| @@ -38,12 +38,38 @@ Required device specific properties (only for SPI chips): · 37 unmodified lines | ||
| 38 | 38 | removed. |
| 39 | 39 | - spi-max-frequency = The maximum frequency this chip is able to handle |
| 40 | 40 | |
| 41 | −Example I2C: | |
| 41 | +Optional properties: | |
| 42 | +- #interrupt-cells : Should be two. | |
| 43 | + - first cell is the pin number | |
| 44 | + - second cell is used to specify flags. | |
| 45 | +- interrupt-controller: Marks the device node as a interrupt controller. | |
| 46 | +NOTE: The interrupt functionality is only supported for i2c versions of the | |
| 47 | +chips. The spi chips can also do the interrupts, but this is not supported by | |
| 48 | +the linux driver yet. | |
| 49 | + | |
| 50 | +Optional device specific properties: | |
| 51 | +- microchip,irq-mirror: Sets the mirror flag in the IOCON register. Devices | |
| 52 | + with two interrupt outputs (these are the devices ending with 17 and | |
| 53 | + those that have 16 IOs) have two IO banks: IO 0-7 form bank 1 and | |
| 54 | + IO 8-15 are bank 2. These chips have two different interrupt outputs: | |
| 55 | + One for bank 1 and another for bank 2. If irq-mirror is set, both | |
| 56 | + interrupts are generated regardless of the bank that an input change | |
| 57 | + occured on. If it is not set, the interrupt are only generated for the | |
| 58 | + bank they belong to. | |
| 59 | + On devices with only one interrupt output this property is useless. | |
| 60 | + | |
| 61 | +Example I2C (with interrupt): | |
| 42 | 62 | gpiom1: gpio@20 { |
| 43 | 63 | compatible = "microchip,mcp23017"; |
| 44 | 64 | gpio-controller; |
| 45 | 65 | #gpio-cells = <2>; |
| 46 | 66 | reg = <0x20>; |
| 67 | + | |
| 68 | + interrupt-parent = <&gpio1>; | |
| 69 | + interrupts = <17 IRQ_TYPE_LEVEL_LOW>; | |
| 70 | + interrupt-controller; | |
| 71 | + #interrupt-cells=<2>; | |
| 72 | + microchip,irq-mirror; | |
| 47 | 73 | }; |
| 48 | 74 | |
| 49 | 75 | Example SPI: |
| @@ -0,0 +1,19 @@ | ||
| 1 | +MOXA ART GPIO Controller | |
| 2 | + | |
| 3 | +Required properties: | |
| 4 | + | |
| 5 | +- #gpio-cells : Should be 2, The first cell is the pin number, | |
| 6 | + the second cell is used to specify polarity: | |
| 7 | + 0 = active high | |
| 8 | + 1 = active low | |
| 9 | +- compatible : Must be "moxa,moxart-gpio" | |
| 10 | +- reg : Should contain registers location and length | |
| 11 | + | |
| 12 | +Example: | |
| 13 | + | |
| 14 | + gpio: gpio@98700000 { | |
| 15 | + gpio-controller; | |
| 16 | + #gpio-cells = <2>; | |
| 17 | + compatible = "moxa,moxart-gpio"; | |
| 18 | + reg = <0x98700000 0xC>; | |
| 19 | + }; | |
| @@ -2,10 +2,11 @@ · 1 unmodified line | ||
| 2 | 2 | |
| 3 | 3 | Required Properties: |
| 4 | 4 | |
| 5 | − - compatible: should be one of the following. | |
| 5 | + - compatible: should contain one of the following. | |
| 6 | 6 | - "renesas,gpio-r8a7778": for R8A7778 (R-Mobile M1) compatible GPIO controller. |
| 7 | 7 | - "renesas,gpio-r8a7779": for R8A7779 (R-Car H1) compatible GPIO controller. |
| 8 | 8 | - "renesas,gpio-r8a7790": for R8A7790 (R-Car H2) compatible GPIO controller. |
| 9 | + - "renesas,gpio-r8a7791": for R8A7791 (R-Car M2) compatible GPIO controller. | |
| 9 | 10 | - "renesas,gpio-rcar": for generic R-Car GPIO controller. |
| 10 | 11 | |
| 11 | 12 | - reg: Base address and length of each memory resource used by the GPIO |
| @@ -9,6 +9,12 @@ Required properties: · 8 unmodified lines | ||
| 9 | 9 | - #size-cells: The number of cells used to represent the size of an address |
| 10 | 10 | range in the host1x address space. Should be 1. |
| 11 | 11 | - ranges: The mapping of the host1x address space to the CPU address space. |
| 12 | +- clocks: Must contain one entry, for the module clock. | |
| 13 | + See ../clocks/clock-bindings.txt for details. | |
| 14 | +- resets: Must contain an entry for each entry in reset-names. | |
| 15 | + See ../reset/reset.txt for details. | |
| 16 | +- reset-names: Must include the following entries: | |
| 17 | + - host1x | |
| 12 | 18 | |
| 13 | 19 | The host1x top-level node defines a number of children, each representing one |
| 14 | 20 | of the following host1x client modules: |
| @@ -19,6 +25,12 @@ of the following host1x client modules: · 4 unmodified lines | ||
| 19 | 25 | - compatible: "nvidia,tegra<chip>-mpe" |
| 20 | 26 | - reg: Physical base address and length of the controller's registers. |
| 21 | 27 | - interrupts: The interrupt outputs from the controller. |
| 28 | + - clocks: Must contain one entry, for the module clock. | |
| 29 | + See ../clocks/clock-bindings.txt for details. | |
| 30 | + - resets: Must contain an entry for each entry in reset-names. | |
| 31 | + See ../reset/reset.txt for details. | |
| 32 | + - reset-names: Must include the following entries: | |
| 33 | + - mpe | |
| 22 | 34 | |
| 23 | 35 | - vi: video input |
| 24 | 36 | |
| @@ -26,6 +38,12 @@ of the following host1x client modules: · 1 unmodified line | ||
| 26 | 38 | - compatible: "nvidia,tegra<chip>-vi" |
| 27 | 39 | - reg: Physical base address and length of the controller's registers. |
| 28 | 40 | - interrupts: The interrupt outputs from the controller. |
| 41 | + - clocks: Must contain one entry, for the module clock. | |
| 42 | + See ../clocks/clock-bindings.txt for details. | |
| 43 | + - resets: Must contain an entry for each entry in reset-names. | |
| 44 | + See ../reset/reset.txt for details. | |
| 45 | + - reset-names: Must include the following entries: | |
| 46 | + - vi | |
| 29 | 47 | |
| 30 | 48 | - epp: encoder pre-processor |
| 31 | 49 | |
| @@ -33,6 +51,12 @@ of the following host1x client modules: · 1 unmodified line | ||
| 33 | 51 | - compatible: "nvidia,tegra<chip>-epp" |
| 34 | 52 | - reg: Physical base address and length of the controller's registers. |
| 35 | 53 | - interrupts: The interrupt outputs from the controller. |
| 54 | + - clocks: Must contain one entry, for the module clock. | |
| 55 | + See ../clocks/clock-bindings.txt for details. | |
| 56 | + - resets: Must contain an entry for each entry in reset-names. | |
| 57 | + See ../reset/reset.txt for details. | |
| 58 | + - reset-names: Must include the following entries: | |
| 59 | + - epp | |
| 36 | 60 | |
| 37 | 61 | - isp: image signal processor |
| 38 | 62 | |
| @@ -40,6 +64,12 @@ of the following host1x client modules: · 1 unmodified line | ||
| 40 | 64 | - compatible: "nvidia,tegra<chip>-isp" |
| 41 | 65 | - reg: Physical base address and length of the controller's registers. |
| 42 | 66 | - interrupts: The interrupt outputs from the controller. |
| 67 | + - clocks: Must contain one entry, for the module clock. | |
| 68 | + See ../clocks/clock-bindings.txt for details. | |
| 69 | + - resets: Must contain an entry for each entry in reset-names. | |
| 70 | + See ../reset/reset.txt for details. | |
| 71 | + - reset-names: Must include the following entries: | |
| 72 | + - isp | |
| 43 | 73 | |
| 44 | 74 | - gr2d: 2D graphics engine |
| 45 | 75 | |
| @@ -47,12 +77,30 @@ of the following host1x client modules: · 1 unmodified line | ||
| 47 | 77 | - compatible: "nvidia,tegra<chip>-gr2d" |
| 48 | 78 | - reg: Physical base address and length of the controller's registers. |
| 49 | 79 | - interrupts: The interrupt outputs from the controller. |
| 80 | + - clocks: Must contain one entry, for the module clock. | |
| 81 | + See ../clocks/clock-bindings.txt for details. | |
| 82 | + - resets: Must contain an entry for each entry in reset-names. | |
| 83 | + See ../reset/reset.txt for details. | |
| 84 | + - reset-names: Must include the following entries: | |
| 85 | + - 2d | |
| 50 | 86 | |
| 51 | 87 | - gr3d: 3D graphics engine |
| 52 | 88 | |
| 53 | 89 | Required properties: |
| 54 | 90 | - compatible: "nvidia,tegra<chip>-gr3d" |
| 55 | 91 | - reg: Physical base address and length of the controller's registers. |
| 92 | + - clocks: Must contain an entry for each entry in clock-names. | |
| 93 | + See ../clocks/clock-bindings.txt for details. | |
| 94 | + - clock-names: Must include the following entries: | |
| 95 | + (This property may be omitted if the only clock in the list is "3d") | |
| 96 | + - 3d | |
| 97 | + This MUST be the first entry. | |
| 98 | + - 3d2 (Only required on SoCs with two 3D clocks) | |
| 99 | + - resets: Must contain an entry for each entry in reset-names. | |
| 100 | + See ../reset/reset.txt for details. | |
| 101 | + - reset-names: Must include the following entries: | |
| 102 | + - 3d | |
| 103 | + - 3d2 (Only required on SoCs with two 3D clocks) | |
| 56 | 104 | |
| 57 | 105 | - dc: display controller |
| 58 | 106 | |
| @@ -60,6 +108,19 @@ of the following host1x client modules: · 1 unmodified line | ||
| 60 | 108 | - compatible: "nvidia,tegra<chip>-dc" |
| 61 | 109 | - reg: Physical base address and length of the controller's registers. |
| 62 | 110 | - interrupts: The interrupt outputs from the controller. |
| 111 | + - clocks: Must contain an entry for each entry in clock-names. | |
| 112 | + See ../clocks/clock-bindings.txt for details. | |
| 113 | + - clock-names: Must include the following entries: | |
| 114 | + - dc | |
| 115 | + This MUST be the first entry. | |
| 116 | + - parent | |
| 117 | + - resets: Must contain an entry for each entry in reset-names. | |
| 118 | + See ../reset/reset.txt for details. | |
| 119 | + - reset-names: Must include the following entries: | |
| 120 | + - dc | |
| 121 | + - nvidia,head: The number of the display controller head. This is used to | |
| 122 | + setup the various types of output to receive video data from the given | |
| 123 | + head. | |
| 63 | 124 | |
| 64 | 125 | Each display controller node has a child node, named "rgb", that represents |
| 65 | 126 | the RGB output associated with the controller. It can take the following |
| @@ -67,6 +128,7 @@ of the following host1x client modules: · 1 unmodified line | ||
| 67 | 128 | - nvidia,ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing |
| 68 | 129 | - nvidia,hpd-gpio: specifies a GPIO used for hotplug detection |
| 69 | 130 | - nvidia,edid: supplies a binary EDID blob |
| 131 | + - nvidia,panel: phandle of a display panel | |
| 70 | 132 | |
| 71 | 133 | - hdmi: High Definition Multimedia Interface |
| 72 | 134 | |
| @@ -76,11 +138,22 @@ of the following host1x client modules: · 3 unmodified lines | ||
| 76 | 138 | - interrupts: The interrupt outputs from the controller. |
| 77 | 139 | - vdd-supply: regulator for supply voltage |
| 78 | 140 | - pll-supply: regulator for PLL |
| 141 | + - clocks: Must contain an entry for each entry in clock-names. | |
| 142 | + See ../clocks/clock-bindings.txt for details. | |
| 143 | + - clock-names: Must include the following entries: | |
| 144 | + - hdmi | |
| 145 | + This MUST be the first entry. | |
| 146 | + - parent | |
| 147 | + - resets: Must contain an entry for each entry in reset-names. | |
| 148 | + See ../reset/reset.txt for details. | |
| 149 | + - reset-names: Must include the following entries: | |
| 150 | + - hdmi | |
| 79 | 151 | |
| 80 | 152 | Optional properties: |
| 81 | 153 | - nvidia,ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing |
| 82 | 154 | - nvidia,hpd-gpio: specifies a GPIO used for hotplug detection |
| 83 | 155 | - nvidia,edid: supplies a binary EDID blob |
| 156 | + - nvidia,panel: phandle of a display panel | |
| 84 | 157 | |
| 85 | 158 | - tvo: TV encoder output |
| 86 | 159 | |
| @@ -88,12 +161,34 @@ of the following host1x client modules: · 1 unmodified line | ||
| 88 | 161 | - compatible: "nvidia,tegra<chip>-tvo" |
| 89 | 162 | - reg: Physical base address and length of the controller's registers. |
| 90 | 163 | - interrupts: The interrupt outputs from the controller. |
| 164 | + - clocks: Must contain one entry, for the module clock. | |
| 165 | + See ../clocks/clock-bindings.txt for details. | |
| 91 | 166 | |
| 92 | 167 | - dsi: display serial interface |
| 93 | 168 | |
| 94 | 169 | Required properties: |
| 95 | 170 | - compatible: "nvidia,tegra<chip>-dsi" |
| 96 | 171 | - reg: Physical base address and length of the controller's registers. |
| 172 | + - clocks: Must contain an entry for each entry in clock-names. | |
| 173 | + See ../clocks/clock-bindings.txt for details. | |
| 174 | + - clock-names: Must include the following entries: | |
| 175 | + - dsi | |
| 176 | + This MUST be the first entry. | |
| 177 | + - lp | |
| 178 | + - parent | |
| 179 | + - resets: Must contain an entry for each entry in reset-names. | |
| 180 | + See ../reset/reset.txt for details. | |
| 181 | + - reset-names: Must include the following entries: | |
| 182 | + - dsi | |
| 183 | + - nvidia,mipi-calibrate: Should contain a phandle and a specifier specifying | |
| 184 | + which pads are used by this DSI output and need to be calibrated. See also | |
| 185 | + ../mipi/nvidia,tegra114-mipi.txt. | |
| 186 | + | |
| 187 | + Optional properties: | |
| 188 | + - nvidia,ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing | |
| 189 | + - nvidia,hpd-gpio: specifies a GPIO used for hotplug detection | |
| 190 | + - nvidia,edid: supplies a binary EDID blob | |
| 191 | + - nvidia,panel: phandle of a display panel | |
| 97 | 192 | |
| 98 | 193 | Example: |
| 99 | 194 | |
| @@ -105,6 +200,9 @@ Example: · 5 unmodified lines | ||
| 105 | 200 | reg = <0x50000000 0x00024000>; |
| 106 | 201 | interrupts = <0 65 0x04 /* mpcore syncpt */ |
| 107 | 202 | 0 67 0x04>; /* mpcore general */ |
| 203 | + clocks = <&tegra_car TEGRA20_CLK_HOST1X>; | |
| 204 | + resets = <&tegra_car 28>; | |
| 205 | + reset-names = "host1x"; | |
| 108 | 206 | |
| 109 | 207 | #address-cells = <1>; |
| 110 | 208 | #size-cells = <1>; |
| @@ -115,41 +213,64 @@ Example: · 4 unmodified lines | ||
| 115 | 213 | compatible = "nvidia,tegra20-mpe"; |
| 116 | 214 | reg = <0x54040000 0x00040000>; |
| 117 | 215 | interrupts = <0 68 0x04>; |
| 216 | + clocks = <&tegra_car TEGRA20_CLK_MPE>; | |
| 217 | + resets = <&tegra_car 60>; | |
| 218 | + reset-names = "mpe"; | |
| 118 | 219 | }; |
| 119 | 220 | |
| 120 | 221 | vi { |
| 121 | 222 | compatible = "nvidia,tegra20-vi"; |
| 122 | 223 | reg = <0x54080000 0x00040000>; |
| 123 | 224 | interrupts = <0 69 0x04>; |
| 225 | + clocks = <&tegra_car TEGRA20_CLK_VI>; | |
| 226 | + resets = <&tegra_car 100>; | |
| 227 | + reset-names = "vi"; | |
| 124 | 228 | }; |
| 125 | 229 | |
| 126 | 230 | epp { |
| 127 | 231 | compatible = "nvidia,tegra20-epp"; |
| 128 | 232 | reg = <0x540c0000 0x00040000>; |
| 129 | 233 | interrupts = <0 70 0x04>; |
| 234 | + clocks = <&tegra_car TEGRA20_CLK_EPP>; | |
| 235 | + resets = <&tegra_car 19>; | |
| 236 | + reset-names = "epp"; | |
| 130 | 237 | }; |
| 131 | 238 | |
| 132 | 239 | isp { |
| 133 | 240 | compatible = "nvidia,tegra20-isp"; |
| 134 | 241 | reg = <0x54100000 0x00040000>; |
| 135 | 242 | interrupts = <0 71 0x04>; |
| 243 | + clocks = <&tegra_car TEGRA20_CLK_ISP>; | |
| 244 | + resets = <&tegra_car 23>; | |
| 245 | + reset-names = "isp"; | |
| 136 | 246 | }; |
| 137 | 247 | |
| 138 | 248 | gr2d { |
| 139 | 249 | compatible = "nvidia,tegra20-gr2d"; |
| 140 | 250 | reg = <0x54140000 0x00040000>; |
| 141 | 251 | interrupts = <0 72 0x04>; |
| 252 | + clocks = <&tegra_car TEGRA20_CLK_GR2D>; | |
| 253 | + resets = <&tegra_car 21>; | |
| 254 | + reset-names = "2d"; | |
| 142 | 255 | }; |
| 143 | 256 | |
| 144 | 257 | gr3d { |
| 145 | 258 | compatible = "nvidia,tegra20-gr3d"; |
| 146 | 259 | reg = <0x54180000 0x00040000>; |
| 260 | + clocks = <&tegra_car TEGRA20_CLK_GR3D>; | |
| 261 | + resets = <&tegra_car 24>; | |
| 262 | + reset-names = "3d"; | |
| 147 | 263 | }; |
| 148 | 264 | |
| 149 | 265 | dc@54200000 { |
| 150 | 266 | compatible = "nvidia,tegra20-dc"; |
| 151 | 267 | reg = <0x54200000 0x00040000>; |
| 152 | 268 | interrupts = <0 73 0x04>; |
| 269 | + clocks = <&tegra_car TEGRA20_CLK_DISP1>, | |
| 270 | + <&tegra_car TEGRA20_CLK_PLL_P>; | |
| 271 | + clock-names = "dc", "parent"; | |
| 272 | + resets = <&tegra_car 27>; | |
| 273 | + reset-names = "dc"; | |
| 153 | 274 | |
| 154 | 275 | rgb { |
| 155 | 276 | status = "disabled"; |
| @@ -160,6 +281,11 @@ Example: · 4 unmodified lines | ||
| 160 | 281 | compatible = "nvidia,tegra20-dc"; |
| 161 | 282 | reg = <0x54240000 0x00040000>; |
| 162 | 283 | interrupts = <0 74 0x04>; |
| 284 | + clocks = <&tegra_car TEGRA20_CLK_DISP2>, | |
| 285 | + <&tegra_car TEGRA20_CLK_PLL_P>; | |
| 286 | + clock-names = "dc", "parent"; | |
| 287 | + resets = <&tegra_car 26>; | |
| 288 | + reset-names = "dc"; | |
| 163 | 289 | |
| 164 | 290 | rgb { |
| 165 | 291 | status = "disabled"; |
| @@ -170,6 +296,11 @@ Example: · 4 unmodified lines | ||
| 170 | 296 | compatible = "nvidia,tegra20-hdmi"; |
| 171 | 297 | reg = <0x54280000 0x00040000>; |
| 172 | 298 | interrupts = <0 75 0x04>; |
| 299 | + clocks = <&tegra_car TEGRA20_CLK_HDMI>, | |
| 300 | + <&tegra_car TEGRA20_CLK_PLL_D_OUT0>; | |
| 301 | + clock-names = "hdmi", "parent"; | |
| 302 | + resets = <&tegra_car 51>; | |
| 303 | + reset-names = "hdmi"; | |
| 173 | 304 | status = "disabled"; |
| 174 | 305 | }; |
| 175 | 306 | |
| @@ -177,12 +308,18 @@ Example: · 1 unmodified line | ||
| 177 | 308 | compatible = "nvidia,tegra20-tvo"; |
| 178 | 309 | reg = <0x542c0000 0x00040000>; |
| 179 | 310 | interrupts = <0 76 0x04>; |
| 311 | + clocks = <&tegra_car TEGRA20_CLK_TVO>; | |
| 180 | 312 | status = "disabled"; |
| 181 | 313 | }; |
| 182 | 314 | |
| 183 | 315 | dsi { |
| 184 | 316 | compatible = "nvidia,tegra20-dsi"; |
| 185 | 317 | reg = <0x54300000 0x00040000>; |
| 318 | + clocks = <&tegra_car TEGRA20_CLK_DSI>, | |
| 319 | + <&tegra_car TEGRA20_CLK_PLL_D_OUT0>; | |
| 320 | + clock-names = "dsi", "parent"; | |
| 321 | + resets = <&tegra_car 48>; | |
| 322 | + reset-names = "dsi"; | |
| 186 | 323 | status = "disabled"; |
| 187 | 324 | }; |
| 188 | 325 | }; |
| @@ -9,6 +9,7 @@ Required properties : · 8 unmodified lines | ||
| 9 | 9 | - interrupts: interrupt number to the cpu. |
| 10 | 10 | - #address-cells = <1>; |
| 11 | 11 | - #size-cells = <0>; |
| 12 | +- clocks: phandles to input clocks. | |
| 12 | 13 | |
| 13 | 14 | Optional properties: |
| 14 | 15 | - Child nodes conforming to i2c bus binding |
| @@ -21,6 +22,7 @@ i2c0: i2c@fff84000 { · 6 unmodified lines | ||
| 21 | 22 | interrupts = <12 4 6>; |
| 22 | 23 | #address-cells = <1>; |
| 23 | 24 | #size-cells = <0>; |
| 25 | + clocks = <&twi0_clk>; | |
| 24 | 26 | |
| 25 | 27 | 24c512@50 { |
| 26 | 28 | compatible = "24c512"; |
| @@ -0,0 +1,50 @@ | ||
| 1 | +* NXP PCA954x I2C bus switch | |
| 2 | + | |
| 3 | +Required Properties: | |
| 4 | + | |
| 5 | + - compatible: Must contain one of the following. | |
| 6 | + "nxp,pca9540", "nxp,pca9542", "nxp,pca9543", "nxp,pca9544", | |
| 7 | + "nxp,pca9545", "nxp,pca9546", "nxp,pca9547", "nxp,pca9548" | |
| 8 | + | |
| 9 | + - reg: The I2C address of the device. | |
| 10 | + | |
| 11 | + The following required properties are defined externally: | |
| 12 | + | |
| 13 | + - Standard I2C mux properties. See i2c-mux.txt in this directory. | |
| 14 | + - I2C child bus nodes. See i2c-mux.txt in this directory. | |
| 15 | + | |
| 16 | +Optional Properties: | |
| 17 | + | |
| 18 | + - reset-gpios: Reference to the GPIO connected to the reset input. | |
| 19 | + | |
| 20 | + | |
| 21 | +Example: | |
| 22 | + | |
| 23 | + i2c-switch@74 { | |
| 24 | + compatible = "nxp,pca9548"; | |
| 25 | + #address-cells = <1>; | |
| 26 | + #size-cells = <0>; | |
| 27 | + reg = <0x74>; | |
| 28 | + | |
| 29 | + i2c@2 { | |
| 30 | + #address-cells = <1>; | |
| 31 | + #size-cells = <0>; | |
| 32 | + reg = <2>; | |
| 33 | + | |
| 34 | + eeprom@54 { | |
| 35 | + compatible = "at,24c08"; | |
| 36 | + reg = <0x54>; | |
| 37 | + }; | |
| 38 | + }; | |
| 39 | + | |
| 40 | + i2c@4 { | |
| 41 | + #address-cells = <1>; | |
| 42 | + #size-cells = <0>; | |
| 43 | + reg = <4>; | |
| 44 | + | |
| 45 | + rtc@51 { | |
| 46 | + compatible = "nxp,pcf8563"; | |
| 47 | + reg = <0x51>; | |
| 48 | + }; | |
| 49 | + }; | |
| 50 | + }; | |
| @@ -5,7 +5,11 @@ Required properties : · 4 unmodified lines | ||
| 5 | 5 | |
| 6 | 6 | - reg : Offset and length of the register set for the device |
| 7 | 7 | - compatible : Should be "marvell,mv64xxx-i2c" or "allwinner,sun4i-i2c" |
| 8 | − or "marvell,mv78230-i2c" | |
| 8 | + or "marvell,mv78230-i2c" or "marvell,mv78230-a0-i2c" | |
| 9 | + Note: Only use "marvell,mv78230-a0-i2c" for a very rare, | |
| 10 | + initial version of the SoC which had broken offload | |
| 11 | + support. Linux auto-detects this and sets it | |
| 12 | + appropriately. | |
| 9 | 13 | - interrupts : The interrupt number |
| 10 | 14 | |
| 11 | 15 | Optional properties : |
| @@ -0,0 +1,29 @@ | ||
| 1 | +Device tree configuration for Renesas RIIC driver | |
| 2 | + | |
| 3 | +Required properties: | |
| 4 | +- compatible : "renesas,riic-<soctype>". "renesas,riic-rz" as fallback | |
| 5 | +- reg : address start and address range size of device | |
| 6 | +- interrupts : 8 interrupts (TEI, RI, TI, SPI, STI, NAKI, ALI, TMOI) | |
| 7 | +- clock-frequency : frequency of bus clock in Hz | |
| 8 | +- #address-cells : should be <1> | |
| 9 | +- #size-cells : should be <0> | |
| 10 | + | |
| 11 | +Pinctrl properties might be needed, too. See there. | |
| 12 | + | |
| 13 | +Example: | |
| 14 | + | |
| 15 | + i2c0: i2c@fcfee000 { | |
| 16 | + compatible = "renesas,riic-r7s72100", "renesas,riic-rz"; | |
| 17 | + reg = <0xfcfee000 0x44>; | |
| 18 | + interrupts = <0 157 IRQ_TYPE_LEVEL_HIGH>, | |
| 19 | + <0 158 IRQ_TYPE_EDGE_RISING>, | |
| 20 | + <0 159 IRQ_TYPE_EDGE_RISING>, | |
| 21 | + <0 160 IRQ_TYPE_LEVEL_HIGH>, | |
| 22 | + <0 161 IRQ_TYPE_LEVEL_HIGH>, | |
| 23 | + <0 162 IRQ_TYPE_LEVEL_HIGH>, | |
| 24 | + <0 163 IRQ_TYPE_LEVEL_HIGH>, | |
| 25 | + <0 164 IRQ_TYPE_LEVEL_HIGH>; | |
| 26 | + clock-frequency = <100000>; | |
| 27 | + #address-cells = <1>; | |
| 28 | + #size-cells = <0>; | |
| 29 | + }; | |
| @@ -10,6 +10,8 @@ Required properties: · 9 unmodified lines | ||
| 10 | 10 | inside HDMIPHY block found on several samsung SoCs |
| 11 | 11 | (d) "samsung, exynos5440-i2c", for s3c2440-like i2c used |
| 12 | 12 | on EXYNOS5440 which does not need GPIO configuration. |
| 13 | + (e) "samsung, exynos5-sata-phy-i2c", for s3c2440-like i2c used as | |
| 14 | + a host to SATA PHY controller on an internal bus. | |
| 13 | 15 | - reg: physical base address of the controller and length of memory mapped |
| 14 | 16 | region. |
| 15 | 17 | - interrupts: interrupt number to the cpu. |
| @@ -39,12 +39,23 @@ Required properties: · 38 unmodified lines | ||
| 39 | 39 | - interrupts: Should contain I2C controller interrupts. |
| 40 | 40 | - address-cells: Address cells for I2C device address. |
| 41 | 41 | - size-cells: Size of the I2C device address. |
| 42 | −- clocks: Clock ID as per | |
| 43 | − Documentation/devicetree/bindings/clock/tegra<chip-id>.txt | |
| 44 | − for I2C controller. | |
| 45 | −- clock-names: Name of the clock: | |
| 46 | − Tegra20/Tegra30 I2C controller: "div-clk and "fast-clk". | |
| 47 | − Tegra114 I2C controller: "div-clk". | |
| 42 | +- clocks: Must contain an entry for each entry in clock-names. | |
| 43 | + See ../clocks/clock-bindings.txt for details. | |
| 44 | +- clock-names: Must include the following entries: | |
| 45 | + Tegra20/Tegra30: | |
| 46 | + - div-clk | |
| 47 | + - fast-clk | |
| 48 | + Tegra114: | |
| 49 | + - div-clk | |
| 50 | +- resets: Must contain an entry for each entry in reset-names. | |
| 51 | + See ../reset/reset.txt for details. | |
| 52 | +- reset-names: Must include the following entries: | |
| 53 | + - i2c | |
| 54 | +- dmas: Must contain an entry for each entry in clock-names. | |
| 55 | + See ../dma/dma.txt for details. | |
| 56 | +- dma-names: Must include the following entries: | |
| 57 | + - rx | |
| 58 | + - tx | |
| 48 | 59 | |
| 49 | 60 | Example: |
| 50 | 61 | |
| @@ -56,5 +67,9 @@ Example: · 5 unmodified lines | ||
| 56 | 67 | #size-cells = <0>; |
| 57 | 68 | clocks = <&tegra_car 12>, <&tegra_car 124>; |
| 58 | 69 | clock-names = "div-clk", "fast-clk"; |
| 70 | + resets = <&tegra_car 12>; | |
| 71 | + reset-names = "i2c"; | |
| 72 | + dmas = <&apbdma 16>, <&apbdma 16>; | |
| 73 | + dma-names = "rx", "tx"; | |
| 59 | 74 | status = "disabled"; |
| 60 | 75 | }; |
| @@ -16,6 +16,7 @@ adt7461 +/-1C TDM Extended Temp Range I.C · 15 unmodified lines | ||
| 16 | 16 | at,24c08 i2c serial eeprom (24cxx) |
| 17 | 17 | atmel,24c02 i2c serial eeprom (24cxx) |
| 18 | 18 | atmel,at97sc3204t i2c trusted platform module (TPM) |
| 19 | +capella,cm32181 CM32181: Ambient Light Sensor | |
| 19 | 20 | catalyst,24c32 i2c serial eeprom |
| 20 | 21 | dallas,ds1307 64 x 8, Serial, I2C Real-Time Clock |
| 21 | 22 | dallas,ds1338 I2C RTC with 56-Byte NV RAM |
| @@ -39,6 +40,7 @@ fsl,sgtl5000 SGTL5000: Ultra Low-Power Audio Codec · 17 unmodified lines | ||
| 39 | 40 | gmt,g751 G751: Digital Temperature Sensor and Thermal Watchdog with Two-Wire Interface |
| 40 | 41 | infineon,slb9635tt Infineon SLB9635 (Soft-) I2C TPM (old protocol, max 100khz) |
| 41 | 42 | infineon,slb9645tt Infineon SLB9645 I2C TPM (new protocol, max 400khz) |
| 43 | +isl,isl12057 Intersil ISL12057 I2C RTC Chip | |
| 42 | 44 | maxim,ds1050 5 Bit Programmable, Pulse-Width Modulator |
| 43 | 45 | maxim,max1237 Low-Power, 4-/12-Channel, 2-Wire Serial, 12-Bit ADCs |
| 44 | 46 | maxim,max6625 9-Bit/12-Bit Temperature Sensors with I²C-Compatible Serial Interface |
| @@ -0,0 +1,14 @@ | ||
| 1 | +* DHT11 humidity/temperature sensor (and compatibles like DHT22) | |
| 2 | + | |
| 3 | +Required properties: | |
| 4 | + - compatible: Should be "dht11" | |
| 5 | + - gpios: Should specify the GPIO connected to the sensor's data | |
| 6 | + line, see "gpios property" in | |
| 7 | + Documentation/devicetree/bindings/gpio/gpio.txt. | |
| 8 | + | |
| 9 | +Example: | |
| 10 | + | |
| 11 | +humidity_sensor { | |
| 12 | + compatible = "dht11"; | |
| 13 | + gpios = <&gpio0 6 0>; | |
| 14 | +} | |
| @@ -0,0 +1,19 @@ | ||
| 1 | +* AMS TAOS TSL2563 ambient light sensor | |
| 2 | + | |
| 3 | +Required properties: | |
| 4 | + | |
| 5 | + - compatible : should be "amstaos,tsl2563" | |
| 6 | + - reg : the I2C address of the sensor | |
| 7 | + | |
| 8 | +Optional properties: | |
| 9 | + | |
| 10 | + - amstaos,cover-comp-gain : integer used as multiplier for gain | |
| 11 | + compensation (default = 1) | |
| 12 | + | |
| 13 | +Example: | |
| 14 | + | |
| 15 | +tsl2563@29 { | |
| 16 | + compatible = "amstaos,tsl2563"; | |
| 17 | + reg = <0x29>; | |
| 18 | + amstaos,cover-comp-gain = <16>; | |
| 19 | +}; | |
| @@ -0,0 +1,17 @@ | ||
| 1 | +* Honeywell HMC5843 magnetometer sensor | |
| 2 | + | |
| 3 | +Required properties: | |
| 4 | + | |
| 5 | + - compatible : should be "honeywell,hmc5843" | |
| 6 | + - reg : the I2C address of the magnetometer - typically 0x1e | |
| 7 | + | |
| 8 | +Optional properties: | |
| 9 | + | |
| 10 | + - gpios : should be device tree identifier of the magnetometer DRDY pin | |
| 11 | + | |
| 12 | +Example: | |
| 13 | + | |
| 14 | +hmc5843@1e { | |
| 15 | + compatible = "honeywell,hmc5843" | |
| 16 | + reg = <0x1e>; | |
| 17 | +}; | |
| @@ -0,0 +1,13 @@ | ||
| 1 | +* GPIO beeper device tree bindings | |
| 2 | + | |
| 3 | +Register a beeper connected to GPIO pin. | |
| 4 | + | |
| 5 | +Required properties: | |
| 6 | +- compatible: Should be "gpio-beeper". | |
| 7 | +- gpios: From common gpio binding; gpio connection to beeper enable pin. | |
| 8 | + | |
| 9 | +Example: | |
| 10 | + beeper: beeper { | |
| 11 | + compatible = "gpio-beeper"; | |
| 12 | + gpios = <&gpio3 23 GPIO_ACTIVE_HIGH>; | |
| 13 | + }; | |
| @@ -13,6 +13,12 @@ Required properties: · 12 unmodified lines | ||
| 13 | 13 | array of pin numbers which is used as column. |
| 14 | 14 | - linux,keymap: The keymap for keys as described in the binding document |
| 15 | 15 | devicetree/bindings/input/matrix-keymap.txt. |
| 16 | +- clocks: Must contain one entry, for the module clock. | |
| 17 | + See ../clocks/clock-bindings.txt for details. | |
| 18 | +- resets: Must contain an entry for each entry in reset-names. | |
| 19 | + See ../reset/reset.txt for details. | |
| 20 | +- reset-names: Must include the following entries: | |
| 21 | + - kbc | |
| 16 | 22 | |
| 17 | 23 | Optional properties, in addition to those specified by the shared |
| 18 | 24 | matrix-keyboard bindings: |
| @@ -31,6 +37,9 @@ keyboard: keyboard { · 12 unmodified lines | ||
| 31 | 37 | compatible = "nvidia,tegra20-kbc"; |
| 32 | 38 | reg = <0x7000e200 0x100>; |
| 33 | 39 | interrupts = <0 85 0x04>; |
| 40 | + clocks = <&tegra_car 36>; | |
| 41 | + resets = <&tegra_car 36>; | |
| 42 | + reset-names = "kbc"; | |
| 34 | 43 | nvidia,ghost-filter; |
| 35 | 44 | nvidia,debounce-delay-ms = <640>; |
| 36 | 45 | nvidia,kbc-row-pins = <0 1 2>; /* pin 0, 1, 2 as rows */ |
| @@ -0,0 +1,41 @@ | ||
| 1 | +* Texas Instruments tsc2007 touchscreen controller | |
| 2 | + | |
| 3 | +Required properties: | |
| 4 | +- compatible: must be "ti,tsc2007". | |
| 5 | +- reg: I2C address of the chip. | |
| 6 | +- ti,x-plate-ohms: X-plate resistance in ohms. | |
| 7 | + | |
| 8 | +Optional properties: | |
| 9 | +- gpios: the interrupt gpio the chip is connected to (trough the penirq pin). | |
| 10 | + The penirq pin goes to low when the panel is touched. | |
| 11 | + (see GPIO binding[1] for more details). | |
| 12 | +- interrupt-parent: the phandle for the gpio controller | |
| 13 | + (see interrupt binding[0]). | |
| 14 | +- interrupts: (gpio) interrupt to which the chip is connected | |
| 15 | + (see interrupt binding[0]). | |
| 16 | +- ti,max-rt: maximum pressure. | |
| 17 | +- ti,fuzzx: specifies the absolute input fuzz x value. | |
| 18 | + If set, it will permit noise in the data up to +- the value given to the fuzz | |
| 19 | + parameter, that is used to filter noise from the event stream. | |
| 20 | +- ti,fuzzy: specifies the absolute input fuzz y value. | |
| 21 | +- ti,fuzzz: specifies the absolute input fuzz z value. | |
| 22 | +- ti,poll-period: how much time to wait (in milliseconds) before reading again the | |
| 23 | + values from the tsc2007. | |
| 24 | + | |
| 25 | +[0]: Documentation/devicetree/bindings/interrupt-controller/interrupts.txt | |
| 26 | +[1]: Documentation/devicetree/bindings/gpio/gpio.txt | |
| 27 | + | |
| 28 | +Example: | |
| 29 | + &i2c1 { | |
| 30 | + /* ... */ | |
| 31 | + tsc2007@49 { | |
| 32 | + compatible = "ti,tsc2007"; | |
| 33 | + reg = <0x49>; | |
| 34 | + interrupt-parent = <&gpio4>; | |
| 35 | + interrupts = <0x0 0x8>; | |
| 36 | + gpios = <&gpio4 0 0>; | |
| 37 | + ti,x-plate-ohms = <180>; | |
| 38 | + }; | |
| 39 | + | |
| 40 | + /* ... */ | |
| 41 | + }; | |
| @@ -0,0 +1,27 @@ | ||
| 1 | +* TWL4030's Keypad Controller device tree bindings | |
| 2 | + | |
| 3 | +TWL4030's Keypad controller is used to interface a SoC with a matrix-type | |
| 4 | +keypad device. The keypad controller supports multiple row and column lines. | |
| 5 | +A key can be placed at each intersection of a unique row and a unique column. | |
| 6 | +The keypad controller can sense a key-press and key-release and report the | |
| 7 | +event using a interrupt to the cpu. | |
| 8 | + | |
| 9 | +This binding is based on the matrix-keymap binding with the following | |
| 10 | +changes: | |
| 11 | + | |
| 12 | + * keypad,num-rows and keypad,num-columns are required. | |
| 13 | + | |
| 14 | +Required SoC Specific Properties: | |
| 15 | +- compatible: should be one of the following | |
| 16 | + - "ti,twl4030-keypad": For controllers compatible with twl4030 keypad | |
| 17 | + controller. | |
| 18 | +- interrupt: should be one of the following | |
| 19 | + - <1>: For controllers compatible with twl4030 keypad controller. | |
| 20 | + | |
| 21 | +Example: | |
| 22 | + twl_keypad: keypad { | |
| 23 | + compatible = "ti,twl4030-keypad"; | |
| 24 | + interrupts = <1>; | |
| 25 | + keypad,num-rows = <8>; | |
| 26 | + keypad,num-columns = <8>; | |
| 27 | + }; | |
| @@ -0,0 +1,21 @@ | ||
| 1 | +Texas Instruments TWL family (twl4030) pwrbutton module | |
| 2 | + | |
| 3 | +This module is part of the TWL4030. For more details about the whole | |
| 4 | +chip see Documentation/devicetree/bindings/mfd/twl-familly.txt. | |
| 5 | + | |
| 6 | +This module provides a simple power button event via an Interrupt. | |
| 7 | + | |
| 8 | +Required properties: | |
| 9 | +- compatible: should be one of the following | |
| 10 | + - "ti,twl4030-pwrbutton": For controllers compatible with twl4030 | |
| 11 | +- interrupts: should be one of the following | |
| 12 | + - <8>: For controllers compatible with twl4030 | |
| 13 | + | |
| 14 | +Example: | |
| 15 | + | |
| 16 | +&twl { | |
| 17 | + twl_pwrbutton: pwrbutton { | |
| 18 | + compatible = "ti,twl4030-pwrbutton"; | |
| 19 | + interrupts = <8>; | |
| 20 | + }; | |
| 21 | +}; | |
| @@ -14,5 +14,5 @@ intc: interrupt-controller { · 13 unmodified lines | ||
| 14 | 14 | compatible = "allwinner,sun4i-ic"; |
| 15 | 15 | reg = <0x01c20400 0x400>; |
| 16 | 16 | interrupt-controller; |
| 17 | − #interrupt-cells = <2>; | |
| 17 | + #interrupt-cells = <1>; | |
| 18 | 18 | }; |
| @@ -0,0 +1,32 @@ | ||
| 1 | +Synopsys DesignWare APB interrupt controller (dw_apb_ictl) | |
| 2 | + | |
| 3 | +Synopsys DesignWare provides interrupt controller IP for APB known as | |
| 4 | +dw_apb_ictl. The IP is used as secondary interrupt controller in some SoCs with | |
| 5 | +APB bus, e.g. Marvell Armada 1500. | |
| 6 | + | |
| 7 | +Required properties: | |
| 8 | +- compatible: shall be "snps,dw-apb-ictl" | |
| 9 | +- reg: physical base address of the controller and length of memory mapped | |
| 10 | + region starting with ENABLE_LOW register | |
| 11 | +- interrupt-controller: identifies the node as an interrupt controller | |
| 12 | +- #interrupt-cells: number of cells to encode an interrupt-specifier, shall be 1 | |
| 13 | +- interrupts: interrupt reference to primary interrupt controller | |
| 14 | +- interrupt-parent: (optional) reference specific primary interrupt controller | |
| 15 | + | |
| 16 | +The interrupt sources map to the corresponding bits in the interrupt | |
| 17 | +registers, i.e. | |
| 18 | +- 0 maps to bit 0 of low interrupts, | |
| 19 | +- 1 maps to bit 1 of low interrupts, | |
| 20 | +- 32 maps to bit 0 of high interrupts, | |
| 21 | +- 33 maps to bit 1 of high interrupts, | |
| 22 | +- (optional) fast interrupts start at 64. | |
| 23 | + | |
| 24 | +Example: | |
| 25 | + aic: interrupt-controller@3000 { | |
| 26 | + compatible = "snps,dw-apb-ictl"; | |
| 27 | + reg = <0x3000 0xc00>; | |
| 28 | + interrupt-controller; | |
| 29 | + #interrupt-cells = <1>; | |
| 30 | + interrupt-parent = <&gic>; | |
| 31 | + interrupts = <GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>; | |
| 32 | + }; | |
| @@ -2,6 +2,13 @@ LEDs connected to tca6507 · 1 unmodified line | ||
| 2 | 2 | |
| 3 | 3 | Required properties: |
| 4 | 4 | - compatible : should be : "ti,tca6507". |
| 5 | +- #address-cells: must be 1 | |
| 6 | +- #size-cells: must be 0 | |
| 7 | +- reg: typically 0x45. | |
| 8 | + | |
| 9 | +Optional properties: | |
| 10 | +- gpio-controller: allows lines to be used as output-only GPIOs. | |
| 11 | +- #gpio-cells: if present, must be 0. | |
| 5 | 12 | |
| 6 | 13 | Each led is represented as a sub-node of the ti,tca6507 device. |
| 7 | 14 | |
| @@ -10,6 +17,7 @@ LED sub-node properties: · 2 unmodified lines | ||
| 10 | 17 | - reg : number of LED line (could be from 0 to 6) |
| 11 | 18 | - linux,default-trigger : (optional) |
| 12 | 19 | see Documentation/devicetree/bindings/leds/common.txt |
| 20 | +- compatible: either "led" (the default) or "gpio". | |
| 13 | 21 | |
| 14 | 22 | Examples: |
| 15 | 23 | |
| @@ -19,6 +27,9 @@ tca6507@45 { · 3 unmodified lines | ||
| 19 | 27 | #size-cells = <0>; |
| 20 | 28 | reg = <0x45>; |
| 21 | 29 | |
| 30 | + gpio-controller; | |
| 31 | + #gpio-cells = <2>; | |
| 32 | + | |
| 22 | 33 | led0: red-aux@0 { |
| 23 | 34 | label = "red:aux"; |
| 24 | 35 | reg = <0x0>; |
| @@ -29,5 +40,10 @@ tca6507@45 { · 4 unmodified lines | ||
| 29 | 40 | reg = <0x5>; |
| 30 | 41 | linux,default-trigger = "default-on"; |
| 31 | 42 | }; |
| 43 | + | |
| 44 | + wifi-reset@6 { | |
| 45 | + reg = <0x6>; | |
| 46 | + compatible = "gpio"; | |
| 47 | + }; | |
| 32 | 48 | }; |
| 33 | 49 | |
| @@ -79,7 +79,6 @@ prefixed with the string "marvell,", for Marvell Technology Group Ltd. · 78 unmodified lines | ||
| 79 | 79 | Required properties: |
| 80 | 80 | - #address-cells : Should be <1> |
| 81 | 81 | - #size-cells : Should be <0> |
| 82 | − - device_type : Should be "mdio" | |
| 83 | 82 | - compatible : Should be "marvell,mv64360-mdio" |
| 84 | 83 | |
| 85 | 84 | Example: |
| @@ -87,7 +86,6 @@ prefixed with the string "marvell,", for Marvell Technology Group Ltd. · 1 unmodified line | ||
| 87 | 86 | mdio { |
| 88 | 87 | #address-cells = <1>; |
| 89 | 88 | #size-cells = <0>; |
| 90 | − device_type = "mdio"; | |
| 91 | 89 | compatible = "marvell,mv64360-mdio"; |
| 92 | 90 | |
| 93 | 91 | ethernet-phy@0 { |
| @@ -132,7 +130,6 @@ prefixed with the string "marvell,", for Marvell Technology Group Ltd. · 38 unmodified lines | ||
| 132 | 130 | Ethernet port node |
| 133 | 131 | |
| 134 | 132 | Required properties: |
| 135 | − - device_type : Should be "network". | |
| 136 | 133 | - compatible : Should be "marvell,mv64360-eth". |
| 137 | 134 | - reg : Should be <0>, <1>, or <2>, according to which registers |
| 138 | 135 | within the silicon block the device uses. |
| @@ -145,7 +142,6 @@ prefixed with the string "marvell,", for Marvell Technology Group Ltd. · 6 unmodified lines | ||
| 145 | 142 | |
| 146 | 143 | Example Discovery Ethernet port node: |
| 147 | 144 | ethernet@0 { |
| 148 | − device_type = "network"; | |
| 149 | 145 | compatible = "marvell,mv64360-eth"; |
| 150 | 146 | reg = <0>; |
| 151 | 147 | interrupts = <32>; |
| @@ -159,7 +155,6 @@ prefixed with the string "marvell,", for Marvell Technology Group Ltd. · 7 unmodified lines | ||
| 159 | 155 | c) Marvell Discovery PHY nodes |
| 160 | 156 | |
| 161 | 157 | Required properties: |
| 162 | − - device_type : Should be "ethernet-phy" | |
| 163 | 158 | - interrupts : <a> where a is the interrupt number for this phy. |
| 164 | 159 | - interrupt-parent : the phandle for the interrupt controller that |
| 165 | 160 | services interrupts for this device. |
| @@ -167,7 +162,6 @@ prefixed with the string "marvell,", for Marvell Technology Group Ltd. · 1 unmodified line | ||
| 167 | 162 | |
| 168 | 163 | Example Discovery PHY node: |
| 169 | 164 | ethernet-phy@1 { |
| 170 | − device_type = "ethernet-phy"; | |
| 171 | 165 | compatible = "broadcom,bcm5421"; |
| 172 | 166 | interrupts = <76>; /* GPP 12 */ |
| 173 | 167 | interrupt-parent = <&PIC>; |
| @@ -271,7 +265,6 @@ prefixed with the string "marvell,", for Marvell Technology Group Ltd. · 97 unmodified lines | ||
| 271 | 265 | serial port. |
| 272 | 266 | |
| 273 | 267 | Required properties: |
| 274 | − - device_type : "serial" | |
| 275 | 268 | - compatible : "marvell,mv64360-mpsc" |
| 276 | 269 | - reg : Offset and length of the register set for this device |
| 277 | 270 | - sdma : the phandle for the SDMA node used by this port |
| @@ -288,7 +281,6 @@ prefixed with the string "marvell,", for Marvell Technology Group Ltd. · 10 unmodified lines | ||
| 288 | 281 | |
| 289 | 282 | Example Discovery MPSCINTR node: |
| 290 | 283 | mpsc@8000 { |
| 291 | − device_type = "serial"; | |
| 292 | 284 | compatible = "marvell,mv64360-mpsc"; |
| 293 | 285 | reg = <0x8000 0x38>; |
| 294 | 286 | virtual-reg = <0xf1008000>; |
| @@ -0,0 +1,11 @@ | ||
| 1 | +Samsung S5P/EXYNOS SoC series JPEG codec | |
| 2 | + | |
| 3 | +Required properties: | |
| 4 | + | |
| 5 | +- compatible : should be one of: | |
| 6 | + "samsung,s5pv210-jpeg", "samsung,exynos4210-jpeg"; | |
| 7 | +- reg : address and length of the JPEG codec IP register set; | |
| 8 | +- interrupts : specifies the JPEG codec IP interrupt; | |
| 9 | +- clocks : should contain the JPEG codec IP gate clock specifier, from the | |
| 10 | + common clock bindings; | |
| 11 | +- clock-names : should contain "jpeg" entry. | |
| @@ -0,0 +1,58 @@ | ||
| 1 | +Samsung S5K5BAF UXGA 1/5" 2M CMOS Image Sensor with embedded SoC ISP | |
| 2 | +-------------------------------------------------------------------- | |
| 3 | + | |
| 4 | +Required properties: | |
| 5 | + | |
| 6 | +- compatible : "samsung,s5k5baf"; | |
| 7 | +- reg : I2C slave address of the sensor; | |
| 8 | +- vdda-supply : analog power supply 2.8V (2.6V to 3.0V); | |
| 9 | +- vddreg-supply : regulator input power supply 1.8V (1.7V to 1.9V) | |
| 10 | + or 2.8V (2.6V to 3.0); | |
| 11 | +- vddio-supply : I/O power supply 1.8V (1.65V to 1.95V) | |
| 12 | + or 2.8V (2.5V to 3.1V); | |
| 13 | +- stbyn-gpios : GPIO connected to STDBYN pin; | |
| 14 | +- rstn-gpios : GPIO connected to RSTN pin; | |
| 15 | +- clocks : list of phandle and clock specifier pairs | |
| 16 | + according to common clock bindings for the | |
| 17 | + clocks described in clock-names; | |
| 18 | +- clock-names : should include "mclk" for the sensor's master clock; | |
| 19 | + | |
| 20 | +Optional properties: | |
| 21 | + | |
| 22 | +- clock-frequency : the frequency at which the "mclk" clock should be | |
| 23 | + configured to operate, in Hz; if this property is not | |
| 24 | + specified default 24 MHz value will be used. | |
| 25 | + | |
| 26 | +The device node should contain one 'port' child node with one child 'endpoint' | |
| 27 | +node, according to the bindings defined in Documentation/devicetree/bindings/ | |
| 28 | +media/video-interfaces.txt. The following are properties specific to those | |
| 29 | +nodes. | |
| 30 | + | |
| 31 | +endpoint node | |
| 32 | +------------- | |
| 33 | + | |
| 34 | +- data-lanes : (optional) specifies MIPI CSI-2 data lanes as covered in | |
| 35 | + video-interfaces.txt. If present it should be <1> - the device | |
| 36 | + supports only one data lane without re-mapping. | |
| 37 | + | |
| 38 | +Example: | |
| 39 | + | |
| 40 | +s5k5bafx@2d { | |
| 41 | + compatible = "samsung,s5k5baf"; | |
| 42 | + reg = <0x2d>; | |
| 43 | + vdda-supply = <&cam_io_en_reg>; | |
| 44 | + vddreg-supply = <&vt_core_15v_reg>; | |
| 45 | + vddio-supply = <&vtcam_reg>; | |
| 46 | + stbyn-gpios = <&gpl2 0 1>; | |
| 47 | + rstn-gpios = <&gpl2 1 1>; | |
| 48 | + clock-names = "mclk"; | |
| 49 | + clocks = <&clock_cam 0>; | |
| 50 | + clock-frequency = <24000000>; | |
| 51 | + | |
| 52 | + port { | |
| 53 | + s5k5bafx_ep: endpoint { | |
| 54 | + remote-endpoint = <&csis1_ep>; | |
| 55 | + data-lanes = <1>; | |
| 56 | + }; | |
| 57 | + }; | |
| 58 | +}; | |
| @@ -112,6 +112,15 @@ Following are properties of regulator subnode. · 111 unmodified lines | ||
| 112 | 112 | ams,enable-tracking: Enable tracking with SD1, only supported |
| 113 | 113 | by LDO3. |
| 114 | 114 | |
| 115 | +Power-off: | |
| 116 | +========= | |
| 117 | +AS3722 supports the system power off by turning off all its rail. This | |
| 118 | +is provided through pm_power_off. | |
| 119 | +The device node should have the following properties to enable this | |
| 120 | +functionality | |
| 121 | +ams,system-power-controller: Boolean, to enable the power off functionality | |
| 122 | + through this device. | |
| 123 | + | |
| 115 | 124 | Example: |
| 116 | 125 | -------- |
| 117 | 126 | #include <dt-bindings/mfd/as3722.h> |
| @@ -120,6 +129,8 @@ ams3722 { · 2 unmodified lines | ||
| 120 | 129 | compatible = "ams,as3722"; |
| 121 | 130 | reg = <0x48>; |
| 122 | 131 | |
| 132 | + ams,system-power-controller; | |
| 133 | + | |
| 123 | 134 | interrupt-parent = <&intc>; |
| 124 | 135 | interrupt-controller; |
| 125 | 136 | #interrupt-cells = <2>; |
| @@ -17,6 +17,15 @@ Required properties (SPI): · 16 unmodified lines | ||
| 17 | 17 | - compatible: "google,cros-ec-spi" |
| 18 | 18 | - reg: SPI chip select |
| 19 | 19 | |
| 20 | +Optional properties (SPI): | |
| 21 | +- google,cros-ec-spi-msg-delay: Some implementations of the EC require some | |
| 22 | + additional processing time in order to accept new transactions. If the delay | |
| 23 | + between transactions is not long enough the EC may not be able to respond | |
| 24 | + properly to subsequent transactions and cause them to hang. This property | |
| 25 | + specifies the delay, in usecs, introduced between transactions to account | |
| 26 | + for the time required by the EC to get back into a state in which new data | |
| 27 | + can be accepted. | |
| 28 | + | |
| 20 | 29 | Required properties (LPC): |
| 21 | 30 | - compatible: "google,cros-ec-lpc" |
| 22 | 31 | - reg: List of (IO address, size) pairs defining the interface uses |
| @@ -0,0 +1,33 @@ | ||
| 1 | +TI/National Semiconductor LP3943 MFD driver | |
| 2 | + | |
| 3 | +Required properties: | |
| 4 | + - compatible: "ti,lp3943" | |
| 5 | + - reg: I2C slave address. From 0x60 to 0x67. | |
| 6 | + | |
| 7 | +LP3943 consists of two sub-devices, lp3943-gpio and lp3943-pwm. | |
| 8 | + | |
| 9 | +For the LP3943 GPIO properties please refer to: | |
| 10 | +Documentation/devicetree/bindings/gpio/gpio-lp3943.txt | |
| 11 | + | |
| 12 | +For the LP3943 PWM properties please refer to: | |
| 13 | +Documentation/devicetree/bindings/pwm/pwm-lp3943.txt | |
| 14 | + | |
| 15 | +Example: | |
| 16 | + | |
| 17 | +lp3943@60 { | |
| 18 | + compatible = "ti,lp3943"; | |
| 19 | + reg = <0x60>; | |
| 20 | + | |
| 21 | + gpioex: gpio { | |
| 22 | + compatible = "ti,lp3943-gpio"; | |
| 23 | + gpio-controller; | |
| 24 | + #gpio-cells = <2>; | |
| 25 | + }; | |
| 26 | + | |
| 27 | + pwm3943: pwm { | |
| 28 | + compatible = "ti,lp3943-pwm"; | |
| 29 | + #pwm-cells = <2>; | |
| 30 | + ti,pwm0 = <8 9 10>; | |
| 31 | + ti,pwm1 = <15>; | |
| 32 | + }; | |
| 33 | +}; | |
| @@ -7,6 +7,9 @@ different i2c slave address,presently for which we are statically creating i2c · 6 unmodified lines | ||
| 7 | 7 | client while probing.This document describes the binding for mfd device and |
| 8 | 8 | PMIC submodule. |
| 9 | 9 | |
| 10 | +Binding for the built-in 32k clock generator block is defined separately | |
| 11 | +in bindings/clk/maxim,max77686.txt file. | |
| 12 | + | |
| 10 | 13 | Required properties: |
| 11 | 14 | - compatible : Must be "maxim,max77686"; |
| 12 | 15 | - reg : Specifies the i2c slave address of PMIC block. |
| @@ -60,7 +60,7 @@ as per the datasheet of s2mps11. · 59 unmodified lines | ||
| 60 | 60 | |
| 61 | 61 | - LDOn |
| 62 | 62 | - valid values for n are 1 to 38 |
| 63 | − - Example: LDO0, LD01, LDO28 | |
| 63 | + - Example: LDO1, LD02, LDO28 | |
| 64 | 64 | - BUCKn |
| 65 | 65 | - valid values for n are 1 to 10. |
| 66 | 66 | - Example: BUCK1, BUCK2, BUCK9 |
| @@ -21,7 +21,7 @@ Required properties: · 20 unmodified lines | ||
| 21 | 21 | |
| 22 | 22 | The valid regulator-compatible values are: |
| 23 | 23 | tps65910: vrtc, vio, vdd1, vdd2, vdd3, vdig1, vdig2, vpll, vdac, vaux1, |
| 24 | − vaux2, vaux33, vmmc | |
| 24 | + vaux2, vaux33, vmmc, vbb | |
| 25 | 25 | tps65911: vrtc, vio, vdd1, vdd3, vddctrl, ldo1, ldo2, ldo3, ldo4, ldo5, |
| 26 | 26 | ldo6, ldo7, ldo8 |
| 27 | 27 | |
| @@ -38,7 +38,7 @@ Required properties: · 10 unmodified lines | ||
| 38 | 38 | vcc4-supply: VAUX1 and VAUX2 input. |
| 39 | 39 | vcc5-supply: VPLL and VDAC input. |
| 40 | 40 | vcc6-supply: VDIG1 and VDIG2 input. |
| 41 | − vcc7-supply: VRTC input. | |
| 41 | + vcc7-supply: VRTC and VBB input. | |
| 42 | 42 | vccio-supply: VIO input. |
| 43 | 43 | tps65911: |
| 44 | 44 | vcc1-supply: VDD1 input. |
| @@ -0,0 +1,98 @@ | ||
| 1 | +MIPI DSI (Display Serial Interface) busses | |
| 2 | +========================================== | |
| 3 | + | |
| 4 | +The MIPI Display Serial Interface specifies a serial bus and a protocol for | |
| 5 | +communication between a host and up to four peripherals. This document will | |
| 6 | +define the syntax used to represent a DSI bus in a device tree. | |
| 7 | + | |
| 8 | +This document describes DSI bus-specific properties only or defines existing | |
| 9 | +standard properties in the context of the DSI bus. | |
| 10 | + | |
| 11 | +Each DSI host provides a DSI bus. The DSI host controller's node contains a | |
| 12 | +set of properties that characterize the bus. Child nodes describe individual | |
| 13 | +peripherals on that bus. | |
| 14 | + | |
| 15 | +The following assumes that only a single peripheral is connected to a DSI | |
| 16 | +host. Experience shows that this is true for the large majority of setups. | |
| 17 | + | |
| 18 | +DSI host | |
| 19 | +-------- | |
| 20 | + | |
| 21 | +In addition to the standard properties and those defined by the parent bus of | |
| 22 | +a DSI host, the following properties apply to a node representing a DSI host. | |
| 23 | + | |
| 24 | +Required properties: | |
| 25 | +- #address-cells: The number of cells required to represent an address on the | |
| 26 | + bus. DSI peripherals are addressed using a 2-bit virtual channel number, so | |
| 27 | + a maximum of 4 devices can be addressed on a single bus. Hence the value of | |
| 28 | + this property should be 1. | |
| 29 | +- #size-cells: Should be 0. There are cases where it makes sense to use a | |
| 30 | + different value here. See below. | |
| 31 | + | |
| 32 | +DSI peripheral | |
| 33 | +-------------- | |
| 34 | + | |
| 35 | +Peripherals are represented as child nodes of the DSI host's node. Properties | |
| 36 | +described here apply to all DSI peripherals, but individual bindings may want | |
| 37 | +to define additional, device-specific properties. | |
| 38 | + | |
| 39 | +Required properties: | |
| 40 | +- reg: The virtual channel number of a DSI peripheral. Must be in the range | |
| 41 | + from 0 to 3. | |
| 42 | + | |
| 43 | +Some DSI peripherals respond to more than a single virtual channel. In that | |
| 44 | +case two alternative representations can be chosen: | |
| 45 | +- The reg property can take multiple entries, one for each virtual channel | |
| 46 | + that the peripheral responds to. | |
| 47 | +- If the virtual channels that a peripheral responds to are consecutive, the | |
| 48 | + #size-cells can be set to 1. The first cell of each entry in the reg | |
| 49 | + property is the number of the first virtual channel and the second cell is | |
| 50 | + the number of consecutive virtual channels. | |
| 51 | + | |
| 52 | +Example | |
| 53 | +------- | |
| 54 | + | |
| 55 | + dsi-host { | |
| 56 | + ... | |
| 57 | + | |
| 58 | + #address-cells = <1>; | |
| 59 | + #size-cells = <0>; | |
| 60 | + | |
| 61 | + /* peripheral responds to virtual channel 0 */ | |
| 62 | + peripheral@0 { | |
| 63 | + compatible = "..."; | |
| 64 | + reg = <0>; | |
| 65 | + }; | |
| 66 | + | |
| 67 | + ... | |
| 68 | + }; | |
| 69 | + | |
| 70 | + dsi-host { | |
| 71 | + ... | |
| 72 | + | |
| 73 | + #address-cells = <1>; | |
| 74 | + #size-cells = <0>; | |
| 75 | + | |
| 76 | + /* peripheral responds to virtual channels 0 and 2 */ | |
| 77 | + peripheral@0 { | |
| 78 | + compatible = "..."; | |
| 79 | + reg = <0, 2>; | |
| 80 | + }; | |
| 81 | + | |
| 82 | + ... | |
| 83 | + }; | |
| 84 | + | |
| 85 | + dsi-host { | |
| 86 | + ... | |
| 87 | + | |
| 88 | + #address-cells = <1>; | |
| 89 | + #size-cells = <1>; | |
| 90 | + | |
| 91 | + /* peripheral responds to virtual channels 1, 2 and 3 */ | |
| 92 | + peripheral@1 { | |
| 93 | + compatible = "..."; | |
| 94 | + reg = <1 3>; | |
| 95 | + }; | |
| 96 | + | |
| 97 | + ... | |
| 98 | + }; | |
| @@ -0,0 +1,41 @@ | ||
| 1 | +NVIDIA Tegra MIPI pad calibration controller | |
| 2 | + | |
| 3 | +Required properties: | |
| 4 | +- compatible: "nvidia,tegra<chip>-mipi" | |
| 5 | +- reg: Physical base address and length of the controller's registers. | |
| 6 | +- clocks: Must contain an entry for each entry in clock-names. | |
| 7 | + See ../clocks/clock-bindings.txt for details. | |
| 8 | +- clock-names: Must include the following entries: | |
| 9 | + - mipi-cal | |
| 10 | +- #nvidia,mipi-calibrate-cells: Should be 1. The cell is a bitmask of the pads | |
| 11 | + that need to be calibrated for a given device. | |
| 12 | + | |
| 13 | +User nodes need to contain an nvidia,mipi-calibrate property that has a | |
| 14 | +phandle to refer to the calibration controller node and a bitmask of the pads | |
| 15 | +that need to be calibrated. | |
| 16 | + | |
| 17 | +Example: | |
| 18 | + | |
| 19 | + mipi: mipi@700e3000 { | |
| 20 | + compatible = "nvidia,tegra114-mipi"; | |
| 21 | + reg = <0x700e3000 0x100>; | |
| 22 | + clocks = <&tegra_car TEGRA114_CLK_MIPI_CAL>; | |
| 23 | + clock-names = "mipi-cal"; | |
| 24 | + #nvidia,mipi-calibrate-cells = <1>; | |
| 25 | + }; | |
| 26 | + | |
| 27 | + ... | |
| 28 | + | |
| 29 | + host1x@50000000 { | |
| 30 | + ... | |
| 31 | + | |
| 32 | + dsi@54300000 { | |
| 33 | + ... | |
| 34 | + | |
| 35 | + nvidia,mipi-calibrate = <&mipi 0x060>; | |
| 36 | + | |
| 37 | + ... | |
| 38 | + }; | |
| 39 | + | |
| 40 | + ... | |
| 41 | + }; | |
| @@ -6,6 +6,9 @@ Required properties: · 5 unmodified lines | ||
| 6 | 6 | - atmel,at91sam9g45-ssc: support dma transfer |
| 7 | 7 | - reg: Should contain SSC registers location and length |
| 8 | 8 | - interrupts: Should contain SSC interrupt |
| 9 | +- clock-names: tuple listing input clock names. | |
| 10 | + Required elements: "pclk" | |
| 11 | +- clocks: phandles to input clocks. | |
| 9 | 12 | |
| 10 | 13 | |
| 11 | 14 | Required properties for devices compatible with "atmel,at91sam9g45-ssc": |
| @@ -20,6 +23,8 @@ ssc0: ssc@fffbc000 { · 8 unmodified lines | ||
| 20 | 23 | compatible = "atmel,at91rm9200-ssc"; |
| 21 | 24 | reg = <0xfffbc000 0x4000>; |
| 22 | 25 | interrupts = <14 4 5>; |
| 26 | + clocks = <&ssc0_clk>; | |
| 27 | + clock-names = "pclk"; | |
| 23 | 28 | }; |
| 24 | 29 | |
| 25 | 30 | - DMA transfer: |
| @@ -8,6 +8,8 @@ Optional properties: · 7 unmodified lines | ||
| 8 | 8 | - temp-measurement-period: temperature measurement period (milliseconds) |
| 9 | 9 | - default-oversampling: default oversampling value to be used at startup, |
| 10 | 10 | value range is 0-3 with rising sensitivity. |
| 11 | +- interrupt-parent: should be the phandle for the interrupt controller | |
| 12 | +- interrupts: interrupt mapping for IRQ | |
| 11 | 13 | |
| 12 | 14 | Example: |
| 13 | 15 | |
| @@ -17,4 +19,6 @@ pressure@77 { · 3 unmodified lines | ||
| 17 | 19 | chip-id = <10>; |
| 18 | 20 | temp-measurement-period = <100>; |
| 19 | 21 | default-oversampling = <2>; |
| 22 | + interrupt-parent = <&gpio0>; | |
| 23 | + interrupts = <25 IRQ_TYPE_EDGE_RISING>; | |
| 20 | 24 | }; |
| @@ -0,0 +1,27 @@ | ||
| 1 | +Device Tree Bindings for the Arasan SDHCI Controller | |
| 2 | + | |
| 3 | + The bindings follow the mmc[1], clock[2] and interrupt[3] bindings. Only | |
| 4 | + deviations are documented here. | |
| 5 | + | |
| 6 | + [1] Documentation/devicetree/bindings/mmc/mmc.txt | |
| 7 | + [2] Documentation/devicetree/bindings/clock/clock-bindings.txt | |
| 8 | + [3] Documentation/devicetree/bindings/interrupt-controller/interrupts.txt | |
| 9 | + | |
| 10 | +Required Properties: | |
| 11 | + - compatible: Compatibility string. Must be 'arasan,sdhci-8.9a' | |
| 12 | + - reg: From mmc bindings: Register location and length. | |
| 13 | + - clocks: From clock bindings: Handles to clock inputs. | |
| 14 | + - clock-names: From clock bindings: Tuple including "clk_xin" and "clk_ahb" | |
| 15 | + - interrupts: Interrupt specifier | |
| 16 | + - interrupt-parent: Phandle for the interrupt controller that services | |
| 17 | + interrupts for this device. | |
| 18 | + | |
| 19 | +Example: | |
| 20 | + sdhci@e0100000 { | |
| 21 | + compatible = "arasan,sdhci-8.9a"; | |
| 22 | + reg = <0xe0100000 0x1000>; | |
| 23 | + clock-names = "clk_xin", "clk_ahb"; | |
| 24 | + clocks = <&clkc 21>, <&clkc 32>; | |
| 25 | + interrupt-parent = <&gic>; | |
| 26 | + interrupts = <0 24 4>; | |
| 27 | + } ; | |
| @@ -16,6 +16,8 @@ Required Properties: · 15 unmodified lines | ||
| 16 | 16 | specific extensions. |
| 17 | 17 | - "samsung,exynos5250-dw-mshc": for controllers with Samsung Exynos5250 |
| 18 | 18 | specific extensions. |
| 19 | + - "samsung,exynos5420-dw-mshc": for controllers with Samsung Exynos5420 | |
| 20 | + specific extensions. | |
| 19 | 21 | |
| 20 | 22 | * samsung,dw-mshc-ciu-div: Specifies the divider value for the card interface |
| 21 | 23 | unit (ciu) clock. This property is applicable only for Exynos5 SoC's and |
| @@ -0,0 +1,46 @@ | ||
| 1 | +* Hisilicon specific extensions to the Synopsys Designware Mobile | |
| 2 | + Storage Host Controller | |
| 3 | + | |
| 4 | +Read synopsys-dw-mshc.txt for more details | |
| 5 | + | |
| 6 | +The Synopsys designware mobile storage host controller is used to interface | |
| 7 | +a SoC with storage medium such as eMMC or SD/MMC cards. This file documents | |
| 8 | +differences between the core Synopsys dw mshc controller properties described | |
| 9 | +by synopsys-dw-mshc.txt and the properties used by the Hisilicon specific | |
| 10 | +extensions to the Synopsys Designware Mobile Storage Host Controller. | |
| 11 | + | |
| 12 | +Required Properties: | |
| 13 | + | |
| 14 | +* compatible: should be one of the following. | |
| 15 | + - "hisilicon,hi4511-dw-mshc": for controllers with hi4511 specific extentions. | |
| 16 | + | |
| 17 | +Example: | |
| 18 | + | |
| 19 | + /* for Hi3620 */ | |
| 20 | + | |
| 21 | + /* SoC portion */ | |
| 22 | + dwmmc_0: dwmmc0@fcd03000 { | |
| 23 | + compatible = "hisilicon,hi4511-dw-mshc"; | |
| 24 | + reg = <0xfcd03000 0x1000>; | |
| 25 | + interrupts = <0 16 4>; | |
| 26 | + #address-cells = <1>; | |
| 27 | + #size-cells = <0>; | |
| 28 | + clocks = <&mmc_clock HI3620_SD_CIUCLK>, <&clock HI3620_DDRC_PER_CLK>; | |
| 29 | + clock-names = "ciu", "biu"; | |
| 30 | + }; | |
| 31 | + | |
| 32 | + /* Board portion */ | |
| 33 | + dwmmc0@fcd03000 { | |
| 34 | + num-slots = <1>; | |
| 35 | + vmmc-supply = <&ldo12>; | |
| 36 | + fifo-depth = <0x100>; | |
| 37 | + supports-highspeed; | |
| 38 | + pinctrl-names = "default"; | |
| 39 | + pinctrl-0 = <&sd_pmx_pins &sd_cfg_func1 &sd_cfg_func2>; | |
| 40 | + slot@0 { | |
| 41 | + reg = <0>; | |
| 42 | + bus-width = <4>; | |
| 43 | + disable-wp; | |
| 44 | + cd-gpios = <&gpio10 3 0>; | |
| 45 | + }; | |
| 46 | + }; | |
| @@ -6,12 +6,16 @@ and the properties present in the bcm281xx SDHCI · 5 unmodified lines | ||
| 6 | 6 | Required properties: |
| 7 | 7 | - compatible : Should be "brcm,kona-sdhci" |
| 8 | 8 | - DEPRECATED: compatible : Should be "bcm,kona-sdhci" |
| 9 | +- clocks: phandle + clock specifier pair of the external clock | |
| 10 | + | |
| 11 | +Refer to clocks/clock-bindings.txt for generic clock consumer properties. | |
| 9 | 12 | |
| 10 | 13 | Example: |
| 11 | 14 | |
| 12 | 15 | sdio2: sdio@0x3f1a0000 { |
| 13 | 16 | compatible = "brcm,kona-sdhci"; |
| 14 | 17 | reg = <0x3f1a0000 0x10000>; |
| 18 | + clocks = <&sdio3_clk>; | |
| 15 | 19 | interrupts = <0x0 74 0x4>; |
| 16 | 20 | }; |
| 17 | 21 | |
| @@ -8,6 +8,12 @@ by mmc.txt and the properties used by the sdhci-tegra driver. · 7 unmodified lines | ||
| 8 | 8 | |
| 9 | 9 | Required properties: |
| 10 | 10 | - compatible : Should be "nvidia,<chip>-sdhci" |
| 11 | +- clocks : Must contain one entry, for the module clock. | |
| 12 | + See ../clocks/clock-bindings.txt for details. | |
| 13 | +- resets : Must contain an entry for each entry in reset-names. | |
| 14 | + See ../reset/reset.txt for details. | |
| 15 | +- reset-names : Must include the following entries: | |
| 16 | + - sdhci | |
| 11 | 17 | |
| 12 | 18 | Optional properties: |
| 13 | 19 | - power-gpios : Specify GPIOs for power control |
| @@ -18,6 +24,9 @@ sdhci@c8000200 { · 4 unmodified lines | ||
| 18 | 24 | compatible = "nvidia,tegra20-sdhci"; |
| 19 | 25 | reg = <0xc8000200 0x200>; |
| 20 | 26 | interrupts = <47>; |
| 27 | + clocks = <&tegra_car 14>; | |
| 28 | + resets = <&tegra_car 14>; | |
| 29 | + reset-names = "sdhci"; | |
| 21 | 30 | cd-gpios = <&gpio 69 0>; /* gpio PI5 */ |
| 22 | 31 | wp-gpios = <&gpio 57 0>; /* gpio PH1 */ |
| 23 | 32 | power-gpios = <&gpio 155 0>; /* gpio PT3 */ |
| @@ -0,0 +1,94 @@ | ||
| 1 | +Device tree bindings for Texas instruments Davinci/Keystone NAND controller | |
| 2 | + | |
| 3 | +This file provides information, what the device node for the davinci/keystone | |
| 4 | +NAND interface contains. | |
| 5 | + | |
| 6 | +Documentation: | |
| 7 | +Davinci DM646x - http://www.ti.com/lit/ug/sprueq7c/sprueq7c.pdf | |
| 8 | +Kestone - http://www.ti.com/lit/ug/sprugz3a/sprugz3a.pdf | |
| 9 | + | |
| 10 | +Required properties: | |
| 11 | + | |
| 12 | +- compatible: "ti,davinci-nand" | |
| 13 | + "ti,keystone-nand" | |
| 14 | + | |
| 15 | +- reg: Contains 2 offset/length values: | |
| 16 | + - offset and length for the access window. | |
| 17 | + - offset and length for accessing the AEMIF | |
| 18 | + control registers. | |
| 19 | + | |
| 20 | +- ti,davinci-chipselect: number of chipselect. Indicates on the | |
| 21 | + davinci_nand driver which chipselect is used | |
| 22 | + for accessing the nand. | |
| 23 | + Can be in the range [0-3]. | |
| 24 | + | |
| 25 | +Recommended properties : | |
| 26 | + | |
| 27 | +- ti,davinci-mask-ale: mask for ALE. Needed for executing address | |
| 28 | + phase. These offset will be added to the base | |
| 29 | + address for the chip select space the NAND Flash | |
| 30 | + device is connected to. | |
| 31 | + If not set equal to 0x08. | |
| 32 | + | |
| 33 | +- ti,davinci-mask-cle: mask for CLE. Needed for executing command | |
| 34 | + phase. These offset will be added to the base | |
| 35 | + address for the chip select space the NAND Flash | |
| 36 | + device is connected to. | |
| 37 | + If not set equal to 0x10. | |
| 38 | + | |
| 39 | +- ti,davinci-mask-chipsel: mask for chipselect address. Needed to mask | |
| 40 | + addresses for given chipselect. | |
| 41 | + | |
| 42 | +- nand-ecc-mode: operation mode of the NAND ecc mode. ECC mode | |
| 43 | + valid values for davinci driver: | |
| 44 | + - "none" | |
| 45 | + - "soft" | |
| 46 | + - "hw" | |
| 47 | + | |
| 48 | +- ti,davinci-ecc-bits: used ECC bits, currently supported 1 or 4. | |
| 49 | + | |
| 50 | +- nand-bus-width: buswidth 8 or 16. If not present 8. | |
| 51 | + | |
| 52 | +- nand-on-flash-bbt: use flash based bad block table support. OOB | |
| 53 | + identifier is saved in OOB area. If not present | |
| 54 | + false. | |
| 55 | + | |
| 56 | +Deprecated properties: | |
| 57 | + | |
| 58 | +- ti,davinci-ecc-mode: operation mode of the NAND ecc mode. ECC mode | |
| 59 | + valid values for davinci driver: | |
| 60 | + - "none" | |
| 61 | + - "soft" | |
| 62 | + - "hw" | |
| 63 | + | |
| 64 | +- ti,davinci-nand-buswidth: buswidth 8 or 16. If not present 8. | |
| 65 | + | |
| 66 | +- ti,davinci-nand-use-bbt: use flash based bad block table support. OOB | |
| 67 | + identifier is saved in OOB area. If not present | |
| 68 | + false. | |
| 69 | + | |
| 70 | +Nand device bindings may contain additional sub-nodes describing partitions of | |
| 71 | +the address space. See partition.txt for more detail. The NAND Flash timing | |
| 72 | +values must be programmed in the chip select’s node of AEMIF | |
| 73 | +memory-controller (see Documentation/devicetree/bindings/memory-controllers/ | |
| 74 | +davinci-aemif.txt). | |
| 75 | + | |
| 76 | +Example(da850 EVM ): | |
| 77 | + | |
| 78 | +nand_cs3@62000000 { | |
| 79 | + compatible = "ti,davinci-nand"; | |
| 80 | + reg = <0x62000000 0x807ff | |
| 81 | + 0x68000000 0x8000>; | |
| 82 | + ti,davinci-chipselect = <1>; | |
| 83 | + ti,davinci-mask-ale = <0>; | |
| 84 | + ti,davinci-mask-cle = <0>; | |
| 85 | + ti,davinci-mask-chipsel = <0>; | |
| 86 | + nand-ecc-mode = "hw"; | |
| 87 | + ti,davinci-ecc-bits = <4>; | |
| 88 | + nand-on-flash-bbt; | |
| 89 | + | |
| 90 | + partition@180000 { | |
| 91 | + label = "ubifs"; | |
| 92 | + reg = <0x180000 0x7e80000>; | |
| 93 | + }; | |
| 94 | +}; | |
| @@ -17,6 +17,14 @@ Required properties: · 16 unmodified lines | ||
| 17 | 17 | Optional properties: |
| 18 | 18 | - nand-on-flash-bbt: boolean to enable on flash bbt option if not |
| 19 | 19 | present false |
| 20 | + - fsl,use-minimum-ecc: Protect this NAND flash with the minimum ECC | |
| 21 | + strength required. The required ECC strength is | |
| 22 | + automatically discoverable for some flash | |
| 23 | + (e.g., according to the ONFI standard). | |
| 24 | + However, note that if this strength is not | |
| 25 | + discoverable or this property is not enabled, | |
| 26 | + the software may chooses an implementation-defined | |
| 27 | + ECC scheme. | |
| 20 | 28 | |
| 21 | 29 | The device tree may optionally contain sub-nodes describing partitions of the |
| 22 | 30 | address space. See partition.txt for more detail. |
| @@ -2,7 +2,9 @@ PXA3xx NAND DT bindings · 1 unmodified line | ||
| 2 | 2 | |
| 3 | 3 | Required properties: |
| 4 | 4 | |
| 5 | − - compatible: Should be "marvell,pxa3xx-nand" | |
| 5 | + - compatible: Should be set to one of the following: | |
| 6 | + marvell,pxa3xx-nand | |
| 7 | + marvell,armada370-nand | |
| 6 | 8 | - reg: The register base for the controller |
| 7 | 9 | - interrupts: The interrupt to map |
| 8 | 10 | - #address-cells: Set to <1> if the node includes partitions |
| @@ -13,6 +15,8 @@ Optional properties: · 4 unmodified lines | ||
| 13 | 15 | - marvell,nand-keep-config: Set to keep the NAND controller config as set |
| 14 | 16 | by the bootloader |
| 15 | 17 | - num-cs: Number of chipselect lines to usw |
| 18 | + - nand-on-flash-bbt: boolean to enable on flash bbt option if | |
| 19 | + not present false | |
| 16 | 20 | |
| 17 | 21 | Example: |
| 18 | 22 | |
| @@ -0,0 +1,27 @@ | ||
| 1 | +* Allwinner GMAC ethernet controller | |
| 2 | + | |
| 3 | +This device is a platform glue layer for stmmac. | |
| 4 | +Please see stmmac.txt for the other unchanged properties. | |
| 5 | + | |
| 6 | +Required properties: | |
| 7 | + - compatible: Should be "allwinner,sun7i-a20-gmac" | |
| 8 | + - clocks: Should contain the GMAC main clock, and tx clock | |
| 9 | + The tx clock type should be "allwinner,sun7i-a20-gmac-clk" | |
| 10 | + - clock-names: Should contain the clock names "stmmaceth", | |
| 11 | + and "allwinner_gmac_tx" | |
| 12 | + | |
| 13 | +Optional properties: | |
| 14 | +- phy-supply: phandle to a regulator if the PHY needs one | |
| 15 | + | |
| 16 | +Examples: | |
| 17 | + | |
| 18 | + gmac: ethernet@01c50000 { | |
| 19 | + compatible = "allwinner,sun7i-a20-gmac"; | |
| 20 | + reg = <0x01c50000 0x10000>, | |
| 21 | + <0x01c20164 0x4>; | |
| 22 | + interrupts = <0 85 1>; | |
| 23 | + interrupt-names = "macirq"; | |
| 24 | + clocks = <&ahb_gates 49>, <&gmac_tx>; | |
| 25 | + clock-names = "stmmaceth", "allwinner_gmac_tx"; | |
| 26 | + phy-mode = "mii"; | |
| 27 | + }; | |
| @@ -0,0 +1,25 @@ | ||
| 1 | +* Microchip MCP251X stand-alone CAN controller device tree bindings | |
| 2 | + | |
| 3 | +Required properties: | |
| 4 | + - compatible: Should be one of the following: | |
| 5 | + - "microchip,mcp2510" for MCP2510. | |
| 6 | + - "microchip,mcp2515" for MCP2515. | |
| 7 | + - reg: SPI chip select. | |
| 8 | + - clocks: The clock feeding the CAN controller. | |
| 9 | + - interrupt-parent: The parent interrupt controller. | |
| 10 | + - interrupts: Should contain IRQ line for the CAN controller. | |
| 11 | + | |
| 12 | +Optional properties: | |
| 13 | + - vdd-supply: Regulator that powers the CAN controller. | |
| 14 | + - xceiver-supply: Regulator that powers the CAN transceiver. | |
| 15 | + | |
| 16 | +Example: | |
| 17 | + can0: can@1 { | |
| 18 | + compatible = "microchip,mcp2515"; | |
| 19 | + reg = <1>; | |
| 20 | + clocks = <&clk24m>; | |
| 21 | + interrupt-parent = <&gpio4>; | |
| 22 | + interrupts = <13 0x2>; | |
| 23 | + vdd-supply = <®5v0>; | |
| 24 | + xceiver-supply = <®5v0>; | |
| 25 | + }; | |
| @@ -10,10 +10,6 @@ Required properties: · 9 unmodified lines | ||
| 10 | 10 | - ti,davinci-ctrl-mod-reg-offset: offset to control module register |
| 11 | 11 | - ti,davinci-ctrl-ram-offset: offset to control module ram |
| 12 | 12 | - ti,davinci-ctrl-ram-size: size of control module ram |
| 13 | −- ti,davinci-rmii-en: use RMII | |
| 14 | −- ti,davinci-no-bd-ram: has the emac controller BD RAM | |
| 15 | −- phy-handle: Contains a phandle to an Ethernet PHY. | |
| 16 | − if not, davinci_emac driver defaults to 100/FULL | |
| 17 | 13 | - interrupts: interrupt mapping for the davinci emac interrupts sources: |
| 18 | 14 | 4 sources: <Receive Threshold Interrupt |
| 19 | 15 | Receive Interrupt |
| @@ -21,7 +17,11 @@ Required properties: · 1 unmodified line | ||
| 21 | 17 | Miscellaneous Interrupt> |
| 22 | 18 | |
| 23 | 19 | Optional properties: |
| 20 | +- phy-handle: Contains a phandle to an Ethernet PHY. | |
| 21 | + If absent, davinci_emac driver defaults to 100/FULL. | |
| 24 | 22 | - local-mac-address : 6 bytes, mac address |
| 23 | +- ti,davinci-rmii-en: 1 byte, 1 means use RMII | |
| 24 | +- ti,davinci-no-bd-ram: boolean, does EMAC have BD RAM? | |
| 25 | 25 | |
| 26 | 26 | Example (enbw_cmc board): |
| 27 | 27 | eth0: emac@1e20000 { |
| @@ -10,6 +10,10 @@ Required properties: · 9 unmodified lines | ||
| 10 | 10 | - interrupts: Should contain macb interrupt |
| 11 | 11 | - phy-mode: String, operation mode of the PHY interface. |
| 12 | 12 | Supported values are: "mii", "rmii", "gmii", "rgmii". |
| 13 | +- clock-names: Tuple listing input clock names. | |
| 14 | + Required elements: 'pclk', 'hclk' | |
| 15 | + Optional elements: 'tx_clk' | |
| 16 | +- clocks: Phandles to input clocks. | |
| 13 | 17 | |
| 14 | 18 | Optional properties: |
| 15 | 19 | - local-mac-address: 6 bytes, mac address |
| @@ -22,4 +26,6 @@ Examples: · 6 unmodified lines | ||
| 22 | 26 | interrupts = <21>; |
| 23 | 27 | phy-mode = "rmii"; |
| 24 | 28 | local-mac-address = [3a 0e 03 04 05 06]; |
| 29 | + clock-names = "pclk", "hclk", "tx_clk"; | |
| 30 | + clocks = <&clkc 30>, <&clkc 30>, <&clkc 13>; | |
| 25 | 31 | }; |
| @@ -32,7 +32,6 @@ Optional controller properties: · 31 unmodified lines | ||
| 32 | 32 | * Ethernet port node |
| 33 | 33 | |
| 34 | 34 | Required port properties: |
| 35 | − - device_type: shall be "network". | |
| 36 | 35 | - compatible: shall be one of "marvell,orion-eth-port", |
| 37 | 36 | "marvell,kirkwood-eth-port". |
| 38 | 37 | - reg: port number relative to ethernet controller, shall be 0, 1, or 2. |
| @@ -61,7 +60,6 @@ or · 22 unmodified lines | ||
| 61 | 60 | mdio-bus { |
| 62 | 61 | ... |
| 63 | 62 | ethphy: ethernet-phy@8 { |
| 64 | − device_type = "ethernet-phy"; | |
| 65 | 63 | ... |
| 66 | 64 | }; |
| 67 | 65 | }; |
| @@ -75,7 +73,6 @@ eth: ethernet-controller@72000 { · 7 unmodified lines | ||
| 75 | 73 | marvell,tx-checksum-limit = <1600>; |
| 76 | 74 | |
| 77 | 75 | ethernet@0 { |
| 78 | − device_type = "network"; | |
| 79 | 76 | compatible = "marvell,orion-eth-port"; |
| 80 | 77 | reg = <0>; |
| 81 | 78 | interrupts = <29>; |
| @@ -2,7 +2,6 @@ PHY nodes · 1 unmodified line | ||
| 2 | 2 | |
| 3 | 3 | Required properties: |
| 4 | 4 | |
| 5 | − - device_type : Should be "ethernet-phy" | |
| 6 | 5 | - interrupts : <a b> where a is the interrupt number and b is a |
| 7 | 6 | field that represents an encoding of the sense and level |
| 8 | 7 | information for the interrupt. This should be encoded based on |
| @@ -11,8 +10,6 @@ Required properties: · 2 unmodified lines | ||
| 11 | 10 | - interrupt-parent : the phandle for the interrupt controller that |
| 12 | 11 | services interrupts for this device. |
| 13 | 12 | - 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 | 13 | |
| 17 | 14 | Optional Properties: |
| 18 | 15 | |
| @@ -22,14 +19,13 @@ Optional Properties: · 3 unmodified lines | ||
| 22 | 19 | specifications. If neither of these are specified, the default is to |
| 23 | 20 | assume clause 22. The compatible list may also contain other |
| 24 | 21 | elements. |
| 22 | +- max-speed: Maximum PHY supported speed (10, 100, 1000...) | |
| 25 | 23 | |
| 26 | 24 | Example: |
| 27 | 25 | |
| 28 | 26 | ethernet-phy@0 { |
| 29 | 27 | compatible = "ethernet-phy-ieee802.3-c22"; |
| 30 | − linux,phandle = <2452000>; | |
| 31 | 28 | interrupt-parent = <40000>; |
| 32 | 29 | interrupts = <35 1>; |
| 33 | 30 | reg = <0>; |
| 34 | − device_type = "ethernet-phy"; | |
| 35 | 31 | }; |
| @@ -12,7 +12,6 @@ Required properties: · 11 unmodified lines | ||
| 12 | 12 | property |
| 13 | 13 | - phy-mode: String, operation mode of the PHY interface. |
| 14 | 14 | Supported values are: "mii", "rmii", "gmii", "rgmii". |
| 15 | −- snps,phy-addr phy address to connect to. | |
| 16 | 15 | - snps,reset-gpio gpio number for phy reset. |
| 17 | 16 | - snps,reset-active-low boolean flag to indicate if phy reset is active low. |
| 18 | 17 | - snps,reset-delays-us is triplet of delays |
| @@ -30,6 +29,11 @@ Required properties: · 11 unmodified lines | ||
| 30 | 29 | |
| 31 | 30 | Optional properties: |
| 32 | 31 | - mac-address: 6 bytes, mac address |
| 32 | +- resets: Should contain a phandle to the STMMAC reset signal, if any | |
| 33 | +- reset-names: Should contain the reset signal name "stmmaceth", if a | |
| 34 | + reset phandle is given | |
| 35 | +- max-frame-size: Maximum Transfer Unit (IEEE defined MTU), rather | |
| 36 | + than the maximum frame size. | |
| 33 | 37 | |
| 34 | 38 | Examples: |
| 35 | 39 | |
| @@ -40,5 +44,6 @@ Examples: · 4 unmodified lines | ||
| 40 | 44 | interrupts = <24 23>; |
| 41 | 45 | interrupt-names = "macirq", "eth_wake_irq"; |
| 42 | 46 | mac-address = [000000000000]; /* Filled in by U-Boot */ |
| 47 | + max-frame-size = <3800>; | |
| 43 | 48 | phy-mode = "gmii"; |
| 44 | 49 | }; |
| @@ -7,3 +7,15 @@ Required properties: · 6 unmodified lines | ||
| 7 | 7 | - clock-frequency : the frequency of the i2c bus |
| 8 | 8 | - gpios : the gpio used for ec request |
| 9 | 9 | - slave-addr: the i2c address of the slave controller |
| 10 | +- clocks : Must contain an entry for each entry in clock-names. | |
| 11 | + See ../clocks/clock-bindings.txt for details. | |
| 12 | +- clock-names : Must include the following entries: | |
| 13 | + Tegra20/Tegra30: | |
| 14 | + - div-clk | |
| 15 | + - fast-clk | |
| 16 | + Tegra114: | |
| 17 | + - div-clk | |
| 18 | +- resets : Must contain an entry for each entry in reset-names. | |
| 19 | + See ../reset/reset.txt for details. | |
| 20 | +- reset-names : Must include the following entries: | |
| 21 | + - i2c | |
| @@ -0,0 +1,7 @@ | ||
| 1 | +AU Optronics Corporation 10.1" WSVGA TFT LCD panel | |
| 2 | + | |
| 3 | +Required properties: | |
| 4 | +- compatible: should be "auo,b101aw03" | |
| 5 | + | |
| 6 | +This binding is compatible with the simple-panel binding, which is specified | |
| 7 | +in simple-panel.txt in this directory. | |
| @@ -0,0 +1,7 @@ | ||
| 1 | +Chunghwa Picture Tubes Ltd. 10.1" WXGA TFT LCD panel | |
| 2 | + | |
| 3 | +Required properties: | |
| 4 | +- compatible: should be "chunghwa,claa101wa01a" | |
| 5 | + | |
| 6 | +This binding is compatible with the simple-panel binding, which is specified | |
| 7 | +in simple-panel.txt in this directory. | |
| @@ -0,0 +1,7 @@ | ||
| 1 | +Chunghwa Picture Tubes Ltd. 10.1" WXGA TFT LCD panel | |
| 2 | + | |
| 3 | +Required properties: | |
| 4 | +- compatible: should be "chunghwa,claa101wb03" | |
| 5 | + | |
| 6 | +This binding is compatible with the simple-panel binding, which is specified | |
| 7 | +in simple-panel.txt in this directory. | |
| @@ -0,0 +1,7 @@ | ||
| 1 | +Panasonic Corporation 10.1" WUXGA TFT LCD panel | |
| 2 | + | |
| 3 | +Required properties: | |
| 4 | +- compatible: should be "panasonic,vvx10f004b00" | |
| 5 | + | |
| 6 | +This binding is compatible with the simple-panel binding, which is specified | |
| 7 | +in simple-panel.txt in this directory. | |
| @@ -0,0 +1,7 @@ | ||
| 1 | +Samsung Electronics 10.1" WSVGA TFT LCD panel | |
| 2 | + | |
| 3 | +Required properties: | |
| 4 | +- compatible: should be "samsung,ltn101nt05" | |
| 5 | + | |
| 6 | +This binding is compatible with the simple-panel binding, which is specified | |
| 7 | +in simple-panel.txt in this directory. | |
| @@ -0,0 +1,21 @@ | ||
| 1 | +Simple display panel | |
| 2 | + | |
| 3 | +Required properties: | |
| 4 | +- power-supply: regulator to provide the supply voltage | |
| 5 | + | |
| 6 | +Optional properties: | |
| 7 | +- ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing | |
| 8 | +- enable-gpios: GPIO pin to enable or disable the panel | |
| 9 | +- backlight: phandle of the backlight device attached to the panel | |
| 10 | + | |
| 11 | +Example: | |
| 12 | + | |
| 13 | + panel: panel { | |
| 14 | + compatible = "cptt,claa101wb01"; | |
| 15 | + ddc-i2c-bus = <&panelddc>; | |
| 16 | + | |
| 17 | + power-supply = <&vdd_pnl_reg>; | |
| 18 | + enable-gpios = <&gpio 90 0>; | |
| 19 | + | |
| 20 | + backlight = <&backlight>; | |
| 21 | + }; | |
| @@ -19,6 +19,8 @@ Required properties: · 18 unmodified lines | ||
| 19 | 19 | to define the mapping of the PCIe interface to interrupt |
| 20 | 20 | numbers. |
| 21 | 21 | - num-lanes: number of lanes to use |
| 22 | + | |
| 23 | +Optional properties: | |
| 22 | 24 | - reset-gpio: gpio pin number of power good signal |
| 23 | 25 | |
| 24 | 26 | Optional properties for fsl,imx6q-pcie |
| @@ -42,14 +42,19 @@ Required properties: · 41 unmodified lines | ||
| 42 | 42 | - 0xc2000000: prefetchable memory region |
| 43 | 43 | Please refer to the standard PCI bus binding document for a more detailed |
| 44 | 44 | explanation. |
| 45 | −- clocks: List of clock inputs of the controller. Must contain an entry for | |
| 46 | − each entry in the clock-names property. | |
| 45 | +- clocks: Must contain an entry for each entry in clock-names. | |
| 46 | + See ../clocks/clock-bindings.txt for details. | |
| 47 | 47 | - clock-names: Must include the following entries: |
| 48 | − "pex": The Tegra clock of that name | |
| 49 | − "afi": The Tegra clock of that name | |
| 50 | − "pcie_xclk": The Tegra clock of that name | |
| 51 | − "pll_e": The Tegra clock of that name | |
| 52 | − "cml": The Tegra clock of that name (not required for Tegra20) | |
| 48 | + - pex | |
| 49 | + - afi | |
| 50 | + - pll_e | |
| 51 | + - cml (not required for Tegra20) | |
| 52 | +- resets: Must contain an entry for each entry in reset-names. | |
| 53 | + See ../reset/reset.txt for details. | |
| 54 | +- reset-names: Must include the following entries: | |
| 55 | + - pex | |
| 56 | + - afi | |
| 57 | + - pcie_x | |
| 53 | 58 | |
| 54 | 59 | Root ports are defined as subnodes of the PCIe controller node. |
| 55 | 60 | |
| @@ -91,9 +96,10 @@ SoC DTSI: · 35 unmodified lines | ||
| 91 | 96 | 0x82000000 0 0xa0000000 0xa0000000 0 0x10000000 /* non-prefetchable memory */ |
| 92 | 97 | 0xc2000000 0 0xb0000000 0xb0000000 0 0x10000000>; /* prefetchable memory */ |
| 93 | 98 | |
| 94 | − clocks = <&tegra_car 70>, <&tegra_car 72>, <&tegra_car 74>, | |
| 95 | − <&tegra_car 118>; | |
| 96 | − clock-names = "pex", "afi", "pcie_xclk", "pll_e"; | |
| 99 | + clocks = <&tegra_car 70>, <&tegra_car 72>, <&tegra_car 118>; | |
| 100 | + clock-names = "pex", "afi", "pll_e"; | |
| 101 | + resets = <&tegra_car 70>, <&tegra_car 72>, <&tegra_car 74>; | |
| 102 | + reset-names = "pex", "afi", "pcie_x"; | |
| 97 | 103 | status = "disabled"; |
| 98 | 104 | |
| 99 | 105 | pci@1,0 { |
| @@ -0,0 +1,15 @@ | ||
| 1 | +BROADCOM KONA USB2 PHY | |
| 2 | + | |
| 3 | +Required properties: | |
| 4 | + - compatible: brcm,kona-usb2-phy | |
| 5 | + - reg: offset and length of the PHY registers | |
| 6 | + - #phy-cells: must be 0 | |
| 7 | +Refer to phy/phy-bindings.txt for the generic PHY binding properties | |
| 8 | + | |
| 9 | +Example: | |
| 10 | + | |
| 11 | + usbphy: usb-phy@3f130000 { | |
| 12 | + compatible = "brcm,kona-usb2-phy"; | |
| 13 | + reg = <0x3f130000 0x28>; | |
| 14 | + #phy-cells = <0>; | |
| 15 | + }; | |
| @@ -0,0 +1,461 @@ | ||
| 1 | +Broadcom Capri Pin Controller | |
| 2 | + | |
| 3 | +This is a pin controller for the Broadcom BCM281xx SoC family, which includes | |
| 4 | +BCM11130, BCM11140, BCM11351, BCM28145, and BCM28155 SoCs. | |
| 5 | + | |
| 6 | +=== Pin Controller Node === | |
| 7 | + | |
| 8 | +Required Properties: | |
| 9 | + | |
| 10 | +- compatible: Must be "brcm,capri-pinctrl". | |
| 11 | +- reg: Base address of the PAD Controller register block and the size | |
| 12 | + of the block. | |
| 13 | + | |
| 14 | +For example, the following is the bare minimum node: | |
| 15 | + | |
| 16 | + pinctrl@35004800 { | |
| 17 | + compatible = "brcm,capri-pinctrl"; | |
| 18 | + reg = <0x35004800 0x430>; | |
| 19 | + }; | |
| 20 | + | |
| 21 | +As a pin controller device, in addition to the required properties, this node | |
| 22 | +should also contain the pin configuration nodes that client devices reference, | |
| 23 | +if any. | |
| 24 | + | |
| 25 | +=== Pin Configuration Node === | |
| 26 | + | |
| 27 | +Each pin configuration node is a sub-node of the pin controller node and is a | |
| 28 | +container of an arbitrary number of subnodes, called pin group nodes in this | |
| 29 | +document. | |
| 30 | + | |
| 31 | +Please refer to the pinctrl-bindings.txt in this directory for details of the | |
| 32 | +common pinctrl bindings used by client devices, including the definition of a | |
| 33 | +"pin configuration node". | |
| 34 | + | |
| 35 | +=== Pin Group Node === | |
| 36 | + | |
| 37 | +A pin group node specifies the desired pin mux and/or pin configuration for an | |
| 38 | +arbitrary number of pins. The name of the pin group node is optional and not | |
| 39 | +used. | |
| 40 | + | |
| 41 | +A pin group node only affects the properties specified in the node, and has no | |
| 42 | +effect on any properties that are omitted. | |
| 43 | + | |
| 44 | +The pin group node accepts a subset of the generic pin config properties. For | |
| 45 | +details generic pin config properties, please refer to pinctrl-bindings.txt | |
| 46 | +and <include/linux/pinctrl/pinconfig-generic.h>. | |
| 47 | + | |
| 48 | +Each pin controlled by this pin controller belong to one of three types: | |
| 49 | +Standard, I2C, and HDMI. Each type accepts a different set of pin config | |
| 50 | +properties. A list of pins and their types is provided below. | |
| 51 | + | |
| 52 | +Required Properties (applicable to all pins): | |
| 53 | + | |
| 54 | +- pins: Multiple strings. Specifies the name(s) of one or more pins to | |
| 55 | + be configured by this node. | |
| 56 | + | |
| 57 | +Optional Properties (for standard pins): | |
| 58 | + | |
| 59 | +- function: String. Specifies the pin mux selection. Values | |
| 60 | + must be one of: "alt1", "alt2", "alt3", "alt4" | |
| 61 | +- input-schmitt-enable: No arguments. Enable schmitt-trigger mode. | |
| 62 | +- input-schmitt-disable: No arguments. Disable schmitt-trigger mode. | |
| 63 | +- bias-pull-up: No arguments. Pull up on pin. | |
| 64 | +- bias-pull-down: No arguments. Pull down on pin. | |
| 65 | +- bias-disable: No arguments. Disable pin bias. | |
| 66 | +- slew-rate: Integer. Meaning depends on configured pin mux: | |
| 67 | + *_SCL or *_SDA: | |
| 68 | + 0: Standard(100kbps)& Fast(400kbps) mode | |
| 69 | + 1: Highspeed (3.4Mbps) mode | |
| 70 | + IC_DM or IC_DP: | |
| 71 | + 0: normal slew rate | |
| 72 | + 1: fast slew rate | |
| 73 | + Otherwise: | |
| 74 | + 0: fast slew rate | |
| 75 | + 1: normal slew rate | |
| 76 | +- input-enable: No arguements. Enable input (does not affect | |
| 77 | + output.) | |
| 78 | +- input-disable: No arguements. Disable input (does not affect | |
| 79 | + output.) | |
| 80 | +- drive-strength: Integer. Drive strength in mA. Valid values are | |
| 81 | + 2, 4, 6, 8, 10, 12, 14, 16 mA. | |
| 82 | + | |
| 83 | +Optional Properties (for I2C pins): | |
| 84 | + | |
| 85 | +- function: String. Specifies the pin mux selection. Values | |
| 86 | + must be one of: "alt1", "alt2", "alt3", "alt4" | |
| 87 | +- bias-pull-up: Integer. Pull up strength in Ohm. There are 3 | |
| 88 | + pull-up resisitors (1.2k, 1.8k, 2.7k) available | |
| 89 | + in parallel for I2C pins, so the valid values | |
| 90 | + are: 568, 720, 831, 1080, 1200, 1800, 2700 Ohm. | |
| 91 | +- bias-disable: No arguments. Disable pin bias. | |
| 92 | +- slew-rate: Integer. Meaning depends on configured pin mux: | |
| 93 | + *_SCL or *_SDA: | |
| 94 | + 0: Standard(100kbps)& Fast(400kbps) mode | |
| 95 | + 1: Highspeed (3.4Mbps) mode | |
| 96 | + IC_DM or IC_DP: | |
| 97 | + 0: normal slew rate | |
| 98 | + 1: fast slew rate | |
| 99 | + Otherwise: | |
| 100 | + 0: fast slew rate | |
| 101 | + 1: normal slew rate | |
| 102 | +- input-enable: No arguements. Enable input (does not affect | |
| 103 | + output.) | |
| 104 | +- input-disable: No arguements. Disable input (does not affect | |
| 105 | + output.) | |
| 106 | + | |
| 107 | +Optional Properties (for HDMI pins): | |
| 108 | + | |
| 109 | +- function: String. Specifies the pin mux selection. Values | |
| 110 | + must be one of: "alt1", "alt2", "alt3", "alt4" | |
| 111 | +- slew-rate: Integer. Controls slew rate. | |
| 112 | + 0: Standard(100kbps)& Fast(400kbps) mode | |
| 113 | + 1: Highspeed (3.4Mbps) mode | |
| 114 | +- input-enable: No arguements. Enable input (does not affect | |
| 115 | + output.) | |
| 116 | +- input-disable: No arguements. Disable input (does not affect | |
| 117 | + output.) | |
| 118 | + | |
| 119 | +Example: | |
| 120 | +// pin controller node | |
| 121 | +pinctrl@35004800 { | |
| 122 | + compatible = "brcm,capri-pinctrl"; | |
| 123 | + reg = <0x35004800 0x430>; | |
| 124 | + | |
| 125 | + // pin configuration node | |
| 126 | + dev_a_default: dev_a_active { | |
| 127 | + //group node defining 1 standard pin | |
| 128 | + grp_1 { | |
| 129 | + pins = "std_pin1"; | |
| 130 | + function = "alt1"; | |
| 131 | + input-schmitt-enable; | |
| 132 | + bias-disable; | |
| 133 | + slew-rate = <1>; | |
| 134 | + drive-strength = <4>; | |
| 135 | + }; | |
| 136 | + | |
| 137 | + // group node defining 2 I2C pins | |
| 138 | + grp_2 { | |
| 139 | + pins = "i2c_pin1", "i2c_pin2"; | |
| 140 | + function = "alt2"; | |
| 141 | + bias-pull-up = <720>; | |
| 142 | + input-enable; | |
| 143 | + }; | |
| 144 | + | |
| 145 | + // group node defining 2 HDMI pins | |
| 146 | + grp_3 { | |
| 147 | + pins = "hdmi_pin1", "hdmi_pin2"; | |
| 148 | + function = "alt3"; | |
| 149 | + slew-rate = <1>; | |
| 150 | + }; | |
| 151 | + | |
| 152 | + // other pin group nodes | |
| 153 | + ... | |
| 154 | + }; | |
| 155 | + | |
| 156 | + // other pin configuration nodes | |
| 157 | + ... | |
| 158 | +}; | |
| 159 | + | |
| 160 | +In the example above, "dev_a_active" is a pin configuration node with a number | |
| 161 | +of sub-nodes. In the pin group node "grp_1", one pin, "std_pin1", is defined in | |
| 162 | +the "pins" property. Thus, the remaining properties in the "grp_1" node applies | |
| 163 | +only to this pin, including the following settings: | |
| 164 | + - setting pinmux to "alt1" | |
| 165 | + - enabling schmitt-trigger (hystersis) mode | |
| 166 | + - disabling pin bias | |
| 167 | + - setting the slew-rate to 1 | |
| 168 | + - setting the drive strength to 4 mA | |
| 169 | +Note that neither "input-enable" nor "input-disable" was specified - the pinctrl | |
| 170 | +subsystem will therefore leave this property unchanged from whatever state it | |
| 171 | +was in before applying these changes. | |
| 172 | + | |
| 173 | +The "pins" property in the pin group node "grp_2" specifies two pins - | |
| 174 | +"i2c_pin1" and "i2c_pin2"; the remaining properties in this pin group node, | |
| 175 | +therefore, applies to both of these pins. The properties include: | |
| 176 | + - setting pinmux to "alt2" | |
| 177 | + - setting pull-up resistance to 720 Ohm (ie. enabling 1.2k and 1.8k resistors | |
| 178 | + in parallel) | |
| 179 | + - enabling both pins' input | |
| 180 | +"slew-rate" is not specified in this pin group node, so the slew-rate for these | |
| 181 | +pins are left as-is. | |
| 182 | + | |
| 183 | +Finally, "grp_3" defines two HDMI pins. The following properties are applied to | |
| 184 | +both pins: | |
| 185 | + - setting pinmux to "alt3" | |
| 186 | + - setting slew-rate to 1; for HDMI pins, this corresponds to the 3.4 Mbps | |
| 187 | + Highspeed mode | |
| 188 | +The input is neither enabled or disabled, and is left untouched. | |
| 189 | + | |
| 190 | +=== Pin Names and Type === | |
| 191 | + | |
| 192 | +The following are valid pin names and their pin types: | |
| 193 | + | |
| 194 | + "adcsync", Standard | |
| 195 | + "bat_rm", Standard | |
| 196 | + "bsc1_scl", I2C | |
| 197 | + "bsc1_sda", I2C | |
| 198 | + "bsc2_scl", I2C | |
| 199 | + "bsc2_sda", I2C | |
| 200 | + "classgpwr", Standard | |
| 201 | + "clk_cx8", Standard | |
| 202 | + "clkout_0", Standard | |
| 203 | + "clkout_1", Standard | |
| 204 | + "clkout_2", Standard | |
| 205 | + "clkout_3", Standard | |
| 206 | + "clkreq_in_0", Standard | |
| 207 | + "clkreq_in_1", Standard | |
| 208 | + "cws_sys_req1", Standard | |
| 209 | + "cws_sys_req2", Standard | |
| 210 | + "cws_sys_req3", Standard | |
| 211 | + "digmic1_clk", Standard | |
| 212 | + "digmic1_dq", Standard | |
| 213 | + "digmic2_clk", Standard | |
| 214 | + "digmic2_dq", Standard | |
| 215 | + "gpen13", Standard | |
| 216 | + "gpen14", Standard | |
| 217 | + "gpen15", Standard | |
| 218 | + "gpio00", Standard | |
| 219 | + "gpio01", Standard | |
| 220 | + "gpio02", Standard | |
| 221 | + "gpio03", Standard | |
| 222 | + "gpio04", Standard | |
| 223 | + "gpio05", Standard | |
| 224 | + "gpio06", Standard | |
| 225 | + "gpio07", Standard | |
| 226 | + "gpio08", Standard | |
| 227 | + "gpio09", Standard | |
| 228 | + "gpio10", Standard | |
| 229 | + "gpio11", Standard | |
| 230 | + "gpio12", Standard | |
| 231 | + "gpio13", Standard | |
| 232 | + "gpio14", Standard | |
| 233 | + "gps_pablank", Standard | |
| 234 | + "gps_tmark", Standard | |
| 235 | + "hdmi_scl", HDMI | |
| 236 | + "hdmi_sda", HDMI | |
| 237 | + "ic_dm", Standard | |
| 238 | + "ic_dp", Standard | |
| 239 | + "kp_col_ip_0", Standard | |
| 240 | + "kp_col_ip_1", Standard | |
| 241 | + "kp_col_ip_2", Standard | |
| 242 | + "kp_col_ip_3", Standard | |
| 243 | + "kp_row_op_0", Standard | |
| 244 | + "kp_row_op_1", Standard | |
| 245 | + "kp_row_op_2", Standard | |
| 246 | + "kp_row_op_3", Standard | |
| 247 | + "lcd_b_0", Standard | |
| 248 | + "lcd_b_1", Standard | |
| 249 | + "lcd_b_2", Standard | |
| 250 | + "lcd_b_3", Standard | |
| 251 | + "lcd_b_4", Standard | |
| 252 | + "lcd_b_5", Standard | |
| 253 | + "lcd_b_6", Standard | |
| 254 | + "lcd_b_7", Standard | |
| 255 | + "lcd_g_0", Standard | |
| 256 | + "lcd_g_1", Standard | |
| 257 | + "lcd_g_2", Standard | |
| 258 | + "lcd_g_3", Standard | |
| 259 | + "lcd_g_4", Standard | |
| 260 | + "lcd_g_5", Standard | |
| 261 | + "lcd_g_6", Standard | |
| 262 | + "lcd_g_7", Standard | |
| 263 | + "lcd_hsync", Standard | |
| 264 | + "lcd_oe", Standard | |
| 265 | + "lcd_pclk", Standard | |
| 266 | + "lcd_r_0", Standard | |
| 267 | + "lcd_r_1", Standard | |
| 268 | + "lcd_r_2", Standard | |
| 269 | + "lcd_r_3", Standard | |
| 270 | + "lcd_r_4", Standard | |
| 271 | + "lcd_r_5", Standard | |
| 272 | + "lcd_r_6", Standard | |
| 273 | + "lcd_r_7", Standard | |
| 274 | + "lcd_vsync", Standard | |
| 275 | + "mdmgpio0", Standard | |
| 276 | + "mdmgpio1", Standard | |
| 277 | + "mdmgpio2", Standard | |
| 278 | + "mdmgpio3", Standard | |
| 279 | + "mdmgpio4", Standard | |
| 280 | + "mdmgpio5", Standard | |
| 281 | + "mdmgpio6", Standard | |
| 282 | + "mdmgpio7", Standard | |
| 283 | + "mdmgpio8", Standard | |
| 284 | + "mphi_data_0", Standard | |
| 285 | + "mphi_data_1", Standard | |
| 286 | + "mphi_data_2", Standard | |
| 287 | + "mphi_data_3", Standard | |
| 288 | + "mphi_data_4", Standard | |
| 289 | + "mphi_data_5", Standard | |
| 290 | + "mphi_data_6", Standard | |
| 291 | + "mphi_data_7", Standard | |
| 292 | + "mphi_data_8", Standard | |
| 293 | + "mphi_data_9", Standard | |
| 294 | + "mphi_data_10", Standard | |
| 295 | + "mphi_data_11", Standard | |
| 296 | + "mphi_data_12", Standard | |
| 297 | + "mphi_data_13", Standard | |
| 298 | + "mphi_data_14", Standard | |
| 299 | + "mphi_data_15", Standard | |
| 300 | + "mphi_ha0", Standard | |
| 301 | + "mphi_hat0", Standard | |
| 302 | + "mphi_hat1", Standard | |
| 303 | + "mphi_hce0_n", Standard | |
| 304 | + "mphi_hce1_n", Standard | |
| 305 | + "mphi_hrd_n", Standard | |
| 306 | + "mphi_hwr_n", Standard | |
| 307 | + "mphi_run0", Standard | |
| 308 | + "mphi_run1", Standard | |
| 309 | + "mtx_scan_clk", Standard | |
| 310 | + "mtx_scan_data", Standard | |
| 311 | + "nand_ad_0", Standard | |
| 312 | + "nand_ad_1", Standard | |
| 313 | + "nand_ad_2", Standard | |
| 314 | + "nand_ad_3", Standard | |
| 315 | + "nand_ad_4", Standard | |
| 316 | + "nand_ad_5", Standard | |
| 317 | + "nand_ad_6", Standard | |
| 318 | + "nand_ad_7", Standard | |
| 319 | + "nand_ale", Standard | |
| 320 | + "nand_cen_0", Standard | |
| 321 | + "nand_cen_1", Standard | |
| 322 | + "nand_cle", Standard | |
| 323 | + "nand_oen", Standard | |
| 324 | + "nand_rdy_0", Standard | |
| 325 | + "nand_rdy_1", Standard | |
| 326 | + "nand_wen", Standard | |
| 327 | + "nand_wp", Standard | |
| 328 | + "pc1", Standard | |
| 329 | + "pc2", Standard | |
| 330 | + "pmu_int", Standard | |
| 331 | + "pmu_scl", I2C | |
| 332 | + "pmu_sda", I2C | |
| 333 | + "rfst2g_mtsloten3g", Standard | |
| 334 | + "rgmii_0_rx_ctl", Standard | |
| 335 | + "rgmii_0_rxc", Standard | |
| 336 | + "rgmii_0_rxd_0", Standard | |
| 337 | + "rgmii_0_rxd_1", Standard | |
| 338 | + "rgmii_0_rxd_2", Standard | |
| 339 | + "rgmii_0_rxd_3", Standard | |
| 340 | + "rgmii_0_tx_ctl", Standard | |
| 341 | + "rgmii_0_txc", Standard | |
| 342 | + "rgmii_0_txd_0", Standard | |
| 343 | + "rgmii_0_txd_1", Standard | |
| 344 | + "rgmii_0_txd_2", Standard | |
| 345 | + "rgmii_0_txd_3", Standard | |
| 346 | + "rgmii_1_rx_ctl", Standard | |
| 347 | + "rgmii_1_rxc", Standard | |
| 348 | + "rgmii_1_rxd_0", Standard | |
| 349 | + "rgmii_1_rxd_1", Standard | |
| 350 | + "rgmii_1_rxd_2", Standard | |
| 351 | + "rgmii_1_rxd_3", Standard | |
| 352 | + "rgmii_1_tx_ctl", Standard | |
| 353 | + "rgmii_1_txc", Standard | |
| 354 | + "rgmii_1_txd_0", Standard | |
| 355 | + "rgmii_1_txd_1", Standard | |
| 356 | + "rgmii_1_txd_2", Standard | |
| 357 | + "rgmii_1_txd_3", Standard | |
| 358 | + "rgmii_gpio_0", Standard | |
| 359 | + "rgmii_gpio_1", Standard | |
| 360 | + "rgmii_gpio_2", Standard | |
| 361 | + "rgmii_gpio_3", Standard | |
| 362 | + "rtxdata2g_txdata3g1", Standard | |
| 363 | + "rtxen2g_txdata3g2", Standard | |
| 364 | + "rxdata3g0", Standard | |
| 365 | + "rxdata3g1", Standard | |
| 366 | + "rxdata3g2", Standard | |
| 367 | + "sdio1_clk", Standard | |
| 368 | + "sdio1_cmd", Standard | |
| 369 | + "sdio1_data_0", Standard | |
| 370 | + "sdio1_data_1", Standard | |
| 371 | + "sdio1_data_2", Standard | |
| 372 | + "sdio1_data_3", Standard | |
| 373 | + "sdio4_clk", Standard | |
| 374 | + "sdio4_cmd", Standard | |
| 375 | + "sdio4_data_0", Standard | |
| 376 | + "sdio4_data_1", Standard | |
| 377 | + "sdio4_data_2", Standard | |
| 378 | + "sdio4_data_3", Standard | |
| 379 | + "sim_clk", Standard | |
| 380 | + "sim_data", Standard | |
| 381 | + "sim_det", Standard | |
| 382 | + "sim_resetn", Standard | |
| 383 | + "sim2_clk", Standard | |
| 384 | + "sim2_data", Standard | |
| 385 | + "sim2_det", Standard | |
| 386 | + "sim2_resetn", Standard | |
| 387 | + "sri_c", Standard | |
| 388 | + "sri_d", Standard | |
| 389 | + "sri_e", Standard | |
| 390 | + "ssp_extclk", Standard | |
| 391 | + "ssp0_clk", Standard | |
| 392 | + "ssp0_fs", Standard | |
| 393 | + "ssp0_rxd", Standard | |
| 394 | + "ssp0_txd", Standard | |
| 395 | + "ssp2_clk", Standard | |
| 396 | + "ssp2_fs_0", Standard | |
| 397 | + "ssp2_fs_1", Standard | |
| 398 | + "ssp2_fs_2", Standard | |
| 399 | + "ssp2_fs_3", Standard | |
| 400 | + "ssp2_rxd_0", Standard | |
| 401 | + "ssp2_rxd_1", Standard | |
| 402 | + "ssp2_txd_0", Standard | |
| 403 | + "ssp2_txd_1", Standard | |
| 404 | + "ssp3_clk", Standard | |
| 405 | + "ssp3_fs", Standard | |
| 406 | + "ssp3_rxd", Standard | |
| 407 | + "ssp3_txd", Standard | |
| 408 | + "ssp4_clk", Standard | |
| 409 | + "ssp4_fs", Standard | |
| 410 | + "ssp4_rxd", Standard | |
| 411 | + "ssp4_txd", Standard | |
| 412 | + "ssp5_clk", Standard | |
| 413 | + "ssp5_fs", Standard | |
| 414 | + "ssp5_rxd", Standard | |
| 415 | + "ssp5_txd", Standard | |
| 416 | + "ssp6_clk", Standard | |
| 417 | + "ssp6_fs", Standard | |
| 418 | + "ssp6_rxd", Standard | |
| 419 | + "ssp6_txd", Standard | |
| 420 | + "stat_1", Standard | |
| 421 | + "stat_2", Standard | |
| 422 | + "sysclken", Standard | |
| 423 | + "traceclk", Standard | |
| 424 | + "tracedt00", Standard | |
| 425 | + "tracedt01", Standard | |
| 426 | + "tracedt02", Standard | |
| 427 | + "tracedt03", Standard | |
| 428 | + "tracedt04", Standard | |
| 429 | + "tracedt05", Standard | |
| 430 | + "tracedt06", Standard | |
| 431 | + "tracedt07", Standard | |
| 432 | + "tracedt08", Standard | |
| 433 | + "tracedt09", Standard | |
| 434 | + "tracedt10", Standard | |
| 435 | + "tracedt11", Standard | |
| 436 | + "tracedt12", Standard | |
| 437 | + "tracedt13", Standard | |
| 438 | + "tracedt14", Standard | |
| 439 | + "tracedt15", Standard | |
| 440 | + "txdata3g0", Standard | |
| 441 | + "txpwrind", Standard | |
| 442 | + "uartb1_ucts", Standard | |
| 443 | + "uartb1_urts", Standard | |
| 444 | + "uartb1_urxd", Standard | |
| 445 | + "uartb1_utxd", Standard | |
| 446 | + "uartb2_urxd", Standard | |
| 447 | + "uartb2_utxd", Standard | |
| 448 | + "uartb3_ucts", Standard | |
| 449 | + "uartb3_urts", Standard | |
| 450 | + "uartb3_urxd", Standard | |
| 451 | + "uartb3_utxd", Standard | |
| 452 | + "uartb4_ucts", Standard | |
| 453 | + "uartb4_urts", Standard | |
| 454 | + "uartb4_urxd", Standard | |
| 455 | + "uartb4_utxd", Standard | |
| 456 | + "vc_cam1_scl", I2C | |
| 457 | + "vc_cam1_sda", I2C | |
| 458 | + "vc_cam2_scl", I2C | |
| 459 | + "vc_cam2_sda", I2C | |
| 460 | + "vc_cam3_scl", I2C | |
| 461 | + "vc_cam3_sda", I2C | |
| @@ -0,0 +1,23 @@ | ||
| 1 | +* Freescale IMX25 IOMUX Controller | |
| 2 | + | |
| 3 | +Please refer to fsl,imx-pinctrl.txt in this directory for common binding part | |
| 4 | +and usage. | |
| 5 | + | |
| 6 | +CONFIG bits definition: | |
| 7 | +PAD_CTL_HYS (1 << 8) | |
| 8 | +PAD_CTL_PKE (1 << 7) | |
| 9 | +PAD_CTL_PUE (1 << 6) | |
| 10 | +PAD_CTL_PUS_100K_DOWN (0 << 4) | |
| 11 | +PAD_CTL_PUS_47K_UP (1 << 4) | |
| 12 | +PAD_CTL_PUS_100K_UP (2 << 4) | |
| 13 | +PAD_CTL_PUS_22K_UP (3 << 4) | |
| 14 | +PAD_CTL_ODE_CMOS (0 << 3) | |
| 15 | +PAD_CTL_ODE_OPENDRAIN (1 << 3) | |
| 16 | +PAD_CTL_DSE_NOMINAL (0 << 1) | |
| 17 | +PAD_CTL_DSE_HIGH (1 << 1) | |
| 18 | +PAD_CTL_DSE_MAX (2 << 1) | |
| 19 | +PAD_CTL_SRE_FAST (1 << 0) | |
| 20 | +PAD_CTL_SRE_SLOW (0 << 0) | |
| 21 | + | |
| 22 | +Refer to imx25-pinfunc.h in device tree source folder for all available | |
| 23 | +imx25 PIN_FUNC_ID. | |
| @@ -52,12 +52,25 @@ Required properties for pin configuration node: · 51 unmodified lines | ||
| 52 | 52 | CONFIG can be 0 or 1, meaning Pullup disable/enable. |
| 53 | 53 | |
| 54 | 54 | |
| 55 | +The iomux controller has gpio child nodes which are embedded in the iomux | |
| 56 | +control registers. They have to be defined as child nodes of the iomux device | |
| 57 | +node. If gpio subnodes are defined "#address-cells", "#size-cells" and "ranges" | |
| 58 | +properties for the iomux device node are required. | |
| 55 | 59 | |
| 56 | 60 | Example: |
| 57 | 61 | |
| 58 | 62 | iomuxc: iomuxc@10015000 { |
| 59 | 63 | compatible = "fsl,imx27-iomuxc"; |
| 60 | 64 | reg = <0x10015000 0x600>; |
| 65 | + #address-cells = <1>; | |
| 66 | + #size-cells = <1>; | |
| 67 | + ranges; | |
| 68 | + | |
| 69 | + gpio1: gpio@10015000 { | |
| 70 | + ... | |
| 71 | + }; | |
| 72 | + | |
| 73 | + ... | |
| 61 | 74 | |
| 62 | 75 | uart { |
| 63 | 76 | pinctrl_uart1: uart-1 { |
| @@ -83,6 +96,15 @@ The above example using macros: · 19 unmodified lines | ||
| 83 | 96 | iomuxc: iomuxc@10015000 { |
| 84 | 97 | compatible = "fsl,imx27-iomuxc"; |
| 85 | 98 | reg = <0x10015000 0x600>; |
| 99 | + #address-cells = <1>; | |
| 100 | + #size-cells = <1>; | |
| 101 | + ranges; | |
| 102 | + | |
| 103 | + gpio1: gpio@10015000 { | |
| 104 | + ... | |
| 105 | + }; | |
| 106 | + | |
| 107 | + ... | |
| 86 | 108 | |
| 87 | 109 | uart { |
| 88 | 110 | pinctrl_uart1: uart-1 { |
| @@ -0,0 +1,144 @@ | ||
| 1 | +NVIDIA Tegra124 pinmux controller | |
| 2 | + | |
| 3 | +The Tegra124 pinctrl binding is very similar to the Tegra20 and Tegra30 | |
| 4 | +pinctrl binding, as described in nvidia,tegra20-pinmux.txt and | |
| 5 | +nvidia,tegra30-pinmux.txt. In fact, this document assumes that binding as | |
| 6 | +a baseline, and only documents the differences between the two bindings. | |
| 7 | + | |
| 8 | +Required properties: | |
| 9 | +- compatible: "nvidia,tegra124-pinmux" | |
| 10 | +- reg: Should contain a list of base address and size pairs for: | |
| 11 | + -- first entry - the drive strength and pad control registers. | |
| 12 | + -- second entry - the pinmux registers | |
| 13 | + | |
| 14 | +Tegra124 adds the following optional properties for pin configuration subnodes. | |
| 15 | +The macros for options are defined in the | |
| 16 | + include/dt-binding/pinctrl/pinctrl-tegra.h. | |
| 17 | +- nvidia,enable-input: Integer. Enable the pin's input path. | |
| 18 | + enable :TEGRA_PIN_ENABLE0 and | |
| 19 | + disable or output only: TEGRA_PIN_DISABLE. | |
| 20 | +- nvidia,open-drain: Integer. | |
| 21 | + enable: TEGRA_PIN_ENABLE. | |
| 22 | + disable: TEGRA_PIN_DISABLE. | |
| 23 | +- nvidia,lock: Integer. Lock the pin configuration against further changes | |
| 24 | + until reset. | |
| 25 | + enable: TEGRA_PIN_ENABLE. | |
| 26 | + disable: TEGRA_PIN_DISABLE. | |
| 27 | +- nvidia,io-reset: Integer. Reset the IO path. | |
| 28 | + enable: TEGRA_PIN_ENABLE. | |
| 29 | + disable: TEGRA_PIN_DISABLE. | |
| 30 | +- nvidia,rcv-sel: Integer. Select VIL/VIH receivers. | |
| 31 | + normal: TEGRA_PIN_DISABLE | |
| 32 | + high: TEGRA_PIN_ENABLE | |
| 33 | + | |
| 34 | +Please refer the Tegra TRM for complete details regarding which groups | |
| 35 | +support which functionality. | |
| 36 | + | |
| 37 | +Valid values for pin and group names are: | |
| 38 | + | |
| 39 | + per-pin mux groups: | |
| 40 | + | |
| 41 | + These all support nvidia,function, nvidia,tristate, nvidia,pull, | |
| 42 | + nvidia,enable-input. Some support nvidia,lock nvidia,open-drain, | |
| 43 | + nvidia,io-reset and nvidia,rcv-sel. | |
| 44 | + | |
| 45 | + ulpi_data0_po1, ulpi_data1_po2, ulpi_data2_po3, ulpi_data3_po4, | |
| 46 | + ulpi_data4_po5, ulpi_data5_po6, ulpi_data6_po7, ulpi_data7_po0, | |
| 47 | + ulpi_clk_py0, ulpi_dir_py1, ulpi_nxt_py2, ulpi_stp_py3, dap3_fs_pp0, | |
| 48 | + dap3_din_pp1, dap3_dout_pp2, dap3_sclk_pp3, pv0, pv1, sdmmc1_clk_pz0, | |
| 49 | + sdmmc1_cmd_pz1, sdmmc1_dat3_py4, sdmmc1_dat2_py5, sdmmc1_dat1_py6, | |
| 50 | + sdmmc1_dat0_py7, clk2_out_pw5, clk2_req_pcc5, hdmi_int_pn7, ddc_scl_pv4, | |
| 51 | + ddc_sda_pv5, uart2_rxd_pc3, uart2_txd_pc2, uart2_rts_n_pj6, | |
| 52 | + uart2_cts_n_pj5, uart3_txd_pw6, uart3_rxd_pw7, uart3_cts_n_pa1, | |
| 53 | + uart3_rts_n_pc0, pu0, pu1, pu2, pu3, pu4, pu5, pu6, gen1_i2c_scl_pc4, | |
| 54 | + gen1_i2c_sda_pc5, dap4_fs_pp4, dap4_din_pp5, dap4_dout_pp6, | |
| 55 | + dap4_sclk_pp7, clk3_out_pee0, clk3_req_pee1, pc7, pi5, pi7, pk0, pk1, | |
| 56 | + pj0, pj2, pk3, pk4, pk2, pi3, pi6, pg0, pg1, pg2, pg3, pg4, pg5, pg6, | |
| 57 | + pg7, ph0, ph1, ph2, ph3, ph4, ph5, ph6, ph7, pj7, pb0, pb1, pk7, pi0, | |
| 58 | + pi1, pi2, pi4, gen2_i2c_scl_pt5, gen2_i2c_sda_pt6, sdmmc4_clk_pcc4, | |
| 59 | + sdmmc4_cmd_pt7, sdmmc4_dat0_paa0, sdmmc4_dat1_paa1, sdmmc4_dat2_paa2, | |
| 60 | + sdmmc4_dat3_paa3, sdmmc4_dat4_paa4, sdmmc4_dat5_paa5, sdmmc4_dat6_paa6, | |
| 61 | + sdmmc4_dat7_paa7, cam_mclk_pcc0, pcc1, pbb0, cam_i2c_scl_pbb1, | |
| 62 | + cam_i2c_sda_pbb2, pbb3, pbb4, pbb5, pbb6, pbb7, pcc2, jtag_rtck, | |
| 63 | + pwr_i2c_scl_pz6, pwr_i2c_sda_pz7, kb_row0_pr0, kb_row1_pr1, kb_row2_pr2, | |
| 64 | + kb_row3_pr3, kb_row4_pr4, kb_row5_pr5, kb_row6_pr6, kb_row7_pr7, | |
| 65 | + kb_row8_ps0, kb_row9_ps1, kb_row10_ps2, kb_row11_ps3, kb_row12_ps4, | |
| 66 | + kb_row13_ps5, kb_row14_ps6, kb_row15_ps7, kb_col0_pq0, kb_col1_pq1, | |
| 67 | + kb_col2_pq2, kb_col3_pq3, kb_col4_pq4, kb_col5_pq5, kb_col6_pq6, | |
| 68 | + kb_col7_pq7, clk_32k_out_pa0, core_pwr_req, cpu_pwr_req, pwr_int_n, | |
| 69 | + clk_32k_in, owr, dap1_fs_pn0, dap1_din_pn1, dap1_dout_pn2, | |
| 70 | + dap1_sclk_pn3, dap_mclk1_req_pee2, dap_mclk1_pw4, spdif_in_pk6, | |
| 71 | + spdif_out_pk5, dap2_fs_pa2, dap2_din_pa4, dap2_dout_pa5, dap2_sclk_pa3, | |
| 72 | + dvfs_pwm_px0, gpio_x1_aud_px1, gpio_x3_aud_px3, dvfs_clk_px2, | |
| 73 | + gpio_x4_aud_px4, gpio_x5_aud_px5, gpio_x6_aud_px6, gpio_x7_aud_px7, | |
| 74 | + sdmmc3_clk_pa6, sdmmc3_cmd_pa7, sdmmc3_dat0_pb7, sdmmc3_dat1_pb6, | |
| 75 | + sdmmc3_dat2_pb5, sdmmc3_dat3_pb4, pex_l0_rst_n_pdd1, | |
| 76 | + pex_l0_clkreq_n_pdd2, pex_wake_n_pdd3, pex_l1_rst_n_pdd5, | |
| 77 | + pex_l1_clkreq_n_pdd6, hdmi_cec_pee3, sdmmc1_wp_n_pv3, | |
| 78 | + sdmmc3_cd_n_pv2, gpio_w2_aud_pw2, gpio_w3_aud_pw3, usb_vbus_en0_pn4, | |
| 79 | + usb_vbus_en1_pn5, sdmmc3_clk_lb_out_pee4, sdmmc3_clk_lb_in_pee5, | |
| 80 | + gmi_clk_lb, reset_out_n, kb_row16_pt0, kb_row17_pt1, usb_vbus_en2_pff1, | |
| 81 | + pff2, dp_hpd_pff0, | |
| 82 | + | |
| 83 | + drive groups: | |
| 84 | + | |
| 85 | + These all support nvidia,pull-down-strength, nvidia,pull-up-strength, | |
| 86 | + nvidia,slew-rate-rising, nvidia,slew-rate-falling. Most but not all | |
| 87 | + support nvidia,high-speed-mode, nvidia,schmitt, nvidia,low-power-mode | |
| 88 | + and nvidia,drive-type. | |
| 89 | + | |
| 90 | + ao1, ao2, at1, at2, at3, at4, at5, cdev1, cdev2, dap1, dap2, dap3, dap4, | |
| 91 | + dbg, sdio3, spi, uaa, uab, uart2, uart3, sdio1, ddc, gma, gme, gmf, gmg, | |
| 92 | + gmh, owr, uda, gpv, dev3, cec, usb_vbus_en, ao3, ao0, hv0, sdio4, ao4. | |
| 93 | + | |
| 94 | +Valid values for nvidia,functions are: | |
| 95 | + | |
| 96 | + blink, cec, cldvfs, clk12, cpu, dap, dap1, dap2, dev3, displaya, | |
| 97 | + displaya_alt, displayb, dtv, extperiph1, extperiph2, extperiph3, | |
| 98 | + gmi, gmi_alt, hda, hsi, i2c1, i2c2, i2c3, i2c4, i2cpwr, i2s0, | |
| 99 | + i2s1, i2s2, i2s3, i2s4, irda, kbc, owr, pmi, pwm0, pwm1, pwm2, pwm3, | |
| 100 | + pwron, reset_out_n, rsvd1, rsvd2, rsvd3, rsvd4, sdmmc1, sdmmc2, sdmmc3, | |
| 101 | + sdmmc4, soc, spdif, spi1, spi2, spi3, spi4, spi5, spi6, trace, uarta, | |
| 102 | + uartb, uartc, uartd, ulpi, usb, vgp1, vgp2, vgp3, vgp4, vgp5, vgp6, | |
| 103 | + vi, vi_alt1, vi_alt3, vimclk2, vimclk2_alt, sata, ccla, pe0, pe, pe1, | |
| 104 | + dp, rtck, sys, clk tmds. | |
| 105 | + | |
| 106 | +Example: | |
| 107 | + | |
| 108 | + pinmux: pinmux { | |
| 109 | + compatible = "nvidia,tegra124-pinmux"; | |
| 110 | + reg = <0x70000868 0x164 /* Pad control registers */ | |
| 111 | + 0x70003000 0x434>; /* PinMux registers */ | |
| 112 | + }; | |
| 113 | + | |
| 114 | +Example pinmux entries: | |
| 115 | + | |
| 116 | + pinctrl { | |
| 117 | + sdmmc4_default: pinmux { | |
| 118 | + sdmmc4_clk_pcc4 { | |
| 119 | + nvidia,pins = "sdmmc4_clk_pcc4", | |
| 120 | + nvidia,function = "sdmmc4"; | |
| 121 | + nvidia,pull = <TEGRA_PIN_PULL_NONE>; | |
| 122 | + nvidia,tristate = <TEGRA_PIN_DISABLE>; | |
| 123 | + }; | |
| 124 | + | |
| 125 | + sdmmc4_dat0_paa0 { | |
| 126 | + nvidia,pins = "sdmmc4_dat0_paa0", | |
| 127 | + "sdmmc4_dat1_paa1", | |
| 128 | + "sdmmc4_dat2_paa2", | |
| 129 | + "sdmmc4_dat3_paa3", | |
| 130 | + "sdmmc4_dat4_paa4", | |
| 131 | + "sdmmc4_dat5_paa5", | |
| 132 | + "sdmmc4_dat6_paa6", | |
| 133 | + "sdmmc4_dat7_paa7"; | |
| 134 | + nvidia,function = "sdmmc4"; | |
| 135 | + nvidia,pull = <TEGRA_PIN_PULL_UP>; | |
| 136 | + nvidia,tristate = <TEGRA_PIN_DISABLE>; | |
| 137 | + }; | |
| 138 | + }; | |
| 139 | + }; | |
| 140 | + | |
| 141 | + sdhci@78000400 { | |
| 142 | + pinctrl-names = "default"; | |
| 143 | + pinctrl-0 = <&sdmmc4_default>; | |
| 144 | + }; | |
| @@ -151,6 +151,8 @@ drive-push-pull - drive actively high and low · 150 unmodified lines | ||
| 151 | 151 | drive-open-drain - drive with open drain |
| 152 | 152 | drive-open-source - drive with open source |
| 153 | 153 | drive-strength - sink or source at most X mA |
| 154 | +input-enable - enable input on pin (no effect on output) | |
| 155 | +input-disable - disable input on pin (no effect on output) | |
| 154 | 156 | input-schmitt-enable - enable schmitt-trigger mode |
| 155 | 157 | input-schmitt-disable - disable schmitt-trigger mode |
| 156 | 158 | input-debounce - debounce mode with debound time X |
| @@ -158,6 +160,7 @@ low-power-enable - enable low power mode · 1 unmodified line | ||
| 158 | 160 | low-power-disable - disable low power mode |
| 159 | 161 | output-low - set the pin to output mode with low level |
| 160 | 162 | output-high - set the pin to output mode with high level |
| 163 | +slew-rate - set the slew rate | |
| 161 | 164 | |
| 162 | 165 | Some of the generic properties take arguments. For those that do, the |
| 163 | 166 | arguments are described below. |
| @@ -98,7 +98,7 @@ below for more information. · 97 unmodified lines | ||
| 98 | 98 | In case when one register changes more than one pin's mux the |
| 99 | 99 | pinctrl-single,bits need to be used which takes three parameters: |
| 100 | 100 | |
| 101 | − pinctrl-single,bits = <0xdc 0x18, 0xff>; | |
| 101 | + pinctrl-single,bits = <0xdc 0x18 0xff>; | |
| 102 | 102 | |
| 103 | 103 | Where 0xdc is the offset from the pinctrl register base address for the |
| 104 | 104 | device pinctrl register, 0x18 is the desired value, and 0xff is the sub mask to |
| @@ -0,0 +1,92 @@ | ||
| 1 | +Qualcomm MSM8974 TLMM block | |
| 2 | + | |
| 3 | +Required properties: | |
| 4 | +- compatible: "qcom,msm8x74-pinctrl" | |
| 5 | +- reg: Should be the base address and length of the TLMM block. | |
| 6 | +- interrupts: Should be the parent IRQ of the TLMM block. | |
| 7 | +- interrupt-controller: Marks the device node as an interrupt controller. | |
| 8 | +- #interrupt-cells: Should be two. | |
| 9 | +- gpio-controller: Marks the device node as a GPIO controller. | |
| 10 | +- #gpio-cells : Should be two. | |
| 11 | + The first cell is the gpio pin number and the | |
| 12 | + second cell is used for optional parameters. | |
| 13 | + | |
| 14 | +Please refer to ../gpio/gpio.txt and ../interrupt-controller/interrupts.txt for | |
| 15 | +a general description of GPIO and interrupt bindings. | |
| 16 | + | |
| 17 | +Please refer to pinctrl-bindings.txt in this directory for details of the | |
| 18 | +common pinctrl bindings used by client devices, including the meaning of the | |
| 19 | +phrase "pin configuration node". | |
| 20 | + | |
| 21 | +Qualcomm's pin configuration nodes act as a container for an abitrary number of | |
| 22 | +subnodes. Each of these subnodes represents some desired configuration for a | |
| 23 | +pin, a group, or a list of pins or groups. This configuration can include the | |
| 24 | +mux function to select on those pin(s)/group(s), and various pin configuration | |
| 25 | +parameters, such as pull-up, drive strength, etc. | |
| 26 | + | |
| 27 | +The name of each subnode is not important; all subnodes should be enumerated | |
| 28 | +and processed purely based on their content. | |
| 29 | + | |
| 30 | +Each subnode only affects those parameters that are explicitly listed. In | |
| 31 | +other words, a subnode that lists a mux function but no pin configuration | |
| 32 | +parameters implies no information about any pin configuration parameters. | |
| 33 | +Similarly, a pin subnode that describes a pullup parameter implies no | |
| 34 | +information about e.g. the mux function. | |
| 35 | + | |
| 36 | + | |
| 37 | +The following generic properties as defined in pinctrl-bindings.txt are valid | |
| 38 | +to specify in a pin configuration subnode: | |
| 39 | + pins, function, bias-disable, bias-pull-down, bias-pull,up, drive-strength. | |
| 40 | + | |
| 41 | +Non-empty subnodes must specify the 'pins' property. | |
| 42 | +Note that not all properties are valid for all pins. | |
| 43 | + | |
| 44 | + | |
| 45 | +Valid values for qcom,pins are: | |
| 46 | + gpio0-gpio145 | |
| 47 | + Supports mux, bias and drive-strength | |
| 48 | + | |
| 49 | + sdc1_clk, sdc1_cmd, sdc1_data, sdc2_clk, sdc2_cmd, sdc2_data | |
| 50 | + Supports bias and drive-strength | |
| 51 | + | |
| 52 | +Valid values for qcom,function are: | |
| 53 | + blsp_i2c2, blsp_i2c6, blsp_i2c11, blsp_spi1, blsp_uart2, blsp_uart8, slimbus | |
| 54 | + | |
| 55 | + (Note that this is not yet the complete list of functions) | |
| 56 | + | |
| 57 | + | |
| 58 | + | |
| 59 | +Example: | |
| 60 | + | |
| 61 | + msmgpio: pinctrl@fd510000 { | |
| 62 | + compatible = "qcom,msm8974-pinctrl"; | |
| 63 | + reg = <0xfd510000 0x4000>; | |
| 64 | + | |
| 65 | + gpio-controller; | |
| 66 | + #gpio-cells = <2>; | |
| 67 | + interrupt-controller; | |
| 68 | + #interrupt-cells = <2>; | |
| 69 | + interrupts = <0 208 0>; | |
| 70 | + | |
| 71 | + pinctrl-names = "default"; | |
| 72 | + pinctrl-0 = <&uart2_default>; | |
| 73 | + | |
| 74 | + uart2_default: uart2_default { | |
| 75 | + mux { | |
| 76 | + qcom,pins = "gpio4", "gpio5"; | |
| 77 | + qcom,function = "blsp_uart2"; | |
| 78 | + }; | |
| 79 | + | |
| 80 | + tx { | |
| 81 | + qcom,pins = "gpio4"; | |
| 82 | + drive-strength = <4>; | |
| 83 | + bias-disable; | |
| 84 | + }; | |
| 85 | + | |
| 86 | + rx { | |
| 87 | + qcom,pins = "gpio5"; | |
| 88 | + drive-strength = <2>; | |
| 89 | + bias-pull-up; | |
| 90 | + }; | |
| 91 | + }; | |
| 92 | + }; | |
| @@ -26,6 +26,11 @@ Optional properties: · 25 unmodified lines | ||
| 26 | 26 | - #gpio-range-cells: Mandatory when the PFC doesn't handle GPIO, forbidden |
| 27 | 27 | otherwise. Should be 3. |
| 28 | 28 | |
| 29 | + - interrupts-extended: Specify the interrupts associated with external | |
| 30 | + IRQ pins. This property is mandatory when the PFC handles GPIOs and | |
| 31 | + forbidden otherwise. When specified, it must contain one interrupt per | |
| 32 | + external IRQ, sorted by external IRQ number. | |
| 33 | + | |
| 29 | 34 | The PFC node also acts as a container for pin configuration nodes. Please refer |
| 30 | 35 | to pinctrl-bindings.txt in this directory for the definition of the term "pin |
| 31 | 36 | configuration node" and for the common pinctrl bindings used by client devices. |
| @@ -103,6 +108,15 @@ Example 1: SH73A0 (SH-Mobile AG5) pin controller node · 71 unmodified lines | ||
| 103 | 108 | <0xe605801c 0x1c>; |
| 104 | 109 | gpio-controller; |
| 105 | 110 | #gpio-cells = <2>; |
| 111 | + interrupts-extended = | |
| 112 | + <&irqpin0 0 0>, <&irqpin0 1 0>, <&irqpin0 2 0>, <&irqpin0 3 0>, | |
| 113 | + <&irqpin0 4 0>, <&irqpin0 5 0>, <&irqpin0 6 0>, <&irqpin0 7 0>, | |
| 114 | + <&irqpin1 0 0>, <&irqpin1 1 0>, <&irqpin1 2 0>, <&irqpin1 3 0>, | |
| 115 | + <&irqpin1 4 0>, <&irqpin1 5 0>, <&irqpin1 6 0>, <&irqpin1 7 0>, | |
| 116 | + <&irqpin2 0 0>, <&irqpin2 1 0>, <&irqpin2 2 0>, <&irqpin2 3 0>, | |
| 117 | + <&irqpin2 4 0>, <&irqpin2 5 0>, <&irqpin2 6 0>, <&irqpin2 7 0>, | |
| 118 | + <&irqpin3 0 0>, <&irqpin3 1 0>, <&irqpin3 2 0>, <&irqpin3 3 0>, | |
| 119 | + <&irqpin3 4 0>, <&irqpin3 5 0>, <&irqpin3 6 0>, <&irqpin3 7 0>; | |
| 106 | 120 | }; |
| 107 | 121 | |
| 108 | 122 | Example 2: A GPIO LED node that references a GPIO |
| @@ -0,0 +1,17 @@ | ||
| 1 | +Binding for NXP ISP1704 USB Charger Detection | |
| 2 | + | |
| 3 | +Required properties: | |
| 4 | +- compatible: Should contain one of the following: | |
| 5 | + * "nxp,isp1704" | |
| 6 | +- nxp,enable-gpio: Should contain a phandle + gpio-specifier | |
| 7 | + to the GPIO pin connected to the chip's enable pin. | |
| 8 | +- usb-phy: Should contain a phandle to the USB PHY | |
| 9 | + the ISP1704 is connected to. | |
| 10 | + | |
| 11 | +Example: | |
| 12 | + | |
| 13 | +isp1704 { | |
| 14 | + compatible = "nxp,isp1704"; | |
| 15 | + nxp,enable-gpio = <&gpio3 3 GPIO_ACTIVE_LOW>; | |
| 16 | + usb-phy = <&usb2_phy>; | |
| 17 | +}; | |
| @@ -0,0 +1,81 @@ | ||
| 1 | +charger-manager bindings | |
| 2 | +~~~~~~~~~~~~~~~~~~~~~~~~ | |
| 3 | + | |
| 4 | +Required properties : | |
| 5 | + - compatible : "charger-manager" | |
| 6 | + - <>-supply : for regulator consumer | |
| 7 | + - cm-num-chargers : number of chargers | |
| 8 | + - cm-chargers : name of chargers | |
| 9 | + - cm-fuel-gauge : name of battery fuel gauge | |
| 10 | + - subnode <regulator> : | |
| 11 | + - cm-regulator-name : name of charger regulator | |
| 12 | + - subnode <cable> : | |
| 13 | + - cm-cable-name : name of charger cable | |
| 14 | + - cm-cable-extcon : name of extcon dev | |
| 15 | +(optional) - cm-cable-min : minimum current of cable | |
| 16 | +(optional) - cm-cable-max : maximum current of cable | |
| 17 | + | |
| 18 | +Optional properties : | |
| 19 | + - cm-name : charger manager's name (default : "battery") | |
| 20 | + - cm-poll-mode : polling mode (enum polling_modes) | |
| 21 | + - cm-poll-interval : polling interval | |
| 22 | + - cm-battery-stat : battery status (enum data_source) | |
| 23 | + - cm-fullbatt-* : data for full battery checking | |
| 24 | + - cm-thermal-zone : name of external thermometer's thermal zone | |
| 25 | + - cm-battery-* : threshold battery temperature for charging | |
| 26 | + -cold : critical cold temperature of battery for charging | |
| 27 | + -cold-in-minus : flag that cold temerature is in minus degree | |
| 28 | + -hot : critical hot temperature of battery for charging | |
| 29 | + -temp-diff : temperature difference to allow recharging | |
| 30 | + - cm-dis/charging-max = limits of charging duration | |
| 31 | + | |
| 32 | +Example : | |
| 33 | + charger-manager@0 { | |
| 34 | + compatible = "charger-manager"; | |
| 35 | + chg-reg-supply = <&charger_regulator>; | |
| 36 | + | |
| 37 | + cm-name = "battery"; | |
| 38 | + /* Always polling ON : 30s */ | |
| 39 | + cm-poll-mode = <1>; | |
| 40 | + cm-poll-interval = <30000>; | |
| 41 | + | |
| 42 | + cm-fullbatt-vchkdrop-ms = <30000>; | |
| 43 | + cm-fullbatt-vchkdrop-volt = <150000>; | |
| 44 | + cm-fullbatt-soc = <100>; | |
| 45 | + | |
| 46 | + cm-battery-stat = <3>; | |
| 47 | + | |
| 48 | + cm-num-chargers = <3>; | |
| 49 | + cm-chargers = "charger0", "charger1", "charger2"; | |
| 50 | + | |
| 51 | + cm-fuel-gauge = "fuelgauge0"; | |
| 52 | + | |
| 53 | + cm-thermal-zone = "thermal_zone.1" | |
| 54 | + /* in deci centigrade */ | |
| 55 | + cm-battery-cold = <50>; | |
| 56 | + cm-battery-cold-in-minus; | |
| 57 | + cm-battery-hot = <800>; | |
| 58 | + cm-battery-temp-diff = <100>; | |
| 59 | + | |
| 60 | + /* Allow charging for 5hr */ | |
| 61 | + cm-charging-max = <18000000>; | |
| 62 | + /* Allow discharging for 2hr */ | |
| 63 | + cm-discharging-max = <7200000>; | |
| 64 | + | |
| 65 | + regulator@0 { | |
| 66 | + cm-regulator-name = "chg-reg"; | |
| 67 | + cable@0 { | |
| 68 | + cm-cable-name = "USB"; | |
| 69 | + cm-cable-extcon = "extcon-dev.0"; | |
| 70 | + cm-cable-min = <475000>; | |
| 71 | + cm-cable-max = <500000>; | |
| 72 | + }; | |
| 73 | + cable@1 { | |
| 74 | + cm-cable-name = "TA"; | |
| 75 | + cm-cable-extcon = "extcon-dev.0"; | |
| 76 | + cm-cable-min = <650000>; | |
| 77 | + cm-cable-max = <675000>; | |
| 78 | + }; | |
| 79 | + }; | |
| 80 | + | |
| 81 | + }; | |
| @@ -10,7 +10,6 @@ Currently defined compatibles: · 9 unmodified lines | ||
| 10 | 10 | Example: |
| 11 | 11 | |
| 12 | 12 | ethernet@11300 { |
| 13 | − device_type = "network"; | |
| 14 | 13 | compatible = "fsl,mpc8272-fcc-enet", |
| 15 | 14 | "fsl,cpm2-fcc-enet"; |
| 16 | 15 | reg = <11300 20 8400 100 11390 1>; |
| @@ -33,7 +32,6 @@ fsl,mdc-pin : pin of port C controlling mdio clock · 16 unmodified lines | ||
| 33 | 32 | |
| 34 | 33 | Example: |
| 35 | 34 | mdio@10d40 { |
| 36 | − device_type = "mdio"; | |
| 37 | 35 | compatible = "fsl,mpc8272ads-mdio-bitbang", |
| 38 | 36 | "fsl,mpc8272-mdio-bitbang", |
| 39 | 37 | "fsl,cpm2-mdio-bitbang"; |
| @@ -1,8 +1,6 @@ | ||
| 1 | 1 | * Pin configuration nodes |
| 2 | 2 | |
| 3 | 3 | Required properties: |
| 4 | −- linux,phandle : phandle of this node; likely referenced by a QE | |
| 5 | − device. | |
| 6 | 4 | - pio-map : array of pin configurations. Each pin is defined by 6 |
| 7 | 5 | integers. The six numbers are respectively: port, pin, dir, |
| 8 | 6 | open_drain, assignment, has_irq. |
| @@ -29,7 +27,6 @@ Required properties: · 20 unmodified lines | ||
| 29 | 27 | |
| 30 | 28 | Example: |
| 31 | 29 | ucc_pin@01 { |
| 32 | − linux,phandle = <140001>; | |
| 33 | 30 | pio-map = < |
| 34 | 31 | /* port pin dir open_drain assignment has_irq */ |
| 35 | 32 | 0 3 1 0 1 0 /* TxD0 */ |
| @@ -0,0 +1,33 @@ | ||
| 1 | +Atmel PWM controller | |
| 2 | + | |
| 3 | +Required properties: | |
| 4 | + - compatible: should be one of: | |
| 5 | + - "atmel,at91sam9rl-pwm" | |
| 6 | + - "atmel,sama5d3-pwm" | |
| 7 | + - reg: physical base address and length of the controller's registers | |
| 8 | + - #pwm-cells: Should be 3. See pwm.txt in this directory for a | |
| 9 | + description of the cells format. | |
| 10 | + | |
| 11 | +Example: | |
| 12 | + | |
| 13 | + pwm0: pwm@f8034000 { | |
| 14 | + compatible = "atmel,at91sam9rl-pwm"; | |
| 15 | + reg = <0xf8034000 0x400>; | |
| 16 | + #pwm-cells = <3>; | |
| 17 | + }; | |
| 18 | + | |
| 19 | + pwmleds { | |
| 20 | + compatible = "pwm-leds"; | |
| 21 | + | |
| 22 | + d1 { | |
| 23 | + label = "d1"; | |
| 24 | + pwms = <&pwm0 3 5000 0> | |
| 25 | + max-brightness = <255>; | |
| 26 | + }; | |
| 27 | + | |
| 28 | + d2 { | |
| 29 | + label = "d2"; | |
| 30 | + pwms = <&pwm0 1 5000 1> | |
| 31 | + max-brightness = <255>; | |
| 32 | + }; | |
| 33 | + }; | |
| @@ -7,6 +7,12 @@ Required properties: · 6 unmodified lines | ||
| 7 | 7 | - reg: physical base address and length of the controller's registers |
| 8 | 8 | - #pwm-cells: should be 2. See pwm.txt in this directory for a description of |
| 9 | 9 | the cells format. |
| 10 | +- clocks: Must contain one entry, for the module clock. | |
| 11 | + See ../clocks/clock-bindings.txt for details. | |
| 12 | +- resets: Must contain an entry for each entry in reset-names. | |
| 13 | + See ../reset/reset.txt for details. | |
| 14 | +- reset-names: Must include the following entries: | |
| 15 | + - pwm | |
| 10 | 16 | |
| 11 | 17 | Example: |
| 12 | 18 | |
| @@ -14,4 +20,7 @@ Example: · 1 unmodified line | ||
| 14 | 20 | compatible = "nvidia,tegra20-pwm"; |
| 15 | 21 | reg = <0x7000a000 0x100>; |
| 16 | 22 | #pwm-cells = <2>; |
| 23 | + clocks = <&tegra_car 17>; | |
| 24 | + resets = <&tegra_car 17>; | |
| 25 | + reset-names = "pwm"; | |
| 17 | 26 | }; |
| @@ -0,0 +1,58 @@ | ||
| 1 | +TI/National Semiconductor LP3943 PWM controller | |
| 2 | + | |
| 3 | +Required properties: | |
| 4 | + - compatible: "ti,lp3943-pwm" | |
| 5 | + - #pwm-cells: Should be 2. See pwm.txt in this directory for a | |
| 6 | + description of the cells format. | |
| 7 | + Note that this hardware limits the period length to the | |
| 8 | + range 6250~1600000. | |
| 9 | + - ti,pwm0 or ti,pwm1: Output pin number(s) for PWM channel 0 or 1. | |
| 10 | + 0 = output 0 | |
| 11 | + 1 = output 1 | |
| 12 | + . | |
| 13 | + . | |
| 14 | + 15 = output 15 | |
| 15 | + | |
| 16 | +Example: | |
| 17 | +PWM 0 is for RGB LED brightness control | |
| 18 | +PWM 1 is for brightness control of LP8557 backlight device | |
| 19 | + | |
| 20 | +&i2c3 { | |
| 21 | + lp3943@60 { | |
| 22 | + compatible = "ti,lp3943"; | |
| 23 | + reg = <0x60>; | |
| 24 | + | |
| 25 | + /* | |
| 26 | + * PWM 0 : output 8, 9 and 10 | |
| 27 | + * PWM 1 : output 15 | |
| 28 | + */ | |
| 29 | + pwm3943: pwm { | |
| 30 | + compatible = "ti,lp3943-pwm"; | |
| 31 | + #pwm-cells = <2>; | |
| 32 | + ti,pwm0 = <8 9 10>; | |
| 33 | + ti,pwm1 = <15>; | |
| 34 | + }; | |
| 35 | + }; | |
| 36 | + | |
| 37 | +}; | |
| 38 | + | |
| 39 | +/* LEDs control with PWM 0 of LP3943 */ | |
| 40 | +pwmleds { | |
| 41 | + compatible = "pwm-leds"; | |
| 42 | + rgb { | |
| 43 | + label = "indi::rgb"; | |
| 44 | + pwms = <&pwm3943 0 10000>; | |
| 45 | + max-brightness = <255>; | |
| 46 | + }; | |
| 47 | +}; | |
| 48 | + | |
| 49 | +&i2c4 { | |
| 50 | + /* Backlight control with PWM 1 of LP3943 */ | |
| 51 | + backlight@2c { | |
| 52 | + compatible = "ti,lp8557"; | |
| 53 | + reg = <0x2c>; | |
| 54 | + | |
| 55 | + pwms = <&pwm3943 1 10000>; | |
| 56 | + pwm-names = "lp8557"; | |
| 57 | + }; | |
| 58 | +}; | |
| @@ -0,0 +1,30 @@ | ||
| 1 | +Marvell PWM controller | |
| 2 | + | |
| 3 | +Required properties: | |
| 4 | +- compatible: should be one or more of: | |
| 5 | + - "marvell,pxa250-pwm" | |
| 6 | + - "marvell,pxa270-pwm" | |
| 7 | + - "marvell,pxa168-pwm" | |
| 8 | + - "marvell,pxa910-pwm" | |
| 9 | +- reg: Physical base address and length of the registers used by the PWM channel | |
| 10 | + Note that one device instance must be created for each PWM that is used, so the | |
| 11 | + length covers only the register window for one PWM output, not that of the | |
| 12 | + entire PWM controller. Currently length is 0x10 for all supported devices. | |
| 13 | +- #pwm-cells: Should be 1. This cell is used to specify the period in | |
| 14 | + nanoseconds. | |
| 15 | + | |
| 16 | +Example PWM device node: | |
| 17 | + | |
| 18 | +pwm0: pwm@40b00000 { | |
| 19 | + compatible = "marvell,pxa250-pwm"; | |
| 20 | + reg = <0x40b00000 0x10>; | |
| 21 | + #pwm-cells = <1>; | |
| 22 | +}; | |
| 23 | + | |
| 24 | +Example PWM client node: | |
| 25 | + | |
| 26 | +backlight { | |
| 27 | + compatible = "pwm-backlight"; | |
| 28 | + pwms = <&pwm0 5000000>; | |
| 29 | + ... | |
| 30 | +} | |
| @@ -0,0 +1,60 @@ | ||
| 1 | +ACT8865 regulator | |
| 2 | +------------------- | |
| 3 | + | |
| 4 | +Required properties: | |
| 5 | +- compatible: "active-semi,act8865" | |
| 6 | +- reg: I2C slave address | |
| 7 | + | |
| 8 | +Any standard regulator properties can be used to configure the single regulator. | |
| 9 | + | |
| 10 | +The valid names for regulators are: | |
| 11 | + DCDC_REG1, DCDC_REG2, DCDC_REG3, LDO_REG1, LDO_REG2, LDO_REG3, LDO_REG4. | |
| 12 | + | |
| 13 | +Example: | |
| 14 | +-------- | |
| 15 | + | |
| 16 | + i2c1: i2c@f0018000 { | |
| 17 | + pmic: act8865@5b { | |
| 18 | + compatible = "active-semi,act8865"; | |
| 19 | + reg = <0x5b>; | |
| 20 | + status = "disabled"; | |
| 21 | + | |
| 22 | + regulators { | |
| 23 | + vcc_1v8_reg: DCDC_REG1 { | |
| 24 | + regulator-name = "VCC_1V8"; | |
| 25 | + regulator-min-microvolt = <1800000>; | |
| 26 | + regulator-max-microvolt = <1800000>; | |
| 27 | + regulator-always-on; | |
| 28 | + }; | |
| 29 | + | |
| 30 | + vcc_1v2_reg: DCDC_REG2 { | |
| 31 | + regulator-name = "VCC_1V2"; | |
| 32 | + regulator-min-microvolt = <1100000>; | |
| 33 | + regulator-max-microvolt = <1300000>; | |
| 34 | + regulator-suspend-mem-microvolt = <1150000>; | |
| 35 | + regulator-suspend-standby-microvolt = <1150000>; | |
| 36 | + regulator-always-on; | |
| 37 | + }; | |
| 38 | + | |
| 39 | + vcc_3v3_reg: DCDC_REG3 { | |
| 40 | + regulator-name = "VCC_3V3"; | |
| 41 | + regulator-min-microvolt = <3300000>; | |
| 42 | + regulator-max-microvolt = <3300000>; | |
| 43 | + regulator-always-on; | |
| 44 | + }; | |
| 45 | + | |
| 46 | + vddana_reg: LDO_REG1 { | |
| 47 | + regulator-name = "VDDANA"; | |
| 48 | + regulator-min-microvolt = <3300000>; | |
| 49 | + regulator-max-microvolt = <3300000>; | |
| 50 | + regulator-always-on; | |
| 51 | + }; | |
| 52 | + | |
| 53 | + vddfuse_reg: LDO_REG2 { | |
| 54 | + regulator-name = "FUSE_2V5"; | |
| 55 | + regulator-min-microvolt = <2500000>; | |
| 56 | + regulator-max-microvolt = <2500000>; | |
| 57 | + }; | |
| 58 | + }; | |
| 59 | + }; | |
| 60 | + }; | |
| @@ -83,7 +83,7 @@ as per the datasheet of s5m8767. · 82 unmodified lines | ||
| 83 | 83 | |
| 84 | 84 | - LDOn |
| 85 | 85 | - valid values for n are 1 to 28 |
| 86 | − - Example: LDO0, LD01, LDO28 | |
| 86 | + - Example: LDO1, LD02, LDO28 | |
| 87 | 87 | - BUCKn |
| 88 | 88 | - valid values for n are 1 to 9. |
| 89 | 89 | - Example: BUCK1, BUCK2, BUCK9 |
| @@ -0,0 +1,27 @@ | ||
| 1 | +Haoyu Microelectronics HYM8563 Real Time Clock | |
| 2 | + | |
| 3 | +The HYM8563 provides basic rtc and alarm functionality | |
| 4 | +as well as a clock output of up to 32kHz. | |
| 5 | + | |
| 6 | +Required properties: | |
| 7 | +- compatible: should be: "haoyu,hym8563" | |
| 8 | +- reg: i2c address | |
| 9 | +- interrupts: rtc alarm/event interrupt | |
| 10 | +- #clock-cells: the value should be 0 | |
| 11 | + | |
| 12 | +Example: | |
| 13 | + | |
| 14 | +hym8563: hym8563@51 { | |
| 15 | + compatible = "haoyu,hym8563"; | |
| 16 | + reg = <0x51>; | |
| 17 | + | |
| 18 | + interrupts = <13 IRQ_TYPE_EDGE_FALLING>; | |
| 19 | + | |
| 20 | + #clock-cells = <0>; | |
| 21 | +}; | |
| 22 | + | |
| 23 | +device { | |
| 24 | +... | |
| 25 | + clocks = <&hym8563>; | |
| 26 | +... | |
| 27 | +}; | |
| @@ -0,0 +1,12 @@ | ||
| 1 | +* Maxim (Dallas) DS1742/DS1743 Real Time Clock | |
| 2 | + | |
| 3 | +Required properties: | |
| 4 | +- compatible: Should contain "maxim,ds1742". | |
| 5 | +- reg: Physical base address of the RTC and length of memory | |
| 6 | + mapped region. | |
| 7 | + | |
| 8 | +Example: | |
| 9 | + rtc: rtc@10000000 { | |
| 10 | + compatible = "maxim,ds1742"; | |
| 11 | + reg = <0x10000000 0x800>; | |
| 12 | + }; | |
| @@ -9,6 +9,8 @@ Required properties: · 8 unmodified lines | ||
| 9 | 9 | - compatible : should be "nvidia,tegra20-rtc". |
| 10 | 10 | - reg : Specifies base physical address and size of the registers. |
| 11 | 11 | - interrupts : A single interrupt specifier. |
| 12 | +- clocks : Must contain one entry, for the module clock. | |
| 13 | + See ../clocks/clock-bindings.txt for details. | |
| 12 | 14 | |
| 13 | 15 | Example: |
| 14 | 16 | |
| @@ -16,4 +18,5 @@ timer { · 1 unmodified line | ||
| 16 | 18 | compatible = "nvidia,tegra20-rtc"; |
| 17 | 19 | reg = <0x7000e000 0x100>; |
| 18 | 20 | interrupts = <0 2 0x04>; |
| 21 | + clocks = <&tegra_car 4>; | |
| 19 | 22 | }; |
| @@ -0,0 +1,17 @@ | ||
| 1 | +* sun4i/sun7i Real Time Clock | |
| 2 | + | |
| 3 | +RTC controller for the Allwinner A10/A20 | |
| 4 | + | |
| 5 | +Required properties: | |
| 6 | +- compatible : Should be "allwinner,sun4i-rtc" or "allwinner,sun7i-a20-rtc" | |
| 7 | +- reg: physical base address of the controller and length of memory mapped | |
| 8 | + region. | |
| 9 | +- interrupts: IRQ line for the RTC. | |
| 10 | + | |
| 11 | +Example: | |
| 12 | + | |
| 13 | +rtc: rtc@01c20d00 { | |
| 14 | + compatible = "allwinner,sun4i-rtc"; | |
| 15 | + reg = <0x01c20d00 0x20>; | |
| 16 | + interrupts = <24>; | |
| 17 | +}; | |
| @@ -6,6 +6,9 @@ Required properties: · 5 unmodified lines | ||
| 6 | 6 | additional mode or an USART new feature. |
| 7 | 7 | - reg: Should contain registers location and length |
| 8 | 8 | - interrupts: Should contain interrupt |
| 9 | +- clock-names: tuple listing input clock names. | |
| 10 | + Required elements: "usart" | |
| 11 | +- clocks: phandles to input clocks. | |
| 9 | 12 | |
| 10 | 13 | Optional properties: |
| 11 | 14 | - atmel,use-dma-rx: use of PDC or DMA for receiving data |
| @@ -26,6 +29,8 @@ Example: · 14 unmodified lines | ||
| 26 | 29 | compatible = "atmel,at91sam9260-usart"; |
| 27 | 30 | reg = <0xfff8c000 0x4000>; |
| 28 | 31 | interrupts = <7>; |
| 32 | + clocks = <&usart0_clk>; | |
| 33 | + clock-names = "usart"; | |
| 29 | 34 | atmel,use-dma-rx; |
| 30 | 35 | atmel,use-dma-tx; |
| 31 | 36 | }; |
| @@ -35,6 +40,8 @@ Example: · 3 unmodified lines | ||
| 35 | 40 | compatible = "atmel,at91sam9260-usart"; |
| 36 | 41 | reg = <0xf001c000 0x100>; |
| 37 | 42 | interrupts = <12 4 5>; |
| 43 | + clocks = <&usart0_clk>; | |
| 44 | + clock-names = "usart"; | |
| 38 | 45 | atmel,use-dma-rx; |
| 39 | 46 | atmel,use-dma-tx; |
| 40 | 47 | dmas = <&dma0 2 0x3>, |
| @@ -0,0 +1,28 @@ | ||
| 1 | +* Cirrus Logic CLPS711X Universal Asynchronous Receiver/Transmitter (UART) | |
| 2 | + | |
| 3 | +Required properties: | |
| 4 | +- compatible: Should be "cirrus,clps711x-uart". | |
| 5 | +- reg: Address and length of the register set for the device. | |
| 6 | +- interrupts: Should contain UART TX and RX interrupt. | |
| 7 | +- clocks: Should contain UART core clock number. | |
| 8 | +- syscon: Phandle to SYSCON node, which contain UART control bits. | |
| 9 | + | |
| 10 | +Optional properties: | |
| 11 | +- uart-use-ms: Indicate the UART has modem signal (DCD, DSR, CTS). | |
| 12 | + | |
| 13 | +Note: Each UART port should have an alias correctly numbered | |
| 14 | +in "aliases" node. | |
| 15 | + | |
| 16 | +Example: | |
| 17 | + aliases { | |
| 18 | + serial0 = &uart1; | |
| 19 | + }; | |
| 20 | + | |
| 21 | + uart1: uart@80000480 { | |
| 22 | + compatible = "cirrus,clps711x-uart"; | |
| 23 | + reg = <0x80000480 0x80>; | |
| 24 | + interrupts = <12 13>; | |
| 25 | + clocks = <&clks 11>; | |
| 26 | + syscon = <&syscon1>; | |
| 27 | + uart-use-ms; | |
| 28 | + }; | |
| @@ -4,8 +4,17 @@ Required properties: · 3 unmodified lines | ||
| 4 | 4 | - compatible : should be "nvidia,tegra30-hsuart", "nvidia,tegra20-hsuart". |
| 5 | 5 | - reg: Should contain UART controller registers location and length. |
| 6 | 6 | - interrupts: Should contain UART controller interrupts. |
| 7 | −- nvidia,dma-request-selector : The Tegra DMA controller's phandle and | |
| 8 | − request selector for this UART controller. | |
| 7 | +- clocks: Must contain one entry, for the module clock. | |
| 8 | + See ../clocks/clock-bindings.txt for details. | |
| 9 | +- resets : Must contain an entry for each entry in reset-names. | |
| 10 | + See ../reset/reset.txt for details. | |
| 11 | +- reset-names : Must include the following entries: | |
| 12 | + - serial | |
| 13 | +- dmas : Must contain an entry for each entry in clock-names. | |
| 14 | + See ../dma/dma.txt for details. | |
| 15 | +- dma-names : Must include the following entries: | |
| 16 | + - rx | |
| 17 | + - tx | |
| 9 | 18 | |
| 10 | 19 | Optional properties: |
| 11 | 20 | - nvidia,enable-modem-interrupt: Enable modem interrupts. Should be enable |
| @@ -18,7 +27,11 @@ serial@70006000 { · 6 unmodified lines | ||
| 18 | 27 | reg = <0x70006000 0x40>; |
| 19 | 28 | reg-shift = <2>; |
| 20 | 29 | interrupts = <0 36 0x04>; |
| 21 | − nvidia,dma-request-selector = <&apbdma 8>; | |
| 22 | 30 | nvidia,enable-modem-interrupt; |
| 31 | + clocks = <&tegra_car 6>; | |
| 32 | + resets = <&tegra_car 6>; | |
| 33 | + reset-names = "serial"; | |
| 34 | + dmas = <&apbdma 8>, <&apbdma 8>; | |
| 35 | + dma-names = "rx", "tx"; | |
| 23 | 36 | status = "disabled"; |
| 24 | 37 | }; |
| @@ -0,0 +1,46 @@ | ||
| 1 | +* Renesas SH-Mobile Serial Communication Interface | |
| 2 | + | |
| 3 | +Required properties: | |
| 4 | + | |
| 5 | + - compatible: Must contain one of the following: | |
| 6 | + | |
| 7 | + - "renesas,scif-r8a7790" for R8A7790 (R-Car H2) SCIF compatible UART. | |
| 8 | + - "renesas,scifa-r8a7790" for R8A7790 (R-Car H2) SCIFA compatible UART. | |
| 9 | + - "renesas,scifb-r8a7790" for R8A7790 (R-Car H2) SCIFB compatible UART. | |
| 10 | + - "renesas,hscif-r8a7790" for R8A7790 (R-Car H2) HSCIF compatible UART. | |
| 11 | + - "renesas,scif-r8a7791" for R8A7791 (R-Car M2) SCIF compatible UART. | |
| 12 | + - "renesas,scifa-r8a7791" for R8A7791 (R-Car M2) SCIFA compatible UART. | |
| 13 | + - "renesas,scifb-r8a7791" for R8A7791 (R-Car M2) SCIFB compatible UART. | |
| 14 | + - "renesas,hscif-r8a7791" for R8A7791 (R-Car M2) HSCIF compatible UART. | |
| 15 | + - "renesas,scif" for generic SCIF compatible UART. | |
| 16 | + - "renesas,scifa" for generic SCIFA compatible UART. | |
| 17 | + - "renesas,scifb" for generic SCIFB compatible UART. | |
| 18 | + - "renesas,hscif" for generic HSCIF compatible UART. | |
| 19 | + | |
| 20 | + When compatible with the generic version, nodes must list the | |
| 21 | + SoC-specific version corresponding to the platform first followed by the | |
| 22 | + generic version. | |
| 23 | + | |
| 24 | + - reg: Base address and length of the I/O registers used by the UART. | |
| 25 | + - interrupts: Must contain an interrupt-specifier for the SCIx interrupt. | |
| 26 | + | |
| 27 | + - clocks: Must contain a phandle and clock-specifier pair for each entry | |
| 28 | + in clock-names. | |
| 29 | + - clock-names: Must contain "sci_ick" for the SCIx UART interface clock. | |
| 30 | + | |
| 31 | +Note: Each enabled SCIx UART should have an alias correctly numbered in the | |
| 32 | +"aliases" node. | |
| 33 | + | |
| 34 | +Example: | |
| 35 | + aliases { | |
| 36 | + serial0 = &scifa0; | |
| 37 | + }; | |
| 38 | + | |
| 39 | + scifa0: serial@e6c40000 { | |
| 40 | + compatible = "renesas,scifa-r8a7790", "renesas,scifa-generic"; | |
| 41 | + reg = <0 0xe6c40000 0 64>; | |
| 42 | + interrupt-parent = <&gic>; | |
| 43 | + interrupts = <0 144 IRQ_TYPE_LEVEL_HIGH>; | |
| 44 | + clocks = <&mstp2_clks R8A7790_CLK_SCIFA0>; | |
| 45 | + clock-names = "sci_ick"; | |
| 46 | + }; | |
| @@ -0,0 +1,26 @@ | ||
| 1 | +* VIA VT8500 and WonderMedia WM8xxx UART Controller | |
| 2 | + | |
| 3 | +Required properties: | |
| 4 | +- compatible: should be "via,vt8500-uart" | |
| 5 | + | |
| 6 | +- reg: base physical address of the controller and length of memory mapped | |
| 7 | + region. | |
| 8 | + | |
| 9 | +- interrupts: hardware interrupt number | |
| 10 | + | |
| 11 | +- clocks: shall be the input parent clock phandle for the clock. This should | |
| 12 | + be the 24Mhz reference clock. | |
| 13 | + | |
| 14 | +Aliases may be defined to ensure the correct ordering of the uarts. | |
| 15 | + | |
| 16 | +Example: | |
| 17 | + aliases { | |
| 18 | + serial0 = &uart0; | |
| 19 | + }; | |
| 20 | + | |
| 21 | + uart0: serial@d8200000 { | |
| 22 | + compatible = "via,vt8500-uart"; | |
| 23 | + reg = <0xd8200000 0x1040>; | |
| 24 | + interrupts = <32>; | |
| 25 | + clocks = <&clkuart0>; | |
| 26 | + }; | |
| @@ -0,0 +1,31 @@ | ||
| 1 | +ADI AXI-I2S controller | |
| 2 | + | |
| 3 | +Required properties: | |
| 4 | + - compatible : Must be "adi,axi-i2s-1.00.a" | |
| 5 | + - reg : Must contain I2S core's registers location and length | |
| 6 | + - clocks : Pairs of phandle and specifier referencing the controller's clocks. | |
| 7 | + The controller expects two clocks, the clock used for the AXI interface and | |
| 8 | + the clock used as the sampling rate reference clock sample. | |
| 9 | + - clock-names : "axi" for the clock to the AXI interface, "ref" for the sample | |
| 10 | + rate reference clock. | |
| 11 | + - dmas: Pairs of phandle and specifier for the DMA channels that are used by | |
| 12 | + the core. The core expects two dma channels, one for transmit and one for | |
| 13 | + receive. | |
| 14 | + - dma-names : "tx" for the transmit channel, "rx" for the receive channel. | |
| 15 | + | |
| 16 | +For more details on the 'dma', 'dma-names', 'clock' and 'clock-names' properties | |
| 17 | +please check: | |
| 18 | + * resource-names.txt | |
| 19 | + * clock/clock-bindings.txt | |
| 20 | + * dma/dma.txt | |
| 21 | + | |
| 22 | +Example: | |
| 23 | + | |
| 24 | + i2s: i2s@0x77600000 { | |
| 25 | + compatible = "adi,axi-i2s-1.00.a"; | |
| 26 | + reg = <0x77600000 0x1000>; | |
| 27 | + clocks = <&clk 15>, <&audio_clock>; | |
| 28 | + clock-names = "axi", "ref"; | |
| 29 | + dmas = <&ps7_dma 0>, <&ps7_dma 1>; | |
| 30 | + dma-names = "tx", "rx"; | |
| 31 | + }; | |
| @@ -0,0 +1,30 @@ | ||
| 1 | +ADI AXI-SPDIF controller | |
| 2 | + | |
| 3 | +Required properties: | |
| 4 | + - compatible : Must be "adi,axi-spdif-1.00.a" | |
| 5 | + - reg : Must contain SPDIF core's registers location and length | |
| 6 | + - clocks : Pairs of phandle and specifier referencing the controller's clocks. | |
| 7 | + The controller expects two clocks, the clock used for the AXI interface and | |
| 8 | + the clock used as the sampling rate reference clock sample. | |
| 9 | + - clock-names: "axi" for the clock to the AXI interface, "ref" for the sample | |
| 10 | + rate reference clock. | |
| 11 | + - dmas: Pairs of phandle and specifier for the DMA channel that is used by | |
| 12 | + the core. The core expects one dma channel for transmit. | |
| 13 | + - dma-names : Must be "tx" | |
| 14 | + | |
| 15 | +For more details on the 'dma', 'dma-names', 'clock' and 'clock-names' properties | |
| 16 | +please check: | |
| 17 | + * resource-names.txt | |
| 18 | + * clock/clock-bindings.txt | |
| 19 | + * dma/dma.txt | |
| 20 | + | |
| 21 | +Example: | |
| 22 | + | |
| 23 | + spdif: spdif@0x77400000 { | |
| 24 | + compatible = "adi,axi-spdif-tx-1.00.a"; | |
| 25 | + reg = <0x77600000 0x1000>; | |
| 26 | + clocks = <&clk 15>, <&audio_clock>; | |
| 27 | + clock-names = "axi", "ref"; | |
| 28 | + dmas = <&ps7_dma 0>; | |
| 29 | + dma-names = "tx"; | |
| 30 | + }; | |
| @@ -0,0 +1,25 @@ | ||
| 1 | +* Broadcom BCM2835 SoC I2S/PCM module | |
| 2 | + | |
| 3 | +Required properties: | |
| 4 | +- compatible: "brcm,bcm2835-i2s" | |
| 5 | +- reg: A list of base address and size entries: | |
| 6 | + * The first entry should cover the PCM registers | |
| 7 | + * The second entry should cover the PCM clock registers | |
| 8 | +- dmas: List of DMA controller phandle and DMA request line ordered pairs. | |
| 9 | +- dma-names: Identifier string for each DMA request line in the dmas property. | |
| 10 | + These strings correspond 1:1 with the ordered pairs in dmas. | |
| 11 | + | |
| 12 | + One of the DMA channels will be responsible for transmission (should be | |
| 13 | + named "tx") and one for reception (should be named "rx"). | |
| 14 | + | |
| 15 | +Example: | |
| 16 | + | |
| 17 | +bcm2835_i2s: i2s@7e203000 { | |
| 18 | + compatible = "brcm,bcm2835-i2s"; | |
| 19 | + reg = <0x7e203000 0x20>, | |
| 20 | + <0x7e101098 0x02>; | |
| 21 | + | |
| 22 | + dmas = <&dma 2>, | |
| 23 | + <&dma 3>; | |
| 24 | + dma-names = "tx", "rx"; | |
| 25 | +}; | |
| @@ -0,0 +1,46 @@ | ||
| 1 | +CS42L52 audio CODEC | |
| 2 | + | |
| 3 | +Required properties: | |
| 4 | + | |
| 5 | + - compatible : "cirrus,cs42l52" | |
| 6 | + | |
| 7 | + - reg : the I2C address of the device for I2C | |
| 8 | + | |
| 9 | +Optional properties: | |
| 10 | + | |
| 11 | + - cirrus,reset-gpio : GPIO controller's phandle and the number | |
| 12 | + of the GPIO used to reset the codec. | |
| 13 | + | |
| 14 | + - cirrus,chgfreq-divisor : Values used to set the Charge Pump Frequency. | |
| 15 | + Allowable values of 0x00 through 0x0F. These are raw values written to the | |
| 16 | + register, not the actual frequency. The frequency is determined by the following. | |
| 17 | + Frequency = (64xFs)/(N+2) | |
| 18 | + N = chgfreq_val | |
| 19 | + Fs = Sample Rate (variable) | |
| 20 | + | |
| 21 | + - cirrus,mica-differential-cfg : boolean, If present, then the MICA input is configured | |
| 22 | + as a differential input. If not present then the MICA input is configured as | |
| 23 | + Single-ended input. Single-ended mode allows for MIC1 or MIC2 muxing for input. | |
| 24 | + | |
| 25 | + - cirrus,micb-differential-cfg : boolean, If present, then the MICB input is configured | |
| 26 | + as a differential input. If not present then the MICB input is configured as | |
| 27 | + Single-ended input. Single-ended mode allows for MIC1 or MIC2 muxing for input. | |
| 28 | + | |
| 29 | + - cirrus,micbias-lvl: Set the output voltage level on the MICBIAS Pin | |
| 30 | + 0 = 0.5 x VA | |
| 31 | + 1 = 0.6 x VA | |
| 32 | + 2 = 0.7 x VA | |
| 33 | + 3 = 0.8 x VA | |
| 34 | + 4 = 0.83 x VA | |
| 35 | + 5 = 0.91 x VA | |
| 36 | + | |
| 37 | +Example: | |
| 38 | + | |
| 39 | +codec: codec@4a { | |
| 40 | + compatible = "cirrus,cs42l52"; | |
| 41 | + reg = <0x4a>; | |
| 42 | + reset-gpio = <&gpio 10 0>; | |
| 43 | + cirrus,chgfreq-divisor = <0x05>; | |
| 44 | + cirrus.mica-differential-cfg; | |
| 45 | + cirrus,micbias-lvl = <5>; | |
| 46 | +}; | |
| @@ -4,7 +4,8 @@ Required properties: · 3 unmodified lines | ||
| 4 | 4 | - compatible : |
| 5 | 5 | "ti,dm646x-mcasp-audio" : for DM646x platforms |
| 6 | 6 | "ti,da830-mcasp-audio" : for both DA830 & DA850 platforms |
| 7 | − "ti,am33xx-mcasp-audio" : for AM33xx platforms (AM33xx, TI81xx) | |
| 7 | + "ti,am33xx-mcasp-audio" : for AM33xx platforms (AM33xx, AM43xx, TI81xx) | |
| 8 | + "ti,dra7-mcasp-audio" : for DRA7xx platforms | |
| 8 | 9 | |
| 9 | 10 | - reg : Should contain reg specifiers for the entries in the reg-names property. |
| 10 | 11 | - reg-names : Should contain: |
| @@ -36,7 +37,8 @@ Optional properties: · 25 unmodified lines | ||
| 36 | 37 | - pinctrl-0: Should specify pin control group used for this controller. |
| 37 | 38 | - pinctrl-names: Should contain only one value - "default", for more details |
| 38 | 39 | please refer to pinctrl-bindings.txt |
| 39 | − | |
| 40 | +- fck_parent : Should contain a valid clock name which will be used as parent | |
| 41 | + for the McASP fck | |
| 40 | 42 | |
| 41 | 43 | Example: |
| 42 | 44 | |
| @@ -0,0 +1,50 @@ | ||
| 1 | +Freescale Enhanced Serial Audio Interface (ESAI) Controller | |
| 2 | + | |
| 3 | +The Enhanced Serial Audio Interface (ESAI) provides a full-duplex serial port | |
| 4 | +for serial communication with a variety of serial devices, including industry | |
| 5 | +standard codecs, Sony/Phillips Digital Interface (S/PDIF) transceivers, and | |
| 6 | +other DSPs. It has up to six transmitters and four receivers. | |
| 7 | + | |
| 8 | +Required properties: | |
| 9 | + | |
| 10 | + - compatible : Compatible list, must contain "fsl,imx35-esai". | |
| 11 | + | |
| 12 | + - reg : Offset and length of the register set for the device. | |
| 13 | + | |
| 14 | + - interrupts : Contains the spdif interrupt. | |
| 15 | + | |
| 16 | + - dmas : Generic dma devicetree binding as described in | |
| 17 | + Documentation/devicetree/bindings/dma/dma.txt. | |
| 18 | + | |
| 19 | + - dma-names : Two dmas have to be defined, "tx" and "rx". | |
| 20 | + | |
| 21 | + - clocks: Contains an entry for each entry in clock-names. | |
| 22 | + | |
| 23 | + - clock-names : Includes the following entries: | |
| 24 | + "core" The core clock used to access registers | |
| 25 | + "extal" The esai baud clock for esai controller used to derive | |
| 26 | + HCK, SCK and FS. | |
| 27 | + "fsys" The system clock derived from ahb clock used to derive | |
| 28 | + HCK, SCK and FS. | |
| 29 | + | |
| 30 | + - fsl,fifo-depth: The number of elements in the transmit and receive FIFOs. | |
| 31 | + This number is the maximum allowed value for TFCR[TFWM] or RFCR[RFWM]. | |
| 32 | + | |
| 33 | + - fsl,esai-synchronous: This is a boolean property. If present, indicating | |
| 34 | + that ESAI would work in the synchronous mode, which means all the settings | |
| 35 | + for Receiving would be duplicated from Transmition related registers. | |
| 36 | + | |
| 37 | +Example: | |
| 38 | + | |
| 39 | +esai: esai@02024000 { | |
| 40 | + compatible = "fsl,imx35-esai"; | |
| 41 | + reg = <0x02024000 0x4000>; | |
| 42 | + interrupts = <0 51 0x04>; | |
| 43 | + clocks = <&clks 208>, <&clks 118>, <&clks 208>; | |
| 44 | + clock-names = "core", "extal", "fsys"; | |
| 45 | + dmas = <&sdma 23 21 0>, <&sdma 24 21 0>; | |
| 46 | + dma-names = "rx", "tx"; | |
| 47 | + fsl,fifo-depth = <128>; | |
| 48 | + fsl,esai-synchronous; | |
| 49 | + status = "disabled"; | |
| 50 | +}; | |
| @@ -4,7 +4,12 @@ The SSI is a serial device that communicates with audio codecs. It can · 3 unmodified lines | ||
| 4 | 4 | be programmed in AC97, I2S, left-justified, or right-justified modes. |
| 5 | 5 | |
| 6 | 6 | Required properties: |
| 7 | −- compatible: Compatible list, contains "fsl,ssi". | |
| 7 | +- compatible: Compatible list, should contain one of the following | |
| 8 | + compatibles: | |
| 9 | + fsl,mpc8610-ssi | |
| 10 | + fsl,imx51-ssi | |
| 11 | + fsl,imx35-ssi | |
| 12 | + fsl,imx21-ssi | |
| 8 | 13 | - cell-index: The SSI, <0> = SSI1, <1> = SSI2, and so on. |
| 9 | 14 | - reg: Offset and length of the register set for the device. |
| 10 | 15 | - interrupts: <a b> where a is the interrupt number and b is a |
| @@ -0,0 +1,40 @@ | ||
| 1 | +Freescale Synchronous Audio Interface (SAI). | |
| 2 | + | |
| 3 | +The SAI is based on I2S module that used communicating with audio codecs, | |
| 4 | +which provides a synchronous audio interface that supports fullduplex | |
| 5 | +serial interfaces with frame synchronization such as I2S, AC97, TDM, and | |
| 6 | +codec/DSP interfaces. | |
| 7 | + | |
| 8 | + | |
| 9 | +Required properties: | |
| 10 | +- compatible: Compatible list, contains "fsl,vf610-sai". | |
| 11 | +- reg: Offset and length of the register set for the device. | |
| 12 | +- clocks: Must contain an entry for each entry in clock-names. | |
| 13 | +- clock-names : Must include the "sai" entry. | |
| 14 | +- dmas : Generic dma devicetree binding as described in | |
| 15 | + Documentation/devicetree/bindings/dma/dma.txt. | |
| 16 | +- dma-names : Two dmas have to be defined, "tx" and "rx". | |
| 17 | +- pinctrl-names: Must contain a "default" entry. | |
| 18 | +- pinctrl-NNN: One property must exist for each entry in pinctrl-names. | |
| 19 | + See ../pinctrl/pinctrl-bindings.txt for details of the property values. | |
| 20 | +- big-endian-regs: If this property is absent, the little endian mode will | |
| 21 | + be in use as default, or the big endian mode will be in use for all the | |
| 22 | + device registers. | |
| 23 | +- big-endian-data: If this property is absent, the little endian mode will | |
| 24 | + be in use as default, or the big endian mode will be in use for all the | |
| 25 | + fifo data. | |
| 26 | + | |
| 27 | +Example: | |
| 28 | +sai2: sai@40031000 { | |
| 29 | + compatible = "fsl,vf610-sai"; | |
| 30 | + reg = <0x40031000 0x1000>; | |
| 31 | + pinctrl-names = "default"; | |
| 32 | + pinctrl-0 = <&pinctrl_sai2_1>; | |
| 33 | + clocks = <&clks VF610_CLK_SAI2>; | |
| 34 | + clock-names = "sai"; | |
| 35 | + dma-names = "tx", "rx"; | |
| 36 | + dmas = <&edma0 0 VF610_EDMA_MUXID0_SAI2_TX>, | |
| 37 | + <&edma0 0 VF610_EDMA_MUXID0_SAI2_RX>; | |
| 38 | + big-endian-regs; | |
| 39 | + big-endian-data; | |
| 40 | +}; | |
| @@ -0,0 +1,17 @@ | ||
| 1 | +Device-Tree bindings for dummy HDMI codec | |
| 2 | + | |
| 3 | +Required properties: | |
| 4 | + - compatible: should be "linux,hdmi-audio". | |
| 5 | + | |
| 6 | +CODEC output pins: | |
| 7 | + * TX | |
| 8 | + | |
| 9 | +CODEC input pins: | |
| 10 | + * RX | |
| 11 | + | |
| 12 | +Example node: | |
| 13 | + | |
| 14 | + hdmi_audio: hdmi_audio@0 { | |
| 15 | + compatible = "linux,hdmi-audio"; | |
| 16 | + status = "okay"; | |
| 17 | + }; | |
| @@ -0,0 +1,43 @@ | ||
| 1 | +MAX98090 audio CODEC | |
| 2 | + | |
| 3 | +This device supports I2C only. | |
| 4 | + | |
| 5 | +Required properties: | |
| 6 | + | |
| 7 | +- compatible : "maxim,max98090". | |
| 8 | + | |
| 9 | +- reg : The I2C address of the device. | |
| 10 | + | |
| 11 | +- interrupts : The CODEC's interrupt output. | |
| 12 | + | |
| 13 | +Pins on the device (for linking into audio routes): | |
| 14 | + | |
| 15 | + * MIC1 | |
| 16 | + * MIC2 | |
| 17 | + * DMICL | |
| 18 | + * DMICR | |
| 19 | + * IN1 | |
| 20 | + * IN2 | |
| 21 | + * IN3 | |
| 22 | + * IN4 | |
| 23 | + * IN5 | |
| 24 | + * IN6 | |
| 25 | + * IN12 | |
| 26 | + * IN34 | |
| 27 | + * IN56 | |
| 28 | + * HPL | |
| 29 | + * HPR | |
| 30 | + * SPKL | |
| 31 | + * SPKR | |
| 32 | + * RCVL | |
| 33 | + * RCVR | |
| 34 | + * MICBIAS | |
| 35 | + | |
| 36 | +Example: | |
| 37 | + | |
| 38 | +audio-codec@10 { | |
| 39 | + compatible = "maxim,max98090"; | |
| 40 | + reg = <0x10>; | |
| 41 | + interrupt-parent = <&gpio>; | |
| 42 | + interrupts = <TEGRA_GPIO(H, 4) GPIO_ACTIVE_HIGH>; | |
| 43 | +}; | |
| @@ -3,10 +3,11 @@ NVIDIA Tegra audio complex · 2 unmodified lines | ||
| 3 | 3 | Required properties: |
| 4 | 4 | - compatible : "nvidia,tegra-audio-alc5632" |
| 5 | 5 | - clocks : Must contain an entry for each entry in clock-names. |
| 6 | + See ../clocks/clock-bindings.txt for details. | |
| 6 | 7 | - clock-names : Must include the following entries: |
| 7 | − "pll_a" (The Tegra clock of that name), | |
| 8 | − "pll_a_out0" (The Tegra clock of that name), | |
| 9 | − "mclk" (The Tegra cdev1/extern1 clock, which feeds the CODEC's mclk) | |
| 8 | + - pll_a | |
| 9 | + - pll_a_out0 | |
| 10 | + - mclk (The Tegra cdev1/extern1 clock, which feeds the CODEC's mclk) | |
| 10 | 11 | - nvidia,model : The user-visible name of this sound complex. |
| 11 | 12 | - nvidia,audio-routing : A list of the connections between audio components. |
| 12 | 13 | Each entry is a pair of strings, the first being the connection's sink, |
| @@ -0,0 +1,51 @@ | ||
| 1 | +NVIDIA Tegra audio complex, with MAX98090 CODEC | |
| 2 | + | |
| 3 | +Required properties: | |
| 4 | +- compatible : "nvidia,tegra-audio-max98090" | |
| 5 | +- clocks : Must contain an entry for each entry in clock-names. | |
| 6 | + See ../clocks/clock-bindings.txt for details. | |
| 7 | +- clock-names : Must include the following entries: | |
| 8 | + - pll_a | |
| 9 | + - pll_a_out0 | |
| 10 | + - mclk (The Tegra cdev1/extern1 clock, which feeds the CODEC's mclk) | |
| 11 | +- nvidia,model : The user-visible name of this sound complex. | |
| 12 | +- nvidia,audio-routing : A list of the connections between audio components. | |
| 13 | + Each entry is a pair of strings, the first being the connection's sink, | |
| 14 | + the second being the connection's source. Valid names for sources and | |
| 15 | + sinks are the MAX98090's pins (as documented in its binding), and the jacks | |
| 16 | + on the board: | |
| 17 | + | |
| 18 | + * Headphones | |
| 19 | + * Speakers | |
| 20 | + * Mic Jack | |
| 21 | + | |
| 22 | +- nvidia,i2s-controller : The phandle of the Tegra I2S controller that's | |
| 23 | + connected to the CODEC. | |
| 24 | +- nvidia,audio-codec : The phandle of the MAX98090 audio codec. | |
| 25 | + | |
| 26 | +Optional properties: | |
| 27 | +- nvidia,hp-det-gpios : The GPIO that detect headphones are plugged in | |
| 28 | + | |
| 29 | +Example: | |
| 30 | + | |
| 31 | +sound { | |
| 32 | + compatible = "nvidia,tegra-audio-max98090-venice2", | |
| 33 | + "nvidia,tegra-audio-max98090"; | |
| 34 | + nvidia,model = "NVIDIA Tegra Venice2"; | |
| 35 | + | |
| 36 | + nvidia,audio-routing = | |
| 37 | + "Headphones", "HPR", | |
| 38 | + "Headphones", "HPL", | |
| 39 | + "Speakers", "SPKR", | |
| 40 | + "Speakers", "SPKL", | |
| 41 | + "Mic Jack", "MICBIAS", | |
| 42 | + "IN34", "Mic Jack"; | |
| 43 | + | |
| 44 | + nvidia,i2s-controller = <&tegra_i2s1>; | |
| 45 | + nvidia,audio-codec = <&acodec>; | |
| 46 | + | |
| 47 | + clocks = <&tegra_car TEGRA124_CLK_PLL_A>, | |
| 48 | + <&tegra_car TEGRA124_CLK_PLL_A_OUT0>, | |
| 49 | + <&tegra_car TEGRA124_CLK_EXTERN1>; | |
| 50 | + clock-names = "pll_a", "pll_a_out0", "mclk"; | |
| 51 | +}; | |
| @@ -3,10 +3,11 @@ NVIDIA Tegra audio complex, with RT5640 CODEC · 2 unmodified lines | ||
| 3 | 3 | Required properties: |
| 4 | 4 | - compatible : "nvidia,tegra-audio-rt5640" |
| 5 | 5 | - clocks : Must contain an entry for each entry in clock-names. |
| 6 | + See ../clocks/clock-bindings.txt for details. | |
| 6 | 7 | - clock-names : Must include the following entries: |
| 7 | − "pll_a" (The Tegra clock of that name), | |
| 8 | − "pll_a_out0" (The Tegra clock of that name), | |
| 9 | − "mclk" (The Tegra cdev1/extern1 clock, which feeds the CODEC's mclk) | |
| 8 | + - pll_a | |
| 9 | + - pll_a_out0 | |
| 10 | + - mclk (The Tegra cdev1/extern1 clock, which feeds the CODEC's mclk) | |
| 10 | 11 | - nvidia,model : The user-visible name of this sound complex. |
| 11 | 12 | - nvidia,audio-routing : A list of the connections between audio components. |
| 12 | 13 | Each entry is a pair of strings, the first being the connection's sink, |
| @@ -3,10 +3,11 @@ NVIDIA Tegra audio complex · 2 unmodified lines | ||
| 3 | 3 | Required properties: |
| 4 | 4 | - compatible : "nvidia,tegra-audio-wm8753" |
| 5 | 5 | - clocks : Must contain an entry for each entry in clock-names. |
| 6 | + See ../clocks/clock-bindings.txt for details. | |
| 6 | 7 | - clock-names : Must include the following entries: |
| 7 | − "pll_a" (The Tegra clock of that name), | |
| 8 | − "pll_a_out0" (The Tegra clock of that name), | |
| 9 | − "mclk" (The Tegra cdev1/extern1 clock, which feeds the CODEC's mclk) | |
| 8 | + - pll_a | |
| 9 | + - pll_a_out0 | |
| 10 | + - mclk (The Tegra cdev1/extern1 clock, which feeds the CODEC's mclk) | |
| 10 | 11 | - nvidia,model : The user-visible name of this sound complex. |
| 11 | 12 | - nvidia,audio-routing : A list of the connections between audio components. |
| 12 | 13 | Each entry is a pair of strings, the first being the connection's sink, |
| @@ -3,10 +3,11 @@ NVIDIA Tegra audio complex · 2 unmodified lines | ||
| 3 | 3 | Required properties: |
| 4 | 4 | - compatible : "nvidia,tegra-audio-wm8903" |
| 5 | 5 | - clocks : Must contain an entry for each entry in clock-names. |
| 6 | + See ../clocks/clock-bindings.txt for details. | |
| 6 | 7 | - clock-names : Must include the following entries: |
| 7 | − "pll_a" (The Tegra clock of that name), | |
| 8 | − "pll_a_out0" (The Tegra clock of that name), | |
| 9 | − "mclk" (The Tegra cdev1/extern1 clock, which feeds the CODEC's mclk) | |
| 8 | + - pll_a | |
| 9 | + - pll_a_out0 | |
| 10 | + - mclk (The Tegra cdev1/extern1 clock, which feeds the CODEC's mclk) | |
| 10 | 11 | - nvidia,model : The user-visible name of this sound complex. |
| 11 | 12 | - nvidia,audio-routing : A list of the connections between audio components. |
| 12 | 13 | Each entry is a pair of strings, the first being the connection's sink, |
| @@ -3,10 +3,11 @@ NVIDIA Tegra audio complex · 2 unmodified lines | ||
| 3 | 3 | Required properties: |
| 4 | 4 | - compatible : "nvidia,tegra-audio-wm9712" |
| 5 | 5 | - clocks : Must contain an entry for each entry in clock-names. |
| 6 | + See ../clocks/clock-bindings.txt for details. | |
| 6 | 7 | - clock-names : Must include the following entries: |
| 7 | − "pll_a" (The Tegra clock of that name), | |
| 8 | − "pll_a_out0" (The Tegra clock of that name), | |
| 9 | − "mclk" (The Tegra cdev1/extern1 clock, which feeds the CODEC's mclk) | |
| 8 | + - pll_a | |
| 9 | + - pll_a_out0 | |
| 10 | + - mclk (The Tegra cdev1/extern1 clock, which feeds the CODEC's mclk) | |
| 10 | 11 | - nvidia,model : The user-visible name of this sound complex. |
| 11 | 12 | - nvidia,audio-routing : A list of the connections between audio components. |
| 12 | 13 | Each entry is a pair of strings, the first being the connection's sink, |
| @@ -4,19 +4,33 @@ Required properties: · 3 unmodified lines | ||
| 4 | 4 | - compatible : "nvidia,tegra20-ac97" |
| 5 | 5 | - reg : Should contain AC97 controller registers location and length |
| 6 | 6 | - interrupts : Should contain AC97 interrupt |
| 7 | −- nvidia,dma-request-selector : The Tegra DMA controller's phandle and | |
| 8 | − request selector for the AC97 controller | |
| 7 | +- resets : Must contain an entry for each entry in reset-names. | |
| 8 | + See ../reset/reset.txt for details. | |
| 9 | +- reset-names : Must include the following entries: | |
| 10 | + - ac97 | |
| 11 | +- dmas : Must contain an entry for each entry in clock-names. | |
| 12 | + See ../dma/dma.txt for details. | |
| 13 | +- dma-names : Must include the following entries: | |
| 14 | + - rx | |
| 15 | + - tx | |
| 16 | +- clocks : Must contain one entry, for the module clock. | |
| 17 | + See ../clocks/clock-bindings.txt for details. | |
| 9 | 18 | - nvidia,codec-reset-gpio : The Tegra GPIO controller's phandle and the number |
| 10 | 19 | of the GPIO used to reset the external AC97 codec |
| 11 | 20 | - nvidia,codec-sync-gpio : The Tegra GPIO controller's phandle and the number |
| 12 | 21 | of the GPIO corresponding with the AC97 DAP _FS line |
| 22 | + | |
| 13 | 23 | Example: |
| 14 | 24 | |
| 15 | 25 | ac97@70002000 { |
| 16 | 26 | compatible = "nvidia,tegra20-ac97"; |
| 17 | 27 | reg = <0x70002000 0x200>; |
| 18 | 28 | interrupts = <0 81 0x04>; |
| 19 | − nvidia,dma-request-selector = <&apbdma 12>; | |
| 20 | 29 | nvidia,codec-reset-gpio = <&gpio 170 0>; |
| 21 | 30 | nvidia,codec-sync-gpio = <&gpio 120 0>; |
| 31 | + clocks = <&tegra_car 3>; | |
| 32 | + resets = <&tegra_car 3>; | |
| 33 | + reset-names = "ac97"; | |
| 34 | + dmas = <&apbdma 12>, <&apbdma 12>; | |
| 35 | + dma-names = "rx", "tx"; | |
| 22 | 36 | }; |
| @@ -4,8 +4,17 @@ Required properties: · 3 unmodified lines | ||
| 4 | 4 | - compatible : "nvidia,tegra20-i2s" |
| 5 | 5 | - reg : Should contain I2S registers location and length |
| 6 | 6 | - interrupts : Should contain I2S interrupt |
| 7 | −- nvidia,dma-request-selector : The Tegra DMA controller's phandle and | |
| 8 | − request selector for this I2S controller | |
| 7 | +- resets : Must contain an entry for each entry in reset-names. | |
| 8 | + See ../reset/reset.txt for details. | |
| 9 | +- reset-names : Must include the following entries: | |
| 10 | + - i2s | |
| 11 | +- dmas : Must contain an entry for each entry in clock-names. | |
| 12 | + See ../dma/dma.txt for details. | |
| 13 | +- dma-names : Must include the following entries: | |
| 14 | + - rx | |
| 15 | + - tx | |
| 16 | +- clocks : Must contain one entry, for the module clock. | |
| 17 | + See ../clocks/clock-bindings.txt for details. | |
| 9 | 18 | |
| 10 | 19 | Example: |
| 11 | 20 | |
| @@ -13,5 +22,9 @@ i2s@70002800 { · 1 unmodified line | ||
| 13 | 22 | compatible = "nvidia,tegra20-i2s"; |
| 14 | 23 | reg = <0x70002800 0x200>; |
| 15 | 24 | interrupts = < 45 >; |
| 16 | − nvidia,dma-request-selector = < &apbdma 2 >; | |
| 25 | + clocks = <&tegra_car 11>; | |
| 26 | + resets = <&tegra_car 11>; | |
| 27 | + reset-names = "i2s"; | |
| 28 | + dmas = <&apbdma 21>, <&apbdma 21>; | |
| 29 | + dma-names = "rx", "tx"; | |
| 17 | 30 | }; |
| @@ -7,18 +7,48 @@ Required properties: · 6 unmodified lines | ||
| 7 | 7 | - Tegra30 requires 2 entries, for the APBIF and AHUB/AUDIO register blocks. |
| 8 | 8 | - Tegra114 requires an additional entry, for the APBIF2 register block. |
| 9 | 9 | - interrupts : Should contain AHUB interrupt |
| 10 | −- nvidia,dma-request-selector : A list of the DMA channel specifiers. Each | |
| 11 | − entry contains the Tegra DMA controller's phandle and request selector. | |
| 12 | − If a single entry is present, the request selectors for the channels are | |
| 13 | − assumed to be contiguous, and increment from this value. | |
| 14 | − If multiple values are given, one value must be given per channel. | |
| 15 | −- clocks : Must contain an entry for each required entry in clock-names. | |
| 10 | +- clocks : Must contain an entry for each entry in clock-names. | |
| 11 | + See ../clocks/clock-bindings.txt for details. | |
| 16 | 12 | - clock-names : Must include the following entries: |
| 17 | − - Tegra30: Requires d_audio, apbif, i2s0, i2s1, i2s2, i2s3, i2s4, dam0, | |
| 18 | − dam1, dam2, spdif_in. | |
| 19 | − - Tegra114: Additionally requires amx, adx. | |
| 13 | + - d_audio | |
| 14 | + - apbif | |
| 15 | +- resets : Must contain an entry for each entry in reset-names. | |
| 16 | + See ../reset/reset.txt for details. | |
| 17 | +- reset-names : Must include the following entries: | |
| 18 | + Tegra30 and later: | |
| 19 | + - d_audio | |
| 20 | + - apbif | |
| 21 | + - i2s0 | |
| 22 | + - i2s1 | |
| 23 | + - i2s2 | |
| 24 | + - i2s3 | |
| 25 | + - i2s4 | |
| 26 | + - dam0 | |
| 27 | + - dam1 | |
| 28 | + - dam2 | |
| 29 | + - spdif | |
| 30 | + Tegra114 and later additionally require: | |
| 31 | + - amx | |
| 32 | + - adx | |
| 33 | + Tegra124 and later additionally require: | |
| 34 | + - amx1 | |
| 35 | + - adx1 | |
| 36 | + - afc0 | |
| 37 | + - afc1 | |
| 38 | + - afc2 | |
| 39 | + - afc3 | |
| 40 | + - afc4 | |
| 41 | + - afc5 | |
| 20 | 42 | - ranges : The bus address mapping for the configlink register bus. |
| 21 | 43 | Can be empty since the mapping is 1:1. |
| 44 | +- dmas : Must contain an entry for each entry in clock-names. | |
| 45 | + See ../dma/dma.txt for details. | |
| 46 | +- dma-names : Must include the following entries: | |
| 47 | + - rx0 .. rx<n> | |
| 48 | + - tx0 .. tx<n> | |
| 49 | + ... where n is: | |
| 50 | + Tegra30: 3 | |
| 51 | + Tegra114, Tegra124: 9 | |
| 22 | 52 | - #address-cells : For the configlink bus. Should be <1>; |
| 23 | 53 | - #size-cells : For the configlink bus. Should be <1>. |
| 24 | 54 | |
| @@ -35,13 +65,20 @@ ahub@70080000 { · 10 unmodified lines | ||
| 35 | 65 | reg = <0x70080000 0x200 0x70080200 0x100>; |
| 36 | 66 | interrupts = < 0 103 0x04 >; |
| 37 | 67 | nvidia,dma-request-selector = <&apbdma 1>; |
| 38 | − clocks = <&tegra_car 106>, <&tegra_car 107>, <&tegra_car 30>, | |
| 68 | + clocks = <&tegra_car 106>, <&tegra_car 107>; | |
| 69 | + clock-names = "d_audio", "apbif"; | |
| 70 | + resets = <&tegra_car 106>, <&tegra_car 107>, <&tegra_car 30>, | |
| 39 | 71 | <&tegra_car 11>, <&tegra_car 18>, <&tegra_car 101>, |
| 40 | 72 | <&tegra_car 102>, <&tegra_car 108>, <&tegra_car 109>, |
| 41 | − <&tegra_car 110>, <&tegra_car 162>; | |
| 42 | − clock-names = "d_audio", "apbif", "i2s0", "i2s1", "i2s2", | |
| 73 | + <&tegra_car 110>, <&tegra_car 10>; | |
| 74 | + reset-names = "d_audio", "apbif", "i2s0", "i2s1", "i2s2", | |
| 43 | 75 | "i2s3", "i2s4", "dam0", "dam1", "dam2", |
| 44 | − "spdif_in"; | |
| 76 | + "spdif"; | |
| 77 | + dmas = <&apbdma 1>, <&apbdma 1>; | |
| 78 | + <&apbdma 2>, <&apbdma 2>; | |
| 79 | + <&apbdma 3>, <&apbdma 3>; | |
| 80 | + <&apbdma 4>, <&apbdma 4>; | |
| 81 | + dma-names = "rx0", "tx0", "rx1", "tx1", "rx2", "tx2", "rx3", "tx3"; | |
| 45 | 82 | ranges; |
| 46 | 83 | #address-cells = <1>; |
| 47 | 84 | #size-cells = <1>; |
| @@ -3,13 +3,22 @@ NVIDIA Tegra30 I2S controller · 2 unmodified lines | ||
| 3 | 3 | Required properties: |
| 4 | 4 | - compatible : "nvidia,tegra30-i2s" |
| 5 | 5 | - reg : Should contain I2S registers location and length |
| 6 | +- clocks : Must contain one entry, for the module clock. | |
| 7 | + See ../clocks/clock-bindings.txt for details. | |
| 8 | +- resets : Must contain an entry for each entry in reset-names. | |
| 9 | + See ../reset/reset.txt for details. | |
| 10 | +- reset-names : Must include the following entries: | |
| 11 | + - i2s | |
| 6 | 12 | - nvidia,ahub-cif-ids : The list of AHUB CIF IDs for this port, rx (playback) |
| 7 | 13 | first, tx (capture) second. See nvidia,tegra30-ahub.txt for values. |
| 8 | 14 | |
| 9 | 15 | Example: |
| 10 | 16 | |
| 11 | −i2s@70002800 { | |
| 17 | +i2s@70080300 { | |
| 12 | 18 | compatible = "nvidia,tegra30-i2s"; |
| 13 | 19 | reg = <0x70080300 0x100>; |
| 14 | 20 | nvidia,ahub-cif-ids = <4 4>; |
| 21 | + clocks = <&tegra_car 11>; | |
| 22 | + resets = <&tegra_car 11>; | |
| 23 | + reset-names = "i2s"; | |
| 15 | 24 | }; |
| @@ -0,0 +1,77 @@ | ||
| 1 | +Simple-Card: | |
| 2 | + | |
| 3 | +Simple-Card specifies audio DAI connection of SoC <-> codec. | |
| 4 | + | |
| 5 | +Required properties: | |
| 6 | + | |
| 7 | +- compatible : "simple-audio-card" | |
| 8 | + | |
| 9 | +Optional properties: | |
| 10 | + | |
| 11 | +- simple-audio-card,format : CPU/CODEC common audio format. | |
| 12 | + "i2s", "right_j", "left_j" , "dsp_a" | |
| 13 | + "dsp_b", "ac97", "pdm", "msb", "lsb" | |
| 14 | +- simple-audio-card,routing : A list of the connections between audio components. | |
| 15 | + Each entry is a pair of strings, the first being the | |
| 16 | + connection's sink, the second being the connection's | |
| 17 | + source. | |
| 18 | + | |
| 19 | +Required subnodes: | |
| 20 | + | |
| 21 | +- simple-audio-card,cpu : CPU sub-node | |
| 22 | +- simple-audio-card,codec : CODEC sub-node | |
| 23 | + | |
| 24 | +Required CPU/CODEC subnodes properties: | |
| 25 | + | |
| 26 | +- sound-dai : phandle and port of CPU/CODEC | |
| 27 | + | |
| 28 | +Optional CPU/CODEC subnodes properties: | |
| 29 | + | |
| 30 | +- format : CPU/CODEC specific audio format if needed. | |
| 31 | + see simple-audio-card,format | |
| 32 | +- frame-master : bool property. add this if subnode is frame master | |
| 33 | +- bitclock-master : bool property. add this if subnode is bitclock master | |
| 34 | +- bitclock-inversion : bool property. add this if subnode has clock inversion | |
| 35 | +- frame-inversion : bool property. add this if subnode has frame inversion | |
| 36 | +- clocks / system-clock-frequency : specify subnode's clock if needed. | |
| 37 | + it can be specified via "clocks" if system has | |
| 38 | + clock node (= common clock), or "system-clock-frequency" | |
| 39 | + (if system doens't support common clock) | |
| 40 | + | |
| 41 | +Example: | |
| 42 | + | |
| 43 | +sound { | |
| 44 | + compatible = "simple-audio-card"; | |
| 45 | + simple-audio-card,format = "left_j"; | |
| 46 | + simple-audio-card,routing = | |
| 47 | + "MIC_IN", "Mic Jack", | |
| 48 | + "Headphone Jack", "HP_OUT", | |
| 49 | + "Ext Spk", "LINE_OUT"; | |
| 50 | + | |
| 51 | + simple-audio-card,cpu { | |
| 52 | + sound-dai = <&sh_fsi2 0>; | |
| 53 | + }; | |
| 54 | + | |
| 55 | + simple-audio-card,codec { | |
| 56 | + sound-dai = <&ak4648>; | |
| 57 | + bitclock-master; | |
| 58 | + frame-master; | |
| 59 | + clocks = <&osc>; | |
| 60 | + }; | |
| 61 | +}; | |
| 62 | + | |
| 63 | +&i2c0 { | |
| 64 | + ak4648: ak4648@12 { | |
| 65 | + #sound-dai-cells = <0>; | |
| 66 | + compatible = "asahi-kasei,ak4648"; | |
| 67 | + reg = <0x12>; | |
| 68 | + }; | |
| 69 | +}; | |
| 70 | + | |
| 71 | +sh_fsi2: sh_fsi2@ec230000 { | |
| 72 | + #sound-dai-cells = <1>; | |
| 73 | + compatible = "renesas,sh_fsi2"; | |
| 74 | + reg = <0xec230000 0x400>; | |
| 75 | + interrupt-parent = <&gic>; | |
| 76 | + interrupts = <0 146 0x4>; | |
| 77 | +}; | |
| @@ -6,6 +6,7 @@ Required properties: · 5 unmodified lines | ||
| 6 | 6 | |
| 7 | 7 | - compatible - "string" - One of: |
| 8 | 8 | "ti,tlv320aic3x" - Generic TLV320AIC3x device |
| 9 | + "ti,tlv320aic32x4" - TLV320AIC32x4 | |
| 9 | 10 | "ti,tlv320aic33" - TLV320AIC33 |
| 10 | 11 | "ti,tlv320aic3007" - TLV320AIC3007 |
| 11 | 12 | "ti,tlv320aic3106" - TLV320AIC3106 |
| @@ -4,10 +4,19 @@ Required properties: · 3 unmodified lines | ||
| 4 | 4 | - compatible : should be "nvidia,tegra114-spi". |
| 5 | 5 | - reg: Should contain SPI registers location and length. |
| 6 | 6 | - interrupts: Should contain SPI interrupts. |
| 7 | −- nvidia,dma-request-selector : The Tegra DMA controller's phandle and | |
| 8 | − request selector for this SPI controller. | |
| 9 | −- This is also require clock named "spi" as per binding document | |
| 10 | − Documentation/devicetree/bindings/clock/clock-bindings.txt | |
| 7 | +- clock-names : Must include the following entries: | |
| 8 | + - spi | |
| 9 | +- resets : Must contain an entry for each entry in reset-names. | |
| 10 | + See ../reset/reset.txt for details. | |
| 11 | +- reset-names : Must include the following entries: | |
| 12 | + - spi | |
| 13 | +- dmas : Must contain an entry for each entry in clock-names. | |
| 14 | + See ../dma/dma.txt for details. | |
| 15 | +- dma-names : Must include the following entries: | |
| 16 | + - rx | |
| 17 | + - tx | |
| 18 | +- clocks : Must contain an entry for each entry in clock-names. | |
| 19 | + See ../clocks/clock-bindings.txt for details. | |
| 11 | 20 | |
| 12 | 21 | Recommended properties: |
| 13 | 22 | - spi-max-frequency: Definition as per |
| @@ -18,9 +27,14 @@ spi@7000d600 { · 4 unmodified lines | ||
| 18 | 27 | compatible = "nvidia,tegra114-spi"; |
| 19 | 28 | reg = <0x7000d600 0x200>; |
| 20 | 29 | interrupts = <0 82 0x04>; |
| 21 | − nvidia,dma-request-selector = <&apbdma 16>; | |
| 22 | 30 | spi-max-frequency = <25000000>; |
| 23 | 31 | #address-cells = <1>; |
| 24 | 32 | #size-cells = <0>; |
| 33 | + clocks = <&tegra_car 44>; | |
| 34 | + clock-names = "spi"; | |
| 35 | + resets = <&tegra_car 44>; | |
| 36 | + reset-names = "spi"; | |
| 37 | + dmas = <&apbdma 16>, <&apbdma 16>; | |
| 38 | + dma-names = "rx", "tx"; | |
| 25 | 39 | status = "disabled"; |
| 26 | 40 | }; |
| @@ -4,8 +4,17 @@ Required properties: · 3 unmodified lines | ||
| 4 | 4 | - compatible : should be "nvidia,tegra20-sflash". |
| 5 | 5 | - reg: Should contain SFLASH registers location and length. |
| 6 | 6 | - interrupts: Should contain SFLASH interrupts. |
| 7 | −- nvidia,dma-request-selector : The Tegra DMA controller's phandle and | |
| 8 | − request selector for this SFLASH controller. | |
| 7 | +- clocks : Must contain one entry, for the module clock. | |
| 8 | + See ../clocks/clock-bindings.txt for details. | |
| 9 | +- resets : Must contain an entry for each entry in reset-names. | |
| 10 | + See ../reset/reset.txt for details. | |
| 11 | +- reset-names : Must include the following entries: | |
| 12 | + - spi | |
| 13 | +- dmas : Must contain an entry for each entry in clock-names. | |
| 14 | + See ../dma/dma.txt for details. | |
| 15 | +- dma-names : Must include the following entries: | |
| 16 | + - rx | |
| 17 | + - tx | |
| 9 | 18 | |
| 10 | 19 | Recommended properties: |
| 11 | 20 | - spi-max-frequency: Definition as per |
| @@ -17,10 +26,13 @@ spi@7000c380 { · 5 unmodified lines | ||
| 17 | 26 | compatible = "nvidia,tegra20-sflash"; |
| 18 | 27 | reg = <0x7000c380 0x80>; |
| 19 | 28 | interrupts = <0 39 0x04>; |
| 20 | − nvidia,dma-request-selector = <&apbdma 16>; | |
| 21 | 29 | spi-max-frequency = <25000000>; |
| 22 | 30 | #address-cells = <1>; |
| 23 | 31 | #size-cells = <0>; |
| 32 | + clocks = <&tegra_car 43>; | |
| 33 | + resets = <&tegra_car 43>; | |
| 34 | + reset-names = "spi"; | |
| 35 | + dmas = <&apbdma 11>, <&apbdma 11>; | |
| 36 | + dma-names = "rx", "tx"; | |
| 24 | 37 | status = "disabled"; |
| 25 | 38 | }; |
| 26 | − | |
| @@ -4,8 +4,17 @@ Required properties: · 3 unmodified lines | ||
| 4 | 4 | - compatible : should be "nvidia,tegra20-slink", "nvidia,tegra30-slink". |
| 5 | 5 | - reg: Should contain SLINK registers location and length. |
| 6 | 6 | - interrupts: Should contain SLINK interrupts. |
| 7 | −- nvidia,dma-request-selector : The Tegra DMA controller's phandle and | |
| 8 | − request selector for this SLINK controller. | |
| 7 | +- clocks : Must contain one entry, for the module clock. | |
| 8 | + See ../clocks/clock-bindings.txt for details. | |
| 9 | +- resets : Must contain an entry for each entry in reset-names. | |
| 10 | + See ../reset/reset.txt for details. | |
| 11 | +- reset-names : Must include the following entries: | |
| 12 | + - spi | |
| 13 | +- dmas : Must contain an entry for each entry in clock-names. | |
| 14 | + See ../dma/dma.txt for details. | |
| 15 | +- dma-names : Must include the following entries: | |
| 16 | + - rx | |
| 17 | + - tx | |
| 9 | 18 | |
| 10 | 19 | Recommended properties: |
| 11 | 20 | - spi-max-frequency: Definition as per |
| @@ -17,10 +26,13 @@ spi@7000d600 { · 5 unmodified lines | ||
| 17 | 26 | compatible = "nvidia,tegra20-slink"; |
| 18 | 27 | reg = <0x7000d600 0x200>; |
| 19 | 28 | interrupts = <0 82 0x04>; |
| 20 | − nvidia,dma-request-selector = <&apbdma 16>; | |
| 21 | 29 | spi-max-frequency = <25000000>; |
| 22 | 30 | #address-cells = <1>; |
| 23 | 31 | #size-cells = <0>; |
| 32 | + clocks = <&tegra_car 44>; | |
| 33 | + resets = <&tegra_car 44>; | |
| 34 | + reset-names = "spi"; | |
| 35 | + dmas = <&apbdma 16>, <&apbdma 16>; | |
| 36 | + dma-names = "rx", "tx"; | |
| 24 | 37 | status = "disabled"; |
| 25 | 38 | }; |
| 26 | − | |
| @@ -67,7 +67,7 @@ only 1(SINGLE), 2(DUAL) and 4(QUAD). · 66 unmodified lines | ||
| 67 | 67 | Dual/Quad mode is not allowed when 3-wire mode is used. |
| 68 | 68 | |
| 69 | 69 | If a gpio chipselect is used for the SPI slave the gpio number will be passed |
| 70 | −via the cs_gpio | |
| 70 | +via the SPI master node cs-gpios property. | |
| 71 | 71 | |
| 72 | 72 | SPI example for an MPC5200 SPI bus: |
| 73 | 73 | spi@f00 { |
| @@ -3,6 +3,11 @@ TI QSPI controller. · 2 unmodified lines | ||
| 3 | 3 | Required properties: |
| 4 | 4 | - compatible : should be "ti,dra7xxx-qspi" or "ti,am4372-qspi". |
| 5 | 5 | - reg: Should contain QSPI registers location and length. |
| 6 | +- reg-names: Should contain the resource reg names. | |
| 7 | + - qspi_base: Qspi configuration register Address space | |
| 8 | + - qspi_mmap: Memory mapped Address space | |
| 9 | + - (optional) qspi_ctrlmod: Control module Address space | |
| 10 | +- interrupts: should contain the qspi interrupt number. | |
| 6 | 11 | - #address-cells, #size-cells : Must be present if the device has sub-nodes |
| 7 | 12 | - ti,hwmods: Name of the hwmod associated to the QSPI |
| 8 | 13 | |
| @@ -14,7 +19,8 @@ Example: · 5 unmodified lines | ||
| 14 | 19 | |
| 15 | 20 | qspi: qspi@4b300000 { |
| 16 | 21 | compatible = "ti,dra7xxx-qspi"; |
| 17 | − reg = <0x4b300000 0x100>; | |
| 22 | + reg = <0x47900000 0x100>, <0x30000000 0x3ffffff>; | |
| 23 | + reg-names = "qspi_base", "qspi_mmap"; | |
| 18 | 24 | #address-cells = <1>; |
| 19 | 25 | #size-cells = <0>; |
| 20 | 26 | spi-max-frequency = <25000000>; |
| @@ -1,15 +0,0 @@ | ||
| 1 | −Platform DesignWare HS OTG USB 2.0 controller | |
| 2 | −----------------------------------------------------- | |
| 3 | − | |
| 4 | −Required properties: | |
| 5 | −- compatible : "snps,dwc2" | |
| 6 | −- reg : Should contain 1 register range (address and length) | |
| 7 | −- interrupts : Should contain 1 interrupt | |
| 8 | − | |
| 9 | −Example: | |
| 10 | − | |
| 11 | − usb@101c0000 { | |
| 12 | − compatible = "ralink,rt3050-usb, snps,dwc2"; | |
| 13 | − reg = <0x101c0000 40000>; | |
| 14 | − interrupts = <18>; | |
| 15 | − }; | |
| @@ -0,0 +1,20 @@ | ||
| 1 | +* Xillybus driver for generic FPGA interface | |
| 2 | + | |
| 3 | +Required properties: | |
| 4 | +- compatible: Should be "xillybus,xillybus-1.00.a" | |
| 5 | +- reg: Address and length of the register set for the device | |
| 6 | +- interrupts: Contains one interrupt node, typically consisting of three cells. | |
| 7 | +- interrupt-parent: the phandle for the interrupt controller that | |
| 8 | + services interrupts for this device. | |
| 9 | + | |
| 10 | +Optional properties: | |
| 11 | +- dma-coherent: Present if DMA operations are coherent | |
| 12 | + | |
| 13 | +Example: | |
| 14 | + | |
| 15 | + xillybus@ff200400 { | |
| 16 | + compatible = "xillybus,xillybus-1.00.a"; | |
| 17 | + reg = < 0xff200400 0x00000080 >; | |
| 18 | + interrupts = < 0 40 1 >; | |
| 19 | + interrupt-parent = <&intc>; | |
| 20 | + } ; | |
| @@ -0,0 +1,38 @@ | ||
| 1 | + | |
| 2 | + Submitting devicetree (DT) binding patches | |
| 3 | + | |
| 4 | +I. For patch submitters | |
| 5 | + | |
| 6 | + 0) Normal patch submission rules from Documentation/SubmittingPatches | |
| 7 | + applies. | |
| 8 | + | |
| 9 | + 1) The Documentation/ portion of the patch should be a separate patch. | |
| 10 | + | |
| 11 | + 2) Submit the entire series to the devicetree mailinglist at | |
| 12 | + | |
| 13 | + devicetree@vger.kernel.org | |
| 14 | + | |
| 15 | +II. For kernel maintainers | |
| 16 | + | |
| 17 | + 1) If you aren't comfortable reviewing a given binding, reply to it and ask | |
| 18 | + the devicetree maintainers for guidance. This will help them prioritize | |
| 19 | + which ones to review and which ones are ok to let go. | |
| 20 | + | |
| 21 | + 2) For driver (not subsystem) bindings: If you are comfortable with the | |
| 22 | + binding, and it hasn't received an Acked-by from the devicetree | |
| 23 | + maintainers after a few weeks, go ahead and take it. | |
| 24 | + | |
| 25 | + Subsystem bindings (anything affecting more than a single device) | |
| 26 | + then getting a devicetree maintainer to review it is required. | |
| 27 | + | |
| 28 | + 3) For a series going though multiple trees, the binding patch should be | |
| 29 | + kept with the driver using the binding. | |
| 30 | + | |
| 31 | +III. Notes | |
| 32 | + | |
| 33 | + 0) Please see ...bindings/ABI.txt for details regarding devicetree ABI. | |
| 34 | + | |
| 35 | + 1) This document is intended as a general familiarization with the process as | |
| 36 | + decided at the 2013 Kernel Summit. When in doubt, the current word of the | |
| 37 | + devicetree maintainers overrules this document. In that situation, a patch | |
| 38 | + updating this document would be appreciated. | |
| @@ -8,10 +8,14 @@ Required properties: · 7 unmodified lines | ||
| 8 | 8 | calibration data, e.g. OCOTP on imx6q. The details about calibration data |
| 9 | 9 | can be found in SoC Reference Manual. |
| 10 | 10 | |
| 11 | +Optional properties: | |
| 12 | +- clocks : thermal sensor's clock source. | |
| 13 | + | |
| 11 | 14 | Example: |
| 12 | 15 | |
| 13 | 16 | tempmon { |
| 14 | 17 | compatible = "fsl,imx6q-tempmon"; |
| 15 | 18 | fsl,tempmon = <&anatop>; |
| 16 | 19 | fsl,tempmon-data = <&ocotp>; |
| 20 | + clocks = <&clks 172>; | |
| 17 | 21 | }; |
| @@ -0,0 +1,595 @@ | ||
| 1 | +* Thermal Framework Device Tree descriptor | |
| 2 | + | |
| 3 | +This file describes a generic binding to provide a way of | |
| 4 | +defining hardware thermal structure using device tree. | |
| 5 | +A thermal structure includes thermal zones and their components, | |
| 6 | +such as trip points, polling intervals, sensors and cooling devices | |
| 7 | +binding descriptors. | |
| 8 | + | |
| 9 | +The target of device tree thermal descriptors is to describe only | |
| 10 | +the hardware thermal aspects. The thermal device tree bindings are | |
| 11 | +not about how the system must control or which algorithm or policy | |
| 12 | +must be taken in place. | |
| 13 | + | |
| 14 | +There are five types of nodes involved to describe thermal bindings: | |
| 15 | +- thermal sensors: devices which may be used to take temperature | |
| 16 | + measurements. | |
| 17 | +- cooling devices: devices which may be used to dissipate heat. | |
| 18 | +- trip points: describe key temperatures at which cooling is recommended. The | |
| 19 | + set of points should be chosen based on hardware limits. | |
| 20 | +- cooling maps: used to describe links between trip points and cooling devices; | |
| 21 | +- thermal zones: used to describe thermal data within the hardware; | |
| 22 | + | |
| 23 | +The following is a description of each of these node types. | |
| 24 | + | |
| 25 | +* Thermal sensor devices | |
| 26 | + | |
| 27 | +Thermal sensor devices are nodes providing temperature sensing capabilities on | |
| 28 | +thermal zones. Typical devices are I2C ADC converters and bandgaps. These are | |
| 29 | +nodes providing temperature data to thermal zones. Thermal sensor devices may | |
| 30 | +control one or more internal sensors. | |
| 31 | + | |
| 32 | +Required property: | |
| 33 | +- #thermal-sensor-cells: Used to provide sensor device specific information | |
| 34 | + Type: unsigned while referring to it. Typically 0 on thermal sensor | |
| 35 | + Size: one cell nodes with only one sensor, and at least 1 on nodes | |
| 36 | + with several internal sensors, in order | |
| 37 | + to identify uniquely the sensor instances within | |
| 38 | + the IC. See thermal zone binding for more details | |
| 39 | + on how consumers refer to sensor devices. | |
| 40 | + | |
| 41 | +* Cooling device nodes | |
| 42 | + | |
| 43 | +Cooling devices are nodes providing control on power dissipation. There | |
| 44 | +are essentially two ways to provide control on power dissipation. First | |
| 45 | +is by means of regulating device performance, which is known as passive | |
| 46 | +cooling. A typical passive cooling is a CPU that has dynamic voltage and | |
| 47 | +frequency scaling (DVFS), and uses lower frequencies as cooling states. | |
| 48 | +Second is by means of activating devices in order to remove | |
| 49 | +the dissipated heat, which is known as active cooling, e.g. regulating | |
| 50 | +fan speeds. In both cases, cooling devices shall have a way to determine | |
| 51 | +the state of cooling in which the device is. | |
| 52 | + | |
| 53 | +Any cooling device has a range of cooling states (i.e. different levels | |
| 54 | +of heat dissipation). For example a fan's cooling states correspond to | |
| 55 | +the different fan speeds possible. Cooling states are referred to by | |
| 56 | +single unsigned integers, where larger numbers mean greater heat | |
| 57 | +dissipation. The precise set of cooling states associated with a device | |
| 58 | +(as referred to be the cooling-min-state and cooling-max-state | |
| 59 | +properties) should be defined in a particular device's binding. | |
| 60 | +For more examples of cooling devices, refer to the example sections below. | |
| 61 | + | |
| 62 | +Required properties: | |
| 63 | +- cooling-min-state: An integer indicating the smallest | |
| 64 | + Type: unsigned cooling state accepted. Typically 0. | |
| 65 | + Size: one cell | |
| 66 | + | |
| 67 | +- cooling-max-state: An integer indicating the largest | |
| 68 | + Type: unsigned cooling state accepted. | |
| 69 | + Size: one cell | |
| 70 | + | |
| 71 | +- #cooling-cells: Used to provide cooling device specific information | |
| 72 | + Type: unsigned while referring to it. Must be at least 2, in order | |
| 73 | + Size: one cell to specify minimum and maximum cooling state used | |
| 74 | + in the reference. The first cell is the minimum | |
| 75 | + cooling state requested and the second cell is | |
| 76 | + the maximum cooling state requested in the reference. | |
| 77 | + See Cooling device maps section below for more details | |
| 78 | + on how consumers refer to cooling devices. | |
| 79 | + | |
| 80 | +* Trip points | |
| 81 | + | |
| 82 | +The trip node is a node to describe a point in the temperature domain | |
| 83 | +in which the system takes an action. This node describes just the point, | |
| 84 | +not the action. | |
| 85 | + | |
| 86 | +Required properties: | |
| 87 | +- temperature: An integer indicating the trip temperature level, | |
| 88 | + Type: signed in millicelsius. | |
| 89 | + Size: one cell | |
| 90 | + | |
| 91 | +- hysteresis: A low hysteresis value on temperature property (above). | |
| 92 | + Type: unsigned This is a relative value, in millicelsius. | |
| 93 | + Size: one cell | |
| 94 | + | |
| 95 | +- type: a string containing the trip type. Expected values are: | |
| 96 | + "active": A trip point to enable active cooling | |
| 97 | + "passive": A trip point to enable passive cooling | |
| 98 | + "hot": A trip point to notify emergency | |
| 99 | + "critical": Hardware not reliable. | |
| 100 | + Type: string | |
| 101 | + | |
| 102 | +* Cooling device maps | |
| 103 | + | |
| 104 | +The cooling device maps node is a node to describe how cooling devices | |
| 105 | +get assigned to trip points of the zone. The cooling devices are expected | |
| 106 | +to be loaded in the target system. | |
| 107 | + | |
| 108 | +Required properties: | |
| 109 | +- cooling-device: A phandle of a cooling device with its specifier, | |
| 110 | + Type: phandle + referring to which cooling device is used in this | |
| 111 | + cooling specifier binding. In the cooling specifier, the first cell | |
| 112 | + is the minimum cooling state and the second cell | |
| 113 | + is the maximum cooling state used in this map. | |
| 114 | +- trip: A phandle of a trip point node within the same thermal | |
| 115 | + Type: phandle of zone. | |
| 116 | + trip point node | |
| 117 | + | |
| 118 | +Optional property: | |
| 119 | +- contribution: The cooling contribution to the thermal zone of the | |
| 120 | + Type: unsigned referred cooling device at the referred trip point. | |
| 121 | + Size: one cell The contribution is a ratio of the sum | |
| 122 | + of all cooling contributions within a thermal zone. | |
| 123 | + | |
| 124 | +Note: Using the THERMAL_NO_LIMIT (-1UL) constant in the cooling-device phandle | |
| 125 | +limit specifier means: | |
| 126 | +(i) - minimum state allowed for minimum cooling state used in the reference. | |
| 127 | +(ii) - maximum state allowed for maximum cooling state used in the reference. | |
| 128 | +Refer to include/dt-bindings/thermal/thermal.h for definition of this constant. | |
| 129 | + | |
| 130 | +* Thermal zone nodes | |
| 131 | + | |
| 132 | +The thermal zone node is the node containing all the required info | |
| 133 | +for describing a thermal zone, including its cooling device bindings. The | |
| 134 | +thermal zone node must contain, apart from its own properties, one sub-node | |
| 135 | +containing trip nodes and one sub-node containing all the zone cooling maps. | |
| 136 | + | |
| 137 | +Required properties: | |
| 138 | +- polling-delay: The maximum number of milliseconds to wait between polls | |
| 139 | + Type: unsigned when checking this thermal zone. | |
| 140 | + Size: one cell | |
| 141 | + | |
| 142 | +- polling-delay-passive: The maximum number of milliseconds to wait | |
| 143 | + Type: unsigned between polls when performing passive cooling. | |
| 144 | + Size: one cell | |
| 145 | + | |
| 146 | +- thermal-sensors: A list of thermal sensor phandles and sensor specifier | |
| 147 | + Type: list of used while monitoring the thermal zone. | |
| 148 | + phandles + sensor | |
| 149 | + specifier | |
| 150 | + | |
| 151 | +- trips: A sub-node which is a container of only trip point nodes | |
| 152 | + Type: sub-node required to describe the thermal zone. | |
| 153 | + | |
| 154 | +- cooling-maps: A sub-node which is a container of only cooling device | |
| 155 | + Type: sub-node map nodes, used to describe the relation between trips | |
| 156 | + and cooling devices. | |
| 157 | + | |
| 158 | +Optional property: | |
| 159 | +- coefficients: An array of integers (one signed cell) containing | |
| 160 | + Type: array coefficients to compose a linear relation between | |
| 161 | + Elem size: one cell the sensors listed in the thermal-sensors property. | |
| 162 | + Elem type: signed Coefficients defaults to 1, in case this property | |
| 163 | + is not specified. A simple linear polynomial is used: | |
| 164 | + Z = c0 * x0 + c1 + x1 + ... + c(n-1) * x(n-1) + cn. | |
| 165 | + | |
| 166 | + The coefficients are ordered and they match with sensors | |
| 167 | + by means of sensor ID. Additional coefficients are | |
| 168 | + interpreted as constant offset. | |
| 169 | + | |
| 170 | +Note: The delay properties are bound to the maximum dT/dt (temperature | |
| 171 | +derivative over time) in two situations for a thermal zone: | |
| 172 | +(i) - when passive cooling is activated (polling-delay-passive); and | |
| 173 | +(ii) - when the zone just needs to be monitored (polling-delay) or | |
| 174 | +when active cooling is activated. | |
| 175 | + | |
| 176 | +The maximum dT/dt is highly bound to hardware power consumption and dissipation | |
| 177 | +capability. The delays should be chosen to account for said max dT/dt, | |
| 178 | +such that a device does not cross several trip boundaries unexpectedly | |
| 179 | +between polls. Choosing the right polling delays shall avoid having the | |
| 180 | +device in temperature ranges that may damage the silicon structures and | |
| 181 | +reduce silicon lifetime. | |
| 182 | + | |
| 183 | +* The thermal-zones node | |
| 184 | + | |
| 185 | +The "thermal-zones" node is a container for all thermal zone nodes. It shall | |
| 186 | +contain only sub-nodes describing thermal zones as in the section | |
| 187 | +"Thermal zone nodes". The "thermal-zones" node appears under "/". | |
| 188 | + | |
| 189 | +* Examples | |
| 190 | + | |
| 191 | +Below are several examples on how to use thermal data descriptors | |
| 192 | +using device tree bindings: | |
| 193 | + | |
| 194 | +(a) - CPU thermal zone | |
| 195 | + | |
| 196 | +The CPU thermal zone example below describes how to setup one thermal zone | |
| 197 | +using one single sensor as temperature source and many cooling devices and | |
| 198 | +power dissipation control sources. | |
| 199 | + | |
| 200 | +#include <dt-bindings/thermal/thermal.h> | |
| 201 | + | |
| 202 | +cpus { | |
| 203 | + /* | |
| 204 | + * Here is an example of describing a cooling device for a DVFS | |
| 205 | + * capable CPU. The CPU node describes its four OPPs. | |
| 206 | + * The cooling states possible are 0..3, and they are | |
| 207 | + * used as OPP indexes. The minimum cooling state is 0, which means | |
| 208 | + * all four OPPs can be available to the system. The maximum | |
| 209 | + * cooling state is 3, which means only the lowest OPPs (198MHz@0.85V) | |
| 210 | + * can be available in the system. | |
| 211 | + */ | |
| 212 | + cpu0: cpu@0 { | |
| 213 | + ... | |
| 214 | + operating-points = < | |
| 215 | + /* kHz uV */ | |
| 216 | + 970000 1200000 | |
| 217 | + 792000 1100000 | |
| 218 | + 396000 950000 | |
| 219 | + 198000 850000 | |
| 220 | + >; | |
| 221 | + cooling-min-state = <0>; | |
| 222 | + cooling-max-state = <3>; | |
| 223 | + #cooling-cells = <2>; /* min followed by max */ | |
| 224 | + }; | |
| 225 | + ... | |
| 226 | +}; | |
| 227 | + | |
| 228 | +&i2c1 { | |
| 229 | + ... | |
| 230 | + /* | |
| 231 | + * A simple fan controller which supports 10 speeds of operation | |
| 232 | + * (represented as 0-9). | |
| 233 | + */ | |
| 234 | + fan0: fan@0x48 { | |
| 235 | + ... | |
| 236 | + cooling-min-state = <0>; | |
| 237 | + cooling-max-state = <9>; | |
| 238 | + #cooling-cells = <2>; /* min followed by max */ | |
| 239 | + }; | |
| 240 | +}; | |
| 241 | + | |
| 242 | +ocp { | |
| 243 | + ... | |
| 244 | + /* | |
| 245 | + * A simple IC with a single bandgap temperature sensor. | |
| 246 | + */ | |
| 247 | + bandgap0: bandgap@0x0000ED00 { | |
| 248 | + ... | |
| 249 | + #thermal-sensor-cells = <0>; | |
| 250 | + }; | |
| 251 | +}; | |
| 252 | + | |
| 253 | +thermal-zones { | |
| 254 | + cpu-thermal: cpu-thermal { | |
| 255 | + polling-delay-passive = <250>; /* milliseconds */ | |
| 256 | + polling-delay = <1000>; /* milliseconds */ | |
| 257 | + | |
| 258 | + thermal-sensors = <&bandgap0>; | |
| 259 | + | |
| 260 | + trips { | |
| 261 | + cpu-alert0: cpu-alert { | |
| 262 | + temperature = <90000>; /* millicelsius */ | |
| 263 | + hysteresis = <2000>; /* millicelsius */ | |
| 264 | + type = "active"; | |
| 265 | + }; | |
| 266 | + cpu-alert1: cpu-alert { | |
| 267 | + temperature = <100000>; /* millicelsius */ | |
| 268 | + hysteresis = <2000>; /* millicelsius */ | |
| 269 | + type = "passive"; | |
| 270 | + }; | |
| 271 | + cpu-crit: cpu-crit { | |
| 272 | + temperature = <125000>; /* millicelsius */ | |
| 273 | + hysteresis = <2000>; /* millicelsius */ | |
| 274 | + type = "critical"; | |
| 275 | + }; | |
| 276 | + }; | |
| 277 | + | |
| 278 | + cooling-maps { | |
| 279 | + map0 { | |
| 280 | + trip = <&cpu-alert0>; | |
| 281 | + cooling-device = <&fan0 THERMAL_NO_LIMITS 4>; | |
| 282 | + }; | |
| 283 | + map1 { | |
| 284 | + trip = <&cpu-alert1>; | |
| 285 | + cooling-device = <&fan0 5 THERMAL_NO_LIMITS>; | |
| 286 | + }; | |
| 287 | + map2 { | |
| 288 | + trip = <&cpu-alert1>; | |
| 289 | + cooling-device = | |
| 290 | + <&cpu0 THERMAL_NO_LIMITS THERMAL_NO_LIMITS>; | |
| 291 | + }; | |
| 292 | + }; | |
| 293 | + }; | |
| 294 | +}; | |
| 295 | + | |
| 296 | +In the example above, the ADC sensor (bandgap0) at address 0x0000ED00 is | |
| 297 | +used to monitor the zone 'cpu-thermal' using its sole sensor. A fan | |
| 298 | +device (fan0) is controlled via I2C bus 1, at address 0x48, and has ten | |
| 299 | +different cooling states 0-9. It is used to remove the heat out of | |
| 300 | +the thermal zone 'cpu-thermal' using its cooling states | |
| 301 | +from its minimum to 4, when it reaches trip point 'cpu-alert0' | |
| 302 | +at 90C, as an example of active cooling. The same cooling device is used at | |
| 303 | +'cpu-alert1', but from 5 to its maximum state. The cpu@0 device is also | |
| 304 | +linked to the same thermal zone, 'cpu-thermal', as a passive cooling device, | |
| 305 | +using all its cooling states at trip point 'cpu-alert1', | |
| 306 | +which is a trip point at 100C. On the thermal zone 'cpu-thermal', at the | |
| 307 | +temperature of 125C, represented by the trip point 'cpu-crit', the silicon | |
| 308 | +is not reliable anymore. | |
| 309 | + | |
| 310 | +(b) - IC with several internal sensors | |
| 311 | + | |
| 312 | +The example below describes how to deploy several thermal zones based off a | |
| 313 | +single sensor IC, assuming it has several internal sensors. This is a common | |
| 314 | +case on SoC designs with several internal IPs that may need different thermal | |
| 315 | +requirements, and thus may have their own sensor to monitor or detect internal | |
| 316 | +hotspots in their silicon. | |
| 317 | + | |
| 318 | +#include <dt-bindings/thermal/thermal.h> | |
| 319 | + | |
| 320 | +ocp { | |
| 321 | + ... | |
| 322 | + /* | |
| 323 | + * A simple IC with several bandgap temperature sensors. | |
| 324 | + */ | |
| 325 | + bandgap0: bandgap@0x0000ED00 { | |
| 326 | + ... | |
| 327 | + #thermal-sensor-cells = <1>; | |
| 328 | + }; | |
| 329 | +}; | |
| 330 | + | |
| 331 | +thermal-zones { | |
| 332 | + cpu-thermal: cpu-thermal { | |
| 333 | + polling-delay-passive = <250>; /* milliseconds */ | |
| 334 | + polling-delay = <1000>; /* milliseconds */ | |
| 335 | + | |
| 336 | + /* sensor ID */ | |
| 337 | + thermal-sensors = <&bandgap0 0>; | |
| 338 | + | |
| 339 | + trips { | |
| 340 | + /* each zone within the SoC may have its own trips */ | |
| 341 | + cpu-alert: cpu-alert { | |
| 342 | + temperature = <100000>; /* millicelsius */ | |
| 343 | + hysteresis = <2000>; /* millicelsius */ | |
| 344 | + type = "passive"; | |
| 345 | + }; | |
| 346 | + cpu-crit: cpu-crit { | |
| 347 | + temperature = <125000>; /* millicelsius */ | |
| 348 | + hysteresis = <2000>; /* millicelsius */ | |
| 349 | + type = "critical"; | |
| 350 | + }; | |
| 351 | + }; | |
| 352 | + | |
| 353 | + cooling-maps { | |
| 354 | + /* each zone within the SoC may have its own cooling */ | |
| 355 | + ... | |
| 356 | + }; | |
| 357 | + }; | |
| 358 | + | |
| 359 | + gpu-thermal: gpu-thermal { | |
| 360 | + polling-delay-passive = <120>; /* milliseconds */ | |
| 361 | + polling-delay = <1000>; /* milliseconds */ | |
| 362 | + | |
| 363 | + /* sensor ID */ | |
| 364 | + thermal-sensors = <&bandgap0 1>; | |
| 365 | + | |
| 366 | + trips { | |
| 367 | + /* each zone within the SoC may have its own trips */ | |
| 368 | + gpu-alert: gpu-alert { | |
| 369 | + temperature = <90000>; /* millicelsius */ | |
| 370 | + hysteresis = <2000>; /* millicelsius */ | |
| 371 | + type = "passive"; | |
| 372 | + }; | |
| 373 | + gpu-crit: gpu-crit { | |
| 374 | + temperature = <105000>; /* millicelsius */ | |
| 375 | + hysteresis = <2000>; /* millicelsius */ | |
| 376 | + type = "critical"; | |
| 377 | + }; | |
| 378 | + }; | |
| 379 | + | |
| 380 | + cooling-maps { | |
| 381 | + /* each zone within the SoC may have its own cooling */ | |
| 382 | + ... | |
| 383 | + }; | |
| 384 | + }; | |
| 385 | + | |
| 386 | + dsp-thermal: dsp-thermal { | |
| 387 | + polling-delay-passive = <50>; /* milliseconds */ | |
| 388 | + polling-delay = <1000>; /* milliseconds */ | |
| 389 | + | |
| 390 | + /* sensor ID */ | |
| 391 | + thermal-sensors = <&bandgap0 2>; | |
| 392 | + | |
| 393 | + trips { | |
| 394 | + /* each zone within the SoC may have its own trips */ | |
| 395 | + dsp-alert: gpu-alert { | |
| 396 | + temperature = <90000>; /* millicelsius */ | |
| 397 | + hysteresis = <2000>; /* millicelsius */ | |
| 398 | + type = "passive"; | |
| 399 | + }; | |
| 400 | + dsp-crit: gpu-crit { | |
| 401 | + temperature = <135000>; /* millicelsius */ | |
| 402 | + hysteresis = <2000>; /* millicelsius */ | |
| 403 | + type = "critical"; | |
| 404 | + }; | |
| 405 | + }; | |
| 406 | + | |
| 407 | + cooling-maps { | |
| 408 | + /* each zone within the SoC may have its own cooling */ | |
| 409 | + ... | |
| 410 | + }; | |
| 411 | + }; | |
| 412 | +}; | |
| 413 | + | |
| 414 | +In the example above, there is one bandgap IC which has the capability to | |
| 415 | +monitor three sensors. The hardware has been designed so that sensors are | |
| 416 | +placed on different places in the DIE to monitor different temperature | |
| 417 | +hotspots: one for CPU thermal zone, one for GPU thermal zone and the | |
| 418 | +other to monitor a DSP thermal zone. | |
| 419 | + | |
| 420 | +Thus, there is a need to assign each sensor provided by the bandgap IC | |
| 421 | +to different thermal zones. This is achieved by means of using the | |
| 422 | +#thermal-sensor-cells property and using the first cell of the sensor | |
| 423 | +specifier as sensor ID. In the example, then, <bandgap 0> is used to | |
| 424 | +monitor CPU thermal zone, <bandgap 1> is used to monitor GPU thermal | |
| 425 | +zone and <bandgap 2> is used to monitor DSP thermal zone. Each zone | |
| 426 | +may be uncorrelated, having its own dT/dt requirements, trips | |
| 427 | +and cooling maps. | |
| 428 | + | |
| 429 | + | |
| 430 | +(c) - Several sensors within one single thermal zone | |
| 431 | + | |
| 432 | +The example below illustrates how to use more than one sensor within | |
| 433 | +one thermal zone. | |
| 434 | + | |
| 435 | +#include <dt-bindings/thermal/thermal.h> | |
| 436 | + | |
| 437 | +&i2c1 { | |
| 438 | + ... | |
| 439 | + /* | |
| 440 | + * A simple IC with a single temperature sensor. | |
| 441 | + */ | |
| 442 | + adc: sensor@0x49 { | |
| 443 | + ... | |
| 444 | + #thermal-sensor-cells = <0>; | |
| 445 | + }; | |
| 446 | +}; | |
| 447 | + | |
| 448 | +ocp { | |
| 449 | + ... | |
| 450 | + /* | |
| 451 | + * A simple IC with a single bandgap temperature sensor. | |
| 452 | + */ | |
| 453 | + bandgap0: bandgap@0x0000ED00 { | |
| 454 | + ... | |
| 455 | + #thermal-sensor-cells = <0>; | |
| 456 | + }; | |
| 457 | +}; | |
| 458 | + | |
| 459 | +thermal-zones { | |
| 460 | + cpu-thermal: cpu-thermal { | |
| 461 | + polling-delay-passive = <250>; /* milliseconds */ | |
| 462 | + polling-delay = <1000>; /* milliseconds */ | |
| 463 | + | |
| 464 | + thermal-sensors = <&bandgap0>, /* cpu */ | |
| 465 | + <&adc>; /* pcb north */ | |
| 466 | + | |
| 467 | + /* hotspot = 100 * bandgap - 120 * adc + 484 */ | |
| 468 | + coefficients = <100 -120 484>; | |
| 469 | + | |
| 470 | + trips { | |
| 471 | + ... | |
| 472 | + }; | |
| 473 | + | |
| 474 | + cooling-maps { | |
| 475 | + ... | |
| 476 | + }; | |
| 477 | + }; | |
| 478 | +}; | |
| 479 | + | |
| 480 | +In some cases, there is a need to use more than one sensor to extrapolate | |
| 481 | +a thermal hotspot in the silicon. The above example illustrates this situation. | |
| 482 | +For instance, it may be the case that a sensor external to CPU IP may be placed | |
| 483 | +close to CPU hotspot and together with internal CPU sensor, it is used | |
| 484 | +to determine the hotspot. Assuming this is the case for the above example, | |
| 485 | +the hypothetical extrapolation rule would be: | |
| 486 | + hotspot = 100 * bandgap - 120 * adc + 484 | |
| 487 | + | |
| 488 | +In other context, the same idea can be used to add fixed offset. For instance, | |
| 489 | +consider the hotspot extrapolation rule below: | |
| 490 | + hotspot = 1 * adc + 6000 | |
| 491 | + | |
| 492 | +In the above equation, the hotspot is always 6C higher than what is read | |
| 493 | +from the ADC sensor. The binding would be then: | |
| 494 | + thermal-sensors = <&adc>; | |
| 495 | + | |
| 496 | + /* hotspot = 1 * adc + 6000 */ | |
| 497 | + coefficients = <1 6000>; | |
| 498 | + | |
| 499 | +(d) - Board thermal | |
| 500 | + | |
| 501 | +The board thermal example below illustrates how to setup one thermal zone | |
| 502 | +with many sensors and many cooling devices. | |
| 503 | + | |
| 504 | +#include <dt-bindings/thermal/thermal.h> | |
| 505 | + | |
| 506 | +&i2c1 { | |
| 507 | + ... | |
| 508 | + /* | |
| 509 | + * An IC with several temperature sensor. | |
| 510 | + */ | |
| 511 | + adc-dummy: sensor@0x50 { | |
| 512 | + ... | |
| 513 | + #thermal-sensor-cells = <1>; /* sensor internal ID */ | |
| 514 | + }; | |
| 515 | +}; | |
| 516 | + | |
| 517 | +thermal-zones { | |
| 518 | + batt-thermal { | |
| 519 | + polling-delay-passive = <500>; /* milliseconds */ | |
| 520 | + polling-delay = <2500>; /* milliseconds */ | |
| 521 | + | |
| 522 | + /* sensor ID */ | |
| 523 | + thermal-sensors = <&adc-dummy 4>; | |
| 524 | + | |
| 525 | + trips { | |
| 526 | + ... | |
| 527 | + }; | |
| 528 | + | |
| 529 | + cooling-maps { | |
| 530 | + ... | |
| 531 | + }; | |
| 532 | + }; | |
| 533 | + | |
| 534 | + board-thermal: board-thermal { | |
| 535 | + polling-delay-passive = <1000>; /* milliseconds */ | |
| 536 | + polling-delay = <2500>; /* milliseconds */ | |
| 537 | + | |
| 538 | + /* sensor ID */ | |
| 539 | + thermal-sensors = <&adc-dummy 0>, /* pcb top edge */ | |
| 540 | + <&adc-dummy 1>, /* lcd */ | |
| 541 | + <&adc-dymmy 2>; /* back cover */ | |
| 542 | + /* | |
| 543 | + * An array of coefficients describing the sensor | |
| 544 | + * linear relation. E.g.: | |
| 545 | + * z = c1*x1 + c2*x2 + c3*x3 | |
| 546 | + */ | |
| 547 | + coefficients = <1200 -345 890>; | |
| 548 | + | |
| 549 | + trips { | |
| 550 | + /* Trips are based on resulting linear equation */ | |
| 551 | + cpu-trip: cpu-trip { | |
| 552 | + temperature = <60000>; /* millicelsius */ | |
| 553 | + hysteresis = <2000>; /* millicelsius */ | |
| 554 | + type = "passive"; | |
| 555 | + }; | |
| 556 | + gpu-trip: gpu-trip { | |
| 557 | + temperature = <55000>; /* millicelsius */ | |
| 558 | + hysteresis = <2000>; /* millicelsius */ | |
| 559 | + type = "passive"; | |
| 560 | + } | |
| 561 | + lcd-trip: lcp-trip { | |
| 562 | + temperature = <53000>; /* millicelsius */ | |
| 563 | + hysteresis = <2000>; /* millicelsius */ | |
| 564 | + type = "passive"; | |
| 565 | + }; | |
| 566 | + crit-trip: crit-trip { | |
| 567 | + temperature = <68000>; /* millicelsius */ | |
| 568 | + hysteresis = <2000>; /* millicelsius */ | |
| 569 | + type = "critical"; | |
| 570 | + }; | |
| 571 | + }; | |
| 572 | + | |
| 573 | + cooling-maps { | |
| 574 | + map0 { | |
| 575 | + trip = <&cpu-trip>; | |
| 576 | + cooling-device = <&cpu0 0 2>; | |
| 577 | + contribution = <55>; | |
| 578 | + }; | |
| 579 | + map1 { | |
| 580 | + trip = <&gpu-trip>; | |
| 581 | + cooling-device = <&gpu0 0 2>; | |
| 582 | + contribution = <20>; | |
| 583 | + }; | |
| 584 | + map2 { | |
| 585 | + trip = <&lcd-trip>; | |
| 586 | + cooling-device = <&lcd0 5 10>; | |
| 587 | + contribution = <15>; | |
| 588 | + }; | |
| 589 | + }; | |
| 590 | + }; | |
| 591 | +}; | |
| 592 | + | |
| 593 | +The above example is a mix of previous examples, a sensor IP with several internal | |
| 594 | +sensors used to monitor different zones, one of them is composed by several sensors and | |
| 595 | +with different cooling devices. | |
| @@ -8,6 +8,8 @@ Required properties: · 7 unmodified lines | ||
| 8 | 8 | - compatible : should be "nvidia,tegra20-timer". |
| 9 | 9 | - reg : Specifies base physical address and size of the registers. |
| 10 | 10 | - interrupts : A list of 4 interrupts; one per timer channel. |
| 11 | +- clocks : Must contain one entry, for the module clock. | |
| 12 | + See ../clocks/clock-bindings.txt for details. | |
| 11 | 13 | |
| 12 | 14 | Example: |
| 13 | 15 | |
| @@ -18,4 +20,5 @@ timer { · 4 unmodified lines | ||
| 18 | 20 | 0 1 0x04 |
| 19 | 21 | 0 41 0x04 |
| 20 | 22 | 0 42 0x04>; |
| 23 | + clocks = <&tegra_car 132>; | |
| 21 | 24 | }; |
| @@ -10,6 +10,8 @@ Required properties: · 9 unmodified lines | ||
| 10 | 10 | - reg : Specifies base physical address and size of the registers. |
| 11 | 11 | - interrupts : A list of 6 interrupts; one per each of timer channels 1 |
| 12 | 12 | through 5, and one for the shared interrupt for the remaining channels. |
| 13 | +- clocks : Must contain one entry, for the module clock. | |
| 14 | + See ../clocks/clock-bindings.txt for details. | |
| 13 | 15 | |
| 14 | 16 | timer { |
| 15 | 17 | compatible = "nvidia,tegra30-timer", "nvidia,tegra20-timer"; |
| @@ -20,4 +22,5 @@ timer { · 4 unmodified lines | ||
| 20 | 22 | 0 42 0x04 |
| 21 | 23 | 0 121 0x04 |
| 22 | 24 | 0 122 0x04>; |
| 25 | + clocks = <&tegra_car 214>; | |
| 23 | 26 | }; |
| @@ -31,38 +31,58 @@ Required properties: · 30 unmodified lines | ||
| 31 | 31 | 7: .. |
| 32 | 32 | i: Local Timer Interrupt n |
| 33 | 33 | |
| 34 | −Example 1: In this example, the system uses only the first global timer | |
| 35 | − interrupt generated by MCT and the remaining three global timer | |
| 36 | − interrupts are unused. Two local timer interrupts have been | |
| 37 | − specified. | |
| 34 | + For MCT block that uses a per-processor interrupt for local timers, such | |
| 35 | + as ones compatible with "samsung,exynos4412-mct", only one local timer | |
| 36 | + interrupt might be specified, meaning that all local timers use the same | |
| 37 | + per processor interrupt. | |
| 38 | + | |
| 39 | +Example 1: In this example, the IP contains two local timers, using separate | |
| 40 | + interrupts, so two local timer interrupts have been specified, | |
| 41 | + in addition to four global timer interrupts. | |
| 38 | 42 | |
| 39 | 43 | mct@10050000 { |
| 40 | 44 | compatible = "samsung,exynos4210-mct"; |
| 41 | 45 | reg = <0x10050000 0x800>; |
| 42 | − interrupts = <0 57 0>, <0 0 0>, <0 0 0>, <0 0 0>, | |
| 46 | + interrupts = <0 57 0>, <0 69 0>, <0 70 0>, <0 71 0>, | |
| 43 | 47 | <0 42 0>, <0 48 0>; |
| 44 | 48 | }; |
| 45 | 49 | |
| 46 | −Example 2: In this example, the MCT global and local timer interrupts are | |
| 47 | − connected to two separate interrupt controllers. Hence, an | |
| 48 | − interrupt-map is created to map the interrupts to the respective | |
| 49 | − interrupt controllers. | |
| 50 | +Example 2: In this example, the timer interrupts are connected to two separate | |
| 51 | + interrupt controllers. Hence, an interrupt-map is created to map | |
| 52 | + the interrupts to the respective interrupt controllers. | |
| 50 | 53 | |
| 51 | 54 | mct@101C0000 { |
| 52 | 55 | compatible = "samsung,exynos4210-mct"; |
| 53 | 56 | reg = <0x101C0000 0x800>; |
| 54 | − interrupt-controller; | |
| 55 | − #interrups-cells = <2>; | |
| 56 | 57 | interrupt-parent = <&mct_map>; |
| 57 | − interrupts = <0 0>, <1 0>, <2 0>, <3 0>, | |
| 58 | − <4 0>, <5 0>; | |
| 58 | + interrupts = <0>, <1>, <2>, <3>, <4>, <5>; | |
| 59 | 59 | |
| 60 | 60 | mct_map: mct-map { |
| 61 | − #interrupt-cells = <2>; | |
| 61 | + #interrupt-cells = <1>; | |
| 62 | 62 | #address-cells = <0>; |
| 63 | 63 | #size-cells = <0>; |
| 64 | − interrupt-map = <0x0 0 &combiner 23 3>, | |
| 65 | − <0x4 0 &gic 0 120 0>, | |
| 66 | − <0x5 0 &gic 0 121 0>; | |
| 64 | + interrupt-map = <0 &gic 0 57 0>, | |
| 65 | + <1 &gic 0 69 0>, | |
| 66 | + <2 &combiner 12 6>, | |
| 67 | + <3 &combiner 12 7>, | |
| 68 | + <4 &gic 0 42 0>, | |
| 69 | + <5 &gic 0 48 0>; | |
| 67 | 70 | }; |
| 68 | 71 | }; |
| 72 | + | |
| 73 | +Example 3: In this example, the IP contains four local timers, but using | |
| 74 | + a per-processor interrupt to handle them. Either all the local | |
| 75 | + timer interrupts can be specified, with the same interrupt specifier | |
| 76 | + value or just the first one. | |
| 77 | + | |
| 78 | + mct@10050000 { | |
| 79 | + compatible = "samsung,exynos4412-mct"; | |
| 80 | + reg = <0x10050000 0x800>; | |
| 81 | + | |
| 82 | + /* Both ways are possible in this case. Either: */ | |
| 83 | + interrupts = <0 57 0>, <0 69 0>, <0 70 0>, <0 71 0>, | |
| 84 | + <0 42 0>; | |
| 85 | + /* or: */ | |
| 86 | + interrupts = <0 57 0>, <0 69 0>, <0 70 0>, <0 71 0>, | |
| 87 | + <0 42 0>, <0 42 0>, <0 42 0>, <0 42 0>; | |
| 88 | + }; | |
File renamed without changes.
| @@ -0,0 +1,29 @@ | ||
| 1 | +Platform DesignWare HS OTG USB 2.0 controller | |
| 2 | +----------------------------------------------------- | |
| 3 | + | |
| 4 | +Required properties: | |
| 5 | +- compatible : One of: | |
| 6 | + - brcm,bcm2835-usb: The DWC2 USB controller instance in the BCM2835 SoC. | |
| 7 | + - snps,dwc2: A generic DWC2 USB controller with default parameters. | |
| 8 | +- reg : Should contain 1 register range (address and length) | |
| 9 | +- interrupts : Should contain 1 interrupt | |
| 10 | +- clocks: clock provider specifier | |
| 11 | +- clock-names: shall be "otg" | |
| 12 | +Refer to clk/clock-bindings.txt for generic clock consumer properties | |
| 13 | + | |
| 14 | +Optional properties: | |
| 15 | +- phys: phy provider specifier | |
| 16 | +- phy-names: shall be "device" | |
| 17 | +Refer to phy/phy-bindings.txt for generic phy consumer properties | |
| 18 | + | |
| 19 | +Example: | |
| 20 | + | |
| 21 | + usb@101c0000 { | |
| 22 | + compatible = "ralink,rt3050-usb, snps,dwc2"; | |
| 23 | + reg = <0x101c0000 40000>; | |
| 24 | + interrupts = <18>; | |
| 25 | + clocks = <&usb_otg_ahb_clk>; | |
| 26 | + clock-names = "otg"; | |
| 27 | + phys = <&usbphy>; | |
| 28 | + phy-names = "usb2-phy"; | |
| 29 | + }; | |
| @@ -0,0 +1,28 @@ | ||
| 1 | +USB Peripheral Controller driver for Aeroflex Gaisler GRUSBDC. | |
| 2 | + | |
| 3 | +The GRUSBDC USB Device Controller core is available in the GRLIB VHDL | |
| 4 | +IP core library. | |
| 5 | + | |
| 6 | +Note: In the ordinary environment for the core, a Leon SPARC system, | |
| 7 | +these properties are built from information in the AMBA plug&play. | |
| 8 | + | |
| 9 | +Required properties: | |
| 10 | + | |
| 11 | +- name : Should be "GAISLER_USBDC" or "01_021" | |
| 12 | + | |
| 13 | +- reg : Address and length of the register set for the device | |
| 14 | + | |
| 15 | +- interrupts : Interrupt numbers for this device | |
| 16 | + | |
| 17 | +Optional properties: | |
| 18 | + | |
| 19 | +- epobufsizes : An array of buffer sizes for OUT endpoints. If the property is | |
| 20 | + not present, or for endpoints outside of the array, 1024 is assumed by | |
| 21 | + the driver. | |
| 22 | + | |
| 23 | +- epibufsizes : An array of buffer sizes for IN endpoints. If the property is | |
| 24 | + not present, or for endpoints outside of the array, 1024 is assumed by | |
| 25 | + the driver. | |
| 26 | + | |
| 27 | +For further information look in the documentation for the GLIB IP core library: | |
| 28 | +http://www.gaisler.com/products/grlib/grip.pdf | |
| @@ -0,0 +1,20 @@ | ||
| 1 | +TI Keystone USB PHY | |
| 2 | + | |
| 3 | +Required properties: | |
| 4 | + - compatible: should be "ti,keystone-usbphy". | |
| 5 | + - #address-cells, #size-cells : should be '1' if the device has sub-nodes | |
| 6 | + with 'reg' property. | |
| 7 | + - reg : Address and length of the usb phy control register set. | |
| 8 | + | |
| 9 | +The main purpose of this PHY driver is to enable the USB PHY reference clock | |
| 10 | +gate on the Keystone SOC for both the USB2 and USB3 PHY. Otherwise it is just | |
| 11 | +an NOP PHY driver. Hence this node is referenced as both the usb2 and usb3 | |
| 12 | +phy node in the USB Glue layer driver node. | |
| 13 | + | |
| 14 | +usb_phy: usb_phy@2620738 { | |
| 15 | + compatible = "ti,keystone-usbphy"; | |
| 16 | + #address-cells = <1>; | |
| 17 | + #size-cells = <1>; | |
| 18 | + reg = <0x2620738 32>; | |
| 19 | + status = "disabled"; | |
| 20 | +}; | |
| @@ -0,0 +1,42 @@ | ||
| 1 | +TI Keystone Soc USB Controller | |
| 2 | + | |
| 3 | +DWC3 GLUE | |
| 4 | + | |
| 5 | +Required properties: | |
| 6 | + - compatible: should be "ti,keystone-dwc3". | |
| 7 | + - #address-cells, #size-cells : should be '1' if the device has sub-nodes | |
| 8 | + with 'reg' property. | |
| 9 | + - reg : Address and length of the register set for the USB subsystem on | |
| 10 | + the SOC. | |
| 11 | + - interrupts : The irq number of this device that is used to interrupt the | |
| 12 | + MPU. | |
| 13 | + - ranges: allows valid 1:1 translation between child's address space and | |
| 14 | + parent's address space. | |
| 15 | + - clocks: Clock IDs array as required by the controller. | |
| 16 | + - clock-names: names of clocks correseponding to IDs in the clock property. | |
| 17 | + | |
| 18 | +Sub-nodes: | |
| 19 | +The dwc3 core should be added as subnode to Keystone DWC3 glue. | |
| 20 | +- dwc3 : | |
| 21 | + The binding details of dwc3 can be found in: | |
| 22 | + Documentation/devicetree/bindings/usb/dwc3.txt | |
| 23 | + | |
| 24 | +Example: | |
| 25 | + usb: usb@2680000 { | |
| 26 | + compatible = "ti,keystone-dwc3"; | |
| 27 | + #address-cells = <1>; | |
| 28 | + #size-cells = <1>; | |
| 29 | + reg = <0x2680000 0x10000>; | |
| 30 | + clocks = <&clkusb>; | |
| 31 | + clock-names = "usb"; | |
| 32 | + interrupts = <GIC_SPI 393 IRQ_TYPE_EDGE_RISING>; | |
| 33 | + ranges; | |
| 34 | + status = "disabled"; | |
| 35 | + | |
| 36 | + dwc3@2690000 { | |
| 37 | + compatible = "synopsys,dwc3"; | |
| 38 | + reg = <0x2690000 0x70000>; | |
| 39 | + interrupts = <GIC_SPI 393 IRQ_TYPE_EDGE_RISING>; | |
| 40 | + usb-phy = <&usb_phy>, <&usb_phy>; | |
| 41 | + }; | |
| 42 | + }; | |
| @@ -8,7 +8,12 @@ and additions : · 7 unmodified lines | ||
| 8 | 8 | Required properties : |
| 9 | 9 | - compatible : Should be "nvidia,tegra20-ehci". |
| 10 | 10 | - nvidia,phy : phandle of the PHY that the controller is connected to. |
| 11 | − - clocks : Contains a single entry which defines the USB controller's clock. | |
| 11 | + - clocks : Must contain one entry, for the module clock. | |
| 12 | + See ../clocks/clock-bindings.txt for details. | |
| 13 | + - resets : Must contain an entry for each entry in reset-names. | |
| 14 | + See ../reset/reset.txt for details. | |
| 15 | + - reset-names : Must include the following entries: | |
| 16 | + - usb | |
| 12 | 17 | |
| 13 | 18 | Optional properties: |
| 14 | 19 | - nvidia,needs-double-reset : boolean is to be set for some of the Tegra20 |
| @@ -87,6 +87,8 @@ Required properties: · 86 unmodified lines | ||
| 87 | 87 | e.g. USB3 PHY and SATA PHY on OMAP5. |
| 88 | 88 | "ti,control-phy-dra7usb2" - if it has power down register like USB2 PHY on |
| 89 | 89 | DRA7 platform. |
| 90 | + "ti,control-phy-am437usb2" - if it has power down register like USB2 PHY on | |
| 91 | + AM437 platform. | |
| 90 | 92 | - reg : Address and length of the register set for the device. It contains |
| 91 | 93 | the address of "otghs_control" for control-phy-otghs or "power" register |
| 92 | 94 | for other types. |
| @@ -3,12 +3,14 @@ Device tree binding vendor prefix registry. Keep list in alphabetical order. · 2 unmodified lines | ||
| 3 | 3 | This isn't an exhaustive list, but you should add new prefixes to it before |
| 4 | 4 | using them to avoid name-space collisions. |
| 5 | 5 | |
| 6 | +active-semi Active-Semi International Inc | |
| 6 | 7 | ad Avionic Design GmbH |
| 7 | 8 | adi Analog Devices, Inc. |
| 8 | 9 | aeroflexgaisler Aeroflex Gaisler AB |
| 9 | 10 | ak Asahi Kasei Corp. |
| 10 | 11 | altr Altera Corp. |
| 11 | 12 | amcc Applied Micro Circuits Corporation (APM, formally AMCC) |
| 13 | +amstaos AMS-Taos Inc. | |
| 12 | 14 | apm Applied Micro Circuits Corporation (APM) |
| 13 | 15 | arm ARM Ltd. |
| 14 | 16 | atmel Atmel Corporation |
| @@ -26,19 +28,25 @@ cortina Cortina Systems, Inc. · 11 unmodified lines | ||
| 26 | 28 | dallas Maxim Integrated Products (formerly Dallas Semiconductor) |
| 27 | 29 | davicom DAVICOM Semiconductor, Inc. |
| 28 | 30 | denx Denx Software Engineering |
| 31 | +edt Emerging Display Technologies | |
| 29 | 32 | emmicro EM Microelectronic |
| 33 | +epfl Ecole Polytechnique Fédérale de Lausanne | |
| 30 | 34 | epson Seiko Epson Corp. |
| 31 | 35 | est ESTeem Wireless Modems |
| 32 | 36 | fsl Freescale Semiconductor |
| 33 | 37 | GEFanuc GE Fanuc Intelligent Platforms Embedded Systems, Inc. |
| 34 | 38 | gef GE Fanuc Intelligent Platforms Embedded Systems, Inc. |
| 35 | 39 | gmt Global Mixed-mode Technology, Inc. |
| 40 | +gumstix Gumstix, Inc. | |
| 41 | +haoyu Haoyu Microelectronic Co. Ltd. | |
| 36 | 42 | hisilicon Hisilicon Limited. |
| 37 | 43 | hp Hewlett Packard |
| 38 | 44 | ibm International Business Machines (IBM) |
| 39 | 45 | idt Integrated Device Technologies, Inc. |
| 40 | 46 | img Imagination Technologies Ltd. |
| 41 | 47 | intercontrol Inter Control Group |
| 48 | +isl Intersil | |
| 49 | +karo Ka-Ro electronics GmbH | |
| 42 | 50 | lg LG Corporation |
| 43 | 51 | linux Linux-specific binding |
| 44 | 52 | lsi LSI Corp. (LSI Logic) |
| @@ -61,6 +69,7 @@ ralink Mediatek/Ralink Technology Corp. · 16 unmodified lines | ||
| 61 | 69 | ramtron Ramtron International |
| 62 | 70 | realtek Realtek Semiconductor Corp. |
| 63 | 71 | renesas Renesas Electronics Corporation |
| 72 | +rockchip Fuzhou Rockchip Electronics Co., Ltd | |
| 64 | 73 | samsung Samsung Semiconductor |
| 65 | 74 | sbs Smart Battery System |
| 66 | 75 | schindler Schindler |
| @@ -73,6 +82,7 @@ st STMicroelectronics · 6 unmodified lines | ||
| 73 | 82 | ste ST-Ericsson |
| 74 | 83 | stericsson ST-Ericsson |
| 75 | 84 | ti Texas Instruments |
| 85 | +tlm Trusted Logic Mobility | |
| 76 | 86 | toshiba Toshiba Corporation |
| 77 | 87 | toumaz Toumaz |
| 78 | 88 | v3 V3 Semiconductor |
| @@ -0,0 +1,13 @@ | ||
| 1 | +* Solomon SSD1289 Framebuffer Driver | |
| 2 | + | |
| 3 | +Required properties: | |
| 4 | + - compatible: Should be "solomon,ssd1289fb". The only supported bus for | |
| 5 | + now is lbc. | |
| 6 | + - reg: Should contain address of the controller on the LBC bus. The detail | |
| 7 | + was described in Documentation/devicetree/bindings/powerpc/fsl/lbc.txt | |
| 8 | + | |
| 9 | +Examples: | |
| 10 | +display@2,0 { | |
| 11 | + compatible = "solomon,ssd1289fb"; | |
| 12 | + reg = <0x2 0x0000 0x0004>; | |
| 13 | +}; | |
| @@ -9,11 +9,37 @@ Required properties: · 8 unmodified lines | ||
| 9 | 9 | |
| 10 | 10 | Optional properties: |
| 11 | 11 | - timeout-sec: contains the watchdog timeout in seconds. |
| 12 | +- interrupts : Should contain WDT interrupt. | |
| 13 | +- atmel,max-heartbeat-sec : Should contain the maximum heartbeat value in | |
| 14 | + seconds. This value should be less or equal to 16. It is used to | |
| 15 | + compute the WDV field. | |
| 16 | +- atmel,min-heartbeat-sec : Should contain the minimum heartbeat value in | |
| 17 | + seconds. This value must be smaller than the max-heartbeat-sec value. | |
| 18 | + It is used to compute the WDD field. | |
| 19 | +- atmel,watchdog-type : Should be "hardware" or "software". Hardware watchdog | |
| 20 | + use the at91 watchdog reset. Software watchdog use the watchdog | |
| 21 | + interrupt to trigger a software reset. | |
| 22 | +- atmel,reset-type : Should be "proc" or "all". | |
| 23 | + "all" : assert peripherals and processor reset signals | |
| 24 | + "proc" : assert the processor reset signal | |
| 25 | + This is valid only when using "hardware" watchdog. | |
| 26 | +- atmel,disable : Should be present if you want to disable the watchdog. | |
| 27 | +- atmel,idle-halt : Should be present if you want to stop the watchdog when | |
| 28 | + entering idle state. | |
| 29 | +- atmel,dbg-halt : Should be present if you want to stop the watchdog when | |
| 30 | + entering debug state. | |
| 12 | 31 | |
| 13 | 32 | Example: |
| 14 | − | |
| 15 | 33 | watchdog@fffffd40 { |
| 16 | 34 | compatible = "atmel,at91sam9260-wdt"; |
| 17 | 35 | reg = <0xfffffd40 0x10>; |
| 18 | − timeout-sec = <10>; | |
| 36 | + interrupts = <1 IRQ_TYPE_LEVEL_HIGH 7>; | |
| 37 | + timeout-sec = <15>; | |
| 38 | + atmel,watchdog-type = "hardware"; | |
| 39 | + atmel,reset-type = "all"; | |
| 40 | + atmel,dbg-halt; | |
| 41 | + atmel,idle-halt; | |
| 42 | + atmel,max-heartbeat-sec = <16>; | |
| 43 | + atmel,min-heartbeat-sec = <0>; | |
| 44 | + status = "okay"; | |
| 19 | 45 | }; |
| @@ -1,12 +1,24 @@ | ||
| 1 | −DaVinci Watchdog Timer (WDT) Controller | |
| 1 | +Texas Instruments DaVinci/Keystone Watchdog Timer (WDT) Controller | |
| 2 | 2 | |
| 3 | 3 | Required properties: |
| 4 | −- compatible : Should be "ti,davinci-wdt" | |
| 4 | +- compatible : Should be "ti,davinci-wdt", "ti,keystone-wdt" | |
| 5 | 5 | - reg : Should contain WDT registers location and length |
| 6 | 6 | |
| 7 | +Optional properties: | |
| 8 | +- timeout-sec : Contains the watchdog timeout in seconds | |
| 9 | +- clocks : the clock feeding the watchdog timer. | |
| 10 | + Needed if platform uses clocks. | |
| 11 | + See clock-bindings.txt | |
| 12 | + | |
| 13 | +Documentation: | |
| 14 | +Davinci DM646x - http://www.ti.com/lit/ug/spruer5b/spruer5b.pdf | |
| 15 | +Keystone - http://www.ti.com/lit/ug/sprugv5a/sprugv5a.pdf | |
| 16 | + | |
| 7 | 17 | Examples: |
| 8 | 18 | |
| 9 | 19 | wdt: wdt@2320000 { |
| 10 | 20 | compatible = "ti,davinci-wdt"; |
| 11 | 21 | reg = <0x02320000 0x80>; |
| 22 | + timeout-sec = <30>; | |
| 23 | + clocks = <&clkwdtimer0>; | |
| 12 | 24 | }; |
| @@ -0,0 +1,23 @@ | ||
| 1 | +* GPIO-controlled Watchdog | |
| 2 | + | |
| 3 | +Required Properties: | |
| 4 | +- compatible: Should contain "linux,wdt-gpio". | |
| 5 | +- gpios: From common gpio binding; gpio connection to WDT reset pin. | |
| 6 | +- hw_algo: The algorithm used by the driver. Should be one of the | |
| 7 | + following values: | |
| 8 | + - toggle: Either a high-to-low or a low-to-high transition clears | |
| 9 | + the WDT counter. The watchdog timer is disabled when GPIO is | |
| 10 | + left floating or connected to a three-state buffer. | |
| 11 | + - level: Low or high level starts counting WDT timeout, | |
| 12 | + the opposite level disables the WDT. Active level is determined | |
| 13 | + by the GPIO flags. | |
| 14 | +- hw_margin_ms: Maximum time to reset watchdog circuit (milliseconds). | |
| 15 | + | |
| 16 | +Example: | |
| 17 | + watchdog: watchdog { | |
| 18 | + /* ADM706 */ | |
| 19 | + compatible = "linux,wdt-gpio"; | |
| 20 | + gpios = <&gpio3 9 GPIO_ACTIVE_LOW>; | |
| 21 | + hw_algo = "toggle"; | |
| 22 | + hw_margin_ms = <1600>; | |
| 23 | + }; | |
| @@ -5,10 +5,29 @@ after a preset amount of time during which the WDT reset event has not · 4 unmodified lines | ||
| 5 | 5 | occurred. |
| 6 | 6 | |
| 7 | 7 | Required properties: |
| 8 | −- compatible : should be "samsung,s3c2410-wdt" | |
| 8 | +- compatible : should be one among the following | |
| 9 | + (a) "samsung,s3c2410-wdt" for Exynos4 and previous SoCs | |
| 10 | + (b) "samsung,exynos5250-wdt" for Exynos5250 | |
| 11 | + (c) "samsung,exynos5420-wdt" for Exynos5420 | |
| 12 | + | |
| 9 | 13 | - reg : base physical address of the controller and length of memory mapped |
| 10 | 14 | region. |
| 11 | 15 | - interrupts : interrupt number to the cpu. |
| 16 | +- samsung,syscon-phandle : reference to syscon node (This property required only | |
| 17 | + in case of compatible being "samsung,exynos5250-wdt" or "samsung,exynos5420-wdt". | |
| 18 | + In case of Exynos5250 and 5420 this property points to syscon node holding the PMU | |
| 19 | + base address) | |
| 12 | 20 | |
| 13 | 21 | Optional properties: |
| 14 | 22 | - timeout-sec : contains the watchdog timeout in seconds. |
| 23 | + | |
| 24 | +Example: | |
| 25 | + | |
| 26 | +watchdog@101D0000 { | |
| 27 | + compatible = "samsung,exynos5250-wdt"; | |
| 28 | + reg = <0x101D0000 0x100>; | |
| 29 | + interrupts = <0 42 0>; | |
| 30 | + clocks = <&clock 336>; | |
| 31 | + clock-names = "watchdog"; | |
| 32 | + samsung,syscon-phandle = <&pmu_syscon>; | |
| 33 | +}; | |
| @@ -1364,19 +1364,16 @@ Appendix A - Sample SOC node for MPC8540 · 1363 unmodified lines | ||
| 1364 | 1364 | phy0: ethernet-phy@0 { |
| 1365 | 1365 | interrupts = <5 1>; |
| 1366 | 1366 | reg = <0>; |
| 1367 | − device_type = "ethernet-phy"; | |
| 1368 | 1367 | }; |
| 1369 | 1368 | |
| 1370 | 1369 | phy1: ethernet-phy@1 { |
| 1371 | 1370 | interrupts = <5 1>; |
| 1372 | 1371 | reg = <1>; |
| 1373 | − device_type = "ethernet-phy"; | |
| 1374 | 1372 | }; |
| 1375 | 1373 | |
| 1376 | 1374 | phy3: ethernet-phy@3 { |
| 1377 | 1375 | interrupts = <7 1>; |
| 1378 | 1376 | reg = <3>; |
| 1379 | − device_type = "ethernet-phy"; | |
| 1380 | 1377 | }; |
| 1381 | 1378 | }; |
| 1382 | 1379 | }; |
| @@ -0,0 +1,116 @@ | ||
| 1 | + | |
| 2 | +Device Driver Design Patterns | |
| 3 | +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | |
| 4 | + | |
| 5 | +This document describes a few common design patterns found in device drivers. | |
| 6 | +It is likely that subsystem maintainers will ask driver developers to | |
| 7 | +conform to these design patterns. | |
| 8 | + | |
| 9 | +1. State Container | |
| 10 | +2. container_of() | |
| 11 | + | |
| 12 | + | |
| 13 | +1. State Container | |
| 14 | +~~~~~~~~~~~~~~~~~~ | |
| 15 | + | |
| 16 | +While the kernel contains a few device drivers that assume that they will | |
| 17 | +only be probed() once on a certain system (singletons), it is custom to assume | |
| 18 | +that the device the driver binds to will appear in several instances. This | |
| 19 | +means that the probe() function and all callbacks need to be reentrant. | |
| 20 | + | |
| 21 | +The most common way to achieve this is to use the state container design | |
| 22 | +pattern. It usually has this form: | |
| 23 | + | |
| 24 | +struct foo { | |
| 25 | + spinlock_t lock; /* Example member */ | |
| 26 | + (...) | |
| 27 | +}; | |
| 28 | + | |
| 29 | +static int foo_probe(...) | |
| 30 | +{ | |
| 31 | + struct foo *foo; | |
| 32 | + | |
| 33 | + foo = devm_kzalloc(dev, sizeof(*foo), GFP_KERNEL); | |
| 34 | + if (!foo) | |
| 35 | + return -ENOMEM; | |
| 36 | + spin_lock_init(&foo->lock); | |
| 37 | + (...) | |
| 38 | +} | |
| 39 | + | |
| 40 | +This will create an instance of struct foo in memory every time probe() is | |
| 41 | +called. This is our state container for this instance of the device driver. | |
| 42 | +Of course it is then necessary to always pass this instance of the | |
| 43 | +state around to all functions that need access to the state and its members. | |
| 44 | + | |
| 45 | +For example, if the driver is registering an interrupt handler, you would | |
| 46 | +pass around a pointer to struct foo like this: | |
| 47 | + | |
| 48 | +static irqreturn_t foo_handler(int irq, void *arg) | |
| 49 | +{ | |
| 50 | + struct foo *foo = arg; | |
| 51 | + (...) | |
| 52 | +} | |
| 53 | + | |
| 54 | +static int foo_probe(...) | |
| 55 | +{ | |
| 56 | + struct foo *foo; | |
| 57 | + | |
| 58 | + (...) | |
| 59 | + ret = request_irq(irq, foo_handler, 0, "foo", foo); | |
| 60 | +} | |
| 61 | + | |
| 62 | +This way you always get a pointer back to the correct instance of foo in | |
| 63 | +your interrupt handler. | |
| 64 | + | |
| 65 | + | |
| 66 | +2. container_of() | |
| 67 | +~~~~~~~~~~~~~~~~~ | |
| 68 | + | |
| 69 | +Continuing on the above example we add an offloaded work: | |
| 70 | + | |
| 71 | +struct foo { | |
| 72 | + spinlock_t lock; | |
| 73 | + struct workqueue_struct *wq; | |
| 74 | + struct work_struct offload; | |
| 75 | + (...) | |
| 76 | +}; | |
| 77 | + | |
| 78 | +static void foo_work(struct work_struct *work) | |
| 79 | +{ | |
| 80 | + struct foo *foo = container_of(work, struct foo, offload); | |
| 81 | + | |
| 82 | + (...) | |
| 83 | +} | |
| 84 | + | |
| 85 | +static irqreturn_t foo_handler(int irq, void *arg) | |
| 86 | +{ | |
| 87 | + struct foo *foo = arg; | |
| 88 | + | |
| 89 | + queue_work(foo->wq, &foo->offload); | |
| 90 | + (...) | |
| 91 | +} | |
| 92 | + | |
| 93 | +static int foo_probe(...) | |
| 94 | +{ | |
| 95 | + struct foo *foo; | |
| 96 | + | |
| 97 | + foo->wq = create_singlethread_workqueue("foo-wq"); | |
| 98 | + INIT_WORK(&foo->offload, foo_work); | |
| 99 | + (...) | |
| 100 | +} | |
| 101 | + | |
| 102 | +The design pattern is the same for an hrtimer or something similar that will | |
| 103 | +return a single argument which is a pointer to a struct member in the | |
| 104 | +callback. | |
| 105 | + | |
| 106 | +container_of() is a macro defined in <linux/kernel.h> | |
| 107 | + | |
| 108 | +What container_of() does is to obtain a pointer to the containing struct from | |
| 109 | +a pointer to a member by a simple subtraction using the offsetof() macro from | |
| 110 | +standard C, which allows something similar to object oriented behaviours. | |
| 111 | +Notice that the contained member must not be a pointer, but an actual member | |
| 112 | +for this to work. | |
| 113 | + | |
| 114 | +We can see here that we avoid having global pointers to our struct foo * | |
| 115 | +instance this way, while still keeping the number of parameters passed to the | |
| 116 | +work function to a single pointer. | |
| @@ -242,6 +242,8 @@ IIO · 241 unmodified lines | ||
| 242 | 242 | devm_iio_device_free() |
| 243 | 243 | devm_iio_trigger_alloc() |
| 244 | 244 | devm_iio_trigger_free() |
| 245 | + devm_iio_device_register() | |
| 246 | + devm_iio_device_unregister() | |
| 245 | 247 | |
| 246 | 248 | IO region |
| 247 | 249 | devm_request_region() |
| @@ -48,7 +48,7 @@ struct platform_driver { · 47 unmodified lines | ||
| 48 | 48 | struct device_driver driver; |
| 49 | 49 | }; |
| 50 | 50 | |
| 51 | −Note that probe() should general verify that the specified device hardware | |
| 51 | +Note that probe() should in general verify that the specified device hardware | |
| 52 | 52 | actually exists; sometimes platform setup code can't be sure. The probing |
| 53 | 53 | can use device resources, including clocks, and device platform_data. |
| 54 | 54 | |
| @@ -108,6 +108,12 @@ If your query set is big, you can batch them too: · 107 unmodified lines | ||
| 108 | 108 | |
| 109 | 109 | ~# cat query-batch-file > <debugfs>/dynamic_debug/control |
| 110 | 110 | |
| 111 | +A another way is to use wildcard. The match rule support '*' (matches | |
| 112 | +zero or more characters) and '?' (matches exactly one character).For | |
| 113 | +example, you can match all usb drivers: | |
| 114 | + | |
| 115 | + ~# echo "file drivers/usb/* +p" > <debugfs>/dynamic_debug/control | |
| 116 | + | |
| 111 | 117 | At the syntactical level, a command comprises a sequence of match |
| 112 | 118 | specifications, followed by a flags change specification. |
| 113 | 119 | |
| @@ -315,6 +321,9 @@ nullarbor:~ # echo -n 'func svc_process -p' > · 201 unmodified lines | ||
| 315 | 321 | nullarbor:~ # echo -n 'format "nfsd: READ" +p' > |
| 316 | 322 | <debugfs>/dynamic_debug/control |
| 317 | 323 | |
| 324 | +// enable messages in files of which the pathes include string "usb" | |
| 325 | +nullarbor:~ # echo -n '*usb* +p' > <debugfs>/dynamic_debug/control | |
| 326 | + | |
| 318 | 327 | // enable all messages |
| 319 | 328 | nullarbor:~ # echo -n '+p' > <debugfs>/dynamic_debug/control |
| 320 | 329 | |
| @@ -20,7 +20,7 @@ The EFI boot stub is enabled with the CONFIG_EFI_STUB kernel option. · 19 unmodified lines | ||
| 20 | 20 | **** How to install bzImage.efi |
| 21 | 21 | |
| 22 | 22 | The bzImage located in arch/x86/boot/bzImage must be copied to the EFI |
| 23 | −System Partiion (ESP) and renamed with the extension ".efi". Without | |
| 23 | +System Partition (ESP) and renamed with the extension ".efi". Without | |
| 24 | 24 | the extension the EFI firmware loader will refuse to execute it. It's |
| 25 | 25 | not possible to execute bzImage.efi from the usual Linux file systems |
| 26 | 26 | because EFI firmware doesn't have support for them. |
| @@ -104,7 +104,7 @@ Then from the "Message" menu item, select insert file and choose your patch. · 103 unmodified lines | ||
| 104 | 104 | As an added bonus you can customise the message creation toolbar menu |
| 105 | 105 | and put the "insert file" icon there. |
| 106 | 106 | |
| 107 | −Make the the composer window wide enough so that no lines wrap. As of | |
| 107 | +Make the composer window wide enough so that no lines wrap. As of | |
| 108 | 108 | KMail 1.13.5 (KDE 4.5.4), KMail will apply word wrapping when sending |
| 109 | 109 | the email if the lines wrap in the composer window. Having word wrapping |
| 110 | 110 | disabled in the Options menu isn't enough. Thus, if your patch has very |
| @@ -50,7 +50,7 @@ so that they are still compatible with legacy userspace processes. · 49 unmodified lines | ||
| 50 | 50 | Extcon's extended features for switch device drivers with |
| 51 | 51 | complex features usually required magic numbers in state |
| 52 | 52 | value of switch_dev. With extcon, such magic numbers that |
| 53 | − support multiple cables ( | |
| 53 | + support multiple cables are no more required or supported. | |
| 54 | 54 | |
| 55 | 55 | 1. Define cable names at edev->supported_cable. |
| 56 | 56 | 2. (Recommended) remove print_state callback. |
| @@ -114,11 +114,8 @@ exclusive, the two cables cannot be in ATTACHED state simulteneously. · 57 unmodified lines | ||
| 114 | 114 | |
| 115 | 115 | ****** ABI Location |
| 116 | 116 | |
| 117 | − If "CONFIG_ANDROID" is enabled and "CONFIG_ANDROID_SWITCH" is | |
| 118 | −disabled, /sys/class/switch/* are created as symbolic links to | |
| 119 | −/sys/class/extcon/*. Because CONFIG_ANDROID_SWITCH creates | |
| 120 | −/sys/class/switch directory, we disable symboling linking if | |
| 121 | −CONFIG_ANDROID_SWITCH is enabled. | |
| 117 | + If "CONFIG_ANDROID" is enabled, /sys/class/switch/* are created | |
| 118 | +as symbolic links to /sys/class/extcon/*. | |
| 122 | 119 | |
| 123 | 120 | The two files of switch class, name and state, are provided with |
| 124 | 121 | extcon, too. When the multistate support (STEP 2 of CHAPTER 1.) is |
| @@ -10,24 +10,32 @@ afs.txt · 9 unmodified lines | ||
| 10 | 10 | - info and examples for the distributed AFS (Andrew File System) fs. |
| 11 | 11 | affs.txt |
| 12 | 12 | - info and mount options for the Amiga Fast File System. |
| 13 | +autofs4-mount-control.txt | |
| 14 | + - info on device control operations for autofs4 module. | |
| 13 | 15 | automount-support.txt |
| 14 | 16 | - information about filesystem automount support. |
| 15 | 17 | befs.txt |
| 16 | 18 | - information about the BeOS filesystem for Linux. |
| 17 | 19 | bfs.txt |
| 18 | 20 | - info for the SCO UnixWare Boot Filesystem (BFS). |
| 21 | +btrfs.txt | |
| 22 | + - info for the BTRFS filesystem. | |
| 23 | +caching/ | |
| 24 | + - directory containing filesystem cache documentation. | |
| 19 | 25 | ceph.txt |
| 20 | − - info for the Ceph Distributed File System | |
| 21 | −cifs.txt | |
| 22 | − - description of the CIFS filesystem. | |
| 26 | + - info for the Ceph Distributed File System. | |
| 27 | +cifs/ | |
| 28 | + - directory containing CIFS filesystem documentation and example code. | |
| 23 | 29 | coda.txt |
| 24 | 30 | - description of the CODA filesystem. |
| 25 | 31 | configfs/ |
| 26 | 32 | - directory containing configfs documentation and example code. |
| 27 | 33 | cramfs.txt |
| 28 | 34 | - info on the cram filesystem for small storage (ROMs etc). |
| 29 | −dentry-locking.txt | |
| 30 | − - info on the RCU-based dcache locking model. | |
| 35 | +debugfs.txt | |
| 36 | + - info on the debugfs filesystem. | |
| 37 | +devpts.txt | |
| 38 | + - info on the devpts filesystem. | |
| 31 | 39 | directory-locking |
| 32 | 40 | - info about the locking scheme used for directory operations. |
| 33 | 41 | dlmfs.txt |
| @@ -35,7 +43,7 @@ dlmfs.txt · 1 unmodified line | ||
| 35 | 43 | dnotify.txt |
| 36 | 44 | - info about directory notification in Linux. |
| 37 | 45 | dnotify_test.c |
| 38 | − - example program for dnotify | |
| 46 | + - example program for dnotify. | |
| 39 | 47 | ecryptfs.txt |
| 40 | 48 | - docs on eCryptfs: stacked cryptographic filesystem for Linux. |
| 41 | 49 | efivarfs.txt |
| @@ -48,12 +56,18 @@ ext3.txt · 6 unmodified lines | ||
| 48 | 56 | - info, mount options and specifications for the Ext3 filesystem. |
| 49 | 57 | ext4.txt |
| 50 | 58 | - info, mount options and specifications for the Ext4 filesystem. |
| 51 | −files.txt | |
| 52 | − - info on file management in the Linux kernel. | |
| 53 | 59 | f2fs.txt |
| 54 | 60 | - info and mount options for the F2FS filesystem. |
| 61 | +fiemap.txt | |
| 62 | + - info on fiemap ioctl. | |
| 63 | +files.txt | |
| 64 | + - info on file management in the Linux kernel. | |
| 55 | 65 | fuse.txt |
| 56 | 66 | - info on the Filesystem in User SpacE including mount options. |
| 67 | +gfs2-glocks.txt | |
| 68 | + - info on the Global File System 2 - Glock internal locking rules. | |
| 69 | +gfs2-uevents.txt | |
| 70 | + - info on the Global File System 2 - uevents. | |
| 57 | 71 | gfs2.txt |
| 58 | 72 | - info on the Global File System 2. |
| 59 | 73 | hfs.txt |
| @@ -84,40 +98,58 @@ ntfs.txt · 24 unmodified lines | ||
| 84 | 98 | - info and mount options for the NTFS filesystem (Windows NT). |
| 85 | 99 | ocfs2.txt |
| 86 | 100 | - info and mount options for the OCFS2 clustered filesystem. |
| 101 | +omfs.txt | |
| 102 | + - info on the Optimized MPEG FileSystem. | |
| 103 | +path-lookup.txt | |
| 104 | + - info on path walking and name lookup locking. | |
| 105 | +pohmelfs/ | |
| 106 | + - directory containing pohmelfs filesystem documentation. | |
| 87 | 107 | porting |
| 88 | 108 | - various information on filesystem porting. |
| 89 | 109 | proc.txt |
| 90 | 110 | - info on Linux's /proc filesystem. |
| 111 | +qnx6.txt | |
| 112 | + - info on the QNX6 filesystem. | |
| 113 | +quota.txt | |
| 114 | + - info on Quota subsystem. | |
| 91 | 115 | ramfs-rootfs-initramfs.txt |
| 92 | 116 | - info on the 'in memory' filesystems ramfs, rootfs and initramfs. |
| 93 | −reiser4.txt | |
| 94 | − - info on the Reiser4 filesystem based on dancing tree algorithms. | |
| 95 | 117 | relay.txt |
| 96 | 118 | - info on relay, for efficient streaming from kernel to user space. |
| 97 | 119 | romfs.txt |
| 98 | 120 | - description of the ROMFS filesystem. |
| 99 | 121 | seq_file.txt |
| 100 | − - how to use the seq_file API | |
| 122 | + - how to use the seq_file API. | |
| 101 | 123 | sharedsubtree.txt |
| 102 | 124 | - a description of shared subtrees for namespaces. |
| 103 | 125 | spufs.txt |
| 104 | 126 | - info and mount options for the SPU filesystem used on Cell. |
| 127 | +squashfs.txt | |
| 128 | + - info on the squashfs filesystem. | |
| 105 | 129 | sysfs-pci.txt |
| 106 | 130 | - info on accessing PCI device resources through sysfs. |
| 131 | +sysfs-tagging.txt | |
| 132 | + - info on sysfs tagging to avoid duplicates. | |
| 107 | 133 | sysfs.txt |
| 108 | 134 | - info on sysfs, a ram-based filesystem for exporting kernel objects. |
| 109 | 135 | sysv-fs.txt |
| 110 | 136 | - info on the SystemV/V7/Xenix/Coherent filesystem. |
| 111 | 137 | tmpfs.txt |
| 112 | 138 | - info on tmpfs, a filesystem that holds all files in virtual memory. |
| 139 | +ubifs.txt | |
| 140 | + - info on the Unsorted Block Images FileSystem. | |
| 113 | 141 | udf.txt |
| 114 | 142 | - info and mount options for the UDF filesystem. |
| 115 | 143 | ufs.txt |
| 116 | 144 | - info on the ufs filesystem. |
| 117 | 145 | vfat.txt |
| 118 | − - info on using the VFAT filesystem used in Windows NT and Windows 95 | |
| 146 | + - info on using the VFAT filesystem used in Windows NT and Windows 95. | |
| 119 | 147 | vfs.txt |
| 120 | − - overview of the Virtual File System | |
| 148 | + - overview of the Virtual File System. | |
| 149 | +xfs-delayed-logging-design.txt | |
| 150 | + - info on the XFS Delayed Logging Design. | |
| 151 | +xfs-self-describing-metadata.txt | |
| 152 | + - info on XFS Self Describing Metadata. | |
| 121 | 153 | xfs.txt |
| 122 | 154 | - info and mount options for the XFS filesystem. |
| 123 | 155 | xip.txt |
| @@ -69,10 +69,14 @@ OPTIONS · 68 unmodified lines | ||
| 69 | 69 | offering several exported file systems. |
| 70 | 70 | |
| 71 | 71 | cache=mode specifies a caching policy. By default, no caches are used. |
| 72 | + none = default no cache policy, metadata and data | |
| 73 | + alike are synchronous. | |
| 72 | 74 | loose = no attempts are made at consistency, |
| 73 | 75 | intended for exclusive, read-only mounts |
| 74 | − fscache = use FS-Cache for a persistent, read-only | |
| 76 | + fscache = use FS-Cache for a persistent, read-only | |
| 75 | 77 | cache backend. |
| 78 | + mmap = minimal cache that is only used for read-write | |
| 79 | + mmap. Northing else is cached, like cache=none | |
| 76 | 80 | |
| 77 | 81 | debug=n specifies debug level. The debug level is a bitmask. |
| 78 | 82 | 0x01 = display verbose error messages |
| @@ -147,8 +151,7 @@ on sourceforge (http://sourceforge.net/projects/v9fs). · 68 unmodified lines | ||
| 147 | 151 | News and other information is maintained on a Wiki. |
| 148 | 152 | (http://sf.net/apps/mediawiki/v9fs/index.php). |
| 149 | 153 | |
| 150 | −Bug reports may be issued through the kernel.org bugzilla | |
| 151 | −(http://bugzilla.kernel.org) | |
| 154 | +Bug reports are best issued via the mailing list. | |
| 152 | 155 | |
| 153 | 156 | For more information on the Plan 9 Operating System check out |
| 154 | 157 | http://plan9.bell-labs.com/plan9 |
| @@ -156,11 +159,3 @@ http://plan9.bell-labs.com/plan9 · 1 unmodified line | ||
| 156 | 159 | For information on Plan 9 from User Space (Plan 9 applications and libraries |
| 157 | 160 | ported to Linux/BSD/OSX/etc) check out http://swtch.com/plan9 |
| 158 | 161 | |
| 159 | − | |
| 160 | −STATUS | |
| 161 | −====== | |
| 162 | − | |
| 163 | −The 2.6 kernel support is working on PPC and x86. | |
| 164 | − | |
| 165 | −PLEASE USE THE KERNEL BUGZILLA TO REPORT PROBLEMS. (http://bugzilla.kernel.org) | |
| 166 | − | |
| @@ -544,7 +544,7 @@ like the ->fault() handler, but simply return with VM_FAULT_NOPAGE, which · 543 unmodified lines | ||
| 544 | 544 | will cause the VM to retry the fault. |
| 545 | 545 | |
| 546 | 546 | ->access() is called when get_user_pages() fails in |
| 547 | −acces_process_vm(), typically used to debug a process through | |
| 547 | +access_process_vm(), typically used to debug a process through | |
| 548 | 548 | /proc/pid/mem or ptrace. This function is needed only for |
| 549 | 549 | VM_IO | VM_PFNMAP VMAs. |
| 550 | 550 | |
| @@ -38,7 +38,7 @@ Mount Options · 37 unmodified lines | ||
| 38 | 38 | ============= |
| 39 | 39 | |
| 40 | 40 | When mounting a btrfs filesystem, the following option are accepted. |
| 41 | −Unless otherwise specified, all options default to off. | |
| 41 | +Options with (*) are default options and will not show in the mount options. | |
| 42 | 42 | |
| 43 | 43 | alloc_start=<bytes> |
| 44 | 44 | Debugging option to force all block allocations above a certain |
| @@ -46,10 +46,12 @@ Unless otherwise specified, all options default to off. · 1 unmodified line | ||
| 46 | 46 | bytes, optionally with a K, M, or G suffix, case insensitive. |
| 47 | 47 | Default is 1MB. |
| 48 | 48 | |
| 49 | + noautodefrag(*) | |
| 49 | 50 | autodefrag |
| 50 | − Detect small random writes into files and queue them up for the | |
| 51 | − defrag process. Works best for small files; Not well suited for | |
| 52 | − large database workloads. | |
| 51 | + Disable/enable auto defragmentation. | |
| 52 | + Auto defragmentation detects small random writes into files and queue | |
| 53 | + them up for the defrag process. Works best for small files; | |
| 54 | + Not well suited for large database workloads. | |
| 53 | 55 | |
| 54 | 56 | check_int |
| 55 | 57 | check_int_data |
| @@ -96,21 +98,26 @@ Unless otherwise specified, all options default to off. · 40 unmodified lines | ||
| 96 | 98 | can be avoided. Especially useful when trying to mount a multi-device |
| 97 | 99 | setup as root. May be specified multiple times for multiple devices. |
| 98 | 100 | |
| 101 | + nodiscard(*) | |
| 99 | 102 | discard |
| 100 | − Issue frequent commands to let the block device reclaim space freed by | |
| 101 | − the filesystem. This is useful for SSD devices, thinly provisioned | |
| 103 | + Disable/enable discard mount option. | |
| 104 | + Discard issues frequent commands to let the block device reclaim space | |
| 105 | + freed by the filesystem. | |
| 106 | + This is useful for SSD devices, thinly provisioned | |
| 102 | 107 | LUNs and virtual machine images, but may have a significant |
| 103 | 108 | performance impact. (The fstrim command is also available to |
| 104 | 109 | initiate batch trims from userspace). |
| 105 | 110 | |
| 111 | + noenospc_debug(*) | |
| 106 | 112 | enospc_debug |
| 107 | − Debugging option to be more verbose in some ENOSPC conditions. | |
| 113 | + Disable/enable debugging option to be more verbose in some ENOSPC conditions. | |
| 108 | 114 | |
| 109 | 115 | fatal_errors=<action> |
| 110 | 116 | Action to take when encountering a fatal error: |
| 111 | 117 | "bug" - BUG() on a fatal error. This is the default. |
| 112 | 118 | "panic" - panic() on a fatal error. |
| 113 | 119 | |
| 120 | + noflushoncommit(*) | |
| 114 | 121 | flushoncommit |
| 115 | 122 | The 'flushoncommit' mount option forces any data dirtied by a write in a |
| 116 | 123 | prior transaction to commit as part of the current commit. This makes |
| @@ -134,26 +141,32 @@ Unless otherwise specified, all options default to off. · 17 unmodified lines | ||
| 134 | 141 | Specify that 1 metadata chunk should be allocated after every <value> |
| 135 | 142 | data chunks. Off by default. |
| 136 | 143 | |
| 144 | + acl(*) | |
| 137 | 145 | noacl |
| 138 | − Disable support for Posix Access Control Lists (ACLs). See the | |
| 146 | + Enable/disable support for Posix Access Control Lists (ACLs). See the | |
| 139 | 147 | acl(5) manual page for more information about ACLs. |
| 140 | 148 | |
| 149 | + barrier(*) | |
| 141 | 150 | nobarrier |
| 142 | − Disables the use of block layer write barriers. Write barriers ensure | |
| 143 | − that certain IOs make it through the device cache and are on persistent | |
| 144 | − storage. If used on a device with a volatile (non-battery-backed) | |
| 145 | − write-back cache, this option will lead to filesystem corruption on a | |
| 146 | − system crash or power loss. | |
| 151 | + Enable/disable the use of block layer write barriers. Write barriers | |
| 152 | + ensure that certain IOs make it through the device cache and are on | |
| 153 | + persistent storage. If disabled on a device with a volatile | |
| 154 | + (non-battery-backed) write-back cache, nobarrier option will lead to | |
| 155 | + filesystem corruption on a system crash or power loss. | |
| 147 | 156 | |
| 157 | + datacow(*) | |
| 148 | 158 | nodatacow |
| 149 | − Disable data copy-on-write for newly created files. Implies nodatasum, | |
| 150 | − and disables all compression. | |
| 159 | + Enable/disable data copy-on-write for newly created files. | |
| 160 | + Nodatacow implies nodatasum, and disables all compression. | |
| 151 | 161 | |
| 162 | + datasum(*) | |
| 152 | 163 | nodatasum |
| 153 | − Disable data checksumming for newly created files. | |
| 164 | + Enable/disable data checksumming for newly created files. | |
| 165 | + Datasum implies datacow. | |
| 154 | 166 | |
| 167 | + treelog(*) | |
| 155 | 168 | notreelog |
| 156 | − Disable the tree logging used for fsync and O_SYNC writes. | |
| 169 | + Enable/disable the tree logging used for fsync and O_SYNC writes. | |
| 157 | 170 | |
| 158 | 171 | recovery |
| 159 | 172 | Enable autorecovery attempts if a bad tree root is found at mount time. |
| @@ -120,6 +120,8 @@ active_logs=%u Support configuring the number of active logs. In the · 119 unmodified lines | ||
| 120 | 120 | disable_ext_identify Disable the extension list configured by mkfs, so f2fs |
| 121 | 121 | does not aware of cold files such as media files. |
| 122 | 122 | inline_xattr Enable the inline xattrs feature. |
| 123 | +inline_data Enable the inline data feature: New created small(<~3.4k) | |
| 124 | + files can be written into inode block. | |
| 123 | 125 | |
| 124 | 126 | ================================================================================ |
| 125 | 127 | DEBUGFS ENTRIES |
| @@ -171,6 +173,28 @@ Files in /sys/fs/f2fs/<devname> · 45 unmodified lines | ||
| 171 | 173 | conduct checkpoint to reclaim the prefree segments |
| 172 | 174 | to free segments. By default, 100 segments, 200MB. |
| 173 | 175 | |
| 176 | + max_small_discards This parameter controls the number of discard | |
| 177 | + commands that consist small blocks less than 2MB. | |
| 178 | + The candidates to be discarded are cached until | |
| 179 | + checkpoint is triggered, and issued during the | |
| 180 | + checkpoint. By default, it is disabled with 0. | |
| 181 | + | |
| 182 | + ipu_policy This parameter controls the policy of in-place | |
| 183 | + updates in f2fs. There are five policies: | |
| 184 | + 0: F2FS_IPU_FORCE, 1: F2FS_IPU_SSR, | |
| 185 | + 2: F2FS_IPU_UTIL, 3: F2FS_IPU_SSR_UTIL, | |
| 186 | + 4: F2FS_IPU_DISABLE. | |
| 187 | + | |
| 188 | + min_ipu_util This parameter controls the threshold to trigger | |
| 189 | + in-place-updates. The number indicates percentage | |
| 190 | + of the filesystem utilization, and used by | |
| 191 | + F2FS_IPU_UTIL and F2FS_IPU_SSR_UTIL policies. | |
| 192 | + | |
| 193 | + max_victim_search This parameter controls the number of trials to | |
| 194 | + find a victim segment when conducting SSR and | |
| 195 | + cleaning operations. The default value is 4096 | |
| 196 | + which covers 8GB block address range. | |
| 197 | + | |
| 174 | 198 | ================================================================================ |
| 175 | 199 | USAGE |
| 176 | 200 | ================================================================================ |
| @@ -5,11 +5,11 @@ Server support for minorversion 1 can be controlled using the · 4 unmodified lines | ||
| 5 | 5 | by reading this file will contain either "+4.1" or "-4.1" |
| 6 | 6 | correspondingly. |
| 7 | 7 | |
| 8 | −Currently, server support for minorversion 1 is disabled by default. | |
| 9 | −It can be enabled at run time by writing the string "+4.1" to | |
| 8 | +Currently, server support for minorversion 1 is enabled by default. | |
| 9 | +It can be disabled at run time by writing the string "-4.1" to | |
| 10 | 10 | the /proc/fs/nfsd/versions control file. Note that to write this |
| 11 | −control file, the nfsd service must be taken down. Use your user-mode | |
| 12 | −nfs-utils to set this up; see rpc.nfsd(8) | |
| 11 | +control file, the nfsd service must be taken down. You can use rpc.nfsd | |
| 12 | +for this; see rpc.nfsd(8). | |
| 13 | 13 | |
| 14 | 14 | (Warning: older servers will interpret "+4.1" and "-4.1" as "+4" and |
| 15 | 15 | "-4", respectively. Therefore, code meant to work on both new and old |
| @@ -29,29 +29,6 @@ are still under development out of tree. · 13 unmodified lines | ||
| 29 | 29 | See http://wiki.linux-nfs.org/wiki/index.php/PNFS_prototype_design |
| 30 | 30 | for more information. |
| 31 | 31 | |
| 32 | −The current implementation is intended for developers only: while it | |
| 33 | −does support ordinary file operations on clients we have tested against | |
| 34 | −(including the linux client), it is incomplete in ways which may limit | |
| 35 | −features unexpectedly, cause known bugs in rare cases, or cause | |
| 36 | −interoperability problems with future clients. Known issues: | |
| 37 | − | |
| 38 | − - gss support is questionable: currently mounts with kerberos | |
| 39 | − from a linux client are possible, but we aren't really | |
| 40 | − conformant with the spec (for example, we don't use kerberos | |
| 41 | − on the backchannel correctly). | |
| 42 | − - We do not support SSV, which provides security for shared | |
| 43 | − client-server state (thus preventing unauthorized tampering | |
| 44 | − with locks and opens, for example). It is mandatory for | |
| 45 | − servers to support this, though no clients use it yet. | |
| 46 | − | |
| 47 | −In addition, some limitations are inherited from the current NFSv4 | |
| 48 | −implementation: | |
| 49 | − | |
| 50 | − - Incomplete delegation enforcement: if a file is renamed or | |
| 51 | − unlinked by a local process, a client holding a delegation may | |
| 52 | − continue to indefinitely allow opens of the file under the old | |
| 53 | − name. | |
| 54 | − | |
| 55 | 32 | The table below, taken from the NFSv4.1 document, lists |
| 56 | 33 | the operations that are mandatory to implement (REQ), optional |
| 57 | 34 | (OPT), and NFSv4.0 operations that are required not to implement (MNI) |
| @@ -169,6 +146,16 @@ NS*| CB_WANTS_CANCELLED | OPT | FDELG, | Section 20.10 | · 111 unmodified lines | ||
| 169 | 146 | |
| 170 | 147 | Implementation notes: |
| 171 | 148 | |
| 149 | +SSV: | |
| 150 | +* The spec claims this is mandatory, but we don't actually know of any | |
| 151 | + implementations, so we're ignoring it for now. The server returns | |
| 152 | + NFS4ERR_ENCR_ALG_UNSUPP on EXCHANGE_ID, which should be future-proof. | |
| 153 | + | |
| 154 | +GSS on the backchannel: | |
| 155 | +* Again, theoretically required but not widely implemented (in | |
| 156 | + particular, the current Linux client doesn't request it). We return | |
| 157 | + NFS4ERR_ENCR_ALG_UNSUPP on CREATE_SESSION. | |
| 158 | + | |
| 172 | 159 | DELEGPURGE: |
| 173 | 160 | * mandatory only for servers that support CLAIM_DELEGATE_PREV and/or |
| 174 | 161 | CLAIM_DELEG_PREV_FH (which allows clients to keep delegations that |
| @@ -176,7 +163,6 @@ DELEGPURGE: · 1 unmodified line | ||
| 176 | 163 | now. |
| 177 | 164 | |
| 178 | 165 | EXCHANGE_ID: |
| 179 | −* only SP4_NONE state protection supported | |
| 180 | 166 | * implementation ids are ignored |
| 181 | 167 | |
| 182 | 168 | CREATE_SESSION: |
| @@ -81,6 +81,62 @@ nodiscard(*) The discard/TRIM commands are sent to the underlying · 80 unmodified lines | ||
| 81 | 81 | block device when blocks are freed. This is useful |
| 82 | 82 | for SSD devices and sparse/thinly-provisioned LUNs. |
| 83 | 83 | |
| 84 | +Ioctls | |
| 85 | +====== | |
| 86 | + | |
| 87 | +There is some NILFS2 specific functionality which can be accessed by applications | |
| 88 | +through the system call interfaces. The list of all NILFS2 specific ioctls are | |
| 89 | +shown in the table below. | |
| 90 | + | |
| 91 | +Table of NILFS2 specific ioctls | |
| 92 | +.............................................................................. | |
| 93 | + Ioctl Description | |
| 94 | + NILFS_IOCTL_CHANGE_CPMODE Change mode of given checkpoint between | |
| 95 | + checkpoint and snapshot state. This ioctl is | |
| 96 | + used in chcp and mkcp utilities. | |
| 97 | + | |
| 98 | + NILFS_IOCTL_DELETE_CHECKPOINT Remove checkpoint from NILFS2 file system. | |
| 99 | + This ioctl is used in rmcp utility. | |
| 100 | + | |
| 101 | + NILFS_IOCTL_GET_CPINFO Return info about requested checkpoints. This | |
| 102 | + ioctl is used in lscp utility and by | |
| 103 | + nilfs_cleanerd daemon. | |
| 104 | + | |
| 105 | + NILFS_IOCTL_GET_CPSTAT Return checkpoints statistics. This ioctl is | |
| 106 | + used by lscp, rmcp utilities and by | |
| 107 | + nilfs_cleanerd daemon. | |
| 108 | + | |
| 109 | + NILFS_IOCTL_GET_SUINFO Return segment usage info about requested | |
| 110 | + segments. This ioctl is used in lssu, | |
| 111 | + nilfs_resize utilities and by nilfs_cleanerd | |
| 112 | + daemon. | |
| 113 | + | |
| 114 | + NILFS_IOCTL_GET_SUSTAT Return segment usage statistics. This ioctl | |
| 115 | + is used in lssu, nilfs_resize utilities and | |
| 116 | + by nilfs_cleanerd daemon. | |
| 117 | + | |
| 118 | + NILFS_IOCTL_GET_VINFO Return information on virtual block addresses. | |
| 119 | + This ioctl is used by nilfs_cleanerd daemon. | |
| 120 | + | |
| 121 | + NILFS_IOCTL_GET_BDESCS Return information about descriptors of disk | |
| 122 | + block numbers. This ioctl is used by | |
| 123 | + nilfs_cleanerd daemon. | |
| 124 | + | |
| 125 | + NILFS_IOCTL_CLEAN_SEGMENTS Do garbage collection operation in the | |
| 126 | + environment of requested parameters from | |
| 127 | + userspace. This ioctl is used by | |
| 128 | + nilfs_cleanerd daemon. | |
| 129 | + | |
| 130 | + NILFS_IOCTL_SYNC Make a checkpoint. This ioctl is used in | |
| 131 | + mkcp utility. | |
| 132 | + | |
| 133 | + NILFS_IOCTL_RESIZE Resize NILFS2 volume. This ioctl is used | |
| 134 | + by nilfs_resize utility. | |
| 135 | + | |
| 136 | + NILFS_IOCTL_SET_ALLOC_RANGE Define lower limit of segments in bytes and | |
| 137 | + upper limit of segments in bytes. This ioctl | |
| 138 | + is used by nilfs_resize utility. | |
| 139 | + | |
| 84 | 140 | NILFS2 usage |
| 85 | 141 | ============ |
| 86 | 142 | |
| @@ -547,7 +547,7 @@ Table 1-5: Kernel info in /proc · 546 unmodified lines | ||
| 547 | 547 | sys See chapter 2 |
| 548 | 548 | sysvipc Info of SysVIPC Resources (msg, sem, shm) (2.4) |
| 549 | 549 | tty Info of tty drivers |
| 550 | − uptime System uptime | |
| 550 | + uptime Wall clock since boot, combined idle time of all cpus | |
| 551 | 551 | version Kernel version |
| 552 | 552 | video bttv info of video resources (2.4) |
| 553 | 553 | vmallocinfo Show vmalloced areas |
| @@ -767,6 +767,7 @@ The "Locked" indicates whether the mapping is locked in memory or not. · 213 unmodified lines | ||
| 767 | 767 | |
| 768 | 768 | MemTotal: 16344972 kB |
| 769 | 769 | MemFree: 13634064 kB |
| 770 | +MemAvailable: 14836172 kB | |
| 770 | 771 | Buffers: 3656 kB |
| 771 | 772 | Cached: 1195708 kB |
| 772 | 773 | SwapCached: 0 kB |
| @@ -799,6 +800,14 @@ AnonHugePages: 49152 kB · 26 unmodified lines | ||
| 799 | 800 | MemTotal: Total usable ram (i.e. physical ram minus a few reserved |
| 800 | 801 | bits and the kernel binary code) |
| 801 | 802 | MemFree: The sum of LowFree+HighFree |
| 803 | +MemAvailable: An estimate of how much memory is available for starting new | |
| 804 | + applications, without swapping. Calculated from MemFree, | |
| 805 | + SReclaimable, the size of the file LRU lists, and the low | |
| 806 | + watermarks in each zone. | |
| 807 | + The estimate takes into account that the system needs some | |
| 808 | + page cache to function well, and that not all reclaimable | |
| 809 | + slab will be reclaimable, due to items being in use. The | |
| 810 | + impact of those factors will vary from system to system. | |
| 802 | 811 | Buffers: Relatively temporary storage for raw disk blocks |
| 803 | 812 | shouldn't get tremendously large (20MB or so) |
| 804 | 813 | Cached: in-memory cache for files read from the disk (the |
| @@ -1377,8 +1386,8 @@ may allocate from based on an estimation of its current memory and swap use. · 572 unmodified lines | ||
| 1377 | 1386 | For example, if a task is using all allowed memory, its badness score will be |
| 1378 | 1387 | 1000. If it is using half of its allowed memory, its score will be 500. |
| 1379 | 1388 | |
| 1380 | −There is an additional factor included in the badness score: root | |
| 1381 | −processes are given 3% extra memory over other tasks. | |
| 1389 | +There is an additional factor included in the badness score: the current memory | |
| 1390 | +and swap usage is discounted by 3% for root processes. | |
| 1382 | 1391 | |
| 1383 | 1392 | The amount of "allowed" memory depends on the context in which the oom killer |
| 1384 | 1393 | was called. If it is due to the memory assigned to the allocating task's cpuset |
| @@ -108,12 +108,12 @@ static DEVICE_ATTR(foo, S_IWUSR | S_IRUGO, show_foo, store_foo); · 107 unmodified lines | ||
| 108 | 108 | is equivalent to doing: |
| 109 | 109 | |
| 110 | 110 | static struct device_attribute dev_attr_foo = { |
| 111 | − .attr = { | |
| 111 | + .attr = { | |
| 112 | 112 | .name = "foo", |
| 113 | 113 | .mode = S_IWUSR | S_IRUGO, |
| 114 | − .show = show_foo, | |
| 115 | − .store = store_foo, | |
| 116 | 114 | }, |
| 115 | + .show = show_foo, | |
| 116 | + .store = store_foo, | |
| 117 | 117 | }; |
| 118 | 118 | |
| 119 | 119 | |
| @@ -782,7 +782,7 @@ struct file_operations · 781 unmodified lines | ||
| 782 | 782 | ---------------------- |
| 783 | 783 | |
| 784 | 784 | This describes how the VFS can manipulate an open file. As of kernel |
| 785 | −3.5, the following members are defined: | |
| 785 | +3.12, the following members are defined: | |
| 786 | 786 | |
| 787 | 787 | struct file_operations { |
| 788 | 788 | struct module *owner; |
| @@ -803,9 +803,6 @@ struct file_operations { · 14 unmodified lines | ||
| 803 | 803 | int (*aio_fsync) (struct kiocb *, int datasync); |
| 804 | 804 | int (*fasync) (int, struct file *, int); |
| 805 | 805 | int (*lock) (struct file *, int, struct file_lock *); |
| 806 | − ssize_t (*readv) (struct file *, const struct iovec *, unsigned long, loff_t *); | |
| 807 | − ssize_t (*writev) (struct file *, const struct iovec *, unsigned long, loff_t *); | |
| 808 | − ssize_t (*sendfile) (struct file *, loff_t *, size_t, read_actor_t, void *); | |
| 809 | 806 | ssize_t (*sendpage) (struct file *, struct page *, int, size_t, loff_t *, int); |
| 810 | 807 | unsigned long (*get_unmapped_area)(struct file *, unsigned long, unsigned long, unsigned long, unsigned long); |
| 811 | 808 | int (*check_flags)(int); |
| @@ -814,6 +811,7 @@ struct file_operations { · 2 unmodified lines | ||
| 814 | 811 | ssize_t (*splice_read)(struct file *, struct pipe_inode_info *, size_t, unsigned int); |
| 815 | 812 | int (*setlease)(struct file *, long arg, struct file_lock **); |
| 816 | 813 | long (*fallocate)(struct file *, int mode, loff_t offset, loff_t len); |
| 814 | + int (*show_fdinfo)(struct seq_file *m, struct file *f); | |
| 817 | 815 | }; |
| 818 | 816 | |
| 819 | 817 | Again, all methods are called without any locks being held, unless |
| @@ -864,12 +862,6 @@ otherwise noted. · 44 unmodified lines | ||
| 864 | 862 | lock: called by the fcntl(2) system call for F_GETLK, F_SETLK, and F_SETLKW |
| 865 | 863 | commands |
| 866 | 864 | |
| 867 | − readv: called by the readv(2) system call | |
| 868 | − | |
| 869 | − writev: called by the writev(2) system call | |
| 870 | − | |
| 871 | − sendfile: called by the sendfile(2) system call | |
| 872 | − | |
| 873 | 865 | get_unmapped_area: called by the mmap(2) system call |
| 874 | 866 | |
| 875 | 867 | check_flags: called by the fcntl(2) system call for F_SETFL command |
| @@ -72,10 +72,11 @@ where · 71 unmodified lines | ||
| 72 | 72 | |
| 73 | 73 | - chip_label is the label of the gpiod_chip instance providing the GPIO |
| 74 | 74 | - chip_hwnum is the hardware number of the GPIO within the chip |
| 75 | − - dev_id is the identifier of the device that will make use of this GPIO. If | |
| 76 | − NULL, the GPIO will be available to all devices. | |
| 75 | + - dev_id is the identifier of the device that will make use of this GPIO. It | |
| 76 | + can be NULL, in which case it will be matched for calls to gpiod_get() | |
| 77 | + with a NULL device. | |
| 77 | 78 | - con_id is the name of the GPIO function from the device point of view. It |
| 78 | − can be NULL. | |
| 79 | + can be NULL, in which case it will match any function. | |
| 79 | 80 | - idx is the index of the GPIO within the function. |
| 80 | 81 | - flags is defined to specify the following properties: |
| 81 | 82 | * GPIOF_ACTIVE_LOW - to configure the GPIO as active-low |
| @@ -86,18 +87,23 @@ In the future, these flags might be extended to support more properties. · 4 unmodified lines | ||
| 86 | 87 | |
| 87 | 88 | Note that GPIO_LOOKUP() is just a shortcut to GPIO_LOOKUP_IDX() where idx = 0. |
| 88 | 89 | |
| 89 | −A lookup table can then be defined as follows: | |
| 90 | +A lookup table can then be defined as follows, with an empty entry defining its | |
| 91 | +end: | |
| 90 | 92 | |
| 91 | − struct gpiod_lookup gpios_table[] = { | |
| 92 | − GPIO_LOOKUP_IDX("gpio.0", 15, "foo.0", "led", 0, GPIO_ACTIVE_HIGH), | |
| 93 | − GPIO_LOOKUP_IDX("gpio.0", 16, "foo.0", "led", 1, GPIO_ACTIVE_HIGH), | |
| 94 | − GPIO_LOOKUP_IDX("gpio.0", 17, "foo.0", "led", 2, GPIO_ACTIVE_HIGH), | |
| 95 | − GPIO_LOOKUP("gpio.0", 1, "foo.0", "power", GPIO_ACTIVE_LOW), | |
| 96 | − }; | |
| 93 | +struct gpiod_lookup_table gpios_table = { | |
| 94 | + .dev_id = "foo.0", | |
| 95 | + .table = { | |
| 96 | + GPIO_LOOKUP_IDX("gpio.0", 15, "led", 0, GPIO_ACTIVE_HIGH), | |
| 97 | + GPIO_LOOKUP_IDX("gpio.0", 16, "led", 1, GPIO_ACTIVE_HIGH), | |
| 98 | + GPIO_LOOKUP_IDX("gpio.0", 17, "led", 2, GPIO_ACTIVE_HIGH), | |
| 99 | + GPIO_LOOKUP("gpio.0", 1, "power", GPIO_ACTIVE_LOW), | |
| 100 | + { }, | |
| 101 | + }, | |
| 102 | +}; | |
| 97 | 103 | |
| 98 | 104 | And the table can be added by the board code as follows: |
| 99 | 105 | |
| 100 | − gpiod_add_table(gpios_table, ARRAY_SIZE(gpios_table)); | |
| 106 | + gpiod_add_lookup_table(&gpios_table); | |
| 101 | 107 | |
| 102 | 108 | The driver controlling "foo.0" will then be able to obtain its GPIOs as follows: |
| 103 | 109 | |
| @@ -38,7 +38,11 @@ device that displays digits), an additional index argument can be specified: · 37 unmodified lines | ||
| 38 | 38 | const char *con_id, unsigned int idx) |
| 39 | 39 | |
| 40 | 40 | Both functions return either a valid GPIO descriptor, or an error code checkable |
| 41 | −with IS_ERR(). They will never return a NULL pointer. | |
| 41 | +with IS_ERR() (they will never return a NULL pointer). -ENOENT will be returned | |
| 42 | +if and only if no GPIO has been assigned to the device/function/index triplet, | |
| 43 | +other error codes are used for cases where a GPIO has been assigned but an error | |
| 44 | +occured while trying to acquire it. This is useful to discriminate between mere | |
| 45 | +errors and an absence of GPIO for optional GPIO parameters. | |
| 42 | 46 | |
| 43 | 47 | Device-managed variants of these functions are also defined: |
| 44 | 48 | |
| @@ -18,7 +18,7 @@ The NE1619 presents some differences with the original ADM1025: · 17 unmodified lines | ||
| 18 | 18 | |
| 19 | 19 | Authors: |
| 20 | 20 | Chen-Yuan Wu <gwu@esoft.com>, |
| 21 | − Jean Delvare <khali@linux-fr.org> | |
| 21 | + Jean Delvare <jdelvare@suse.de> | |
| 22 | 22 | |
| 23 | 23 | Description |
| 24 | 24 | ----------- |
| @@ -16,7 +16,7 @@ Supported chips: · 15 unmodified lines | ||
| 16 | 16 | |
| 17 | 17 | Authors: |
| 18 | 18 | Alexandre d'Alton <alex@alexdalton.org> |
| 19 | − Jean Delvare <khali@linux-fr.org> | |
| 19 | + Jean Delvare <jdelvare@suse.de> | |
| 20 | 20 | |
| 21 | 21 | Description |
| 22 | 22 | ----------- |
| @@ -25,7 +25,7 @@ Authors: · 24 unmodified lines | ||
| 25 | 25 | Philip Edelbrock <phil@netroedge.com>, |
| 26 | 26 | Michiel Rook <michiel@grendelproject.nl>, |
| 27 | 27 | Grant Coady <gcoady.lk@gmail.com> with guidance |
| 28 | − from Jean Delvare <khali@linux-fr.org> | |
| 28 | + from Jean Delvare <jdelvare@suse.de> | |
| 29 | 29 | |
| 30 | 30 | Interface |
| 31 | 31 | --------- |
| @@ -31,7 +31,7 @@ Authors: · 30 unmodified lines | ||
| 31 | 31 | Christian W. Zuckschwerdt <zany@triq.net> |
| 32 | 32 | valuable contributions by Jan M. Sendler <sendler@sendler.de> |
| 33 | 33 | ported to 2.6 by Aurelien Jarno <aurelien@aurel32.net> |
| 34 | − with the help of Jean Delvare <khali@linux-fr.org> | |
| 34 | + with the help of Jean Delvare <jdelvare@suse.de> | |
| 35 | 35 | |
| 36 | 36 | Module Parameters |
| 37 | 37 | ------------------ |
| @@ -7,7 +7,7 @@ Supported chips: · 6 unmodified lines | ||
| 7 | 7 | Addresses scanned: I2C 0x2c, 0x2d, 0x2e |
| 8 | 8 | Datasheet: Not public |
| 9 | 9 | |
| 10 | −Author: Jean Delvare <khali@linux-fr.org> | |
| 10 | +Author: Jean Delvare <jdelvare@suse.de> | |
| 11 | 11 | |
| 12 | 12 | |
| 13 | 13 | Description |
| @@ -15,7 +15,7 @@ Supported chips: · 14 unmodified lines | ||
| 15 | 15 | Addresses scanned: none, address read from Super I/O config space |
| 16 | 16 | Datasheet: Available from the Fintek website |
| 17 | 17 | |
| 18 | −Author: Jean Delvare <khali@linux-fr.org> | |
| 18 | +Author: Jean Delvare <jdelvare@suse.de> | |
| 19 | 19 | |
| 20 | 20 | Thanks to Denis Kieft from Barracuda Networks for the donation of a |
| 21 | 21 | test system (custom Jetway K8M8MS motherboard, with CPU and RAM) and |
| @@ -14,7 +14,7 @@ Authors: · 13 unmodified lines | ||
| 14 | 14 | Frodo Looijaard <frodol@dds.nl>, |
| 15 | 15 | Kyösti Mälkki <kmalkki@cc.hut.fi> |
| 16 | 16 | Hong-Gunn Chew <hglinux@gunnet.org> |
| 17 | − Jean Delvare <khali@linux-fr.org> | |
| 17 | + Jean Delvare <jdelvare@suse.de> | |
| 18 | 18 | |
| 19 | 19 | Description |
| 20 | 20 | ----------- |
| @@ -2,6 +2,10 @@ Kernel driver it87 · 1 unmodified line | ||
| 2 | 2 | ================== |
| 3 | 3 | |
| 4 | 4 | Supported chips: |
| 5 | + * IT8603E | |
| 6 | + Prefix: 'it8603' | |
| 7 | + Addresses scanned: from Super I/O config space (8 I/O ports) | |
| 8 | + Datasheet: Not publicly available | |
| 5 | 9 | * IT8705F |
| 6 | 10 | Prefix: 'it87' |
| 7 | 11 | Addresses scanned: from Super I/O config space (8 I/O ports) |
| @@ -53,7 +57,7 @@ Supported chips: · 45 unmodified lines | ||
| 53 | 57 | |
| 54 | 58 | Authors: |
| 55 | 59 | Christophe Gauthron |
| 56 | − Jean Delvare <khali@linux-fr.org> | |
| 60 | + Jean Delvare <jdelvare@suse.de> | |
| 57 | 61 | |
| 58 | 62 | |
| 59 | 63 | Module Parameters |
| @@ -90,7 +94,7 @@ motherboard models. · 30 unmodified lines | ||
| 90 | 94 | Description |
| 91 | 95 | ----------- |
| 92 | 96 | |
| 93 | −This driver implements support for the IT8705F, IT8712F, IT8716F, | |
| 97 | +This driver implements support for the IT8603E, IT8705F, IT8712F, IT8716F, | |
| 94 | 98 | IT8718F, IT8720F, IT8721F, IT8726F, IT8728F, IT8758E, IT8771E, IT8772E, |
| 95 | 99 | IT8782F, IT8783E/F, and SiS950 chips. |
| 96 | 100 | |
| @@ -129,6 +133,10 @@ to userspace applications. · 32 unmodified lines | ||
| 129 | 133 | The IT8728F, IT8771E, and IT8772E are considered compatible with the IT8721F, |
| 130 | 134 | until a datasheet becomes available (hopefully.) |
| 131 | 135 | |
| 136 | +The IT8603E is a custom design, hardware monitoring part is similar to | |
| 137 | +IT8728F. It only supports 16-bit fan mode, the full speed mode of the | |
| 138 | +fan is not supported (value 0 of pwmX_enable). | |
| 139 | + | |
| 132 | 140 | Temperatures are measured in degrees Celsius. An alarm is triggered once |
| 133 | 141 | when the Overtemperature Shutdown limit is crossed. |
| 134 | 142 | |
| @@ -145,13 +153,16 @@ alarm is triggered if the voltage has crossed a programmable minimum or · 10 unmodified lines | ||
| 145 | 153 | maximum limit. Note that minimum in this case always means 'closest to |
| 146 | 154 | zero'; this is important for negative voltage measurements. All voltage |
| 147 | 155 | inputs can measure voltages between 0 and 4.08 volts, with a resolution of |
| 148 | −0.016 volt (except IT8721F/IT8758E and IT8728F: 0.012 volt.) The battery | |
| 149 | −voltage in8 does not have limit registers. | |
| 150 | − | |
| 151 | −On the IT8721F/IT8758E, IT8782F, and IT8783E/F, some voltage inputs are | |
| 152 | −internal and scaled inside the chip (in7 (optional for IT8782F and IT8783E/F), | |
| 153 | −in8 and optionally in3). The driver handles this transparently so user-space | |
| 154 | −doesn't have to care. | |
| 156 | +0.016 volt (except IT8603E, IT8721F/IT8758E and IT8728F: 0.012 volt.) The | |
| 157 | +battery voltage in8 does not have limit registers. | |
| 158 | + | |
| 159 | +On the IT8603E, IT8721F/IT8758E, IT8782F, and IT8783E/F, some voltage inputs | |
| 160 | +are internal and scaled inside the chip: | |
| 161 | +* in3 (optional) | |
| 162 | +* in7 (optional for IT8782F and IT8783E/F) | |
| 163 | +* in8 (always) | |
| 164 | +* in9 (relevant for IT8603E only) | |
| 165 | +The driver handles this transparently so user-space doesn't have to care. | |
| 155 | 166 | |
| 156 | 167 | The VID lines (IT8712F/IT8716F/IT8718F/IT8720F) encode the core voltage value: |
| 157 | 168 | the voltage level your processor should work with. This is hardcoded by |
| @@ -18,7 +18,7 @@ Supported chips: · 17 unmodified lines | ||
| 18 | 18 | Datasheet: Publicly available at the National Semiconductor website |
| 19 | 19 | http://www.national.com/pf/LM/LM96163.html |
| 20 | 20 | |
| 21 | −Author: Jean Delvare <khali@linux-fr.org> | |
| 21 | +Author: Jean Delvare <jdelvare@suse.de> | |
| 22 | 22 | |
| 23 | 23 | Thanks go to Tyan and especially Alex Buckingham for setting up a remote |
| 24 | 24 | access to their S4882 test platform for this driver. |
| @@ -43,5 +43,5 @@ data (0.03125 degrees celsius resolution). · 42 unmodified lines | ||
| 43 | 43 | |
| 44 | 44 | Thanks to |
| 45 | 45 | --------- |
| 46 | −Jean Delvare <khali@linux-fr.org> for mentoring the hwmon-side driver | |
| 46 | +Jean Delvare <jdelvare@suse.de> for mentoring the hwmon-side driver | |
| 47 | 47 | development. |
| @@ -14,7 +14,7 @@ Supported chips: · 13 unmodified lines | ||
| 14 | 14 | http://www.national.com/ |
| 15 | 15 | |
| 16 | 16 | Authors: Frodo Looijaard <frodol@dds.nl> |
| 17 | − Jean Delvare <khali@linux-fr.org> | |
| 17 | + Jean Delvare <jdelvare@suse.de> | |
| 18 | 18 | |
| 19 | 19 | Description |
| 20 | 20 | ----------- |
| @@ -13,7 +13,7 @@ Supported chips: · 12 unmodified lines | ||
| 13 | 13 | http://www.national.com/pf/LM/LM82.html |
| 14 | 14 | |
| 15 | 15 | |
| 16 | −Author: Jean Delvare <khali@linux-fr.org> | |
| 16 | +Author: Jean Delvare <jdelvare@suse.de> | |
| 17 | 17 | |
| 18 | 18 | Description |
| 19 | 19 | ----------- |
| @@ -17,7 +17,7 @@ Authors: · 16 unmodified lines | ||
| 17 | 17 | Mark Studebaker <mdsxyz123@yahoo.com>, |
| 18 | 18 | Stephen Rousset <stephen.rousset@rocketlogix.com>, |
| 19 | 19 | Dan Eaton <dan.eaton@rocketlogix.com>, |
| 20 | − Jean Delvare <khali@linux-fr.org>, | |
| 20 | + Jean Delvare <jdelvare@suse.de>, | |
| 21 | 21 | Original 2.6 port Jeff Oliver |
| 22 | 22 | |
| 23 | 23 | Description |
| @@ -129,7 +129,7 @@ Supported chips: · 128 unmodified lines | ||
| 129 | 129 | http://www.ti.com/litv/pdf/sbos686 |
| 130 | 130 | |
| 131 | 131 | |
| 132 | −Author: Jean Delvare <khali@linux-fr.org> | |
| 132 | +Author: Jean Delvare <jdelvare@suse.de> | |
| 133 | 133 | |
| 134 | 134 | |
| 135 | 135 | Description |
| @@ -19,7 +19,7 @@ Supported chips: · 18 unmodified lines | ||
| 19 | 19 | |
| 20 | 20 | Authors: |
| 21 | 21 | Abraham van der Merwe <abraham@2d3d.co.za> |
| 22 | − Jean Delvare <khali@linux-fr.org> | |
| 22 | + Jean Delvare <jdelvare@suse.de> | |
| 23 | 23 | |
| 24 | 24 | |
| 25 | 25 | Description |
| @@ -10,7 +10,7 @@ Supported chips: · 9 unmodified lines | ||
| 10 | 10 | |
| 11 | 11 | Authors: |
| 12 | 12 | Oleksij Rempel <bug-track@fisher-privat.net>, |
| 13 | − Jean Delvare <khali@linux-fr.org> | |
| 13 | + Jean Delvare <jdelvare@suse.de> | |
| 14 | 14 | |
| 15 | 15 | Description |
| 16 | 16 | ----------- |
| @@ -7,7 +7,7 @@ Supported chips: · 6 unmodified lines | ||
| 7 | 7 | Addresses scanned: none, address read from Super I/O config space |
| 8 | 8 | Datasheets: No longer available |
| 9 | 9 | |
| 10 | −Authors: Jean Delvare <khali@linux-fr.org> | |
| 10 | +Authors: Jean Delvare <jdelvare@suse.de> | |
| 11 | 11 | |
| 12 | 12 | Thanks to Sandeep Mehta, Tonko de Rooy and Daniel Ceregatti for testing. |
| 13 | 13 | Thanks to Rudolf Marek for helping me investigate conversion issues. |
| @@ -7,7 +7,7 @@ Supported chips: · 6 unmodified lines | ||
| 7 | 7 | Addresses scanned: none, address read from Super I/O config space |
| 8 | 8 | Datasheet: No longer available |
| 9 | 9 | |
| 10 | −Author: Jean Delvare <khali@linux-fr.org> | |
| 10 | +Author: Jean Delvare <jdelvare@suse.de> | |
| 11 | 11 | |
| 12 | 12 | Thanks to Amir Habibi at Candelis for setting up a test system, and to |
| 13 | 13 | Michael Kress for testing several iterations of this driver. |
| @@ -11,7 +11,7 @@ Supported chips: · 10 unmodified lines | ||
| 11 | 11 | Authors: |
| 12 | 12 | Aurelien Jarno <aurelien@aurel32.net> |
| 13 | 13 | valuable contributions by Jan M. Sendler <sendler@sendler.de>, |
| 14 | − Jean Delvare <khali@linux-fr.org> | |
| 14 | + Jean Delvare <jdelvare@suse.de> | |
| 15 | 15 | |
| 16 | 16 | |
| 17 | 17 | Description |
| @@ -25,7 +25,7 @@ Authors: · 24 unmodified lines | ||
| 25 | 25 | With assistance from Bruce Allen <ballen@uwm.edu>, and his |
| 26 | 26 | fan.c program: http://www.lsc-group.phys.uwm.edu/%7Eballen/driver/ |
| 27 | 27 | Gabriele Gorla <gorlik@yahoo.com>, |
| 28 | − Jean Delvare <khali@linux-fr.org> | |
| 28 | + Jean Delvare <jdelvare@suse.de> | |
| 29 | 29 | |
| 30 | 30 | Description |
| 31 | 31 | ----------- |
| @@ -36,7 +36,7 @@ Supported chips: · 35 unmodified lines | ||
| 36 | 36 | Datasheet: Available from Nuvoton upon request |
| 37 | 37 | |
| 38 | 38 | Authors: |
| 39 | − Jean Delvare <khali@linux-fr.org> | |
| 39 | + Jean Delvare <jdelvare@suse.de> | |
| 40 | 40 | Yuan Mu (Winbond) |
| 41 | 41 | Rudolf Marek <r.marek@assembler.cz> |
| 42 | 42 | David Hubbard <david.c.hubbard@gmail.com> |
| @@ -13,7 +13,7 @@ Supported chips: · 12 unmodified lines | ||
| 13 | 13 | |
| 14 | 14 | Authors: |
| 15 | 15 | Wei Song (Nuvoton) |
| 16 | − Jean Delvare <khali@linux-fr.org> | |
| 16 | + Jean Delvare <jdelvare@suse.de> | |
| 17 | 17 | |
| 18 | 18 | |
| 19 | 19 | Pin mapping |
| @@ -9,7 +9,7 @@ Supported chips: · 8 unmodified lines | ||
| 9 | 9 | http://www.winbond-usa.com/products/winbond_products/pdfs/PCIC/W83L785TS-S.pdf |
| 10 | 10 | |
| 11 | 11 | Authors: |
| 12 | − Jean Delvare <khali@linux-fr.org> | |
| 12 | + Jean Delvare <jdelvare@suse.de> | |
| 13 | 13 | |
| 14 | 14 | Description |
| 15 | 15 | ----------- |
| @@ -33,7 +33,7 @@ and the additional 'Integrated Device Function' controllers are supported. · 32 unmodified lines | ||
| 33 | 33 | |
| 34 | 34 | Authors: |
| 35 | 35 | Mark Studebaker <mdsxyz123@yahoo.com> |
| 36 | − Jean Delvare <khali@linux-fr.org> | |
| 36 | + Jean Delvare <jdelvare@suse.de> | |
| 37 | 37 | |
| 38 | 38 | |
| 39 | 39 | Module Parameters |
| @@ -1,6 +1,6 @@ | ||
| 1 | 1 | Kernel driver i2c-parport |
| 2 | 2 | |
| 3 | −Author: Jean Delvare <khali@linux-fr.org> | |
| 3 | +Author: Jean Delvare <jdelvare@suse.de> | |
| 4 | 4 | |
| 5 | 5 | This is a unified driver for several i2c-over-parallel-port adapters, |
| 6 | 6 | such as the ones made by Philips, Velleman or ELV. This driver is |
| @@ -1,6 +1,6 @@ | ||
| 1 | 1 | Kernel driver i2c-parport-light |
| 2 | 2 | |
| 3 | −Author: Jean Delvare <khali@linux-fr.org> | |
| 3 | +Author: Jean Delvare <jdelvare@suse.de> | |
| 4 | 4 | |
| 5 | 5 | This driver is a light version of i2c-parport. It doesn't depend |
| 6 | 6 | on the parport driver, and uses direct I/O access instead. This might be |
| @@ -13,7 +13,7 @@ Supported adapters: · 12 unmodified lines | ||
| 13 | 13 | * AMD SP5100 (SB700 derivative found on some server mainboards) |
| 14 | 14 | Datasheet: Publicly available at the AMD website |
| 15 | 15 | http://support.amd.com/us/Embedded_TechDocs/44413.pdf |
| 16 | − * AMD Hudson-2, CZ | |
| 16 | + * AMD Hudson-2, ML, CZ | |
| 17 | 17 | Datasheet: Not publicly available |
| 18 | 18 | * Standard Microsystems (SMSC) SLC90E66 (Victory66) southbridge |
| 19 | 19 | Datasheet: Publicly available at the SMSC website http://www.smsc.com |
| @@ -1,6 +1,6 @@ | ||
| 1 | 1 | Kernel driver i2c-taos-evm |
| 2 | 2 | |
| 3 | −Author: Jean Delvare <khali@linux-fr.org> | |
| 3 | +Author: Jean Delvare <jdelvare@suse.de> | |
| 4 | 4 | |
| 5 | 5 | This is a driver for the evaluation modules for TAOS I2C/SMBus chips. |
| 6 | 6 | The modules include an SMBus master with limited capabilities, which can |
| @@ -28,7 +28,7 @@ Supported adapters: · 27 unmodified lines | ||
| 28 | 28 | Authors: |
| 29 | 29 | Kyösti Mälkki <kmalkki@cc.hut.fi>, |
| 30 | 30 | Mark D. Studebaker <mdsxyz123@yahoo.com>, |
| 31 | − Jean Delvare <khali@linux-fr.org> | |
| 31 | + Jean Delvare <jdelvare@suse.de> | |
| 32 | 32 | |
| 33 | 33 | Module Parameters |
| 34 | 34 | ----------------- |
| @@ -64,9 +64,6 @@ EINVAL · 63 unmodified lines | ||
| 64 | 64 | detected before any I/O operation was started. Use a more |
| 65 | 65 | specific fault code when you can. |
| 66 | 66 | |
| 67 | − One example would be a driver trying an SMBus Block Write | |
| 68 | − with block size outside the range of 1-32 bytes. | |
| 69 | − | |
| 70 | 67 | EIO |
| 71 | 68 | This rather vague error means something went wrong when |
| 72 | 69 | performing an I/O operation. Use a more specific fault |
| @@ -68,7 +68,7 @@ features that you need, first. How each feature is mapped is described below. · 67 unmodified lines | ||
| 68 | 68 | Legacy drivers often don't comply to these rules. As we cannot change them |
| 69 | 69 | for backwards-compatibility reasons, you need to provide fixup mappings in |
| 70 | 70 | user-space yourself. Some of them might also provide module-options that |
| 71 | −change the mappings so you can adivce users to set these. | |
| 71 | +change the mappings so you can advise users to set these. | |
| 72 | 72 | |
| 73 | 73 | All new gamepads are supposed to comply with this mapping. Please report any |
| 74 | 74 | bugs, if they don't. |
| @@ -150,10 +150,10 @@ Menu-Pad: · 75 unmodified lines | ||
| 150 | 150 | BTN_START |
| 151 | 151 | Many pads also have a third button which is branded or has a special symbol |
| 152 | 152 | and meaning. Such buttons are mapped as BTN_MODE. Examples are the Nintendo |
| 153 | − "HOME" button, the XBox "X"-button or Sony "P" button. | |
| 153 | + "HOME" button, the XBox "X"-button or Sony "PS" button. | |
| 154 | 154 | |
| 155 | 155 | Rumble: |
| 156 | − Rumble is adverticed as FF_RUMBLE. | |
| 156 | + Rumble is advertised as FF_RUMBLE. | |
| 157 | 157 | |
| 158 | 158 | ---------------------------------------------------------------------------- |
| 159 | 159 | Written 2013 by David Herrmann <dh.herrmann@gmail.com> |
| @@ -16,14 +16,14 @@ joystick. · 15 unmodified lines | ||
| 16 | 16 | |
| 17 | 17 | By default, the device is opened in blocking mode. |
| 18 | 18 | |
| 19 | − int fd = open ("/dev/js0", O_RDONLY); | |
| 19 | + int fd = open ("/dev/input/js0", O_RDONLY); | |
| 20 | 20 | |
| 21 | 21 | |
| 22 | 22 | 2. Event Reading |
| 23 | 23 | ~~~~~~~~~~~~~~~~ |
| 24 | 24 | |
| 25 | 25 | struct js_event e; |
| 26 | − read (fd, &e, sizeof(struct js_event)); | |
| 26 | + read (fd, &e, sizeof(e)); | |
| 27 | 27 | |
| 28 | 28 | where js_event is defined as |
| 29 | 29 | |
| @@ -34,8 +34,8 @@ where js_event is defined as · 4 unmodified lines | ||
| 34 | 34 | __u8 number; /* axis/button number */ |
| 35 | 35 | }; |
| 36 | 36 | |
| 37 | −If the read is successful, it will return sizeof(struct js_event), unless | |
| 38 | −you wanted to read more than one event per read as described in section 3.1. | |
| 37 | +If the read is successful, it will return sizeof(e), unless you wanted to read | |
| 38 | +more than one event per read as described in section 3.1. | |
| 39 | 39 | |
| 40 | 40 | |
| 41 | 41 | 2.1 js_event.type |
| @@ -99,9 +99,9 @@ may work well if you handle JS_EVENT_INIT events separately, · 57 unmodified lines | ||
| 99 | 99 | |
| 100 | 100 | if ((js_event.type & ~JS_EVENT_INIT) == JS_EVENT_BUTTON) { |
| 101 | 101 | if (js_event.value) |
| 102 | − buttons_state |= (1 << js_event.number); | |
| 103 | − else | |
| 104 | − buttons_state &= ~(1 << js_event.number); | |
| 102 | + buttons_state |= (1 << js_event.number); | |
| 103 | + else | |
| 104 | + buttons_state &= ~(1 << js_event.number); | |
| 105 | 105 | } |
| 106 | 106 | |
| 107 | 107 | is much safer since it can't lose sync with the driver. As you would |
| @@ -144,14 +144,14 @@ all events on the queue (that is, until you get a -1). · 36 unmodified lines | ||
| 144 | 144 | For example, |
| 145 | 145 | |
| 146 | 146 | while (1) { |
| 147 | − while (read (fd, &e, sizeof(struct js_event)) > 0) { | |
| 148 | − process_event (e); | |
| 149 | − } | |
| 150 | − /* EAGAIN is returned when the queue is empty */ | |
| 151 | − if (errno != EAGAIN) { | |
| 152 | − /* error */ | |
| 153 | − } | |
| 154 | − /* do something interesting with processed events */ | |
| 147 | + while (read (fd, &e, sizeof(e)) > 0) { | |
| 148 | + process_event (e); | |
| 149 | + } | |
| 150 | + /* EAGAIN is returned when the queue is empty */ | |
| 151 | + if (errno != EAGAIN) { | |
| 152 | + /* error */ | |
| 153 | + } | |
| 154 | + /* do something interesting with processed events */ | |
| 155 | 155 | } |
| 156 | 156 | |
| 157 | 157 | One reason for emptying the queue is that if it gets full you'll start |
| @@ -181,7 +181,7 @@ at a time using the typical read(2) functionality. For that, you would · 23 unmodified lines | ||
| 181 | 181 | replace the read above with something like |
| 182 | 182 | |
| 183 | 183 | struct js_event mybuffer[0xff]; |
| 184 | − int i = read (fd, mybuffer, sizeof(struct mybuffer)); | |
| 184 | + int i = read (fd, mybuffer, sizeof(mybuffer)); | |
| 185 | 185 | |
| 186 | 186 | In this case, read would return -1 if the queue was empty, or some |
| 187 | 187 | other value in which the number of events read would be i / |
| @@ -269,9 +269,9 @@ The driver offers backward compatibility, though. Here's a quick summary: · 81 unmodified lines | ||
| 269 | 269 | struct JS_DATA_TYPE js; |
| 270 | 270 | while (1) { |
| 271 | 271 | if (read (fd, &js, JS_RETURN) != JS_RETURN) { |
| 272 | − /* error */ | |
| 273 | − } | |
| 274 | − usleep (1000); | |
| 272 | + /* error */ | |
| 273 | + } | |
| 274 | + usleep (1000); | |
| 275 | 275 | } |
| 276 | 276 | |
| 277 | 277 | As you can figure out from the example, the read returns immediately, |
| @@ -116,7 +116,7 @@ your needs: · 115 unmodified lines | ||
| 116 | 116 | For testing the joystick driver functionality, there is the jstest |
| 117 | 117 | program in the utilities package. You run it by typing: |
| 118 | 118 | |
| 119 | − jstest /dev/js0 | |
| 119 | + jstest /dev/input/js0 | |
| 120 | 120 | |
| 121 | 121 | And it should show a line with the joystick values, which update as you |
| 122 | 122 | move the stick, and press its buttons. The axes should all be zero when the |
| @@ -136,7 +136,7 @@ joystick should be autocalibrated by the driver automagically. However, with · 13 unmodified lines | ||
| 136 | 136 | some analog joysticks, that either do not use linear resistors, or if you |
| 137 | 137 | want better precision, you can use the jscal program |
| 138 | 138 | |
| 139 | − jscal -c /dev/js0 | |
| 139 | + jscal -c /dev/input/js0 | |
| 140 | 140 | |
| 141 | 141 | included in the joystick package to set better correction coefficients than |
| 142 | 142 | what the driver would choose itself. |
| @@ -145,7 +145,7 @@ what the driver would choose itself. · 2 unmodified lines | ||
| 145 | 145 | calibration using the jstest command, and if you do, you then can save the |
| 146 | 146 | correction coefficients into a file |
| 147 | 147 | |
| 148 | − jscal -p /dev/js0 > /etc/joystick.cal | |
| 148 | + jscal -p /dev/input/js0 > /etc/joystick.cal | |
| 149 | 149 | |
| 150 | 150 | And add a line to your rc script executing that file |
| 151 | 151 | |
| @@ -556,7 +556,7 @@ interface, and "old" for the "0.x" interface. You run it by typing: · 404 unmodified lines | ||
| 556 | 556 | |
| 557 | 557 | 5. FAQ |
| 558 | 558 | ~~~~~~ |
| 559 | −Q: Running 'jstest /dev/js0' results in "File not found" error. What's the | |
| 559 | +Q: Running 'jstest /dev/input/js0' results in "File not found" error. What's the | |
| 560 | 560 | cause? |
| 561 | 561 | A: The device files don't exist. Create them (see section 2.2). |
| 562 | 562 | |
| @@ -38,7 +38,7 @@ maps are more efficient: · 37 unmodified lines | ||
| 38 | 38 | |
| 39 | 39 | void io_mapping_unmap_atomic(void *vaddr) |
| 40 | 40 | |
| 41 | − 'vaddr' must be the the value returned by the last | |
| 41 | + 'vaddr' must be the value returned by the last | |
| 42 | 42 | io_mapping_map_atomic_wc call. This unmaps the specified |
| 43 | 43 | page and allows the task to sleep once again. |
| 44 | 44 | |
| @@ -73,6 +73,7 @@ Code Seq#(hex) Include File Comments · 72 unmodified lines | ||
| 73 | 73 | 0x09 all linux/raid/md_u.h |
| 74 | 74 | 0x10 00-0F drivers/char/s390/vmcp.h |
| 75 | 75 | 0x10 10-1F arch/s390/include/uapi/sclp_ctl.h |
| 76 | +0x10 20-2F arch/s390/include/uapi/asm/hypfs.h | |
| 76 | 77 | 0x12 all linux/fs.h |
| 77 | 78 | linux/blkpg.h |
| 78 | 79 | 0x1b all InfiniBand Subsystem <http://infiniband.sourceforge.net/> |
| @@ -149,7 +149,7 @@ linux-api@ver.kernel.org に送ることを勧めます。 · 148 unmodified lines | ||
| 149 | 149 | この他にパッチを作る方法についてのよくできた記述は- |
| 150 | 150 | |
| 151 | 151 | "The Perfect Patch" |
| 152 | − http://userweb.kernel.org/~akpm/stuff/tpp.txt | |
| 152 | + http://www.ozlabs.org/~akpm/stuff/tpp.txt | |
| 153 | 153 | "Linux kernel patch submission format" |
| 154 | 154 | http://linux.yyz.us/patch-format.html |
| 155 | 155 | |
| @@ -622,7 +622,7 @@ Linux カーネルコミュニティは、一度に大量のコードの塊を · 466 unmodified lines | ||
| 622 | 622 | これについて全てがどのようにあるべきかについての詳細は、以下のドキュメ |
| 623 | 623 | ントの ChangeLog セクションを見てください- |
| 624 | 624 | "The Perfect Patch" |
| 625 | − http://userweb.kernel.org/~akpm/stuff/tpp.txt | |
| 625 | + http://www.ozlabs.org/~akpm/stuff/tpp.txt | |
| 626 | 626 | |
| 627 | 627 | これらのどれもが、時にはとても困難です。これらの慣例を完璧に実施するに |
| 628 | 628 | は数年かかるかもしれません。これは継続的な改善のプロセスであり、そのた |
| @@ -343,6 +343,9 @@ bytes respectively. Such letter suffixes can also be entirely omitted. · 342 unmodified lines | ||
| 343 | 343 | no: ACPI OperationRegions are not marked as reserved, |
| 344 | 344 | no further checks are performed. |
| 345 | 345 | |
| 346 | + acpi_no_memhotplug [ACPI] Disable memory hotplug. Useful for kdump | |
| 347 | + kernels. | |
| 348 | + | |
| 346 | 349 | add_efi_memmap [EFI; X86] Include EFI memory map in |
| 347 | 350 | kernel's map of available physical RAM. |
| 348 | 351 | |
| @@ -463,6 +466,22 @@ bytes respectively. Such letter suffixes can also be entirely omitted. · 114 unmodified lines | ||
| 463 | 466 | atkbd.softrepeat= [HW] |
| 464 | 467 | Use software keyboard repeat |
| 465 | 468 | |
| 469 | + audit= [KNL] Enable the audit sub-system | |
| 470 | + Format: { "0" | "1" } (0 = disabled, 1 = enabled) | |
| 471 | + 0 - kernel audit is disabled and can not be enabled | |
| 472 | + until the next reboot | |
| 473 | + unset - kernel audit is initialized but disabled and | |
| 474 | + will be fully enabled by the userspace auditd. | |
| 475 | + 1 - kernel audit is initialized and partially enabled, | |
| 476 | + storing at most audit_backlog_limit messages in | |
| 477 | + RAM until it is fully enabled by the userspace | |
| 478 | + auditd. | |
| 479 | + Default: unset | |
| 480 | + | |
| 481 | + audit_backlog_limit= [KNL] Set the audit queue size limit. | |
| 482 | + Format: <int> (must be >=0) | |
| 483 | + Default: 64 | |
| 484 | + | |
| 466 | 485 | baycom_epp= [HW,AX25] |
| 467 | 486 | Format: <io>,<mode> |
| 468 | 487 | |
| @@ -515,7 +534,14 @@ bytes respectively. Such letter suffixes can also be entirely omitted. · 46 unmodified lines | ||
| 515 | 534 | |
| 516 | 535 | cgroup_disable= [KNL] Disable a particular controller |
| 517 | 536 | Format: {name of the controller(s) to disable} |
| 518 | − {Currently supported controllers - "memory"} | |
| 537 | + The effects of cgroup_disable=foo are: | |
| 538 | + - foo isn't auto-mounted if you mount all cgroups in | |
| 539 | + a single hierarchy | |
| 540 | + - foo isn't visible as an individually mountable | |
| 541 | + subsystem | |
| 542 | + {Currently only "memory" controller deal with this and | |
| 543 | + cut the overhead, others just disable the usage. So | |
| 544 | + only cgroup_disable=memory is actually worthy} | |
| 519 | 545 | |
| 520 | 546 | checkreqprot [SELINUX] Set initial checkreqprot flag value. |
| 521 | 547 | Format: { "0" | "1" } |
| @@ -1036,7 +1062,9 @@ bytes respectively. Such letter suffixes can also be entirely omitted. · 514 unmodified lines | ||
| 1036 | 1062 | debugfs files are removed at module unload time. |
| 1037 | 1063 | |
| 1038 | 1064 | gpt [EFI] Forces disk with valid GPT signature but |
| 1039 | − invalid Protective MBR to be treated as GPT. | |
| 1065 | + invalid Protective MBR to be treated as GPT. If the | |
| 1066 | + primary GPT is corrupted, it enables the backup/alternate | |
| 1067 | + GPT to be used instead. | |
| 1040 | 1068 | |
| 1041 | 1069 | grcan.enable0= [HW] Configuration of physical interface 0. Determines |
| 1042 | 1070 | the "Enable 0" bit of the configuration register. |
| @@ -1438,6 +1466,13 @@ bytes respectively. Such letter suffixes can also be entirely omitted. · 395 unmodified lines | ||
| 1438 | 1466 | Valid arguments: on, off |
| 1439 | 1467 | Default: on |
| 1440 | 1468 | |
| 1469 | + kmemcheck= [X86] Boot-time kmemcheck enable/disable/one-shot mode | |
| 1470 | + Valid arguments: 0, 1, 2 | |
| 1471 | + kmemcheck=0 (disabled) | |
| 1472 | + kmemcheck=1 (enabled) | |
| 1473 | + kmemcheck=2 (one-shot mode) | |
| 1474 | + Default: 2 (one-shot mode) | |
| 1475 | + | |
| 1441 | 1476 | kstack=N [X86] Print N words from the kernel stack |
| 1442 | 1477 | in oops dumps. |
| 1443 | 1478 | |
| @@ -3089,7 +3124,11 @@ bytes respectively. Such letter suffixes can also be entirely omitted. · 1645 unmodified lines | ||
| 3089 | 3124 | controller if no parameter or 1 is given or disable |
| 3090 | 3125 | it if 0 is given (See Documentation/cgroups/memory.txt) |
| 3091 | 3126 | |
| 3092 | − swiotlb= [IA-64] Number of I/O TLB slabs | |
| 3127 | + swiotlb= [ARM,IA-64,PPC,MIPS,X86] | |
| 3128 | + Format: { <int> | force } | |
| 3129 | + <int> -- Number of I/O TLB slabs | |
| 3130 | + force -- force using of bounce buffers even if they | |
| 3131 | + wouldn't be automatically used by the kernel | |
| 3093 | 3132 | |
| 3094 | 3133 | switches= [HW,M68k] |
| 3095 | 3134 | |
| @@ -1,20 +0,0 @@ | ||
| 1 | −/*? | |
| 2 | − * Text: "Cryptographic device %x failed and was set offline\n" | |
| 3 | − * Severity: Error | |
| 4 | − * Parameter: | |
| 5 | − * @1: device index | |
| 6 | − * Description: | |
| 7 | − * A cryptographic device failed to process a cryptographic request. | |
| 8 | − * The cryptographic device driver could not correct the error and | |
| 9 | − * set the device offline. The application that issued the | |
| 10 | − * request received an indication that the request has failed. | |
| 11 | − * User action: | |
| 12 | − * Use the lszcrypt command to confirm that the cryptographic | |
| 13 | − * hardware is still configured to your LPAR or z/VM guest virtual | |
| 14 | − * machine. If the device is available to your Linux instance the | |
| 15 | − * command output contains a line that begins with 'card<device index>', | |
| 16 | − * where <device index> is the two-digit decimal number in the message text. | |
| 17 | − * After ensuring that the device is available, use the chzcrypt command to | |
| 18 | − * set it online again. | |
| 19 | − * If the error persists, contact your support organization. | |
| 20 | − */ | |
| @@ -122,7 +122,7 @@ mtk.manpages@gmail.com의 메인테이너에게 보낼 것을 권장한다. · 121 unmodified lines | ||
| 122 | 122 | |
| 123 | 123 | 올바른 패치들을 만드는 법에 관한 훌륭한 다른 문서들이 있다. |
| 124 | 124 | "The Perfect Patch" |
| 125 | − http://userweb.kernel.org/~akpm/stuff/tpp.txt | |
| 125 | + http://www.ozlabs.org/~akpm/stuff/tpp.txt | |
| 126 | 126 | "Linux kernel patch submission format" |
| 127 | 127 | http://linux.yyz.us/patch-format.html |
| 128 | 128 | |
| @@ -213,7 +213,7 @@ Documentation/DocBook/ 디렉토리 내에서 만들어지며 PDF, Postscript, H · 84 unmodified lines | ||
| 213 | 213 | 것은 Linux Cross-Reference project이며 그것은 자기 참조 방식이며 |
| 214 | 214 | 소스코드를 인덱스된 웹 페이지들의 형태로 보여준다. 최신의 멋진 커널 |
| 215 | 215 | 코드 저장소는 다음을 통하여 참조할 수 있다. |
| 216 | − http://users.sosdg.org/~qiyong/lxr/ | |
| 216 | + http://lxr.linux.no/+trees | |
| 217 | 217 | |
| 218 | 218 | |
| 219 | 219 | 개발 프로세스 |
| @@ -222,20 +222,20 @@ Documentation/DocBook/ 디렉토리 내에서 만들어지며 PDF, Postscript, H · 2 unmodified lines | ||
| 222 | 222 | 리눅스 커널 개발 프로세스는 현재 몇몇 다른 메인 커널 "브랜치들"과 |
| 223 | 223 | 서브시스템에 특화된 커널 브랜치들로 구성된다. 몇몇 다른 메인 |
| 224 | 224 | 브랜치들은 다음과 같다. |
| 225 | − - main 2.6.x 커널 트리 | |
| 226 | − - 2.6.x.y - 안정된 커널 트리 | |
| 227 | − - 2.6.x -git 커널 패치들 | |
| 228 | − - 2.6.x -mm 커널 패치들 | |
| 225 | + - main 3.x 커널 트리 | |
| 226 | + - 3.x.y - 안정된 커널 트리 | |
| 227 | + - 3.x -git 커널 패치들 | |
| 229 | 228 | - 서브시스템을 위한 커널 트리들과 패치들 |
| 229 | + - 3.x - 통합 테스트를 위한 next 커널 트리 | |
| 230 | 230 | |
| 231 | −2.6.x 커널 트리 | |
| 231 | +3.x 커널 트리 | |
| 232 | 232 | --------------- |
| 233 | 233 | |
| 234 | −2.6.x 커널들은 Linux Torvalds가 관리하며 kernel.org의 pub/linux/kernel/v2.6/ | |
| 234 | +3.x 커널들은 Linux Torvalds가 관리하며 kernel.org의 pub/linux/kernel/v3.x/ | |
| 235 | 235 | 디렉토리에서 참조될 수 있다.개발 프로세스는 다음과 같다. |
| 236 | 236 | - 새로운 커널이 배포되자마자 2주의 시간이 주어진다. 이 기간동은 |
| 237 | 237 | 메인테이너들은 큰 diff들을 Linus에게 제출할 수 있다. 대개 이 패치들은 |
| 238 | − 몇 주 동안 -mm 커널내에 이미 있었던 것들이다. 큰 변경들을 제출하는 데 | |
| 238 | + 몇 주 동안 -next 커널내에 이미 있었던 것들이다. 큰 변경들을 제출하는 데 | |
| 239 | 239 | 선호되는 방법은 git(커널의 소스 관리 툴, 더 많은 정보들은 http://git.or.cz/ |
| 240 | 240 | 에서 참조할 수 있다)를 사용하는 것이지만 순수한 패치파일의 형식으로 보내는 |
| 241 | 241 | 것도 무관하다. |
| @@ -262,20 +262,20 @@ Andrew Morton의 글이 있다. · 20 unmodified lines | ||
| 262 | 262 | 버그의 상황에 따라 배포되는 것이지 미리정해 놓은 시간에 따라 |
| 263 | 263 | 배포되는 것은 아니기 때문이다." |
| 264 | 264 | |
| 265 | −2.6.x.y - 안정 커널 트리 | |
| 265 | +3.x.y - 안정 커널 트리 | |
| 266 | 266 | ------------------------ |
| 267 | 267 | |
| 268 | −4 자리 숫자로 이루어진 버젼의 커널들은 -stable 커널들이다. 그것들은 2.6.x | |
| 268 | +3 자리 숫자로 이루어진 버젼의 커널들은 -stable 커널들이다. 그것들은 3.x | |
| 269 | 269 | 커널에서 발견된 큰 회귀들이나 보안 문제들 중 비교적 작고 중요한 수정들을 |
| 270 | 270 | 포함한다. |
| 271 | 271 | |
| 272 | 272 | 이것은 가장 최근의 안정적인 커널을 원하는 사용자에게 추천되는 브랜치이며, |
| 273 | 273 | 개발/실험적 버젼을 테스트하는 것을 돕고자 하는 사용자들과는 별로 관련이 없다. |
| 274 | 274 | |
| 275 | −어떤 2.6.x.y 커널도 사용할 수 없다면 그때는 가장 높은 숫자의 2.6.x | |
| 275 | +어떤 3.x.y 커널도 사용할 수 없다면 그때는 가장 높은 숫자의 3.x | |
| 276 | 276 | 커널이 현재의 안정 커널이다. |
| 277 | 277 | |
| 278 | −2.6.x.y는 "stable" 팀<stable@kernel.org>에 의해 관리되며 거의 매번 격주로 | |
| 278 | +3.x.y는 "stable" 팀<stable@vger.kernel.org>에 의해 관리되며 거의 매번 격주로 | |
| 279 | 279 | 배포된다. |
| 280 | 280 | |
| 281 | 281 | 커널 트리 문서들 내에 Documentation/stable_kernel_rules.txt 파일은 어떤 |
| @@ -283,84 +283,46 @@ Andrew Morton의 글이 있다. · 1 unmodified line | ||
| 283 | 283 | 진행되는지를 설명한다. |
| 284 | 284 | |
| 285 | 285 | |
| 286 | −2.6.x -git 패치들 | |
| 286 | +3.x -git 패치들 | |
| 287 | 287 | ------------------ |
| 288 | 288 | git 저장소(그러므로 -git이라는 이름이 붙음)에는 날마다 관리되는 Linus의 |
| 289 | 289 | 커널 트리의 snapshot 들이 있다. 이 패치들은 일반적으로 날마다 배포되며 |
| 290 | 290 | Linus의 트리의 현재 상태를 나타낸다. 이 패치들은 정상적인지 조금도 |
| 291 | 291 | 살펴보지 않고 자동적으로 생성된 것이므로 -rc 커널들 보다도 더 실험적이다. |
| 292 | 292 | |
| 293 | −2.6.x -mm 커널 패치들 | |
| 294 | −--------------------- | |
| 295 | −Andrew Morton에 의해 배포된 실험적인 커널 패치들이다. Andrew는 모든 다른 | |
| 296 | −서브시스템 커널 트리와 패치들을 가져와서 리눅스 커널 메일링 리스트로 | |
| 297 | −온 많은 패치들과 한데 묶는다. 이 트리는 새로운 기능들과 패치들을 위한 | |
| 298 | −장소를 제공하는 역할을 한다. 하나의 패치가 -mm에 한동안 있으면서 그 가치가 | |
| 299 | −증명되게 되면 Andrew나 서브시스템 메인테이너는 그것을 메인라인에 포함시키기 | |
| 300 | −위하여 Linus에게 보낸다. | |
| 301 | − | |
| 302 | −커널 트리에 포함하고 싶은 모든 새로운 패치들은 Linus에게 보내지기 전에 | |
| 303 | −-mm 트리에서 테스트를 하는 것을 적극 추천한다. | |
| 304 | − | |
| 305 | −이 커널들은 안정되게 사용할 시스템에서에 실행하는 것은 적합하지 않으며 | |
| 306 | −다른 브랜치들의 어떤 것들보다 위험하다. | |
| 307 | − | |
| 308 | −여러분이 커널 개발 프로세스를 돕길 원한다면 이 커널 배포들을 사용하고 | |
| 309 | −테스트한 후 어떤 문제를 발견하거나 또는 모든 것이 잘 동작한다면 리눅스 | |
| 310 | −커널 메일링 리스트로 피드백을 해달라. | |
| 311 | − | |
| 312 | −이 커널들은 일반적으로 모든 다른 실험적인 패치들과 배포될 당시의 | |
| 313 | −사용가능한 메인라인 -git 커널들의 몇몇 변경을 포함한다. | |
| 314 | − | |
| 315 | −-mm 커널들은 정해진 일정대로 배포되지 않는다. 하지만 대개 몇몇 -mm 커널들은 | |
| 316 | −각 -rc 커널(1부터 3이 흔함) 사이에서 배포된다. | |
| 317 | − | |
| 318 | 293 | 서브시스템 커널 트리들과 패치들 |
| 319 | 294 | ------------------------------- |
| 320 | −많은 다른 커널 서브시스템 개발자들은 커널의 다른 부분들에서 무슨 일이 | |
| 321 | −일어나고 있는지를 볼수 있도록 그들의 개발 트리를 공개한다. 이 트리들은 | |
| 322 | −위에서 설명하였던 것 처럼 -mm 커널 배포들로 합쳐진다. | |
| 323 | − | |
| 324 | −다음은 활용가능한 커널 트리들을 나열한다. | |
| 325 | − git trees: | |
| 326 | − - Kbuild development tree, Sam Ravnborg < sam@ravnborg.org> | |
| 327 | − git.kernel.org:/pub/scm/linux/kernel/git/sam/kbuild.git | |
| 328 | − | |
| 329 | − - ACPI development tree, Len Brown <len.brown@intel.com > | |
| 330 | − git.kernel.org:/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git | |
| 331 | − | |
| 332 | − - Block development tree, Jens Axboe <jens.axboe@oracle.com> | |
| 333 | − git.kernel.org:/pub/scm/linux/kernel/git/axboe/linux-2.6-block.git | |
| 334 | − | |
| 335 | − - DRM development tree, Dave Airlie <airlied@linux.ie> | |
| 336 | − git.kernel.org:/pub/scm/linux/kernel/git/airlied/drm-2.6.git | |
| 337 | − | |
| 338 | − - ia64 development tree, Tony Luck < tony.luck@intel.com> | |
| 339 | − git.kernel.org:/pub/scm/linux/kernel/git/aegl/linux-2.6.git | |
| 340 | − | |
| 341 | − - infiniband, Roland Dreier <rolandd@cisco.com > | |
| 342 | − git.kernel.org:/pub/scm/linux/kernel/git/roland/infiniband.git | |
| 343 | − | |
| 344 | − - libata, Jeff Garzik <jgarzik@pobox.com> | |
| 345 | − git.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev.git | |
| 346 | − | |
| 347 | − - network drivers, Jeff Garzik <jgarzik@pobox.com> | |
| 348 | − git.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git | |
| 349 | − | |
| 350 | − - pcmcia, Dominik Brodowski < linux@dominikbrodowski.net> | |
| 351 | − git.kernel.org:/pub/scm/linux/kernel/git/brodo/pcmcia-2.6.git | |
| 352 | − | |
| 353 | − - SCSI, James Bottomley < James.Bottomley@SteelEye.com> | |
| 354 | − git.kernel.org:/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6.git | |
| 355 | − | |
| 356 | − quilt trees: | |
| 357 | − - USB, PCI, Driver Core, and I2C, Greg Kroah-Hartman < gregkh@linuxfoundation.org> | |
| 358 | − kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/ | |
| 359 | − - x86-64, partly i386, Andi Kleen < ak@suse.de> | |
| 360 | − ftp.firstfloor.org:/pub/ak/x86_64/quilt/ | |
| 361 | − | |
| 362 | − 다른 커널 트리들은 http://kernel.org/git와 MAINTAINERS 파일에서 참조할 수 | |
| 363 | − 있다. | |
| 295 | +다양한 커널 서브시스템의 메인테이너들 --- 그리고 많은 커널 서브시스템 개발자들 | |
| 296 | +--- 은 그들의 현재 개발 상태를 소스 저장소로 노출한다. 이를 통해 다른 사람들도 | |
| 297 | +커널의 다른 영역에 어떤 변화가 이루어지고 있는지 알 수 있다. 급속히 개발이 | |
| 298 | +진행되는 영역이 있고 그렇지 않은 영역이 있으므로, 개발자는 다른 개발자가 제출한 | |
| 299 | +수정 사항과 자신의 수정사항의 충돌이나 동일한 일을 동시에 두사람이 따로 | |
| 300 | +진행하는 사태를 방지하기 위해 급속히 개발이 진행되고 있는 영역에 작업의 | |
| 301 | +베이스를 맞춰줄 것이 요구된다. | |
| 302 | + | |
| 303 | +대부분의 이러한 저장소는 git 트리지만, git이 아닌 SCM으로 관리되거나, quilt | |
| 304 | +시리즈로 제공되는 패치들도 존재한다. 이러한 서브시스템 저장소들은 MAINTAINERS | |
| 305 | +파일에 나열되어 있다. 대부분은 http://git.kernel.org 에서 볼 수 있다. | |
| 306 | + | |
| 307 | +제안된 패치는 서브시스템 트리에 커밋되기 전에 메일링 리스트를 통해 | |
| 308 | +리뷰된다(아래의 관련 섹션을 참고하기 바란다). 일부 커널 서브시스템의 경우, 이 | |
| 309 | +리뷰 프로세스는 patchwork라는 도구를 통해 추적된다. patchwork은 등록된 패치와 | |
| 310 | +패치에 대한 코멘트, 패치의 버전을 볼 수 있는 웹 인터페이스를 제공하고, | |
| 311 | +메인테이너는 패치를 리뷰 중, 리뷰 통과, 또는 반려됨으로 표시할 수 있다. | |
| 312 | +대부분의 이러한 patchwork 사이트는 http://patchwork.kernel.org/ 또는 | |
| 313 | +http://patchwork.ozlabs.org/ 에 나열되어 있다. | |
| 314 | + | |
| 315 | +3.x - 통합 테스트를 위한 next 커널 트리 | |
| 316 | +----------------------------------------- | |
| 317 | +서브시스템 트리들의 변경사항들은 mainline 3.x 트리로 들어오기 전에 통합 | |
| 318 | +테스트를 거쳐야 한다. 이런 목적으로, 모든 서브시스템 트리의 변경사항을 거의 | |
| 319 | +매일 받아가는 특수한 테스트 저장소가 존재한다: | |
| 320 | + http://git.kernel.org/?p=linux/kernel/git/sfr/linux-next.git | |
| 321 | + http://linux.f-seidel.de/linux-next/pmwiki/ | |
| 322 | + | |
| 323 | +이런 식으로, -next 커널을 통해 다음 머지 기간에 메인라인 커널에 어떤 변경이 | |
| 324 | +가해질 것인지 간략히 알 수 있다. 모험심 강한 테스터라면 -next 커널에서 테스트를 | |
| 325 | +수행하는 것도 좋을 것이다. | |
| 364 | 326 | |
| 365 | 327 | 버그 보고 |
| 366 | 328 | --------- |
| @@ -597,7 +559,7 @@ Pat이라는 이름을 가진 여자가 있을 수도 있는 것이다. 리눅 · 230 unmodified lines | ||
| 597 | 559 | |
| 598 | 560 | 이것이 무엇인지 더 자세한 것을 알고 싶다면 다음 문서의 ChageLog 항을 봐라. |
| 599 | 561 | "The Perfect Patch" |
| 600 | − http://userweb.kernel.org/~akpm/stuff/tpp.txt | |
| 562 | + http://www.ozlabs.org/~akpm/stuff/tpp.txt | |
| 601 | 563 | |
| 602 | 564 | |
| 603 | 565 | |
| @@ -342,7 +342,10 @@ kset use: · 341 unmodified lines | ||
| 342 | 342 | |
| 343 | 343 | When you are finished with the kset, call: |
| 344 | 344 | void kset_unregister(struct kset *kset); |
| 345 | −to destroy it. | |
| 345 | +to destroy it. This removes the kset from sysfs and decrements its reference | |
| 346 | +count. When the reference count goes to zero, the kset will be released. | |
| 347 | +Because other references to the kset may still exist, the release may happen | |
| 348 | +after kset_unregister() returns. | |
| 346 | 349 | |
| 347 | 350 | An example of using a kset can be seen in the |
| 348 | 351 | samples/kobject/kset-example.c file in the kernel tree. |
| @@ -29,7 +29,7 @@ int set_unload_heads_path(char *device) · 28 unmodified lines | ||
| 29 | 29 | return -EINVAL; |
| 30 | 30 | strncpy(devname, device + 5, sizeof(devname)); |
| 31 | 31 | |
| 32 | − snprintf(unload_heads_path, sizeof(unload_heads_path), | |
| 32 | + snprintf(unload_heads_path, sizeof(unload_heads_path) - 1, | |
| 33 | 33 | "/sys/block/%s/device/unload_heads", devname); |
| 34 | 34 | return 0; |
| 35 | 35 | } |
| @@ -73,6 +73,10 @@ select_engine : Select which engine is used for running program · 72 unmodified lines | ||
| 73 | 73 | run_engine : Start program which is loaded via the firmware interface |
| 74 | 74 | firmware : Load program data |
| 75 | 75 | |
| 76 | +In case of LP5523, one more command is required, 'enginex_leds'. | |
| 77 | +It is used for selecting LED output(s) at each engine number. | |
| 78 | +In more details, please refer to 'leds-lp5523.txt'. | |
| 79 | + | |
| 76 | 80 | For example, run blinking pattern in engine #1 of LP5521 |
| 77 | 81 | echo 1 > /sys/bus/i2c/devices/xxxx/select_engine |
| 78 | 82 | echo 1 > /sys/class/firmware/lp5521/loading |
| @@ -81,10 +85,12 @@ echo 0 > /sys/class/firmware/lp5521/loading · 2 unmodified lines | ||
| 81 | 85 | echo 1 > /sys/bus/i2c/devices/xxxx/run_engine |
| 82 | 86 | |
| 83 | 87 | For example, run blinking pattern in engine #3 of LP55231 |
| 88 | +Two LEDs are configured as pattern output channels. | |
| 84 | 89 | echo 3 > /sys/bus/i2c/devices/xxxx/select_engine |
| 85 | 90 | echo 1 > /sys/class/firmware/lp55231/loading |
| 86 | 91 | echo "9d0740ff7e0040007e00a0010000" > /sys/class/firmware/lp55231/data |
| 87 | 92 | echo 0 > /sys/class/firmware/lp55231/loading |
| 93 | +echo "000001100" > /sys/bus/i2c/devices/xxxx/engine3_leds | |
| 88 | 94 | echo 1 > /sys/bus/i2c/devices/xxxx/run_engine |
| 89 | 95 | |
| 90 | 96 | To start blinking patterns in engine #2 and #3 simultaneously, |
| @@ -99,17 +105,19 @@ done · 8 unmodified lines | ||
| 99 | 105 | echo 1 > /sys/class/leds/red/device/run_engine |
| 100 | 106 | |
| 101 | 107 | Here is another example for LP5523. |
| 108 | +Full LED strings are selected by 'engine2_leds'. | |
| 102 | 109 | echo 2 > /sys/bus/i2c/devices/xxxx/select_engine |
| 103 | 110 | echo 1 > /sys/class/firmware/lp5523/loading |
| 104 | 111 | echo "9d80400004ff05ff437f0000" > /sys/class/firmware/lp5523/data |
| 105 | 112 | echo 0 > /sys/class/firmware/lp5523/loading |
| 113 | +echo "111111111" > /sys/bus/i2c/devices/xxxx/engine2_leds | |
| 106 | 114 | echo 1 > /sys/bus/i2c/devices/xxxx/run_engine |
| 107 | 115 | |
| 108 | 116 | As soon as 'loading' is set to 0, registered callback is called. |
| 109 | 117 | Inside the callback, the selected engine is loaded and memory is updated. |
| 110 | 118 | To run programmed pattern, 'run_engine' attribute should be enabled. |
| 111 | 119 | |
| 112 | −The pattern sqeuence of LP8501 is same as LP5523. | |
| 120 | +The pattern sqeuence of LP8501 is similar to LP5523. | |
| 113 | 121 | However pattern data is specific. |
| 114 | 122 | Ex 1) Engine 1 is used |
| 115 | 123 | echo 1 > /sys/bus/i2c/devices/xxxx/select_engine |
| @@ -533,7 +533,7 @@ also have · 532 unmodified lines | ||
| 533 | 533 | found. The count in 'mismatch_cnt' is the number of sectors |
| 534 | 534 | that were re-written, or (for 'check') would have been |
| 535 | 535 | re-written. As most raid levels work in units of pages rather |
| 536 | − than sectors, this my be larger than the number of actual errors | |
| 536 | + than sectors, this may be larger than the number of actual errors | |
| 537 | 537 | by a factor of the number of sectors in a page. |
| 538 | 538 | |
| 539 | 539 | bitmap_set_bits |
| @@ -38,7 +38,7 @@ Supported chips: · 37 unmodified lines | ||
| 38 | 38 | Authors: |
| 39 | 39 | Frodo Looijaard <frodol@dds.nl>, |
| 40 | 40 | Philip Edelbrock <phil@netroedge.com>, |
| 41 | − Jean Delvare <khali@linux-fr.org>, | |
| 41 | + Jean Delvare <jdelvare@suse.de>, | |
| 42 | 42 | Greg Kroah-Hartman <greg@kroah.com>, |
| 43 | 43 | IBM Corp. |
| 44 | 44 | |
| @@ -115,8 +115,6 @@ static bool mei_init(struct mei *me, const uuid_le *guid, · 114 unmodified lines | ||
| 115 | 115 | struct mei_client *cl; |
| 116 | 116 | struct mei_connect_client_data data; |
| 117 | 117 | |
| 118 | − mei_deinit(me); | |
| 119 | − | |
| 120 | 118 | me->verbose = verbose; |
| 121 | 119 | |
| 122 | 120 | me->fd = open("/dev/mei", O_RDWR); |
| @@ -0,0 +1,113 @@ | ||
| 1 | + | |
| 2 | +About this document | |
| 3 | +=================== | |
| 4 | + | |
| 5 | +Some notes about Marvell's NAND controller available in PXA and Armada 370/XP | |
| 6 | +SoC (aka NFCv1 and NFCv2), with an emphasis on the latter. | |
| 7 | + | |
| 8 | +NFCv2 controller background | |
| 9 | +=========================== | |
| 10 | + | |
| 11 | +The controller has a 2176 bytes FIFO buffer. Therefore, in order to support | |
| 12 | +larger pages, I/O operations on 4 KiB and 8 KiB pages is done with a set of | |
| 13 | +chunked transfers. | |
| 14 | + | |
| 15 | +For instance, if we choose a 2048 data chunk and set "BCH" ECC (see below) | |
| 16 | +we'll have this layout in the pages: | |
| 17 | + | |
| 18 | + ------------------------------------------------------------------------------ | |
| 19 | + | 2048B data | 32B spare | 30B ECC || 2048B data | 32B spare | 30B ECC | ... | | |
| 20 | + ------------------------------------------------------------------------------ | |
| 21 | + | |
| 22 | +The driver reads the data and spare portions independently and builds an internal | |
| 23 | +buffer with this layout (in the 4 KiB page case): | |
| 24 | + | |
| 25 | + ------------------------------------------ | |
| 26 | + | 4096B data | 64B spare | | |
| 27 | + ------------------------------------------ | |
| 28 | + | |
| 29 | +Also, for the READOOB command the driver disables the ECC and reads a 'spare + ECC' | |
| 30 | +OOB, one per chunk read. | |
| 31 | + | |
| 32 | + ------------------------------------------------------------------- | |
| 33 | + | 4096B data | 32B spare | 30B ECC | 32B spare | 30B ECC | | |
| 34 | + ------------------------------------------------------------------- | |
| 35 | + | |
| 36 | +So, in order to achieve reading (for instance), we issue several READ0 commands | |
| 37 | +(with some additional controller-specific magic) and read two chunks of 2080B | |
| 38 | +(2048 data + 32 spare) each. | |
| 39 | +The driver accommodates this data to expose the NAND core a contiguous buffer | |
| 40 | +(4096 data + spare) or (4096 + spare + ECC + spare + ECC). | |
| 41 | + | |
| 42 | +ECC | |
| 43 | +=== | |
| 44 | + | |
| 45 | +The controller has built-in hardware ECC capabilities. In addition it is | |
| 46 | +configurable between two modes: 1) Hamming, 2) BCH. | |
| 47 | + | |
| 48 | +Note that the actual BCH mode: BCH-4 or BCH-8 will depend on the way | |
| 49 | +the controller is configured to transfer the data. | |
| 50 | + | |
| 51 | +In the BCH mode the ECC code will be calculated for each transfered chunk | |
| 52 | +and expected to be located (when reading/programming) right after the spare | |
| 53 | +bytes as the figure above shows. | |
| 54 | + | |
| 55 | +So, repeating the above scheme, a 2048B data chunk will be followed by 32B | |
| 56 | +spare, and then the ECC controller will read/write the ECC code (30B in | |
| 57 | +this case): | |
| 58 | + | |
| 59 | + ------------------------------------ | |
| 60 | + | 2048B data | 32B spare | 30B ECC | | |
| 61 | + ------------------------------------ | |
| 62 | + | |
| 63 | +If the ECC mode is 'BCH' then the ECC is *always* 30 bytes long. | |
| 64 | +If the ECC mode is 'Hamming' the ECC is 6 bytes long, for each 512B block. | |
| 65 | +So in Hamming mode, a 2048B page will have a 24B ECC. | |
| 66 | + | |
| 67 | +Despite all of the above, the controller requires the driver to only read or | |
| 68 | +write in multiples of 8-bytes, because the data buffer is 64-bits. | |
| 69 | + | |
| 70 | +OOB | |
| 71 | +=== | |
| 72 | + | |
| 73 | +Because of the above scheme, and because the "spare" OOB is really located in | |
| 74 | +the middle of a page, spare OOB cannot be read or write independently of the | |
| 75 | +data area. In other words, in order to read the OOB (aka READOOB), the entire | |
| 76 | +page (aka READ0) has to be read. | |
| 77 | + | |
| 78 | +In the same sense, in order to write to the spare OOB the driver has to write | |
| 79 | +an *entire* page. | |
| 80 | + | |
| 81 | +Factory bad blocks handling | |
| 82 | +=========================== | |
| 83 | + | |
| 84 | +Given the ECC BCH requires to layout the device's pages in a split | |
| 85 | +data/OOB/data/OOB way, the controller has a view of the flash page that's | |
| 86 | +different from the specified (aka the manufacturer's) view. In other words, | |
| 87 | + | |
| 88 | +Factory view: | |
| 89 | + | |
| 90 | + ----------------------------------------------- | |
| 91 | + | Data |x OOB | | |
| 92 | + ----------------------------------------------- | |
| 93 | + | |
| 94 | +Driver's view: | |
| 95 | + | |
| 96 | + ----------------------------------------------- | |
| 97 | + | Data | OOB | Data x | OOB | | |
| 98 | + ----------------------------------------------- | |
| 99 | + | |
| 100 | +It can be seen from the above, that the factory bad block marker must be | |
| 101 | +searched within the 'data' region, and not in the usual OOB region. | |
| 102 | + | |
| 103 | +In addition, this means under regular usage the driver will write such | |
| 104 | +position (since it belongs to the data region) and every used block is | |
| 105 | +likely to be marked as bad. | |
| 106 | + | |
| 107 | +For this reason, marking the block as bad in the OOB is explicitly | |
| 108 | +disabled by using the NAND_BBT_NO_OOB_BBM option in the driver. The rationale | |
| 109 | +for this is that there's no point in marking a block as bad, because good | |
| 110 | +blocks are also 'marked as bad' (in the OOB BBM sense) under normal usage. | |
| 111 | + | |
| 112 | +Instead, the driver relies on the bad block table alone, and should only perform | |
| 113 | +the bad block scan on the very first time (when the device hasn't been used). | |
| @@ -66,11 +66,10 @@ All mesh wide settings can be found in batman's own interface · 65 unmodified lines | ||
| 66 | 66 | folder: |
| 67 | 67 | |
| 68 | 68 | # ls /sys/class/net/bat0/mesh/ |
| 69 | −# aggregated_ogms gw_bandwidth log_level | |
| 70 | −# ap_isolation gw_mode orig_interval | |
| 71 | −# bonding gw_sel_class routing_algo | |
| 72 | −# bridge_loop_avoidance hop_penalty fragmentation | |
| 73 | − | |
| 69 | +#aggregated_ogms distributed_arp_table gw_sel_class orig_interval | |
| 70 | +#ap_isolation fragmentation hop_penalty routing_algo | |
| 71 | +#bonding gw_bandwidth isolation_mark vlan0 | |
| 72 | +#bridge_loop_avoidance gw_mode log_level | |
| 74 | 73 | |
| 75 | 74 | There is a special folder for debugging information: |
| 76 | 75 | |
| @@ -657,7 +657,8 @@ primary · 656 unmodified lines | ||
| 657 | 657 | one slave is preferred over another, e.g., when one slave has |
| 658 | 658 | higher throughput than another. |
| 659 | 659 | |
| 660 | − The primary option is only valid for active-backup mode. | |
| 660 | + The primary option is only valid for active-backup(1), | |
| 661 | + balance-tlb (5) and balance-alb (6) mode. | |
| 661 | 662 | |
| 662 | 663 | primary_reselect |
| 663 | 664 | |
| @@ -853,6 +854,14 @@ resend_igmp · 189 unmodified lines | ||
| 853 | 854 | |
| 854 | 855 | This option was added for bonding version 3.7.0. |
| 855 | 856 | |
| 857 | +lp_interval | |
| 858 | + | |
| 859 | + Specifies the number of seconds between instances where the bonding | |
| 860 | + driver sends learning packets to each slaves peer switch. | |
| 861 | + | |
| 862 | + The valid range is 1 - 0x7fffffff; the default value is 1. This Option | |
| 863 | + has effect only in balance-tlb and balance-alb modes. | |
| 864 | + | |
| 856 | 865 | 3. Configuring Bonding Devices |
| 857 | 866 | ============================== |
| 858 | 867 | |
| @@ -2,21 +2,20 @@ · 1 unmodified line | ||
| 2 | 2 | |
| 3 | 3 | can.txt |
| 4 | 4 | |
| 5 | −Readme file for the Controller Area Network Protocol Family (aka Socket CAN) | |
| 5 | +Readme file for the Controller Area Network Protocol Family (aka SocketCAN) | |
| 6 | 6 | |
| 7 | 7 | This file contains |
| 8 | 8 | |
| 9 | − 1 Overview / What is Socket CAN | |
| 9 | + 1 Overview / What is SocketCAN | |
| 10 | 10 | |
| 11 | 11 | 2 Motivation / Why using the socket API |
| 12 | 12 | |
| 13 | − 3 Socket CAN concept | |
| 13 | + 3 SocketCAN concept | |
| 14 | 14 | 3.1 receive lists |
| 15 | 15 | 3.2 local loopback of sent frames |
| 16 | − 3.3 network security issues (capabilities) | |
| 17 | − 3.4 network problem notifications | |
| 16 | + 3.3 network problem notifications | |
| 18 | 17 | |
| 19 | − 4 How to use Socket CAN | |
| 18 | + 4 How to use SocketCAN | |
| 20 | 19 | 4.1 RAW protocol sockets with can_filters (SOCK_RAW) |
| 21 | 20 | 4.1.1 RAW socket option CAN_RAW_FILTER |
| 22 | 21 | 4.1.2 RAW socket option CAN_RAW_ERR_FILTER |
| @@ -34,7 +33,7 @@ This file contains · 11 unmodified lines | ||
| 34 | 33 | 4.3 connected transport protocols (SOCK_SEQPACKET) |
| 35 | 34 | 4.4 unconnected transport protocols (SOCK_DGRAM) |
| 36 | 35 | |
| 37 | − 5 Socket CAN core module | |
| 36 | + 5 SocketCAN core module | |
| 38 | 37 | 5.1 can.ko module params |
| 39 | 38 | 5.2 procfs content |
| 40 | 39 | 5.3 writing own CAN protocol modules |
| @@ -51,20 +50,20 @@ This file contains · 10 unmodified lines | ||
| 51 | 50 | 6.6 CAN FD (flexible data rate) driver support |
| 52 | 51 | 6.7 supported CAN hardware |
| 53 | 52 | |
| 54 | − 7 Socket CAN resources | |
| 53 | + 7 SocketCAN resources | |
| 55 | 54 | |
| 56 | 55 | 8 Credits |
| 57 | 56 | |
| 58 | 57 | ============================================================================ |
| 59 | 58 | |
| 60 | −1. Overview / What is Socket CAN | |
| 59 | +1. Overview / What is SocketCAN | |
| 61 | 60 | -------------------------------- |
| 62 | 61 | |
| 63 | 62 | The socketcan package is an implementation of CAN protocols |
| 64 | 63 | (Controller Area Network) for Linux. CAN is a networking technology |
| 65 | 64 | which has widespread use in automation, embedded devices, and |
| 66 | 65 | automotive fields. While there have been other CAN implementations |
| 67 | −for Linux based on character devices, Socket CAN uses the Berkeley | |
| 66 | +for Linux based on character devices, SocketCAN uses the Berkeley | |
| 68 | 67 | socket API, the Linux network stack and implements the CAN device |
| 69 | 68 | drivers as network interfaces. The CAN socket API has been designed |
| 70 | 69 | as similar as possible to the TCP/IP protocols to allow programmers, |
| @@ -74,7 +73,7 @@ sockets. · 3 unmodified lines | ||
| 74 | 73 | 2. Motivation / Why using the socket API |
| 75 | 74 | ---------------------------------------- |
| 76 | 75 | |
| 77 | −There have been CAN implementations for Linux before Socket CAN so the | |
| 76 | +There have been CAN implementations for Linux before SocketCAN so the | |
| 78 | 77 | question arises, why we have started another project. Most existing |
| 79 | 78 | implementations come as a device driver for some CAN hardware, they |
| 80 | 79 | are based on character devices and provide comparatively little |
| @@ -89,10 +88,10 @@ the CAN controller requires employment of another device driver and · 8 unmodified lines | ||
| 89 | 88 | often the need for adaption of large parts of the application to the |
| 90 | 89 | new driver's API. |
| 91 | 90 | |
| 92 | −Socket CAN was designed to overcome all of these limitations. A new | |
| 91 | +SocketCAN was designed to overcome all of these limitations. A new | |
| 93 | 92 | protocol family has been implemented which provides a socket interface |
| 94 | 93 | to user space applications and which builds upon the Linux network |
| 95 | −layer, so to use all of the provided queueing functionality. A device | |
| 94 | +layer, enabling use all of the provided queueing functionality. A device | |
| 96 | 95 | driver for CAN controller hardware registers itself with the Linux |
| 97 | 96 | network layer as a network device, so that CAN frames from the |
| 98 | 97 | controller can be passed up to the network layer and on to the CAN |
| @@ -146,15 +145,15 @@ solution for a couple of reasons: · 47 unmodified lines | ||
| 146 | 145 | providing an API for device drivers to register with. However, then |
| 147 | 146 | it would be no more difficult, or may be even easier, to use the |
| 148 | 147 | networking framework provided by the Linux kernel, and this is what |
| 149 | − Socket CAN does. | |
| 148 | + SocketCAN does. | |
| 150 | 149 | |
| 151 | 150 | The use of the networking framework of the Linux kernel is just the |
| 152 | 151 | natural and most appropriate way to implement CAN for Linux. |
| 153 | 152 | |
| 154 | −3. Socket CAN concept | |
| 153 | +3. SocketCAN concept | |
| 155 | 154 | --------------------- |
| 156 | 155 | |
| 157 | − As described in chapter 2 it is the main goal of Socket CAN to | |
| 156 | + As described in chapter 2 it is the main goal of SocketCAN to | |
| 158 | 157 | provide a socket interface to user space applications which builds |
| 159 | 158 | upon the Linux network layer. In contrast to the commonly known |
| 160 | 159 | TCP/IP and ethernet networking, the CAN bus is a broadcast-only(!) |
| @@ -168,11 +167,11 @@ solution for a couple of reasons: · 7 unmodified lines | ||
| 168 | 167 | |
| 169 | 168 | The network transparent access of multiple applications leads to the |
| 170 | 169 | problem that different applications may be interested in the same |
| 171 | − CAN-IDs from the same CAN network interface. The Socket CAN core | |
| 170 | + CAN-IDs from the same CAN network interface. The SocketCAN core | |
| 172 | 171 | module - which implements the protocol family CAN - provides several |
| 173 | 172 | high efficient receive lists for this reason. If e.g. a user space |
| 174 | 173 | application opens a CAN RAW socket, the raw protocol module itself |
| 175 | − requests the (range of) CAN-IDs from the Socket CAN core that are | |
| 174 | + requests the (range of) CAN-IDs from the SocketCAN core that are | |
| 176 | 175 | requested by the user. The subscription and unsubscription of |
| 177 | 176 | CAN-IDs can be done for specific CAN interfaces or for all(!) known |
| 178 | 177 | CAN interfaces with the can_rx_(un)register() functions provided to |
| @@ -217,21 +216,7 @@ solution for a couple of reasons: · 38 unmodified lines | ||
| 217 | 216 | * = you really like to have this when you're running analyser tools |
| 218 | 217 | like 'candump' or 'cansniffer' on the (same) node. |
| 219 | 218 | |
| 220 | − 3.3 network security issues (capabilities) | |
| 221 | − | |
| 222 | − The Controller Area Network is a local field bus transmitting only | |
| 223 | − broadcast messages without any routing and security concepts. | |
| 224 | − In the majority of cases the user application has to deal with | |
| 225 | − raw CAN frames. Therefore it might be reasonable NOT to restrict | |
| 226 | − the CAN access only to the user root, as known from other networks. | |
| 227 | − Since the currently implemented CAN_RAW and CAN_BCM sockets can only | |
| 228 | − send and receive frames to/from CAN interfaces it does not affect | |
| 229 | − security of others networks to allow all users to access the CAN. | |
| 230 | − To enable non-root users to access CAN_RAW and CAN_BCM protocol | |
| 231 | − sockets the Kconfig options CAN_RAW_USER and/or CAN_BCM_USER may be | |
| 232 | − selected at kernel compile time. | |
| 233 | − | |
| 234 | − 3.4 network problem notifications | |
| 219 | + 3.3 network problem notifications | |
| 235 | 220 | |
| 236 | 221 | The use of the CAN bus may lead to several problems on the physical |
| 237 | 222 | and media access control layer. Detecting and logging of these lower |
| @@ -251,11 +236,11 @@ solution for a couple of reasons: · 13 unmodified lines | ||
| 251 | 236 | by default. The format of the CAN error message frame is briefly |
| 252 | 237 | described in the Linux header file "include/linux/can/error.h". |
| 253 | 238 | |
| 254 | −4. How to use Socket CAN | |
| 239 | +4. How to use SocketCAN | |
| 255 | 240 | ------------------------ |
| 256 | 241 | |
| 257 | 242 | Like TCP/IP, you first need to open a socket for communicating over a |
| 258 | − CAN network. Since Socket CAN implements a new protocol family, you | |
| 243 | + CAN network. Since SocketCAN implements a new protocol family, you | |
| 259 | 244 | need to pass PF_CAN as the first argument to the socket(2) system |
| 260 | 245 | call. Currently, there are two CAN protocols to choose from, the raw |
| 261 | 246 | socket protocol and the broadcast manager (BCM). So to open a socket, |
| @@ -286,8 +271,8 @@ solution for a couple of reasons: · 24 unmodified lines | ||
| 286 | 271 | }; |
| 287 | 272 | |
| 288 | 273 | The alignment of the (linear) payload data[] to a 64bit boundary |
| 289 | − allows the user to define own structs and unions to easily access the | |
| 290 | − CAN payload. There is no given byteorder on the CAN bus by | |
| 274 | + allows the user to define their own structs and unions to easily access | |
| 275 | + the CAN payload. There is no given byteorder on the CAN bus by | |
| 291 | 276 | default. A read(2) system call on a CAN_RAW socket transfers a |
| 292 | 277 | struct can_frame to the user space. |
| 293 | 278 | |
| @@ -479,7 +464,7 @@ solution for a couple of reasons: · 185 unmodified lines | ||
| 479 | 464 | |
| 480 | 465 | setsockopt(s, SOL_CAN_RAW, CAN_RAW_FILTER, NULL, 0); |
| 481 | 466 | |
| 482 | − To set the filters to zero filters is quite obsolete as not read | |
| 467 | + To set the filters to zero filters is quite obsolete as to not read | |
| 483 | 468 | data causes the raw socket to discard the received CAN frames. But |
| 484 | 469 | having this 'send only' use-case we may remove the receive list in the |
| 485 | 470 | Kernel to save a little (really a very little!) CPU usage. |
| @@ -814,17 +799,17 @@ solution for a couple of reasons: · 328 unmodified lines | ||
| 814 | 799 | 4.4 unconnected transport protocols (SOCK_DGRAM) |
| 815 | 800 | |
| 816 | 801 | |
| 817 | −5. Socket CAN core module | |
| 802 | +5. SocketCAN core module | |
| 818 | 803 | ------------------------- |
| 819 | 804 | |
| 820 | − The Socket CAN core module implements the protocol family | |
| 805 | + The SocketCAN core module implements the protocol family | |
| 821 | 806 | PF_CAN. CAN protocol modules are loaded by the core module at |
| 822 | 807 | runtime. The core module provides an interface for CAN protocol |
| 823 | 808 | modules to subscribe needed CAN IDs (see chapter 3.1). |
| 824 | 809 | |
| 825 | 810 | 5.1 can.ko module params |
| 826 | 811 | |
| 827 | − - stats_timer: To calculate the Socket CAN core statistics | |
| 812 | + - stats_timer: To calculate the SocketCAN core statistics | |
| 828 | 813 | (e.g. current/maximum frames per second) this 1 second timer is |
| 829 | 814 | invoked at can.ko module start time by default. This timer can be |
| 830 | 815 | disabled by using stattimer=0 on the module commandline. |
| @@ -833,7 +818,7 @@ solution for a couple of reasons: · 2 unmodified lines | ||
| 833 | 818 | |
| 834 | 819 | 5.2 procfs content |
| 835 | 820 | |
| 836 | − As described in chapter 3.1 the Socket CAN core uses several filter | |
| 821 | + As described in chapter 3.1 the SocketCAN core uses several filter | |
| 837 | 822 | lists to deliver received CAN frames to CAN protocol modules. These |
| 838 | 823 | receive lists, their filters and the count of filter matches can be |
| 839 | 824 | checked in the appropriate receive list. All entries contain the |
| @@ -860,15 +845,15 @@ solution for a couple of reasons: · 20 unmodified lines | ||
| 860 | 845 | |
| 861 | 846 | Additional procfs files in /proc/net/can |
| 862 | 847 | |
| 863 | − stats - Socket CAN core statistics (rx/tx frames, match ratios, ...) | |
| 848 | + stats - SocketCAN core statistics (rx/tx frames, match ratios, ...) | |
| 864 | 849 | reset_stats - manual statistic reset |
| 865 | − version - prints the Socket CAN core version and the ABI version | |
| 850 | + version - prints the SocketCAN core version and the ABI version | |
| 866 | 851 | |
| 867 | 852 | 5.3 writing own CAN protocol modules |
| 868 | 853 | |
| 869 | 854 | To implement a new protocol in the protocol family PF_CAN a new |
| 870 | 855 | protocol has to be defined in include/linux/can.h . |
| 871 | − The prototypes and definitions to use the Socket CAN core can be | |
| 856 | + The prototypes and definitions to use the SocketCAN core can be | |
| 872 | 857 | accessed by including include/linux/can/core.h . |
| 873 | 858 | In addition to functions that register the CAN protocol and the |
| 874 | 859 | CAN device notifier chain there are functions to subscribe CAN |
| @@ -1105,7 +1090,7 @@ solution for a couple of reasons: · 230 unmodified lines | ||
| 1105 | 1090 | |
| 1106 | 1091 | $ ip link set canX up type can bitrate 125000 |
| 1107 | 1092 | |
| 1108 | − A device may enter the "bus-off" state if too much errors occurred on | |
| 1093 | + A device may enter the "bus-off" state if too many errors occurred on | |
| 1109 | 1094 | the CAN bus. Then no more messages are received or sent. An automatic |
| 1110 | 1095 | bus-off recovery can be enabled by setting the "restart-ms" to a |
| 1111 | 1096 | non-zero value, e.g.: |
| @@ -1125,7 +1110,7 @@ solution for a couple of reasons: · 13 unmodified lines | ||
| 1125 | 1110 | |
| 1126 | 1111 | CAN FD capable CAN controllers support two different bitrates for the |
| 1127 | 1112 | arbitration phase and the payload phase of the CAN FD frame. Therefore a |
| 1128 | − second bittiming has to be specified in order to enable the CAN FD bitrate. | |
| 1113 | + second bit timing has to be specified in order to enable the CAN FD bitrate. | |
| 1129 | 1114 | |
| 1130 | 1115 | Additionally CAN FD capable CAN controllers support up to 64 bytes of |
| 1131 | 1116 | payload. The representation of this length in can_frame.can_dlc and |
| @@ -1150,21 +1135,16 @@ solution for a couple of reasons: · 18 unmodified lines | ||
| 1150 | 1135 | 6.7 Supported CAN hardware |
| 1151 | 1136 | |
| 1152 | 1137 | Please check the "Kconfig" file in "drivers/net/can" to get an actual |
| 1153 | − list of the support CAN hardware. On the Socket CAN project website | |
| 1138 | + list of the support CAN hardware. On the SocketCAN project website | |
| 1154 | 1139 | (see chapter 7) there might be further drivers available, also for |
| 1155 | 1140 | older kernel versions. |
| 1156 | 1141 | |
| 1157 | −7. Socket CAN resources | |
| 1142 | +7. SocketCAN resources | |
| 1158 | 1143 | ----------------------- |
| 1159 | 1144 | |
| 1160 | − You can find further resources for Socket CAN like user space tools, | |
| 1161 | − support for old kernel versions, more drivers, mailing lists, etc. | |
| 1162 | − at the BerliOS OSS project website for Socket CAN: | |
| 1163 | − | |
| 1164 | − http://developer.berlios.de/projects/socketcan | |
| 1165 | − | |
| 1166 | − If you have questions, bug fixes, etc., don't hesitate to post them to | |
| 1167 | − the Socketcan-Users mailing list. But please search the archives first. | |
| 1145 | + The Linux CAN / SocketCAN project ressources (project site / mailing list) | |
| 1146 | + are referenced in the MAINTAINERS file in the Linux source tree. | |
| 1147 | + Search for CAN NETWORK [LAYERS|DRIVERS]. | |
| 1168 | 1148 | |
| 1169 | 1149 | 8. Credits |
| 1170 | 1150 | ---------- |
| @@ -1,49 +1,563 @@ | ||
| 1 | −filter.txt: Linux Socket Filtering | |
| 2 | −Written by: Jay Schulist <jschlst@samba.org> | |
| 1 | +Linux Socket Filtering aka Berkeley Packet Filter (BPF) | |
| 2 | +======================================================= | |
| 3 | 3 | |
| 4 | 4 | Introduction |
| 5 | −============ | |
| 6 | − | |
| 7 | − Linux Socket Filtering is derived from the Berkeley | |
| 8 | −Packet Filter. There are some distinct differences between | |
| 9 | −the BSD and Linux Kernel Filtering. | |
| 10 | − | |
| 11 | −Linux Socket Filtering (LSF) allows a user-space program to | |
| 12 | −attach a filter onto any socket and allow or disallow certain | |
| 13 | −types of data to come through the socket. LSF follows exactly | |
| 14 | −the same filter code structure as the BSD Berkeley Packet Filter | |
| 15 | −(BPF), so referring to the BSD bpf.4 manpage is very helpful in | |
| 16 | −creating filters. | |
| 17 | − | |
| 18 | −LSF is much simpler than BPF. One does not have to worry about | |
| 19 | −devices or anything like that. You simply create your filter | |
| 20 | −code, send it to the kernel via the SO_ATTACH_FILTER option and | |
| 21 | −if your filter code passes the kernel check on it, you then | |
| 22 | −immediately begin filtering data on that socket. | |
| 23 | − | |
| 24 | −You can also detach filters from your socket via the | |
| 25 | −SO_DETACH_FILTER option. This will probably not be used much | |
| 26 | −since when you close a socket that has a filter on it the | |
| 27 | −filter is automagically removed. The other less common case | |
| 28 | −may be adding a different filter on the same socket where you had another | |
| 29 | −filter that is still running: the kernel takes care of removing | |
| 30 | −the old one and placing your new one in its place, assuming your | |
| 31 | −filter has passed the checks, otherwise if it fails the old filter | |
| 32 | −will remain on that socket. | |
| 33 | − | |
| 34 | −SO_LOCK_FILTER option allows to lock the filter attached to a | |
| 35 | −socket. Once set, a filter cannot be removed or changed. This allows | |
| 36 | −one process to setup a socket, attach a filter, lock it then drop | |
| 37 | −privileges and be assured that the filter will be kept until the | |
| 38 | −socket is closed. | |
| 39 | − | |
| 40 | −Examples | |
| 41 | −======== | |
| 42 | − | |
| 43 | −Ioctls- | |
| 44 | −setsockopt(sockfd, SOL_SOCKET, SO_ATTACH_FILTER, &Filter, sizeof(Filter)); | |
| 45 | −setsockopt(sockfd, SOL_SOCKET, SO_DETACH_FILTER, &value, sizeof(value)); | |
| 46 | −setsockopt(sockfd, SOL_SOCKET, SO_LOCK_FILTER, &value, sizeof(value)); | |
| 47 | − | |
| 48 | −See the BSD bpf.4 manpage and the BSD Packet Filter paper written by | |
| 49 | −Steven McCanne and Van Jacobson of Lawrence Berkeley Laboratory. | |
| 5 | +------------ | |
| 6 | + | |
| 7 | +Linux Socket Filtering (LSF) is derived from the Berkeley Packet Filter. | |
| 8 | +Though there are some distinct differences between the BSD and Linux | |
| 9 | +Kernel filtering, but when we speak of BPF or LSF in Linux context, we | |
| 10 | +mean the very same mechanism of filtering in the Linux kernel. | |
| 11 | + | |
| 12 | +BPF allows a user-space program to attach a filter onto any socket and | |
| 13 | +allow or disallow certain types of data to come through the socket. LSF | |
| 14 | +follows exactly the same filter code structure as BSD's BPF, so referring | |
| 15 | +to the BSD bpf.4 manpage is very helpful in creating filters. | |
| 16 | + | |
| 17 | +On Linux, BPF is much simpler than on BSD. One does not have to worry | |
| 18 | +about devices or anything like that. You simply create your filter code, | |
| 19 | +send it to the kernel via the SO_ATTACH_FILTER option and if your filter | |
| 20 | +code passes the kernel check on it, you then immediately begin filtering | |
| 21 | +data on that socket. | |
| 22 | + | |
| 23 | +You can also detach filters from your socket via the SO_DETACH_FILTER | |
| 24 | +option. This will probably not be used much since when you close a socket | |
| 25 | +that has a filter on it the filter is automagically removed. The other | |
| 26 | +less common case may be adding a different filter on the same socket where | |
| 27 | +you had another filter that is still running: the kernel takes care of | |
| 28 | +removing the old one and placing your new one in its place, assuming your | |
| 29 | +filter has passed the checks, otherwise if it fails the old filter will | |
| 30 | +remain on that socket. | |
| 31 | + | |
| 32 | +SO_LOCK_FILTER option allows to lock the filter attached to a socket. Once | |
| 33 | +set, a filter cannot be removed or changed. This allows one process to | |
| 34 | +setup a socket, attach a filter, lock it then drop privileges and be | |
| 35 | +assured that the filter will be kept until the socket is closed. | |
| 36 | + | |
| 37 | +The biggest user of this construct might be libpcap. Issuing a high-level | |
| 38 | +filter command like `tcpdump -i em1 port 22` passes through the libpcap | |
| 39 | +internal compiler that generates a structure that can eventually be loaded | |
| 40 | +via SO_ATTACH_FILTER to the kernel. `tcpdump -i em1 port 22 -ddd` | |
| 41 | +displays what is being placed into this structure. | |
| 42 | + | |
| 43 | +Although we were only speaking about sockets here, BPF in Linux is used | |
| 44 | +in many more places. There's xt_bpf for netfilter, cls_bpf in the kernel | |
| 45 | +qdisc layer, SECCOMP-BPF (SECure COMPuting [1]), and lots of other places | |
| 46 | +such as team driver, PTP code, etc where BPF is being used. | |
| 47 | + | |
| 48 | + [1] Documentation/prctl/seccomp_filter.txt | |
| 49 | + | |
| 50 | +Original BPF paper: | |
| 51 | + | |
| 52 | +Steven McCanne and Van Jacobson. 1993. The BSD packet filter: a new | |
| 53 | +architecture for user-level packet capture. In Proceedings of the | |
| 54 | +USENIX Winter 1993 Conference Proceedings on USENIX Winter 1993 | |
| 55 | +Conference Proceedings (USENIX'93). USENIX Association, Berkeley, | |
| 56 | +CA, USA, 2-2. [http://www.tcpdump.org/papers/bpf-usenix93.pdf] | |
| 57 | + | |
| 58 | +Structure | |
| 59 | +--------- | |
| 60 | + | |
| 61 | +User space applications include <linux/filter.h> which contains the | |
| 62 | +following relevant structures: | |
| 63 | + | |
| 64 | +struct sock_filter { /* Filter block */ | |
| 65 | + __u16 code; /* Actual filter code */ | |
| 66 | + __u8 jt; /* Jump true */ | |
| 67 | + __u8 jf; /* Jump false */ | |
| 68 | + __u32 k; /* Generic multiuse field */ | |
| 69 | +}; | |
| 70 | + | |
| 71 | +Such a structure is assembled as an array of 4-tuples, that contains | |
| 72 | +a code, jt, jf and k value. jt and jf are jump offsets and k a generic | |
| 73 | +value to be used for a provided code. | |
| 74 | + | |
| 75 | +struct sock_fprog { /* Required for SO_ATTACH_FILTER. */ | |
| 76 | + unsigned short len; /* Number of filter blocks */ | |
| 77 | + struct sock_filter __user *filter; | |
| 78 | +}; | |
| 79 | + | |
| 80 | +For socket filtering, a pointer to this structure (as shown in | |
| 81 | +follow-up example) is being passed to the kernel through setsockopt(2). | |
| 82 | + | |
| 83 | +Example | |
| 84 | +------- | |
| 85 | + | |
| 86 | +#include <sys/socket.h> | |
| 87 | +#include <sys/types.h> | |
| 88 | +#include <arpa/inet.h> | |
| 89 | +#include <linux/if_ether.h> | |
| 90 | +/* ... */ | |
| 91 | + | |
| 92 | +/* From the example above: tcpdump -i em1 port 22 -dd */ | |
| 93 | +struct sock_filter code[] = { | |
| 94 | + { 0x28, 0, 0, 0x0000000c }, | |
| 95 | + { 0x15, 0, 8, 0x000086dd }, | |
| 96 | + { 0x30, 0, 0, 0x00000014 }, | |
| 97 | + { 0x15, 2, 0, 0x00000084 }, | |
| 98 | + { 0x15, 1, 0, 0x00000006 }, | |
| 99 | + { 0x15, 0, 17, 0x00000011 }, | |
| 100 | + { 0x28, 0, 0, 0x00000036 }, | |
| 101 | + { 0x15, 14, 0, 0x00000016 }, | |
| 102 | + { 0x28, 0, 0, 0x00000038 }, | |
| 103 | + { 0x15, 12, 13, 0x00000016 }, | |
| 104 | + { 0x15, 0, 12, 0x00000800 }, | |
| 105 | + { 0x30, 0, 0, 0x00000017 }, | |
| 106 | + { 0x15, 2, 0, 0x00000084 }, | |
| 107 | + { 0x15, 1, 0, 0x00000006 }, | |
| 108 | + { 0x15, 0, 8, 0x00000011 }, | |
| 109 | + { 0x28, 0, 0, 0x00000014 }, | |
| 110 | + { 0x45, 6, 0, 0x00001fff }, | |
| 111 | + { 0xb1, 0, 0, 0x0000000e }, | |
| 112 | + { 0x48, 0, 0, 0x0000000e }, | |
| 113 | + { 0x15, 2, 0, 0x00000016 }, | |
| 114 | + { 0x48, 0, 0, 0x00000010 }, | |
| 115 | + { 0x15, 0, 1, 0x00000016 }, | |
| 116 | + { 0x06, 0, 0, 0x0000ffff }, | |
| 117 | + { 0x06, 0, 0, 0x00000000 }, | |
| 118 | +}; | |
| 119 | + | |
| 120 | +struct sock_fprog bpf = { | |
| 121 | + .len = ARRAY_SIZE(code), | |
| 122 | + .filter = code, | |
| 123 | +}; | |
| 124 | + | |
| 125 | +sock = socket(PF_PACKET, SOCK_RAW, htons(ETH_P_ALL)); | |
| 126 | +if (sock < 0) | |
| 127 | + /* ... bail out ... */ | |
| 128 | + | |
| 129 | +ret = setsockopt(sock, SOL_SOCKET, SO_ATTACH_FILTER, &bpf, sizeof(bpf)); | |
| 130 | +if (ret < 0) | |
| 131 | + /* ... bail out ... */ | |
| 132 | + | |
| 133 | +/* ... */ | |
| 134 | +close(sock); | |
| 135 | + | |
| 136 | +The above example code attaches a socket filter for a PF_PACKET socket | |
| 137 | +in order to let all IPv4/IPv6 packets with port 22 pass. The rest will | |
| 138 | +be dropped for this socket. | |
| 139 | + | |
| 140 | +The setsockopt(2) call to SO_DETACH_FILTER doesn't need any arguments | |
| 141 | +and SO_LOCK_FILTER for preventing the filter to be detached, takes an | |
| 142 | +integer value with 0 or 1. | |
| 143 | + | |
| 144 | +Note that socket filters are not restricted to PF_PACKET sockets only, | |
| 145 | +but can also be used on other socket families. | |
| 146 | + | |
| 147 | +Summary of system calls: | |
| 148 | + | |
| 149 | + * setsockopt(sockfd, SOL_SOCKET, SO_ATTACH_FILTER, &val, sizeof(val)); | |
| 150 | + * setsockopt(sockfd, SOL_SOCKET, SO_DETACH_FILTER, &val, sizeof(val)); | |
| 151 | + * setsockopt(sockfd, SOL_SOCKET, SO_LOCK_FILTER, &val, sizeof(val)); | |
| 152 | + | |
| 153 | +Normally, most use cases for socket filtering on packet sockets will be | |
| 154 | +covered by libpcap in high-level syntax, so as an application developer | |
| 155 | +you should stick to that. libpcap wraps its own layer around all that. | |
| 156 | + | |
| 157 | +Unless i) using/linking to libpcap is not an option, ii) the required BPF | |
| 158 | +filters use Linux extensions that are not supported by libpcap's compiler, | |
| 159 | +iii) a filter might be more complex and not cleanly implementable with | |
| 160 | +libpcap's compiler, or iv) particular filter codes should be optimized | |
| 161 | +differently than libpcap's internal compiler does; then in such cases | |
| 162 | +writing such a filter "by hand" can be of an alternative. For example, | |
| 163 | +xt_bpf and cls_bpf users might have requirements that could result in | |
| 164 | +more complex filter code, or one that cannot be expressed with libpcap | |
| 165 | +(e.g. different return codes for various code paths). Moreover, BPF JIT | |
| 166 | +implementors may wish to manually write test cases and thus need low-level | |
| 167 | +access to BPF code as well. | |
| 168 | + | |
| 169 | +BPF engine and instruction set | |
| 170 | +------------------------------ | |
| 171 | + | |
| 172 | +Under tools/net/ there's a small helper tool called bpf_asm which can | |
| 173 | +be used to write low-level filters for example scenarios mentioned in the | |
| 174 | +previous section. Asm-like syntax mentioned here has been implemented in | |
| 175 | +bpf_asm and will be used for further explanations (instead of dealing with | |
| 176 | +less readable opcodes directly, principles are the same). The syntax is | |
| 177 | +closely modelled after Steven McCanne's and Van Jacobson's BPF paper. | |
| 178 | + | |
| 179 | +The BPF architecture consists of the following basic elements: | |
| 180 | + | |
| 181 | + Element Description | |
| 182 | + | |
| 183 | + A 32 bit wide accumulator | |
| 184 | + X 32 bit wide X register | |
| 185 | + M[] 16 x 32 bit wide misc registers aka "scratch memory | |
| 186 | + store", addressable from 0 to 15 | |
| 187 | + | |
| 188 | +A program, that is translated by bpf_asm into "opcodes" is an array that | |
| 189 | +consists of the following elements (as already mentioned): | |
| 190 | + | |
| 191 | + op:16, jt:8, jf:8, k:32 | |
| 192 | + | |
| 193 | +The element op is a 16 bit wide opcode that has a particular instruction | |
| 194 | +encoded. jt and jf are two 8 bit wide jump targets, one for condition | |
| 195 | +"jump if true", the other one "jump if false". Eventually, element k | |
| 196 | +contains a miscellaneous argument that can be interpreted in different | |
| 197 | +ways depending on the given instruction in op. | |
| 198 | + | |
| 199 | +The instruction set consists of load, store, branch, alu, miscellaneous | |
| 200 | +and return instructions that are also represented in bpf_asm syntax. This | |
| 201 | +table lists all bpf_asm instructions available resp. what their underlying | |
| 202 | +opcodes as defined in linux/filter.h stand for: | |
| 203 | + | |
| 204 | + Instruction Addressing mode Description | |
| 205 | + | |
| 206 | + ld 1, 2, 3, 4, 10 Load word into A | |
| 207 | + ldi 4 Load word into A | |
| 208 | + ldh 1, 2 Load half-word into A | |
| 209 | + ldb 1, 2 Load byte into A | |
| 210 | + ldx 3, 4, 5, 10 Load word into X | |
| 211 | + ldxi 4 Load word into X | |
| 212 | + ldxb 5 Load byte into X | |
| 213 | + | |
| 214 | + st 3 Store A into M[] | |
| 215 | + stx 3 Store X into M[] | |
| 216 | + | |
| 217 | + jmp 6 Jump to label | |
| 218 | + ja 6 Jump to label | |
| 219 | + jeq 7, 8 Jump on k == A | |
| 220 | + jneq 8 Jump on k != A | |
| 221 | + jne 8 Jump on k != A | |
| 222 | + jlt 8 Jump on k < A | |
| 223 | + jle 8 Jump on k <= A | |
| 224 | + jgt 7, 8 Jump on k > A | |
| 225 | + jge 7, 8 Jump on k >= A | |
| 226 | + jset 7, 8 Jump on k & A | |
| 227 | + | |
| 228 | + add 0, 4 A + <x> | |
| 229 | + sub 0, 4 A - <x> | |
| 230 | + mul 0, 4 A * <x> | |
| 231 | + div 0, 4 A / <x> | |
| 232 | + mod 0, 4 A % <x> | |
| 233 | + neg 0, 4 !A | |
| 234 | + and 0, 4 A & <x> | |
| 235 | + or 0, 4 A | <x> | |
| 236 | + xor 0, 4 A ^ <x> | |
| 237 | + lsh 0, 4 A << <x> | |
| 238 | + rsh 0, 4 A >> <x> | |
| 239 | + | |
| 240 | + tax Copy A into X | |
| 241 | + txa Copy X into A | |
| 242 | + | |
| 243 | + ret 4, 9 Return | |
| 244 | + | |
| 245 | +The next table shows addressing formats from the 2nd column: | |
| 246 | + | |
| 247 | + Addressing mode Syntax Description | |
| 248 | + | |
| 249 | + 0 x/%x Register X | |
| 250 | + 1 [k] BHW at byte offset k in the packet | |
| 251 | + 2 [x + k] BHW at the offset X + k in the packet | |
| 252 | + 3 M[k] Word at offset k in M[] | |
| 253 | + 4 #k Literal value stored in k | |
| 254 | + 5 4*([k]&0xf) Lower nibble * 4 at byte offset k in the packet | |
| 255 | + 6 L Jump label L | |
| 256 | + 7 #k,Lt,Lf Jump to Lt if true, otherwise jump to Lf | |
| 257 | + 8 #k,Lt Jump to Lt if predicate is true | |
| 258 | + 9 a/%a Accumulator A | |
| 259 | + 10 extension BPF extension | |
| 260 | + | |
| 261 | +The Linux kernel also has a couple of BPF extensions that are used along | |
| 262 | +with the class of load instructions by "overloading" the k argument with | |
| 263 | +a negative offset + a particular extension offset. The result of such BPF | |
| 264 | +extensions are loaded into A. | |
| 265 | + | |
| 266 | +Possible BPF extensions are shown in the following table: | |
| 267 | + | |
| 268 | + Extension Description | |
| 269 | + | |
| 270 | + len skb->len | |
| 271 | + proto skb->protocol | |
| 272 | + type skb->pkt_type | |
| 273 | + poff Payload start offset | |
| 274 | + ifidx skb->dev->ifindex | |
| 275 | + nla Netlink attribute of type X with offset A | |
| 276 | + nlan Nested Netlink attribute of type X with offset A | |
| 277 | + mark skb->mark | |
| 278 | + queue skb->queue_mapping | |
| 279 | + hatype skb->dev->type | |
| 280 | + rxhash skb->rxhash | |
| 281 | + cpu raw_smp_processor_id() | |
| 282 | + vlan_tci vlan_tx_tag_get(skb) | |
| 283 | + vlan_pr vlan_tx_tag_present(skb) | |
| 284 | + | |
| 285 | +These extensions can also be prefixed with '#'. | |
| 286 | +Examples for low-level BPF: | |
| 287 | + | |
| 288 | +** ARP packets: | |
| 289 | + | |
| 290 | + ldh [12] | |
| 291 | + jne #0x806, drop | |
| 292 | + ret #-1 | |
| 293 | + drop: ret #0 | |
| 294 | + | |
| 295 | +** IPv4 TCP packets: | |
| 296 | + | |
| 297 | + ldh [12] | |
| 298 | + jne #0x800, drop | |
| 299 | + ldb [23] | |
| 300 | + jneq #6, drop | |
| 301 | + ret #-1 | |
| 302 | + drop: ret #0 | |
| 303 | + | |
| 304 | +** (Accelerated) VLAN w/ id 10: | |
| 305 | + | |
| 306 | + ld vlan_tci | |
| 307 | + jneq #10, drop | |
| 308 | + ret #-1 | |
| 309 | + drop: ret #0 | |
| 310 | + | |
| 311 | +** SECCOMP filter example: | |
| 312 | + | |
| 313 | + ld [4] /* offsetof(struct seccomp_data, arch) */ | |
| 314 | + jne #0xc000003e, bad /* AUDIT_ARCH_X86_64 */ | |
| 315 | + ld [0] /* offsetof(struct seccomp_data, nr) */ | |
| 316 | + jeq #15, good /* __NR_rt_sigreturn */ | |
| 317 | + jeq #231, good /* __NR_exit_group */ | |
| 318 | + jeq #60, good /* __NR_exit */ | |
| 319 | + jeq #0, good /* __NR_read */ | |
| 320 | + jeq #1, good /* __NR_write */ | |
| 321 | + jeq #5, good /* __NR_fstat */ | |
| 322 | + jeq #9, good /* __NR_mmap */ | |
| 323 | + jeq #14, good /* __NR_rt_sigprocmask */ | |
| 324 | + jeq #13, good /* __NR_rt_sigaction */ | |
| 325 | + jeq #35, good /* __NR_nanosleep */ | |
| 326 | + bad: ret #0 /* SECCOMP_RET_KILL */ | |
| 327 | + good: ret #0x7fff0000 /* SECCOMP_RET_ALLOW */ | |
| 328 | + | |
| 329 | +The above example code can be placed into a file (here called "foo"), and | |
| 330 | +then be passed to the bpf_asm tool for generating opcodes, output that xt_bpf | |
| 331 | +and cls_bpf understands and can directly be loaded with. Example with above | |
| 332 | +ARP code: | |
| 333 | + | |
| 334 | +$ ./bpf_asm foo | |
| 335 | +4,40 0 0 12,21 0 1 2054,6 0 0 4294967295,6 0 0 0, | |
| 336 | + | |
| 337 | +In copy and paste C-like output: | |
| 338 | + | |
| 339 | +$ ./bpf_asm -c foo | |
| 340 | +{ 0x28, 0, 0, 0x0000000c }, | |
| 341 | +{ 0x15, 0, 1, 0x00000806 }, | |
| 342 | +{ 0x06, 0, 0, 0xffffffff }, | |
| 343 | +{ 0x06, 0, 0, 0000000000 }, | |
| 344 | + | |
| 345 | +In particular, as usage with xt_bpf or cls_bpf can result in more complex BPF | |
| 346 | +filters that might not be obvious at first, it's good to test filters before | |
| 347 | +attaching to a live system. For that purpose, there's a small tool called | |
| 348 | +bpf_dbg under tools/net/ in the kernel source directory. This debugger allows | |
| 349 | +for testing BPF filters against given pcap files, single stepping through the | |
| 350 | +BPF code on the pcap's packets and to do BPF machine register dumps. | |
| 351 | + | |
| 352 | +Starting bpf_dbg is trivial and just requires issuing: | |
| 353 | + | |
| 354 | +# ./bpf_dbg | |
| 355 | + | |
| 356 | +In case input and output do not equal stdin/stdout, bpf_dbg takes an | |
| 357 | +alternative stdin source as a first argument, and an alternative stdout | |
| 358 | +sink as a second one, e.g. `./bpf_dbg test_in.txt test_out.txt`. | |
| 359 | + | |
| 360 | +Other than that, a particular libreadline configuration can be set via | |
| 361 | +file "~/.bpf_dbg_init" and the command history is stored in the file | |
| 362 | +"~/.bpf_dbg_history". | |
| 363 | + | |
| 364 | +Interaction in bpf_dbg happens through a shell that also has auto-completion | |
| 365 | +support (follow-up example commands starting with '>' denote bpf_dbg shell). | |
| 366 | +The usual workflow would be to ... | |
| 367 | + | |
| 368 | +> load bpf 6,40 0 0 12,21 0 3 2048,48 0 0 23,21 0 1 1,6 0 0 65535,6 0 0 0 | |
| 369 | + Loads a BPF filter from standard output of bpf_asm, or transformed via | |
| 370 | + e.g. `tcpdump -iem1 -ddd port 22 | tr '\n' ','`. Note that for JIT | |
| 371 | + debugging (next section), this command creates a temporary socket and | |
| 372 | + loads the BPF code into the kernel. Thus, this will also be useful for | |
| 373 | + JIT developers. | |
| 374 | + | |
| 375 | +> load pcap foo.pcap | |
| 376 | + Loads standard tcpdump pcap file. | |
| 377 | + | |
| 378 | +> run [<n>] | |
| 379 | +bpf passes:1 fails:9 | |
| 380 | + Runs through all packets from a pcap to account how many passes and fails | |
| 381 | + the filter will generate. A limit of packets to traverse can be given. | |
| 382 | + | |
| 383 | +> disassemble | |
| 384 | +l0: ldh [12] | |
| 385 | +l1: jeq #0x800, l2, l5 | |
| 386 | +l2: ldb [23] | |
| 387 | +l3: jeq #0x1, l4, l5 | |
| 388 | +l4: ret #0xffff | |
| 389 | +l5: ret #0 | |
| 390 | + Prints out BPF code disassembly. | |
| 391 | + | |
| 392 | +> dump | |
| 393 | +/* { op, jt, jf, k }, */ | |
| 394 | +{ 0x28, 0, 0, 0x0000000c }, | |
| 395 | +{ 0x15, 0, 3, 0x00000800 }, | |
| 396 | +{ 0x30, 0, 0, 0x00000017 }, | |
| 397 | +{ 0x15, 0, 1, 0x00000001 }, | |
| 398 | +{ 0x06, 0, 0, 0x0000ffff }, | |
| 399 | +{ 0x06, 0, 0, 0000000000 }, | |
| 400 | + Prints out C-style BPF code dump. | |
| 401 | + | |
| 402 | +> breakpoint 0 | |
| 403 | +breakpoint at: l0: ldh [12] | |
| 404 | +> breakpoint 1 | |
| 405 | +breakpoint at: l1: jeq #0x800, l2, l5 | |
| 406 | + ... | |
| 407 | + Sets breakpoints at particular BPF instructions. Issuing a `run` command | |
| 408 | + will walk through the pcap file continuing from the current packet and | |
| 409 | + break when a breakpoint is being hit (another `run` will continue from | |
| 410 | + the currently active breakpoint executing next instructions): | |
| 411 | + | |
| 412 | + > run | |
| 413 | + -- register dump -- | |
| 414 | + pc: [0] <-- program counter | |
| 415 | + code: [40] jt[0] jf[0] k[12] <-- plain BPF code of current instruction | |
| 416 | + curr: l0: ldh [12] <-- disassembly of current instruction | |
| 417 | + A: [00000000][0] <-- content of A (hex, decimal) | |
| 418 | + X: [00000000][0] <-- content of X (hex, decimal) | |
| 419 | + M[0,15]: [00000000][0] <-- folded content of M (hex, decimal) | |
| 420 | + -- packet dump -- <-- Current packet from pcap (hex) | |
| 421 | + len: 42 | |
| 422 | + 0: 00 19 cb 55 55 a4 00 14 a4 43 78 69 08 06 00 01 | |
| 423 | + 16: 08 00 06 04 00 01 00 14 a4 43 78 69 0a 3b 01 26 | |
| 424 | + 32: 00 00 00 00 00 00 0a 3b 01 01 | |
| 425 | + (breakpoint) | |
| 426 | + > | |
| 427 | + | |
| 428 | +> breakpoint | |
| 429 | +breakpoints: 0 1 | |
| 430 | + Prints currently set breakpoints. | |
| 431 | + | |
| 432 | +> step [-<n>, +<n>] | |
| 433 | + Performs single stepping through the BPF program from the current pc | |
| 434 | + offset. Thus, on each step invocation, above register dump is issued. | |
| 435 | + This can go forwards and backwards in time, a plain `step` will break | |
| 436 | + on the next BPF instruction, thus +1. (No `run` needs to be issued here.) | |
| 437 | + | |
| 438 | +> select <n> | |
| 439 | + Selects a given packet from the pcap file to continue from. Thus, on | |
| 440 | + the next `run` or `step`, the BPF program is being evaluated against | |
| 441 | + the user pre-selected packet. Numbering starts just as in Wireshark | |
| 442 | + with index 1. | |
| 443 | + | |
| 444 | +> quit | |
| 445 | +# | |
| 446 | + Exits bpf_dbg. | |
| 447 | + | |
| 448 | +JIT compiler | |
| 449 | +------------ | |
| 450 | + | |
| 451 | +The Linux kernel has a built-in BPF JIT compiler for x86_64, SPARC, PowerPC, | |
| 452 | +ARM and s390 and can be enabled through CONFIG_BPF_JIT. The JIT compiler is | |
| 453 | +transparently invoked for each attached filter from user space or for internal | |
| 454 | +kernel users if it has been previously enabled by root: | |
| 455 | + | |
| 456 | + echo 1 > /proc/sys/net/core/bpf_jit_enable | |
| 457 | + | |
| 458 | +For JIT developers, doing audits etc, each compile run can output the generated | |
| 459 | +opcode image into the kernel log via: | |
| 460 | + | |
| 461 | + echo 2 > /proc/sys/net/core/bpf_jit_enable | |
| 462 | + | |
| 463 | +Example output from dmesg: | |
| 464 | + | |
| 465 | +[ 3389.935842] flen=6 proglen=70 pass=3 image=ffffffffa0069c8f | |
| 466 | +[ 3389.935847] JIT code: 00000000: 55 48 89 e5 48 83 ec 60 48 89 5d f8 44 8b 4f 68 | |
| 467 | +[ 3389.935849] JIT code: 00000010: 44 2b 4f 6c 4c 8b 87 d8 00 00 00 be 0c 00 00 00 | |
| 468 | +[ 3389.935850] JIT code: 00000020: e8 1d 94 ff e0 3d 00 08 00 00 75 16 be 17 00 00 | |
| 469 | +[ 3389.935851] JIT code: 00000030: 00 e8 28 94 ff e0 83 f8 01 75 07 b8 ff ff 00 00 | |
| 470 | +[ 3389.935852] JIT code: 00000040: eb 02 31 c0 c9 c3 | |
| 471 | + | |
| 472 | +In the kernel source tree under tools/net/, there's bpf_jit_disasm for | |
| 473 | +generating disassembly out of the kernel log's hexdump: | |
| 474 | + | |
| 475 | +# ./bpf_jit_disasm | |
| 476 | +70 bytes emitted from JIT compiler (pass:3, flen:6) | |
| 477 | +ffffffffa0069c8f + <x>: | |
| 478 | + 0: push %rbp | |
| 479 | + 1: mov %rsp,%rbp | |
| 480 | + 4: sub $0x60,%rsp | |
| 481 | + 8: mov %rbx,-0x8(%rbp) | |
| 482 | + c: mov 0x68(%rdi),%r9d | |
| 483 | + 10: sub 0x6c(%rdi),%r9d | |
| 484 | + 14: mov 0xd8(%rdi),%r8 | |
| 485 | + 1b: mov $0xc,%esi | |
| 486 | + 20: callq 0xffffffffe0ff9442 | |
| 487 | + 25: cmp $0x800,%eax | |
| 488 | + 2a: jne 0x0000000000000042 | |
| 489 | + 2c: mov $0x17,%esi | |
| 490 | + 31: callq 0xffffffffe0ff945e | |
| 491 | + 36: cmp $0x1,%eax | |
| 492 | + 39: jne 0x0000000000000042 | |
| 493 | + 3b: mov $0xffff,%eax | |
| 494 | + 40: jmp 0x0000000000000044 | |
| 495 | + 42: xor %eax,%eax | |
| 496 | + 44: leaveq | |
| 497 | + 45: retq | |
| 498 | + | |
| 499 | +Issuing option `-o` will "annotate" opcodes to resulting assembler | |
| 500 | +instructions, which can be very useful for JIT developers: | |
| 501 | + | |
| 502 | +# ./bpf_jit_disasm -o | |
| 503 | +70 bytes emitted from JIT compiler (pass:3, flen:6) | |
| 504 | +ffffffffa0069c8f + <x>: | |
| 505 | + 0: push %rbp | |
| 506 | + 55 | |
| 507 | + 1: mov %rsp,%rbp | |
| 508 | + 48 89 e5 | |
| 509 | + 4: sub $0x60,%rsp | |
| 510 | + 48 83 ec 60 | |
| 511 | + 8: mov %rbx,-0x8(%rbp) | |
| 512 | + 48 89 5d f8 | |
| 513 | + c: mov 0x68(%rdi),%r9d | |
| 514 | + 44 8b 4f 68 | |
| 515 | + 10: sub 0x6c(%rdi),%r9d | |
| 516 | + 44 2b 4f 6c | |
| 517 | + 14: mov 0xd8(%rdi),%r8 | |
| 518 | + 4c 8b 87 d8 00 00 00 | |
| 519 | + 1b: mov $0xc,%esi | |
| 520 | + be 0c 00 00 00 | |
| 521 | + 20: callq 0xffffffffe0ff9442 | |
| 522 | + e8 1d 94 ff e0 | |
| 523 | + 25: cmp $0x800,%eax | |
| 524 | + 3d 00 08 00 00 | |
| 525 | + 2a: jne 0x0000000000000042 | |
| 526 | + 75 16 | |
| 527 | + 2c: mov $0x17,%esi | |
| 528 | + be 17 00 00 00 | |
| 529 | + 31: callq 0xffffffffe0ff945e | |
| 530 | + e8 28 94 ff e0 | |
| 531 | + 36: cmp $0x1,%eax | |
| 532 | + 83 f8 01 | |
| 533 | + 39: jne 0x0000000000000042 | |
| 534 | + 75 07 | |
| 535 | + 3b: mov $0xffff,%eax | |
| 536 | + b8 ff ff 00 00 | |
| 537 | + 40: jmp 0x0000000000000044 | |
| 538 | + eb 02 | |
| 539 | + 42: xor %eax,%eax | |
| 540 | + 31 c0 | |
| 541 | + 44: leaveq | |
| 542 | + c9 | |
| 543 | + 45: retq | |
| 544 | + c3 | |
| 545 | + | |
| 546 | +For BPF JIT developers, bpf_jit_disasm, bpf_asm and bpf_dbg provides a useful | |
| 547 | +toolchain for developing and testing the kernel's JIT compiler. | |
| 548 | + | |
| 549 | +Misc | |
| 550 | +---- | |
| 551 | + | |
| 552 | +Also trinity, the Linux syscall fuzzer, has built-in support for BPF and | |
| 553 | +SECCOMP-BPF kernel fuzzing. | |
| 554 | + | |
| 555 | +Written by | |
| 556 | +---------- | |
| 557 | + | |
| 558 | +The document was written in the hope that it is found useful and in order | |
| 559 | +to give potential BPF hackers or security auditors a better overview of | |
| 560 | +the underlying architecture. | |
| 561 | + | |
| 562 | +Jay Schulist <jschlst@samba.org> | |
| 563 | +Daniel Borkmann <dborkman@redhat.com> | |
| @@ -0,0 +1,47 @@ | ||
| 1 | +Linux* Base Driver for Intel(R) Network Connection | |
| 2 | +================================================== | |
| 3 | + | |
| 4 | +Intel XL710 X710 Virtual Function Linux driver. | |
| 5 | +Copyright(c) 2013 Intel Corporation. | |
| 6 | + | |
| 7 | +Contents | |
| 8 | +======== | |
| 9 | + | |
| 10 | +- Identifying Your Adapter | |
| 11 | +- Known Issues/Troubleshooting | |
| 12 | +- Support | |
| 13 | + | |
| 14 | +This file describes the i40evf Linux* Base Driver for the Intel(R) XL710 | |
| 15 | +X710 Virtual Function. | |
| 16 | + | |
| 17 | +The i40evf driver supports XL710 and X710 virtual function devices that | |
| 18 | +can only be activated on kernels with CONFIG_PCI_IOV enabled. | |
| 19 | + | |
| 20 | +The guest OS loading the i40evf driver must support MSI-X interrupts. | |
| 21 | + | |
| 22 | +Identifying Your Adapter | |
| 23 | +======================== | |
| 24 | + | |
| 25 | +For more information on how to identify your adapter, go to the Adapter & | |
| 26 | +Driver ID Guide at: | |
| 27 | + | |
| 28 | + http://support.intel.com/support/go/network/adapter/idguide.htm | |
| 29 | + | |
| 30 | +Known Issues/Troubleshooting | |
| 31 | +============================ | |
| 32 | + | |
| 33 | + | |
| 34 | +Support | |
| 35 | +======= | |
| 36 | + | |
| 37 | +For general information, go to the Intel support website at: | |
| 38 | + | |
| 39 | + http://support.intel.com | |
| 40 | + | |
| 41 | +or the Intel Wired Networking project hosted by Sourceforge at: | |
| 42 | + | |
| 43 | + http://sourceforge.net/projects/e1000 | |
| 44 | + | |
| 45 | +If an issue is identified with the released source code on the supported | |
| 46 | +kernel with a supported adapter, email the specific information related | |
| 47 | +to the issue to e1000-devel@lists.sf.net | |
| @@ -15,17 +15,47 @@ ip_default_ttl - INTEGER · 14 unmodified lines | ||
| 15 | 15 | forwarded) IP packets. Should be between 1 and 255 inclusive. |
| 16 | 16 | Default: 64 (as recommended by RFC1700) |
| 17 | 17 | |
| 18 | −ip_no_pmtu_disc - BOOLEAN | |
| 19 | − Disable Path MTU Discovery. If enabled and a | |
| 18 | +ip_no_pmtu_disc - INTEGER | |
| 19 | + Disable Path MTU Discovery. If enabled in mode 1 and a | |
| 20 | 20 | fragmentation-required ICMP is received, the PMTU to this |
| 21 | 21 | destination will be set to min_pmtu (see below). You will need |
| 22 | 22 | to raise min_pmtu to the smallest interface MTU on your system |
| 23 | 23 | manually if you want to avoid locally generated fragments. |
| 24 | + | |
| 25 | + In mode 2 incoming Path MTU Discovery messages will be | |
| 26 | + discarded. Outgoing frames are handled the same as in mode 1, | |
| 27 | + implicitly setting IP_PMTUDISC_DONT on every created socket. | |
| 28 | + | |
| 29 | + Mode 3 is a hardend pmtu discover mode. The kernel will only | |
| 30 | + accept fragmentation-needed errors if the underlying protocol | |
| 31 | + can verify them besides a plain socket lookup. Current | |
| 32 | + protocols for which pmtu events will be honored are TCP, SCTP | |
| 33 | + and DCCP as they verify e.g. the sequence number or the | |
| 34 | + association. This mode should not be enabled globally but is | |
| 35 | + only intended to secure e.g. name servers in namespaces where | |
| 36 | + TCP path mtu must still work but path MTU information of other | |
| 37 | + protocols should be discarded. If enabled globally this mode | |
| 38 | + could break other protocols. | |
| 39 | + | |
| 40 | + Possible values: 0-3 | |
| 24 | 41 | Default: FALSE |
| 25 | 42 | |
| 26 | 43 | min_pmtu - INTEGER |
| 27 | 44 | default 552 - minimum discovered Path MTU |
| 28 | 45 | |
| 46 | +ip_forward_use_pmtu - BOOLEAN | |
| 47 | + By default we don't trust protocol path MTUs while forwarding | |
| 48 | + because they could be easily forged and can lead to unwanted | |
| 49 | + fragmentation by the router. | |
| 50 | + You only need to enable this if you have user-space software | |
| 51 | + which tries to discover path mtus by itself and depends on the | |
| 52 | + kernel honoring this information. This is normally not the | |
| 53 | + case. | |
| 54 | + Default: 0 (disabled) | |
| 55 | + Possible values: | |
| 56 | + 0 - disabled | |
| 57 | + 1 - enabled | |
| 58 | + | |
| 29 | 59 | route/max_size - INTEGER |
| 30 | 60 | Maximum number of routes allowed in the kernel. Increase |
| 31 | 61 | this when using large numbers of interfaces and/or routes. |
| @@ -160,6 +190,16 @@ tcp_app_win - INTEGER · 128 unmodified lines | ||
| 160 | 190 | buffer. Value 0 is special, it means that nothing is reserved. |
| 161 | 191 | Default: 31 |
| 162 | 192 | |
| 193 | +tcp_autocorking - BOOLEAN | |
| 194 | + Enable TCP auto corking : | |
| 195 | + When applications do consecutive small write()/sendmsg() system calls, | |
| 196 | + we try to coalesce these small writes as much as possible, to lower | |
| 197 | + total amount of sent packets. This is done if at least one prior | |
| 198 | + packet for the flow is waiting in Qdisc queues or device transmit | |
| 199 | + queue. Applications can still use TCP_CORK for optimal behavior | |
| 200 | + when they know how/when to uncork their sockets. | |
| 201 | + Default : 1 | |
| 202 | + | |
| 163 | 203 | tcp_available_congestion_control - STRING |
| 164 | 204 | Shows the available congestion control choices that are registered. |
| 165 | 205 | More congestion control algorithms may be available as modules, |
| @@ -1048,6 +1088,12 @@ igmpv3_unsolicited_report_interval - INTEGER · 882 unmodified lines | ||
| 1048 | 1088 | IGMPv3 report retransmit will take place. |
| 1049 | 1089 | Default: 1000 (1 seconds) |
| 1050 | 1090 | |
| 1091 | +promote_secondaries - BOOLEAN | |
| 1092 | + When a primary IP address is removed from this interface | |
| 1093 | + promote a corresponding secondary IP address instead of | |
| 1094 | + removing all the corresponding secondary IP addresses. | |
| 1095 | + | |
| 1096 | + | |
| 1051 | 1097 | tag - INTEGER |
| 1052 | 1098 | Allows you to write a number, which can be used as required. |
| 1053 | 1099 | Default value is 0. |
| @@ -1078,6 +1124,21 @@ bindv6only - BOOLEAN · 24 unmodified lines | ||
| 1078 | 1124 | |
| 1079 | 1125 | Default: FALSE (as specified in RFC3493) |
| 1080 | 1126 | |
| 1127 | +flowlabel_consistency - BOOLEAN | |
| 1128 | + Protect the consistency (and unicity) of flow label. | |
| 1129 | + You have to disable it to use IPV6_FL_F_REFLECT flag on the | |
| 1130 | + flow label manager. | |
| 1131 | + TRUE: enabled | |
| 1132 | + FALSE: disabled | |
| 1133 | + Default: TRUE | |
| 1134 | + | |
| 1135 | +anycast_src_echo_reply - BOOLEAN | |
| 1136 | + Controls the use of anycast addresses as source addresses for ICMPv6 | |
| 1137 | + echo reply | |
| 1138 | + TRUE: enabled | |
| 1139 | + FALSE: disabled | |
| 1140 | + Default: FALSE | |
| 1141 | + | |
| 1081 | 1142 | IPv6 Fragmentation: |
| 1082 | 1143 | |
| 1083 | 1144 | ip6frag_high_thresh - INTEGER |
| @@ -0,0 +1,38 @@ | ||
| 1 | + | |
| 2 | +Here documents known IPsec corner cases which need to be keep in mind when | |
| 3 | +deploy various IPsec configuration in real world production environment. | |
| 4 | + | |
| 5 | +1. IPcomp: Small IP packet won't get compressed at sender, and failed on | |
| 6 | + policy check on receiver. | |
| 7 | + | |
| 8 | +Quote from RFC3173: | |
| 9 | +2.2. Non-Expansion Policy | |
| 10 | + | |
| 11 | + If the total size of a compressed payload and the IPComp header, as | |
| 12 | + defined in section 3, is not smaller than the size of the original | |
| 13 | + payload, the IP datagram MUST be sent in the original non-compressed | |
| 14 | + form. To clarify: If an IP datagram is sent non-compressed, no | |
| 15 | + | |
| 16 | + IPComp header is added to the datagram. This policy ensures saving | |
| 17 | + the decompression processing cycles and avoiding incurring IP | |
| 18 | + datagram fragmentation when the expanded datagram is larger than the | |
| 19 | + MTU. | |
| 20 | + | |
| 21 | + Small IP datagrams are likely to expand as a result of compression. | |
| 22 | + Therefore, a numeric threshold should be applied before compression, | |
| 23 | + where IP datagrams of size smaller than the threshold are sent in the | |
| 24 | + original form without attempting compression. The numeric threshold | |
| 25 | + is implementation dependent. | |
| 26 | + | |
| 27 | +Current IPComp implementation is indeed by the book, while as in practice | |
| 28 | +when sending non-compressed packet to the peer(whether or not packet len | |
| 29 | +is smaller than the threshold or the compressed len is large than original | |
| 30 | +packet len), the packet is dropped when checking the policy as this packet | |
| 31 | +matches the selector but not coming from any XFRM layer, i.e., with no | |
| 32 | +security path. Such naked packet will not eventually make it to upper layer. | |
| 33 | +The result is much more wired to the user when ping peer with different | |
| 34 | +payload length. | |
| 35 | + | |
| 36 | +One workaround is try to set "level use" for each policy if user observed | |
| 37 | +above scenario. The consequence of doing so is small packet(uncompressed) | |
| 38 | +will skip policy checking on receiver side. | |
| @@ -98,6 +98,11 @@ by the kernel. · 97 unmodified lines | ||
| 98 | 98 | The destruction of the socket and all associated resources |
| 99 | 99 | is done by a simple call to close(fd). |
| 100 | 100 | |
| 101 | +Similarly as without PACKET_MMAP, it is possible to use one socket | |
| 102 | +for capture and transmission. This can be done by mapping the | |
| 103 | +allocated RX and TX buffer ring with a single mmap() call. | |
| 104 | +See "Mapping and use of the circular buffer (ring)". | |
| 105 | + | |
| 101 | 106 | Next I will describe PACKET_MMAP settings and its constraints, |
| 102 | 107 | also the mapping of the circular buffer in the user process and |
| 103 | 108 | the use of this buffer. |
| @@ -414,6 +419,19 @@ tp_block_size/tp_frame_size frames there will be a gap between · 310 unmodified lines | ||
| 414 | 419 | the frames. This is because a frame cannot be spawn across two |
| 415 | 420 | blocks. |
| 416 | 421 | |
| 422 | +To use one socket for capture and transmission, the mapping of both the | |
| 423 | +RX and TX buffer ring has to be done with one call to mmap: | |
| 424 | + | |
| 425 | + ... | |
| 426 | + setsockopt(fd, SOL_PACKET, PACKET_RX_RING, &foo, sizeof(foo)); | |
| 427 | + setsockopt(fd, SOL_PACKET, PACKET_TX_RING, &bar, sizeof(bar)); | |
| 428 | + ... | |
| 429 | + rx_ring = mmap(0, size * 2, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0); | |
| 430 | + tx_ring = rx_ring + size; | |
| 431 | + | |
| 432 | +RX must be the first as the kernel maps the TX ring memory right | |
| 433 | +after the RX one. | |
| 434 | + | |
| 417 | 435 | At the beginning of each frame there is an status field (see |
| 418 | 436 | struct tpacket_hdr). If this field is 0 means that the frame is ready |
| 419 | 437 | to be used for the kernel, If not, there is a frame the user can read |
| @@ -517,8 +535,6 @@ where 'tpacket_version' can be TPACKET_V1 (default), TPACKET_V2, TPACKET_V3. · 97 unmodified lines | ||
| 517 | 535 | TPACKET_V1: |
| 518 | 536 | - Default if not otherwise specified by setsockopt(2) |
| 519 | 537 | - RX_RING, TX_RING available |
| 520 | − - VLAN metadata information available for packets | |
| 521 | − (TP_STATUS_VLAN_VALID) | |
| 522 | 538 | |
| 523 | 539 | TPACKET_V1 --> TPACKET_V2: |
| 524 | 540 | - Made 64 bit clean due to unsigned long usage in TPACKET_V1 |
| @@ -526,6 +542,13 @@ TPACKET_V1 --> TPACKET_V2: · 1 unmodified line | ||
| 526 | 542 | userspace and the like |
| 527 | 543 | - Timestamp resolution in nanoseconds instead of microseconds |
| 528 | 544 | - RX_RING, TX_RING available |
| 545 | + - VLAN metadata information available for packets | |
| 546 | + (TP_STATUS_VLAN_VALID, TP_STATUS_VLAN_TPID_VALID), | |
| 547 | + in the tpacket2_hdr structure: | |
| 548 | + - TP_STATUS_VLAN_VALID bit being set into the tp_status field indicates | |
| 549 | + that the tp_vlan_tci field has valid VLAN TCI value | |
| 550 | + - TP_STATUS_VLAN_TPID_VALID bit being set into the tp_status field | |
| 551 | + indicates that the tp_vlan_tpid field has valid VLAN TPID value | |
| 529 | 552 | - How to switch to TPACKET_V2: |
| 530 | 553 | 1. Replace struct tpacket_hdr by struct tpacket2_hdr |
| 531 | 554 | 2. Query header len and save |
| @@ -560,6 +583,7 @@ Currently implemented fanout policies are: · 28 unmodified lines | ||
| 560 | 583 | - PACKET_FANOUT_CPU: schedule to socket by CPU packet arrives on |
| 561 | 584 | - PACKET_FANOUT_RND: schedule to socket by random selection |
| 562 | 585 | - PACKET_FANOUT_ROLLOVER: if one socket is full, rollover to another |
| 586 | + - PACKET_FANOUT_QM: schedule to socket by skbs recorded queue_mapping | |
| 563 | 587 | |
| 564 | 588 | Minimal example code by David S. Miller (try things like "./test eth0 hash", |
| 565 | 589 | "./test eth0 lb", etc.): |
| @@ -952,6 +976,27 @@ int main(int argc, char **argp) · 386 unmodified lines | ||
| 952 | 976 | return 0; |
| 953 | 977 | } |
| 954 | 978 | |
| 979 | +------------------------------------------------------------------------------- | |
| 980 | ++ PACKET_QDISC_BYPASS | |
| 981 | +------------------------------------------------------------------------------- | |
| 982 | + | |
| 983 | +If there is a requirement to load the network with many packets in a similar | |
| 984 | +fashion as pktgen does, you might set the following option after socket | |
| 985 | +creation: | |
| 986 | + | |
| 987 | + int one = 1; | |
| 988 | + setsockopt(fd, SOL_PACKET, PACKET_QDISC_BYPASS, &one, sizeof(one)); | |
| 989 | + | |
| 990 | +This has the side-effect, that packets sent through PF_PACKET will bypass the | |
| 991 | +kernel's qdisc layer and are forcedly pushed to the driver directly. Meaning, | |
| 992 | +packet are not buffered, tc disciplines are ignored, increased loss can occur | |
| 993 | +and such packets are also not visible to other PF_PACKET sockets anymore. So, | |
| 994 | +you have been warned; generally, this can be useful for stress testing various | |
| 995 | +components of a system. | |
| 996 | + | |
| 997 | +On default, PACKET_QDISC_BYPASS is disabled and needs to be explicitly enabled | |
| 998 | +on PF_PACKET sockets. | |
| 999 | + | |
| 955 | 1000 | ------------------------------------------------------------------------------- |
| 956 | 1001 | + PACKET_TIMESTAMP |
| 957 | 1002 | ------------------------------------------------------------------------------- |
| @@ -255,7 +255,8 @@ Writing a PHY driver · 254 unmodified lines | ||
| 255 | 255 | |
| 256 | 256 | config_init: configures PHY into a sane state after a reset. |
| 257 | 257 | For instance, a Davicom PHY requires descrambling disabled. |
| 258 | − probe: Does any setup needed by the driver | |
| 258 | + probe: Allocate phy->priv, optionally refuse to bind. | |
| 259 | + PHY may not have been reset or had fixups run yet. | |
| 259 | 260 | suspend/resume: power management |
| 260 | 261 | config_aneg: Changes the speed/duplex/negotiation settings |
| 261 | 262 | read_status: Reads the current speed/duplex/negotiation settings |
| @@ -108,7 +108,9 @@ Examples: · 107 unmodified lines | ||
| 108 | 108 | MPLS_RND, VID_RND, SVID_RND |
| 109 | 109 | QUEUE_MAP_RND # queue map random |
| 110 | 110 | QUEUE_MAP_CPU # queue map mirrors smp_processor_id() |
| 111 | + IPSEC # Make IPsec encapsulation for packet | |
| 111 | 112 | |
| 113 | + pgset spi SPI_VALUE Set specific SA used to transform packet. | |
| 112 | 114 | |
| 113 | 115 | pgset "udp_src_min 9" set UDP source port min, If < udp_src_max, then |
| 114 | 116 | cycle through the port range. |
| @@ -177,6 +179,18 @@ Note when adding devices to a specific CPU there good idea to also assign · 62 unmodified lines | ||
| 177 | 179 | /proc/irq/XX/smp_affinity so the TX-interrupts gets bound to the same CPU. |
| 178 | 180 | as this reduces cache bouncing when freeing skb's. |
| 179 | 181 | |
| 182 | +Enable IPsec | |
| 183 | +============ | |
| 184 | +Default IPsec transformation with ESP encapsulation plus Transport mode | |
| 185 | +could be enabled by simply setting: | |
| 186 | + | |
| 187 | +pgset "flag IPSEC" | |
| 188 | +pgset "flows 1" | |
| 189 | + | |
| 190 | +To avoid breaking existing testbed scripts for using AH type and tunnel mode, | |
| 191 | +user could use "pgset spi SPI_VALUE" to specify which formal of transformation | |
| 192 | +to employ. | |
| 193 | + | |
| 180 | 194 | |
| 181 | 195 | Current commands and configuration options |
| 182 | 196 | ========================================== |
| @@ -225,6 +239,7 @@ flag · 42 unmodified lines | ||
| 225 | 239 | UDPDST_RND |
| 226 | 240 | MACSRC_RND |
| 227 | 241 | MACDST_RND |
| 242 | + IPSEC | |
| 228 | 243 | |
| 229 | 244 | dst_min |
| 230 | 245 | dst_max |
| @@ -159,10 +159,10 @@ struct ieee80211_regdomain mydriver_jp_regdom = { · 158 unmodified lines | ||
| 159 | 159 | REG_RULE(2412-20, 2484+20, 40, 6, 20, 0), |
| 160 | 160 | /* IEEE 802.11a, channels 34..48 */ |
| 161 | 161 | REG_RULE(5170-20, 5240+20, 40, 6, 20, |
| 162 | − NL80211_RRF_PASSIVE_SCAN), | |
| 162 | + NL80211_RRF_NO_IR), | |
| 163 | 163 | /* IEEE 802.11a, channels 52..64 */ |
| 164 | 164 | REG_RULE(5260-20, 5320+20, 40, 6, 20, |
| 165 | − NL80211_RRF_NO_IBSS | | |
| 165 | + NL80211_RRF_NO_IR| | |
| 166 | 166 | NL80211_RRF_DFS), |
| 167 | 167 | } |
| 168 | 168 | }; |
| @@ -127,8 +127,9 @@ struct plat_stmmacenet_data { · 126 unmodified lines | ||
| 127 | 127 | int riwt_off; |
| 128 | 128 | void (*fix_mac_speed)(void *priv, unsigned int speed); |
| 129 | 129 | void (*bus_setup)(void __iomem *ioaddr); |
| 130 | − int (*init)(struct platform_device *pdev); | |
| 131 | − void (*exit)(struct platform_device *pdev); | |
| 130 | + void *(*setup)(struct platform_device *pdev); | |
| 131 | + int (*init)(struct platform_device *pdev, void *priv); | |
| 132 | + void (*exit)(struct platform_device *pdev, void *priv); | |
| 132 | 133 | void *custom_cfg; |
| 133 | 134 | void *custom_data; |
| 134 | 135 | void *bsp_priv; |
| @@ -169,10 +170,13 @@ Where: · 34 unmodified lines | ||
| 169 | 170 | o bus_setup: perform HW setup of the bus. For example, on some ST platforms |
| 170 | 171 | this field is used to configure the AMBA bridge to generate more |
| 171 | 172 | efficient STBus traffic. |
| 172 | − o init/exit: callbacks used for calling a custom initialization; | |
| 173 | + o setup/init/exit: callbacks used for calling a custom initialization; | |
| 173 | 174 | this is sometime necessary on some platforms (e.g. ST boxes) |
| 174 | 175 | where the HW needs to have set some PIO lines or system cfg |
| 175 | − registers. | |
| 176 | + registers. setup should return a pointer to private data, | |
| 177 | + which will be stored in bsp_priv, and then passed to init and | |
| 178 | + exit callbacks. init/exit callbacks should not use or modify | |
| 179 | + platform data. | |
| 176 | 180 | o custom_cfg/custom_data: this is a custom configuration that can be passed |
| 177 | 181 | while initializing the resources. |
| 178 | 182 | o bsp_priv: another private pointer. |
| @@ -85,7 +85,7 @@ Filled in if SOF_TIMESTAMPING_SYS_HARDWARE is set. Requires support · 84 unmodified lines | ||
| 85 | 85 | by the network device and will be empty without that support. |
| 86 | 86 | |
| 87 | 87 | |
| 88 | −SIOCSHWTSTAMP: | |
| 88 | +SIOCSHWTSTAMP, SIOCGHWTSTAMP: | |
| 89 | 89 | |
| 90 | 90 | Hardware time stamping must also be initialized for each device driver |
| 91 | 91 | that is expected to do hardware time stamping. The parameter is defined in |
| @@ -115,6 +115,10 @@ Only a processes with admin rights may change the configuration. User · 23 unmodified lines | ||
| 115 | 115 | space is responsible to ensure that multiple processes don't interfere |
| 116 | 116 | with each other and that the settings are reset. |
| 117 | 117 | |
| 118 | +Any process can read the actual configuration by passing this | |
| 119 | +structure to ioctl(SIOCGHWTSTAMP) in the same way. However, this has | |
| 120 | +not been implemented in all drivers. | |
| 121 | + | |
| 118 | 122 | /* possible values for hwtstamp_config->tx_type */ |
| 119 | 123 | enum { |
| 120 | 124 | /* |
| @@ -157,7 +161,8 @@ DEVICE IMPLEMENTATION · 36 unmodified lines | ||
| 157 | 161 | |
| 158 | 162 | A driver which supports hardware time stamping must support the |
| 159 | 163 | SIOCSHWTSTAMP ioctl and update the supplied struct hwtstamp_config with |
| 160 | −the actual values as described in the section on SIOCSHWTSTAMP. | |
| 164 | +the actual values as described in the section on SIOCSHWTSTAMP. It | |
| 165 | +should also support SIOCGHWTSTAMP. | |
| 161 | 166 | |
| 162 | 167 | Time stamps for received packets must be stored in the skb. To get a pointer |
| 163 | 168 | to the shared time stamp structure of the skb call skb_hwtstamps(). Then |
| @@ -1 +1,2 @@ | ||
| 1 | 1 | timestamping |
| 2 | +hwtstamp_config | |
| @@ -2,12 +2,13 @@ · 1 unmodified line | ||
| 2 | 2 | obj- := dummy.o |
| 3 | 3 | |
| 4 | 4 | # List of programs to build |
| 5 | −hostprogs-y := timestamping | |
| 5 | +hostprogs-y := timestamping hwtstamp_config | |
| 6 | 6 | |
| 7 | 7 | # Tell kbuild to always build the programs |
| 8 | 8 | always := $(hostprogs-y) |
| 9 | 9 | |
| 10 | 10 | HOSTCFLAGS_timestamping.o += -I$(objtree)/usr/include |
| 11 | +HOSTCFLAGS_hwtstamp_config.o += -I$(objtree)/usr/include | |
| 11 | 12 | |
| 12 | 13 | clean: |
| 13 | − rm -f timestamping | |
| 14 | + rm -f timestamping hwtstamp_config | |
| @@ -0,0 +1,134 @@ | ||
| 1 | +/* Test program for SIOC{G,S}HWTSTAMP | |
| 2 | + * Copyright 2013 Solarflare Communications | |
| 3 | + * Author: Ben Hutchings | |
| 4 | + */ | |
| 5 | + | |
| 6 | +#include <errno.h> | |
| 7 | +#include <stdio.h> | |
| 8 | +#include <stdlib.h> | |
| 9 | +#include <string.h> | |
| 10 | + | |
| 11 | +#include <sys/socket.h> | |
| 12 | +#include <sys/ioctl.h> | |
| 13 | + | |
| 14 | +#include <linux/if.h> | |
| 15 | +#include <linux/net_tstamp.h> | |
| 16 | +#include <linux/sockios.h> | |
| 17 | + | |
| 18 | +static int | |
| 19 | +lookup_value(const char **names, int size, const char *name) | |
| 20 | +{ | |
| 21 | + int value; | |
| 22 | + | |
| 23 | + for (value = 0; value < size; value++) | |
| 24 | + if (names[value] && strcasecmp(names[value], name) == 0) | |
| 25 | + return value; | |
| 26 | + | |
| 27 | + return -1; | |
| 28 | +} | |
| 29 | + | |
| 30 | +static const char * | |
| 31 | +lookup_name(const char **names, int size, int value) | |
| 32 | +{ | |
| 33 | + return (value >= 0 && value < size) ? names[value] : NULL; | |
| 34 | +} | |
| 35 | + | |
| 36 | +static void list_names(FILE *f, const char **names, int size) | |
| 37 | +{ | |
| 38 | + int value; | |
| 39 | + | |
| 40 | + for (value = 0; value < size; value++) | |
| 41 | + if (names[value]) | |
| 42 | + fprintf(f, " %s\n", names[value]); | |
| 43 | +} | |
| 44 | + | |
| 45 | +static const char *tx_types[] = { | |
| 46 | +#define TX_TYPE(name) [HWTSTAMP_TX_ ## name] = #name | |
| 47 | + TX_TYPE(OFF), | |
| 48 | + TX_TYPE(ON), | |
| 49 | + TX_TYPE(ONESTEP_SYNC) | |
| 50 | +#undef TX_TYPE | |
| 51 | +}; | |
| 52 | +#define N_TX_TYPES ((int)(sizeof(tx_types) / sizeof(tx_types[0]))) | |
| 53 | + | |
| 54 | +static const char *rx_filters[] = { | |
| 55 | +#define RX_FILTER(name) [HWTSTAMP_FILTER_ ## name] = #name | |
| 56 | + RX_FILTER(NONE), | |
| 57 | + RX_FILTER(ALL), | |
| 58 | + RX_FILTER(SOME), | |
| 59 | + RX_FILTER(PTP_V1_L4_EVENT), | |
| 60 | + RX_FILTER(PTP_V1_L4_SYNC), | |
| 61 | + RX_FILTER(PTP_V1_L4_DELAY_REQ), | |
| 62 | + RX_FILTER(PTP_V2_L4_EVENT), | |
| 63 | + RX_FILTER(PTP_V2_L4_SYNC), | |
| 64 | + RX_FILTER(PTP_V2_L4_DELAY_REQ), | |
| 65 | + RX_FILTER(PTP_V2_L2_EVENT), | |
| 66 | + RX_FILTER(PTP_V2_L2_SYNC), | |
| 67 | + RX_FILTER(PTP_V2_L2_DELAY_REQ), | |
| 68 | + RX_FILTER(PTP_V2_EVENT), | |
| 69 | + RX_FILTER(PTP_V2_SYNC), | |
| 70 | + RX_FILTER(PTP_V2_DELAY_REQ), | |
| 71 | +#undef RX_FILTER | |
| 72 | +}; | |
| 73 | +#define N_RX_FILTERS ((int)(sizeof(rx_filters) / sizeof(rx_filters[0]))) | |
| 74 | + | |
| 75 | +static void usage(void) | |
| 76 | +{ | |
| 77 | + fputs("Usage: hwtstamp_config if_name [tx_type rx_filter]\n" | |
| 78 | + "tx_type is any of (case-insensitive):\n", | |
| 79 | + stderr); | |
| 80 | + list_names(stderr, tx_types, N_TX_TYPES); | |
| 81 | + fputs("rx_filter is any of (case-insensitive):\n", stderr); | |
| 82 | + list_names(stderr, rx_filters, N_RX_FILTERS); | |
| 83 | +} | |
| 84 | + | |
| 85 | +int main(int argc, char **argv) | |
| 86 | +{ | |
| 87 | + struct ifreq ifr; | |
| 88 | + struct hwtstamp_config config; | |
| 89 | + const char *name; | |
| 90 | + int sock; | |
| 91 | + | |
| 92 | + if ((argc != 2 && argc != 4) || (strlen(argv[1]) >= IFNAMSIZ)) { | |
| 93 | + usage(); | |
| 94 | + return 2; | |
| 95 | + } | |
| 96 | + | |
| 97 | + if (argc == 4) { | |
| 98 | + config.flags = 0; | |
| 99 | + config.tx_type = lookup_value(tx_types, N_TX_TYPES, argv[2]); | |
| 100 | + config.rx_filter = lookup_value(rx_filters, N_RX_FILTERS, argv[3]); | |
| 101 | + if (config.tx_type < 0 || config.rx_filter < 0) { | |
| 102 | + usage(); | |
| 103 | + return 2; | |
| 104 | + } | |
| 105 | + } | |
| 106 | + | |
| 107 | + sock = socket(AF_INET, SOCK_DGRAM, 0); | |
| 108 | + if (sock < 0) { | |
| 109 | + perror("socket"); | |
| 110 | + return 1; | |
| 111 | + } | |
| 112 | + | |
| 113 | + strcpy(ifr.ifr_name, argv[1]); | |
| 114 | + ifr.ifr_data = (caddr_t)&config; | |
| 115 | + | |
| 116 | + if (ioctl(sock, (argc == 2) ? SIOCGHWTSTAMP : SIOCSHWTSTAMP, &ifr)) { | |
| 117 | + perror("ioctl"); | |
| 118 | + return 1; | |
| 119 | + } | |
| 120 | + | |
| 121 | + printf("flags = %#x\n", config.flags); | |
| 122 | + name = lookup_name(tx_types, N_TX_TYPES, config.tx_type); | |
| 123 | + if (name) | |
| 124 | + printf("tx_type = %s\n", name); | |
| 125 | + else | |
| 126 | + printf("tx_type = %d\n", config.tx_type); | |
| 127 | + name = lookup_name(rx_filters, N_RX_FILTERS, config.rx_filter); | |
| 128 | + if (name) | |
| 129 | + printf("rx_filter = %s\n", name); | |
| 130 | + else | |
| 131 | + printf("rx_filter = %d\n", config.rx_filter); | |
| 132 | + | |
| 133 | + return 0; | |
| 134 | +} | |
| @@ -18,7 +18,7 @@ Definition of PIN CONTROLLER: · 17 unmodified lines | ||
| 18 | 18 | |
| 19 | 19 | - A pin controller is a piece of hardware, usually a set of registers, that |
| 20 | 20 | can control PINs. It may be able to multiplex, bias, set load capacitance, |
| 21 | − set drive strength etc for individual pins or groups of pins. | |
| 21 | + set drive strength, etc. for individual pins or groups of pins. | |
| 22 | 22 | |
| 23 | 23 | Definition of PIN: |
| 24 | 24 | |
| @@ -90,7 +90,7 @@ selected drivers, you need to select them from your machine's Kconfig entry, · 65 unmodified lines | ||
| 90 | 90 | since these are so tightly integrated with the machines they are used on. |
| 91 | 91 | See for example arch/arm/mach-u300/Kconfig for an example. |
| 92 | 92 | |
| 93 | −Pins usually have fancier names than this. You can find these in the dataheet | |
| 93 | +Pins usually have fancier names than this. You can find these in the datasheet | |
| 94 | 94 | for your chip. Notice that the core pinctrl.h file provides a fancy macro |
| 95 | 95 | called PINCTRL_PIN() to create the struct entries. As you can see I enumerated |
| 96 | 96 | the pins from 0 in the upper left corner to 63 in the lower right corner. |
| @@ -185,7 +185,7 @@ static struct pinctrl_desc foo_desc = { · 88 unmodified lines | ||
| 185 | 185 | }; |
| 186 | 186 | |
| 187 | 187 | The pin control subsystem will call the .get_groups_count() function to |
| 188 | −determine total number of legal selectors, then it will call the other functions | |
| 188 | +determine the total number of legal selectors, then it will call the other functions | |
| 189 | 189 | to retrieve the name and pins of the group. Maintaining the data structure of |
| 190 | 190 | the groups is up to the driver, this is just a simple example - in practice you |
| 191 | 191 | may need more entries in your group structure, for example specific register |
| @@ -195,7 +195,7 @@ ranges associated with each group and so on. · 3 unmodified lines | ||
| 195 | 195 | Pin configuration |
| 196 | 196 | ================= |
| 197 | 197 | |
| 198 | −Pins can sometimes be software-configured in an various ways, mostly related | |
| 198 | +Pins can sometimes be software-configured in various ways, mostly related | |
| 199 | 199 | to their electronic properties when used as inputs or outputs. For example you |
| 200 | 200 | may be able to make an output pin high impedance, or "tristate" meaning it is |
| 201 | 201 | effectively disconnected. You may be able to connect an input pin to VDD or GND |
| @@ -291,7 +291,7 @@ Since the pin controller subsystem have its pinspace local to the pin · 89 unmodified lines | ||
| 291 | 291 | controller we need a mapping so that the pin control subsystem can figure out |
| 292 | 292 | which pin controller handles control of a certain GPIO pin. Since a single |
| 293 | 293 | pin controller may be muxing several GPIO ranges (typically SoCs that have |
| 294 | −one set of pins but internally several GPIO silicon blocks, each modelled as | |
| 294 | +one set of pins, but internally several GPIO silicon blocks, each modelled as | |
| 295 | 295 | a struct gpio_chip) any number of GPIO ranges can be added to a pin controller |
| 296 | 296 | instance like this: |
| 297 | 297 | |
| @@ -373,9 +373,9 @@ will be called on that specific pin controller. · 75 unmodified lines | ||
| 373 | 373 | |
| 374 | 374 | For all functionalities dealing with pin biasing, pin muxing etc, the pin |
| 375 | 375 | controller subsystem will look up the corresponding pin number from the passed |
| 376 | −in gpio number, and use the range's internals to retrive a pin number. After | |
| 376 | +in gpio number, and use the range's internals to retrieve a pin number. After | |
| 377 | 377 | that, the subsystem passes it on to the pin control driver, so the driver |
| 378 | −will get an pin number into its handled number range. Further it is also passed | |
| 378 | +will get a pin number into its handled number range. Further it is also passed | |
| 379 | 379 | the range ID value, so that the pin controller knows which range it should |
| 380 | 380 | deal with. |
| 381 | 381 | |
| @@ -430,8 +430,8 @@ pins you see some will be taken by things like a few VCC and GND to feed power · 48 unmodified lines | ||
| 430 | 430 | to the chip, and quite a few will be taken by large ports like an external |
| 431 | 431 | memory interface. The remaining pins will often be subject to pin multiplexing. |
| 432 | 432 | |
| 433 | −The example 8x8 PGA package above will have pin numbers 0 thru 63 assigned to | |
| 434 | −its physical pins. It will name the pins { A1, A2, A3 ... H6, H7, H8 } using | |
| 433 | +The example 8x8 PGA package above will have pin numbers 0 through 63 assigned | |
| 434 | +to its physical pins. It will name the pins { A1, A2, A3 ... H6, H7, H8 } using | |
| 435 | 435 | pinctrl_register_pins() and a suitable data set as shown earlier. |
| 436 | 436 | |
| 437 | 437 | In this 8x8 BGA package the pins { A8, A7, A6, A5 } can be used as an SPI port |
| @@ -442,7 +442,7 @@ we cannot use the SPI port and I2C port at the same time. However in the inside · 4 unmodified lines | ||
| 442 | 442 | of the package the silicon performing the SPI logic can alternatively be routed |
| 443 | 443 | out on pins { G4, G3, G2, G1 }. |
| 444 | 444 | |
| 445 | −On the botton row at { A1, B1, C1, D1, E1, F1, G1, H1 } we have something | |
| 445 | +On the bottom row at { A1, B1, C1, D1, E1, F1, G1, H1 } we have something | |
| 446 | 446 | special - it's an external MMC bus that can be 2, 4 or 8 bits wide, and it will |
| 447 | 447 | consume 2, 4 or 8 pins respectively, so either { A1, B1 } are taken or |
| 448 | 448 | { A1, B1, C1, D1 } or all of them. If we use all 8 bits, we cannot use the SPI |
| @@ -549,7 +549,7 @@ Assumptions: · 100 unmodified lines | ||
| 549 | 549 | |
| 550 | 550 | We assume that the number of possible function maps to pin groups is limited by |
| 551 | 551 | the hardware. I.e. we assume that there is no system where any function can be |
| 552 | −mapped to any pin, like in a phone exchange. So the available pins groups for | |
| 552 | +mapped to any pin, like in a phone exchange. So the available pin groups for | |
| 553 | 553 | a certain function will be limited to a few choices (say up to eight or so), |
| 554 | 554 | not hundreds or any amount of choices. This is the characteristic we have found |
| 555 | 555 | by inspecting available pinmux hardware, and a necessary assumption since we |
| @@ -564,7 +564,7 @@ The pinmux core takes care of preventing conflicts on pins and calling · 8 unmodified lines | ||
| 564 | 564 | the pin controller driver to execute different settings. |
| 565 | 565 | |
| 566 | 566 | It is the responsibility of the pinmux driver to impose further restrictions |
| 567 | −(say for example infer electronic limitations due to load etc) to determine | |
| 567 | +(say for example infer electronic limitations due to load, etc.) to determine | |
| 568 | 568 | whether or not the requested function can actually be allowed, and in case it |
| 569 | 569 | is possible to perform the requested mux setting, poke the hardware so that |
| 570 | 570 | this happens. |
| @@ -755,7 +755,7 @@ Pin control interaction with the GPIO subsystem · 184 unmodified lines | ||
| 755 | 755 | Note that the following implies that the use case is to use a certain pin |
| 756 | 756 | from the Linux kernel using the API in <linux/gpio.h> with gpio_request() |
| 757 | 757 | and similar functions. There are cases where you may be using something |
| 758 | −that your datasheet calls "GPIO mode" but actually is just an electrical | |
| 758 | +that your datasheet calls "GPIO mode", but actually is just an electrical | |
| 759 | 759 | configuration for a certain device. See the section below named |
| 760 | 760 | "GPIO mode pitfalls" for more details on this scenario. |
| 761 | 761 | |
| @@ -871,7 +871,7 @@ hardware and shall be put into different subsystems: · 109 unmodified lines | ||
| 871 | 871 | |
| 872 | 872 | - Registers (or fields within registers) that control muxing of signals |
| 873 | 873 | from various other HW blocks (e.g. I2C, MMC, or GPIO) onto pins should |
| 874 | − be exposed through the pinctrl subssytem, as mux functions. | |
| 874 | + be exposed through the pinctrl subsystem, as mux functions. | |
| 875 | 875 | |
| 876 | 876 | - Registers (or fields within registers) that control GPIO functionality |
| 877 | 877 | such as setting a GPIO's output value, reading a GPIO's input value, or |
| @@ -895,7 +895,7 @@ Example: a pin is usually muxed in to be used as a UART TX line. But during · 17 unmodified lines | ||
| 895 | 895 | system sleep, we need to put this pin into "GPIO mode" and ground it. |
| 896 | 896 | |
| 897 | 897 | If you make a 1-to-1 map to the GPIO subsystem for this pin, you may start |
| 898 | −to think that you need to come up with something real complex, that the | |
| 898 | +to think that you need to come up with something really complex, that the | |
| 899 | 899 | pin shall be used for UART TX and GPIO at the same time, that you will grab |
| 900 | 900 | a pin control handle and set it to a certain state to enable UART TX to be |
| 901 | 901 | muxed in, then twist it over to GPIO mode and use gpio_direction_output() |
| @@ -964,12 +964,12 @@ GPIO mode. · 62 unmodified lines | ||
| 964 | 964 | This will give the desired effect without any bogus interaction with the |
| 965 | 965 | GPIO subsystem. It is just an electrical configuration used by that device |
| 966 | 966 | when going to sleep, it might imply that the pin is set into something the |
| 967 | −datasheet calls "GPIO mode" but that is not the point: it is still used | |
| 967 | +datasheet calls "GPIO mode", but that is not the point: it is still used | |
| 968 | 968 | by that UART device to control the pins that pertain to that very UART |
| 969 | 969 | driver, putting them into modes needed by the UART. GPIO in the Linux |
| 970 | 970 | kernel sense are just some 1-bit line, and is a different use case. |
| 971 | 971 | |
| 972 | −How the registers are poked to attain the push/pull and output low | |
| 972 | +How the registers are poked to attain the push or pull, and output low | |
| 973 | 973 | configuration and the muxing of the "u0" or "gpio-mode" group onto these |
| 974 | 974 | pins is a question for the driver. |
| 975 | 975 | |
| @@ -977,7 +977,7 @@ Some datasheets will be more helpful and refer to the "GPIO mode" as · 1 unmodified line | ||
| 977 | 977 | "low power mode" rather than anything to do with GPIO. This often means |
| 978 | 978 | the same thing electrically speaking, but in this latter case the |
| 979 | 979 | software engineers will usually quickly identify that this is some |
| 980 | −specific muxing/configuration rather than anything related to the GPIO | |
| 980 | +specific muxing or configuration rather than anything related to the GPIO | |
| 981 | 981 | API. |
| 982 | 982 | |
| 983 | 983 | |
| @@ -1024,8 +1024,7 @@ up the device struct (just like with clockdev or regulators). The function name · 40 unmodified lines | ||
| 1024 | 1024 | must match a function provided by the pinmux driver handling this pin range. |
| 1025 | 1025 | |
| 1026 | 1026 | As you can see we may have several pin controllers on the system and thus |
| 1027 | −we need to specify which one of them that contain the functions we wish | |
| 1028 | −to map. | |
| 1027 | +we need to specify which one of them contains the functions we wish to map. | |
| 1029 | 1028 | |
| 1030 | 1029 | You register this pinmux mapping to the pinmux subsystem by simply: |
| 1031 | 1030 | |
| @@ -1254,10 +1253,10 @@ The semantics of the pinctrl APIs are: · 222 unmodified lines | ||
| 1254 | 1253 | pinctrl_get(). |
| 1255 | 1254 | |
| 1256 | 1255 | - pinctrl_lookup_state() is called in process context to obtain a handle to a |
| 1257 | − specific state for a the client device. This operation may be slow too. | |
| 1256 | + specific state for a client device. This operation may be slow, too. | |
| 1258 | 1257 | |
| 1259 | 1258 | - pinctrl_select_state() programs pin controller hardware according to the |
| 1260 | − definition of the state as given by the mapping table. In theory this is a | |
| 1259 | + definition of the state as given by the mapping table. In theory, this is a | |
| 1261 | 1260 | fast-path operation, since it only involved blasting some register settings |
| 1262 | 1261 | into hardware. However, note that some pin controllers may have their |
| 1263 | 1262 | registers on a slow/IRQ-based bus, so client devices should not assume they |
| @@ -172,7 +172,7 @@ you can boot the kernel with the 'no_console_suspend' parameter and try to log · 171 unmodified lines | ||
| 172 | 172 | kernel messages using the serial console. This may provide you with some |
| 173 | 173 | information about the reasons of the suspend (resume) failure. Alternatively, |
| 174 | 174 | it may be possible to use a FireWire port for debugging with firescope |
| 175 | −(ftp://ftp.firstfloor.org/pub/ak/firescope/). On x86 it is also possible to | |
| 175 | +(http://v3.sk/~lkundrak/firescope/). On x86 it is also possible to | |
| 176 | 176 | use the PM_TRACE mechanism documented in Documentation/power/s2ram.txt . |
| 177 | 177 | |
| 178 | 178 | 2. Testing suspend to RAM (STR) |
| @@ -55,14 +55,21 @@ Struct Resources: · 54 unmodified lines | ||
| 55 | 55 | For printing struct resources. The 'R' and 'r' specifiers result in a |
| 56 | 56 | printed resource with ('R') or without ('r') a decoded flags member. |
| 57 | 57 | |
| 58 | −Physical addresses: | |
| 58 | +Physical addresses types phys_addr_t: | |
| 59 | 59 | |
| 60 | − %pa 0x01234567 or 0x0123456789abcdef | |
| 60 | + %pa[p] 0x01234567 or 0x0123456789abcdef | |
| 61 | 61 | |
| 62 | 62 | For printing a phys_addr_t type (and its derivatives, such as |
| 63 | 63 | resource_size_t) which can vary based on build options, regardless of |
| 64 | 64 | the width of the CPU data path. Passed by reference. |
| 65 | 65 | |
| 66 | +DMA addresses types dma_addr_t: | |
| 67 | + | |
| 68 | + %pad 0x01234567 or 0x0123456789abcdef | |
| 69 | + | |
| 70 | + For printing a dma_addr_t type which can vary based on build options, | |
| 71 | + regardless of the width of the CPU data path. Passed by reference. | |
| 72 | + | |
| 66 | 73 | Raw buffer as a hex string: |
| 67 | 74 | %*ph 00 01 02 ... 3f |
| 68 | 75 | %*phC 00:01:02: ... :3f |
| @@ -71,7 +71,7 @@ To create an rfkill driver, driver's Kconfig needs to have · 70 unmodified lines | ||
| 71 | 71 | depends on RFKILL || !RFKILL |
| 72 | 72 | |
| 73 | 73 | to ensure the driver cannot be built-in when rfkill is modular. The !RFKILL |
| 74 | −case allows the driver to be built when rfkill is not configured, which which | |
| 74 | +case allows the driver to be built when rfkill is not configured, which | |
| 75 | 75 | case all rfkill API can still be used but will be provided by static inlines |
| 76 | 76 | which compile to almost nothing. |
| 77 | 77 | |
| @@ -30,7 +30,7 @@ is something called unbounded priority inversion. That is when the high · 29 unmodified lines | ||
| 30 | 30 | priority process is prevented from running by a lower priority process for |
| 31 | 31 | an undetermined amount of time. |
| 32 | 32 | |
| 33 | −The classic example of unbounded priority inversion is were you have three | |
| 33 | +The classic example of unbounded priority inversion is where you have three | |
| 34 | 34 | processes, let's call them processes A, B, and C, where A is the highest |
| 35 | 35 | priority process, C is the lowest, and B is in between. A tries to grab a lock |
| 36 | 36 | that C owns and must wait and lets C run to release the lock. But in the |
| @@ -0,0 +1,50 @@ | ||
| 1 | +IBM s390 QDIO Ethernet Driver | |
| 2 | + | |
| 3 | +HiperSockets Bridge Port Support | |
| 4 | + | |
| 5 | +Uevents | |
| 6 | + | |
| 7 | +To generate the events the device must be assigned a role of either | |
| 8 | +a primary or a secondary Bridge Port. For more information, see | |
| 9 | +"z/VM Connectivity, SC24-6174". | |
| 10 | + | |
| 11 | +When run on HiperSockets Bridge Capable Port hardware, and the state | |
| 12 | +of some configured Bridge Port device on the channel changes, a udev | |
| 13 | +event with ACTION=CHANGE is emitted on behalf of the corresponding | |
| 14 | +ccwgroup device. The event has the following attributes: | |
| 15 | + | |
| 16 | +BRIDGEPORT=statechange - indicates that the Bridge Port device changed | |
| 17 | + its state. | |
| 18 | + | |
| 19 | +ROLE={primary|secondary|none} - the role assigned to the port. | |
| 20 | + | |
| 21 | +STATE={active|standby|inactive} - the newly assumed state of the port. | |
| 22 | + | |
| 23 | +When run on HiperSockets Bridge Capable Port hardware with host address | |
| 24 | +notifications enabled, a udev event with ACTION=CHANGE is emitted. | |
| 25 | +It is emitted on behalf of the corresponding ccwgroup device when a host | |
| 26 | +or a VLAN is registered or unregistered on the network served by the device. | |
| 27 | +The event has the following attributes: | |
| 28 | + | |
| 29 | +BRIDGEDHOST={reset|register|deregister|abort} - host address | |
| 30 | + notifications are started afresh, a new host or VLAN is registered or | |
| 31 | + deregistered on the Bridge Port HiperSockets channel, or address | |
| 32 | + notifications are aborted. | |
| 33 | + | |
| 34 | +VLAN=numeric-vlan-id - VLAN ID on which the event occurred. Not included | |
| 35 | + if no VLAN is involved in the event. | |
| 36 | + | |
| 37 | +MAC=xx:xx:xx:xx:xx:xx - MAC address of the host that is being registered | |
| 38 | + or deregistered from the HiperSockets channel. Not reported if the | |
| 39 | + event reports the creation or destruction of a VLAN. | |
| 40 | + | |
| 41 | +NTOK_BUSID=x.y.zzzz - device bus ID (CSSID, SSID and device number). | |
| 42 | + | |
| 43 | +NTOK_IID=xx - device IID. | |
| 44 | + | |
| 45 | +NTOK_CHPID=xx - device CHPID. | |
| 46 | + | |
| 47 | +NTOK_CHID=xxxx - device channel ID. | |
| 48 | + | |
| 49 | +Note that the NTOK_* attributes refer to devices other than the one | |
| 50 | +connected to the system on which the OS is running. | |
| @@ -42,8 +42,6 @@ aic79xx.txt · 41 unmodified lines | ||
| 42 | 42 | - Adaptec Ultra320 SCSI host adapters |
| 43 | 43 | aic7xxx.txt |
| 44 | 44 | - info on driver for Adaptec controllers |
| 45 | −aic7xxx_old.txt | |
| 46 | − - info on driver for Adaptec controllers, old generation | |
| 47 | 45 | arcmsr_spec.txt |
| 48 | 46 | - ARECA FIRMWARE SPEC (for IOP331 adapter) |
| 49 | 47 | dc395x.txt |
| @@ -1,511 +0,0 @@ | ||
| 1 | − AIC7xxx Driver for Linux | |
| 2 | − | |
| 3 | −Introduction | |
| 4 | −---------------------------- | |
| 5 | −The AIC7xxx SCSI driver adds support for Adaptec (http://www.adaptec.com) | |
| 6 | −SCSI controllers and chipsets. Major portions of the driver and driver | |
| 7 | −development are shared between both Linux and FreeBSD. Support for the | |
| 8 | −AIC-7xxx chipsets have been in the default Linux kernel since approximately | |
| 9 | −linux-1.1.x and fairly stable since linux-1.2.x, and are also in FreeBSD | |
| 10 | −2.1.0 or later. | |
| 11 | − | |
| 12 | − Supported cards/chipsets | |
| 13 | − ---------------------------- | |
| 14 | − Adaptec Cards | |
| 15 | − ---------------------------- | |
| 16 | − AHA-274x | |
| 17 | − AHA-274xT | |
| 18 | − AHA-2842 | |
| 19 | − AHA-2910B | |
| 20 | − AHA-2920C | |
| 21 | − AHA-2930 | |
| 22 | − AHA-2930U | |
| 23 | − AHA-2930CU | |
| 24 | − AHA-2930U2 | |
| 25 | − AHA-2940 | |
| 26 | − AHA-2940W | |
| 27 | − AHA-2940U | |
| 28 | − AHA-2940UW | |
| 29 | − AHA-2940UW-PRO | |
| 30 | − AHA-2940AU | |
| 31 | − AHA-2940U2W | |
| 32 | − AHA-2940U2 | |
| 33 | − AHA-2940U2B | |
| 34 | − AHA-2940U2BOEM | |
| 35 | − AHA-2944D | |
| 36 | − AHA-2944WD | |
| 37 | − AHA-2944UD | |
| 38 | − AHA-2944UWD | |
| 39 | − AHA-2950U2 | |
| 40 | − AHA-2950U2W | |
| 41 | − AHA-2950U2B | |
| 42 | − AHA-29160M | |
| 43 | − AHA-3940 | |
| 44 | − AHA-3940U | |
| 45 | − AHA-3940W | |
| 46 | − AHA-3940UW | |
| 47 | − AHA-3940AUW | |
| 48 | − AHA-3940U2W | |
| 49 | − AHA-3950U2B | |
| 50 | − AHA-3950U2D | |
| 51 | − AHA-3960D | |
| 52 | − AHA-39160M | |
| 53 | − AHA-3985 | |
| 54 | − AHA-3985U | |
| 55 | − AHA-3985W | |
| 56 | − AHA-3985UW | |
| 57 | − | |
| 58 | − Motherboard Chipsets | |
| 59 | − ---------------------------- | |
| 60 | − AIC-777x | |
| 61 | − AIC-785x | |
| 62 | − AIC-786x | |
| 63 | − AIC-787x | |
| 64 | − AIC-788x | |
| 65 | − AIC-789x | |
| 66 | − AIC-3860 | |
| 67 | − | |
| 68 | − Bus Types | |
| 69 | − ---------------------------- | |
| 70 | − W - Wide SCSI, SCSI-3, 16bit bus, 68pin connector, will also support | |
| 71 | − SCSI-1/SCSI-2 50pin devices, transfer rates up to 20MB/s. | |
| 72 | − U - Ultra SCSI, transfer rates up to 40MB/s. | |
| 73 | − U2- Ultra 2 SCSI, transfer rates up to 80MB/s. | |
| 74 | − D - Differential SCSI. | |
| 75 | − T - Twin Channel SCSI. Up to 14 SCSI devices. | |
| 76 | − | |
| 77 | − AHA-274x - EISA SCSI controller | |
| 78 | − AHA-284x - VLB SCSI controller | |
| 79 | − AHA-29xx - PCI SCSI controller | |
| 80 | − AHA-394x - PCI controllers with two separate SCSI controllers on-board. | |
| 81 | − AHA-398x - PCI RAID controllers with three separate SCSI controllers | |
| 82 | − on-board. | |
| 83 | − | |
| 84 | − Not Supported Devices | |
| 85 | − ------------------------------ | |
| 86 | − Adaptec Cards | |
| 87 | − ---------------------------- | |
| 88 | − AHA-2920 (Only the cards that use the Future Domain chipset are not | |
| 89 | − supported, any 2920 cards based on Adaptec AIC chipsets, | |
| 90 | − such as the 2920C, are supported) | |
| 91 | − AAA-13x Raid Adapters | |
| 92 | − AAA-113x Raid Port Card | |
| 93 | − | |
| 94 | − Motherboard Chipsets | |
| 95 | − ---------------------------- | |
| 96 | − AIC-7810 | |
| 97 | − | |
| 98 | − Bus Types | |
| 99 | − ---------------------------- | |
| 100 | − R - Raid Port busses are not supported. | |
| 101 | − | |
| 102 | − The hardware RAID devices sold by Adaptec are *NOT* supported by this | |
| 103 | − driver (and will people please stop emailing me about them, they are | |
| 104 | − a totally separate beast from the bare SCSI controllers and this driver | |
| 105 | − cannot be retrofitted in any sane manner to support the hardware RAID | |
| 106 | − features on those cards - Doug Ledford). | |
| 107 | − | |
| 108 | − | |
| 109 | − People | |
| 110 | − ------------------------------ | |
| 111 | − Justin T Gibbs gibbs@plutotech.com | |
| 112 | − (BSD Driver Author) | |
| 113 | − Dan Eischen deischen@iworks.InterWorks.org | |
| 114 | − (Original Linux Driver Co-maintainer) | |
| 115 | − Dean Gehnert deang@teleport.com | |
| 116 | − (Original Linux FTP/patch maintainer) | |
| 117 | − Jess Johnson jester@frenzy.com | |
| 118 | − (AIC7xxx FAQ author) | |
| 119 | − Doug Ledford dledford@redhat.com | |
| 120 | − (Current Linux aic7xxx-5.x.x Driver/Patch/FTP maintainer) | |
| 121 | − | |
| 122 | − Special thanks go to John Aycock (aycock@cpsc.ucalgary.ca), the original | |
| 123 | − author of the driver. John has since retired from the project. Thanks | |
| 124 | − again for all his work! | |
| 125 | − | |
| 126 | − Mailing list | |
| 127 | − ------------------------------ | |
| 128 | − There is a mailing list available for users who want to track development | |
| 129 | − and converse with other users and developers. This list is for both | |
| 130 | − FreeBSD and Linux support of the AIC7xxx chipsets. | |
| 131 | − | |
| 132 | − To subscribe to the AIC7xxx mailing list send mail to the list server, | |
| 133 | − with "subscribe AIC7xxx" in the body (no Subject: required): | |
| 134 | − To: majordomo@FreeBSD.ORG | |
| 135 | − --- | |
| 136 | − subscribe AIC7xxx | |
| 137 | − | |
| 138 | − To unsubscribe from the list, send mail to the list server with: | |
| 139 | − To: majordomo@FreeBSD.ORG | |
| 140 | − --- | |
| 141 | − unsubscribe AIC7xxx | |
| 142 | − | |
| 143 | − Send regular messages and replies to: AIC7xxx@FreeBSD.ORG | |
| 144 | − | |
| 145 | − Boot Command line options | |
| 146 | − ------------------------------ | |
| 147 | − "aic7xxx=no_reset" - Eliminate the SCSI bus reset during startup. | |
| 148 | − Some SCSI devices need the initial reset that this option disables | |
| 149 | − in order to work. If you have problems at bootup, please make sure | |
| 150 | − you aren't using this option. | |
| 151 | − | |
| 152 | − "aic7xxx=reverse_scan" - Certain PCI motherboards scan for devices at | |
| 153 | − bootup by scanning from the highest numbered PCI device to the | |
| 154 | − lowest numbered PCI device, others do just the opposite and scan | |
| 155 | − from lowest to highest numbered PCI device. There is no reliable | |
| 156 | − way to autodetect this ordering. So, we default to the most common | |
| 157 | − order, which is lowest to highest. Then, in case your motherboard | |
| 158 | − scans from highest to lowest, we have this option. If your BIOS | |
| 159 | − finds the drives on controller A before controller B but the linux | |
| 160 | − kernel finds your drives on controller B before A, then you should | |
| 161 | − use this option. | |
| 162 | − | |
| 163 | − "aic7xxx=extended" - Force the driver to detect extended drive translation | |
| 164 | − on your controller. This helps those people who have cards without | |
| 165 | − a SEEPROM make sure that linux and all other operating systems think | |
| 166 | − the same way about your hard drives. | |
| 167 | − | |
| 168 | − "aic7xxx=scbram" - Some cards have external SCB RAM that can be used to | |
| 169 | − give the card more hardware SCB slots. This allows the driver to use | |
| 170 | − that SCB RAM. Without this option, the driver won't touch the SCB | |
| 171 | − RAM because it is known to cause problems on a few cards out there | |
| 172 | − (such as 3985 class cards). | |
| 173 | − | |
| 174 | − "aic7xxx=irq_trigger:x" - Replace x with either 0 or 1 to force the kernel | |
| 175 | − to use the correct IRQ type for your card. This only applies to EISA | |
| 176 | − based controllers. On these controllers, 0 is for Edge triggered | |
| 177 | − interrupts, and 1 is for Level triggered interrupts. If you aren't | |
| 178 | − sure or don't know which IRQ trigger type your EISA card uses, then | |
| 179 | − let the kernel autodetect the trigger type. | |
| 180 | − | |
| 181 | − "aic7xxx=verbose" - This option can be used in one of two ways. If you | |
| 182 | − simply specify aic7xxx=verbose, then the kernel will automatically | |
| 183 | − pick the default set of verbose messages for you to see. | |
| 184 | − Alternatively, you can specify the command as | |
| 185 | − "aic7xxx=verbose:0xXXXX" where the X entries are replaced with | |
| 186 | − hexadecimal digits. This option is a bit field type option. For | |
| 187 | − a full listing of the available options, search for the | |
| 188 | − #define VERBOSE_xxxxxx lines in the aic7xxx.c file. If you want | |
| 189 | − verbose messages, then it is recommended that you simply use the | |
| 190 | − aic7xxx=verbose variant of this command. | |
| 191 | − | |
| 192 | − "aic7xxx=pci_parity:x" - This option controls whether or not the driver | |
| 193 | − enables PCI parity error checking on the PCI bus. By default, this | |
| 194 | − checking is disabled. To enable the checks, simply specify pci_parity | |
| 195 | − with no value afterwords. To reverse the parity from even to odd, | |
| 196 | − supply any number other than 0 or 255. In short: | |
| 197 | − pci_parity - Even parity checking (even is the normal PCI parity) | |
| 198 | − pci_parity:x - Where x > 0, Odd parity checking | |
| 199 | − pci_parity:0 - No check (default) | |
| 200 | − NOTE: In order to get Even PCI parity checking, you must use the | |
| 201 | − version of the option that does not include the : and a number at | |
| 202 | − the end (unless you want to enter exactly 2^32 - 1 as the number). | |
| 203 | − | |
| 204 | − "aic7xxx=no_probe" - This option will disable the probing for any VLB | |
| 205 | − based 2842 controllers and any EISA based controllers. This is | |
| 206 | − needed on certain newer motherboards where the normal EISA I/O ranges | |
| 207 | − have been claimed by other PCI devices. Probing on those machines | |
| 208 | − will often result in the machine crashing or spontaneously rebooting | |
| 209 | − during startup. Examples of machines that need this are the | |
| 210 | − Dell PowerEdge 6300 machines. | |
| 211 | − | |
| 212 | − "aic7xxx=seltime:2" - This option controls how long the card waits | |
| 213 | − during a device selection sequence for the device to respond. | |
| 214 | − The original SCSI spec says that this "should be" 256ms. This | |
| 215 | − is generally not required with modern devices. However, some | |
| 216 | − very old SCSI I devices need the full 256ms. Most modern devices | |
| 217 | − can run fine with only 64ms. The default for this option is | |
| 218 | − 64ms. If you need to change this option, then use the following | |
| 219 | − table to set the proper value in the example above: | |
| 220 | − 0 - 256ms | |
| 221 | − 1 - 128ms | |
| 222 | − 2 - 64ms | |
| 223 | − 3 - 32ms | |
| 224 | − | |
| 225 | − "aic7xxx=panic_on_abort" - This option is for debugging and will cause | |
| 226 | − the driver to panic the linux kernel and freeze the system the first | |
| 227 | − time the drivers abort or reset routines are called. This is most | |
| 228 | − helpful when some problem causes infinite reset loops that scroll too | |
| 229 | − fast to see. By using this option, you can write down what the errors | |
| 230 | − actually are and send that information to me so it can be fixed. | |
| 231 | − | |
| 232 | − "aic7xxx=dump_card" - This option will print out the *entire* set of | |
| 233 | − configuration registers on the card during the init sequence. This | |
| 234 | − is a debugging aid used to see exactly what state the card is in | |
| 235 | − when we finally finish our initialization routines. If you don't | |
| 236 | − have documentation on the chipsets, this will do you absolutely | |
| 237 | − no good unless you are simply trying to write all the information | |
| 238 | − down in order to send it to me. | |
| 239 | − | |
| 240 | − "aic7xxx=dump_sequencer" - This is the same as the above options except | |
| 241 | − that instead of dumping the register contents on the card, this | |
| 242 | − option dumps the contents of the sequencer program RAM. This gives | |
| 243 | − the ability to verify that the instructions downloaded to the | |
| 244 | − card's sequencer are indeed what they are supposed to be. Again, | |
| 245 | − unless you have documentation to tell you how to interpret these | |
| 246 | − numbers, then it is totally useless. | |
| 247 | − | |
| 248 | − "aic7xxx=override_term:0xffffffff" - This option is used to force the | |
| 249 | − termination on your SCSI controllers to a particular setting. This | |
| 250 | − is a bit mask variable that applies for up to 8 aic7xxx SCSI channels. | |
| 251 | − Each channel gets 4 bits, divided as follows: | |
| 252 | − bit 3 2 1 0 | |
| 253 | − | | | Enable/Disable Single Ended Low Byte Termination | |
| 254 | − | | En/Disable Single Ended High Byte Termination | |
| 255 | − | En/Disable Low Byte LVD Termination | |
| 256 | − En/Disable High Byte LVD Termination | |
| 257 | − | |
| 258 | − The upper 2 bits that deal with LVD termination only apply to Ultra2 | |
| 259 | − controllers. Furthermore, due to the current Ultra2 controller | |
| 260 | − designs, these bits are tied together such that setting either bit | |
| 261 | − enables both low and high byte LVD termination. It is not possible | |
| 262 | − to only set high or low byte LVD termination in this manner. This is | |
| 263 | − an artifact of the BIOS definition on Ultra2 controllers. For other | |
| 264 | − controllers, the only important bits are the two lowest bits. Setting | |
| 265 | − the higher bits on non-Ultra2 controllers has no effect. A few | |
| 266 | − examples of how to use this option: | |
| 267 | − | |
| 268 | − Enable low and high byte termination on a non-ultra2 controller that | |
| 269 | − is the first aic7xxx controller (the correct bits are 0011), | |
| 270 | − aic7xxx=override_term:0x3 | |
| 271 | − | |
| 272 | − Enable all termination on the third aic7xxx controller, high byte | |
| 273 | − termination on the second aic7xxx controller, and low and high byte | |
| 274 | − SE termination on the first aic7xxx controller | |
| 275 | − (bits are 1111 0010 0011), | |
| 276 | − aic7xxx=override_term:0xf23 | |
| 277 | − | |
| 278 | − No attempt has been made to make this option non-cryptic. It really | |
| 279 | − shouldn't be used except in dire circumstances, and if that happens, | |
| 280 | − I'm probably going to be telling you what to set this to anyway :) | |
| 281 | − | |
| 282 | − "aic7xxx=stpwlev:0xffffffff" - This option is used to control the STPWLEV | |
| 283 | − bit in the DEVCONFIG PCI register. Currently, this is one of the | |
| 284 | − very few registers that we have absolutely *no* way of detecting | |
| 285 | − what the variable should be. It depends entirely on how the chipset | |
| 286 | − and external terminators were coupled by the card/motherboard maker. | |
| 287 | − Further, a chip reset (at power up) always sets this bit to 0. If | |
| 288 | − there is no BIOS to run on the chipset/card (such as with a 2910C | |
| 289 | − or a motherboard controller with the BIOS totally disabled) then | |
| 290 | − the variable may not get set properly. Of course, if the proper | |
| 291 | − setting was 0, then that's what it would be after the reset, but if | |
| 292 | − the proper setting is actually 1.....you get the picture. Now, since | |
| 293 | − we can't detect this at all, I've added this option to force the | |
| 294 | − setting. If you have a BIOS on your controller then you should never | |
| 295 | − need to use this option. However, if you are having lots of SCSI | |
| 296 | − reset problems and can't seem to get them knocked out, this may help. | |
| 297 | − | |
| 298 | − Here's a test to know for certain if you need this option. Make | |
| 299 | − a boot floppy that you can use to boot your computer up and that | |
| 300 | − will detect the aic7xxx controller. Next, power down your computer. | |
| 301 | − While it's down, unplug all SCSI cables from your Adaptec SCSI | |
| 302 | − controller. Boot the system back up to the Adaptec EZ-SCSI BIOS | |
| 303 | − and then make sure that termination is enabled on your adapter (if | |
| 304 | − you have an Adaptec BIOS of course). Next, boot up the floppy you | |
| 305 | − made and wait for it to detect the aic7xxx controller. If the kernel | |
| 306 | − finds the controller fine, says scsi : x hosts and then tries to | |
| 307 | − detect your devices like normal, up to the point where it fails to | |
| 308 | − mount your root file system and panics, then you're fine. If, on | |
| 309 | − the other hand, the system goes into an infinite reset loop, then | |
| 310 | − you need to use this option and/or the previous option to force the | |
| 311 | − proper termination settings on your controller. If this happens, | |
| 312 | − then you next need to figure out what your settings should be. | |
| 313 | − | |
| 314 | − To find the correct settings, power your machine back down, connect | |
| 315 | − back up the SCSI cables, and boot back into your machine like normal. | |
| 316 | − However, boot with the aic7xxx=verbose:0x39 option. Record the | |
| 317 | − initial DEVCONFIG values for each of your aic7xxx controllers as | |
| 318 | − they are listed, and also record what the machine is detecting as | |
| 319 | − the proper termination on your controllers. NOTE: the order in | |
| 320 | − which the initial DEVCONFIG values are printed out is not guaranteed | |
| 321 | − to be the same order as the SCSI controllers are registered. The | |
| 322 | − above option and this option both work on the order of the SCSI | |
| 323 | − controllers as they are registered, so make sure you match the right | |
| 324 | − DEVCONFIG values with the right controllers if you have more than | |
| 325 | − one aic7xxx controller. | |
| 326 | − | |
| 327 | − Once you have the detected termination settings and the initial | |
| 328 | − DEVCONFIG values for each controller, then figure out what the | |
| 329 | − termination on each of the controllers *should* be. Hopefully, that | |
| 330 | − part is correct, but it could possibly be wrong if there is | |
| 331 | − bogus cable detection logic on your controller or something similar. | |
| 332 | − If all the controllers have the correct termination settings, then | |
| 333 | − don't set the aic7xxx=override_term variable at all, leave it alone. | |
| 334 | − Next, on any controllers that go into an infinite reset loop when | |
| 335 | − you unplug all the SCSI cables, get the starting DEVCONFIG value. | |
| 336 | − If the initial DEVCONFIG value is divisible by 2, then the correct | |
| 337 | − setting for that controller is 0. If it's an odd number, then | |
| 338 | − the correct setting for that controller is 1. For any other | |
| 339 | − controllers that didn't have an infinite reset problem, then reverse | |
| 340 | − the above options. If DEVCONFIG was even, then the correct setting | |
| 341 | − is 1, if not then the correct setting is 0. | |
| 342 | − | |
| 343 | − Now that you know what the correct setting was for each controller, | |
| 344 | − we need to encode that into the aic7xxx=stpwlev:0x... variable. | |
| 345 | − This variable is a bit field encoded variable. Bit 0 is for the first | |
| 346 | − aic7xxx controller, bit 1 for the next, etc. Put all these bits | |
| 347 | − together and you get a number. For example, if the third aic7xxx | |
| 348 | − needed a 1, but the second and first both needed a 0, then the bits | |
| 349 | − would be 100 in binary. This then translates to 0x04. You would | |
| 350 | − therefore set aic7xxx=stpwlev:0x04. This is fairly standard binary | |
| 351 | − to hexadecimal conversions here. If you aren't up to speed on the | |
| 352 | − binary->hex conversion then send an email to the aic7xxx mailing | |
| 353 | − list and someone can help you out. | |
| 354 | − | |
| 355 | − "aic7xxx=tag_info:{{8,8..},{8,8..},..}" - This option is used to disable | |
| 356 | − or enable Tagged Command Queueing (TCQ) on specific devices. As of | |
| 357 | − driver version 5.1.11, TCQ is now either on or off by default | |
| 358 | − according to the setting you choose during the make config process. | |
| 359 | − In order to en/disable TCQ for certain devices at boot time, a user | |
| 360 | − may use this boot param. The driver will then parse this message out | |
| 361 | − and en/disable the specific device entries that are present based upon | |
| 362 | − the value given. The param line is parsed in the following manner: | |
| 363 | − | |
| 364 | − { - first instance indicates the start of this parameter values | |
| 365 | − second instance is the start of entries for a particular | |
| 366 | − device entry | |
| 367 | − } - end the entries for a particular host adapter, or end the entire | |
| 368 | − set of parameter entries | |
| 369 | − , - move to next entry. Inside of a set of device entries, this | |
| 370 | − moves us to the next device on the list. Outside of device | |
| 371 | − entries, this moves us to the next host adapter | |
| 372 | − . - Same effect as , but is safe to use with insmod. | |
| 373 | − x - the number to enter into the array at this position. | |
| 374 | − 0 = Enable tagged queueing on this device and use the default | |
| 375 | − queue depth | |
| 376 | − 1-254 = Enable tagged queueing on this device and use this | |
| 377 | − number as the queue depth | |
| 378 | − 255 = Disable tagged queueing on this device. | |
| 379 | − Note: anything above 32 for an actual queue depth is wasteful | |
| 380 | − and not recommended. | |
| 381 | − | |
| 382 | − A few examples of how this can be used: | |
| 383 | − | |
| 384 | − tag_info:{{8,12,,0,,255,4}} | |
| 385 | − This line will only effect the first aic7xxx card registered. It | |
| 386 | − will set scsi id 0 to a queue depth of 8, id 1 to 12, leave id 2 | |
| 387 | − at the default, set id 3 to tagged queueing enabled and use the | |
| 388 | − default queue depth, id 4 default, id 5 disabled, and id 6 to 4. | |
| 389 | − Any not specified entries stay at the default value, repeated | |
| 390 | − commas with no value specified will simply increment to the next id | |
| 391 | − without changing anything for the missing values. | |
| 392 | − | |
| 393 | − tag_info:{,,,{,,,255}} | |
| 394 | − First, second, and third adapters at default values. Fourth | |
| 395 | − adapter, id 3 is disabled. Notice that leading commas simply | |
| 396 | − increment what the first number effects, and there are no need | |
| 397 | − for trailing commas. When you close out an adapter, or the | |
| 398 | − entire entry, anything not explicitly set stays at the default | |
| 399 | − value. | |
| 400 | − | |
| 401 | − A final note on this option. The scanner I used for this isn't | |
| 402 | − perfect or highly robust. If you mess the line up, the worst that | |
| 403 | − should happen is that the line will get ignored. If you don't | |
| 404 | − close out the entire entry with the final bracket, then any other | |
| 405 | − aic7xxx options after this will get ignored. So, in general, be | |
| 406 | − sure of what you are entering, and after you have it right, just | |
| 407 | − add it to the lilo.conf file so there won't be any mistakes. As | |
| 408 | − a means of checking this parser, the entire tag_info array for | |
| 409 | − each card is now printed out in the /proc/scsi/aic7xxx/x file. You | |
| 410 | − can use that to verify that your options were parsed correctly. | |
| 411 | − | |
| 412 | − Boot command line options may be combined to form the proper set of options | |
| 413 | − a user might need. For example, the following is valid: | |
| 414 | − | |
| 415 | − aic7xxx=verbose,extended,irq_trigger:1 | |
| 416 | − | |
| 417 | − The only requirement is that individual options be separated by a comma or | |
| 418 | − a period on the command line. | |
| 419 | − | |
| 420 | − Module Loading command options | |
| 421 | − ------------------------------ | |
| 422 | − When loading the aic7xxx driver as a module, the exact same options are | |
| 423 | − available to the user. However, the syntax to specify the options changes | |
| 424 | − slightly. For insmod, you need to wrap the aic7xxx= argument in quotes | |
| 425 | − and replace all ',' with '.'. So, for example, a valid insmod line | |
| 426 | − would be: | |
| 427 | − | |
| 428 | − insmod aic7xxx aic7xxx='verbose.irq_trigger:1.extended' | |
| 429 | − | |
| 430 | − This line should result in the *exact* same behaviour as if you typed | |
| 431 | − it in at the lilo prompt and the driver was compiled into the kernel | |
| 432 | − instead of being a module. The reason for the single quote is so that | |
| 433 | − the shell won't try to interpret anything in the line, such as {. | |
| 434 | − Insmod assumes any options starting with a letter instead of a number | |
| 435 | − is a character string (which is what we want) and by switching all of | |
| 436 | − the commas to periods, insmod won't interpret this as more than one | |
| 437 | − string and write junk into our binary image. I consider it a bug in | |
| 438 | − the insmod program that even if you wrap your string in quotes (quotes | |
| 439 | − that pass the shell mind you and that insmod sees) it still treats | |
| 440 | − a comma inside of those quotes as starting a new variable, resulting | |
| 441 | − in memory scribbles if you don't switch the commas to periods. | |
| 442 | − | |
| 443 | − | |
| 444 | − Kernel Compile options | |
| 445 | − ------------------------------ | |
| 446 | − The various kernel compile time options for this driver are now fairly | |
| 447 | − well documented in the file drivers/scsi/Kconfig. In order to | |
| 448 | − see this documentation, you need to use one of the advanced configuration | |
| 449 | − programs (menuconfig and xconfig). If you are using the "make menuconfig" | |
| 450 | − method of configuring your kernel, then you would simply highlight the | |
| 451 | − option in question and hit the ? key. If you are using the "make xconfig" | |
| 452 | − method of configuring your kernel, then simply click on the help button | |
| 453 | − next to the option you have questions about. The help information from | |
| 454 | − the Configure.help file will then get automatically displayed. | |
| 455 | − | |
| 456 | − /proc support | |
| 457 | − ------------------------------ | |
| 458 | − The /proc support for the AIC7xxx can be found in the /proc/scsi/aic7xxx/ | |
| 459 | − directory. That directory contains a file for each SCSI controller in | |
| 460 | − the system. Each file presents the current configuration and transfer | |
| 461 | − statistics (enabled with #define in aic7xxx.c) for each controller. | |
| 462 | − | |
| 463 | − Thanks to Michael Neuffer for his upper-level SCSI help, and | |
| 464 | − Matthew Jacob for statistics support. | |
| 465 | − | |
| 466 | − Debugging the driver | |
| 467 | − ------------------------------ | |
| 468 | − Should you have problems with this driver, and would like some help in | |
| 469 | − getting them solved, there are a couple debugging items built into | |
| 470 | − the driver to facilitate getting the needed information from the system. | |
| 471 | − In general, I need a complete description of the problem, with as many | |
| 472 | − logs as possible concerning what happens. To help with this, there is | |
| 473 | − a command option aic7xxx=panic_on_abort. This option, when set, forces | |
| 474 | − the driver to panic the kernel on the first SCSI abort issued by the | |
| 475 | − mid level SCSI code. If your system is going to reset loops and you | |
| 476 | − can't read the screen, then this is what you need. Not only will it | |
| 477 | − stop the system, but it also prints out a large amount of state | |
| 478 | − information in the process. Second, if you specify the option | |
| 479 | − "aic7xxx=verbose:0x1ffff", the system will print out *SOOOO* much | |
| 480 | − information as it runs that you won't be able to see anything. | |
| 481 | − However, this can actually be very useful if your machine simply | |
| 482 | − locks up when trying to boot, since it will pin-point what was last | |
| 483 | − happening (in regards to the aic7xxx driver) immediately prior to | |
| 484 | − the lockup. This is really only useful if your machine simply can | |
| 485 | − not boot up successfully. If you can get your machine to run, then | |
| 486 | − this will produce far too much information. | |
| 487 | − | |
| 488 | − FTP sites | |
| 489 | − ------------------------------ | |
| 490 | − ftp://ftp.redhat.com/pub/aic/ | |
| 491 | − - Out of date. I used to keep stuff here, but too many people | |
| 492 | − complained about having a hard time getting into Red Hat's ftp | |
| 493 | − server. So use the web site below instead. | |
| 494 | − ftp://ftp.pcnet.com/users/eischen/Linux/ | |
| 495 | − - Dan Eischen's driver distribution area | |
| 496 | − ftp://ekf2.vsb.cz/pub/linux/kernel/aic7xxx/ftp.teleport.com/ | |
| 497 | − - European Linux mirror of Teleport site | |
| 498 | − | |
| 499 | − Web sites | |
| 500 | − ------------------------------ | |
| 501 | − http://people.redhat.com/dledford/ | |
| 502 | − - My web site, also the primary aic7xxx site with several related | |
| 503 | − pages. | |
| 504 | − | |
| 505 | −Dean W. Gehnert | |
| 506 | −deang@teleport.com | |
| 507 | − | |
| 508 | −$Revision: 3.0 $ | |
| 509 | − | |
| 510 | −Modified by Doug Ledford 1998-2000 | |
| 511 | − | |
| @@ -42,20 +42,14 @@ discussion. · 41 unmodified lines | ||
| 42 | 42 | |
| 43 | 43 | Once LLDD gets hold of a scmd, either the LLDD will complete the |
| 44 | 44 | command by calling scsi_done callback passed from midlayer when |
| 45 | −invoking hostt->queuecommand() or SCSI midlayer will time it out. | |
| 45 | +invoking hostt->queuecommand() or the block layer will time it out. | |
| 46 | 46 | |
| 47 | 47 | |
| 48 | 48 | [1-2-1] Completing a scmd w/ scsi_done |
| 49 | 49 | |
| 50 | 50 | For all non-EH commands, scsi_done() is the completion callback. It |
| 51 | −does the following. | |
| 52 | − | |
| 53 | − 1. Delete timeout timer. If it fails, it means that timeout timer | |
| 54 | − has expired and is going to finish the command. Just return. | |
| 55 | − | |
| 56 | − 2. Link scmd to per-cpu scsi_done_q using scmd->en_entry | |
| 57 | − | |
| 58 | − 3. Raise SCSI_SOFTIRQ | |
| 51 | +just calls blk_complete_request() to delete the block layer timer and | |
| 52 | +raise SCSI_SOFTIRQ | |
| 59 | 53 | |
| 60 | 54 | SCSI_SOFTIRQ handler scsi_softirq calls scsi_decide_disposition() to |
| 61 | 55 | determine what to do with the command. scsi_decide_disposition() |
| @@ -64,10 +58,12 @@ with the command. · 2 unmodified lines | ||
| 64 | 58 | |
| 65 | 59 | - SUCCESS |
| 66 | 60 | scsi_finish_command() is invoked for the command. The |
| 67 | − function does some maintenance choirs and notify completion by | |
| 68 | − calling scmd->done() callback, which, for fs requests, would | |
| 69 | − be HLD completion callback - sd:sd_rw_intr, sr:rw_intr, | |
| 70 | − st:st_intr. | |
| 61 | + function does some maintenance chores and then calls | |
| 62 | + scsi_io_completion() to finish the I/O. | |
| 63 | + scsi_io_completion() then notifies the block layer on | |
| 64 | + the completed request by calling blk_end_request and | |
| 65 | + friends or figures out what to do with the remainder | |
| 66 | + of the data in case of an error. | |
| 71 | 67 | |
| 72 | 68 | - NEEDS_RETRY |
| 73 | 69 | - ADD_TO_MLQUEUE |
| @@ -86,33 +82,45 @@ function · 12 unmodified lines | ||
| 86 | 82 | 1. invokes optional hostt->eh_timed_out() callback. Return value can |
| 87 | 83 | be one of |
| 88 | 84 | |
| 89 | − - EH_HANDLED | |
| 90 | − This indicates that eh_timed_out() dealt with the timeout. The | |
| 91 | − scmd is passed to __scsi_done() and thus linked into per-cpu | |
| 92 | − scsi_done_q. Normal command completion described in [1-2-1] | |
| 93 | − follows. | |
| 85 | + - BLK_EH_HANDLED | |
| 86 | + This indicates that eh_timed_out() dealt with the timeout. | |
| 87 | + The command is passed back to the block layer and completed | |
| 88 | + via __blk_complete_requests(). | |
| 89 | + | |
| 90 | + *NOTE* After returning BLK_EH_HANDLED the SCSI layer is | |
| 91 | + assumed to be finished with the command, and no other | |
| 92 | + functions from the SCSI layer will be called. So this | |
| 93 | + should typically only be returned if the eh_timed_out() | |
| 94 | + handler raced with normal completion. | |
| 94 | 95 | |
| 95 | − - EH_RESET_TIMER | |
| 96 | + - BLK_EH_RESET_TIMER | |
| 96 | 97 | This indicates that more time is required to finish the |
| 97 | 98 | command. Timer is restarted. This action is counted as a |
| 98 | 99 | retry and only allowed scmd->allowed + 1(!) times. Once the |
| 99 | − limit is reached, action for EH_NOT_HANDLED is taken instead. | |
| 100 | + limit is reached, action for BLK_EH_NOT_HANDLED is taken instead. | |
| 100 | 101 | |
| 101 | − *NOTE* This action is racy as the LLDD could finish the scmd | |
| 102 | − after the timeout has expired but before it's added back. In | |
| 103 | − such cases, scsi_done() would think that timeout has occurred | |
| 104 | − and return without doing anything. We lose completion and the | |
| 105 | − command will time out again. | |
| 106 | − | |
| 107 | − - EH_NOT_HANDLED | |
| 108 | − This is the same as when eh_timed_out() callback doesn't exist. | |
| 102 | + - BLK_EH_NOT_HANDLED | |
| 103 | + eh_timed_out() callback did not handle the command. | |
| 109 | 104 | Step #2 is taken. |
| 110 | 105 | |
| 106 | + 2. If the host supports asynchronous completion (as indicated by the | |
| 107 | + no_async_abort setting in the host template) scsi_abort_command() | |
| 108 | + is invoked to schedule an asynchrous abort. If that fails | |
| 109 | + Step #3 is taken. | |
| 110 | + | |
| 111 | 111 | 2. scsi_eh_scmd_add(scmd, SCSI_EH_CANCEL_CMD) is invoked for the |
| 112 | 112 | command. See [1-3] for more information. |
| 113 | 113 | |
| 114 | +[1-3] Asynchronous command aborts | |
| 115 | + | |
| 116 | + After a timeout occurs a command abort is scheduled from | |
| 117 | + scsi_abort_command(). If the abort is successful the command | |
| 118 | + will either be retried (if the number of retries is not exhausted) | |
| 119 | + or terminated with DID_TIME_OUT. | |
| 120 | + Otherwise scsi_eh_scmd_add() is invoked for the command. | |
| 121 | + See [1-4] for more information. | |
| 114 | 122 | |
| 115 | −[1-3] How EH takes over | |
| 123 | +[1-4] How EH takes over | |
| 116 | 124 | |
| 117 | 125 | scmds enter EH via scsi_eh_scmd_add(), which does the following. |
| 118 | 126 | |
| @@ -320,7 +328,8 @@ scmd->allowed. · 201 unmodified lines | ||
| 320 | 328 | |
| 321 | 329 | <<scsi_eh_abort_cmds>> |
| 322 | 330 | |
| 323 | − This action is taken for each timed out command. | |
| 331 | + This action is taken for each timed out command when | |
| 332 | + no_async_abort is enabled in the host template. | |
| 324 | 333 | hostt->eh_abort_handler() is invoked for each scmd. The |
| 325 | 334 | handler returns SUCCESS if it has succeeded to make LLDD and |
| 326 | 335 | all related hardware forget about the scmd. |
| @@ -882,8 +882,11 @@ Details: · 881 unmodified lines | ||
| 882 | 882 | * |
| 883 | 883 | * Calling context: kernel thread |
| 884 | 884 | * |
| 885 | − * Notes: Invoked from scsi_eh thread. No other commands will be | |
| 886 | − * queued on current host during eh. | |
| 885 | + * Notes: If 'no_async_abort' is defined this callback | |
| 886 | + * will be invoked from scsi_eh thread. No other commands | |
| 887 | + * will then be queued on current host during eh. | |
| 888 | + * Otherwise it will be called whenever scsi_times_out() | |
| 889 | + * is called due to a command timeout. | |
| 887 | 890 | * |
| 888 | 891 | * Optionally defined in: LLD |
| 889 | 892 | **/ |
| @@ -1257,6 +1260,8 @@ of interest: · 367 unmodified lines | ||
| 1257 | 1260 | address space |
| 1258 | 1261 | use_clustering - 1=>SCSI commands in mid level's queue can be merged, |
| 1259 | 1262 | 0=>disallow SCSI command merging |
| 1263 | + no_async_abort - 1=>Asynchronous aborts are not supported | |
| 1264 | + 0=>Timed-out commands will be aborted asynchronously | |
| 1260 | 1265 | hostt - pointer to driver's struct scsi_host_template from which |
| 1261 | 1266 | this struct Scsi_Host instance was spawned |
| 1262 | 1267 | hostt->proc_name - name of LLD. This is the driver name that sysfs uses |
| @@ -0,0 +1,7 @@ | ||
| 1 | +all: rport_state_diagram.svg rport_state_diagram.png | |
| 2 | + | |
| 3 | +rport_state_diagram.svg: rport_state_diagram.dot | |
| 4 | + dot -Tsvg -o $@ $< | |
| 5 | + | |
| 6 | +rport_state_diagram.png: rport_state_diagram.dot | |
| 7 | + dot -Tpng -o $@ $< | |
| @@ -0,0 +1,26 @@ | ||
| 1 | +digraph srp_initiator { | |
| 2 | + node [shape = doublecircle]; running lost; | |
| 3 | + node [shape = circle]; | |
| 4 | + | |
| 5 | + { | |
| 6 | + rank = min; | |
| 7 | + running_rta [ label = "running;\nreconnect\ntimer\nactive" ]; | |
| 8 | + }; | |
| 9 | + running [ label = "running;\nreconnect\ntimer\nstopped" ]; | |
| 10 | + blocked; | |
| 11 | + failfast [ label = "fail I/O\nfast" ]; | |
| 12 | + lost; | |
| 13 | + | |
| 14 | + running -> running_rta [ label = "fast_io_fail_tmo = off and\ndev_loss_tmo = off;\nsrp_start_tl_fail_timers()" ]; | |
| 15 | + running_rta -> running [ label = "fast_io_fail_tmo = off and\ndev_loss_tmo = off;\nreconnecting succeeded" ]; | |
| 16 | + running -> blocked [ label = "fast_io_fail_tmo >= 0 or\ndev_loss_tmo >= 0;\nsrp_start_tl_fail_timers()" ]; | |
| 17 | + running -> failfast [ label = "fast_io_fail_tmo = off and\ndev_loss_tmo = off;\nreconnecting failed\n" ]; | |
| 18 | + blocked -> failfast [ label = "fast_io_fail_tmo\nexpired or\nreconnecting\nfailed" ]; | |
| 19 | + blocked -> lost [ label = "dev_loss_tmo\nexpired or\nsrp_stop_rport_timers()" ]; | |
| 20 | + failfast -> lost [ label = "dev_loss_tmo\nexpired or\nsrp_stop_rport_timers()" ]; | |
| 21 | + blocked -> running [ label = "reconnecting\nsucceeded" ]; | |
| 22 | + failfast -> failfast [ label = "reconnecting\nfailed" ]; | |
| 23 | + failfast -> running [ label = "reconnecting\nsucceeded" ]; | |
| 24 | + running -> lost [ label = "srp_stop_rport_timers()" ]; | |
| 25 | + running_rta -> lost [ label = "srp_stop_rport_timers()" ]; | |
| 26 | +} | |
| @@ -67,12 +67,14 @@ descriptors by adding their identifier to the format string · 66 unmodified lines | ||
| 67 | 67 | - 'd-ng': the digest of the event, calculated with an arbitrary hash |
| 68 | 68 | algorithm (field format: [<hash algo>:]digest, where the digest |
| 69 | 69 | prefix is shown only if the hash algorithm is not SHA1 or MD5); |
| 70 | − - 'n-ng': the name of the event, without size limitations. | |
| 70 | + - 'n-ng': the name of the event, without size limitations; | |
| 71 | + - 'sig': the file signature. | |
| 71 | 72 | |
| 72 | 73 | |
| 73 | 74 | Below, there is the list of defined template descriptors: |
| 74 | 75 | - "ima": its format is 'd|n'; |
| 75 | − - "ima-ng" (default): its format is 'd-ng|n-ng'. | |
| 76 | + - "ima-ng" (default): its format is 'd-ng|n-ng'; | |
| 77 | + - "ima-sig": its format is 'd-ng|n-ng|sig'. | |
| 76 | 78 | |
| 77 | 79 | |
| 78 | 80 | |
| @@ -49,18 +49,23 @@ features :- · 48 unmodified lines | ||
| 49 | 49 | * Machine specific controls: Allow machines to add controls to the sound card |
| 50 | 50 | (e.g. volume control for speaker amplifier). |
| 51 | 51 | |
| 52 | −To achieve all this, ASoC basically splits an embedded audio system into 3 | |
| 53 | −components :- | |
| 52 | +To achieve all this, ASoC basically splits an embedded audio system into | |
| 53 | +multiple re-usable component drivers :- | |
| 54 | 54 | |
| 55 | − * Codec driver: The codec driver is platform independent and contains audio | |
| 56 | − controls, audio interface capabilities, codec DAPM definition and codec IO | |
| 57 | − functions. | |
| 55 | + * Codec class drivers: The codec class driver is platform independent and | |
| 56 | + contains audio controls, audio interface capabilities, codec DAPM | |
| 57 | + definition and codec IO functions. This class extends to BT, FM and MODEM | |
| 58 | + ICs if required. Codec class drivers should be generic code that can run | |
| 59 | + on any architecture and machine. | |
| 58 | 60 | |
| 59 | − * Platform driver: The platform driver contains the audio DMA engine and audio | |
| 60 | − interface drivers (e.g. I2S, AC97, PCM) for that platform. | |
| 61 | + * Platform class drivers: The platform class driver includes the audio DMA | |
| 62 | + engine driver, digital audio interface (DAI) drivers (e.g. I2S, AC97, PCM) | |
| 63 | + and any audio DSP drivers for that platform. | |
| 61 | 64 | |
| 62 | − * Machine driver: The machine driver handles any machine specific controls and | |
| 63 | − audio events (e.g. turning on an amp at start of playback). | |
| 65 | + * Machine class driver: The machine driver class acts as the glue that | |
| 66 | + decribes and binds the other component drivers together to form an ALSA | |
| 67 | + "sound card device". It handles any machine specific controls and | |
| 68 | + machine level audio events (e.g. turning on an amp at start of playback). | |
| 64 | 69 | |
| 65 | 70 | |
| 66 | 71 | Documentation |
| @@ -84,3 +89,7 @@ machine.txt: Machine driver internals. · 17 unmodified lines | ||
| 84 | 89 | pop_clicks.txt: How to minimise audio artifacts. |
| 85 | 90 | |
| 86 | 91 | clocking.txt: ASoC clocking for best power performance. |
| 92 | + | |
| 93 | +jack.txt: ASoC jack detection. | |
| 94 | + | |
| 95 | +DPCM.txt: Dynamic PCM - Describes DPCM with DSP examples. | |
| @@ -34,7 +34,7 @@ SPI slave functions are usually not interoperable between vendors · 33 unmodified lines | ||
| 34 | 34 | - It may also be used to stream data in either direction (half duplex), |
| 35 | 35 | or both of them at the same time (full duplex). |
| 36 | 36 | |
| 37 | − - Some devices may use eight bit words. Others may different word | |
| 37 | + - Some devices may use eight bit words. Others may use different word | |
| 38 | 38 | lengths, such as streams of 12-bit or 20-bit digital samples. |
| 39 | 39 | |
| 40 | 40 | - Words are usually sent with their most significant bit (MSB) first, |
| @@ -121,7 +121,7 @@ active. So the master must set the clock to inactive before selecting · 80 unmodified lines | ||
| 121 | 121 | a slave, and the slave can tell the chosen polarity by sampling the |
| 122 | 122 | clock level when its select line goes active. That's why many devices |
| 123 | 123 | support for example both modes 0 and 3: they don't care about polarity, |
| 124 | −and alway clock data in/out on rising clock edges. | |
| 124 | +and always clock data in/out on rising clock edges. | |
| 125 | 125 | |
| 126 | 126 | |
| 127 | 127 | How do these driver programming interfaces work? |
| @@ -139,7 +139,7 @@ a command and then reading its response. · 11 unmodified lines | ||
| 139 | 139 | |
| 140 | 140 | There are two types of SPI driver, here called: |
| 141 | 141 | |
| 142 | − Controller drivers ... controllers may be built in to System-On-Chip | |
| 142 | + Controller drivers ... controllers may be built into System-On-Chip | |
| 143 | 143 | processors, and often support both Master and Slave roles. |
| 144 | 144 | These drivers touch hardware registers and may use DMA. |
| 145 | 145 | Or they can be PIO bitbangers, needing just GPIO pins. |
| @@ -548,7 +548,7 @@ SPI MASTER METHODS · 402 unmodified lines | ||
| 548 | 548 | DEPRECATED METHODS |
| 549 | 549 | |
| 550 | 550 | master->transfer(struct spi_device *spi, struct spi_message *message) |
| 551 | − This must not sleep. Its responsibility is arrange that the | |
| 551 | + This must not sleep. Its responsibility is to arrange that the | |
| 552 | 552 | transfer happens and its complete() callback is issued. The two |
| 553 | 553 | will normally happen later, after other transfers complete, and |
| 554 | 554 | if the controller is idle it will need to be kickstarted. This |
| @@ -116,7 +116,7 @@ The branch(es) can then be switched via: · 115 unmodified lines | ||
| 116 | 116 | static_key_slow_dec(&key); |
| 117 | 117 | |
| 118 | 118 | Thus, 'static_key_slow_inc()' means 'make the branch true', and |
| 119 | −'static_key_slow_dec()' means 'make the the branch false' with appropriate | |
| 119 | +'static_key_slow_dec()' means 'make the branch false' with appropriate | |
| 120 | 120 | reference counting. For example, if the key is initialized true, a |
| 121 | 121 | static_key_slow_dec(), will switch the branch to false. And a subsequent |
| 122 | 122 | static_key_slow_inc(), will change the branch back to true. Likewise, if the |
| @@ -236,7 +236,7 @@ label case adds: · 113 unmodified lines | ||
| 236 | 236 | |
| 237 | 237 | If we then include the padding bytes, the jump label code saves, 16 total bytes |
| 238 | 238 | of instruction memory for this small function. In this case the non-jump label |
| 239 | −function is 80 bytes long. Thus, we have have saved 20% of the instruction | |
| 239 | +function is 80 bytes long. Thus, we have saved 20% of the instruction | |
| 240 | 240 | footprint. We can in fact improve this even further, since the 5-byte no-op |
| 241 | 241 | really can be a 2-byte no-op since we can reach the branch with a 2-byte jmp. |
| 242 | 242 | However, we have not yet implemented optimal no-op sizes (they are currently |
| @@ -33,6 +33,11 @@ show up in /proc/sys/kernel: · 32 unmodified lines | ||
| 33 | 33 | - domainname |
| 34 | 34 | - hostname |
| 35 | 35 | - hotplug |
| 36 | +- hung_task_panic | |
| 37 | +- hung_task_check_count | |
| 38 | +- hung_task_timeout_secs | |
| 39 | +- hung_task_warnings | |
| 40 | +- kexec_load_disabled | |
| 36 | 41 | - kptr_restrict |
| 37 | 42 | - kstack_depth_to_print [ X86 only ] |
| 38 | 43 | - l2cr [ PPC only ] |
| @@ -287,6 +292,56 @@ Default value is "/sbin/hotplug". · 248 unmodified lines | ||
| 287 | 292 | |
| 288 | 293 | ============================================================== |
| 289 | 294 | |
| 295 | +hung_task_panic: | |
| 296 | + | |
| 297 | +Controls the kernel's behavior when a hung task is detected. | |
| 298 | +This file shows up if CONFIG_DETECT_HUNG_TASK is enabled. | |
| 299 | + | |
| 300 | +0: continue operation. This is the default behavior. | |
| 301 | + | |
| 302 | +1: panic immediately. | |
| 303 | + | |
| 304 | +============================================================== | |
| 305 | + | |
| 306 | +hung_task_check_count: | |
| 307 | + | |
| 308 | +The upper bound on the number of tasks that are checked. | |
| 309 | +This file shows up if CONFIG_DETECT_HUNG_TASK is enabled. | |
| 310 | + | |
| 311 | +============================================================== | |
| 312 | + | |
| 313 | +hung_task_timeout_secs: | |
| 314 | + | |
| 315 | +Check interval. When a task in D state did not get scheduled | |
| 316 | +for more than this value report a warning. | |
| 317 | +This file shows up if CONFIG_DETECT_HUNG_TASK is enabled. | |
| 318 | + | |
| 319 | +0: means infinite timeout - no checking done. | |
| 320 | + | |
| 321 | +============================================================== | |
| 322 | + | |
| 323 | +hung_task_warning: | |
| 324 | + | |
| 325 | +The maximum number of warnings to report. During a check interval | |
| 326 | +When this value is reached, no more the warnings will be reported. | |
| 327 | +This file shows up if CONFIG_DETECT_HUNG_TASK is enabled. | |
| 328 | + | |
| 329 | +-1: report an infinite number of warnings. | |
| 330 | + | |
| 331 | +============================================================== | |
| 332 | + | |
| 333 | +kexec_load_disabled: | |
| 334 | + | |
| 335 | +A toggle indicating if the kexec_load syscall has been disabled. This | |
| 336 | +value defaults to 0 (false: kexec_load enabled), but can be set to 1 | |
| 337 | +(true: kexec_load disabled). Once true, kexec can no longer be used, and | |
| 338 | +the toggle cannot be set back to false. This allows a kexec image to be | |
| 339 | +loaded before disabling the syscall, allowing a system to set up (and | |
| 340 | +later use) an image without it being altered. Generally used together | |
| 341 | +with the "modules_disabled" sysctl. | |
| 342 | + | |
| 343 | +============================================================== | |
| 344 | + | |
| 290 | 345 | kptr_restrict: |
| 291 | 346 | |
| 292 | 347 | This toggle indicates whether restrictions are placed on |
| @@ -331,7 +386,7 @@ A toggle value indicating if modules are allowed to be loaded · 38 unmodified lines | ||
| 331 | 386 | in an otherwise modular kernel. This toggle defaults to off |
| 332 | 387 | (0), but can be set true (1). Once true, modules can be |
| 333 | 388 | neither loaded nor unloaded, and the toggle cannot be set back |
| 334 | −to false. | |
| 389 | +to false. Generally used with the "kexec_load_disabled" toggle. | |
| 335 | 390 | |
| 336 | 391 | ============================================================== |
| 337 | 392 | |
| @@ -47,6 +47,7 @@ Currently, these files are in /proc/sys/vm: · 46 unmodified lines | ||
| 47 | 47 | - numa_zonelist_order |
| 48 | 48 | - oom_dump_tasks |
| 49 | 49 | - oom_kill_allocating_task |
| 50 | +- overcommit_kbytes | |
| 50 | 51 | - overcommit_memory |
| 51 | 52 | - overcommit_ratio |
| 52 | 53 | - page-cluster |
| @@ -574,6 +575,17 @@ The default value is 0. · 521 unmodified lines | ||
| 574 | 575 | |
| 575 | 576 | ============================================================== |
| 576 | 577 | |
| 578 | +overcommit_kbytes: | |
| 579 | + | |
| 580 | +When overcommit_memory is set to 2, the committed address space is not | |
| 581 | +permitted to exceed swap plus this amount of physical RAM. See below. | |
| 582 | + | |
| 583 | +Note: overcommit_kbytes is the counterpart of overcommit_ratio. Only one | |
| 584 | +of them may be specified at a time. Setting one disables the other (which | |
| 585 | +then appears as 0 when read). | |
| 586 | + | |
| 587 | +============================================================== | |
| 588 | + | |
| 577 | 589 | overcommit_memory: |
| 578 | 590 | |
| 579 | 591 | This value contains a flag that enables memory overcommitment. |
| @@ -684,7 +696,9 @@ swappiness · 104 unmodified lines | ||
| 684 | 696 | |
| 685 | 697 | This control is used to define how aggressive the kernel will swap |
| 686 | 698 | memory pages. Higher values will increase agressiveness, lower values |
| 687 | −decrease the amount of swap. | |
| 699 | +decrease the amount of swap. A value of 0 instructs the kernel not to | |
| 700 | +initiate swap until the amount of free and file-backed pages is less | |
| 701 | +than the high water mark in a zone. | |
| 688 | 702 | |
| 689 | 703 | The default value is 60. |
| 690 | 704 | |
| @@ -287,3 +287,210 @@ their old filters): · 286 unmodified lines | ||
| 287 | 287 | prev_pid == 0 |
| 288 | 288 | # cat sched_wakeup/filter |
| 289 | 289 | common_pid == 0 |
| 290 | + | |
| 291 | +6. Event triggers | |
| 292 | +================= | |
| 293 | + | |
| 294 | +Trace events can be made to conditionally invoke trigger 'commands' | |
| 295 | +which can take various forms and are described in detail below; | |
| 296 | +examples would be enabling or disabling other trace events or invoking | |
| 297 | +a stack trace whenever the trace event is hit. Whenever a trace event | |
| 298 | +with attached triggers is invoked, the set of trigger commands | |
| 299 | +associated with that event is invoked. Any given trigger can | |
| 300 | +additionally have an event filter of the same form as described in | |
| 301 | +section 5 (Event filtering) associated with it - the command will only | |
| 302 | +be invoked if the event being invoked passes the associated filter. | |
| 303 | +If no filter is associated with the trigger, it always passes. | |
| 304 | + | |
| 305 | +Triggers are added to and removed from a particular event by writing | |
| 306 | +trigger expressions to the 'trigger' file for the given event. | |
| 307 | + | |
| 308 | +A given event can have any number of triggers associated with it, | |
| 309 | +subject to any restrictions that individual commands may have in that | |
| 310 | +regard. | |
| 311 | + | |
| 312 | +Event triggers are implemented on top of "soft" mode, which means that | |
| 313 | +whenever a trace event has one or more triggers associated with it, | |
| 314 | +the event is activated even if it isn't actually enabled, but is | |
| 315 | +disabled in a "soft" mode. That is, the tracepoint will be called, | |
| 316 | +but just will not be traced, unless of course it's actually enabled. | |
| 317 | +This scheme allows triggers to be invoked even for events that aren't | |
| 318 | +enabled, and also allows the current event filter implementation to be | |
| 319 | +used for conditionally invoking triggers. | |
| 320 | + | |
| 321 | +The syntax for event triggers is roughly based on the syntax for | |
| 322 | +set_ftrace_filter 'ftrace filter commands' (see the 'Filter commands' | |
| 323 | +section of Documentation/trace/ftrace.txt), but there are major | |
| 324 | +differences and the implementation isn't currently tied to it in any | |
| 325 | +way, so beware about making generalizations between the two. | |
| 326 | + | |
| 327 | +6.1 Expression syntax | |
| 328 | +--------------------- | |
| 329 | + | |
| 330 | +Triggers are added by echoing the command to the 'trigger' file: | |
| 331 | + | |
| 332 | + # echo 'command[:count] [if filter]' > trigger | |
| 333 | + | |
| 334 | +Triggers are removed by echoing the same command but starting with '!' | |
| 335 | +to the 'trigger' file: | |
| 336 | + | |
| 337 | + # echo '!command[:count] [if filter]' > trigger | |
| 338 | + | |
| 339 | +The [if filter] part isn't used in matching commands when removing, so | |
| 340 | +leaving that off in a '!' command will accomplish the same thing as | |
| 341 | +having it in. | |
| 342 | + | |
| 343 | +The filter syntax is the same as that described in the 'Event | |
| 344 | +filtering' section above. | |
| 345 | + | |
| 346 | +For ease of use, writing to the trigger file using '>' currently just | |
| 347 | +adds or removes a single trigger and there's no explicit '>>' support | |
| 348 | +('>' actually behaves like '>>') or truncation support to remove all | |
| 349 | +triggers (you have to use '!' for each one added.) | |
| 350 | + | |
| 351 | +6.2 Supported trigger commands | |
| 352 | +------------------------------ | |
| 353 | + | |
| 354 | +The following commands are supported: | |
| 355 | + | |
| 356 | +- enable_event/disable_event | |
| 357 | + | |
| 358 | + These commands can enable or disable another trace event whenever | |
| 359 | + the triggering event is hit. When these commands are registered, | |
| 360 | + the other trace event is activated, but disabled in a "soft" mode. | |
| 361 | + That is, the tracepoint will be called, but just will not be traced. | |
| 362 | + The event tracepoint stays in this mode as long as there's a trigger | |
| 363 | + in effect that can trigger it. | |
| 364 | + | |
| 365 | + For example, the following trigger causes kmalloc events to be | |
| 366 | + traced when a read system call is entered, and the :1 at the end | |
| 367 | + specifies that this enablement happens only once: | |
| 368 | + | |
| 369 | + # echo 'enable_event:kmem:kmalloc:1' > \ | |
| 370 | + /sys/kernel/debug/tracing/events/syscalls/sys_enter_read/trigger | |
| 371 | + | |
| 372 | + The following trigger causes kmalloc events to stop being traced | |
| 373 | + when a read system call exits. This disablement happens on every | |
| 374 | + read system call exit: | |
| 375 | + | |
| 376 | + # echo 'disable_event:kmem:kmalloc' > \ | |
| 377 | + /sys/kernel/debug/tracing/events/syscalls/sys_exit_read/trigger | |
| 378 | + | |
| 379 | + The format is: | |
| 380 | + | |
| 381 | + enable_event:<system>:<event>[:count] | |
| 382 | + disable_event:<system>:<event>[:count] | |
| 383 | + | |
| 384 | + To remove the above commands: | |
| 385 | + | |
| 386 | + # echo '!enable_event:kmem:kmalloc:1' > \ | |
| 387 | + /sys/kernel/debug/tracing/events/syscalls/sys_enter_read/trigger | |
| 388 | + | |
| 389 | + # echo '!disable_event:kmem:kmalloc' > \ | |
| 390 | + /sys/kernel/debug/tracing/events/syscalls/sys_exit_read/trigger | |
| 391 | + | |
| 392 | + Note that there can be any number of enable/disable_event triggers | |
| 393 | + per triggering event, but there can only be one trigger per | |
| 394 | + triggered event. e.g. sys_enter_read can have triggers enabling both | |
| 395 | + kmem:kmalloc and sched:sched_switch, but can't have two kmem:kmalloc | |
| 396 | + versions such as kmem:kmalloc and kmem:kmalloc:1 or 'kmem:kmalloc if | |
| 397 | + bytes_req == 256' and 'kmem:kmalloc if bytes_alloc == 256' (they | |
| 398 | + could be combined into a single filter on kmem:kmalloc though). | |
| 399 | + | |
| 400 | +- stacktrace | |
| 401 | + | |
| 402 | + This command dumps a stacktrace in the trace buffer whenever the | |
| 403 | + triggering event occurs. | |
| 404 | + | |
| 405 | + For example, the following trigger dumps a stacktrace every time the | |
| 406 | + kmalloc tracepoint is hit: | |
| 407 | + | |
| 408 | + # echo 'stacktrace' > \ | |
| 409 | + /sys/kernel/debug/tracing/events/kmem/kmalloc/trigger | |
| 410 | + | |
| 411 | + The following trigger dumps a stacktrace the first 5 times a kmalloc | |
| 412 | + request happens with a size >= 64K | |
| 413 | + | |
| 414 | + # echo 'stacktrace:5 if bytes_req >= 65536' > \ | |
| 415 | + /sys/kernel/debug/tracing/events/kmem/kmalloc/trigger | |
| 416 | + | |
| 417 | + The format is: | |
| 418 | + | |
| 419 | + stacktrace[:count] | |
| 420 | + | |
| 421 | + To remove the above commands: | |
| 422 | + | |
| 423 | + # echo '!stacktrace' > \ | |
| 424 | + /sys/kernel/debug/tracing/events/kmem/kmalloc/trigger | |
| 425 | + | |
| 426 | + # echo '!stacktrace:5 if bytes_req >= 65536' > \ | |
| 427 | + /sys/kernel/debug/tracing/events/kmem/kmalloc/trigger | |
| 428 | + | |
| 429 | + The latter can also be removed more simply by the following (without | |
| 430 | + the filter): | |
| 431 | + | |
| 432 | + # echo '!stacktrace:5' > \ | |
| 433 | + /sys/kernel/debug/tracing/events/kmem/kmalloc/trigger | |
| 434 | + | |
| 435 | + Note that there can be only one stacktrace trigger per triggering | |
| 436 | + event. | |
| 437 | + | |
| 438 | +- snapshot | |
| 439 | + | |
| 440 | + This command causes a snapshot to be triggered whenever the | |
| 441 | + triggering event occurs. | |
| 442 | + | |
| 443 | + The following command creates a snapshot every time a block request | |
| 444 | + queue is unplugged with a depth > 1. If you were tracing a set of | |
| 445 | + events or functions at the time, the snapshot trace buffer would | |
| 446 | + capture those events when the trigger event occured: | |
| 447 | + | |
| 448 | + # echo 'snapshot if nr_rq > 1' > \ | |
| 449 | + /sys/kernel/debug/tracing/events/block/block_unplug/trigger | |
| 450 | + | |
| 451 | + To only snapshot once: | |
| 452 | + | |
| 453 | + # echo 'snapshot:1 if nr_rq > 1' > \ | |
| 454 | + /sys/kernel/debug/tracing/events/block/block_unplug/trigger | |
| 455 | + | |
| 456 | + To remove the above commands: | |
| 457 | + | |
| 458 | + # echo '!snapshot if nr_rq > 1' > \ | |
| 459 | + /sys/kernel/debug/tracing/events/block/block_unplug/trigger | |
| 460 | + | |
| 461 | + # echo '!snapshot:1 if nr_rq > 1' > \ | |
| 462 | + /sys/kernel/debug/tracing/events/block/block_unplug/trigger | |
| 463 | + | |
| 464 | + Note that there can be only one snapshot trigger per triggering | |
| 465 | + event. | |
| 466 | + | |
| 467 | +- traceon/traceoff | |
| 468 | + | |
| 469 | + These commands turn tracing on and off when the specified events are | |
| 470 | + hit. The parameter determines how many times the tracing system is | |
| 471 | + turned on and off. If unspecified, there is no limit. | |
| 472 | + | |
| 473 | + The following command turns tracing off the first time a block | |
| 474 | + request queue is unplugged with a depth > 1. If you were tracing a | |
| 475 | + set of events or functions at the time, you could then examine the | |
| 476 | + trace buffer to see the sequence of events that led up to the | |
| 477 | + trigger event: | |
| 478 | + | |
| 479 | + # echo 'traceoff:1 if nr_rq > 1' > \ | |
| 480 | + /sys/kernel/debug/tracing/events/block/block_unplug/trigger | |
| 481 | + | |
| 482 | + To always disable tracing when nr_rq > 1 : | |
| 483 | + | |
| 484 | + # echo 'traceoff if nr_rq > 1' > \ | |
| 485 | + /sys/kernel/debug/tracing/events/block/block_unplug/trigger | |
| 486 | + | |
| 487 | + To remove the above commands: | |
| 488 | + | |
| 489 | + # echo '!traceoff:1 if nr_rq > 1' > \ | |
| 490 | + /sys/kernel/debug/tracing/events/block/block_unplug/trigger | |
| 491 | + | |
| 492 | + # echo '!traceoff if nr_rq > 1' > \ | |
| 493 | + /sys/kernel/debug/tracing/events/block/block_unplug/trigger | |
| 494 | + | |
| 495 | + Note that there can be only one traceon or traceoff trigger per | |
| 496 | + triggering event. | |
| @@ -123,7 +123,7 @@ my $regex_writepage; · 122 unmodified lines | ||
| 123 | 123 | |
| 124 | 124 | # Static regex used. Specified like this for readability and for use with /o |
| 125 | 125 | # (process_pid) (cpus ) ( time ) (tpoint ) (details) |
| 126 | −my $regex_traceevent = '\s*([a-zA-Z0-9-]*)\s*(\[[0-9]*\])\s*([0-9.]*):\s*([a-zA-Z_]*):\s*(.*)'; | |
| 126 | +my $regex_traceevent = '\s*([a-zA-Z0-9-]*)\s*(\[[0-9]*\])(\s*[dX.][Nnp.][Hhs.][0-9a-fA-F.]*|)\s*([0-9.]*):\s*([a-zA-Z_]*):\s*(.*)'; | |
| 127 | 127 | my $regex_statname = '[-0-9]*\s\((.*)\).*'; |
| 128 | 128 | my $regex_statppid = '[-0-9]*\s\(.*\)\s[A-Za-z]\s([0-9]*).*'; |
| 129 | 129 | |
| @@ -270,8 +270,8 @@ EVENT_PROCESS: · 140 unmodified lines | ||
| 270 | 270 | while ($traceevent = <STDIN>) { |
| 271 | 271 | if ($traceevent =~ /$regex_traceevent/o) { |
| 272 | 272 | $process_pid = $1; |
| 273 | − $timestamp = $3; | |
| 274 | − $tracepoint = $4; | |
| 273 | + $timestamp = $4; | |
| 274 | + $tracepoint = $5; | |
| 275 | 275 | |
| 276 | 276 | $process_pid =~ /(.*)-([0-9]*)$/; |
| 277 | 277 | my $process = $1; |
| @@ -299,7 +299,7 @@ EVENT_PROCESS: · 21 unmodified lines | ||
| 299 | 299 | $perprocesspid{$process_pid}->{MM_VMSCAN_DIRECT_RECLAIM_BEGIN}++; |
| 300 | 300 | $perprocesspid{$process_pid}->{STATE_DIRECT_BEGIN} = $timestamp; |
| 301 | 301 | |
| 302 | − $details = $5; | |
| 302 | + $details = $6; | |
| 303 | 303 | if ($details !~ /$regex_direct_begin/o) { |
| 304 | 304 | print "WARNING: Failed to parse mm_vmscan_direct_reclaim_begin as expected\n"; |
| 305 | 305 | print " $details\n"; |
| @@ -322,7 +322,7 @@ EVENT_PROCESS: · 16 unmodified lines | ||
| 322 | 322 | $perprocesspid{$process_pid}->{HIGH_DIRECT_RECLAIM_LATENCY}[$index] = "$order-$latency"; |
| 323 | 323 | } |
| 324 | 324 | } elsif ($tracepoint eq "mm_vmscan_kswapd_wake") { |
| 325 | − $details = $5; | |
| 325 | + $details = $6; | |
| 326 | 326 | if ($details !~ /$regex_kswapd_wake/o) { |
| 327 | 327 | print "WARNING: Failed to parse mm_vmscan_kswapd_wake as expected\n"; |
| 328 | 328 | print " $details\n"; |
| @@ -356,7 +356,7 @@ EVENT_PROCESS: · 27 unmodified lines | ||
| 356 | 356 | } elsif ($tracepoint eq "mm_vmscan_wakeup_kswapd") { |
| 357 | 357 | $perprocesspid{$process_pid}->{MM_VMSCAN_WAKEUP_KSWAPD}++; |
| 358 | 358 | |
| 359 | − $details = $5; | |
| 359 | + $details = $6; | |
| 360 | 360 | if ($details !~ /$regex_wakeup_kswapd/o) { |
| 361 | 361 | print "WARNING: Failed to parse mm_vmscan_wakeup_kswapd as expected\n"; |
| 362 | 362 | print " $details\n"; |
| @@ -366,7 +366,7 @@ EVENT_PROCESS: · 3 unmodified lines | ||
| 366 | 366 | my $order = $3; |
| 367 | 367 | $perprocesspid{$process_pid}->{MM_VMSCAN_WAKEUP_KSWAPD_PERORDER}[$order]++; |
| 368 | 368 | } elsif ($tracepoint eq "mm_vmscan_lru_isolate") { |
| 369 | − $details = $5; | |
| 369 | + $details = $6; | |
| 370 | 370 | if ($details !~ /$regex_lru_isolate/o) { |
| 371 | 371 | print "WARNING: Failed to parse mm_vmscan_lru_isolate as expected\n"; |
| 372 | 372 | print " $details\n"; |
| @@ -387,7 +387,7 @@ EVENT_PROCESS: · 14 unmodified lines | ||
| 387 | 387 | } |
| 388 | 388 | $perprocesspid{$process_pid}->{HIGH_NR_CONTIG_DIRTY} += $nr_contig_dirty; |
| 389 | 389 | } elsif ($tracepoint eq "mm_vmscan_lru_shrink_inactive") { |
| 390 | − $details = $5; | |
| 390 | + $details = $6; | |
| 391 | 391 | if ($details !~ /$regex_lru_shrink_inactive/o) { |
| 392 | 392 | print "WARNING: Failed to parse mm_vmscan_lru_shrink_inactive as expected\n"; |
| 393 | 393 | print " $details\n"; |
| @@ -397,7 +397,7 @@ EVENT_PROCESS: · 3 unmodified lines | ||
| 397 | 397 | my $nr_reclaimed = $4; |
| 398 | 398 | $perprocesspid{$process_pid}->{HIGH_NR_RECLAIMED} += $nr_reclaimed; |
| 399 | 399 | } elsif ($tracepoint eq "mm_vmscan_writepage") { |
| 400 | − $details = $5; | |
| 400 | + $details = $6; | |
| 401 | 401 | if ($details !~ /$regex_writepage/o) { |
| 402 | 402 | print "WARNING: Failed to parse mm_vmscan_writepage as expected\n"; |
| 403 | 403 | print " $details\n"; |
| @@ -19,18 +19,44 @@ user to calculate the offset of the probepoint in the object. · 18 unmodified lines | ||
| 19 | 19 | |
| 20 | 20 | Synopsis of uprobe_tracer |
| 21 | 21 | ------------------------- |
| 22 | − p[:[GRP/]EVENT] PATH:SYMBOL[+offs] [FETCHARGS] : Set a uprobe | |
| 23 | − r[:[GRP/]EVENT] PATH:SYMBOL[+offs] [FETCHARGS] : Set a return uprobe (uretprobe) | |
| 24 | − -:[GRP/]EVENT : Clear uprobe or uretprobe event | |
| 22 | + p[:[GRP/]EVENT] PATH:OFFSET [FETCHARGS] : Set a uprobe | |
| 23 | + r[:[GRP/]EVENT] PATH:OFFSET [FETCHARGS] : Set a return uprobe (uretprobe) | |
| 24 | + -:[GRP/]EVENT : Clear uprobe or uretprobe event | |
| 25 | 25 | |
| 26 | 26 | GRP : Group name. If omitted, "uprobes" is the default value. |
| 27 | 27 | EVENT : Event name. If omitted, the event name is generated based |
| 28 | − on SYMBOL+offs. | |
| 28 | + on PATH+OFFSET. | |
| 29 | 29 | PATH : Path to an executable or a library. |
| 30 | − SYMBOL[+offs] : Symbol+offset where the probe is inserted. | |
| 30 | + OFFSET : Offset where the probe is inserted. | |
| 31 | 31 | |
| 32 | 32 | FETCHARGS : Arguments. Each probe can have up to 128 args. |
| 33 | 33 | %REG : Fetch register REG |
| 34 | + @ADDR : Fetch memory at ADDR (ADDR should be in userspace) | |
| 35 | + @+OFFSET : Fetch memory at OFFSET (OFFSET from same file as PATH) | |
| 36 | + $stackN : Fetch Nth entry of stack (N >= 0) | |
| 37 | + $stack : Fetch stack address. | |
| 38 | + $retval : Fetch return value.(*) | |
| 39 | + +|-offs(FETCHARG) : Fetch memory at FETCHARG +|- offs address.(**) | |
| 40 | + NAME=FETCHARG : Set NAME as the argument name of FETCHARG. | |
| 41 | + FETCHARG:TYPE : Set TYPE as the type of FETCHARG. Currently, basic types | |
| 42 | + (u8/u16/u32/u64/s8/s16/s32/s64), "string" and bitfield | |
| 43 | + are supported. | |
| 44 | + | |
| 45 | + (*) only for return probe. | |
| 46 | + (**) this is useful for fetching a field of data structures. | |
| 47 | + | |
| 48 | +Types | |
| 49 | +----- | |
| 50 | +Several types are supported for fetch-args. Uprobe tracer will access memory | |
| 51 | +by given type. Prefix 's' and 'u' means those types are signed and unsigned | |
| 52 | +respectively. Traced arguments are shown in decimal (signed) or hex (unsigned). | |
| 53 | +String type is a special type, which fetches a "null-terminated" string from | |
| 54 | +user space. | |
| 55 | +Bitfield is another special type, which takes 3 parameters, bit-width, bit- | |
| 56 | +offset, and container-size (usually 32). The syntax is; | |
| 57 | + | |
| 58 | + b<bit-width>@<bit-offset>/<container-size> | |
| 59 | + | |
| 34 | 60 | |
| 35 | 61 | Event Profiling |
| 36 | 62 | --------------- |
| @@ -137,24 +137,34 @@ Code that causes unaligned access · 136 unmodified lines | ||
| 137 | 137 | ================================= |
| 138 | 138 | |
| 139 | 139 | With the above in mind, let's move onto a real life example of a function |
| 140 | −that can cause an unaligned memory access. The following function adapted | |
| 140 | +that can cause an unaligned memory access. The following function taken | |
| 141 | 141 | from include/linux/etherdevice.h is an optimized routine to compare two |
| 142 | 142 | ethernet MAC addresses for equality. |
| 143 | 143 | |
| 144 | −unsigned int compare_ether_addr(const u8 *addr1, const u8 *addr2) | |
| 144 | +bool ether_addr_equal(const u8 *addr1, const u8 *addr2) | |
| 145 | 145 | { |
| 146 | − const u16 *a = (const u16 *) addr1; | |
| 147 | − const u16 *b = (const u16 *) addr2; | |
| 146 | +#ifdef CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS | |
| 147 | + u32 fold = ((*(const u32 *)addr1) ^ (*(const u32 *)addr2)) | | |
| 148 | + ((*(const u16 *)(addr1 + 4)) ^ (*(const u16 *)(addr2 + 4))); | |
| 149 | + | |
| 150 | + return fold == 0; | |
| 151 | +#else | |
| 152 | + const u16 *a = (const u16 *)addr1; | |
| 153 | + const u16 *b = (const u16 *)addr2; | |
| 148 | 154 | return ((a[0] ^ b[0]) | (a[1] ^ b[1]) | (a[2] ^ b[2])) != 0; |
| 155 | +#endif | |
| 149 | 156 | } |
| 150 | 157 | |
| 151 | −In the above function, the reference to a[0] causes 2 bytes (16 bits) to | |
| 152 | −be read from memory starting at address addr1. Think about what would happen | |
| 153 | −if addr1 was an odd address such as 0x10003. (Hint: it'd be an unaligned | |
| 154 | −access.) | |
| 158 | +In the above function, when the hardware has efficient unaligned access | |
| 159 | +capability, there is no issue with this code. But when the hardware isn't | |
| 160 | +able to access memory on arbitrary boundaries, the reference to a[0] causes | |
| 161 | +2 bytes (16 bits) to be read from memory starting at address addr1. | |
| 162 | + | |
| 163 | +Think about what would happen if addr1 was an odd address such as 0x10003. | |
| 164 | +(Hint: it'd be an unaligned access.) | |
| 155 | 165 | |
| 156 | 166 | Despite the potential unaligned access problems with the above function, it |
| 157 | −is included in the kernel anyway but is understood to only work on | |
| 167 | +is included in the kernel anyway but is understood to only work normally on | |
| 158 | 168 | 16-bit-aligned addresses. It is up to the caller to ensure this alignment or |
| 159 | 169 | not use this function at all. This alignment-unsafe function is still useful |
| 160 | 170 | as it is a decent optimization for the cases when you can ensure alignment, |
| @@ -14,7 +14,7 @@ A CDC ECM (Ethernet) function may be turned on via a Kconfig option · 13 unmodified lines | ||
| 14 | 14 | and RNDIS can be turned off. If they are both enabled the gadget will |
| 15 | 15 | have two configurations -- one with RNDIS and another with CDC ECM[3]. |
| 16 | 16 | |
| 17 | −Please not that if you use non-standard configuration (that is enable | |
| 17 | +Please note that if you use non-standard configuration (that is enable | |
| 18 | 18 | CDC ECM) you may need to change vendor and/or product ID. |
| 19 | 19 | |
| 20 | 20 | * Host drivers |
| @@ -0,0 +1,60 @@ | ||
| 1 | + OMAP4 ISS Driver | |
| 2 | + ================ | |
| 3 | + | |
| 4 | +Introduction | |
| 5 | +------------ | |
| 6 | + | |
| 7 | +The OMAP44XX family of chips contains the Imaging SubSystem (a.k.a. ISS), | |
| 8 | +Which contains several components that can be categorized in 3 big groups: | |
| 9 | + | |
| 10 | +- Interfaces (2 Interfaces: CSI2-A & CSI2-B/CCP2) | |
| 11 | +- ISP (Image Signal Processor) | |
| 12 | +- SIMCOP (Still Image Coprocessor) | |
| 13 | + | |
| 14 | +For more information, please look in [1] for latest version of: | |
| 15 | + "OMAP4430 Multimedia Device Silicon Revision 2.x" | |
| 16 | + | |
| 17 | +As of Revision AB, the ISS is described in detail in section 8. | |
| 18 | + | |
| 19 | +This driver is supporting _only_ the CSI2-A/B interfaces for now. | |
| 20 | + | |
| 21 | +It makes use of the Media Controller framework [2], and inherited most of the | |
| 22 | +code from OMAP3 ISP driver (found under drivers/media/platform/omap3isp/*), | |
| 23 | +except that it doesn't need an IOMMU now for ISS buffers memory mapping. | |
| 24 | + | |
| 25 | +Supports usage of MMAP buffers only (for now). | |
| 26 | + | |
| 27 | +Tested platforms | |
| 28 | +---------------- | |
| 29 | + | |
| 30 | +- OMAP4430SDP, w/ ES2.1 GP & SEVM4430-CAM-V1-0 (Contains IMX060 & OV5640, in | |
| 31 | + which only the last one is supported, outputting YUV422 frames). | |
| 32 | + | |
| 33 | +- TI Blaze MDP, w/ OMAP4430 ES2.2 EMU (Contains 1 IMX060 & 2 OV5650 sensors, in | |
| 34 | + which only the OV5650 are supported, outputting RAW10 frames). | |
| 35 | + | |
| 36 | +- PandaBoard, Rev. A2, w/ OMAP4430 ES2.1 GP & OV adapter board, tested with | |
| 37 | + following sensors: | |
| 38 | + * OV5640 | |
| 39 | + * OV5650 | |
| 40 | + | |
| 41 | +- Tested on mainline kernel: | |
| 42 | + | |
| 43 | + http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=summary | |
| 44 | + | |
| 45 | + Tag: v3.3 (commit c16fa4f2ad19908a47c63d8fa436a1178438c7e7) | |
| 46 | + | |
| 47 | +File list | |
| 48 | +--------- | |
| 49 | +drivers/staging/media/omap4iss/ | |
| 50 | +include/media/omap4iss.h | |
| 51 | + | |
| 52 | +References | |
| 53 | +---------- | |
| 54 | + | |
| 55 | +[1] http://focus.ti.com/general/docs/wtbu/wtbudocumentcenter.tsp?navigationId=12037&templateId=6123#62 | |
| 56 | +[2] http://lwn.net/Articles/420485/ | |
| 57 | +[3] http://www.spinics.net/lists/linux-media/msg44370.html | |
| 58 | +-- | |
| 59 | +Author: Sergio Aguirre <sergio.a.aguirre@gmail.com> | |
| 60 | +Copyright (C) 2012, Texas Instruments | |
| @@ -147,7 +147,7 @@ The drivers exposes following files: · 146 unmodified lines | ||
| 147 | 147 | -------------------------------------------------------------------- |
| 148 | 148 | 0x12 | readfreq | Current tuned frequency |
| 149 | 149 | -------------------------------------------------------------------- |
| 150 | − 0x14 | freqoff | Singed frequency offset in units of | |
| 150 | + 0x14 | freqoff | Signed frequency offset in units of | |
| 151 | 151 | | | 2ppm |
| 152 | 152 | -------------------------------------------------------------------- |
| 153 | 153 | 0x15 | rssi | Signed value of RSSI in dBuV |
| @@ -1838,6 +1838,7 @@ registers, find a list below: · 1837 unmodified lines | ||
| 1838 | 1838 | PPC | KVM_REG_PPC_LPCR | 64 |
| 1839 | 1839 | PPC | KVM_REG_PPC_PPR | 64 |
| 1840 | 1840 | PPC | KVM_REG_PPC_ARCH_COMPAT 32 |
| 1841 | + PPC | KVM_REG_PPC_DABRX | 32 | |
| 1841 | 1842 | PPC | KVM_REG_PPC_TM_GPR0 | 64 |
| 1842 | 1843 | ... |
| 1843 | 1844 | PPC | KVM_REG_PPC_TM_GPR31 | 64 |
| @@ -2104,7 +2105,7 @@ Returns: 0 on success, -1 on error · 260 unmodified lines | ||
| 2104 | 2105 | Allows setting an eventfd to directly trigger a guest interrupt. |
| 2105 | 2106 | kvm_irqfd.fd specifies the file descriptor to use as the eventfd and |
| 2106 | 2107 | kvm_irqfd.gsi specifies the irqchip pin toggled by this event. When |
| 2107 | −an event is tiggered on the eventfd, an interrupt is injected into | |
| 2108 | +an event is triggered on the eventfd, an interrupt is injected into | |
| 2108 | 2109 | the guest using the specified gsi pin. The irqfd is removed using |
| 2109 | 2110 | the KVM_IRQFD_FLAG_DEASSIGN flag, specifying both kvm_irqfd.fd |
| 2110 | 2111 | and kvm_irqfd.gsi. |
| @@ -2115,7 +2116,7 @@ interrupts. When KVM_IRQFD_FLAG_RESAMPLE is set the user must pass an · 4 unmodified lines | ||
| 2115 | 2116 | additional eventfd in the kvm_irqfd.resamplefd field. When operating |
| 2116 | 2117 | in resample mode, posting of an interrupt through kvm_irq.fd asserts |
| 2117 | 2118 | the specified gsi in the irqchip. When the irqchip is resampled, such |
| 2118 | −as from an EOI, the gsi is de-asserted and the user is notifed via | |
| 2119 | +as from an EOI, the gsi is de-asserted and the user is notified via | |
| 2119 | 2120 | kvm_irqfd.resamplefd. It is the user's responsibility to re-queue |
| 2120 | 2121 | the interrupt if the device making use of it still requires service. |
| 2121 | 2122 | Note that closing the resamplefd is not sufficient to disable the |
| @@ -2327,7 +2328,7 @@ current state. "addr" is ignored. · 205 unmodified lines | ||
| 2327 | 2328 | Capability: basic |
| 2328 | 2329 | Architectures: arm, arm64 |
| 2329 | 2330 | Type: vcpu ioctl |
| 2330 | −Parameters: struct struct kvm_vcpu_init (in) | |
| 2331 | +Parameters: struct kvm_vcpu_init (in) | |
| 2331 | 2332 | Returns: 0 on success; -1 on error |
| 2332 | 2333 | Errors: |
| 2333 | 2334 | EINVAL: the target is unknown, or the combination of features is invalid. |
| @@ -2391,7 +2392,8 @@ struct kvm_reg_list { · 57 unmodified lines | ||
| 2391 | 2392 | This ioctl returns the guest registers that are supported for the |
| 2392 | 2393 | KVM_GET_ONE_REG/KVM_SET_ONE_REG calls. |
| 2393 | 2394 | |
| 2394 | −4.85 KVM_ARM_SET_DEVICE_ADDR | |
| 2395 | + | |
| 2396 | +4.85 KVM_ARM_SET_DEVICE_ADDR (deprecated) | |
| 2395 | 2397 | |
| 2396 | 2398 | Capability: KVM_CAP_ARM_SET_DEVICE_ADDR |
| 2397 | 2399 | Architectures: arm, arm64 |
| @@ -2429,6 +2431,10 @@ must be called after calling KVM_CREATE_IRQCHIP, but before calling · 31 unmodified lines | ||
| 2429 | 2431 | KVM_RUN on any of the VCPUs. Calling this ioctl twice for any of the |
| 2430 | 2432 | base addresses will return -EEXIST. |
| 2431 | 2433 | |
| 2434 | +Note, this IOCTL is deprecated and the more flexible SET/GET_DEVICE_ATTR API | |
| 2435 | +should be used instead. | |
| 2436 | + | |
| 2437 | + | |
| 2432 | 2438 | 4.86 KVM_PPC_RTAS_DEFINE_TOKEN |
| 2433 | 2439 | |
| 2434 | 2440 | Capability: KVM_CAP_PPC_RTAS |
| @@ -0,0 +1,73 @@ | ||
| 1 | +ARM Virtual Generic Interrupt Controller (VGIC) | |
| 2 | +=============================================== | |
| 3 | + | |
| 4 | +Device types supported: | |
| 5 | + KVM_DEV_TYPE_ARM_VGIC_V2 ARM Generic Interrupt Controller v2.0 | |
| 6 | + | |
| 7 | +Only one VGIC instance may be instantiated through either this API or the | |
| 8 | +legacy KVM_CREATE_IRQCHIP api. The created VGIC will act as the VM interrupt | |
| 9 | +controller, requiring emulated user-space devices to inject interrupts to the | |
| 10 | +VGIC instead of directly to CPUs. | |
| 11 | + | |
| 12 | +Groups: | |
| 13 | + KVM_DEV_ARM_VGIC_GRP_ADDR | |
| 14 | + Attributes: | |
| 15 | + KVM_VGIC_V2_ADDR_TYPE_DIST (rw, 64-bit) | |
| 16 | + Base address in the guest physical address space of the GIC distributor | |
| 17 | + register mappings. | |
| 18 | + | |
| 19 | + KVM_VGIC_V2_ADDR_TYPE_CPU (rw, 64-bit) | |
| 20 | + Base address in the guest physical address space of the GIC virtual cpu | |
| 21 | + interface register mappings. | |
| 22 | + | |
| 23 | + KVM_DEV_ARM_VGIC_GRP_DIST_REGS | |
| 24 | + Attributes: | |
| 25 | + The attr field of kvm_device_attr encodes two values: | |
| 26 | + bits: | 63 .... 40 | 39 .. 32 | 31 .... 0 | | |
| 27 | + values: | reserved | cpu id | offset | | |
| 28 | + | |
| 29 | + All distributor regs are (rw, 32-bit) | |
| 30 | + | |
| 31 | + The offset is relative to the "Distributor base address" as defined in the | |
| 32 | + GICv2 specs. Getting or setting such a register has the same effect as | |
| 33 | + reading or writing the register on the actual hardware from the cpu | |
| 34 | + specified with cpu id field. Note that most distributor fields are not | |
| 35 | + banked, but return the same value regardless of the cpu id used to access | |
| 36 | + the register. | |
| 37 | + Limitations: | |
| 38 | + - Priorities are not implemented, and registers are RAZ/WI | |
| 39 | + Errors: | |
| 40 | + -ENODEV: Getting or setting this register is not yet supported | |
| 41 | + -EBUSY: One or more VCPUs are running | |
| 42 | + | |
| 43 | + KVM_DEV_ARM_VGIC_GRP_CPU_REGS | |
| 44 | + Attributes: | |
| 45 | + The attr field of kvm_device_attr encodes two values: | |
| 46 | + bits: | 63 .... 40 | 39 .. 32 | 31 .... 0 | | |
| 47 | + values: | reserved | cpu id | offset | | |
| 48 | + | |
| 49 | + All CPU interface regs are (rw, 32-bit) | |
| 50 | + | |
| 51 | + The offset specifies the offset from the "CPU interface base address" as | |
| 52 | + defined in the GICv2 specs. Getting or setting such a register has the | |
| 53 | + same effect as reading or writing the register on the actual hardware. | |
| 54 | + | |
| 55 | + The Active Priorities Registers APRn are implementation defined, so we set a | |
| 56 | + fixed format for our implementation that fits with the model of a "GICv2 | |
| 57 | + implementation without the security extensions" which we present to the | |
| 58 | + guest. This interface always exposes four register APR[0-3] describing the | |
| 59 | + maximum possible 128 preemption levels. The semantics of the register | |
| 60 | + indicate if any interrupts in a given preemption level are in the active | |
| 61 | + state by setting the corresponding bit. | |
| 62 | + | |
| 63 | + Thus, preemption level X has one or more active interrupts if and only if: | |
| 64 | + | |
| 65 | + APRn[X mod 32] == 0b1, where n = X / 32 | |
| 66 | + | |
| 67 | + Bits for undefined preemption levels are RAZ/WI. | |
| 68 | + | |
| 69 | + Limitations: | |
| 70 | + - Priorities are not implemented, and registers are RAZ/WI | |
| 71 | + Errors: | |
| 72 | + -ENODEV: Getting or setting this register is not yet supported | |
| 73 | + -EBUSY: One or more VCPUs are running | |
| @@ -17,6 +17,9 @@ S390: · 16 unmodified lines | ||
| 17 | 17 | S390 uses diagnose instruction as hypercall (0x500) along with hypercall |
| 18 | 18 | number in R1. |
| 19 | 19 | |
| 20 | + For further information on the S390 diagnose call as supported by KVM, | |
| 21 | + refer to Documentation/virtual/kvm/s390-diag.txt. | |
| 22 | + | |
| 20 | 23 | PowerPC: |
| 21 | 24 | It uses R3-R10 and hypercall number in R11. R4-R11 are used as output registers. |
| 22 | 25 | Return value is placed in R3. |
| @@ -74,7 +77,7 @@ Usage example : A vcpu of a paravirtualized guest that is busywaiting in guest · 51 unmodified lines | ||
| 74 | 77 | kernel mode for an event to occur (ex: a spinlock to become available) can |
| 75 | 78 | execute HLT instruction once it has busy-waited for more than a threshold |
| 76 | 79 | time-interval. Execution of HLT instruction would cause the hypervisor to put |
| 77 | −the vcpu to sleep until occurence of an appropriate event. Another vcpu of the | |
| 80 | +the vcpu to sleep until occurrence of an appropriate event. Another vcpu of the | |
| 78 | 81 | same guest can wakeup the sleeping vcpu by issuing KVM_HC_KICK_CPU hypercall, |
| 79 | 82 | specifying APIC ID (a1) of the vcpu to be woken up. An additional argument (a0) |
| 80 | 83 | is used in the hypercall for future use. |
| @@ -112,7 +112,7 @@ The Dirty bit is lost in this case. · 111 unmodified lines | ||
| 112 | 112 | |
| 113 | 113 | In order to avoid this kind of issue, we always treat the spte as "volatile" |
| 114 | 114 | if it can be updated out of mmu-lock, see spte_has_volatile_bits(), it means, |
| 115 | −the spte is always atomicly updated in this case. | |
| 115 | +the spte is always atomically updated in this case. | |
| 116 | 116 | |
| 117 | 117 | 3): flush tlbs due to spte updated |
| 118 | 118 | If the spte is updated from writable to readonly, we should flush all TLBs, |
| @@ -125,7 +125,7 @@ be flushed caused by this reason in mmu_spte_update() since this is a common · 6 unmodified lines | ||
| 125 | 125 | function to update spte (present -> present). |
| 126 | 126 | |
| 127 | 127 | Since the spte is "volatile" if it can be updated out of mmu-lock, we always |
| 128 | −atomicly update the spte, the race caused by fast page fault can be avoided, | |
| 128 | +atomically update the spte, the race caused by fast page fault can be avoided, | |
| 129 | 129 | See the comments in spte_has_volatile_bits() and mmu_spte_update(). |
| 130 | 130 | |
| 131 | 131 | 3. Reference |
| @@ -115,7 +115,7 @@ If any other bit changes in the MSR, please still use mtmsr(d). · 114 unmodified lines | ||
| 115 | 115 | Patched instructions |
| 116 | 116 | ==================== |
| 117 | 117 | |
| 118 | −The "ld" and "std" instructions are transormed to "lwz" and "stw" instructions | |
| 118 | +The "ld" and "std" instructions are transformed to "lwz" and "stw" instructions | |
| 119 | 119 | respectively on 32 bit systems with an added offset of 4 to accommodate for big |
| 120 | 120 | endianness. |
| 121 | 121 | |
| @@ -0,0 +1,80 @@ | ||
| 1 | +The s390 DIAGNOSE call on KVM | |
| 2 | +============================= | |
| 3 | + | |
| 4 | +KVM on s390 supports the DIAGNOSE call for making hypercalls, both for | |
| 5 | +native hypercalls and for selected hypercalls found on other s390 | |
| 6 | +hypervisors. | |
| 7 | + | |
| 8 | +Note that bits are numbered as by the usual s390 convention (most significant | |
| 9 | +bit on the left). | |
| 10 | + | |
| 11 | + | |
| 12 | +General remarks | |
| 13 | +--------------- | |
| 14 | + | |
| 15 | +DIAGNOSE calls by the guest cause a mandatory intercept. This implies | |
| 16 | +all supported DIAGNOSE calls need to be handled by either KVM or its | |
| 17 | +userspace. | |
| 18 | + | |
| 19 | +All DIAGNOSE calls supported by KVM use the RS-a format: | |
| 20 | + | |
| 21 | +-------------------------------------- | |
| 22 | +| '83' | R1 | R3 | B2 | D2 | | |
| 23 | +-------------------------------------- | |
| 24 | +0 8 12 16 20 31 | |
| 25 | + | |
| 26 | +The second-operand address (obtained by the base/displacement calculation) | |
| 27 | +is not used to address data. Instead, bits 48-63 of this address specify | |
| 28 | +the function code, and bits 0-47 are ignored. | |
| 29 | + | |
| 30 | +The supported DIAGNOSE function codes vary by the userspace used. For | |
| 31 | +DIAGNOSE function codes not specific to KVM, please refer to the | |
| 32 | +documentation for the s390 hypervisors defining them. | |
| 33 | + | |
| 34 | + | |
| 35 | +DIAGNOSE function code 'X'500' - KVM virtio functions | |
| 36 | +----------------------------------------------------- | |
| 37 | + | |
| 38 | +If the function code specifies 0x500, various virtio-related functions | |
| 39 | +are performed. | |
| 40 | + | |
| 41 | +General register 1 contains the virtio subfunction code. Supported | |
| 42 | +virtio subfunctions depend on KVM's userspace. Generally, userspace | |
| 43 | +provides either s390-virtio (subcodes 0-2) or virtio-ccw (subcode 3). | |
| 44 | + | |
| 45 | +Upon completion of the DIAGNOSE instruction, general register 2 contains | |
| 46 | +the function's return code, which is either a return code or a subcode | |
| 47 | +specific value. | |
| 48 | + | |
| 49 | +Subcode 0 - s390-virtio notification and early console printk | |
| 50 | + Handled by userspace. | |
| 51 | + | |
| 52 | +Subcode 1 - s390-virtio reset | |
| 53 | + Handled by userspace. | |
| 54 | + | |
| 55 | +Subcode 2 - s390-virtio set status | |
| 56 | + Handled by userspace. | |
| 57 | + | |
| 58 | +Subcode 3 - virtio-ccw notification | |
| 59 | + Handled by either userspace or KVM (ioeventfd case). | |
| 60 | + | |
| 61 | + General register 2 contains a subchannel-identification word denoting | |
| 62 | + the subchannel of the virtio-ccw proxy device to be notified. | |
| 63 | + | |
| 64 | + General register 3 contains the number of the virtqueue to be notified. | |
| 65 | + | |
| 66 | + General register 4 contains a 64bit identifier for KVM usage (the | |
| 67 | + kvm_io_bus cookie). If general register 4 does not contain a valid | |
| 68 | + identifier, it is ignored. | |
| 69 | + | |
| 70 | + After completion of the DIAGNOSE call, general register 2 may contain | |
| 71 | + a 64bit identifier (in the kvm_io_bus cookie case). | |
| 72 | + | |
| 73 | + See also the virtio standard for a discussion of this hypercall. | |
| 74 | + | |
| 75 | + | |
| 76 | +DIAGNOSE function code 'X'501 - KVM breakpoint | |
| 77 | +---------------------------------------------- | |
| 78 | + | |
| 79 | +If the function code specifies 0x501, breakpoint functions may be performed. | |
| 80 | +This function code is handled by userspace. | |
| @@ -467,7 +467,7 @@ at any time. This causes problems as the passage of real time, the injection · 466 unmodified lines | ||
| 467 | 467 | of machine interrupts and the associated clock sources are no longer completely |
| 468 | 468 | synchronized with real time. |
| 469 | 469 | |
| 470 | −This same problem can occur on native harware to a degree, as SMM mode may | |
| 470 | +This same problem can occur on native hardware to a degree, as SMM mode may | |
| 471 | 471 | steal cycles from the naturally on X86 systems when SMM mode is used by the |
| 472 | 472 | BIOS, but not in such an extreme fashion. However, the fact that SMM mode may |
| 473 | 473 | cause similar problems to virtualization makes it a good justification for |
| @@ -1,130 +0,0 @@ | ||
| 1 | −Started Oct 1999 by Kanoj Sarcar <kanojsarcar@yahoo.com> | |
| 2 | − | |
| 3 | −The intent of this file is to have an uptodate, running commentary | |
| 4 | −from different people about how locking and synchronization is done | |
| 5 | −in the Linux vm code. | |
| 6 | − | |
| 7 | −page_table_lock & mmap_sem | |
| 8 | −-------------------------------------- | |
| 9 | − | |
| 10 | −Page stealers pick processes out of the process pool and scan for | |
| 11 | −the best process to steal pages from. To guarantee the existence | |
| 12 | −of the victim mm, a mm_count inc and a mmdrop are done in swap_out(). | |
| 13 | −Page stealers hold kernel_lock to protect against a bunch of races. | |
| 14 | −The vma list of the victim mm is also scanned by the stealer, | |
| 15 | −and the page_table_lock is used to preserve list sanity against the | |
| 16 | −process adding/deleting to the list. This also guarantees existence | |
| 17 | −of the vma. Vma existence is not guaranteed once try_to_swap_out() | |
| 18 | −drops the page_table_lock. To guarantee the existence of the underlying | |
| 19 | −file structure, a get_file is done before the swapout() method is | |
| 20 | −invoked. The page passed into swapout() is guaranteed not to be reused | |
| 21 | −for a different purpose because the page reference count due to being | |
| 22 | −present in the user's pte is not released till after swapout() returns. | |
| 23 | − | |
| 24 | −Any code that modifies the vmlist, or the vm_start/vm_end/ | |
| 25 | −vm_flags:VM_LOCKED/vm_next of any vma *in the list* must prevent | |
| 26 | −kswapd from looking at the chain. | |
| 27 | − | |
| 28 | −The rules are: | |
| 29 | −1. To scan the vmlist (look but don't touch) you must hold the | |
| 30 | − mmap_sem with read bias, i.e. down_read(&mm->mmap_sem) | |
| 31 | −2. To modify the vmlist you need to hold the mmap_sem with | |
| 32 | − read&write bias, i.e. down_write(&mm->mmap_sem) *AND* | |
| 33 | − you need to take the page_table_lock. | |
| 34 | −3. The swapper takes _just_ the page_table_lock, this is done | |
| 35 | − because the mmap_sem can be an extremely long lived lock | |
| 36 | − and the swapper just cannot sleep on that. | |
| 37 | −4. The exception to this rule is expand_stack, which just | |
| 38 | − takes the read lock and the page_table_lock, this is ok | |
| 39 | − because it doesn't really modify fields anybody relies on. | |
| 40 | −5. You must be able to guarantee that while holding page_table_lock | |
| 41 | − or page_table_lock of mm A, you will not try to get either lock | |
| 42 | − for mm B. | |
| 43 | − | |
| 44 | −The caveats are: | |
| 45 | −1. find_vma() makes use of, and updates, the mmap_cache pointer hint. | |
| 46 | −The update of mmap_cache is racy (page stealer can race with other code | |
| 47 | −that invokes find_vma with mmap_sem held), but that is okay, since it | |
| 48 | −is a hint. This can be fixed, if desired, by having find_vma grab the | |
| 49 | −page_table_lock. | |
| 50 | − | |
| 51 | − | |
| 52 | −Code that add/delete elements from the vmlist chain are | |
| 53 | −1. callers of insert_vm_struct | |
| 54 | −2. callers of merge_segments | |
| 55 | −3. callers of avl_remove | |
| 56 | − | |
| 57 | −Code that changes vm_start/vm_end/vm_flags:VM_LOCKED of vma's on | |
| 58 | −the list: | |
| 59 | −1. expand_stack | |
| 60 | −2. mprotect | |
| 61 | −3. mlock | |
| 62 | −4. mremap | |
| 63 | − | |
| 64 | −It is advisable that changes to vm_start/vm_end be protected, although | |
| 65 | −in some cases it is not really needed. Eg, vm_start is modified by | |
| 66 | −expand_stack(), it is hard to come up with a destructive scenario without | |
| 67 | −having the vmlist protection in this case. | |
| 68 | − | |
| 69 | −The page_table_lock nests with the inode i_mmap_mutex and the kmem cache | |
| 70 | −c_spinlock spinlocks. This is okay, since the kmem code asks for pages after | |
| 71 | −dropping c_spinlock. The page_table_lock also nests with pagecache_lock and | |
| 72 | −pagemap_lru_lock spinlocks, and no code asks for memory with these locks | |
| 73 | −held. | |
| 74 | − | |
| 75 | −The page_table_lock is grabbed while holding the kernel_lock spinning monitor. | |
| 76 | − | |
| 77 | −The page_table_lock is a spin lock. | |
| 78 | − | |
| 79 | −Note: PTL can also be used to guarantee that no new clones using the | |
| 80 | −mm start up ... this is a loose form of stability on mm_users. For | |
| 81 | −example, it is used in copy_mm to protect against a racing tlb_gather_mmu | |
| 82 | −single address space optimization, so that the zap_page_range (from | |
| 83 | −truncate) does not lose sending ipi's to cloned threads that might | |
| 84 | −be spawned underneath it and go to user mode to drag in pte's into tlbs. | |
| 85 | − | |
| 86 | −swap_lock | |
| 87 | −-------------- | |
| 88 | −The swap devices are chained in priority order from the "swap_list" header. | |
| 89 | −The "swap_list" is used for the round-robin swaphandle allocation strategy. | |
| 90 | −The #free swaphandles is maintained in "nr_swap_pages". These two together | |
| 91 | −are protected by the swap_lock. | |
| 92 | − | |
| 93 | −The swap_lock also protects all the device reference counts on the | |
| 94 | −corresponding swaphandles, maintained in the "swap_map" array, and the | |
| 95 | −"highest_bit" and "lowest_bit" fields. | |
| 96 | − | |
| 97 | −The swap_lock is a spinlock, and is never acquired from intr level. | |
| 98 | − | |
| 99 | −To prevent races between swap space deletion or async readahead swapins | |
| 100 | −deciding whether a swap handle is being used, ie worthy of being read in | |
| 101 | −from disk, and an unmap -> swap_free making the handle unused, the swap | |
| 102 | −delete and readahead code grabs a temp reference on the swaphandle to | |
| 103 | −prevent warning messages from swap_duplicate <- read_swap_cache_async. | |
| 104 | − | |
| 105 | −Swap cache locking | |
| 106 | −------------------ | |
| 107 | −Pages are added into the swap cache with kernel_lock held, to make sure | |
| 108 | −that multiple pages are not being added (and hence lost) by associating | |
| 109 | −all of them with the same swaphandle. | |
| 110 | − | |
| 111 | −Pages are guaranteed not to be removed from the scache if the page is | |
| 112 | −"shared": ie, other processes hold reference on the page or the associated | |
| 113 | −swap handle. The only code that does not follow this rule is shrink_mmap, | |
| 114 | −which deletes pages from the swap cache if no process has a reference on | |
| 115 | −the page (multiple processes might have references on the corresponding | |
| 116 | −swap handle though). lookup_swap_cache() races with shrink_mmap, when | |
| 117 | −establishing a reference on a scache page, so, it must check whether the | |
| 118 | −page it located is still in the swapcache, or shrink_mmap deleted it. | |
| 119 | −(This race is due to the fact that shrink_mmap looks at the page ref | |
| 120 | −count with pagecache_lock, but then drops pagecache_lock before deleting | |
| 121 | −the page from the scache). | |
| 122 | − | |
| 123 | −do_wp_page and do_swap_page have MP races in them while trying to figure | |
| 124 | −out whether a page is "shared", by looking at the page_count + swap_count. | |
| 125 | −To preserve the sum of the counts, the page lock _must_ be acquired before | |
| 126 | −calling is_page_shared (else processes might switch their swap_count refs | |
| 127 | −to the page count refs, after the page count ref has been snapshotted). | |
| 128 | − | |
| 129 | −Swap device deletion code currently breaks all the scache assumptions, | |
| 130 | −since it grabs neither mmap_sem nor page_table_lock. | |
| @@ -14,8 +14,8 @@ The Linux kernel supports the following overcommit handling modes · 13 unmodified lines | ||
| 14 | 14 | |
| 15 | 15 | 2 - Don't overcommit. The total address space commit |
| 16 | 16 | for the system is not permitted to exceed swap + a |
| 17 | − configurable percentage (default is 50) of physical RAM. | |
| 18 | − Depending on the percentage you use, in most situations | |
| 17 | + configurable amount (default is 50%) of physical RAM. | |
| 18 | + Depending on the amount you use, in most situations | |
| 19 | 19 | this means a process will not be killed while accessing |
| 20 | 20 | pages but will receive errors on memory allocation as |
| 21 | 21 | appropriate. |
| @@ -26,7 +26,8 @@ The Linux kernel supports the following overcommit handling modes · 4 unmodified lines | ||
| 26 | 26 | |
| 27 | 27 | The overcommit policy is set via the sysctl `vm.overcommit_memory'. |
| 28 | 28 | |
| 29 | −The overcommit percentage is set via `vm.overcommit_ratio'. | |
| 29 | +The overcommit amount can be set via `vm.overcommit_ratio' (percentage) | |
| 30 | +or `vm.overcommit_kbytes' (absolute value). | |
| 30 | 31 | |
| 31 | 32 | The current overcommit limit and amount committed are viewable in |
| 32 | 33 | /proc/meminfo as CommitLimit and Committed_AS respectively. |
| @@ -393,4 +393,14 @@ Slot Detection · 392 unmodified lines | ||
| 393 | 393 | |
| 394 | 394 | This function returns the slot ID of the provided bridge. |
| 395 | 395 | |
| 396 | − int vme_slot_get(struct vme_dev *dev); | |
| 396 | + int vme_slot_num(struct vme_dev *dev); | |
| 397 | + | |
| 398 | + | |
| 399 | +Bus Detection | |
| 400 | +============= | |
| 401 | + | |
| 402 | +This function returns the bus ID of the provided bridge. | |
| 403 | + | |
| 404 | + int vme_bus_num(struct vme_dev *dev); | |
| 405 | + | |
| 406 | + | |
| @@ -78,14 +78,6 @@ APICs · 77 unmodified lines | ||
| 78 | 78 | |
| 79 | 79 | no_timer_check Don't check the IO-APIC timer. This can work around |
| 80 | 80 | problems with incorrect timer initialization on some boards. |
| 81 | − | |
| 82 | − apicmaintimer Run time keeping from the local APIC timer instead | |
| 83 | − of using the PIT/HPET interrupt for this. This is useful | |
| 84 | − when the PIT/HPET interrupts are unreliable. | |
| 85 | − | |
| 86 | − noapicmaintimer Don't do time keeping using the APIC timer. | |
| 87 | − Useful when this option was auto selected, but doesn't work. | |
| 88 | − | |
| 89 | 81 | apicpmtimer |
| 90 | 82 | Do APIC timer calibration using the pmtimer. Implies |
| 91 | 83 | apicmaintimer. Useful when your PIT timer is totally |
| @@ -144,11 +136,6 @@ Non Executable Mappings · 52 unmodified lines | ||
| 144 | 136 | on Enable(default) |
| 145 | 137 | off Disable |
| 146 | 138 | |
| 147 | −SMP | |
| 148 | − | |
| 149 | − additional_cpus=NUM Allow NUM more CPUs for hotplug | |
| 150 | − (defaults are specified by the BIOS, see Documentation/x86/x86_64/cpu-hotplug-spec) | |
| 151 | − | |
| 152 | 139 | NUMA |
| 153 | 140 | |
| 154 | 141 | numa=off Only set up a single NUMA node spanning all memory. |
| @@ -289,16 +276,6 @@ Debugging · 134 unmodified lines | ||
| 289 | 276 | |
| 290 | 277 | kstack=N Print N words from the kernel stack in oops dumps. |
| 291 | 278 | |
| 292 | − pagefaulttrace Dump all page faults. Only useful for extreme debugging | |
| 293 | − and will create a lot of output. | |
| 294 | − | |
| 295 | − call_trace=[old|both|newfallback|new] | |
| 296 | − old: use old inexact backtracer | |
| 297 | − new: use new exact dwarf2 unwinder | |
| 298 | − both: print entries from both | |
| 299 | − newfallback: use new unwinder but fall back to old if it gets | |
| 300 | − stuck (default) | |
| 301 | − | |
| 302 | 279 | Miscellaneous |
| 303 | 280 | |
| 304 | 281 | nogbpages |
| @@ -40,5 +40,5 @@ See Section 4.3.12.4 of ISA; Bits: · 39 unmodified lines | ||
| 40 | 40 | --------- --------------- ----------------- ---------------- |
| 41 | 41 | 0 Exception Exception Exception |
| 42 | 42 | 1 RCW Transaction RCW Transaction RCW Transaction |
| 43 | − 2 Internal Operation Exception Reserved | |
| 43 | + 2 Internal Operation Internal Operation Reserved | |
| 44 | 44 | 3 Reserved Reserved Reserved |
| @@ -44,3 +44,21 @@ After step 4, we jump to intended (linked) address of this code. · 43 unmodified lines | ||
| 44 | 44 | 40..5F -> 40 40..5F -> pc -> pc 40..5F -> pc |
| 45 | 45 | 20..3F -> 20 -> 20 20..3F -> 20 |
| 46 | 46 | 00..1F -> 00 -> 00 00..1F -> 00 |
| 47 | + | |
| 48 | +The default location of IO peripherals is above 0xf0000000. This may change | |
| 49 | +using a "ranges" property in a device tree simple-bus node. See ePAPR 1.1, §6.5 | |
| 50 | +for details on the syntax and semantic of simple-bus nodes. The following | |
| 51 | +limitations apply: | |
| 52 | + | |
| 53 | +1. Only top level simple-bus nodes are considered | |
| 54 | + | |
| 55 | +2. Only one (first) simple-bus node is considered | |
| 56 | + | |
| 57 | +3. Empty "ranges" properties are not supported | |
| 58 | + | |
| 59 | +4. Only the first triplet in the "ranges" property is considered | |
| 60 | + | |
| 61 | +5. The parent-bus-address value is rounded down to the nearest 256MB boundary | |
| 62 | + | |
| 63 | +6. The IO area covers the entire 256MB segment of parent-bus-address; the | |
| 64 | + "ranges" triplet length field is ignored | |
| @@ -112,7 +112,7 @@ Linux内核代码中包含有大量的文档。这些文档对于学习如何与 · 111 unmodified lines | ||
| 112 | 112 | |
| 113 | 113 | 其他关于如何正确地生成补丁的优秀文档包括： |
| 114 | 114 | "The Perfect Patch" |
| 115 | − http://userweb.kernel.org/~akpm/stuff/tpp.txt | |
| 115 | + http://www.ozlabs.org/~akpm/stuff/tpp.txt | |
| 116 | 116 | "Linux kernel patch submission format" |
| 117 | 117 | http://linux.yyz.us/patch-format.html |
| 118 | 118 | |
| @@ -515,7 +515,7 @@ Linux内核社区并不喜欢一下接收大段的代码。修改需要被恰当 · 396 unmodified lines | ||
| 515 | 515 | |
| 516 | 516 | 想了解它具体应该看起来像什么，请查阅以下文档中的“ChangeLog”章节： |
| 517 | 517 | “The Perfect Patch” |
| 518 | − http://userweb.kernel.org/~akpm/stuff/tpp.txt | |
| 518 | + http://www.ozlabs.org/~akpm/stuff/tpp.txt | |
| 519 | 519 | |
| 520 | 520 | |
| 521 | 521 | 这些事情有时候做起来很难。要在任何方面都做到完美可能需要好几年时间。这是 |
| @@ -93,6 +93,11 @@ Descriptions of section entries: · 92 unmodified lines | ||
| 93 | 93 | N: Files and directories with regex patterns. |
| 94 | 94 | N: [^a-z]tegra all files whose path contains the word tegra |
| 95 | 95 | One pattern per line. Multiple N: lines acceptable. |
| 96 | + scripts/get_maintainer.pl has different behavior for files that | |
| 97 | + match F: pattern and matches of N: patterns. By default, | |
| 98 | + get_maintainer will not look at git log history when an F: pattern | |
| 99 | + match occurs. When an N: match occurs, git log history is used | |
| 100 | + to also notify the people that have git commit signatures. | |
| 96 | 101 | X: Files and directories that are NOT maintained, same rules as F: |
| 97 | 102 | Files exclusions are tested before file matches. |
| 98 | 103 | Can be useful for excluding a specific subdirectory, for instance: |
| @@ -252,6 +257,7 @@ F: Documentation/ABI/testing/sysfs-bus-acpi · 153 unmodified lines | ||
| 252 | 257 | F: drivers/pci/*acpi* |
| 253 | 258 | F: drivers/pci/*/*acpi* |
| 254 | 259 | F: drivers/pci/*/*/*acpi* |
| 260 | +F: tools/power/acpi | |
| 255 | 261 | |
| 256 | 262 | ACPI COMPONENT ARCHITECTURE (ACPICA) |
| 257 | 263 | M: Robert Moore <robert.moore@intel.com> |
| @@ -266,6 +272,7 @@ T: git git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm · 8 unmodified lines | ||
| 266 | 272 | S: Supported |
| 267 | 273 | F: drivers/acpi/acpica/ |
| 268 | 274 | F: include/acpi/ |
| 275 | +F: tools/power/acpi/ | |
| 269 | 276 | |
| 270 | 277 | ACPI FAN DRIVER |
| 271 | 278 | M: Zhang Rui <rui.zhang@intel.com> |
| @@ -302,36 +309,36 @@ F: sound/pci/ad1889.* · 30 unmodified lines | ||
| 302 | 309 | |
| 303 | 310 | AD525X ANALOG DEVICES DIGITAL POTENTIOMETERS DRIVER |
| 304 | 311 | M: Michael Hennerich <michael.hennerich@analog.com> |
| 305 | −L: device-drivers-devel@blackfin.uclinux.org | |
| 306 | 312 | W: http://wiki.analog.com/AD5254 |
| 313 | +W: http://ez.analog.com/community/linux-device-drivers | |
| 307 | 314 | S: Supported |
| 308 | 315 | F: drivers/misc/ad525x_dpot.c |
| 309 | 316 | |
| 310 | 317 | AD5398 CURRENT REGULATOR DRIVER (AD5398/AD5821) |
| 311 | 318 | M: Michael Hennerich <michael.hennerich@analog.com> |
| 312 | −L: device-drivers-devel@blackfin.uclinux.org | |
| 313 | 319 | W: http://wiki.analog.com/AD5398 |
| 320 | +W: http://ez.analog.com/community/linux-device-drivers | |
| 314 | 321 | S: Supported |
| 315 | 322 | F: drivers/regulator/ad5398.c |
| 316 | 323 | |
| 317 | 324 | AD714X CAPACITANCE TOUCH SENSOR DRIVER (AD7142/3/7/8/7A) |
| 318 | 325 | M: Michael Hennerich <michael.hennerich@analog.com> |
| 319 | −L: device-drivers-devel@blackfin.uclinux.org | |
| 320 | 326 | W: http://wiki.analog.com/AD7142 |
| 327 | +W: http://ez.analog.com/community/linux-device-drivers | |
| 321 | 328 | S: Supported |
| 322 | 329 | F: drivers/input/misc/ad714x.c |
| 323 | 330 | |
| 324 | 331 | AD7877 TOUCHSCREEN DRIVER |
| 325 | 332 | M: Michael Hennerich <michael.hennerich@analog.com> |
| 326 | −L: device-drivers-devel@blackfin.uclinux.org | |
| 327 | 333 | W: http://wiki.analog.com/AD7877 |
| 334 | +W: http://ez.analog.com/community/linux-device-drivers | |
| 328 | 335 | S: Supported |
| 329 | 336 | F: drivers/input/touchscreen/ad7877.c |
| 330 | 337 | |
| 331 | 338 | AD7879 TOUCHSCREEN DRIVER (AD7879/AD7889) |
| 332 | 339 | M: Michael Hennerich <michael.hennerich@analog.com> |
| 333 | −L: device-drivers-devel@blackfin.uclinux.org | |
| 334 | 340 | W: http://wiki.analog.com/AD7879 |
| 341 | +W: http://ez.analog.com/community/linux-device-drivers | |
| 335 | 342 | S: Supported |
| 336 | 343 | F: drivers/input/touchscreen/ad7879.c |
| 337 | 344 | |
| @@ -340,7 +347,7 @@ M: Jiri Kosina <jkosina@suse.cz> · 2 unmodified lines | ||
| 340 | 347 | S: Maintained |
| 341 | 348 | |
| 342 | 349 | ADM1025 HARDWARE MONITOR DRIVER |
| 343 | −M: Jean Delvare <khali@linux-fr.org> | |
| 350 | +M: Jean Delvare <jdelvare@suse.de> | |
| 344 | 351 | L: lm-sensors@lm-sensors.org |
| 345 | 352 | S: Maintained |
| 346 | 353 | F: Documentation/hwmon/adm1025 |
| @@ -367,8 +374,8 @@ F: include/media/adp1653.h · 20 unmodified lines | ||
| 367 | 374 | |
| 368 | 375 | ADP5520 BACKLIGHT DRIVER WITH IO EXPANDER (ADP5520/ADP5501) |
| 369 | 376 | M: Michael Hennerich <michael.hennerich@analog.com> |
| 370 | −L: device-drivers-devel@blackfin.uclinux.org | |
| 371 | 377 | W: http://wiki.analog.com/ADP5520 |
| 378 | +W: http://ez.analog.com/community/linux-device-drivers | |
| 372 | 379 | S: Supported |
| 373 | 380 | F: drivers/mfd/adp5520.c |
| 374 | 381 | F: drivers/video/backlight/adp5520_bl.c |
| @@ -378,16 +385,16 @@ F: drivers/input/keyboard/adp5520-keys.c · 3 unmodified lines | ||
| 378 | 385 | |
| 379 | 386 | ADP5588 QWERTY KEYPAD AND IO EXPANDER DRIVER (ADP5588/ADP5587) |
| 380 | 387 | M: Michael Hennerich <michael.hennerich@analog.com> |
| 381 | −L: device-drivers-devel@blackfin.uclinux.org | |
| 382 | 388 | W: http://wiki.analog.com/ADP5588 |
| 389 | +W: http://ez.analog.com/community/linux-device-drivers | |
| 383 | 390 | S: Supported |
| 384 | 391 | F: drivers/input/keyboard/adp5588-keys.c |
| 385 | 392 | F: drivers/gpio/gpio-adp5588.c |
| 386 | 393 | |
| 387 | 394 | ADP8860 BACKLIGHT DRIVER (ADP8860/ADP8861/ADP8863) |
| 388 | 395 | M: Michael Hennerich <michael.hennerich@analog.com> |
| 389 | −L: device-drivers-devel@blackfin.uclinux.org | |
| 390 | 396 | W: http://wiki.analog.com/ADP8860 |
| 397 | +W: http://ez.analog.com/community/linux-device-drivers | |
| 391 | 398 | S: Supported |
| 392 | 399 | F: drivers/video/backlight/adp8860_bl.c |
| 393 | 400 | |
| @@ -405,7 +412,7 @@ S: Maintained · 11 unmodified lines | ||
| 405 | 412 | F: drivers/macintosh/therm_adt746x.c |
| 406 | 413 | |
| 407 | 414 | ADT7475 HARDWARE MONITOR DRIVER |
| 408 | −M: Jean Delvare <khali@linux-fr.org> | |
| 415 | +M: Jean Delvare <jdelvare@suse.de> | |
| 409 | 416 | L: lm-sensors@lm-sensors.org |
| 410 | 417 | S: Maintained |
| 411 | 418 | F: Documentation/hwmon/adt7475 |
| @@ -413,8 +420,8 @@ F: drivers/hwmon/adt7475.c · 1 unmodified line | ||
| 413 | 420 | |
| 414 | 421 | ADXL34X THREE-AXIS DIGITAL ACCELEROMETER DRIVER (ADXL345/ADXL346) |
| 415 | 422 | M: Michael Hennerich <michael.hennerich@analog.com> |
| 416 | −L: device-drivers-devel@blackfin.uclinux.org | |
| 417 | 423 | W: http://wiki.analog.com/ADXL345 |
| 424 | +W: http://ez.analog.com/community/linux-device-drivers | |
| 418 | 425 | S: Supported |
| 419 | 426 | F: drivers/input/misc/adxl34x.c |
| 420 | 427 | |
| @@ -484,7 +491,6 @@ M: Hannes Reinecke <hare@suse.de> · 63 unmodified lines | ||
| 484 | 491 | L: linux-scsi@vger.kernel.org |
| 485 | 492 | S: Maintained |
| 486 | 493 | F: drivers/scsi/aic7xxx/ |
| 487 | −F: drivers/scsi/aic7xxx_old/ | |
| 488 | 494 | |
| 489 | 495 | AIMSLAB FM RADIO RECEIVER DRIVER |
| 490 | 496 | M: Hans Verkuil <hverkuil@xs4all.nl> |
| @@ -539,6 +545,13 @@ F: drivers/tty/serial/altera_jtaguart.c · 48 unmodified lines | ||
| 539 | 545 | F: include/linux/altera_uart.h |
| 540 | 546 | F: include/linux/altera_jtaguart.h |
| 541 | 547 | |
| 548 | +AMD CRYPTOGRAPHIC COPROCESSOR (CCP) DRIVER | |
| 549 | +M: Tom Lendacky <thomas.lendacky@amd.com> | |
| 550 | +L: linux-crypto@vger.kernel.org | |
| 551 | +S: Supported | |
| 552 | +F: drivers/crypto/ccp/ | |
| 553 | +F: include/linux/ccp.h | |
| 554 | + | |
| 542 | 555 | AMD FAM15H PROCESSOR POWER MONITORING DRIVER |
| 543 | 556 | M: Andreas Herrmann <herrmann.der.user@googlemail.com> |
| 544 | 557 | L: lm-sensors@lm-sensors.org |
| @@ -614,9 +627,9 @@ F: drivers/media/i2c/adv7842* · 69 unmodified lines | ||
| 614 | 627 | |
| 615 | 628 | ANALOG DEVICES INC ASOC CODEC DRIVERS |
| 616 | 629 | M: Lars-Peter Clausen <lars@metafoo.de> |
| 617 | −L: device-drivers-devel@blackfin.uclinux.org | |
| 618 | 630 | L: alsa-devel@alsa-project.org (moderated for non-subscribers) |
| 619 | 631 | W: http://wiki.analog.com/ |
| 632 | +W: http://ez.analog.com/community/linux-device-drivers | |
| 620 | 633 | S: Supported |
| 621 | 634 | F: sound/soc/codecs/adau* |
| 622 | 635 | F: sound/soc/codecs/adav* |
| @@ -626,7 +639,7 @@ F: sound/soc/codecs/ssm* · 3 unmodified lines | ||
| 626 | 639 | F: sound/soc/codecs/sigmadsp.* |
| 627 | 640 | |
| 628 | 641 | ANALOG DEVICES INC ASOC DRIVERS |
| 629 | −L: uclinux-dist-devel@blackfin.uclinux.org | |
| 642 | +L: adi-buildroot-devel@lists.sourceforge.net | |
| 630 | 643 | L: alsa-devel@alsa-project.org (moderated for non-subscribers) |
| 631 | 644 | W: http://blackfin.uclinux.org/ |
| 632 | 645 | S: Supported |
| @@ -766,7 +779,12 @@ ARM/Allwinner A1X SoC support · 133 unmodified lines | ||
| 766 | 779 | M: Maxime Ripard <maxime.ripard@free-electrons.com> |
| 767 | 780 | L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers) |
| 768 | 781 | S: Maintained |
| 769 | −F: arch/arm/mach-sunxi/ | |
| 782 | +N: sun[x4567]i | |
| 783 | + | |
| 784 | +ARM/Allwinner SoC Clock Support | |
| 785 | +M: Emilio López <emilio@elopez.com.ar> | |
| 786 | +S: Maintained | |
| 787 | +F: drivers/clk/sunxi/ | |
| 770 | 788 | |
| 771 | 789 | ARM/ATMEL AT91RM9200 AND AT91SAM ARM ARCHITECTURES |
| 772 | 790 | M: Andrew Victor <linux@maxim.org.za> |
| @@ -867,6 +885,12 @@ S: Maintained · 94 unmodified lines | ||
| 867 | 885 | F: arch/arm/mach-ebsa110/ |
| 868 | 886 | F: drivers/net/ethernet/amd/am79c961a.* |
| 869 | 887 | |
| 888 | +ARM/ENERGY MICRO (SILICON LABS) EFM32 SUPPORT | |
| 889 | +M: Uwe Kleine-König <kernel@pengutronix.de> | |
| 890 | +L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers) | |
| 891 | +S: Maintained | |
| 892 | +N: efm32 | |
| 893 | + | |
| 870 | 894 | ARM/EZX SMARTPHONES (A780, A910, A1200, E680, ROKR E2 and ROKR E6) |
| 871 | 895 | M: Daniel Ribeiro <drwyrm@gmail.com> |
| 872 | 896 | M: Stefan Schmidt <stefan@openezx.org> |
| @@ -1029,6 +1053,12 @@ L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers) · 156 unmodified lines | ||
| 1029 | 1053 | S: Maintained |
| 1030 | 1054 | F: arch/arm/mach-mvebu/ |
| 1031 | 1055 | |
| 1056 | +ARM/Marvell Berlin SoC support | |
| 1057 | +M: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> | |
| 1058 | +L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers) | |
| 1059 | +S: Maintained | |
| 1060 | +F: arch/arm/mach-berlin/ | |
| 1061 | + | |
| 1032 | 1062 | ARM/Marvell Dove/Kirkwood/MV78xx0/Orion SOC support |
| 1033 | 1063 | M: Jason Cooper <jason@lakedaemon.net> |
| 1034 | 1064 | M: Andrew Lunn <andrew@lunn.ch> |
| @@ -1322,6 +1352,14 @@ F: drivers/rtc/rtc-ab8500.c · 287 unmodified lines | ||
| 1322 | 1352 | F: drivers/rtc/rtc-pl031.c |
| 1323 | 1353 | T: git git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-stericsson.git |
| 1324 | 1354 | |
| 1355 | +ARM/Ux500 CLOCK FRAMEWORK SUPPORT | |
| 1356 | +M: Ulf Hansson <ulf.hansson@linaro.org> | |
| 1357 | +L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers) | |
| 1358 | +T: git git://git.linaro.org/people/ulfh/clk.git | |
| 1359 | +S: Maintained | |
| 1360 | +F: drivers/clk/ux500/ | |
| 1361 | +F: include/linux/platform_data/clk-ux500.h | |
| 1362 | + | |
| 1325 | 1363 | ARM/VFP SUPPORT |
| 1326 | 1364 | M: Russell King <linux@arm.linux.org.uk> |
| 1327 | 1365 | L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers) |
| @@ -1371,6 +1409,7 @@ F: drivers/cpuidle/cpuidle-zynq.c · 43 unmodified lines | ||
| 1371 | 1409 | N: zynq |
| 1372 | 1410 | N: xilinx |
| 1373 | 1411 | F: drivers/clocksource/cadence_ttc_timer.c |
| 1412 | +F: drivers/mmc/host/sdhci-of-arasan.c | |
| 1374 | 1413 | |
| 1375 | 1414 | ARM SMMU DRIVER |
| 1376 | 1415 | M: Will Deacon <will.deacon@arm.com> |
| @@ -1435,7 +1474,7 @@ F: Documentation/aoe/ · 58 unmodified lines | ||
| 1435 | 1474 | F: drivers/block/aoe/ |
| 1436 | 1475 | |
| 1437 | 1476 | ATHEROS ATH GENERIC UTILITIES |
| 1438 | −M: "Luis R. Rodriguez" <mcgrof@qca.qualcomm.com> | |
| 1477 | +M: "Luis R. Rodriguez" <mcgrof@do-not-panic.com> | |
| 1439 | 1478 | L: linux-wireless@vger.kernel.org |
| 1440 | 1479 | S: Supported |
| 1441 | 1480 | F: drivers/net/wireless/ath/* |
| @@ -1443,7 +1482,7 @@ F: drivers/net/wireless/ath/* · 1 unmodified line | ||
| 1443 | 1482 | ATHEROS ATH5K WIRELESS DRIVER |
| 1444 | 1483 | M: Jiri Slaby <jirislaby@gmail.com> |
| 1445 | 1484 | M: Nick Kossifidis <mickflemm@gmail.com> |
| 1446 | −M: "Luis R. Rodriguez" <mcgrof@qca.qualcomm.com> | |
| 1485 | +M: "Luis R. Rodriguez" <mcgrof@do-not-panic.com> | |
| 1447 | 1486 | L: linux-wireless@vger.kernel.org |
| 1448 | 1487 | L: ath5k-devel@lists.ath5k.org |
| 1449 | 1488 | W: http://wireless.kernel.org/en/users/Drivers/ath5k |
| @@ -1458,17 +1497,6 @@ T: git git://github.com/kvalo/ath.git · 8 unmodified lines | ||
| 1458 | 1497 | S: Supported |
| 1459 | 1498 | F: drivers/net/wireless/ath/ath6kl/ |
| 1460 | 1499 | |
| 1461 | −ATHEROS ATH9K WIRELESS DRIVER | |
| 1462 | −M: "Luis R. Rodriguez" <mcgrof@qca.qualcomm.com> | |
| 1463 | −M: Jouni Malinen <jouni@qca.qualcomm.com> | |
| 1464 | −M: Vasanthakumar Thiagarajan <vthiagar@qca.qualcomm.com> | |
| 1465 | −M: Senthil Balasubramanian <senthilb@qca.qualcomm.com> | |
| 1466 | −L: linux-wireless@vger.kernel.org | |
| 1467 | −L: ath9k-devel@lists.ath9k.org | |
| 1468 | −W: http://wireless.kernel.org/en/users/Drivers/ath9k | |
| 1469 | −S: Supported | |
| 1470 | −F: drivers/net/wireless/ath/ath9k/ | |
| 1471 | − | |
| 1472 | 1500 | WILOCITY WIL6210 WIRELESS DRIVER |
| 1473 | 1501 | M: Vladimir Kondratiev <qca_vkondrat@qca.qualcomm.com> |
| 1474 | 1502 | L: linux-wireless@vger.kernel.org |
| @@ -1598,11 +1626,10 @@ S: Supported · 123 unmodified lines | ||
| 1598 | 1626 | F: drivers/scsi/esas2r |
| 1599 | 1627 | |
| 1600 | 1628 | AUDIT SUBSYSTEM |
| 1601 | −M: Al Viro <viro@zeniv.linux.org.uk> | |
| 1602 | 1629 | M: Eric Paris <eparis@redhat.com> |
| 1603 | 1630 | L: linux-audit@redhat.com (subscribers-only) |
| 1604 | 1631 | W: http://people.redhat.com/sgrubb/audit/ |
| 1605 | −T: git git://git.kernel.org/pub/scm/linux/kernel/git/viro/audit-current.git | |
| 1632 | +T: git git://git.infradead.org/users/eparis/audit.git | |
| 1606 | 1633 | S: Maintained |
| 1607 | 1634 | F: include/linux/audit.h |
| 1608 | 1635 | F: include/uapi/linux/audit.h |
| @@ -1715,56 +1742,54 @@ F: fs/bfs/ · 106 unmodified lines | ||
| 1715 | 1742 | F: include/uapi/linux/bfs_fs.h |
| 1716 | 1743 | |
| 1717 | 1744 | BLACKFIN ARCHITECTURE |
| 1718 | −M: Mike Frysinger <vapier@gentoo.org> | |
| 1719 | −L: uclinux-dist-devel@blackfin.uclinux.org | |
| 1745 | +M: Steven Miao <realmz6@gmail.com> | |
| 1746 | +L: adi-buildroot-devel@lists.sourceforge.net | |
| 1720 | 1747 | W: http://blackfin.uclinux.org |
| 1721 | 1748 | S: Supported |
| 1722 | 1749 | F: arch/blackfin/ |
| 1723 | 1750 | |
| 1724 | 1751 | BLACKFIN EMAC DRIVER |
| 1725 | −L: uclinux-dist-devel@blackfin.uclinux.org | |
| 1752 | +L: adi-buildroot-devel@lists.sourceforge.net | |
| 1726 | 1753 | W: http://blackfin.uclinux.org |
| 1727 | 1754 | S: Supported |
| 1728 | 1755 | F: drivers/net/ethernet/adi/ |
| 1729 | 1756 | |
| 1730 | 1757 | BLACKFIN RTC DRIVER |
| 1731 | −M: Mike Frysinger <vapier.adi@gmail.com> | |
| 1732 | −L: uclinux-dist-devel@blackfin.uclinux.org | |
| 1758 | +L: adi-buildroot-devel@lists.sourceforge.net | |
| 1733 | 1759 | W: http://blackfin.uclinux.org |
| 1734 | 1760 | S: Supported |
| 1735 | 1761 | F: drivers/rtc/rtc-bfin.c |
| 1736 | 1762 | |
| 1737 | 1763 | BLACKFIN SDH DRIVER |
| 1738 | 1764 | M: Sonic Zhang <sonic.zhang@analog.com> |
| 1739 | −L: uclinux-dist-devel@blackfin.uclinux.org | |
| 1765 | +L: adi-buildroot-devel@lists.sourceforge.net | |
| 1740 | 1766 | W: http://blackfin.uclinux.org |
| 1741 | 1767 | S: Supported |
| 1742 | 1768 | F: drivers/mmc/host/bfin_sdh.c |
| 1743 | 1769 | |
| 1744 | 1770 | BLACKFIN SERIAL DRIVER |
| 1745 | 1771 | M: Sonic Zhang <sonic.zhang@analog.com> |
| 1746 | −L: uclinux-dist-devel@blackfin.uclinux.org | |
| 1772 | +L: adi-buildroot-devel@lists.sourceforge.net | |
| 1747 | 1773 | W: http://blackfin.uclinux.org |
| 1748 | 1774 | S: Supported |
| 1749 | 1775 | F: drivers/tty/serial/bfin_uart.c |
| 1750 | 1776 | |
| 1751 | 1777 | BLACKFIN WATCHDOG DRIVER |
| 1752 | −M: Mike Frysinger <vapier.adi@gmail.com> | |
| 1753 | −L: uclinux-dist-devel@blackfin.uclinux.org | |
| 1778 | +L: adi-buildroot-devel@lists.sourceforge.net | |
| 1754 | 1779 | W: http://blackfin.uclinux.org |
| 1755 | 1780 | S: Supported |
| 1756 | 1781 | F: drivers/watchdog/bfin_wdt.c |
| 1757 | 1782 | |
| 1758 | 1783 | BLACKFIN I2C TWI DRIVER |
| 1759 | 1784 | M: Sonic Zhang <sonic.zhang@analog.com> |
| 1760 | −L: uclinux-dist-devel@blackfin.uclinux.org | |
| 1785 | +L: adi-buildroot-devel@lists.sourceforge.net | |
| 1761 | 1786 | W: http://blackfin.uclinux.org/ |
| 1762 | 1787 | S: Supported |
| 1763 | 1788 | F: drivers/i2c/busses/i2c-bfin-twi.c |
| 1764 | 1789 | |
| 1765 | 1790 | BLACKFIN MEDIA DRIVER |
| 1766 | 1791 | M: Scott Jiang <scott.jiang.linux@gmail.com> |
| 1767 | −L: uclinux-dist-devel@blackfin.uclinux.org | |
| 1792 | +L: adi-buildroot-devel@lists.sourceforge.net | |
| 1768 | 1793 | W: http://blackfin.uclinux.org/ |
| 1769 | 1794 | S: Supported |
| 1770 | 1795 | F: drivers/media/platform/blackfin/ |
| @@ -2024,6 +2049,7 @@ L: linux-can@vger.kernel.org · 253 unmodified lines | ||
| 2024 | 2049 | W: http://gitorious.org/linux-can |
| 2025 | 2050 | T: git git://gitorious.org/linux-can/linux-can-next.git |
| 2026 | 2051 | S: Maintained |
| 2052 | +F: Documentation/networking/can.txt | |
| 2027 | 2053 | F: net/can/ |
| 2028 | 2054 | F: include/linux/can/core.h |
| 2029 | 2055 | F: include/uapi/linux/can.h |
| @@ -2158,6 +2184,11 @@ M: Nishank Trivedi <nistrive@cisco.com> · 128 unmodified lines | ||
| 2158 | 2184 | S: Supported |
| 2159 | 2185 | F: drivers/net/ethernet/cisco/enic/ |
| 2160 | 2186 | |
| 2187 | +CISCO VIC LOW LATENCY NIC DRIVER | |
| 2188 | +M: Upinder Malhi <umalhi@cisco.com> | |
| 2189 | +S: Supported | |
| 2190 | +F: drivers/infiniband/hw/usnic | |
| 2191 | + | |
| 2161 | 2192 | CIRRUS LOGIC EP93XX ETHERNET DRIVER |
| 2162 | 2193 | M: Hartley Sweeten <hsweeten@visionengravers.com> |
| 2163 | 2194 | L: netdev@vger.kernel.org |
| @@ -2191,6 +2222,7 @@ F: include/linux/clk.h · 27 unmodified lines | ||
| 2191 | 2222 | CLOCKSOURCE, CLOCKEVENT DRIVERS |
| 2192 | 2223 | M: Daniel Lezcano <daniel.lezcano@linaro.org> |
| 2193 | 2224 | M: Thomas Gleixner <tglx@linutronix.de> |
| 2225 | +L: linux-kernel@vger.kernel.org | |
| 2194 | 2226 | T: git git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git timers/core |
| 2195 | 2227 | S: Supported |
| 2196 | 2228 | F: drivers/clocksource |
| @@ -2619,7 +2651,7 @@ S: Maintained · 422 unmodified lines | ||
| 2619 | 2651 | F: drivers/platform/x86/dell-laptop.c |
| 2620 | 2652 | |
| 2621 | 2653 | DELL LAPTOP SMM DRIVER |
| 2622 | −S: Orphan | |
| 2654 | +M: Guenter Roeck <linux@roeck-us.net> | |
| 2623 | 2655 | F: drivers/char/i8k.c |
| 2624 | 2656 | F: include/uapi/linux/i8k.h |
| 2625 | 2657 | |
| @@ -2638,7 +2670,7 @@ DESIGNWARE USB2 DRD IP DRIVER · 12 unmodified lines | ||
| 2638 | 2670 | M: Paul Zimmerman <paulz@synopsys.com> |
| 2639 | 2671 | L: linux-usb@vger.kernel.org |
| 2640 | 2672 | S: Maintained |
| 2641 | −F: drivers/staging/dwc2/ | |
| 2673 | +F: drivers/usb/dwc2/ | |
| 2642 | 2674 | |
| 2643 | 2675 | DESIGNWARE USB3 DRD IP DRIVER |
| 2644 | 2676 | M: Felipe Balbi <balbi@ti.com> |
| @@ -3335,6 +3367,7 @@ EXTERNAL CONNECTOR SUBSYSTEM (EXTCON) · 690 unmodified lines | ||
| 3335 | 3367 | M: MyungJoo Ham <myungjoo.ham@samsung.com> |
| 3336 | 3368 | M: Chanwoo Choi <cw00.choi@samsung.com> |
| 3337 | 3369 | L: linux-kernel@vger.kernel.org |
| 3370 | +T: git git://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/extcon.git | |
| 3338 | 3371 | S: Maintained |
| 3339 | 3372 | F: drivers/extcon/ |
| 3340 | 3373 | F: Documentation/extcon/ |
| @@ -3344,7 +3377,6 @@ M: Jingoo Han <jg1.han@samsung.com> · 3 unmodified lines | ||
| 3344 | 3377 | L: linux-fbdev@vger.kernel.org |
| 3345 | 3378 | S: Maintained |
| 3346 | 3379 | F: drivers/video/exynos/exynos_dp* |
| 3347 | −F: include/video/exynos_dp* | |
| 3348 | 3380 | |
| 3349 | 3381 | EXYNOS MIPI DISPLAY DRIVERS |
| 3350 | 3382 | M: Inki Dae <inki.dae@samsung.com> |
| @@ -3356,7 +3388,7 @@ F: drivers/video/exynos/exynos_mipi* · 5 unmodified lines | ||
| 3356 | 3388 | F: include/video/exynos_mipi* |
| 3357 | 3389 | |
| 3358 | 3390 | F71805F HARDWARE MONITORING DRIVER |
| 3359 | −M: Jean Delvare <khali@linux-fr.org> | |
| 3391 | +M: Jean Delvare <jdelvare@suse.de> | |
| 3360 | 3392 | L: lm-sensors@lm-sensors.org |
| 3361 | 3393 | S: Maintained |
| 3362 | 3394 | F: Documentation/hwmon/f71805f |
| @@ -3634,6 +3666,7 @@ W: http://en.wikipedia.org/wiki/F2FS · 271 unmodified lines | ||
| 3634 | 3666 | T: git git://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs.git |
| 3635 | 3667 | S: Maintained |
| 3636 | 3668 | F: Documentation/filesystems/f2fs.txt |
| 3669 | +F: Documentation/ABI/testing/sysfs-fs-f2fs | |
| 3637 | 3670 | F: fs/f2fs/ |
| 3638 | 3671 | F: include/linux/f2fs_fs.h |
| 3639 | 3672 | |
| @@ -3882,7 +3915,7 @@ S: Odd Fixes · 242 unmodified lines | ||
| 3882 | 3915 | F: drivers/tty/hvc/ |
| 3883 | 3916 | |
| 3884 | 3917 | HARDWARE MONITORING |
| 3885 | −M: Jean Delvare <khali@linux-fr.org> | |
| 3918 | +M: Jean Delvare <jdelvare@suse.de> | |
| 3886 | 3919 | M: Guenter Roeck <linux@roeck-us.net> |
| 3887 | 3920 | L: lm-sensors@lm-sensors.org |
| 3888 | 3921 | W: http://www.lm-sensors.org/ |
| @@ -3954,6 +3987,12 @@ S: Orphan · 65 unmodified lines | ||
| 3954 | 3987 | F: Documentation/filesystems/hfs.txt |
| 3955 | 3988 | F: fs/hfs/ |
| 3956 | 3989 | |
| 3990 | +HFSPLUS FILESYSTEM | |
| 3991 | +L: linux-fsdevel@vger.kernel.org | |
| 3992 | +S: Orphan | |
| 3993 | +F: Documentation/filesystems/hfsplus.txt | |
| 3994 | +F: fs/hfsplus/ | |
| 3995 | + | |
| 3957 | 3996 | HGA FRAMEBUFFER DRIVER |
| 3958 | 3997 | M: Ferenc Bakonyi <fero@drama.obuda.kando.hu> |
| 3959 | 3998 | L: linux-nvidia@lists.surfsouth.com |
| @@ -3985,6 +4024,7 @@ F: include/uapi/linux/hid* · 25 unmodified lines | ||
| 3985 | 4024 | |
| 3986 | 4025 | HIGH-RESOLUTION TIMERS, CLOCKEVENTS, DYNTICKS |
| 3987 | 4026 | M: Thomas Gleixner <tglx@linutronix.de> |
| 4027 | +L: linux-kernel@vger.kernel.org | |
| 3988 | 4028 | T: git git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git timers/core |
| 3989 | 4029 | S: Maintained |
| 3990 | 4030 | F: Documentation/timers/ |
| @@ -4104,7 +4144,7 @@ F: include/linux/hyperv.h · 113 unmodified lines | ||
| 4104 | 4144 | F: tools/hv/ |
| 4105 | 4145 | |
| 4106 | 4146 | I2C OVER PARALLEL PORT |
| 4107 | −M: Jean Delvare <khali@linux-fr.org> | |
| 4147 | +M: Jean Delvare <jdelvare@suse.de> | |
| 4108 | 4148 | L: linux-i2c@vger.kernel.org |
| 4109 | 4149 | S: Maintained |
| 4110 | 4150 | F: Documentation/i2c/busses/i2c-parport |
| @@ -4113,7 +4153,7 @@ F: drivers/i2c/busses/i2c-parport.c · 2 unmodified lines | ||
| 4113 | 4153 | F: drivers/i2c/busses/i2c-parport-light.c |
| 4114 | 4154 | |
| 4115 | 4155 | I2C/SMBUS CONTROLLER DRIVERS FOR PC |
| 4116 | −M: Jean Delvare <khali@linux-fr.org> | |
| 4156 | +M: Jean Delvare <jdelvare@suse.de> | |
| 4117 | 4157 | L: linux-i2c@vger.kernel.org |
| 4118 | 4158 | S: Maintained |
| 4119 | 4159 | F: Documentation/i2c/busses/i2c-ali1535 |
| @@ -4154,7 +4194,7 @@ F: drivers/i2c/busses/i2c-ismt.c · 34 unmodified lines | ||
| 4154 | 4194 | F: Documentation/i2c/busses/i2c-ismt |
| 4155 | 4195 | |
| 4156 | 4196 | I2C/SMBUS STUB DRIVER |
| 4157 | −M: Jean Delvare <khali@linux-fr.org> | |
| 4197 | +M: Jean Delvare <jdelvare@suse.de> | |
| 4158 | 4198 | L: linux-i2c@vger.kernel.org |
| 4159 | 4199 | S: Maintained |
| 4160 | 4200 | F: drivers/i2c/i2c-stub.c |
| @@ -4173,7 +4213,7 @@ F: include/uapi/linux/i2c.h · 12 unmodified lines | ||
| 4173 | 4213 | F: include/uapi/linux/i2c-*.h |
| 4174 | 4214 | |
| 4175 | 4215 | I2C-TAOS-EVM DRIVER |
| 4176 | −M: Jean Delvare <khali@linux-fr.org> | |
| 4216 | +M: Jean Delvare <jdelvare@suse.de> | |
| 4177 | 4217 | L: linux-i2c@vger.kernel.org |
| 4178 | 4218 | S: Maintained |
| 4179 | 4219 | F: Documentation/i2c/busses/i2c-taos-evm |
| @@ -4474,7 +4514,7 @@ M: Deepak Saxena <dsaxena@plexity.net> · 294 unmodified lines | ||
| 4474 | 4514 | S: Maintained |
| 4475 | 4515 | F: drivers/char/hw_random/ixp4xx-rng.c |
| 4476 | 4516 | |
| 4477 | −INTEL ETHERNET DRIVERS (e100/e1000/e1000e/igb/igbvf/ixgb/ixgbe/ixgbevf/i40e) | |
| 4517 | +INTEL ETHERNET DRIVERS (e100/e1000/e1000e/igb/igbvf/ixgb/ixgbe/ixgbevf/i40e/i40evf) | |
| 4478 | 4518 | M: Jeff Kirsher <jeffrey.t.kirsher@intel.com> |
| 4479 | 4519 | M: Jesse Brandeburg <jesse.brandeburg@intel.com> |
| 4480 | 4520 | M: Bruce Allan <bruce.w.allan@intel.com> |
| @@ -4483,6 +4523,7 @@ M: Don Skidmore <donald.c.skidmore@intel.com> · 2 unmodified lines | ||
| 4483 | 4523 | M: Greg Rose <gregory.v.rose@intel.com> |
| 4484 | 4524 | M: Alex Duyck <alexander.h.duyck@intel.com> |
| 4485 | 4525 | M: John Ronciak <john.ronciak@intel.com> |
| 4526 | +M: Mitch Williams <mitch.a.williams@intel.com> | |
| 4486 | 4527 | L: e1000-devel@lists.sourceforge.net |
| 4487 | 4528 | W: http://www.intel.com/support/feedback.htm |
| 4488 | 4529 | W: http://e1000.sourceforge.net/ |
| @@ -4498,6 +4539,7 @@ F: Documentation/networking/ixgb.txt · 9 unmodified lines | ||
| 4498 | 4539 | F: Documentation/networking/ixgbe.txt |
| 4499 | 4540 | F: Documentation/networking/ixgbevf.txt |
| 4500 | 4541 | F: Documentation/networking/i40e.txt |
| 4542 | +F: Documentation/networking/i40evf.txt | |
| 4501 | 4543 | F: drivers/net/ethernet/intel/ |
| 4502 | 4544 | |
| 4503 | 4545 | INTEL-MID GPIO DRIVER |
| @@ -4654,6 +4696,7 @@ F: net/irda/ · 150 unmodified lines | ||
| 4654 | 4696 | |
| 4655 | 4697 | IRQ SUBSYSTEM |
| 4656 | 4698 | M: Thomas Gleixner <tglx@linutronix.de> |
| 4699 | +L: linux-kernel@vger.kernel.org | |
| 4657 | 4700 | S: Maintained |
| 4658 | 4701 | T: git git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git irq/core |
| 4659 | 4702 | F: kernel/irq/ |
| @@ -4728,7 +4771,7 @@ S: Maintained · 68 unmodified lines | ||
| 4728 | 4771 | F: drivers/isdn/hardware/eicon/ |
| 4729 | 4772 | |
| 4730 | 4773 | IT87 HARDWARE MONITORING DRIVER |
| 4731 | −M: Jean Delvare <khali@linux-fr.org> | |
| 4774 | +M: Jean Delvare <jdelvare@suse.de> | |
| 4732 | 4775 | L: lm-sensors@lm-sensors.org |
| 4733 | 4776 | S: Maintained |
| 4734 | 4777 | F: Documentation/hwmon/it87 |
| @@ -4915,7 +4958,7 @@ F: include/linux/sunrpc/ · 180 unmodified lines | ||
| 4915 | 4958 | F: include/uapi/linux/sunrpc/ |
| 4916 | 4959 | |
| 4917 | 4960 | KERNEL VIRTUAL MACHINE (KVM) |
| 4918 | −M: Gleb Natapov <gleb@redhat.com> | |
| 4961 | +M: Gleb Natapov <gleb@kernel.org> | |
| 4919 | 4962 | M: Paolo Bonzini <pbonzini@redhat.com> |
| 4920 | 4963 | L: kvm@vger.kernel.org |
| 4921 | 4964 | W: http://www.linux-kvm.org |
| @@ -5098,7 +5141,7 @@ F: drivers/leds/ · 176 unmodified lines | ||
| 5098 | 5141 | F: include/linux/leds.h |
| 5099 | 5142 | |
| 5100 | 5143 | LEGACY EEPROM DRIVER |
| 5101 | −M: Jean Delvare <khali@linux-fr.org> | |
| 5144 | +M: Jean Delvare <jdelvare@suse.de> | |
| 5102 | 5145 | S: Maintained |
| 5103 | 5146 | F: Documentation/misc-devices/eeprom |
| 5104 | 5147 | F: drivers/misc/eeprom/eeprom.c |
| @@ -5246,21 +5289,21 @@ S: Maintained · 141 unmodified lines | ||
| 5246 | 5289 | F: drivers/hwmon/lm73.c |
| 5247 | 5290 | |
| 5248 | 5291 | LM78 HARDWARE MONITOR DRIVER |
| 5249 | −M: Jean Delvare <khali@linux-fr.org> | |
| 5292 | +M: Jean Delvare <jdelvare@suse.de> | |
| 5250 | 5293 | L: lm-sensors@lm-sensors.org |
| 5251 | 5294 | S: Maintained |
| 5252 | 5295 | F: Documentation/hwmon/lm78 |
| 5253 | 5296 | F: drivers/hwmon/lm78.c |
| 5254 | 5297 | |
| 5255 | 5298 | LM83 HARDWARE MONITOR DRIVER |
| 5256 | −M: Jean Delvare <khali@linux-fr.org> | |
| 5299 | +M: Jean Delvare <jdelvare@suse.de> | |
| 5257 | 5300 | L: lm-sensors@lm-sensors.org |
| 5258 | 5301 | S: Maintained |
| 5259 | 5302 | F: Documentation/hwmon/lm83 |
| 5260 | 5303 | F: drivers/hwmon/lm83.c |
| 5261 | 5304 | |
| 5262 | 5305 | LM90 HARDWARE MONITOR DRIVER |
| 5263 | −M: Jean Delvare <khali@linux-fr.org> | |
| 5306 | +M: Jean Delvare <jdelvare@suse.de> | |
| 5264 | 5307 | L: lm-sensors@lm-sensors.org |
| 5265 | 5308 | S: Maintained |
| 5266 | 5309 | F: Documentation/hwmon/lm90 |
| @@ -5285,6 +5328,7 @@ F: drivers/media/usb/dvb-usb-v2/lmedm04* · 18 unmodified lines | ||
| 5285 | 5328 | LOCKDEP AND LOCKSTAT |
| 5286 | 5329 | M: Peter Zijlstra <peterz@infradead.org> |
| 5287 | 5330 | M: Ingo Molnar <mingo@redhat.com> |
| 5331 | +L: linux-kernel@vger.kernel.org | |
| 5288 | 5332 | T: git git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git core/locking |
| 5289 | 5333 | S: Maintained |
| 5290 | 5334 | F: Documentation/lockdep*.txt |
| @@ -5381,6 +5425,16 @@ W: http://www.tazenda.demon.co.uk/phil/linux-hp · 90 unmodified lines | ||
| 5381 | 5425 | S: Maintained |
| 5382 | 5426 | F: arch/m68k/hp300/ |
| 5383 | 5427 | |
| 5428 | +M88DS3103 MEDIA DRIVER | |
| 5429 | +M: Antti Palosaari <crope@iki.fi> | |
| 5430 | +L: linux-media@vger.kernel.org | |
| 5431 | +W: http://linuxtv.org/ | |
| 5432 | +W: http://palosaari.fi/linux/ | |
| 5433 | +Q: http://patchwork.linuxtv.org/project/linux-media/list/ | |
| 5434 | +T: git git://linuxtv.org/anttip/media_tree.git | |
| 5435 | +S: Maintained | |
| 5436 | +F: drivers/media/dvb-frontends/m88ds3103* | |
| 5437 | + | |
| 5384 | 5438 | M88RS2000 MEDIA DRIVER |
| 5385 | 5439 | M: Malcolm Priestley <tvboxspy@gmail.com> |
| 5386 | 5440 | L: linux-media@vger.kernel.org |
| @@ -5389,6 +5443,16 @@ Q: http://patchwork.linuxtv.org/project/linux-media/list/ · 2 unmodified lines | ||
| 5389 | 5443 | S: Maintained |
| 5390 | 5444 | F: drivers/media/dvb-frontends/m88rs2000* |
| 5391 | 5445 | |
| 5446 | +M88TS2022 MEDIA DRIVER | |
| 5447 | +M: Antti Palosaari <crope@iki.fi> | |
| 5448 | +L: linux-media@vger.kernel.org | |
| 5449 | +W: http://linuxtv.org/ | |
| 5450 | +W: http://palosaari.fi/linux/ | |
| 5451 | +Q: http://patchwork.linuxtv.org/project/linux-media/list/ | |
| 5452 | +T: git git://linuxtv.org/anttip/media_tree.git | |
| 5453 | +S: Maintained | |
| 5454 | +F: drivers/media/tuners/m88ts2022* | |
| 5455 | + | |
| 5392 | 5456 | MA901 MASTERKIT USB FM RADIO DRIVER |
| 5393 | 5457 | M: Alexey Klimov <klimov.linux@gmail.com> |
| 5394 | 5458 | L: linux-media@vger.kernel.org |
| @@ -5580,10 +5644,11 @@ F: mm/page_cgroup.c · 185 unmodified lines | ||
| 5580 | 5644 | |
| 5581 | 5645 | MEMORY TECHNOLOGY DEVICES (MTD) |
| 5582 | 5646 | M: David Woodhouse <dwmw2@infradead.org> |
| 5647 | +M: Brian Norris <computersforpeace@gmail.com> | |
| 5583 | 5648 | L: linux-mtd@lists.infradead.org |
| 5584 | 5649 | W: http://www.linux-mtd.infradead.org/ |
| 5585 | 5650 | Q: http://patchwork.ozlabs.org/project/linux-mtd/list/ |
| 5586 | −T: git git://git.infradead.org/mtd-2.6.git | |
| 5651 | +T: git git://git.infradead.org/linux-mtd.git | |
| 5587 | 5652 | S: Maintained |
| 5588 | 5653 | F: drivers/mtd/ |
| 5589 | 5654 | F: include/linux/mtd/ |
| @@ -5741,7 +5806,7 @@ F: drivers/mfd/ · 151 unmodified lines | ||
| 5741 | 5806 | F: include/linux/mfd/ |
| 5742 | 5807 | |
| 5743 | 5808 | MULTIMEDIA CARD (MMC), SECURE DIGITAL (SD) AND SDIO SUBSYSTEM |
| 5744 | −M: Chris Ball <cjb@laptop.org> | |
| 5809 | +M: Chris Ball <chris@printf.net> | |
| 5745 | 5810 | L: linux-mmc@vger.kernel.org |
| 5746 | 5811 | T: git git://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc.git |
| 5747 | 5812 | S: Maintained |
| @@ -6452,7 +6517,7 @@ S: Maintained · 704 unmodified lines | ||
| 6452 | 6517 | F: drivers/char/pc8736x_gpio.c |
| 6453 | 6518 | |
| 6454 | 6519 | PC87427 HARDWARE MONITORING DRIVER |
| 6455 | −M: Jean Delvare <khali@linux-fr.org> | |
| 6520 | +M: Jean Delvare <jdelvare@suse.de> | |
| 6456 | 6521 | L: lm-sensors@lm-sensors.org |
| 6457 | 6522 | S: Maintained |
| 6458 | 6523 | F: Documentation/hwmon/pc87427 |
| @@ -6581,6 +6646,7 @@ M: Peter Zijlstra <a.p.zijlstra@chello.nl> · 122 unmodified lines | ||
| 6581 | 6646 | M: Paul Mackerras <paulus@samba.org> |
| 6582 | 6647 | M: Ingo Molnar <mingo@redhat.com> |
| 6583 | 6648 | M: Arnaldo Carvalho de Melo <acme@ghostprotocols.net> |
| 6649 | +L: linux-kernel@vger.kernel.org | |
| 6584 | 6650 | T: git git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git perf/core |
| 6585 | 6651 | S: Supported |
| 6586 | 6652 | F: kernel/events/* |
| @@ -6704,6 +6770,7 @@ F: drivers/scsi/pm8001/ · 117 unmodified lines | ||
| 6704 | 6770 | |
| 6705 | 6771 | POSIX CLOCKS and TIMERS |
| 6706 | 6772 | M: Thomas Gleixner <tglx@linutronix.de> |
| 6773 | +L: linux-kernel@vger.kernel.org | |
| 6707 | 6774 | T: git git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git timers/core |
| 6708 | 6775 | S: Supported |
| 6709 | 6776 | F: fs/timerfd.c |
| @@ -6711,7 +6778,7 @@ F: include/linux/timer* · 1 unmodified line | ||
| 6711 | 6778 | F: kernel/*timer* |
| 6712 | 6779 | |
| 6713 | 6780 | POWER SUPPLY CLASS/SUBSYSTEM and DRIVERS |
| 6714 | −M: Anton Vorontsov <anton@enomsg.org> | |
| 6781 | +M: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com> | |
| 6715 | 6782 | M: David Woodhouse <dwmw2@infradead.org> |
| 6716 | 6783 | T: git git://git.infradead.org/battery-2.6.git |
| 6717 | 6784 | S: Maintained |
| @@ -6900,6 +6967,12 @@ F: include/sound/pxa2xx-lib.h · 182 unmodified lines | ||
| 6900 | 6967 | F: sound/arm/pxa* |
| 6901 | 6968 | F: sound/soc/pxa/ |
| 6902 | 6969 | |
| 6970 | +PXA3xx NAND FLASH DRIVER | |
| 6971 | +M: Ezequiel Garcia <ezequiel.garcia@free-electrons.com> | |
| 6972 | +L: linux-mtd@lists.infradead.org | |
| 6973 | +S: Maintained | |
| 6974 | +F: drivers/mtd/nand/pxa3xx-nand.c | |
| 6975 | + | |
| 6903 | 6976 | MMP SUPPORT |
| 6904 | 6977 | M: Eric Miao <eric.y.miao@gmail.com> |
| 6905 | 6978 | M: Haojian Zhuang <haojian.zhuang@gmail.com> |
| @@ -6930,8 +7003,7 @@ S: Maintained · 24 unmodified lines | ||
| 6930 | 7003 | F: drivers/scsi/qla1280.[ch] |
| 6931 | 7004 | |
| 6932 | 7005 | QLOGIC QLA2XXX FC-SCSI DRIVER |
| 6933 | −M: Andrew Vasquez <andrew.vasquez@qlogic.com> | |
| 6934 | −M: linux-driver@qlogic.com | |
| 7006 | +M: qla2xxx-upstream@qlogic.com | |
| 6935 | 7007 | L: linux-scsi@vger.kernel.org |
| 6936 | 7008 | S: Supported |
| 6937 | 7009 | F: Documentation/scsi/LICENSE.qla2xxx |
| @@ -6993,6 +7065,14 @@ T: git git://linuxtv.org/anttip/media_tree.git · 55 unmodified lines | ||
| 6993 | 7065 | S: Maintained |
| 6994 | 7066 | F: drivers/media/tuners/qt1010* |
| 6995 | 7067 | |
| 7068 | +QUALCOMM ATHEROS ATH9K WIRELESS DRIVER | |
| 7069 | +M: QCA ath9k Development <ath9k-devel@qca.qualcomm.com> | |
| 7070 | +L: linux-wireless@vger.kernel.org | |
| 7071 | +L: ath9k-devel@lists.ath9k.org | |
| 7072 | +W: http://wireless.kernel.org/en/users/Drivers/ath9k | |
| 7073 | +S: Supported | |
| 7074 | +F: drivers/net/wireless/ath/ath9k/ | |
| 7075 | + | |
| 6996 | 7076 | QUALCOMM ATHEROS ATH10K WIRELESS DRIVER |
| 6997 | 7077 | M: Kalle Valo <kvalo@qca.qualcomm.com> |
| 6998 | 7078 | L: ath10k@lists.infradead.org |
| @@ -7026,7 +7106,7 @@ F: drivers/media/parport/*-qcam* · 27 unmodified lines | ||
| 7026 | 7106 | RADOS BLOCK DEVICE (RBD) |
| 7027 | 7107 | M: Yehuda Sadeh <yehuda@inktank.com> |
| 7028 | 7108 | M: Sage Weil <sage@inktank.com> |
| 7029 | −M: Alex Elder <elder@inktank.com> | |
| 7109 | +M: Alex Elder <elder@kernel.org> | |
| 7030 | 7110 | M: ceph-devel@vger.kernel.org |
| 7031 | 7111 | W: http://ceph.com/ |
| 7032 | 7112 | T: git git://git.kernel.org/pub/scm/linux/kernel/git/sage/ceph-client.git |
| @@ -7099,6 +7179,7 @@ F: drivers/net/wireless/ray* · 66 unmodified lines | ||
| 7099 | 7179 | RCUTORTURE MODULE |
| 7100 | 7180 | M: Josh Triplett <josh@freedesktop.org> |
| 7101 | 7181 | M: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> |
| 7182 | +L: linux-kernel@vger.kernel.org | |
| 7102 | 7183 | S: Supported |
| 7103 | 7184 | T: git git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git |
| 7104 | 7185 | F: Documentation/RCU/torture.txt |
| @@ -7106,6 +7187,7 @@ F: kernel/rcu/torture.c · 1 unmodified line | ||
| 7106 | 7187 | |
| 7107 | 7188 | RCUTORTURE TEST FRAMEWORK |
| 7108 | 7189 | M: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> |
| 7190 | +L: linux-kernel@vger.kernel.org | |
| 7109 | 7191 | S: Supported |
| 7110 | 7192 | T: git git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git |
| 7111 | 7193 | F: tools/testing/selftests/rcutorture |
| @@ -7129,6 +7211,7 @@ F: net/rds/ · 17 unmodified lines | ||
| 7129 | 7211 | READ-COPY UPDATE (RCU) |
| 7130 | 7212 | M: Dipankar Sarma <dipankar@in.ibm.com> |
| 7131 | 7213 | M: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> |
| 7214 | +L: linux-kernel@vger.kernel.org | |
| 7132 | 7215 | W: http://www.rdrop.com/users/paulmck/RCU/ |
| 7133 | 7216 | S: Supported |
| 7134 | 7217 | T: git git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git |
| @@ -7408,6 +7491,19 @@ L: linux-media@vger.kernel.org · 273 unmodified lines | ||
| 7408 | 7491 | S: Supported |
| 7409 | 7492 | F: drivers/media/i2c/s5c73m3/* |
| 7410 | 7493 | |
| 7494 | +SAMSUNG S5K5BAF CAMERA DRIVER | |
| 7495 | +M: Kyungmin Park <kyungmin.park@samsung.com> | |
| 7496 | +M: Andrzej Hajda <a.hajda@samsung.com> | |
| 7497 | +L: linux-media@vger.kernel.org | |
| 7498 | +S: Supported | |
| 7499 | +F: drivers/media/i2c/s5k5baf.c | |
| 7500 | + | |
| 7501 | +SAMSUNG SOC CLOCK DRIVERS | |
| 7502 | +M: Tomasz Figa <t.figa@samsung.com> | |
| 7503 | +S: Supported | |
| 7504 | +L: linux-samsung-soc@vger.kernel.org (moderated for non-subscribers) | |
| 7505 | +F: drivers/clk/samsung/ | |
| 7506 | + | |
| 7411 | 7507 | SERIAL DRIVERS |
| 7412 | 7508 | M: Greg Kroah-Hartman <gregkh@linuxfoundation.org> |
| 7413 | 7509 | L: linux-serial@vger.kernel.org |
| @@ -7432,6 +7528,7 @@ F: drivers/mmc/host/dw_mmc* · 18 unmodified lines | ||
| 7432 | 7528 | TIMEKEEPING, CLOCKSOURCE CORE, NTP |
| 7433 | 7529 | M: John Stultz <john.stultz@linaro.org> |
| 7434 | 7530 | M: Thomas Gleixner <tglx@linutronix.de> |
| 7531 | +L: linux-kernel@vger.kernel.org | |
| 7435 | 7532 | T: git git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git timers/core |
| 7436 | 7533 | S: Supported |
| 7437 | 7534 | F: include/linux/clocksource.h |
| @@ -7457,6 +7554,7 @@ F: drivers/watchdog/sc1200wdt.c · 19 unmodified lines | ||
| 7457 | 7554 | SCHEDULER |
| 7458 | 7555 | M: Ingo Molnar <mingo@redhat.com> |
| 7459 | 7556 | M: Peter Zijlstra <peterz@infradead.org> |
| 7557 | +L: linux-kernel@vger.kernel.org | |
| 7460 | 7558 | T: git git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git sched/core |
| 7461 | 7559 | S: Maintained |
| 7462 | 7560 | F: kernel/sched/ |
| @@ -7479,7 +7577,7 @@ S: Maintained · 16 unmodified lines | ||
| 7479 | 7577 | F: drivers/scsi/sr* |
| 7480 | 7578 | |
| 7481 | 7579 | SCSI RDMA PROTOCOL (SRP) INITIATOR |
| 7482 | −M: David Dillow <dillowda@ornl.gov> | |
| 7580 | +M: Bart Van Assche <bvanassche@acm.org> | |
| 7483 | 7581 | L: linux-rdma@vger.kernel.org |
| 7484 | 7582 | S: Supported |
| 7485 | 7583 | W: http://www.openfabrics.org |
| @@ -7491,8 +7589,9 @@ F: include/scsi/srp.h · 5 unmodified lines | ||
| 7491 | 7589 | SCSI SG DRIVER |
| 7492 | 7590 | M: Doug Gilbert <dgilbert@interlog.com> |
| 7493 | 7591 | L: linux-scsi@vger.kernel.org |
| 7494 | −W: http://www.torque.net/sg | |
| 7592 | +W: http://sg.danny.cz/sg | |
| 7495 | 7593 | S: Maintained |
| 7594 | +F: Documentation/scsi/scsi-generic.txt | |
| 7496 | 7595 | F: drivers/scsi/sg.c |
| 7497 | 7596 | F: include/scsi/sg.h |
| 7498 | 7597 | |
| @@ -7554,7 +7653,7 @@ S: Maintained · 55 unmodified lines | ||
| 7554 | 7653 | F: drivers/mmc/host/sdricoh_cs.c |
| 7555 | 7654 | |
| 7556 | 7655 | SECURE DIGITAL HOST CONTROLLER INTERFACE (SDHCI) DRIVER |
| 7557 | −M: Chris Ball <cjb@laptop.org> | |
| 7656 | +M: Chris Ball <chris@printf.net> | |
| 7558 | 7657 | L: linux-mmc@vger.kernel.org |
| 7559 | 7658 | T: git git://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc.git |
| 7560 | 7659 | S: Maintained |
| @@ -7647,7 +7746,7 @@ F: drivers/net/ethernet/emulex/benet/ · 86 unmodified lines | ||
| 7647 | 7746 | |
| 7648 | 7747 | SFC NETWORK DRIVER |
| 7649 | 7748 | M: Solarflare linux maintainers <linux-net-drivers@solarflare.com> |
| 7650 | −M: Ben Hutchings <bhutchings@solarflare.com> | |
| 7749 | +M: Shradha Shah <sshah@solarflare.com> | |
| 7651 | 7750 | L: netdev@vger.kernel.org |
| 7652 | 7751 | S: Supported |
| 7653 | 7752 | F: drivers/net/ethernet/sfc/ |
| @@ -7702,7 +7801,7 @@ L: linux-media@vger.kernel.org · 48 unmodified lines | ||
| 7702 | 7801 | T: git git://linuxtv.org/media_tree.git |
| 7703 | 7802 | W: http://linuxtv.org |
| 7704 | 7803 | S: Odd Fixes |
| 7705 | −F: drivers/media/radio/si4713-i2c.? | |
| 7804 | +F: drivers/media/radio/si4713/si4713.? | |
| 7706 | 7805 | |
| 7707 | 7806 | SI4713 FM RADIO TRANSMITTER PLATFORM DRIVER |
| 7708 | 7807 | M: Eduardo Valentin <edubezval@gmail.com> |
| @@ -7710,7 +7809,15 @@ L: linux-media@vger.kernel.org · 1 unmodified line | ||
| 7710 | 7809 | T: git git://linuxtv.org/media_tree.git |
| 7711 | 7810 | W: http://linuxtv.org |
| 7712 | 7811 | S: Odd Fixes |
| 7713 | −F: drivers/media/radio/radio-si4713.c | |
| 7812 | +F: drivers/media/radio/si4713/radio-platform-si4713.c | |
| 7813 | + | |
| 7814 | +SI4713 FM RADIO TRANSMITTER USB DRIVER | |
| 7815 | +M: Hans Verkuil <hverkuil@xs4all.nl> | |
| 7816 | +L: linux-media@vger.kernel.org | |
| 7817 | +T: git git://linuxtv.org/media_tree.git | |
| 7818 | +W: http://linuxtv.org | |
| 7819 | +S: Maintained | |
| 7820 | +F: drivers/media/radio/si4713/radio-usb-si4713.c | |
| 7714 | 7821 | |
| 7715 | 7822 | SIANO DVB DRIVER |
| 7716 | 7823 | M: Mauro Carvalho Chehab <m.chehab@samsung.com> |
| @@ -7823,6 +7930,7 @@ F: mm/sl?b.c · 106 unmodified lines | ||
| 7823 | 7930 | SLEEPABLE READ-COPY UPDATE (SRCU) |
| 7824 | 7931 | M: Lai Jiangshan <laijs@cn.fujitsu.com> |
| 7825 | 7932 | M: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> |
| 7933 | +L: linux-kernel@vger.kernel.org | |
| 7826 | 7934 | W: http://www.rdrop.com/users/paulmck/RCU/ |
| 7827 | 7935 | S: Supported |
| 7828 | 7936 | T: git git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git |
| @@ -7882,7 +7990,7 @@ F: Documentation/hwmon/sch5627 · 53 unmodified lines | ||
| 7882 | 7990 | F: drivers/hwmon/sch5627.c |
| 7883 | 7991 | |
| 7884 | 7992 | SMSC47B397 HARDWARE MONITOR DRIVER |
| 7885 | −M: Jean Delvare <khali@linux-fr.org> | |
| 7993 | +M: Jean Delvare <jdelvare@suse.de> | |
| 7886 | 7994 | L: lm-sensors@lm-sensors.org |
| 7887 | 7995 | S: Maintained |
| 7888 | 7996 | F: Documentation/hwmon/smsc47b397 |
| @@ -8561,6 +8669,14 @@ L: linux-xtensa@linux-xtensa.org · 672 unmodified lines | ||
| 8561 | 8669 | S: Maintained |
| 8562 | 8670 | F: arch/xtensa/ |
| 8563 | 8671 | |
| 8672 | +THANKO'S RAREMONO AM/FM/SW RADIO RECEIVER USB DRIVER | |
| 8673 | +M: Hans Verkuil <hverkuil@xs4all.nl> | |
| 8674 | +L: linux-media@vger.kernel.org | |
| 8675 | +T: git git://linuxtv.org/media_tree.git | |
| 8676 | +W: http://linuxtv.org | |
| 8677 | +S: Maintained | |
| 8678 | +F: drivers/media/radio/radio-raremono.c | |
| 8679 | + | |
| 8564 | 8680 | THERMAL |
| 8565 | 8681 | M: Zhang Rui <rui.zhang@intel.com> |
| 8566 | 8682 | M: Eduardo Valentin <eduardo.valentin@ti.com> |
| @@ -8572,6 +8688,7 @@ S: Supported · 5 unmodified lines | ||
| 8572 | 8688 | F: drivers/thermal/ |
| 8573 | 8689 | F: include/linux/thermal.h |
| 8574 | 8690 | F: include/linux/cpu_cooling.h |
| 8691 | +F: Documentation/devicetree/bindings/thermal/ | |
| 8575 | 8692 | |
| 8576 | 8693 | THINGM BLINK(1) USB RGB LED DRIVER |
| 8577 | 8694 | M: Vivien Didelot <vivien.didelot@savoirfairelinux.com> |
| @@ -8639,12 +8756,11 @@ S: Maintained · 61 unmodified lines | ||
| 8639 | 8756 | F: sound/soc/codecs/twl4030* |
| 8640 | 8757 | |
| 8641 | 8758 | TI WILINK WIRELESS DRIVERS |
| 8642 | −M: Luciano Coelho <luca@coelho.fi> | |
| 8643 | 8759 | L: linux-wireless@vger.kernel.org |
| 8644 | 8760 | W: http://wireless.kernel.org/en/users/Drivers/wl12xx |
| 8645 | 8761 | W: http://wireless.kernel.org/en/users/Drivers/wl1251 |
| 8646 | 8762 | T: git git://git.kernel.org/pub/scm/linux/kernel/git/luca/wl12xx.git |
| 8647 | −S: Maintained | |
| 8763 | +S: Orphan | |
| 8648 | 8764 | F: drivers/net/wireless/ti/ |
| 8649 | 8765 | F: include/linux/wl12xx.h |
| 8650 | 8766 | |
| @@ -8713,7 +8829,6 @@ F: include/linux/toshiba.h · 62 unmodified lines | ||
| 8713 | 8829 | F: include/uapi/linux/toshiba.h |
| 8714 | 8830 | |
| 8715 | 8831 | TMIO MMC DRIVER |
| 8716 | −M: Guennadi Liakhovetski <g.liakhovetski@gmx.de> | |
| 8717 | 8832 | M: Ian Molton <ian@mnementh.co.uk> |
| 8718 | 8833 | L: linux-mmc@vger.kernel.org |
| 8719 | 8834 | S: Maintained |
| @@ -8745,14 +8860,10 @@ S: Odd fixes · 25 unmodified lines | ||
| 8745 | 8860 | F: drivers/media/usb/tm6000/ |
| 8746 | 8861 | |
| 8747 | 8862 | TPM DEVICE DRIVER |
| 8748 | −M: Leonidas Da Silva Barbosa <leosilva@linux.vnet.ibm.com> | |
| 8749 | −M: Ashley Lai <ashley@ashleylai.com> | |
| 8750 | 8863 | M: Peter Huewe <peterhuewe@gmx.de> |
| 8751 | −M: Rajiv Andrade <mail@srajiv.net> | |
| 8752 | −W: http://tpmdd.sourceforge.net | |
| 8864 | +M: Ashley Lai <ashley@ashleylai.com> | |
| 8753 | 8865 | M: Marcel Selhorst <tpmdd@selhorst.net> |
| 8754 | −M: Sirrix AG <tpmdd@sirrix.com> | |
| 8755 | −W: http://www.sirrix.com | |
| 8866 | +W: http://tpmdd.sourceforge.net | |
| 8756 | 8867 | L: tpmdd-devel@lists.sourceforge.net (moderated for non-subscribers) |
| 8757 | 8868 | S: Maintained |
| 8758 | 8869 | F: drivers/char/tpm/ |
| @@ -8904,7 +9015,7 @@ UNSORTED BLOCK IMAGES (UBI) · 145 unmodified lines | ||
| 8904 | 9015 | M: Artem Bityutskiy <dedekind1@gmail.com> |
| 8905 | 9016 | W: http://www.linux-mtd.infradead.org/ |
| 8906 | 9017 | L: linux-mtd@lists.infradead.org |
| 8907 | −T: git git://git.infradead.org/ubi-2.6.git | |
| 9018 | +T: git git://git.infradead.org/ubifs-2.6.git | |
| 8908 | 9019 | S: Maintained |
| 8909 | 9020 | F: drivers/mtd/ubi/ |
| 8910 | 9021 | F: include/linux/mtd/ubi.h |
| @@ -9098,8 +9209,7 @@ L: linux-media@vger.kernel.org · 187 unmodified lines | ||
| 9098 | 9209 | T: git git://linuxtv.org/media_tree.git |
| 9099 | 9210 | W: http://www.linux-projects.org |
| 9100 | 9211 | S: Maintained |
| 9101 | −F: Documentation/video4linux/sn9c102.txt | |
| 9102 | −F: drivers/media/usb/sn9c102/ | |
| 9212 | +F: drivers/staging/media/sn9c102/ | |
| 9103 | 9213 | |
| 9104 | 9214 | USB SUBSYSTEM |
| 9105 | 9215 | M: Greg Kroah-Hartman <gregkh@linuxfoundation.org> |
| @@ -9405,7 +9515,7 @@ F: Documentation/hwmon/w83793 · 299 unmodified lines | ||
| 9405 | 9515 | F: drivers/hwmon/w83793.c |
| 9406 | 9516 | |
| 9407 | 9517 | W83795 HARDWARE MONITORING DRIVER |
| 9408 | −M: Jean Delvare <khali@linux-fr.org> | |
| 9518 | +M: Jean Delvare <jdelvare@suse.de> | |
| 9409 | 9519 | L: lm-sensors@lm-sensors.org |
| 9410 | 9520 | S: Maintained |
| 9411 | 9521 | F: drivers/hwmon/w83795.c |
| @@ -9531,6 +9641,7 @@ M: Thomas Gleixner <tglx@linutronix.de> · 119 unmodified lines | ||
| 9531 | 9641 | M: Ingo Molnar <mingo@redhat.com> |
| 9532 | 9642 | M: "H. Peter Anvin" <hpa@zytor.com> |
| 9533 | 9643 | M: x86@kernel.org |
| 9644 | +L: linux-kernel@vger.kernel.org | |
| 9534 | 9645 | T: git git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/core |
| 9535 | 9646 | S: Maintained |
| 9536 | 9647 | F: Documentation/x86/ |
| @@ -9563,6 +9674,7 @@ M: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> · 26 unmodified lines | ||
| 9563 | 9674 | M: Boris Ostrovsky <boris.ostrovsky@oracle.com> |
| 9564 | 9675 | M: David Vrabel <david.vrabel@citrix.com> |
| 9565 | 9676 | L: xen-devel@lists.xenproject.org (moderated for non-subscribers) |
| 9677 | +T: git git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git | |
| 9566 | 9678 | S: Supported |
| 9567 | 9679 | F: arch/x86/xen/ |
| 9568 | 9680 | F: drivers/*/xen-*front.c |
| @@ -9683,11 +9795,27 @@ T: Mercurial http://linuxtv.org/hg/v4l-dvb · 114 unmodified lines | ||
| 9683 | 9795 | S: Odd Fixes |
| 9684 | 9796 | F: drivers/media/pci/zoran/ |
| 9685 | 9797 | |
| 9798 | +ZRAM COMPRESSED RAM BLOCK DEVICE DRVIER | |
| 9799 | +M: Minchan Kim <minchan@kernel.org> | |
| 9800 | +M: Nitin Gupta <ngupta@vflare.org> | |
| 9801 | +L: linux-kernel@vger.kernel.org | |
| 9802 | +S: Maintained | |
| 9803 | +F: drivers/block/zram/ | |
| 9804 | +F: Documentation/blockdev/zram.txt | |
| 9805 | + | |
| 9686 | 9806 | ZS DECSTATION Z85C30 SERIAL DRIVER |
| 9687 | 9807 | M: "Maciej W. Rozycki" <macro@linux-mips.org> |
| 9688 | 9808 | S: Maintained |
| 9689 | 9809 | F: drivers/tty/serial/zs.* |
| 9690 | 9810 | |
| 9811 | +ZSMALLOC COMPRESSED SLAB MEMORY ALLOCATOR | |
| 9812 | +M: Minchan Kim <minchan@kernel.org> | |
| 9813 | +M: Nitin Gupta <ngupta@vflare.org> | |
| 9814 | +L: linux-mm@kvack.org | |
| 9815 | +S: Maintained | |
| 9816 | +F: mm/zsmalloc.c | |
| 9817 | +F: include/linux/zsmalloc.h | |
| 9818 | + | |
| 9691 | 9819 | ZSWAP COMPRESSED SWAP CACHING |
| 9692 | 9820 | M: Seth Jennings <sjenning@linux.vnet.ibm.com> |
| 9693 | 9821 | L: linux-mm@kvack.org |
| @@ -311,9 +311,15 @@ endif · 310 unmodified lines | ||
| 311 | 311 | # If the user is running make -s (silent mode), suppress echoing of |
| 312 | 312 | # commands |
| 313 | 313 | |
| 314 | +ifneq ($(filter 4.%,$(MAKE_VERSION)),) # make-4 | |
| 315 | +ifneq ($(filter %s ,$(firstword x$(MAKEFLAGS))),) | |
| 316 | + quiet=silent_ | |
| 317 | +endif | |
| 318 | +else # make-3.8x | |
| 314 | 319 | ifneq ($(filter s% -s%,$(MAKEFLAGS)),) |
| 315 | 320 | quiet=silent_ |
| 316 | 321 | endif |
| 322 | +endif | |
| 317 | 323 | |
| 318 | 324 | export quiet Q KBUILD_VERBOSE |
| 319 | 325 | |
| @@ -633,7 +639,7 @@ endif · 313 unmodified lines | ||
| 633 | 639 | |
| 634 | 640 | ifdef CONFIG_DEBUG_INFO |
| 635 | 641 | KBUILD_CFLAGS += -g |
| 636 | −KBUILD_AFLAGS += -gdwarf-2 | |
| 642 | +KBUILD_AFLAGS += -Wa,--gdwarf-2 | |
| 637 | 643 | endif |
| 638 | 644 | |
| 639 | 645 | ifdef CONFIG_DEBUG_INFO_REDUCED |
| @@ -682,6 +688,9 @@ KBUILD_CFLAGS += $(call cc-option,-Werror=implicit-int) · 42 unmodified lines | ||
| 682 | 688 | # require functions to have arguments in prototypes, not empty 'int foo()' |
| 683 | 689 | KBUILD_CFLAGS += $(call cc-option,-Werror=strict-prototypes) |
| 684 | 690 | |
| 691 | +# Prohibit date/time macros, which would make the build non-deterministic | |
| 692 | +KBUILD_CFLAGS += $(call cc-option,-Werror=date-time) | |
| 693 | + | |
| 685 | 694 | # use the deterministic mode of AR if available |
| 686 | 695 | KBUILD_ARFLAGS := $(call ar-option,D) |
| 687 | 696 | |
| @@ -2,6 +2,7 @@ config ALPHA · 1 unmodified line | ||
| 2 | 2 | bool |
| 3 | 3 | default y |
| 4 | 4 | select ARCH_MIGHT_HAVE_PC_PARPORT |
| 5 | + select ARCH_MIGHT_HAVE_PC_SERIO | |
| 5 | 6 | select HAVE_AOUT |
| 6 | 7 | select HAVE_IDE |
| 7 | 8 | select HAVE_OPROFILE |
| @@ -16,6 +17,7 @@ config ALPHA · 8 unmodified lines | ||
| 16 | 17 | select ARCH_WANT_IPC_PARSE_VERSION |
| 17 | 18 | select ARCH_HAVE_NMI_SAFE_CMPXCHG |
| 18 | 19 | select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE |
| 20 | + select AUDIT_ARCH | |
| 19 | 21 | select GENERIC_CLOCKEVENTS |
| 20 | 22 | select GENERIC_SMP_IDLE_THREAD |
| 21 | 23 | select GENERIC_STRNCPY_FROM_USER |
| @@ -76,6 +78,8 @@ config GENERIC_ISA_DMA · 54 unmodified lines | ||
| 76 | 78 | source "init/Kconfig" |
| 77 | 79 | source "kernel/Kconfig.freezer" |
| 78 | 80 | |
| 81 | +config AUDIT_ARCH | |
| 82 | + bool | |
| 79 | 83 | |
| 80 | 84 | menu "System setup" |
| 81 | 85 | |
| @@ -539,13 +543,13 @@ config SMP · 457 unmodified lines | ||
| 539 | 543 | depends on ALPHA_SABLE || ALPHA_LYNX || ALPHA_RAWHIDE || ALPHA_DP264 || ALPHA_WILDFIRE || ALPHA_TITAN || ALPHA_GENERIC || ALPHA_SHARK || ALPHA_MARVEL |
| 540 | 544 | ---help--- |
| 541 | 545 | This enables support for systems with more than one CPU. If you have |
| 542 | − a system with only one CPU, like most personal computers, say N. If | |
| 543 | − you have a system with more than one CPU, say Y. | |
| 546 | + a system with only one CPU, say N. If you have a system with more | |
| 547 | + than one CPU, say Y. | |
| 544 | 548 | |
| 545 | − If you say N here, the kernel will run on single and multiprocessor | |
| 549 | + If you say N here, the kernel will run on uni- and multiprocessor | |
| 546 | 550 | machines, but will use only one CPU of a multiprocessor machine. If |
| 547 | 551 | you say Y here, the kernel will run on many, but not all, |
| 548 | − singleprocessor machines. On a singleprocessor machine, the kernel | |
| 552 | + uniprocessor machines. On a uniprocessor machine, the kernel | |
| 549 | 553 | will run faster if you say N here. |
| 550 | 554 | |
| 551 | 555 | See also the SMP-HOWTO available at |
| @@ -4,3 +4,4 @@ generic-y += clkdev.h · 3 unmodified lines | ||
| 4 | 4 | generic-y += exec.h |
| 5 | 5 | generic-y += trace_clock.h |
| 6 | 6 | generic-y += preempt.h |
| 7 | +generic-y += hash.h | |
| @@ -19,4 +19,9 @@ · 18 unmodified lines | ||
| 19 | 19 | |
| 20 | 20 | #define force_successful_syscall_return() (current_pt_regs()->r0 = 0) |
| 21 | 21 | |
| 22 | +static inline unsigned long regs_return_value(struct pt_regs *regs) | |
| 23 | +{ | |
| 24 | + return regs->r0; | |
| 25 | +} | |
| 26 | + | |
| 22 | 27 | #endif |
| @@ -70,6 +70,7 @@ register struct thread_info *__current_thread_info __asm__("$8"); · 69 unmodified lines | ||
| 70 | 70 | #define TIF_NOTIFY_RESUME 1 /* callback before returning to user */ |
| 71 | 71 | #define TIF_SIGPENDING 2 /* signal pending */ |
| 72 | 72 | #define TIF_NEED_RESCHED 3 /* rescheduling necessary */ |
| 73 | +#define TIF_SYSCALL_AUDIT 4 /* syscall audit active */ | |
| 73 | 74 | #define TIF_DIE_IF_KERNEL 9 /* dik recursion lock */ |
| 74 | 75 | #define TIF_MEMDIE 13 /* is terminating due to OOM killer */ |
| 75 | 76 | |
| @@ -77,6 +78,7 @@ register struct thread_info *__current_thread_info __asm__("$8"); · 1 unmodified line | ||
| 77 | 78 | #define _TIF_SIGPENDING (1<<TIF_SIGPENDING) |
| 78 | 79 | #define _TIF_NEED_RESCHED (1<<TIF_NEED_RESCHED) |
| 79 | 80 | #define _TIF_NOTIFY_RESUME (1<<TIF_NOTIFY_RESUME) |
| 81 | +#define _TIF_SYSCALL_AUDIT (1<<TIF_SYSCALL_AUDIT) | |
| 80 | 82 | |
| 81 | 83 | /* Work to do on interrupt/exception return. */ |
| 82 | 84 | #define _TIF_WORK_MASK (_TIF_SIGPENDING | _TIF_NEED_RESCHED | \ |
| @@ -85,4 +85,6 @@ · 84 unmodified lines | ||
| 85 | 85 | |
| 86 | 86 | #define SO_MAX_PACING_RATE 47 |
| 87 | 87 | |
| 88 | +#define SO_BPF_EXTENSIONS 48 | |
| 89 | + | |
| 88 | 90 | #endif /* _UAPI_ASM_SOCKET_H */ |
| @@ -17,6 +17,7 @@ obj-$(CONFIG_SRM_ENV) += srm_env.o · 16 unmodified lines | ||
| 17 | 17 | obj-$(CONFIG_MODULES) += module.o |
| 18 | 18 | obj-$(CONFIG_PERF_EVENTS) += perf_event.o |
| 19 | 19 | obj-$(CONFIG_RTC_DRV_ALPHA) += rtc.o |
| 20 | +obj-$(CONFIG_AUDIT) += audit.o | |
| 20 | 21 | |
| 21 | 22 | ifdef CONFIG_ALPHA_GENERIC |
| 22 | 23 | |
| @@ -0,0 +1,60 @@ | ||
| 1 | +#include <linux/init.h> | |
| 2 | +#include <linux/types.h> | |
| 3 | +#include <linux/audit.h> | |
| 4 | +#include <asm/unistd.h> | |
| 5 | + | |
| 6 | +static unsigned dir_class[] = { | |
| 7 | +#include <asm-generic/audit_dir_write.h> | |
| 8 | +~0U | |
| 9 | +}; | |
| 10 | + | |
| 11 | +static unsigned read_class[] = { | |
| 12 | +#include <asm-generic/audit_read.h> | |
| 13 | +~0U | |
| 14 | +}; | |
| 15 | + | |
| 16 | +static unsigned write_class[] = { | |
| 17 | +#include <asm-generic/audit_write.h> | |
| 18 | +~0U | |
| 19 | +}; | |
| 20 | + | |
| 21 | +static unsigned chattr_class[] = { | |
| 22 | +#include <asm-generic/audit_change_attr.h> | |
| 23 | +~0U | |
| 24 | +}; | |
| 25 | + | |
| 26 | +static unsigned signal_class[] = { | |
| 27 | +#include <asm-generic/audit_signal.h> | |
| 28 | +~0U | |
| 29 | +}; | |
| 30 | + | |
| 31 | +int audit_classify_arch(int arch) | |
| 32 | +{ | |
| 33 | + return 0; | |
| 34 | +} | |
| 35 | + | |
| 36 | +int audit_classify_syscall(int abi, unsigned syscall) | |
| 37 | +{ | |
| 38 | + switch(syscall) { | |
| 39 | + case __NR_open: | |
| 40 | + return 2; | |
| 41 | + case __NR_openat: | |
| 42 | + return 3; | |
| 43 | + case __NR_execve: | |
| 44 | + return 5; | |
| 45 | + default: | |
| 46 | + return 0; | |
| 47 | + } | |
| 48 | +} | |
| 49 | + | |
| 50 | +static int __init audit_classes_init(void) | |
| 51 | +{ | |
| 52 | + audit_register_class(AUDIT_CLASS_WRITE, write_class); | |
| 53 | + audit_register_class(AUDIT_CLASS_READ, read_class); | |
| 54 | + audit_register_class(AUDIT_CLASS_DIR_WRITE, dir_class); | |
| 55 | + audit_register_class(AUDIT_CLASS_CHATTR, chattr_class); | |
| 56 | + audit_register_class(AUDIT_CLASS_SIGNAL, signal_class); | |
| 57 | + return 0; | |
| 58 | +} | |
| 59 | + | |
| 60 | +__initcall(audit_classes_init); | |
| @@ -465,7 +465,11 @@ entSys: · 464 unmodified lines | ||
| 465 | 465 | .cfi_rel_offset $16, SP_OFF+24 |
| 466 | 466 | .cfi_rel_offset $17, SP_OFF+32 |
| 467 | 467 | .cfi_rel_offset $18, SP_OFF+40 |
| 468 | − blbs $3, strace | |
| 468 | +#ifdef CONFIG_AUDITSYSCALL | |
| 469 | + lda $6, _TIF_SYSCALL_TRACE | _TIF_SYSCALL_AUDIT | |
| 470 | + and $3, $6, $3 | |
| 471 | +#endif | |
| 472 | + bne $3, strace | |
| 469 | 473 | beq $4, 1f |
| 470 | 474 | ldq $27, 0($5) |
| 471 | 475 | 1: jsr $26, ($27), alpha_ni_syscall |
| @@ -83,7 +83,7 @@ static int pci_mmap_resource(struct kobject *kobj, · 82 unmodified lines | ||
| 83 | 83 | if (iomem_is_exclusive(res->start)) |
| 84 | 84 | return -EINVAL; |
| 85 | 85 | |
| 86 | − pcibios_resource_to_bus(pdev, &bar, res); | |
| 86 | + pcibios_resource_to_bus(pdev->bus, &bar, res); | |
| 87 | 87 | vma->vm_pgoff += bar.start >> (PAGE_SHIFT - (sparse ? 5 : 0)); |
| 88 | 88 | mmap_type = res->flags & IORESOURCE_MEM ? pci_mmap_mem : pci_mmap_io; |
| 89 | 89 | |
| @@ -139,7 +139,7 @@ static int sparse_mem_mmap_fits(struct pci_dev *pdev, int num) · 49 unmodified lines | ||
| 139 | 139 | long dense_offset; |
| 140 | 140 | unsigned long sparse_size; |
| 141 | 141 | |
| 142 | − pcibios_resource_to_bus(pdev, &bar, &pdev->resource[num]); | |
| 142 | + pcibios_resource_to_bus(pdev->bus, &bar, &pdev->resource[num]); | |
| 143 | 143 | |
| 144 | 144 | /* All core logic chips have 4G sparse address space, except |
| 145 | 145 | CIA which has 16G (see xxx_SPARSE_MEM and xxx_DENSE_MEM |
| @@ -325,7 +325,7 @@ pci_map_single_1(struct pci_dev *pdev, void *cpu_addr, size_t size, · 324 unmodified lines | ||
| 325 | 325 | /* Helper for generic DMA-mapping functions. */ |
| 326 | 326 | static struct pci_dev *alpha_gendev_to_pci(struct device *dev) |
| 327 | 327 | { |
| 328 | − if (dev && dev->bus == &pci_bus_type) | |
| 328 | + if (dev && dev_is_pci(dev)) | |
| 329 | 329 | return to_pci_dev(dev); |
| 330 | 330 | |
| 331 | 331 | /* Assume that non-PCI devices asking for DMA are either ISA or EISA, |
| @@ -14,6 +14,7 @@ · 13 unmodified lines | ||
| 14 | 14 | #include <linux/security.h> |
| 15 | 15 | #include <linux/signal.h> |
| 16 | 16 | #include <linux/tracehook.h> |
| 17 | +#include <linux/audit.h> | |
| 17 | 18 | |
| 18 | 19 | #include <asm/uaccess.h> |
| 19 | 20 | #include <asm/pgtable.h> |
| @@ -316,15 +317,18 @@ long arch_ptrace(struct task_struct *child, long request, · 296 unmodified lines | ||
| 316 | 317 | asmlinkage unsigned long syscall_trace_enter(void) |
| 317 | 318 | { |
| 318 | 319 | unsigned long ret = 0; |
| 320 | + struct pt_regs *regs = current_pt_regs(); | |
| 319 | 321 | if (test_thread_flag(TIF_SYSCALL_TRACE) && |
| 320 | 322 | tracehook_report_syscall_entry(current_pt_regs())) |
| 321 | 323 | ret = -1UL; |
| 324 | + audit_syscall_entry(AUDIT_ARCH_ALPHA, regs->r0, regs->r16, regs->r17, regs->r18, regs->r19); | |
| 322 | 325 | return ret ?: current_pt_regs()->r0; |
| 323 | 326 | } |
| 324 | 327 | |
| 325 | 328 | asmlinkage void |
| 326 | 329 | syscall_trace_leave(void) |
| 327 | 330 | { |
| 331 | + audit_syscall_exit(current_pt_regs()); | |
| 328 | 332 | if (test_thread_flag(TIF_SYSCALL_TRACE)) |
| 329 | 333 | tracehook_report_syscall_exit(current_pt_regs(), 0); |
| 330 | 334 | } |
| @@ -378,6 +378,11 @@ csum_partial_copy_from_user(const void __user *src, void *dst, int len, · 377 unmodified lines | ||
| 378 | 378 | __wsum |
| 379 | 379 | csum_partial_copy_nocheck(const void *src, void *dst, int len, __wsum sum) |
| 380 | 380 | { |
| 381 | − return csum_partial_copy_from_user((__force const void __user *)src, | |
| 382 | − dst, len, sum, NULL); | |
| 381 | + __wsum checksum; | |
| 382 | + mm_segment_t oldfs = get_fs(); | |
| 383 | + set_fs(KERNEL_DS); | |
| 384 | + checksum = csum_partial_copy_from_user((__force const void __user *)src, | |
| 385 | + dst, len, sum, NULL); | |
| 386 | + set_fs(oldfs); | |
| 387 | + return checksum; | |
| 383 | 388 | } |
| @@ -128,8 +128,8 @@ config SMP · 127 unmodified lines | ||
| 128 | 128 | default n |
| 129 | 129 | help |
| 130 | 130 | This enables support for systems with more than one CPU. If you have |
| 131 | − a system with only one CPU, like most personal computers, say N. If | |
| 132 | − you have a system with more than one CPU, say Y. | |
| 131 | + a system with only one CPU, say N. If you have a system with more | |
| 132 | + than one CPU, say Y. | |
| 133 | 133 | |
| 134 | 134 | if SMP |
| 135 | 135 | |
| @@ -409,17 +409,6 @@ config ARC_DBG_TLB_MISS_COUNT · 273 unmodified lines | ||
| 409 | 409 | Counts number of I and D TLB Misses and exports them via Debugfs |
| 410 | 410 | The counters can be cleared via Debugfs as well |
| 411 | 411 | |
| 412 | −config CMDLINE_UBOOT | |
| 413 | − bool "Support U-boot kernel command line passing" | |
| 414 | − default n | |
| 415 | − help | |
| 416 | − If you are using U-boot (www.denx.de) and wish to pass the kernel | |
| 417 | − command line from the U-boot environment to the Linux kernel then | |
| 418 | − switch this option on. | |
| 419 | − ARC U-boot will setup the cmdline in RAM/flash and set r2 to point | |
| 420 | − to it. kernel startup code will append this to DeviceTree | |
| 421 | − /bootargs provided cmdline args. | |
| 422 | − | |
| 423 | 412 | config ARC_BUILTIN_DTB_NAME |
| 424 | 413 | string "Built in DTB" |
| 425 | 414 | help |
| @@ -12,6 +12,7 @@ generic-y += fcntl.h · 11 unmodified lines | ||
| 12 | 12 | generic-y += fb.h |
| 13 | 13 | generic-y += ftrace.h |
| 14 | 14 | generic-y += hardirq.h |
| 15 | +generic-y += hash.h | |
| 15 | 16 | generic-y += hw_irq.h |
| 16 | 17 | generic-y += ioctl.h |
| 17 | 18 | generic-y += ioctls.h |
| @@ -11,6 +11,8 @@ · 10 unmodified lines | ||
| 11 | 11 | |
| 12 | 12 | #ifdef __ASSEMBLY__ |
| 13 | 13 | |
| 14 | +#define ASM_NL ` /* use '`' to mark new line in macro */ | |
| 15 | + | |
| 14 | 16 | /* Can't use the ENTRY macro in linux/linkage.h |
| 15 | 17 | * gas considers ';' as comment vs. newline |
| 16 | 18 | */ |
| @@ -46,14 +46,14 @@ extern int smp_ipi_irq_setup(int cpu, int irq); · 45 unmodified lines | ||
| 46 | 46 | * |
| 47 | 47 | * @info: SoC SMP specific info for /proc/cpuinfo etc |
| 48 | 48 | * @cpu_kick: For Master to kickstart a cpu (optionally at a PC) |
| 49 | − * @ipi_send: To send IPI to a @cpumask | |
| 50 | − * @ips_clear: To clear IPI received by @cpu at @irq | |
| 49 | + * @ipi_send: To send IPI to a @cpu | |
| 50 | + * @ips_clear: To clear IPI received at @irq | |
| 51 | 51 | */ |
| 52 | 52 | struct plat_smp_ops { |
| 53 | 53 | const char *info; |
| 54 | 54 | void (*cpu_kick)(int cpu, unsigned long pc); |
| 55 | − void (*ipi_send)(void *callmap); | |
| 56 | − void (*ipi_clear)(int cpu, int irq); | |
| 55 | + void (*ipi_send)(int cpu); | |
| 56 | + void (*ipi_clear)(int irq); | |
| 57 | 57 | }; |
| 58 | 58 | |
| 59 | 59 | /* TBD: stop exporting it for direct population by platform */ |
| @@ -49,25 +49,13 @@ stext: · 48 unmodified lines | ||
| 49 | 49 | st.ab 0, [r5,4] |
| 50 | 50 | brlt r5, r6, 1b |
| 51 | 51 | |
| 52 | −#ifdef CONFIG_CMDLINE_UBOOT | |
| 53 | − ; support for bootloader provided cmdline | |
| 54 | − ; If cmdline passed by u-boot, then | |
| 55 | − ; r0 = 1 (because ATAGS parsing, now retired, used to use 0) | |
| 56 | − ; r1 = magic number (board identity) | |
| 57 | − ; r2 = addr of cmdline string (somewhere in memory/flash) | |
| 58 | − | |
| 59 | − brne r0, 1, .Lother_bootup_chores ; u-boot didn't pass cmdline | |
| 60 | − breq r2, 0, .Lother_bootup_chores ; or cmdline is NULL | |
| 61 | − | |
| 62 | − mov r5, @command_line | |
| 63 | −1: | |
| 64 | − ldb.ab r6, [r2, 1] | |
| 65 | − breq r6, 0, .Lother_bootup_chores | |
| 66 | − b.d 1b | |
| 67 | − stb.ab r6, [r5, 1] | |
| 68 | −#endif | |
| 69 | − | |
| 70 | −.Lother_bootup_chores: | |
| 52 | + ; Uboot - kernel ABI | |
| 53 | + ; r0 = [0] No uboot interaction, [1] cmdline in r2, [2] DTB in r2 | |
| 54 | + ; r1 = magic number (board identity, unused as of now | |
| 55 | + ; r2 = pointer to uboot provided cmdline or external DTB in mem | |
| 56 | + ; These are handled later in setup_arch() | |
| 57 | + st r0, [@uboot_tag] | |
| 58 | + st r2, [@uboot_arg] | |
| 71 | 59 | |
| 72 | 60 | ; Identify if running on ISS vs Silicon |
| 73 | 61 | ; IDENTITY Reg [ 3 2 1 0 ] |
| @@ -29,7 +29,10 @@ · 28 unmodified lines | ||
| 29 | 29 | |
| 30 | 30 | int running_on_hw = 1; /* vs. on ISS */ |
| 31 | 31 | |
| 32 | −char __initdata command_line[COMMAND_LINE_SIZE]; | |
| 32 | +/* Part of U-boot ABI: see head.S */ | |
| 33 | +int __initdata uboot_tag; | |
| 34 | +char __initdata *uboot_arg; | |
| 35 | + | |
| 33 | 36 | const struct machine_desc *machine_desc; |
| 34 | 37 | |
| 35 | 38 | struct task_struct *_current_task[NR_CPUS]; /* For stack switching */ |
| @@ -311,19 +314,40 @@ void setup_processor(void) · 275 unmodified lines | ||
| 311 | 314 | arc_chk_fpu(); |
| 312 | 315 | } |
| 313 | 316 | |
| 317 | +static inline int is_kernel(unsigned long addr) | |
| 318 | +{ | |
| 319 | + if (addr >= (unsigned long)_stext && addr <= (unsigned long)_end) | |
| 320 | + return 1; | |
| 321 | + return 0; | |
| 322 | +} | |
| 323 | + | |
| 314 | 324 | void __init setup_arch(char **cmdline_p) |
| 315 | 325 | { |
| 316 | − /* This also populates @boot_command_line from /bootargs */ | |
| 317 | − machine_desc = setup_machine_fdt(__dtb_start); | |
| 318 | − if (!machine_desc) | |
| 319 | − panic("Embedded DT invalid\n"); | |
| 320 | − | |
| 321 | − /* Append any u-boot provided cmdline */ | |
| 322 | −#ifdef CONFIG_CMDLINE_UBOOT | |
| 323 | − /* Add a whitespace seperator between the 2 cmdlines */ | |
| 324 | − strlcat(boot_command_line, " ", COMMAND_LINE_SIZE); | |
| 325 | − strlcat(boot_command_line, command_line, COMMAND_LINE_SIZE); | |
| 326 | −#endif | |
| 326 | + /* make sure that uboot passed pointer to cmdline/dtb is valid */ | |
| 327 | + if (uboot_tag && is_kernel((unsigned long)uboot_arg)) | |
| 328 | + panic("Invalid uboot arg\n"); | |
| 329 | + | |
| 330 | + /* See if u-boot passed an external Device Tree blob */ | |
| 331 | + machine_desc = setup_machine_fdt(uboot_arg); /* uboot_tag == 2 */ | |
| 332 | + if (!machine_desc) { | |
| 333 | + /* No, so try the embedded one */ | |
| 334 | + machine_desc = setup_machine_fdt(__dtb_start); | |
| 335 | + if (!machine_desc) | |
| 336 | + panic("Embedded DT invalid\n"); | |
| 337 | + | |
| 338 | + /* | |
| 339 | + * If we are here, it is established that @uboot_arg didn't | |
| 340 | + * point to DT blob. Instead if u-boot says it is cmdline, | |
| 341 | + * Appent to embedded DT cmdline. | |
| 342 | + * setup_machine_fdt() would have populated @boot_command_line | |
| 343 | + */ | |
| 344 | + if (uboot_tag == 1) { | |
| 345 | + /* Ensure a whitespace between the 2 cmdlines */ | |
| 346 | + strlcat(boot_command_line, " ", COMMAND_LINE_SIZE); | |
| 347 | + strlcat(boot_command_line, uboot_arg, | |
| 348 | + COMMAND_LINE_SIZE); | |
| 349 | + } | |
| 350 | + } | |
| 327 | 351 | |
| 328 | 352 | /* Save unparsed command line copy for /proc/cmdline */ |
| 329 | 353 | *cmdline_p = boot_command_line; |
| @@ -197,51 +197,65 @@ int __init setup_profiling_timer(unsigned int multiplier) · 196 unmodified lines | ||
| 197 | 197 | /* Inter Processor Interrupt Handling */ |
| 198 | 198 | /*****************************************************************************/ |
| 199 | 199 | |
| 200 | −/* | |
| 201 | − * structures for inter-processor calls | |
| 202 | − * A Collection of single bit ipi messages | |
| 203 | − * | |
| 204 | − */ | |
| 205 | − | |
| 206 | −/* | |
| 207 | − * TODO_rajesh investigate tlb message types. | |
| 208 | − * IPI Timer not needed because each ARC has an individual Interrupting Timer | |
| 209 | − */ | |
| 210 | 200 | enum ipi_msg_type { |
| 211 | − IPI_NOP = 0, | |
| 201 | + IPI_EMPTY = 0, | |
| 212 | 202 | IPI_RESCHEDULE = 1, |
| 213 | 203 | IPI_CALL_FUNC, |
| 214 | − IPI_CPU_STOP | |
| 204 | + IPI_CPU_STOP, | |
| 215 | 205 | }; |
| 216 | 206 | |
| 217 | −struct ipi_data { | |
| 218 | − unsigned long bits; | |
| 219 | −}; | |
| 207 | +/* | |
| 208 | + * In arches with IRQ for each msg type (above), receiver can use IRQ-id to | |
| 209 | + * figure out what msg was sent. For those which don't (ARC has dedicated IPI | |
| 210 | + * IRQ), the msg-type needs to be conveyed via per-cpu data | |
| 211 | + */ | |
| 220 | 212 | |
| 221 | −static DEFINE_PER_CPU(struct ipi_data, ipi_data); | |
| 213 | +static DEFINE_PER_CPU(unsigned long, ipi_data); | |
| 222 | 214 | |
| 223 | −static void ipi_send_msg(const struct cpumask *callmap, enum ipi_msg_type msg) | |
| 215 | +static void ipi_send_msg_one(int cpu, enum ipi_msg_type msg) | |
| 224 | 216 | { |
| 217 | + unsigned long __percpu *ipi_data_ptr = per_cpu_ptr(&ipi_data, cpu); | |
| 218 | + unsigned long old, new; | |
| 225 | 219 | unsigned long flags; |
| 226 | − unsigned int cpu; | |
| 220 | + | |
| 221 | + pr_debug("%d Sending msg [%d] to %d\n", smp_processor_id(), msg, cpu); | |
| 227 | 222 | |
| 228 | 223 | local_irq_save(flags); |
| 229 | 224 | |
| 230 | − for_each_cpu(cpu, callmap) { | |
| 231 | − struct ipi_data *ipi = &per_cpu(ipi_data, cpu); | |
| 232 | − set_bit(msg, &ipi->bits); | |
| 233 | − } | |
| 225 | + /* | |
| 226 | + * Atomically write new msg bit (in case others are writing too), | |
| 227 | + * and read back old value | |
| 228 | + */ | |
| 229 | + do { | |
| 230 | + new = old = *ipi_data_ptr; | |
| 231 | + new |= 1U << msg; | |
| 232 | + } while (cmpxchg(ipi_data_ptr, old, new) != old); | |
| 234 | 233 | |
| 235 | − /* Call the platform specific cross-CPU call function */ | |
| 236 | − if (plat_smp_ops.ipi_send) | |
| 237 | − plat_smp_ops.ipi_send((void *)callmap); | |
| 234 | + /* | |
| 235 | + * Call the platform specific IPI kick function, but avoid if possible: | |
| 236 | + * Only do so if there's no pending msg from other concurrent sender(s). | |
| 237 | + * Otherwise, recevier will see this msg as well when it takes the | |
| 238 | + * IPI corresponding to that msg. This is true, even if it is already in | |
| 239 | + * IPI handler, because !@old means it has not yet dequeued the msg(s) | |
| 240 | + * so @new msg can be a free-loader | |
| 241 | + */ | |
| 242 | + if (plat_smp_ops.ipi_send && !old) | |
| 243 | + plat_smp_ops.ipi_send(cpu); | |
| 238 | 244 | |
| 239 | 245 | local_irq_restore(flags); |
| 240 | 246 | } |
| 241 | 247 | |
| 248 | +static void ipi_send_msg(const struct cpumask *callmap, enum ipi_msg_type msg) | |
| 249 | +{ | |
| 250 | + unsigned int cpu; | |
| 251 | + | |
| 252 | + for_each_cpu(cpu, callmap) | |
| 253 | + ipi_send_msg_one(cpu, msg); | |
| 254 | +} | |
| 255 | + | |
| 242 | 256 | void smp_send_reschedule(int cpu) |
| 243 | 257 | { |
| 244 | − ipi_send_msg(cpumask_of(cpu), IPI_RESCHEDULE); | |
| 258 | + ipi_send_msg_one(cpu, IPI_RESCHEDULE); | |
| 245 | 259 | } |
| 246 | 260 | |
| 247 | 261 | void smp_send_stop(void) |
| @@ -254,7 +268,7 @@ void smp_send_stop(void) · 6 unmodified lines | ||
| 254 | 268 | |
| 255 | 269 | void arch_send_call_function_single_ipi(int cpu) |
| 256 | 270 | { |
| 257 | − ipi_send_msg(cpumask_of(cpu), IPI_CALL_FUNC); | |
| 271 | + ipi_send_msg_one(cpu, IPI_CALL_FUNC); | |
| 258 | 272 | } |
| 259 | 273 | |
| 260 | 274 | void arch_send_call_function_ipi_mask(const struct cpumask *mask) |
| @@ -265,33 +279,29 @@ void arch_send_call_function_ipi_mask(const struct cpumask *mask) · 4 unmodified lines | ||
| 265 | 279 | /* |
| 266 | 280 | * ipi_cpu_stop - handle IPI from smp_send_stop() |
| 267 | 281 | */ |
| 268 | −static void ipi_cpu_stop(unsigned int cpu) | |
| 282 | +static void ipi_cpu_stop(void) | |
| 269 | 283 | { |
| 270 | 284 | machine_halt(); |
| 271 | 285 | } |
| 272 | 286 | |
| 273 | −static inline void __do_IPI(unsigned long *ops, struct ipi_data *ipi, int cpu) | |
| 287 | +static inline void __do_IPI(unsigned long msg) | |
| 274 | 288 | { |
| 275 | − unsigned long msg = 0; | |
| 289 | + switch (msg) { | |
| 290 | + case IPI_RESCHEDULE: | |
| 291 | + scheduler_ipi(); | |
| 292 | + break; | |
| 276 | 293 | |
| 277 | − do { | |
| 278 | − msg = find_next_bit(ops, BITS_PER_LONG, msg+1); | |
| 294 | + case IPI_CALL_FUNC: | |
| 295 | + generic_smp_call_function_interrupt(); | |
| 296 | + break; | |
| 279 | 297 | |
| 280 | − switch (msg) { | |
| 281 | − case IPI_RESCHEDULE: | |
| 282 | − scheduler_ipi(); | |
| 283 | − break; | |
| 284 | − | |
| 285 | − case IPI_CALL_FUNC: | |
| 286 | − generic_smp_call_function_interrupt(); | |
| 287 | − break; | |
| 288 | − | |
| 289 | − case IPI_CPU_STOP: | |
| 290 | − ipi_cpu_stop(cpu); | |
| 291 | − break; | |
| 292 | − } | |
| 293 | − } while (msg < BITS_PER_LONG); | |
| 298 | + case IPI_CPU_STOP: | |
| 299 | + ipi_cpu_stop(); | |
| 300 | + break; | |
| 294 | 301 | |
| 302 | + default: | |
| 303 | + pr_warn("IPI with unexpected msg %ld\n", msg); | |
| 304 | + } | |
| 295 | 305 | } |
| 296 | 306 | |
| 297 | 307 | /* |
| @@ -300,19 +310,25 @@ static inline void __do_IPI(unsigned long *ops, struct ipi_data *ipi, int cpu) · 2 unmodified lines | ||
| 300 | 310 | */ |
| 301 | 311 | irqreturn_t do_IPI(int irq, void *dev_id) |
| 302 | 312 | { |
| 303 | − int cpu = smp_processor_id(); | |
| 304 | − struct ipi_data *ipi = &per_cpu(ipi_data, cpu); | |
| 305 | − unsigned long ops; | |
| 313 | + unsigned long pending; | |
| 314 | + | |
| 315 | + pr_debug("IPI [%ld] received on cpu %d\n", | |
| 316 | + *this_cpu_ptr(&ipi_data), smp_processor_id()); | |
| 306 | 317 | |
| 307 | 318 | if (plat_smp_ops.ipi_clear) |
| 308 | − plat_smp_ops.ipi_clear(cpu, irq); | |
| 319 | + plat_smp_ops.ipi_clear(irq); | |
| 309 | 320 | |
| 310 | 321 | /* |
| 311 | − * XXX: is this loop really needed | |
| 312 | − * And do we need to move ipi_clean inside | |
| 322 | + * "dequeue" the msg corresponding to this IPI (and possibly other | |
| 323 | + * piggybacked msg from elided IPIs: see ipi_send_msg_one() above) | |
| 313 | 324 | */ |
| 314 | − while ((ops = xchg(&ipi->bits, 0)) != 0) | |
| 315 | − __do_IPI(&ops, ipi, cpu); | |
| 325 | + pending = xchg(this_cpu_ptr(&ipi_data), 0); | |
| 326 | + | |
| 327 | + do { | |
| 328 | + unsigned long msg = __ffs(pending); | |
| 329 | + __do_IPI(msg); | |
| 330 | + pending &= ~(1U << msg); | |
| 331 | + } while (pending); | |
| 316 | 332 | |
| 317 | 333 | return IRQ_HANDLED; |
| 318 | 334 | } |
| @@ -88,18 +88,14 @@ void iss_model_init_smp(unsigned int cpu) · 87 unmodified lines | ||
| 88 | 88 | smp_ipi_irq_setup(cpu, IDU_INTERRUPT_0 + cpu); |
| 89 | 89 | } |
| 90 | 90 | |
| 91 | −static void iss_model_ipi_send(void *arg) | |
| 91 | +static void iss_model_ipi_send(int cpu) | |
| 92 | 92 | { |
| 93 | − struct cpumask *callmap = arg; | |
| 94 | − unsigned int cpu; | |
| 95 | − | |
| 96 | − for_each_cpu(cpu, callmap) | |
| 97 | − idu_irq_assert(cpu); | |
| 93 | + idu_irq_assert(cpu); | |
| 98 | 94 | } |
| 99 | 95 | |
| 100 | −static void iss_model_ipi_clear(int cpu, int irq) | |
| 96 | +static void iss_model_ipi_clear(int irq) | |
| 101 | 97 | { |
| 102 | − idu_irq_clear(IDU_INTERRUPT_0 + cpu); | |
| 98 | + idu_irq_clear(IDU_INTERRUPT_0 + smp_processor_id()); | |
| 103 | 99 | } |
| 104 | 100 | |
| 105 | 101 | void iss_model_init_early_smp(void) |
| @@ -6,12 +6,13 @@ config ARM · 5 unmodified lines | ||
| 6 | 6 | select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST |
| 7 | 7 | select ARCH_HAVE_CUSTOM_GPIO_H |
| 8 | 8 | select ARCH_MIGHT_HAVE_PC_PARPORT |
| 9 | + select ARCH_USE_BUILTIN_BSWAP | |
| 9 | 10 | select ARCH_USE_CMPXCHG_LOCKREF |
| 10 | 11 | select ARCH_WANT_IPC_PARSE_VERSION |
| 11 | 12 | select BUILDTIME_EXTABLE_SORT if MMU |
| 12 | 13 | select CLONE_BACKWARDS |
| 13 | 14 | select CPU_PM if (SUSPEND || CPU_IDLE) |
| 14 | − select DCACHE_WORD_ACCESS if (CPU_V6 || CPU_V6K || CPU_V7) && !CPU_BIG_ENDIAN && MMU | |
| 15 | + select DCACHE_WORD_ACCESS if HAVE_EFFICIENT_UNALIGNED_ACCESS | |
| 15 | 16 | select GENERIC_ATOMIC64 if (CPU_V7M || CPU_V6 || !CPU_32v6K || !AEABI) |
| 16 | 17 | select GENERIC_CLOCKEVENTS_BROADCAST if SMP |
| 17 | 18 | select GENERIC_IDLE_POLL_SETUP |
| @@ -36,6 +37,7 @@ config ARM · 18 unmodified lines | ||
| 36 | 37 | select HAVE_DMA_ATTRS |
| 37 | 38 | select HAVE_DMA_CONTIGUOUS if MMU |
| 38 | 39 | select HAVE_DYNAMIC_FTRACE if (!XIP_KERNEL) |
| 40 | + select HAVE_EFFICIENT_UNALIGNED_ACCESS if (CPU_V6 || CPU_V6K || CPU_V7) && MMU | |
| 39 | 41 | select HAVE_FTRACE_MCOUNT_RECORD if (!XIP_KERNEL) |
| 40 | 42 | select HAVE_FUNCTION_GRAPH_TRACER if (!THUMB2_KERNEL) |
| 41 | 43 | select HAVE_FUNCTION_TRACER if (!XIP_KERNEL) |
| @@ -63,6 +65,7 @@ config ARM · 21 unmodified lines | ||
| 63 | 65 | select IRQ_FORCED_THREADING |
| 64 | 66 | select KTIME_SCALAR |
| 65 | 67 | select MODULES_USE_ELF_REL |
| 68 | + select NO_BOOTMEM | |
| 66 | 69 | select OLD_SIGACTION |
| 67 | 70 | select OLD_SIGSUSPEND3 |
| 68 | 71 | select PERF_USE_VMALLOC |
| @@ -314,6 +317,8 @@ config ARCH_INTEGRATOR · 245 unmodified lines | ||
| 314 | 317 | bool "ARM Ltd. Integrator family" |
| 315 | 318 | select ARCH_HAS_CPUFREQ |
| 316 | 319 | select ARM_AMBA |
| 320 | + select ARM_PATCH_PHYS_VIRT | |
| 321 | + select AUTO_ZRELADDR | |
| 317 | 322 | select COMMON_CLK |
| 318 | 323 | select COMMON_CLK_VERSATILE |
| 319 | 324 | select GENERIC_CLOCKEVENTS |
| @@ -411,6 +416,26 @@ config ARCH_EBSA110 · 91 unmodified lines | ||
| 411 | 416 | Ethernet interface, two PCMCIA sockets, two serial ports and a |
| 412 | 417 | parallel port. |
| 413 | 418 | |
| 419 | +config ARCH_EFM32 | |
| 420 | + bool "Energy Micro efm32" | |
| 421 | + depends on !MMU | |
| 422 | + select ARCH_REQUIRE_GPIOLIB | |
| 423 | + select ARM_NVIC | |
| 424 | + # CLKSRC_MMIO is wrong here, but needed until a proper fix is merged, | |
| 425 | + # i.e. CLKSRC_EFM32 selecting CLKSRC_MMIO | |
| 426 | + select CLKSRC_MMIO | |
| 427 | + select CLKSRC_OF | |
| 428 | + select COMMON_CLK | |
| 429 | + select CPU_V7M | |
| 430 | + select GENERIC_CLOCKEVENTS | |
| 431 | + select NO_DMA | |
| 432 | + select NO_IOPORT | |
| 433 | + select SPARSE_IRQ | |
| 434 | + select USE_OF | |
| 435 | + help | |
| 436 | + Support for Energy Micro's (now Silicon Labs) efm32 Giant Gecko | |
| 437 | + processors. | |
| 438 | + | |
| 414 | 439 | config ARCH_EP93XX |
| 415 | 440 | bool "EP93xx-based" |
| 416 | 441 | select ARCH_HAS_HOLES_MEMORYMODEL |
| @@ -632,10 +657,10 @@ config ARCH_PXA · 215 unmodified lines | ||
| 632 | 657 | help |
| 633 | 658 | Support for Intel/Marvell's PXA2xx/PXA3xx processor line. |
| 634 | 659 | |
| 635 | −config ARCH_MSM | |
| 660 | +config ARCH_MSM_NODT | |
| 636 | 661 | bool "Qualcomm MSM" |
| 662 | + select ARCH_MSM | |
| 637 | 663 | select ARCH_REQUIRE_GPIOLIB |
| 638 | − select CLKSRC_OF if OF | |
| 639 | 664 | select COMMON_CLK |
| 640 | 665 | select GENERIC_CLOCKEVENTS |
| 641 | 666 | help |
| @@ -645,8 +670,9 @@ config ARCH_MSM · 3 unmodified lines | ||
| 645 | 670 | stack and controls some vital subsystems |
| 646 | 671 | (clock and power control, etc). |
| 647 | 672 | |
| 648 | −config ARCH_SHMOBILE | |
| 649 | − bool "Renesas SH-Mobile / R-Mobile" | |
| 673 | +config ARCH_SHMOBILE_LEGACY | |
| 674 | + bool "Renesas ARM SoCs (non-multiplatform)" | |
| 675 | + select ARCH_SHMOBILE | |
| 650 | 676 | select ARM_PATCH_PHYS_VIRT |
| 651 | 677 | select CLKDEV_LOOKUP |
| 652 | 678 | select GENERIC_CLOCKEVENTS |
| @@ -661,7 +687,9 @@ config ARCH_SHMOBILE · 8 unmodified lines | ||
| 661 | 687 | select PM_GENERIC_DOMAINS if PM |
| 662 | 688 | select SPARSE_IRQ |
| 663 | 689 | help |
| 664 | − Support for Renesas's SH-Mobile and R-Mobile ARM platforms. | |
| 690 | + Support for Renesas ARM SoC platforms using a non-multiplatform | |
| 691 | + kernel. This includes the SH-Mobile, R-Mobile, EMMA-Mobile, R-Car | |
| 692 | + and RZ families. | |
| 665 | 693 | |
| 666 | 694 | config ARCH_RPC |
| 667 | 695 | bool "RiscPC" |
| @@ -711,7 +739,6 @@ config ARCH_S3C24XX · 43 unmodified lines | ||
| 711 | 739 | select HAVE_S3C2410_WATCHDOG if WATCHDOG |
| 712 | 740 | select HAVE_S3C_RTC if RTC_CLASS |
| 713 | 741 | select MULTI_IRQ_HANDLER |
| 714 | − select NEED_MACH_GPIO_H | |
| 715 | 742 | select NEED_MACH_IO_H |
| 716 | 743 | select SAMSUNG_ATAGS |
| 717 | 744 | help |
| @@ -724,24 +751,23 @@ config ARCH_S3C64XX · 6 unmodified lines | ||
| 724 | 751 | bool "Samsung S3C64XX" |
| 725 | 752 | select ARCH_HAS_CPUFREQ |
| 726 | 753 | select ARCH_REQUIRE_GPIOLIB |
| 754 | + select ARM_AMBA | |
| 727 | 755 | select ARM_VIC |
| 728 | 756 | select CLKDEV_LOOKUP |
| 729 | 757 | select CLKSRC_SAMSUNG_PWM |
| 730 | 758 | select COMMON_CLK |
| 731 | − select CPU_V6 | |
| 759 | + select CPU_V6K | |
| 732 | 760 | select GENERIC_CLOCKEVENTS |
| 733 | 761 | select GPIO_SAMSUNG |
| 734 | 762 | select HAVE_S3C2410_I2C if I2C |
| 735 | 763 | select HAVE_S3C2410_WATCHDOG if WATCHDOG |
| 736 | 764 | select HAVE_TCM |
| 737 | − select NEED_MACH_GPIO_H | |
| 738 | 765 | select NO_IOPORT |
| 739 | 766 | select PLAT_SAMSUNG |
| 740 | 767 | select PM_GENERIC_DOMAINS |
| 741 | 768 | select S3C_DEV_NAND |
| 742 | 769 | select S3C_GPIO_TRACK |
| 743 | 770 | select SAMSUNG_ATAGS |
| 744 | − select SAMSUNG_GPIOLIB_4BIT | |
| 745 | 771 | select SAMSUNG_WAKEMASK |
| 746 | 772 | select SAMSUNG_WDT_RESET |
| 747 | 773 | select USB_ARCH_HAS_OHCI |
| @@ -912,6 +938,8 @@ source "arch/arm/mach-bcm/Kconfig" · 164 unmodified lines | ||
| 912 | 938 | |
| 913 | 939 | source "arch/arm/mach-bcm2835/Kconfig" |
| 914 | 940 | |
| 941 | +source "arch/arm/mach-berlin/Kconfig" | |
| 942 | + | |
| 915 | 943 | source "arch/arm/mach-clps711x/Kconfig" |
| 916 | 944 | |
| 917 | 945 | source "arch/arm/mach-cns3xxx/Kconfig" |
| @@ -928,6 +956,8 @@ source "arch/arm/mach-gemini/Kconfig" · 10 unmodified lines | ||
| 928 | 956 | |
| 929 | 957 | source "arch/arm/mach-highbank/Kconfig" |
| 930 | 958 | |
| 959 | +source "arch/arm/mach-hisi/Kconfig" | |
| 960 | + | |
| 931 | 961 | source "arch/arm/mach-integrator/Kconfig" |
| 932 | 962 | |
| 933 | 963 | source "arch/arm/mach-iop32x/Kconfig" |
| @@ -946,6 +976,8 @@ source "arch/arm/mach-ks8695/Kconfig" · 12 unmodified lines | ||
| 946 | 976 | |
| 947 | 977 | source "arch/arm/mach-msm/Kconfig" |
| 948 | 978 | |
| 979 | +source "arch/arm/mach-moxart/Kconfig" | |
| 980 | + | |
| 949 | 981 | source "arch/arm/mach-mv78xx0/Kconfig" |
| 950 | 982 | |
| 951 | 983 | source "arch/arm/mach-imx/Kconfig" |
| @@ -1054,6 +1086,8 @@ config ARM_TIMER_SP804 · 102 unmodified lines | ||
| 1054 | 1086 | select CLKSRC_MMIO |
| 1055 | 1087 | select CLKSRC_OF if OF |
| 1056 | 1088 | |
| 1089 | +source "arch/arm/firmware/Kconfig" | |
| 1090 | + | |
| 1057 | 1091 | source arch/arm/mm/Kconfig |
| 1058 | 1092 | |
| 1059 | 1093 | config ARM_NR_BANKS |
| @@ -1436,14 +1470,14 @@ config SMP · 376 unmodified lines | ||
| 1436 | 1470 | depends on MMU || ARM_MPU |
| 1437 | 1471 | help |
| 1438 | 1472 | This enables support for systems with more than one CPU. If you have |
| 1439 | − a system with only one CPU, like most personal computers, say N. If | |
| 1440 | − you have a system with more than one CPU, say Y. | |
| 1473 | + a system with only one CPU, say N. If you have a system with more | |
| 1474 | + than one CPU, say Y. | |
| 1441 | 1475 | |
| 1442 | − If you say N here, the kernel will run on single and multiprocessor | |
| 1476 | + If you say N here, the kernel will run on uni- and multiprocessor | |
| 1443 | 1477 | machines, but will use only one CPU of a multiprocessor machine. If |
| 1444 | − you say Y here, the kernel will run on many, but not all, single | |
| 1445 | − processor machines. On a single processor machine, the kernel will | |
| 1446 | − run faster if you say N here. | |
| 1478 | + you say Y here, the kernel will run on many, but not all, | |
| 1479 | + uniprocessor machines. On a uniprocessor machine, the kernel | |
| 1480 | + will run faster if you say N here. | |
| 1447 | 1481 | |
| 1448 | 1482 | See also <file:Documentation/x86/i386/IO-APIC.txt>, |
| 1449 | 1483 | <file:Documentation/nmi_watchdog.txt> and the SMP-HOWTO available at |
| @@ -1594,7 +1628,7 @@ config ARM_PSCI · 144 unmodified lines | ||
| 1594 | 1628 | config ARCH_NR_GPIO |
| 1595 | 1629 | int |
| 1596 | 1630 | default 1024 if ARCH_SHMOBILE || ARCH_TEGRA |
| 1597 | − default 512 if ARCH_EXYNOS || ARCH_KEYSTONE || SOC_OMAP5 || SOC_DRA7XX | |
| 1631 | + default 512 if ARCH_EXYNOS || ARCH_KEYSTONE || SOC_OMAP5 || SOC_DRA7XX || ARCH_S3C24XX || ARCH_S3C64XX | |
| 1598 | 1632 | default 392 if ARCH_U8500 |
| 1599 | 1633 | default 352 if ARCH_VT8500 |
| 1600 | 1634 | default 288 if ARCH_SUNXI |
| @@ -1612,7 +1646,7 @@ config HZ_FIXED · 11 unmodified lines | ||
| 1612 | 1646 | default 200 if ARCH_EBSA110 || ARCH_S3C24XX || ARCH_S5P64X0 || \ |
| 1613 | 1647 | ARCH_S5PV210 || ARCH_EXYNOS4 |
| 1614 | 1648 | default AT91_TIMER_HZ if ARCH_AT91 |
| 1615 | − default SHMOBILE_TIMER_HZ if ARCH_SHMOBILE | |
| 1649 | + default SHMOBILE_TIMER_HZ if ARCH_SHMOBILE_LEGACY | |
| 1616 | 1650 | default 0 |
| 1617 | 1651 | |
| 1618 | 1652 | choice |
| @@ -1652,9 +1686,6 @@ config HZ · 33 unmodified lines | ||
| 1652 | 1686 | config SCHED_HRTICK |
| 1653 | 1687 | def_bool HIGH_RES_TIMERS |
| 1654 | 1688 | |
| 1655 | −config SCHED_HRTICK | |
| 1656 | − def_bool HIGH_RES_TIMERS | |
| 1657 | − | |
| 1658 | 1689 | config THUMB2_KERNEL |
| 1659 | 1690 | bool "Compile the kernel in Thumb-2 mode" if !CPU_THUMBONLY |
| 1660 | 1691 | depends on (CPU_V7 || CPU_V7M) && !CPU_V6 && !CPU_V6K |
| @@ -1797,10 +1828,10 @@ config ARCH_WANT_GENERAL_HUGETLB · 136 unmodified lines | ||
| 1797 | 1828 | source "mm/Kconfig" |
| 1798 | 1829 | |
| 1799 | 1830 | config FORCE_MAX_ZONEORDER |
| 1800 | − int "Maximum zone order" if ARCH_SHMOBILE | |
| 1801 | − range 11 64 if ARCH_SHMOBILE | |
| 1831 | + int "Maximum zone order" if ARCH_SHMOBILE_LEGACY | |
| 1832 | + range 11 64 if ARCH_SHMOBILE_LEGACY | |
| 1802 | 1833 | default "12" if SOC_AM33XX |
| 1803 | − default "9" if SA1111 | |
| 1834 | + default "9" if SA1111 || ARCH_EFM32 | |
| 1804 | 1835 | default "11" |
| 1805 | 1836 | help |
| 1806 | 1837 | The kernel memory allocator divides physically contiguous memory |
| @@ -1874,6 +1905,7 @@ config XEN · 67 unmodified lines | ||
| 1874 | 1905 | depends on !GENERIC_ATOMIC64 |
| 1875 | 1906 | select ARM_PSCI |
| 1876 | 1907 | select SWIOTLB_XEN |
| 1908 | + select ARCH_DMA_ADDR_T_64BIT | |
| 1877 | 1909 | help |
| 1878 | 1910 | Say Y if you want to run Linux in a Virtual Machine on Xen on ARM. |
| 1879 | 1911 | |
| @@ -1935,6 +1967,7 @@ config ZBOOT_ROM_BSS · 55 unmodified lines | ||
| 1935 | 1967 | config ZBOOT_ROM |
| 1936 | 1968 | bool "Compressed boot loader in ROM/flash" |
| 1937 | 1969 | depends on ZBOOT_ROM_TEXT != ZBOOT_ROM_BSS |
| 1970 | + depends on !ARM_APPENDED_DTB && !XIP_KERNEL && !AUTO_ZRELADDR | |
| 1938 | 1971 | help |
| 1939 | 1972 | Say Y here if you intend to execute your compressed kernel image |
| 1940 | 1973 | (zImage) directly from ROM or flash. If unsure, say N. |
| @@ -1970,7 +2003,7 @@ endchoice · 29 unmodified lines | ||
| 1970 | 2003 | |
| 1971 | 2004 | config ARM_APPENDED_DTB |
| 1972 | 2005 | bool "Use appended device tree blob to zImage (EXPERIMENTAL)" |
| 1973 | − depends on OF && !ZBOOT_ROM | |
| 2006 | + depends on OF | |
| 1974 | 2007 | help |
| 1975 | 2008 | With this option, the boot code will look for a device tree binary |
| 1976 | 2009 | (DTB) appended to zImage |
| @@ -2058,7 +2091,7 @@ endchoice · 81 unmodified lines | ||
| 2058 | 2091 | |
| 2059 | 2092 | config XIP_KERNEL |
| 2060 | 2093 | bool "Kernel Execute-In-Place from ROM" |
| 2061 | − depends on !ZBOOT_ROM && !ARM_LPAE && !ARCH_MULTIPLATFORM | |
| 2094 | + depends on !ARM_LPAE && !ARCH_MULTIPLATFORM | |
| 2062 | 2095 | help |
| 2063 | 2096 | Execute-In-Place allows the kernel to run from non-volatile storage |
| 2064 | 2097 | directly addressable by the CPU, such as NOR flash. This saves RAM |
| @@ -2121,7 +2154,6 @@ config CRASH_DUMP · 56 unmodified lines | ||
| 2121 | 2154 | |
| 2122 | 2155 | config AUTO_ZRELADDR |
| 2123 | 2156 | bool "Auto calculation of the decompressed kernel image address" |
| 2124 | − depends on !ZBOOT_ROM | |
| 2125 | 2157 | help |
| 2126 | 2158 | ZRELADDR is the physical address where the decompressed kernel |
| 2127 | 2159 | image will be placed. If AUTO_ZRELADDR is selected, the address |
| @@ -2,6 +2,18 @@ menu "Kernel hacking" · 1 unmodified line | ||
| 2 | 2 | |
| 3 | 3 | source "lib/Kconfig.debug" |
| 4 | 4 | |
| 5 | +config ARM_PTDUMP | |
| 6 | + bool "Export kernel pagetable layout to userspace via debugfs" | |
| 7 | + depends on DEBUG_KERNEL | |
| 8 | + select DEBUG_FS | |
| 9 | + ---help--- | |
| 10 | + Say Y here if you want to show the kernel pagetable layout in a | |
| 11 | + debugfs file. This information is only useful for kernel developers | |
| 12 | + who are working in architecture specific areas of the kernel. | |
| 13 | + It is probably not a good idea to enable this feature in a production | |
| 14 | + kernel. | |
| 15 | + If in doubt, say "N" | |
| 16 | + | |
| 5 | 17 | config STRICT_DEVMEM |
| 6 | 18 | bool "Filter access to /dev/mem" |
| 7 | 19 | depends on MMU |
| @@ -94,6 +106,25 @@ choice · 86 unmodified lines | ||
| 94 | 106 | depends on ARCH_BCM2835 |
| 95 | 107 | select DEBUG_UART_PL01X |
| 96 | 108 | |
| 109 | + config DEBUG_BCM_KONA_UART | |
| 110 | + bool "Kernel low-level debugging messages via BCM KONA UART" | |
| 111 | + depends on ARCH_BCM | |
| 112 | + select DEBUG_UART_8250 | |
| 113 | + help | |
| 114 | + Say Y here if you want kernel low-level debugging support | |
| 115 | + on Broadcom SoC platforms. | |
| 116 | + This low level debug works for Broadcom | |
| 117 | + mobile SoCs in the Kona family of chips (e.g. bcm28155, | |
| 118 | + bcm11351, etc...) | |
| 119 | + | |
| 120 | + config DEBUG_BERLIN_UART | |
| 121 | + bool "Marvell Berlin SoC Debug UART" | |
| 122 | + depends on ARCH_BERLIN | |
| 123 | + select DEBUG_UART_8250 | |
| 124 | + help | |
| 125 | + Say Y here if you want kernel low-level debugging support | |
| 126 | + on Marvell Berlin SoC based platforms. | |
| 127 | + | |
| 97 | 128 | config DEBUG_CLPS711X_UART1 |
| 98 | 129 | bool "Kernel low-level debugging messages via UART1" |
| 99 | 130 | depends on ARCH_CLPS711X |
| @@ -255,6 +286,13 @@ choice · 155 unmodified lines | ||
| 255 | 286 | Say Y here if you want kernel low-level debugging support |
| 256 | 287 | on i.MX35. |
| 257 | 288 | |
| 289 | + config DEBUG_IMX50_UART | |
| 290 | + bool "i.MX50 Debug UART" | |
| 291 | + depends on SOC_IMX50 | |
| 292 | + help | |
| 293 | + Say Y here if you want kernel low-level debugging support | |
| 294 | + on i.MX50. | |
| 295 | + | |
| 258 | 296 | config DEBUG_IMX51_UART |
| 259 | 297 | bool "i.MX51 Debug UART" |
| 260 | 298 | depends on SOC_IMX51 |
| @@ -897,6 +935,7 @@ config DEBUG_IMX_UART_PORT · 636 unmodified lines | ||
| 897 | 935 | DEBUG_IMX21_IMX27_UART || \ |
| 898 | 936 | DEBUG_IMX31_UART || \ |
| 899 | 937 | DEBUG_IMX35_UART || \ |
| 938 | + DEBUG_IMX50_UART || \ | |
| 900 | 939 | DEBUG_IMX51_UART || \ |
| 901 | 940 | DEBUG_IMX53_UART || \ |
| 902 | 941 | DEBUG_IMX6Q_UART || \ |
| @@ -931,6 +970,7 @@ config DEBUG_LL_INCLUDE · 28 unmodified lines | ||
| 931 | 970 | DEBUG_IMX21_IMX27_UART || \ |
| 932 | 971 | DEBUG_IMX31_UART || \ |
| 933 | 972 | DEBUG_IMX35_UART || \ |
| 973 | + DEBUG_IMX50_UART || \ | |
| 934 | 974 | DEBUG_IMX51_UART || \ |
| 935 | 975 | DEBUG_IMX53_UART ||\ |
| 936 | 976 | DEBUG_IMX6Q_UART || \ |
| @@ -988,6 +1028,7 @@ config DEBUG_UART_PHYS · 51 unmodified lines | ||
| 988 | 1028 | default 0x20064000 if DEBUG_RK29_UART1 || DEBUG_RK3X_UART2 |
| 989 | 1029 | default 0x20068000 if DEBUG_RK29_UART2 || DEBUG_RK3X_UART3 |
| 990 | 1030 | default 0x20201000 if DEBUG_BCM2835 |
| 1031 | + default 0x3e000000 if DEBUG_BCM_KONA_UART | |
| 991 | 1032 | default 0x4000e400 if DEBUG_LL_UART_EFM32 |
| 992 | 1033 | default 0x40090000 if ARCH_LPC32XX |
| 993 | 1034 | default 0x40100000 if DEBUG_PXA_UART1 |
| @@ -1011,6 +1052,7 @@ config DEBUG_UART_PHYS · 17 unmodified lines | ||
| 1011 | 1052 | default 0xf1012000 if DEBUG_MVEBU_UART_ALTERNATE |
| 1012 | 1053 | default 0xf1012000 if ARCH_DOVE || ARCH_KIRKWOOD || ARCH_MV78XX0 || \ |
| 1013 | 1054 | ARCH_ORION5X |
| 1055 | + default 0xf7fc9000 if DEBUG_BERLIN_UART | |
| 1014 | 1056 | default 0xf8b00000 if DEBUG_HI3716_UART |
| 1015 | 1057 | default 0xfcb00000 if DEBUG_HI3620_UART |
| 1016 | 1058 | default 0xfe800000 if ARCH_IOP32X |
| @@ -1036,6 +1078,7 @@ config DEBUG_UART_VIRT · 19 unmodified lines | ||
| 1036 | 1078 | default 0xf2100000 if DEBUG_PXA_UART1 |
| 1037 | 1079 | default 0xf4090000 if ARCH_LPC32XX |
| 1038 | 1080 | default 0xf4200000 if ARCH_GEMINI |
| 1081 | + default 0xf7fc9000 if DEBUG_BERLIN_UART | |
| 1039 | 1082 | default 0xf8009000 if DEBUG_VEXPRESS_UART0_CA9 |
| 1040 | 1083 | default 0xf8090000 if DEBUG_VEXPRESS_UART0_RS1 |
| 1041 | 1084 | default 0xfb009000 if DEBUG_REALVIEW_STD_PORT |
| @@ -1049,6 +1092,7 @@ config DEBUG_UART_VIRT · 7 unmodified lines | ||
| 1049 | 1092 | default 0xfe018000 if DEBUG_MMP_UART3 |
| 1050 | 1093 | default 0xfe100000 if DEBUG_IMX23_UART || DEBUG_IMX28_UART |
| 1051 | 1094 | default 0xfe230000 if DEBUG_PICOXCELL_UART |
| 1095 | + default 0xfe300000 if DEBUG_BCM_KONA_UART | |
| 1052 | 1096 | default 0xfe800000 if ARCH_IOP32X |
| 1053 | 1097 | default 0xfeb00000 if DEBUG_HI3620_UART || DEBUG_HI3716_UART |
| 1054 | 1098 | default 0xfeb24000 if DEBUG_RK3X_UART0 |
| @@ -1091,7 +1135,8 @@ config DEBUG_UART_8250_WORD · 36 unmodified lines | ||
| 1091 | 1135 | default y if DEBUG_PICOXCELL_UART || DEBUG_SOCFPGA_UART || \ |
| 1092 | 1136 | ARCH_KEYSTONE || \ |
| 1093 | 1137 | DEBUG_DAVINCI_DMx_UART0 || DEBUG_DAVINCI_DA8XX_UART1 || \ |
| 1094 | − DEBUG_DAVINCI_DA8XX_UART2 || DEBUG_DAVINCI_TNETV107X_UART1 | |
| 1138 | + DEBUG_DAVINCI_DA8XX_UART2 || DEBUG_DAVINCI_TNETV107X_UART1 || \ | |
| 1139 | + DEBUG_BCM_KONA_UART | |
| 1095 | 1140 | |
| 1096 | 1141 | config DEBUG_UART_8250_FLOW_CONTROL |
| 1097 | 1142 | bool "Enable flow control for 8250 UART" |
| @@ -1150,4 +1195,15 @@ config PID_IN_CONTEXTIDR · 52 unmodified lines | ||
| 1150 | 1195 | additional instructions during context switch. Say Y here only if you |
| 1151 | 1196 | are planning to use hardware trace tools with this kernel. |
| 1152 | 1197 | |
| 1198 | +config DEBUG_SET_MODULE_RONX | |
| 1199 | + bool "Set loadable kernel module data as NX and text as RO" | |
| 1200 | + depends on MODULES | |
| 1201 | + ---help--- | |
| 1202 | + This option helps catch unintended modifications to loadable | |
| 1203 | + kernel module's text and read-only data. It also prevents execution | |
| 1204 | + of module data. Such protection may interfere with run-time code | |
| 1205 | + patching and dynamic kernel tracing - and they might also protect | |
| 1206 | + against certain classes of kernel exploits. | |
| 1207 | + If in doubt, say "N". | |
| 1208 | + | |
| 1153 | 1209 | endmenu |
| @@ -96,7 +96,7 @@ tune-$(CONFIG_CPU_V6K) =$(call cc-option,-mtune=arm1136j-s,-mtune=strongarm) · 95 unmodified lines | ||
| 96 | 96 | tune-y := $(tune-y) |
| 97 | 97 | |
| 98 | 98 | ifeq ($(CONFIG_AEABI),y) |
| 99 | −CFLAGS_ABI :=-mabi=aapcs-linux -mno-thumb-interwork | |
| 99 | +CFLAGS_ABI :=-mabi=aapcs-linux -mno-thumb-interwork -mfpu=vfp | |
| 100 | 100 | else |
| 101 | 101 | CFLAGS_ABI :=$(call cc-option,-mapcs-32,-mabi=apcs-gnu) $(call cc-option,-mno-thumb-interwork,) |
| 102 | 102 | endif |
| @@ -144,15 +144,18 @@ textofs-$(CONFIG_ARCH_MSM8960) := 0x00208000 · 41 unmodified lines | ||
| 144 | 144 | machine-$(CONFIG_ARCH_AT91) += at91 |
| 145 | 145 | machine-$(CONFIG_ARCH_BCM) += bcm |
| 146 | 146 | machine-$(CONFIG_ARCH_BCM2835) += bcm2835 |
| 147 | +machine-$(CONFIG_ARCH_BERLIN) += berlin | |
| 147 | 148 | machine-$(CONFIG_ARCH_CLPS711X) += clps711x |
| 148 | 149 | machine-$(CONFIG_ARCH_CNS3XXX) += cns3xxx |
| 149 | 150 | machine-$(CONFIG_ARCH_DAVINCI) += davinci |
| 150 | 151 | machine-$(CONFIG_ARCH_DOVE) += dove |
| 151 | 152 | machine-$(CONFIG_ARCH_EBSA110) += ebsa110 |
| 153 | +machine-$(CONFIG_ARCH_EFM32) += efm32 | |
| 152 | 154 | machine-$(CONFIG_ARCH_EP93XX) += ep93xx |
| 153 | 155 | machine-$(CONFIG_ARCH_EXYNOS) += exynos |
| 154 | 156 | machine-$(CONFIG_ARCH_GEMINI) += gemini |
| 155 | 157 | machine-$(CONFIG_ARCH_HIGHBANK) += highbank |
| 158 | +machine-$(CONFIG_ARCH_HI3xxx) += hisi | |
| 156 | 159 | machine-$(CONFIG_ARCH_INTEGRATOR) += integrator |
| 157 | 160 | machine-$(CONFIG_ARCH_IOP13XX) += iop13xx |
| 158 | 161 | machine-$(CONFIG_ARCH_IOP32X) += iop32x |
| @@ -163,6 +166,7 @@ machine-$(CONFIG_ARCH_KIRKWOOD) += kirkwood · 4 unmodified lines | ||
| 163 | 166 | machine-$(CONFIG_ARCH_KS8695) += ks8695 |
| 164 | 167 | machine-$(CONFIG_ARCH_LPC32XX) += lpc32xx |
| 165 | 168 | machine-$(CONFIG_ARCH_MMP) += mmp |
| 169 | +machine-$(CONFIG_ARCH_MOXART) += moxart | |
| 166 | 170 | machine-$(CONFIG_ARCH_MSM) += msm |
| 167 | 171 | machine-$(CONFIG_ARCH_MV78XX0) += mv78xx0 |
| 168 | 172 | machine-$(CONFIG_ARCH_MVEBU) += mvebu |
| @@ -186,7 +190,6 @@ machine-$(CONFIG_ARCH_S5PC100) += s5pc100 · 17 unmodified lines | ||
| 186 | 190 | machine-$(CONFIG_ARCH_S5PV210) += s5pv210 |
| 187 | 191 | machine-$(CONFIG_ARCH_SA1100) += sa1100 |
| 188 | 192 | machine-$(CONFIG_ARCH_SHMOBILE) += shmobile |
| 189 | −machine-$(CONFIG_ARCH_SHMOBILE_MULTI) += shmobile | |
| 190 | 193 | machine-$(CONFIG_ARCH_SIRF) += prima2 |
| 191 | 194 | machine-$(CONFIG_ARCH_SOCFPGA) += socfpga |
| 192 | 195 | machine-$(CONFIG_ARCH_STI) += sti |
| @@ -264,6 +267,7 @@ core-$(CONFIG_KVM_ARM_HOST) += arch/arm/kvm/ · 71 unmodified lines | ||
| 264 | 267 | core-y += arch/arm/kernel/ arch/arm/mm/ arch/arm/common/ |
| 265 | 268 | core-y += arch/arm/net/ |
| 266 | 269 | core-y += arch/arm/crypto/ |
| 270 | +core-y += arch/arm/firmware/ | |
| 267 | 271 | core-y += $(machdirs) $(platdirs) |
| 268 | 272 | |
| 269 | 273 | drivers-$(CONFIG_OPROFILE) += arch/arm/oprofile/ |
| @@ -64,7 +64,7 @@ else · 63 unmodified lines | ||
| 64 | 64 | endif |
| 65 | 65 | endif |
| 66 | 66 | |
| 67 | −ifeq ($(CONFIG_ARCH_SHMOBILE),y) | |
| 67 | +ifeq ($(CONFIG_ARCH_SHMOBILE_LEGACY),y) | |
| 68 | 68 | OBJS += head-shmobile.o |
| 69 | 69 | endif |
| 70 | 70 | |
| @@ -108,12 +108,12 @@ endif · 37 unmodified lines | ||
| 108 | 108 | |
| 109 | 109 | targets := vmlinux vmlinux.lds \ |
| 110 | 110 | piggy.$(suffix_y) piggy.$(suffix_y).o \ |
| 111 | − lib1funcs.o lib1funcs.S ashldi3.o ashldi3.S \ | |
| 112 | − font.o font.c head.o misc.o $(OBJS) | |
| 111 | + lib1funcs.o lib1funcs.S ashldi3.o ashldi3.S bswapsdi2.o \ | |
| 112 | + bswapsdi2.S font.o font.c head.o misc.o $(OBJS) | |
| 113 | 113 | |
| 114 | 114 | # Make sure files are removed during clean |
| 115 | 115 | extra-y += piggy.gzip piggy.lzo piggy.lzma piggy.xzkern piggy.lz4 \ |
| 116 | − lib1funcs.S ashldi3.S $(libfdt) $(libfdt_hdrs) \ | |
| 116 | + lib1funcs.S ashldi3.S bswapsdi2.S $(libfdt) $(libfdt_hdrs) \ | |
| 117 | 117 | hyp-stub.S |
| 118 | 118 | |
| 119 | 119 | ifeq ($(CONFIG_FUNCTION_TRACER),y) |
| @@ -156,6 +156,12 @@ ashldi3 = $(obj)/ashldi3.o · 36 unmodified lines | ||
| 156 | 156 | $(obj)/ashldi3.S: $(srctree)/arch/$(SRCARCH)/lib/ashldi3.S |
| 157 | 157 | $(call cmd,shipped) |
| 158 | 158 | |
| 159 | +# For __bswapsi2, __bswapdi2 | |
| 160 | +bswapsdi2 = $(obj)/bswapsdi2.o | |
| 161 | + | |
| 162 | +$(obj)/bswapsdi2.S: $(srctree)/arch/$(SRCARCH)/lib/bswapsdi2.S | |
| 163 | + $(call cmd,shipped) | |
| 164 | + | |
| 159 | 165 | # We need to prevent any GOTOFF relocs being used with references |
| 160 | 166 | # to symbols in the .bss section since we cannot relocate them |
| 161 | 167 | # independently from the rest at run time. This can be achieved by |
| @@ -177,7 +183,8 @@ if [ $(words $(ZRELADDR)) -gt 1 -a "$(CONFIG_AUTO_ZRELADDR)" = "" ]; then \ · 15 unmodified lines | ||
| 177 | 183 | fi |
| 178 | 184 | |
| 179 | 185 | $(obj)/vmlinux: $(obj)/vmlinux.lds $(obj)/$(HEAD) $(obj)/piggy.$(suffix_y).o \ |
| 180 | − $(addprefix $(obj)/, $(OBJS)) $(lib1funcs) $(ashldi3) FORCE | |
| 186 | + $(addprefix $(obj)/, $(OBJS)) $(lib1funcs) $(ashldi3) \ | |
| 187 | + $(bswapsdi2) FORCE | |
| 181 | 188 | @$(check_for_multiple_zreladdr) |
| 182 | 189 | $(call if_changed,ld) |
| 183 | 190 | @$(check_for_bad_syms) |
| @@ -6,6 +6,7 @@ dtb-$(CONFIG_ARCH_AT91) += at91rm9200ek.dtb · 5 unmodified lines | ||
| 6 | 6 | dtb-$(CONFIG_ARCH_AT91) += mpa1600.dtb |
| 7 | 7 | # sam9260 |
| 8 | 8 | dtb-$(CONFIG_ARCH_AT91) += animeo_ip.dtb |
| 9 | +dtb-$(CONFIG_ARCH_AT91) += at91-qil_a9260.dtb | |
| 9 | 10 | dtb-$(CONFIG_ARCH_AT91) += aks-cdu.dtb |
| 10 | 11 | dtb-$(CONFIG_ARCH_AT91) += ethernut5.dtb |
| 11 | 12 | dtb-$(CONFIG_ARCH_AT91) += evk-pro3.dtb |
| @@ -30,6 +31,7 @@ dtb-$(CONFIG_ARCH_AT91) += pm9g45.dtb · 18 unmodified lines | ||
| 30 | 31 | dtb-$(CONFIG_ARCH_AT91) += at91sam9n12ek.dtb |
| 31 | 32 | # sam9x5 |
| 32 | 33 | dtb-$(CONFIG_ARCH_AT91) += at91-ariag25.dtb |
| 34 | +dtb-$(CONFIG_ARCH_AT91) += at91-cosino_mega2560.dtb | |
| 33 | 35 | dtb-$(CONFIG_ARCH_AT91) += at91sam9g15ek.dtb |
| 34 | 36 | dtb-$(CONFIG_ARCH_AT91) += at91sam9g25ek.dtb |
| 35 | 37 | dtb-$(CONFIG_ARCH_AT91) += at91sam9g35ek.dtb |
| @@ -40,11 +42,16 @@ dtb-$(CONFIG_ARCH_AT91) += sama5d31ek.dtb · 4 unmodified lines | ||
| 40 | 42 | dtb-$(CONFIG_ARCH_AT91) += sama5d33ek.dtb |
| 41 | 43 | dtb-$(CONFIG_ARCH_AT91) += sama5d34ek.dtb |
| 42 | 44 | dtb-$(CONFIG_ARCH_AT91) += sama5d35ek.dtb |
| 45 | +dtb-$(CONFIG_ARCH_AT91) += sama5d36ek.dtb | |
| 46 | + | |
| 43 | 47 | dtb-$(CONFIG_ARCH_ATLAS6) += atlas6-evb.dtb |
| 44 | 48 | dtb-$(CONFIG_ARCH_BCM2835) += bcm2835-rpi-b.dtb |
| 45 | 49 | dtb-$(CONFIG_ARCH_BCM_MOBILE) += bcm11351-brt.dtb \ |
| 46 | 50 | bcm28155-ap.dtb |
| 47 | 51 | dtb-$(CONFIG_ARCH_BCM2835) += bcm2835-rpi-b.dtb |
| 52 | +dtb-$(CONFIG_ARCH_BERLIN) += \ | |
| 53 | + berlin2-sony-nsz-gs7.dtb \ | |
| 54 | + berlin2cd-google-chromecast.dtb | |
| 48 | 55 | dtb-$(CONFIG_ARCH_DAVINCI) += da850-enbw-cmc.dtb \ |
| 49 | 56 | da850-evm.dtb |
| 50 | 57 | dtb-$(CONFIG_ARCH_DOVE) += dove-cm-a510.dtb \ |
| @@ -52,6 +59,7 @@ dtb-$(CONFIG_ARCH_DOVE) += dove-cm-a510.dtb \ · 1 unmodified line | ||
| 52 | 59 | dove-d2plug.dtb \ |
| 53 | 60 | dove-d3plug.dtb \ |
| 54 | 61 | dove-dove-db.dtb |
| 62 | +dtb-$(CONFIG_ARCH_EFM32) += efm32gg-dk3750.dtb | |
| 55 | 63 | dtb-$(CONFIG_ARCH_EXYNOS) += exynos4210-origen.dtb \ |
| 56 | 64 | exynos4210-smdkv310.dtb \ |
| 57 | 65 | exynos4210-trats.dtb \ |
| @@ -59,13 +67,16 @@ dtb-$(CONFIG_ARCH_EXYNOS) += exynos4210-origen.dtb \ · 1 unmodified line | ||
| 59 | 67 | exynos4412-odroidx.dtb \ |
| 60 | 68 | exynos4412-origen.dtb \ |
| 61 | 69 | exynos4412-smdk4412.dtb \ |
| 70 | + exynos4412-tiny4412.dtb \ | |
| 62 | 71 | exynos4412-trats2.dtb \ |
| 63 | 72 | exynos5250-arndale.dtb \ |
| 64 | 73 | exynos5250-smdk5250.dtb \ |
| 65 | 74 | exynos5250-snow.dtb \ |
| 75 | + exynos5420-arndale-octa.dtb \ | |
| 66 | 76 | exynos5420-smdk5420.dtb \ |
| 67 | 77 | exynos5440-sd5v1.dtb \ |
| 68 | 78 | exynos5440-ssdk5440.dtb |
| 79 | +dtb-$(CONFIG_ARCH_HI3xxx) += hi3620-hi4511.dtb | |
| 69 | 80 | dtb-$(CONFIG_ARCH_HIGHBANK) += highbank.dtb \ |
| 70 | 81 | ecx-2000.dtb |
| 71 | 82 | dtb-$(CONFIG_ARCH_INTEGRATOR) += integratorap.dtb \ |
| @@ -85,11 +96,13 @@ dtb-$(CONFIG_ARCH_KIRKWOOD) += kirkwood-cloudbox.dtb \ · 13 unmodified lines | ||
| 85 | 96 | kirkwood-iomega_ix2_200.dtb \ |
| 86 | 97 | kirkwood-is2.dtb \ |
| 87 | 98 | kirkwood-km_kirkwood.dtb \ |
| 99 | + kirkwood-laplug.dtb \ | |
| 88 | 100 | kirkwood-lschlv2.dtb \ |
| 89 | 101 | kirkwood-lsxhl.dtb \ |
| 90 | 102 | kirkwood-mplcec4.dtb \ |
| 91 | 103 | kirkwood-mv88f6281gtw-ge.dtb \ |
| 92 | 104 | kirkwood-netgear_readynas_duo_v2.dtb \ |
| 105 | + kirkwood-netgear_readynas_nv+_v2.dtb \ | |
| 93 | 106 | kirkwood-ns2.dtb \ |
| 94 | 107 | kirkwood-ns2lite.dtb \ |
| 95 | 108 | kirkwood-ns2max.dtb \ |
| @@ -104,8 +117,10 @@ dtb-$(CONFIG_ARCH_KIRKWOOD) += kirkwood-cloudbox.dtb \ · 8 unmodified lines | ||
| 104 | 117 | kirkwood-ts219-6281.dtb \ |
| 105 | 118 | kirkwood-ts219-6282.dtb |
| 106 | 119 | dtb-$(CONFIG_ARCH_MARCO) += marco-evb.dtb |
| 120 | +dtb-$(CONFIG_ARCH_MOXART) += moxart-uc7112lx.dtb | |
| 107 | 121 | dtb-$(CONFIG_ARCH_MSM) += qcom-msm8660-surf.dtb \ |
| 108 | − qcom-msm8960-cdp.dtb | |
| 122 | + qcom-msm8960-cdp.dtb \ | |
| 123 | + qcom-apq8074-dragonboard.dtb | |
| 109 | 124 | dtb-$(CONFIG_ARCH_MVEBU) += armada-370-db.dtb \ |
| 110 | 125 | armada-370-mirabox.dtb \ |
| 111 | 126 | armada-370-netgear-rn102.dtb \ |
| @@ -114,6 +129,7 @@ dtb-$(CONFIG_ARCH_MVEBU) += armada-370-db.dtb \ · 2 unmodified lines | ||
| 114 | 129 | armada-xp-axpwifiap.dtb \ |
| 115 | 130 | armada-xp-db.dtb \ |
| 116 | 131 | armada-xp-gp.dtb \ |
| 132 | + armada-xp-netgear-rn2120.dtb \ | |
| 117 | 133 | armada-xp-matrix.dtb \ |
| 118 | 134 | armada-xp-openblocks-ax3-4.dtb |
| 119 | 135 | dtb-$(CONFIG_ARCH_MXC) += \ |
| @@ -136,10 +152,13 @@ dtb-$(CONFIG_ARCH_MXC) += \ · 16 unmodified lines | ||
| 136 | 152 | imx53-mba53.dtb \ |
| 137 | 153 | imx53-qsb.dtb \ |
| 138 | 154 | imx53-smd.dtb \ |
| 155 | + imx6dl-cubox-i.dtb \ | |
| 156 | + imx6dl-hummingboard.dtb \ | |
| 139 | 157 | imx6dl-sabreauto.dtb \ |
| 140 | 158 | imx6dl-sabresd.dtb \ |
| 141 | 159 | imx6dl-wandboard.dtb \ |
| 142 | 160 | imx6q-arm2.dtb \ |
| 161 | + imx6q-cubox-i.dtb \ | |
| 143 | 162 | imx6q-phytec-pbab01.dtb \ |
| 144 | 163 | imx6q-sabreauto.dtb \ |
| 145 | 164 | imx6q-sabrelite.dtb \ |
| @@ -173,12 +192,19 @@ dtb-$(CONFIG_ARCH_NSPIRE) += nspire-cx.dtb \ · 27 unmodified lines | ||
| 173 | 192 | nspire-tp.dtb \ |
| 174 | 193 | nspire-clp.dtb |
| 175 | 194 | dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \ |
| 195 | + omap2430-sdp.dtb \ | |
| 196 | + omap2420-n800.dtb \ | |
| 197 | + omap2420-n810.dtb \ | |
| 198 | + omap2420-n810-wimax.dtb \ | |
| 176 | 199 | omap3430-sdp.dtb \ |
| 177 | 200 | omap3-beagle.dtb \ |
| 201 | + omap3-cm-t3730.dtb \ | |
| 202 | + omap3-sbc-t3730.dtb \ | |
| 178 | 203 | omap3-devkit8000.dtb \ |
| 179 | 204 | omap3-beagle-xm.dtb \ |
| 180 | 205 | omap3-evm.dtb \ |
| 181 | 206 | omap3-evm-37xx.dtb \ |
| 207 | + omap3-ldp.dtb \ | |
| 182 | 208 | omap3-n900.dtb \ |
| 183 | 209 | omap3-n9.dtb \ |
| 184 | 210 | omap3-n950.dtb \ |
| @@ -216,8 +242,9 @@ dtb-$(CONFIG_ARCH_U8500) += ste-snowball.dtb \ · 31 unmodified lines | ||
| 216 | 242 | dtb-$(CONFIG_ARCH_S3C24XX) += s3c2416-smdk2416.dtb |
| 217 | 243 | dtb-$(CONFIG_ARCH_S3C64XX) += s3c6410-mini6410.dtb \ |
| 218 | 244 | s3c6410-smdk6410.dtb |
| 219 | −dtb-$(CONFIG_ARCH_SHMOBILE) += emev2-kzm9d.dtb \ | |
| 245 | +dtb-$(CONFIG_ARCH_SHMOBILE_LEGACY) += emev2-kzm9d.dtb \ | |
| 220 | 246 | r7s72100-genmai.dtb \ |
| 247 | + r7s72100-genmai-reference.dtb \ | |
| 221 | 248 | r8a7740-armadillo800eva.dtb \ |
| 222 | 249 | r8a7778-bockw.dtb \ |
| 223 | 250 | r8a7778-bockw-reference.dtb \ |
| @@ -226,13 +253,15 @@ dtb-$(CONFIG_ARCH_SHMOBILE) += emev2-kzm9d.dtb \ · 2 unmodified lines | ||
| 226 | 253 | r8a7779-marzen-reference.dtb \ |
| 227 | 254 | r8a7791-koelsch.dtb \ |
| 228 | 255 | r8a7790-lager.dtb \ |
| 229 | − r8a7790-lager-reference.dtb \ | |
| 230 | 256 | sh73a0-kzm9g.dtb \ |
| 231 | 257 | sh73a0-kzm9g-reference.dtb \ |
| 232 | 258 | r8a73a4-ape6evm.dtb \ |
| 233 | 259 | r8a73a4-ape6evm-reference.dtb \ |
| 234 | 260 | sh7372-mackerel.dtb |
| 235 | −dtb-$(CONFIG_ARCH_SHMOBILE_MULTI) += emev2-kzm9d.dtb | |
| 261 | +dtb-$(CONFIG_ARCH_SHMOBILE_MULTI) += emev2-kzm9d.dtb \ | |
| 262 | + r7s72100-genmai-reference.dtb \ | |
| 263 | + r8a7791-koelsch.dtb \ | |
| 264 | + r8a7790-lager.dtb | |
| 236 | 265 | dtb-$(CONFIG_ARCH_SOCFPGA) += socfpga_arria5_socdk.dtb \ |
| 237 | 266 | socfpga_cyclone5_socdk.dtb \ |
| 238 | 267 | socfpga_cyclone5_sockit.dtb \ |
| @@ -255,6 +284,7 @@ dtb-$(CONFIG_ARCH_SUNXI) += \ · 16 unmodified lines | ||
| 255 | 284 | sun4i-a10-hackberry.dtb \ |
| 256 | 285 | sun5i-a10s-olinuxino-micro.dtb \ |
| 257 | 286 | sun5i-a13-olinuxino.dtb \ |
| 287 | + sun5i-a13-olinuxino-micro.dtb \ | |
| 258 | 288 | sun6i-a31-colombus.dtb \ |
| 259 | 289 | sun7i-a20-cubieboard2.dtb \ |
| 260 | 290 | sun7i-a20-cubietruck.dtb \ |
| @@ -0,0 +1,664 @@ | ||
| 1 | +/* | |
| 2 | + * Device Tree Source for AM33xx clock data | |
| 3 | + * | |
| 4 | + * Copyright (C) 2013 Texas Instruments, Inc. | |
| 5 | + * | |
| 6 | + * This program is free software; you can redistribute it and/or modify | |
| 7 | + * it under the terms of the GNU General Public License version 2 as | |
| 8 | + * published by the Free Software Foundation. | |
| 9 | + */ | |
| 10 | +&scrm_clocks { | |
| 11 | + sys_clkin_ck: sys_clkin_ck { | |
| 12 | + #clock-cells = <0>; | |
| 13 | + compatible = "ti,mux-clock"; | |
| 14 | + clocks = <&virt_19200000_ck>, <&virt_24000000_ck>, <&virt_25000000_ck>, <&virt_26000000_ck>; | |
| 15 | + ti,bit-shift = <22>; | |
| 16 | + reg = <0x0040>; | |
| 17 | + }; | |
| 18 | + | |
| 19 | + adc_tsc_fck: adc_tsc_fck { | |
| 20 | + #clock-cells = <0>; | |
| 21 | + compatible = "fixed-factor-clock"; | |
| 22 | + clocks = <&sys_clkin_ck>; | |
| 23 | + clock-mult = <1>; | |
| 24 | + clock-div = <1>; | |
| 25 | + }; | |
| 26 | + | |
| 27 | + dcan0_fck: dcan0_fck { | |
| 28 | + #clock-cells = <0>; | |
| 29 | + compatible = "fixed-factor-clock"; | |
| 30 | + clocks = <&sys_clkin_ck>; | |
| 31 | + clock-mult = <1>; | |
| 32 | + clock-div = <1>; | |
| 33 | + }; | |
| 34 | + | |
| 35 | + dcan1_fck: dcan1_fck { | |
| 36 | + #clock-cells = <0>; | |
| 37 | + compatible = "fixed-factor-clock"; | |
| 38 | + clocks = <&sys_clkin_ck>; | |
| 39 | + clock-mult = <1>; | |
| 40 | + clock-div = <1>; | |
| 41 | + }; | |
| 42 | + | |
| 43 | + mcasp0_fck: mcasp0_fck { | |
| 44 | + #clock-cells = <0>; | |
| 45 | + compatible = "fixed-factor-clock"; | |
| 46 | + clocks = <&sys_clkin_ck>; | |
| 47 | + clock-mult = <1>; | |
| 48 | + clock-div = <1>; | |
| 49 | + }; | |
| 50 | + | |
| 51 | + mcasp1_fck: mcasp1_fck { | |
| 52 | + #clock-cells = <0>; | |
| 53 | + compatible = "fixed-factor-clock"; | |
| 54 | + clocks = <&sys_clkin_ck>; | |
| 55 | + clock-mult = <1>; | |
| 56 | + clock-div = <1>; | |
| 57 | + }; | |
| 58 | + | |
| 59 | + smartreflex0_fck: smartreflex0_fck { | |
| 60 | + #clock-cells = <0>; | |
| 61 | + compatible = "fixed-factor-clock"; | |
| 62 | + clocks = <&sys_clkin_ck>; | |
| 63 | + clock-mult = <1>; | |
| 64 | + clock-div = <1>; | |
| 65 | + }; | |
| 66 | + | |
| 67 | + smartreflex1_fck: smartreflex1_fck { | |
| 68 | + #clock-cells = <0>; | |
| 69 | + compatible = "fixed-factor-clock"; | |
| 70 | + clocks = <&sys_clkin_ck>; | |
| 71 | + clock-mult = <1>; | |
| 72 | + clock-div = <1>; | |
| 73 | + }; | |
| 74 | + | |
| 75 | + sha0_fck: sha0_fck { | |
| 76 | + #clock-cells = <0>; | |
| 77 | + compatible = "fixed-factor-clock"; | |
| 78 | + clocks = <&sys_clkin_ck>; | |
| 79 | + clock-mult = <1>; | |
| 80 | + clock-div = <1>; | |
| 81 | + }; | |
| 82 | + | |
| 83 | + aes0_fck: aes0_fck { | |
| 84 | + #clock-cells = <0>; | |
| 85 | + compatible = "fixed-factor-clock"; | |
| 86 | + clocks = <&sys_clkin_ck>; | |
| 87 | + clock-mult = <1>; | |
| 88 | + clock-div = <1>; | |
| 89 | + }; | |
| 90 | + | |
| 91 | + rng_fck: rng_fck { | |
| 92 | + #clock-cells = <0>; | |
| 93 | + compatible = "fixed-factor-clock"; | |
| 94 | + clocks = <&sys_clkin_ck>; | |
| 95 | + clock-mult = <1>; | |
| 96 | + clock-div = <1>; | |
| 97 | + }; | |
| 98 | + | |
| 99 | + ehrpwm0_gate_tbclk: ehrpwm0_gate_tbclk { | |
| 100 | + #clock-cells = <0>; | |
| 101 | + compatible = "ti,composite-no-wait-gate-clock"; | |
| 102 | + clocks = <&dpll_per_m2_ck>; | |
| 103 | + ti,bit-shift = <0>; | |
| 104 | + reg = <0x0664>; | |
| 105 | + }; | |
| 106 | + | |
| 107 | + ehrpwm0_tbclk: ehrpwm0_tbclk { | |
| 108 | + #clock-cells = <0>; | |
| 109 | + compatible = "ti,composite-clock"; | |
| 110 | + clocks = <&ehrpwm0_gate_tbclk>; | |
| 111 | + }; | |
| 112 | + | |
| 113 | + ehrpwm1_gate_tbclk: ehrpwm1_gate_tbclk { | |
| 114 | + #clock-cells = <0>; | |
| 115 | + compatible = "ti,composite-no-wait-gate-clock"; | |
| 116 | + clocks = <&dpll_per_m2_ck>; | |
| 117 | + ti,bit-shift = <1>; | |
| 118 | + reg = <0x0664>; | |
| 119 | + }; | |
| 120 | + | |
| 121 | + ehrpwm1_tbclk: ehrpwm1_tbclk { | |
| 122 | + #clock-cells = <0>; | |
| 123 | + compatible = "ti,composite-clock"; | |
| 124 | + clocks = <&ehrpwm1_gate_tbclk>; | |
| 125 | + }; | |
| 126 | + | |
| 127 | + ehrpwm2_gate_tbclk: ehrpwm2_gate_tbclk { | |
| 128 | + #clock-cells = <0>; | |
| 129 | + compatible = "ti,composite-no-wait-gate-clock"; | |
| 130 | + clocks = <&dpll_per_m2_ck>; | |
| 131 | + ti,bit-shift = <2>; | |
| 132 | + reg = <0x0664>; | |
| 133 | + }; | |
| 134 | + | |
| 135 | + ehrpwm2_tbclk: ehrpwm2_tbclk { | |
| 136 | + #clock-cells = <0>; | |
| 137 | + compatible = "ti,composite-clock"; | |
| 138 | + clocks = <&ehrpwm2_gate_tbclk>; | |
| 139 | + }; | |
| 140 | +}; | |
| 141 | +&prcm_clocks { | |
| 142 | + clk_32768_ck: clk_32768_ck { | |
| 143 | + #clock-cells = <0>; | |
| 144 | + compatible = "fixed-clock"; | |
| 145 | + clock-frequency = <32768>; | |
| 146 | + }; | |
| 147 | + | |
| 148 | + clk_rc32k_ck: clk_rc32k_ck { | |
| 149 | + #clock-cells = <0>; | |
| 150 | + compatible = "fixed-clock"; | |
| 151 | + clock-frequency = <32000>; | |
| 152 | + }; | |
| 153 | + | |
| 154 | + virt_19200000_ck: virt_19200000_ck { | |
| 155 | + #clock-cells = <0>; | |
| 156 | + compatible = "fixed-clock"; | |
| 157 | + clock-frequency = <19200000>; | |
| 158 | + }; | |
| 159 | + | |
| 160 | + virt_24000000_ck: virt_24000000_ck { | |
| 161 | + #clock-cells = <0>; | |
| 162 | + compatible = "fixed-clock"; | |
| 163 | + clock-frequency = <24000000>; | |
| 164 | + }; | |
| 165 | + | |
| 166 | + virt_25000000_ck: virt_25000000_ck { | |
| 167 | + #clock-cells = <0>; | |
| 168 | + compatible = "fixed-clock"; | |
| 169 | + clock-frequency = <25000000>; | |
| 170 | + }; | |
| 171 | + | |
| 172 | + virt_26000000_ck: virt_26000000_ck { | |
| 173 | + #clock-cells = <0>; | |
| 174 | + compatible = "fixed-clock"; | |
| 175 | + clock-frequency = <26000000>; | |
| 176 | + }; | |
| 177 | + | |
| 178 | + tclkin_ck: tclkin_ck { | |
| 179 | + #clock-cells = <0>; | |
| 180 | + compatible = "fixed-clock"; | |
| 181 | + clock-frequency = <12000000>; | |
| 182 | + }; | |
| 183 | + | |
| 184 | + dpll_core_ck: dpll_core_ck { | |
| 185 | + #clock-cells = <0>; | |
| 186 | + compatible = "ti,am3-dpll-core-clock"; | |
| 187 | + clocks = <&sys_clkin_ck>, <&sys_clkin_ck>; | |
| 188 | + reg = <0x0490>, <0x045c>, <0x0468>; | |
| 189 | + }; | |
| 190 | + | |
| 191 | + dpll_core_x2_ck: dpll_core_x2_ck { | |
| 192 | + #clock-cells = <0>; | |
| 193 | + compatible = "ti,am3-dpll-x2-clock"; | |
| 194 | + clocks = <&dpll_core_ck>; | |
| 195 | + }; | |
| 196 | + | |
| 197 | + dpll_core_m4_ck: dpll_core_m4_ck { | |
| 198 | + #clock-cells = <0>; | |
| 199 | + compatible = "ti,divider-clock"; | |
| 200 | + clocks = <&dpll_core_x2_ck>; | |
| 201 | + ti,max-div = <31>; | |
| 202 | + reg = <0x0480>; | |
| 203 | + ti,index-starts-at-one; | |
| 204 | + }; | |
| 205 | + | |
| 206 | + dpll_core_m5_ck: dpll_core_m5_ck { | |
| 207 | + #clock-cells = <0>; | |
| 208 | + compatible = "ti,divider-clock"; | |
| 209 | + clocks = <&dpll_core_x2_ck>; | |
| 210 | + ti,max-div = <31>; | |
| 211 | + reg = <0x0484>; | |
| 212 | + ti,index-starts-at-one; | |
| 213 | + }; | |
| 214 | + | |
| 215 | + dpll_core_m6_ck: dpll_core_m6_ck { | |
| 216 | + #clock-cells = <0>; | |
| 217 | + compatible = "ti,divider-clock"; | |
| 218 | + clocks = <&dpll_core_x2_ck>; | |
| 219 | + ti,max-div = <31>; | |
| 220 | + reg = <0x04d8>; | |
| 221 | + ti,index-starts-at-one; | |
| 222 | + }; | |
| 223 | + | |
| 224 | + dpll_mpu_ck: dpll_mpu_ck { | |
| 225 | + #clock-cells = <0>; | |
| 226 | + compatible = "ti,am3-dpll-clock"; | |
| 227 | + clocks = <&sys_clkin_ck>, <&sys_clkin_ck>; | |
| 228 | + reg = <0x0488>, <0x0420>, <0x042c>; | |
| 229 | + }; | |
| 230 | + | |
| 231 | + dpll_mpu_m2_ck: dpll_mpu_m2_ck { | |
| 232 | + #clock-cells = <0>; | |
| 233 | + compatible = "ti,divider-clock"; | |
| 234 | + clocks = <&dpll_mpu_ck>; | |
| 235 | + ti,max-div = <31>; | |
| 236 | + reg = <0x04a8>; | |
| 237 | + ti,index-starts-at-one; | |
| 238 | + }; | |
| 239 | + | |
| 240 | + dpll_ddr_ck: dpll_ddr_ck { | |
| 241 | + #clock-cells = <0>; | |
| 242 | + compatible = "ti,am3-dpll-no-gate-clock"; | |
| 243 | + clocks = <&sys_clkin_ck>, <&sys_clkin_ck>; | |
| 244 | + reg = <0x0494>, <0x0434>, <0x0440>; | |
| 245 | + }; | |
| 246 | + | |
| 247 | + dpll_ddr_m2_ck: dpll_ddr_m2_ck { | |
| 248 | + #clock-cells = <0>; | |
| 249 | + compatible = "ti,divider-clock"; | |
| 250 | + clocks = <&dpll_ddr_ck>; | |
| 251 | + ti,max-div = <31>; | |
| 252 | + reg = <0x04a0>; | |
| 253 | + ti,index-starts-at-one; | |
| 254 | + }; | |
| 255 | + | |
| 256 | + dpll_ddr_m2_div2_ck: dpll_ddr_m2_div2_ck { | |
| 257 | + #clock-cells = <0>; | |
| 258 | + compatible = "fixed-factor-clock"; | |
| 259 | + clocks = <&dpll_ddr_m2_ck>; | |
| 260 | + clock-mult = <1>; | |
| 261 | + clock-div = <2>; | |
| 262 | + }; | |
| 263 | + | |
| 264 | + dpll_disp_ck: dpll_disp_ck { | |
| 265 | + #clock-cells = <0>; | |
| 266 | + compatible = "ti,am3-dpll-no-gate-clock"; | |
| 267 | + clocks = <&sys_clkin_ck>, <&sys_clkin_ck>; | |
| 268 | + reg = <0x0498>, <0x0448>, <0x0454>; | |
| 269 | + }; | |
| 270 | + | |
| 271 | + dpll_disp_m2_ck: dpll_disp_m2_ck { | |
| 272 | + #clock-cells = <0>; | |
| 273 | + compatible = "ti,divider-clock"; | |
| 274 | + clocks = <&dpll_disp_ck>; | |
| 275 | + ti,max-div = <31>; | |
| 276 | + reg = <0x04a4>; | |
| 277 | + ti,index-starts-at-one; | |
| 278 | + ti,set-rate-parent; | |
| 279 | + }; | |
| 280 | + | |
| 281 | + dpll_per_ck: dpll_per_ck { | |
| 282 | + #clock-cells = <0>; | |
| 283 | + compatible = "ti,am3-dpll-no-gate-j-type-clock"; | |
| 284 | + clocks = <&sys_clkin_ck>, <&sys_clkin_ck>; | |
| 285 | + reg = <0x048c>, <0x0470>, <0x049c>; | |
| 286 | + }; | |
| 287 | + | |
| 288 | + dpll_per_m2_ck: dpll_per_m2_ck { | |
| 289 | + #clock-cells = <0>; | |
| 290 | + compatible = "ti,divider-clock"; | |
| 291 | + clocks = <&dpll_per_ck>; | |
| 292 | + ti,max-div = <31>; | |
| 293 | + reg = <0x04ac>; | |
| 294 | + ti,index-starts-at-one; | |
| 295 | + }; | |
| 296 | + | |
| 297 | + dpll_per_m2_div4_wkupdm_ck: dpll_per_m2_div4_wkupdm_ck { | |
| 298 | + #clock-cells = <0>; | |
| 299 | + compatible = "fixed-factor-clock"; | |
| 300 | + clocks = <&dpll_per_m2_ck>; | |
| 301 | + clock-mult = <1>; | |
| 302 | + clock-div = <4>; | |
| 303 | + }; | |
| 304 | + | |
| 305 | + dpll_per_m2_div4_ck: dpll_per_m2_div4_ck { | |
| 306 | + #clock-cells = <0>; | |
| 307 | + compatible = "fixed-factor-clock"; | |
| 308 | + clocks = <&dpll_per_m2_ck>; | |
| 309 | + clock-mult = <1>; | |
| 310 | + clock-div = <4>; | |
| 311 | + }; | |
| 312 | + | |
| 313 | + cefuse_fck: cefuse_fck { | |
| 314 | + #clock-cells = <0>; | |
| 315 | + compatible = "ti,gate-clock"; | |
| 316 | + clocks = <&sys_clkin_ck>; | |
| 317 | + ti,bit-shift = <1>; | |
| 318 | + reg = <0x0a20>; | |
| 319 | + }; | |
| 320 | + | |
| 321 | + clk_24mhz: clk_24mhz { | |
| 322 | + #clock-cells = <0>; | |
| 323 | + compatible = "fixed-factor-clock"; | |
| 324 | + clocks = <&dpll_per_m2_ck>; | |
| 325 | + clock-mult = <1>; | |
| 326 | + clock-div = <8>; | |
| 327 | + }; | |
| 328 | + | |
| 329 | + clkdiv32k_ck: clkdiv32k_ck { | |
| 330 | + #clock-cells = <0>; | |
| 331 | + compatible = "fixed-factor-clock"; | |
| 332 | + clocks = <&clk_24mhz>; | |
| 333 | + clock-mult = <1>; | |
| 334 | + clock-div = <732>; | |
| 335 | + }; | |
| 336 | + | |
| 337 | + clkdiv32k_ick: clkdiv32k_ick { | |
| 338 | + #clock-cells = <0>; | |
| 339 | + compatible = "ti,gate-clock"; | |
| 340 | + clocks = <&clkdiv32k_ck>; | |
| 341 | + ti,bit-shift = <1>; | |
| 342 | + reg = <0x014c>; | |
| 343 | + }; | |
| 344 | + | |
| 345 | + l3_gclk: l3_gclk { | |
| 346 | + #clock-cells = <0>; | |
| 347 | + compatible = "fixed-factor-clock"; | |
| 348 | + clocks = <&dpll_core_m4_ck>; | |
| 349 | + clock-mult = <1>; | |
| 350 | + clock-div = <1>; | |
| 351 | + }; | |
| 352 | + | |
| 353 | + pruss_ocp_gclk: pruss_ocp_gclk { | |
| 354 | + #clock-cells = <0>; | |
| 355 | + compatible = "ti,mux-clock"; | |
| 356 | + clocks = <&l3_gclk>, <&dpll_disp_m2_ck>; | |
| 357 | + reg = <0x0530>; | |
| 358 | + }; | |
| 359 | + | |
| 360 | + mmu_fck: mmu_fck { | |
| 361 | + #clock-cells = <0>; | |
| 362 | + compatible = "ti,gate-clock"; | |
| 363 | + clocks = <&dpll_core_m4_ck>; | |
| 364 | + ti,bit-shift = <1>; | |
| 365 | + reg = <0x0914>; | |
| 366 | + }; | |
| 367 | + | |
| 368 | + timer1_fck: timer1_fck { | |
| 369 | + #clock-cells = <0>; | |
| 370 | + compatible = "ti,mux-clock"; | |
| 371 | + clocks = <&sys_clkin_ck>, <&clkdiv32k_ick>, <&tclkin_ck>, <&clk_rc32k_ck>, <&clk_32768_ck>; | |
| 372 | + reg = <0x0528>; | |
| 373 | + }; | |
| 374 | + | |
| 375 | + timer2_fck: timer2_fck { | |
| 376 | + #clock-cells = <0>; | |
| 377 | + compatible = "ti,mux-clock"; | |
| 378 | + clocks = <&tclkin_ck>, <&sys_clkin_ck>, <&clkdiv32k_ick>; | |
| 379 | + reg = <0x0508>; | |
| 380 | + }; | |
| 381 | + | |
| 382 | + timer3_fck: timer3_fck { | |
| 383 | + #clock-cells = <0>; | |
| 384 | + compatible = "ti,mux-clock"; | |
| 385 | + clocks = <&tclkin_ck>, <&sys_clkin_ck>, <&clkdiv32k_ick>; | |
| 386 | + reg = <0x050c>; | |
| 387 | + }; | |
| 388 | + | |
| 389 | + timer4_fck: timer4_fck { | |
| 390 | + #clock-cells = <0>; | |
| 391 | + compatible = "ti,mux-clock"; | |
| 392 | + clocks = <&tclkin_ck>, <&sys_clkin_ck>, <&clkdiv32k_ick>; | |
| 393 | + reg = <0x0510>; | |
| 394 | + }; | |
| 395 | + | |
| 396 | + timer5_fck: timer5_fck { | |
| 397 | + #clock-cells = <0>; | |
| 398 | + compatible = "ti,mux-clock"; | |
| 399 | + clocks = <&tclkin_ck>, <&sys_clkin_ck>, <&clkdiv32k_ick>; | |
| 400 | + reg = <0x0518>; | |
| 401 | + }; | |
| 402 | + | |
| 403 | + timer6_fck: timer6_fck { | |
| 404 | + #clock-cells = <0>; | |
| 405 | + compatible = "ti,mux-clock"; | |
| 406 | + clocks = <&tclkin_ck>, <&sys_clkin_ck>, <&clkdiv32k_ick>; | |
| 407 | + reg = <0x051c>; | |
| 408 | + }; | |
| 409 | + | |
| 410 | + timer7_fck: timer7_fck { | |
| 411 | + #clock-cells = <0>; | |
| 412 | + compatible = "ti,mux-clock"; | |
| 413 | + clocks = <&tclkin_ck>, <&sys_clkin_ck>, <&clkdiv32k_ick>; | |
| 414 | + reg = <0x0504>; | |
| 415 | + }; | |
| 416 | + | |
| 417 | + usbotg_fck: usbotg_fck { | |
| 418 | + #clock-cells = <0>; | |
| 419 | + compatible = "ti,gate-clock"; | |
| 420 | + clocks = <&dpll_per_ck>; | |
| 421 | + ti,bit-shift = <8>; | |
| 422 | + reg = <0x047c>; | |
| 423 | + }; | |
| 424 | + | |
| 425 | + dpll_core_m4_div2_ck: dpll_core_m4_div2_ck { | |
| 426 | + #clock-cells = <0>; | |
| 427 | + compatible = "fixed-factor-clock"; | |
| 428 | + clocks = <&dpll_core_m4_ck>; | |
| 429 | + clock-mult = <1>; | |
| 430 | + clock-div = <2>; | |
| 431 | + }; | |
| 432 | + | |
| 433 | + ieee5000_fck: ieee5000_fck { | |
| 434 | + #clock-cells = <0>; | |
| 435 | + compatible = "ti,gate-clock"; | |
| 436 | + clocks = <&dpll_core_m4_div2_ck>; | |
| 437 | + ti,bit-shift = <1>; | |
| 438 | + reg = <0x00e4>; | |
| 439 | + }; | |
| 440 | + | |
| 441 | + wdt1_fck: wdt1_fck { | |
| 442 | + #clock-cells = <0>; | |
| 443 | + compatible = "ti,mux-clock"; | |
| 444 | + clocks = <&clk_rc32k_ck>, <&clkdiv32k_ick>; | |
| 445 | + reg = <0x0538>; | |
| 446 | + }; | |
| 447 | + | |
| 448 | + l4_rtc_gclk: l4_rtc_gclk { | |
| 449 | + #clock-cells = <0>; | |
| 450 | + compatible = "fixed-factor-clock"; | |
| 451 | + clocks = <&dpll_core_m4_ck>; | |
| 452 | + clock-mult = <1>; | |
| 453 | + clock-div = <2>; | |
| 454 | + }; | |
| 455 | + | |
| 456 | + l4hs_gclk: l4hs_gclk { | |
| 457 | + #clock-cells = <0>; | |
| 458 | + compatible = "fixed-factor-clock"; | |
| 459 | + clocks = <&dpll_core_m4_ck>; | |
| 460 | + clock-mult = <1>; | |
| 461 | + clock-div = <1>; | |
| 462 | + }; | |
| 463 | + | |
| 464 | + l3s_gclk: l3s_gclk { | |
| 465 | + #clock-cells = <0>; | |
| 466 | + compatible = "fixed-factor-clock"; | |
| 467 | + clocks = <&dpll_core_m4_div2_ck>; | |
| 468 | + clock-mult = <1>; | |
| 469 | + clock-div = <1>; | |
| 470 | + }; | |
| 471 | + | |
| 472 | + l4fw_gclk: l4fw_gclk { | |
| 473 | + #clock-cells = <0>; | |
| 474 | + compatible = "fixed-factor-clock"; | |
| 475 | + clocks = <&dpll_core_m4_div2_ck>; | |
| 476 | + clock-mult = <1>; | |
| 477 | + clock-div = <1>; | |
| 478 | + }; | |
| 479 | + | |
| 480 | + l4ls_gclk: l4ls_gclk { | |
| 481 | + #clock-cells = <0>; | |
| 482 | + compatible = "fixed-factor-clock"; | |
| 483 | + clocks = <&dpll_core_m4_div2_ck>; | |
| 484 | + clock-mult = <1>; | |
| 485 | + clock-div = <1>; | |
| 486 | + }; | |
| 487 | + | |
| 488 | + sysclk_div_ck: sysclk_div_ck { | |
| 489 | + #clock-cells = <0>; | |
| 490 | + compatible = "fixed-factor-clock"; | |
| 491 | + clocks = <&dpll_core_m4_ck>; | |
| 492 | + clock-mult = <1>; | |
| 493 | + clock-div = <1>; | |
| 494 | + }; | |
| 495 | + | |
| 496 | + cpsw_125mhz_gclk: cpsw_125mhz_gclk { | |
| 497 | + #clock-cells = <0>; | |
| 498 | + compatible = "fixed-factor-clock"; | |
| 499 | + clocks = <&dpll_core_m5_ck>; | |
| 500 | + clock-mult = <1>; | |
| 501 | + clock-div = <2>; | |
| 502 | + }; | |
| 503 | + | |
| 504 | + cpsw_cpts_rft_clk: cpsw_cpts_rft_clk { | |
| 505 | + #clock-cells = <0>; | |
| 506 | + compatible = "ti,mux-clock"; | |
| 507 | + clocks = <&dpll_core_m5_ck>, <&dpll_core_m4_ck>; | |
| 508 | + reg = <0x0520>; | |
| 509 | + }; | |
| 510 | + | |
| 511 | + gpio0_dbclk_mux_ck: gpio0_dbclk_mux_ck { | |
| 512 | + #clock-cells = <0>; | |
| 513 | + compatible = "ti,mux-clock"; | |
| 514 | + clocks = <&clk_rc32k_ck>, <&clk_32768_ck>, <&clkdiv32k_ick>; | |
| 515 | + reg = <0x053c>; | |
| 516 | + }; | |
| 517 | + | |
| 518 | + gpio0_dbclk: gpio0_dbclk { | |
| 519 | + #clock-cells = <0>; | |
| 520 | + compatible = "ti,gate-clock"; | |
| 521 | + clocks = <&gpio0_dbclk_mux_ck>; | |
| 522 | + ti,bit-shift = <18>; | |
| 523 | + reg = <0x0408>; | |
| 524 | + }; | |
| 525 | + | |
| 526 | + gpio1_dbclk: gpio1_dbclk { | |
| 527 | + #clock-cells = <0>; | |
| 528 | + compatible = "ti,gate-clock"; | |
| 529 | + clocks = <&clkdiv32k_ick>; | |
| 530 | + ti,bit-shift = <18>; | |
| 531 | + reg = <0x00ac>; | |
| 532 | + }; | |
| 533 | + | |
| 534 | + gpio2_dbclk: gpio2_dbclk { | |
| 535 | + #clock-cells = <0>; | |
| 536 | + compatible = "ti,gate-clock"; | |
| 537 | + clocks = <&clkdiv32k_ick>; | |
| 538 | + ti,bit-shift = <18>; | |
| 539 | + reg = <0x00b0>; | |
| 540 | + }; | |
| 541 | + | |
| 542 | + gpio3_dbclk: gpio3_dbclk { | |
| 543 | + #clock-cells = <0>; | |
| 544 | + compatible = "ti,gate-clock"; | |
| 545 | + clocks = <&clkdiv32k_ick>; | |
| 546 | + ti,bit-shift = <18>; | |
| 547 | + reg = <0x00b4>; | |
| 548 | + }; | |
| 549 | + | |
| 550 | + lcd_gclk: lcd_gclk { | |
| 551 | + #clock-cells = <0>; | |
| 552 | + compatible = "ti,mux-clock"; | |
| 553 | + clocks = <&dpll_disp_m2_ck>, <&dpll_core_m5_ck>, <&dpll_per_m2_ck>; | |
| 554 | + reg = <0x0534>; | |
| 555 | + ti,set-rate-parent; | |
| 556 | + }; | |
| 557 | + | |
| 558 | + mmc_clk: mmc_clk { | |
| 559 | + #clock-cells = <0>; | |
| 560 | + compatible = "fixed-factor-clock"; | |
| 561 | + clocks = <&dpll_per_m2_ck>; | |
| 562 | + clock-mult = <1>; | |
| 563 | + clock-div = <2>; | |
| 564 | + }; | |
| 565 | + | |
| 566 | + gfx_fclk_clksel_ck: gfx_fclk_clksel_ck { | |
| 567 | + #clock-cells = <0>; | |
| 568 | + compatible = "ti,mux-clock"; | |
| 569 | + clocks = <&dpll_core_m4_ck>, <&dpll_per_m2_ck>; | |
| 570 | + ti,bit-shift = <1>; | |
| 571 | + reg = <0x052c>; | |
| 572 | + }; | |
| 573 | + | |
| 574 | + gfx_fck_div_ck: gfx_fck_div_ck { | |
| 575 | + #clock-cells = <0>; | |
| 576 | + compatible = "ti,divider-clock"; | |
| 577 | + clocks = <&gfx_fclk_clksel_ck>; | |
| 578 | + reg = <0x052c>; | |
| 579 | + ti,max-div = <2>; | |
| 580 | + }; | |
| 581 | + | |
| 582 | + sysclkout_pre_ck: sysclkout_pre_ck { | |
| 583 | + #clock-cells = <0>; | |
| 584 | + compatible = "ti,mux-clock"; | |
| 585 | + clocks = <&clk_32768_ck>, <&l3_gclk>, <&dpll_ddr_m2_ck>, <&dpll_per_m2_ck>, <&lcd_gclk>; | |
| 586 | + reg = <0x0700>; | |
| 587 | + }; | |
| 588 | + | |
| 589 | + clkout2_div_ck: clkout2_div_ck { | |
| 590 | + #clock-cells = <0>; | |
| 591 | + compatible = "ti,divider-clock"; | |
| 592 | + clocks = <&sysclkout_pre_ck>; | |
| 593 | + ti,bit-shift = <3>; | |
| 594 | + ti,max-div = <8>; | |
| 595 | + reg = <0x0700>; | |
| 596 | + }; | |
| 597 | + | |
| 598 | + dbg_sysclk_ck: dbg_sysclk_ck { | |
| 599 | + #clock-cells = <0>; | |
| 600 | + compatible = "ti,gate-clock"; | |
| 601 | + clocks = <&sys_clkin_ck>; | |
| 602 | + ti,bit-shift = <19>; | |
| 603 | + reg = <0x0414>; | |
| 604 | + }; | |
| 605 | + | |
| 606 | + dbg_clka_ck: dbg_clka_ck { | |
| 607 | + #clock-cells = <0>; | |
| 608 | + compatible = "ti,gate-clock"; | |
| 609 | + clocks = <&dpll_core_m4_ck>; | |
| 610 | + ti,bit-shift = <30>; | |
| 611 | + reg = <0x0414>; | |
| 612 | + }; | |
| 613 | + | |
| 614 | + stm_pmd_clock_mux_ck: stm_pmd_clock_mux_ck { | |
| 615 | + #clock-cells = <0>; | |
| 616 | + compatible = "ti,mux-clock"; | |
| 617 | + clocks = <&dbg_sysclk_ck>, <&dbg_clka_ck>; | |
| 618 | + ti,bit-shift = <22>; | |
| 619 | + reg = <0x0414>; | |
| 620 | + }; | |
| 621 | + | |
| 622 | + trace_pmd_clk_mux_ck: trace_pmd_clk_mux_ck { | |
| 623 | + #clock-cells = <0>; | |
| 624 | + compatible = "ti,mux-clock"; | |
| 625 | + clocks = <&dbg_sysclk_ck>, <&dbg_clka_ck>; | |
| 626 | + ti,bit-shift = <20>; | |
| 627 | + reg = <0x0414>; | |
| 628 | + }; | |
| 629 | + | |
| 630 | + stm_clk_div_ck: stm_clk_div_ck { | |
| 631 | + #clock-cells = <0>; | |
| 632 | + compatible = "ti,divider-clock"; | |
| 633 | + clocks = <&stm_pmd_clock_mux_ck>; | |
| 634 | + ti,bit-shift = <27>; | |
| 635 | + ti,max-div = <64>; | |
| 636 | + reg = <0x0414>; | |
| 637 | + ti,index-power-of-two; | |
| 638 | + }; | |
| 639 | + | |
| 640 | + trace_clk_div_ck: trace_clk_div_ck { | |
| 641 | + #clock-cells = <0>; | |
| 642 | + compatible = "ti,divider-clock"; | |
| 643 | + clocks = <&trace_pmd_clk_mux_ck>; | |
| 644 | + ti,bit-shift = <24>; | |
| 645 | + ti,max-div = <64>; | |
| 646 | + reg = <0x0414>; | |
| 647 | + ti,index-power-of-two; | |
| 648 | + }; | |
| 649 | + | |
| 650 | + clkout2_ck: clkout2_ck { | |
| 651 | + #clock-cells = <0>; | |
| 652 | + compatible = "ti,gate-clock"; | |
| 653 | + clocks = <&clkout2_div_ck>; | |
| 654 | + ti,bit-shift = <7>; | |
| 655 | + reg = <0x0700>; | |
| 656 | + }; | |
| 657 | +}; | |
| 658 | + | |
| 659 | +&prcm_clockdomains { | |
| 660 | + clk_24mhz_clkdm: clk_24mhz_clkdm { | |
| 661 | + compatible = "ti,clockdomain"; | |
| 662 | + clocks = <&clkdiv32k_ick>; | |
| 663 | + }; | |
| 664 | +}; | |
| @@ -102,6 +102,32 @@ · 101 unmodified lines | ||
| 102 | 102 | ranges; |
| 103 | 103 | ti,hwmods = "l3_main"; |
| 104 | 104 | |
| 105 | + prcm: prcm@44e00000 { | |
| 106 | + compatible = "ti,am3-prcm"; | |
| 107 | + reg = <0x44e00000 0x4000>; | |
| 108 | + | |
| 109 | + prcm_clocks: clocks { | |
| 110 | + #address-cells = <1>; | |
| 111 | + #size-cells = <0>; | |
| 112 | + }; | |
| 113 | + | |
| 114 | + prcm_clockdomains: clockdomains { | |
| 115 | + }; | |
| 116 | + }; | |
| 117 | + | |
| 118 | + scrm: scrm@44e10000 { | |
| 119 | + compatible = "ti,am3-scrm"; | |
| 120 | + reg = <0x44e10000 0x2000>; | |
| 121 | + | |
| 122 | + scrm_clocks: clocks { | |
| 123 | + #address-cells = <1>; | |
| 124 | + #size-cells = <0>; | |
| 125 | + }; | |
| 126 | + | |
| 127 | + scrm_clockdomains: clockdomains { | |
| 128 | + }; | |
| 129 | + }; | |
| 130 | + | |
| 105 | 131 | intc: interrupt-controller@48200000 { |
| 106 | 132 | compatible = "ti,omap2-intc"; |
| 107 | 133 | interrupt-controller; |
| @@ -794,3 +820,5 @@ · 686 unmodified lines | ||
| 794 | 820 | }; |
| 795 | 821 | }; |
| 796 | 822 | }; |
| 823 | + | |
| 824 | +/include/ "am33xx-clocks.dtsi" | |
| @@ -17,6 +17,21 @@ · 16 unmodified lines | ||
| 17 | 17 | device_type = "memory"; |
| 18 | 18 | reg = <0x80000000 0x10000000>; /* 256 MB */ |
| 19 | 19 | }; |
| 20 | + | |
| 21 | + vmmc_fixed: vmmc { | |
| 22 | + compatible = "regulator-fixed"; | |
| 23 | + regulator-name = "vmmc_fixed"; | |
| 24 | + regulator-min-microvolt = <3300000>; | |
| 25 | + regulator-max-microvolt = <3300000>; | |
| 26 | + }; | |
| 27 | +}; | |
| 28 | + | |
| 29 | +&davinci_emac { | |
| 30 | + status = "okay"; | |
| 31 | +}; | |
| 32 | + | |
| 33 | +&davinci_mdio { | |
| 34 | + status = "okay"; | |
| 20 | 35 | }; |
| 21 | 36 | |
| 22 | 37 | &i2c1 { |
| @@ -30,3 +45,17 @@ · 7 unmodified lines | ||
| 30 | 45 | &i2c3 { |
| 31 | 46 | clock-frequency = <400000>; |
| 32 | 47 | }; |
| 48 | + | |
| 49 | +&mmc1 { | |
| 50 | + vmmc-supply = <&vmmc_fixed>; | |
| 51 | + bus-width = <4>; | |
| 52 | +}; | |
| 53 | + | |
| 54 | +&mmc2 { | |
| 55 | + status = "disabled"; | |
| 56 | +}; | |
| 57 | + | |
| 58 | +&mmc3 { | |
| 59 | + status = "disabled"; | |
| 60 | +}; | |
| 61 | + | |
| @@ -61,3 +61,6 @@ · 60 unmodified lines | ||
| 61 | 61 | }; |
| 62 | 62 | }; |
| 63 | 63 | }; |
| 64 | + | |
| 65 | +/include/ "am35xx-clocks.dtsi" | |
| 66 | +/include/ "omap36xx-am35xx-omap3430es2plus-clocks.dtsi" | |
| @@ -0,0 +1,128 @@ | ||
| 1 | +/* | |
| 2 | + * Device Tree Source for OMAP3 clock data | |
| 3 | + * | |
| 4 | + * Copyright (C) 2013 Texas Instruments, Inc. | |
| 5 | + * | |
| 6 | + * This program is free software; you can redistribute it and/or modify | |
| 7 | + * it under the terms of the GNU General Public License version 2 as | |
| 8 | + * published by the Free Software Foundation. | |
| 9 | + */ | |
| 10 | +&scrm_clocks { | |
| 11 | + emac_ick: emac_ick { | |
| 12 | + #clock-cells = <0>; | |
| 13 | + compatible = "ti,am35xx-gate-clock"; | |
| 14 | + clocks = <&ipss_ick>; | |
| 15 | + reg = <0x059c>; | |
| 16 | + ti,bit-shift = <1>; | |
| 17 | + }; | |
| 18 | + | |
| 19 | + emac_fck: emac_fck { | |
| 20 | + #clock-cells = <0>; | |
| 21 | + compatible = "ti,gate-clock"; | |
| 22 | + clocks = <&rmii_ck>; | |
| 23 | + reg = <0x059c>; | |
| 24 | + ti,bit-shift = <9>; | |
| 25 | + }; | |
| 26 | + | |
| 27 | + vpfe_ick: vpfe_ick { | |
| 28 | + #clock-cells = <0>; | |
| 29 | + compatible = "ti,am35xx-gate-clock"; | |
| 30 | + clocks = <&ipss_ick>; | |
| 31 | + reg = <0x059c>; | |
| 32 | + ti,bit-shift = <2>; | |
| 33 | + }; | |
| 34 | + | |
| 35 | + vpfe_fck: vpfe_fck { | |
| 36 | + #clock-cells = <0>; | |
| 37 | + compatible = "ti,gate-clock"; | |
| 38 | + clocks = <&pclk_ck>; | |
| 39 | + reg = <0x059c>; | |
| 40 | + ti,bit-shift = <10>; | |
| 41 | + }; | |
| 42 | + | |
| 43 | + hsotgusb_ick_am35xx: hsotgusb_ick_am35xx { | |
| 44 | + #clock-cells = <0>; | |
| 45 | + compatible = "ti,am35xx-gate-clock"; | |
| 46 | + clocks = <&ipss_ick>; | |
| 47 | + reg = <0x059c>; | |
| 48 | + ti,bit-shift = <0>; | |
| 49 | + }; | |
| 50 | + | |
| 51 | + hsotgusb_fck_am35xx: hsotgusb_fck_am35xx { | |
| 52 | + #clock-cells = <0>; | |
| 53 | + compatible = "ti,gate-clock"; | |
| 54 | + clocks = <&sys_ck>; | |
| 55 | + reg = <0x059c>; | |
| 56 | + ti,bit-shift = <8>; | |
| 57 | + }; | |
| 58 | + | |
| 59 | + hecc_ck: hecc_ck { | |
| 60 | + #clock-cells = <0>; | |
| 61 | + compatible = "ti,am35xx-gate-clock"; | |
| 62 | + clocks = <&sys_ck>; | |
| 63 | + reg = <0x059c>; | |
| 64 | + ti,bit-shift = <3>; | |
| 65 | + }; | |
| 66 | +}; | |
| 67 | +&cm_clocks { | |
| 68 | + ipss_ick: ipss_ick { | |
| 69 | + #clock-cells = <0>; | |
| 70 | + compatible = "ti,am35xx-interface-clock"; | |
| 71 | + clocks = <&core_l3_ick>; | |
| 72 | + reg = <0x0a10>; | |
| 73 | + ti,bit-shift = <4>; | |
| 74 | + }; | |
| 75 | + | |
| 76 | + rmii_ck: rmii_ck { | |
| 77 | + #clock-cells = <0>; | |
| 78 | + compatible = "fixed-clock"; | |
| 79 | + clock-frequency = <50000000>; | |
| 80 | + }; | |
| 81 | + | |
| 82 | + pclk_ck: pclk_ck { | |
| 83 | + #clock-cells = <0>; | |
| 84 | + compatible = "fixed-clock"; | |
| 85 | + clock-frequency = <27000000>; | |
| 86 | + }; | |
| 87 | + | |
| 88 | + uart4_ick_am35xx: uart4_ick_am35xx { | |
| 89 | + #clock-cells = <0>; | |
| 90 | + compatible = "ti,omap3-interface-clock"; | |
| 91 | + clocks = <&core_l4_ick>; | |
| 92 | + reg = <0x0a10>; | |
| 93 | + ti,bit-shift = <23>; | |
| 94 | + }; | |
| 95 | + | |
| 96 | + uart4_fck_am35xx: uart4_fck_am35xx { | |
| 97 | + #clock-cells = <0>; | |
| 98 | + compatible = "ti,wait-gate-clock"; | |
| 99 | + clocks = <&core_48m_fck>; | |
| 100 | + reg = <0x0a00>; | |
| 101 | + ti,bit-shift = <23>; | |
| 102 | + }; | |
| 103 | +}; | |
| 104 | + | |
| 105 | +&cm_clockdomains { | |
| 106 | + core_l3_clkdm: core_l3_clkdm { | |
| 107 | + compatible = "ti,clockdomain"; | |
| 108 | + clocks = <&sdrc_ick>, <&ipss_ick>, <&emac_ick>, <&vpfe_ick>, | |
| 109 | + <&hsotgusb_ick_am35xx>, <&hsotgusb_fck_am35xx>, | |
| 110 | + <&hecc_ck>; | |
| 111 | + }; | |
| 112 | + | |
| 113 | + core_l4_clkdm: core_l4_clkdm { | |
| 114 | + compatible = "ti,clockdomain"; | |
| 115 | + clocks = <&cpefuse_fck>, <&ts_fck>, <&usbtll_fck>, | |
| 116 | + <&usbtll_ick>, <&mmchs3_ick>, <&mmchs3_fck>, | |
| 117 | + <&mmchs2_fck>, <&mmchs1_fck>, <&i2c3_fck>, <&i2c2_fck>, | |
| 118 | + <&i2c1_fck>, <&mcspi4_fck>, <&mcspi3_fck>, | |
| 119 | + <&mcspi2_fck>, <&mcspi1_fck>, <&uart2_fck>, | |
| 120 | + <&uart1_fck>, <&hdq_fck>, <&mmchs2_ick>, <&mmchs1_ick>, | |
| 121 | + <&hdq_ick>, <&mcspi4_ick>, <&mcspi3_ick>, | |
| 122 | + <&mcspi2_ick>, <&mcspi1_ick>, <&i2c3_ick>, <&i2c2_ick>, | |
| 123 | + <&i2c1_ick>, <&uart2_ick>, <&uart1_ick>, <&gpt11_ick>, | |
| 124 | + <&gpt10_ick>, <&mcbsp5_ick>, <&mcbsp1_ick>, | |
| 125 | + <&omapctrl_ick>, <&aes2_ick>, <&sha12_ick>, | |
| 126 | + <&uart4_ick_am35xx>, <&uart4_fck_am35xx>; | |
| 127 | + }; | |
| 128 | +}; | |
| @@ -67,6 +67,32 @@ · 66 unmodified lines | ||
| 67 | 67 | ranges; |
| 68 | 68 | ti,hwmods = "l3_main"; |
| 69 | 69 | |
| 70 | + prcm: prcm@44df0000 { | |
| 71 | + compatible = "ti,am4-prcm"; | |
| 72 | + reg = <0x44df0000 0x11000>; | |
| 73 | + | |
| 74 | + prcm_clocks: clocks { | |
| 75 | + #address-cells = <1>; | |
| 76 | + #size-cells = <0>; | |
| 77 | + }; | |
| 78 | + | |
| 79 | + prcm_clockdomains: clockdomains { | |
| 80 | + }; | |
| 81 | + }; | |
| 82 | + | |
| 83 | + scrm: scrm@44e10000 { | |
| 84 | + compatible = "ti,am4-scrm"; | |
| 85 | + reg = <0x44e10000 0x2000>; | |
| 86 | + | |
| 87 | + scrm_clocks: clocks { | |
| 88 | + #address-cells = <1>; | |
| 89 | + #size-cells = <0>; | |
| 90 | + }; | |
| 91 | + | |
| 92 | + scrm_clockdomains: clockdomains { | |
| 93 | + }; | |
| 94 | + }; | |
| 95 | + | |
| 70 | 96 | edma: edma@49000000 { |
| 71 | 97 | compatible = "ti,edma3"; |
| 72 | 98 | ti,hwmods = "tpcc", "tptc0", "tptc1", "tptc2"; |
| @@ -665,3 +691,5 @@ · 592 unmodified lines | ||
| 665 | 691 | }; |
| 666 | 692 | }; |
| 667 | 693 | }; |
| 694 | + | |
| 695 | +/include/ "am43xx-clocks.dtsi" | |
| @@ -0,0 +1,656 @@ | ||
| 1 | +/* | |
| 2 | + * Device Tree Source for AM43xx clock data | |
| 3 | + * | |
| 4 | + * Copyright (C) 2013 Texas Instruments, Inc. | |
| 5 | + * | |
| 6 | + * This program is free software; you can redistribute it and/or modify | |
| 7 | + * it under the terms of the GNU General Public License version 2 as | |
| 8 | + * published by the Free Software Foundation. | |
| 9 | + */ | |
| 10 | +&scrm_clocks { | |
| 11 | + sys_clkin_ck: sys_clkin_ck { | |
| 12 | + #clock-cells = <0>; | |
| 13 | + compatible = "ti,mux-clock"; | |
| 14 | + clocks = <&virt_19200000_ck>, <&virt_24000000_ck>, <&virt_25000000_ck>, <&virt_26000000_ck>; | |
| 15 | + ti,bit-shift = <22>; | |
| 16 | + reg = <0x0040>; | |
| 17 | + }; | |
| 18 | + | |
| 19 | + adc_tsc_fck: adc_tsc_fck { | |
| 20 | + #clock-cells = <0>; | |
| 21 | + compatible = "fixed-factor-clock"; | |
| 22 | + clocks = <&sys_clkin_ck>; | |
| 23 | + clock-mult = <1>; | |
| 24 | + clock-div = <1>; | |
| 25 | + }; | |
| 26 | + | |
| 27 | + dcan0_fck: dcan0_fck { | |
| 28 | + #clock-cells = <0>; | |
| 29 | + compatible = "fixed-factor-clock"; | |
| 30 | + clocks = <&sys_clkin_ck>; | |
| 31 | + clock-mult = <1>; | |
| 32 | + clock-div = <1>; | |
| 33 | + }; | |
| 34 | + | |
| 35 | + dcan1_fck: dcan1_fck { | |
| 36 | + #clock-cells = <0>; | |
| 37 | + compatible = "fixed-factor-clock"; | |
| 38 | + clocks = <&sys_clkin_ck>; | |
| 39 | + clock-mult = <1>; | |
| 40 | + clock-div = <1>; | |
| 41 | + }; | |
| 42 | + | |
| 43 | + mcasp0_fck: mcasp0_fck { | |
| 44 | + #clock-cells = <0>; | |
| 45 | + compatible = "fixed-factor-clock"; | |
| 46 | + clocks = <&sys_clkin_ck>; | |
| 47 | + clock-mult = <1>; | |
| 48 | + clock-div = <1>; | |
| 49 | + }; | |
| 50 | + | |
| 51 | + mcasp1_fck: mcasp1_fck { | |
| 52 | + #clock-cells = <0>; | |
| 53 | + compatible = "fixed-factor-clock"; | |
| 54 | + clocks = <&sys_clkin_ck>; | |
| 55 | + clock-mult = <1>; | |
| 56 | + clock-div = <1>; | |
| 57 | + }; | |
| 58 | + | |
| 59 | + smartreflex0_fck: smartreflex0_fck { | |
| 60 | + #clock-cells = <0>; | |
| 61 | + compatible = "fixed-factor-clock"; | |
| 62 | + clocks = <&sys_clkin_ck>; | |
| 63 | + clock-mult = <1>; | |
| 64 | + clock-div = <1>; | |
| 65 | + }; | |
| 66 | + | |
| 67 | + smartreflex1_fck: smartreflex1_fck { | |
| 68 | + #clock-cells = <0>; | |
| 69 | + compatible = "fixed-factor-clock"; | |
| 70 | + clocks = <&sys_clkin_ck>; | |
| 71 | + clock-mult = <1>; | |
| 72 | + clock-div = <1>; | |
| 73 | + }; | |
| 74 | + | |
| 75 | + sha0_fck: sha0_fck { | |
| 76 | + #clock-cells = <0>; | |
| 77 | + compatible = "fixed-factor-clock"; | |
| 78 | + clocks = <&sys_clkin_ck>; | |
| 79 | + clock-mult = <1>; | |
| 80 | + clock-div = <1>; | |
| 81 | + }; | |
| 82 | + | |
| 83 | + aes0_fck: aes0_fck { | |
| 84 | + #clock-cells = <0>; | |
| 85 | + compatible = "fixed-factor-clock"; | |
| 86 | + clocks = <&sys_clkin_ck>; | |
| 87 | + clock-mult = <1>; | |
| 88 | + clock-div = <1>; | |
| 89 | + }; | |
| 90 | +}; | |
| 91 | +&prcm_clocks { | |
| 92 | + clk_32768_ck: clk_32768_ck { | |
| 93 | + #clock-cells = <0>; | |
| 94 | + compatible = "fixed-clock"; | |
| 95 | + clock-frequency = <32768>; | |
| 96 | + }; | |
| 97 | + | |
| 98 | + clk_rc32k_ck: clk_rc32k_ck { | |
| 99 | + #clock-cells = <0>; | |
| 100 | + compatible = "fixed-clock"; | |
| 101 | + clock-frequency = <32768>; | |
| 102 | + }; | |
| 103 | + | |
| 104 | + virt_19200000_ck: virt_19200000_ck { | |
| 105 | + #clock-cells = <0>; | |
| 106 | + compatible = "fixed-clock"; | |
| 107 | + clock-frequency = <19200000>; | |
| 108 | + }; | |
| 109 | + | |
| 110 | + virt_24000000_ck: virt_24000000_ck { | |
| 111 | + #clock-cells = <0>; | |
| 112 | + compatible = "fixed-clock"; | |
| 113 | + clock-frequency = <24000000>; | |
| 114 | + }; | |
| 115 | + | |
| 116 | + virt_25000000_ck: virt_25000000_ck { | |
| 117 | + #clock-cells = <0>; | |
| 118 | + compatible = "fixed-clock"; | |
| 119 | + clock-frequency = <25000000>; | |
| 120 | + }; | |
| 121 | + | |
| 122 | + virt_26000000_ck: virt_26000000_ck { | |
| 123 | + #clock-cells = <0>; | |
| 124 | + compatible = "fixed-clock"; | |
| 125 | + clock-frequency = <26000000>; | |
| 126 | + }; | |
| 127 | + | |
| 128 | + tclkin_ck: tclkin_ck { | |
| 129 | + #clock-cells = <0>; | |
| 130 | + compatible = "fixed-clock"; | |
| 131 | + clock-frequency = <26000000>; | |
| 132 | + }; | |
| 133 | + | |
| 134 | + dpll_core_ck: dpll_core_ck { | |
| 135 | + #clock-cells = <0>; | |
| 136 | + compatible = "ti,am3-dpll-core-clock"; | |
| 137 | + clocks = <&sys_clkin_ck>, <&sys_clkin_ck>; | |
| 138 | + reg = <0x2d20>, <0x2d24>, <0x2d2c>; | |
| 139 | + }; | |
| 140 | + | |
| 141 | + dpll_core_x2_ck: dpll_core_x2_ck { | |
| 142 | + #clock-cells = <0>; | |
| 143 | + compatible = "ti,am3-dpll-x2-clock"; | |
| 144 | + clocks = <&dpll_core_ck>; | |
| 145 | + }; | |
| 146 | + | |
| 147 | + dpll_core_m4_ck: dpll_core_m4_ck { | |
| 148 | + #clock-cells = <0>; | |
| 149 | + compatible = "ti,divider-clock"; | |
| 150 | + clocks = <&dpll_core_x2_ck>; | |
| 151 | + ti,max-div = <31>; | |
| 152 | + ti,autoidle-shift = <8>; | |
| 153 | + reg = <0x2d38>; | |
| 154 | + ti,index-starts-at-one; | |
| 155 | + ti,invert-autoidle-bit; | |
| 156 | + }; | |
| 157 | + | |
| 158 | + dpll_core_m5_ck: dpll_core_m5_ck { | |
| 159 | + #clock-cells = <0>; | |
| 160 | + compatible = "ti,divider-clock"; | |
| 161 | + clocks = <&dpll_core_x2_ck>; | |
| 162 | + ti,max-div = <31>; | |
| 163 | + ti,autoidle-shift = <8>; | |
| 164 | + reg = <0x2d3c>; | |
| 165 | + ti,index-starts-at-one; | |
| 166 | + ti,invert-autoidle-bit; | |
| 167 | + }; | |
| 168 | + | |
| 169 | + dpll_core_m6_ck: dpll_core_m6_ck { | |
| 170 | + #clock-cells = <0>; | |
| 171 | + compatible = "ti,divider-clock"; | |
| 172 | + clocks = <&dpll_core_x2_ck>; | |
| 173 | + ti,max-div = <31>; | |
| 174 | + ti,autoidle-shift = <8>; | |
| 175 | + reg = <0x2d40>; | |
| 176 | + ti,index-starts-at-one; | |
| 177 | + ti,invert-autoidle-bit; | |
| 178 | + }; | |
| 179 | + | |
| 180 | + dpll_mpu_ck: dpll_mpu_ck { | |
| 181 | + #clock-cells = <0>; | |
| 182 | + compatible = "ti,am3-dpll-clock"; | |
| 183 | + clocks = <&sys_clkin_ck>, <&sys_clkin_ck>; | |
| 184 | + reg = <0x2d60>, <0x2d64>, <0x2d6c>; | |
| 185 | + }; | |
| 186 | + | |
| 187 | + dpll_mpu_m2_ck: dpll_mpu_m2_ck { | |
| 188 | + #clock-cells = <0>; | |
| 189 | + compatible = "ti,divider-clock"; | |
| 190 | + clocks = <&dpll_mpu_ck>; | |
| 191 | + ti,max-div = <31>; | |
| 192 | + ti,autoidle-shift = <8>; | |
| 193 | + reg = <0x2d70>; | |
| 194 | + ti,index-starts-at-one; | |
| 195 | + ti,invert-autoidle-bit; | |
| 196 | + }; | |
| 197 | + | |
| 198 | + dpll_ddr_ck: dpll_ddr_ck { | |
| 199 | + #clock-cells = <0>; | |
| 200 | + compatible = "ti,am3-dpll-clock"; | |
| 201 | + clocks = <&sys_clkin_ck>, <&sys_clkin_ck>; | |
| 202 | + reg = <0x2da0>, <0x2da4>, <0x2dac>; | |
| 203 | + }; | |
| 204 | + | |
| 205 | + dpll_ddr_m2_ck: dpll_ddr_m2_ck { | |
| 206 | + #clock-cells = <0>; | |
| 207 | + compatible = "ti,divider-clock"; | |
| 208 | + clocks = <&dpll_ddr_ck>; | |
| 209 | + ti,max-div = <31>; | |
| 210 | + ti,autoidle-shift = <8>; | |
| 211 | + reg = <0x2db0>; | |
| 212 | + ti,index-starts-at-one; | |
| 213 | + ti,invert-autoidle-bit; | |
| 214 | + }; | |
| 215 | + | |
| 216 | + dpll_disp_ck: dpll_disp_ck { | |
| 217 | + #clock-cells = <0>; | |
| 218 | + compatible = "ti,am3-dpll-clock"; | |
| 219 | + clocks = <&sys_clkin_ck>, <&sys_clkin_ck>; | |
| 220 | + reg = <0x2e20>, <0x2e24>, <0x2e2c>; | |
| 221 | + }; | |
| 222 | + | |
| 223 | + dpll_disp_m2_ck: dpll_disp_m2_ck { | |
| 224 | + #clock-cells = <0>; | |
| 225 | + compatible = "ti,divider-clock"; | |
| 226 | + clocks = <&dpll_disp_ck>; | |
| 227 | + ti,max-div = <31>; | |
| 228 | + ti,autoidle-shift = <8>; | |
| 229 | + reg = <0x2e30>; | |
| 230 | + ti,index-starts-at-one; | |
| 231 | + ti,invert-autoidle-bit; | |
| 232 | + }; | |
| 233 | + | |
| 234 | + dpll_per_ck: dpll_per_ck { | |
| 235 | + #clock-cells = <0>; | |
| 236 | + compatible = "ti,am3-dpll-j-type-clock"; | |
| 237 | + clocks = <&sys_clkin_ck>, <&sys_clkin_ck>; | |
| 238 | + reg = <0x2de0>, <0x2de4>, <0x2dec>; | |
| 239 | + }; | |
| 240 | + | |
| 241 | + dpll_per_m2_ck: dpll_per_m2_ck { | |
| 242 | + #clock-cells = <0>; | |
| 243 | + compatible = "ti,divider-clock"; | |
| 244 | + clocks = <&dpll_per_ck>; | |
| 245 | + ti,max-div = <127>; | |
| 246 | + ti,autoidle-shift = <8>; | |
| 247 | + reg = <0x2df0>; | |
| 248 | + ti,index-starts-at-one; | |
| 249 | + ti,invert-autoidle-bit; | |
| 250 | + }; | |
| 251 | + | |
| 252 | + dpll_per_m2_div4_wkupdm_ck: dpll_per_m2_div4_wkupdm_ck { | |
| 253 | + #clock-cells = <0>; | |
| 254 | + compatible = "fixed-factor-clock"; | |
| 255 | + clocks = <&dpll_per_m2_ck>; | |
| 256 | + clock-mult = <1>; | |
| 257 | + clock-div = <4>; | |
| 258 | + }; | |
| 259 | + | |
| 260 | + dpll_per_m2_div4_ck: dpll_per_m2_div4_ck { | |
| 261 | + #clock-cells = <0>; | |
| 262 | + compatible = "fixed-factor-clock"; | |
| 263 | + clocks = <&dpll_per_m2_ck>; | |
| 264 | + clock-mult = <1>; | |
| 265 | + clock-div = <4>; | |
| 266 | + }; | |
| 267 | + | |
| 268 | + clk_24mhz: clk_24mhz { | |
| 269 | + #clock-cells = <0>; | |
| 270 | + compatible = "fixed-factor-clock"; | |
| 271 | + clocks = <&dpll_per_m2_ck>; | |
| 272 | + clock-mult = <1>; | |
| 273 | + clock-div = <8>; | |
| 274 | + }; | |
| 275 | + | |
| 276 | + clkdiv32k_ck: clkdiv32k_ck { | |
| 277 | + #clock-cells = <0>; | |
| 278 | + compatible = "fixed-factor-clock"; | |
| 279 | + clocks = <&clk_24mhz>; | |
| 280 | + clock-mult = <1>; | |
| 281 | + clock-div = <732>; | |
| 282 | + }; | |
| 283 | + | |
| 284 | + clkdiv32k_ick: clkdiv32k_ick { | |
| 285 | + #clock-cells = <0>; | |
| 286 | + compatible = "ti,gate-clock"; | |
| 287 | + clocks = <&clkdiv32k_ck>; | |
| 288 | + ti,bit-shift = <8>; | |
| 289 | + reg = <0x2a38>; | |
| 290 | + }; | |
| 291 | + | |
| 292 | + sysclk_div: sysclk_div { | |
| 293 | + #clock-cells = <0>; | |
| 294 | + compatible = "fixed-factor-clock"; | |
| 295 | + clocks = <&dpll_core_m4_ck>; | |
| 296 | + clock-mult = <1>; | |
| 297 | + clock-div = <1>; | |
| 298 | + }; | |
| 299 | + | |
| 300 | + pruss_ocp_gclk: pruss_ocp_gclk { | |
| 301 | + #clock-cells = <0>; | |
| 302 | + compatible = "ti,mux-clock"; | |
| 303 | + clocks = <&sysclk_div>, <&dpll_disp_m2_ck>; | |
| 304 | + reg = <0x4248>; | |
| 305 | + }; | |
| 306 | + | |
| 307 | + clk_32k_tpm_ck: clk_32k_tpm_ck { | |
| 308 | + #clock-cells = <0>; | |
| 309 | + compatible = "fixed-clock"; | |
| 310 | + clock-frequency = <32768>; | |
| 311 | + }; | |
| 312 | + | |
| 313 | + timer1_fck: timer1_fck { | |
| 314 | + #clock-cells = <0>; | |
| 315 | + compatible = "ti,mux-clock"; | |
| 316 | + clocks = <&sys_clkin_ck>, <&clkdiv32k_ick>, <&tclkin_ck>, <&clk_rc32k_ck>, <&clk_32768_ck>, <&clk_32k_tpm_ck>; | |
| 317 | + reg = <0x4200>; | |
| 318 | + }; | |
| 319 | + | |
| 320 | + timer2_fck: timer2_fck { | |
| 321 | + #clock-cells = <0>; | |
| 322 | + compatible = "ti,mux-clock"; | |
| 323 | + clocks = <&tclkin_ck>, <&sys_clkin_ck>, <&clkdiv32k_ick>; | |
| 324 | + reg = <0x4204>; | |
| 325 | + }; | |
| 326 | + | |
| 327 | + timer3_fck: timer3_fck { | |
| 328 | + #clock-cells = <0>; | |
| 329 | + compatible = "ti,mux-clock"; | |
| 330 | + clocks = <&tclkin_ck>, <&sys_clkin_ck>, <&clkdiv32k_ick>; | |
| 331 | + reg = <0x4208>; | |
| 332 | + }; | |
| 333 | + | |
| 334 | + timer4_fck: timer4_fck { | |
| 335 | + #clock-cells = <0>; | |
| 336 | + compatible = "ti,mux-clock"; | |
| 337 | + clocks = <&tclkin_ck>, <&sys_clkin_ck>, <&clkdiv32k_ick>; | |
| 338 | + reg = <0x420c>; | |
| 339 | + }; | |
| 340 | + | |
| 341 | + timer5_fck: timer5_fck { | |
| 342 | + #clock-cells = <0>; | |
| 343 | + compatible = "ti,mux-clock"; | |
| 344 | + clocks = <&tclkin_ck>, <&sys_clkin_ck>, <&clkdiv32k_ick>; | |
| 345 | + reg = <0x4210>; | |
| 346 | + }; | |
| 347 | + | |
| 348 | + timer6_fck: timer6_fck { | |
| 349 | + #clock-cells = <0>; | |
| 350 | + compatible = "ti,mux-clock"; | |
| 351 | + clocks = <&tclkin_ck>, <&sys_clkin_ck>, <&clkdiv32k_ick>; | |
| 352 | + reg = <0x4214>; | |
| 353 | + }; | |
| 354 | + | |
| 355 | + timer7_fck: timer7_fck { | |
| 356 | + #clock-cells = <0>; | |
| 357 | + compatible = "ti,mux-clock"; | |
| 358 | + clocks = <&tclkin_ck>, <&sys_clkin_ck>, <&clkdiv32k_ick>; | |
| 359 | + reg = <0x4218>; | |
| 360 | + }; | |
| 361 | + | |
| 362 | + wdt1_fck: wdt1_fck { | |
| 363 | + #clock-cells = <0>; | |
| 364 | + compatible = "ti,mux-clock"; | |
| 365 | + clocks = <&clk_rc32k_ck>, <&clkdiv32k_ick>; | |
| 366 | + reg = <0x422c>; | |
| 367 | + }; | |
| 368 | + | |
| 369 | + l3_gclk: l3_gclk { | |
| 370 | + #clock-cells = <0>; | |
| 371 | + compatible = "fixed-factor-clock"; | |
| 372 | + clocks = <&dpll_core_m4_ck>; | |
| 373 | + clock-mult = <1>; | |
| 374 | + clock-div = <1>; | |
| 375 | + }; | |
| 376 | + | |
| 377 | + dpll_core_m4_div2_ck: dpll_core_m4_div2_ck { | |
| 378 | + #clock-cells = <0>; | |
| 379 | + compatible = "fixed-factor-clock"; | |
| 380 | + clocks = <&sysclk_div>; | |
| 381 | + clock-mult = <1>; | |
| 382 | + clock-div = <2>; | |
| 383 | + }; | |
| 384 | + | |
| 385 | + l4hs_gclk: l4hs_gclk { | |
| 386 | + #clock-cells = <0>; | |
| 387 | + compatible = "fixed-factor-clock"; | |
| 388 | + clocks = <&dpll_core_m4_ck>; | |
| 389 | + clock-mult = <1>; | |
| 390 | + clock-div = <1>; | |
| 391 | + }; | |
| 392 | + | |
| 393 | + l3s_gclk: l3s_gclk { | |
| 394 | + #clock-cells = <0>; | |
| 395 | + compatible = "fixed-factor-clock"; | |
| 396 | + clocks = <&dpll_core_m4_div2_ck>; | |
| 397 | + clock-mult = <1>; | |
| 398 | + clock-div = <1>; | |
| 399 | + }; | |
| 400 | + | |
| 401 | + l4ls_gclk: l4ls_gclk { | |
| 402 | + #clock-cells = <0>; | |
| 403 | + compatible = "fixed-factor-clock"; | |
| 404 | + clocks = <&dpll_core_m4_div2_ck>; | |
| 405 | + clock-mult = <1>; | |
| 406 | + clock-div = <1>; | |
| 407 | + }; | |
| 408 | + | |
| 409 | + cpsw_125mhz_gclk: cpsw_125mhz_gclk { | |
| 410 | + #clock-cells = <0>; | |
| 411 | + compatible = "fixed-factor-clock"; | |
| 412 | + clocks = <&dpll_core_m5_ck>; | |
| 413 | + clock-mult = <1>; | |
| 414 | + clock-div = <2>; | |
| 415 | + }; | |
| 416 | + | |
| 417 | + cpsw_cpts_rft_clk: cpsw_cpts_rft_clk { | |
| 418 | + #clock-cells = <0>; | |
| 419 | + compatible = "ti,mux-clock"; | |
| 420 | + clocks = <&sysclk_div>, <&dpll_core_m5_ck>, <&dpll_disp_m2_ck>; | |
| 421 | + reg = <0x4238>; | |
| 422 | + }; | |
| 423 | + | |
| 424 | + clk_32k_mosc_ck: clk_32k_mosc_ck { | |
| 425 | + #clock-cells = <0>; | |
| 426 | + compatible = "fixed-clock"; | |
| 427 | + clock-frequency = <32768>; | |
| 428 | + }; | |
| 429 | + | |
| 430 | + gpio0_dbclk_mux_ck: gpio0_dbclk_mux_ck { | |
| 431 | + #clock-cells = <0>; | |
| 432 | + compatible = "ti,mux-clock"; | |
| 433 | + clocks = <&clk_rc32k_ck>, <&clk_32768_ck>, <&clkdiv32k_ick>, <&clk_32k_mosc_ck>, <&clk_32k_tpm_ck>; | |
| 434 | + reg = <0x4240>; | |
| 435 | + }; | |
| 436 | + | |
| 437 | + gpio0_dbclk: gpio0_dbclk { | |
| 438 | + #clock-cells = <0>; | |
| 439 | + compatible = "ti,gate-clock"; | |
| 440 | + clocks = <&gpio0_dbclk_mux_ck>; | |
| 441 | + ti,bit-shift = <8>; | |
| 442 | + reg = <0x2b68>; | |
| 443 | + }; | |
| 444 | + | |
| 445 | + gpio1_dbclk: gpio1_dbclk { | |
| 446 | + #clock-cells = <0>; | |
| 447 | + compatible = "ti,gate-clock"; | |
| 448 | + clocks = <&clkdiv32k_ick>; | |
| 449 | + ti,bit-shift = <8>; | |
| 450 | + reg = <0x8c78>; | |
| 451 | + }; | |
| 452 | + | |
| 453 | + gpio2_dbclk: gpio2_dbclk { | |
| 454 | + #clock-cells = <0>; | |
| 455 | + compatible = "ti,gate-clock"; | |
| 456 | + clocks = <&clkdiv32k_ick>; | |
| 457 | + ti,bit-shift = <8>; | |
| 458 | + reg = <0x8c80>; | |
| 459 | + }; | |
| 460 | + | |
| 461 | + gpio3_dbclk: gpio3_dbclk { | |
| 462 | + #clock-cells = <0>; | |
| 463 | + compatible = "ti,gate-clock"; | |
| 464 | + clocks = <&clkdiv32k_ick>; | |
| 465 | + ti,bit-shift = <8>; | |
| 466 | + reg = <0x8c88>; | |
| 467 | + }; | |
| 468 | + | |
| 469 | + gpio4_dbclk: gpio4_dbclk { | |
| 470 | + #clock-cells = <0>; | |
| 471 | + compatible = "ti,gate-clock"; | |
| 472 | + clocks = <&clkdiv32k_ick>; | |
| 473 | + ti,bit-shift = <8>; | |
| 474 | + reg = <0x8c90>; | |
| 475 | + }; | |
| 476 | + | |
| 477 | + gpio5_dbclk: gpio5_dbclk { | |
| 478 | + #clock-cells = <0>; | |
| 479 | + compatible = "ti,gate-clock"; | |
| 480 | + clocks = <&clkdiv32k_ick>; | |
| 481 | + ti,bit-shift = <8>; | |
| 482 | + reg = <0x8c98>; | |
| 483 | + }; | |
| 484 | + | |
| 485 | + mmc_clk: mmc_clk { | |
| 486 | + #clock-cells = <0>; | |
| 487 | + compatible = "fixed-factor-clock"; | |
| 488 | + clocks = <&dpll_per_m2_ck>; | |
| 489 | + clock-mult = <1>; | |
| 490 | + clock-div = <2>; | |
| 491 | + }; | |
| 492 | + | |
| 493 | + gfx_fclk_clksel_ck: gfx_fclk_clksel_ck { | |
| 494 | + #clock-cells = <0>; | |
| 495 | + compatible = "ti,mux-clock"; | |
| 496 | + clocks = <&sysclk_div>, <&dpll_per_m2_ck>; | |
| 497 | + ti,bit-shift = <1>; | |
| 498 | + reg = <0x423c>; | |
| 499 | + }; | |
| 500 | + | |
| 501 | + gfx_fck_div_ck: gfx_fck_div_ck { | |
| 502 | + #clock-cells = <0>; | |
| 503 | + compatible = "ti,divider-clock"; | |
| 504 | + clocks = <&gfx_fclk_clksel_ck>; | |
| 505 | + reg = <0x423c>; | |
| 506 | + ti,max-div = <2>; | |
| 507 | + }; | |
| 508 | + | |
| 509 | + disp_clk: disp_clk { | |
| 510 | + #clock-cells = <0>; | |
| 511 | + compatible = "ti,mux-clock"; | |
| 512 | + clocks = <&dpll_disp_m2_ck>, <&dpll_core_m5_ck>, <&dpll_per_m2_ck>; | |
| 513 | + reg = <0x4244>; | |
| 514 | + }; | |
| 515 | + | |
| 516 | + dpll_extdev_ck: dpll_extdev_ck { | |
| 517 | + #clock-cells = <0>; | |
| 518 | + compatible = "ti,am3-dpll-clock"; | |
| 519 | + clocks = <&sys_clkin_ck>, <&sys_clkin_ck>; | |
| 520 | + reg = <0x2e60>, <0x2e64>, <0x2e6c>; | |
| 521 | + }; | |
| 522 | + | |
| 523 | + dpll_extdev_m2_ck: dpll_extdev_m2_ck { | |
| 524 | + #clock-cells = <0>; | |
| 525 | + compatible = "ti,divider-clock"; | |
| 526 | + clocks = <&dpll_extdev_ck>; | |
| 527 | + ti,max-div = <127>; | |
| 528 | + ti,autoidle-shift = <8>; | |
| 529 | + reg = <0x2e70>; | |
| 530 | + ti,index-starts-at-one; | |
| 531 | + ti,invert-autoidle-bit; | |
| 532 | + }; | |
| 533 | + | |
| 534 | + mux_synctimer32k_ck: mux_synctimer32k_ck { | |
| 535 | + #clock-cells = <0>; | |
| 536 | + compatible = "ti,mux-clock"; | |
| 537 | + clocks = <&clk_32768_ck>, <&clk_32k_tpm_ck>, <&clkdiv32k_ick>; | |
| 538 | + reg = <0x4230>; | |
| 539 | + }; | |
| 540 | + | |
| 541 | + synctimer_32kclk: synctimer_32kclk { | |
| 542 | + #clock-cells = <0>; | |
| 543 | + compatible = "ti,gate-clock"; | |
| 544 | + clocks = <&mux_synctimer32k_ck>; | |
| 545 | + ti,bit-shift = <8>; | |
| 546 | + reg = <0x2a30>; | |
| 547 | + }; | |
| 548 | + | |
| 549 | + timer8_fck: timer8_fck { | |
| 550 | + #clock-cells = <0>; | |
| 551 | + compatible = "ti,mux-clock"; | |
| 552 | + clocks = <&tclkin_ck>, <&sys_clkin_ck>, <&clkdiv32k_ick>, <&clk_32k_tpm_ck>; | |
| 553 | + reg = <0x421c>; | |
| 554 | + }; | |
| 555 | + | |
| 556 | + timer9_fck: timer9_fck { | |
| 557 | + #clock-cells = <0>; | |
| 558 | + compatible = "ti,mux-clock"; | |
| 559 | + clocks = <&tclkin_ck>, <&sys_clkin_ck>, <&clkdiv32k_ick>, <&clk_32k_tpm_ck>; | |
| 560 | + reg = <0x4220>; | |
| 561 | + }; | |
| 562 | + | |
| 563 | + timer10_fck: timer10_fck { | |
| 564 | + #clock-cells = <0>; | |
| 565 | + compatible = "ti,mux-clock"; | |
| 566 | + clocks = <&tclkin_ck>, <&sys_clkin_ck>, <&clkdiv32k_ick>, <&clk_32k_tpm_ck>; | |
| 567 | + reg = <0x4224>; | |
| 568 | + }; | |
| 569 | + | |
| 570 | + timer11_fck: timer11_fck { | |
| 571 | + #clock-cells = <0>; | |
| 572 | + compatible = "ti,mux-clock"; | |
| 573 | + clocks = <&tclkin_ck>, <&sys_clkin_ck>, <&clkdiv32k_ick>, <&clk_32k_tpm_ck>; | |
| 574 | + reg = <0x4228>; | |
| 575 | + }; | |
| 576 | + | |
| 577 | + cpsw_50m_clkdiv: cpsw_50m_clkdiv { | |
| 578 | + #clock-cells = <0>; | |
| 579 | + compatible = "fixed-factor-clock"; | |
| 580 | + clocks = <&dpll_core_m5_ck>; | |
| 581 | + clock-mult = <1>; | |
| 582 | + clock-div = <1>; | |
| 583 | + }; | |
| 584 | + | |
| 585 | + cpsw_5m_clkdiv: cpsw_5m_clkdiv { | |
| 586 | + #clock-cells = <0>; | |
| 587 | + compatible = "fixed-factor-clock"; | |
| 588 | + clocks = <&cpsw_50m_clkdiv>; | |
| 589 | + clock-mult = <1>; | |
| 590 | + clock-div = <10>; | |
| 591 | + }; | |
| 592 | + | |
| 593 | + dpll_ddr_x2_ck: dpll_ddr_x2_ck { | |
| 594 | + #clock-cells = <0>; | |
| 595 | + compatible = "ti,am3-dpll-x2-clock"; | |
| 596 | + clocks = <&dpll_ddr_ck>; | |
| 597 | + }; | |
| 598 | + | |
| 599 | + dpll_ddr_m4_ck: dpll_ddr_m4_ck { | |
| 600 | + #clock-cells = <0>; | |
| 601 | + compatible = "ti,divider-clock"; | |
| 602 | + clocks = <&dpll_ddr_x2_ck>; | |
| 603 | + ti,max-div = <31>; | |
| 604 | + ti,autoidle-shift = <8>; | |
| 605 | + reg = <0x2db8>; | |
| 606 | + ti,index-starts-at-one; | |
| 607 | + ti,invert-autoidle-bit; | |
| 608 | + }; | |
| 609 | + | |
| 610 | + dpll_per_clkdcoldo: dpll_per_clkdcoldo { | |
| 611 | + #clock-cells = <0>; | |
| 612 | + compatible = "fixed-factor-clock"; | |
| 613 | + clocks = <&dpll_per_ck>; | |
| 614 | + clock-mult = <1>; | |
| 615 | + clock-div = <1>; | |
| 616 | + }; | |
| 617 | + | |
| 618 | + dll_aging_clk_div: dll_aging_clk_div { | |
| 619 | + #clock-cells = <0>; | |
| 620 | + compatible = "ti,divider-clock"; | |
| 621 | + clocks = <&sys_clkin_ck>; | |
| 622 | + reg = <0x4250>; | |
| 623 | + ti,dividers = <8>, <16>, <32>; | |
| 624 | + }; | |
| 625 | + | |
| 626 | + div_core_25m_ck: div_core_25m_ck { | |
| 627 | + #clock-cells = <0>; | |
| 628 | + compatible = "fixed-factor-clock"; | |
| 629 | + clocks = <&sysclk_div>; | |
| 630 | + clock-mult = <1>; | |
| 631 | + clock-div = <8>; | |
| 632 | + }; | |
| 633 | + | |
| 634 | + func_12m_clk: func_12m_clk { | |
| 635 | + #clock-cells = <0>; | |
| 636 | + compatible = "fixed-factor-clock"; | |
| 637 | + clocks = <&dpll_per_m2_ck>; | |
| 638 | + clock-mult = <1>; | |
| 639 | + clock-div = <16>; | |
| 640 | + }; | |
| 641 | + | |
| 642 | + vtp_clk_div: vtp_clk_div { | |
| 643 | + #clock-cells = <0>; | |
| 644 | + compatible = "fixed-factor-clock"; | |
| 645 | + clocks = <&sys_clkin_ck>; | |
| 646 | + clock-mult = <1>; | |
| 647 | + clock-div = <2>; | |
| 648 | + }; | |
| 649 | + | |
| 650 | + usbphy_32khz_clkmux: usbphy_32khz_clkmux { | |
| 651 | + #clock-cells = <0>; | |
| 652 | + compatible = "ti,mux-clock"; | |
| 653 | + clocks = <&clk_32768_ck>, <&clk_32k_tpm_ck>; | |
| 654 | + reg = <0x4260>; | |
| 655 | + }; | |
| 656 | +}; | |
| @@ -90,34 +90,19 @@ · 89 unmodified lines | ||
| 90 | 90 | nand-on-flash-bbt; |
| 91 | 91 | status = "okay"; |
| 92 | 92 | |
| 93 | − at91bootstrap@0 { | |
| 94 | − label = "at91bootstrap"; | |
| 95 | − reg = <0x0 0x8000>; | |
| 96 | − }; | |
| 97 | − | |
| 98 | − barebox@8000 { | |
| 93 | + barebox@0 { | |
| 99 | 94 | label = "barebox"; |
| 100 | − reg = <0x8000 0x40000>; | |
| 101 | − }; | |
| 102 | − | |
| 103 | − bareboxenv@48000 { | |
| 104 | − label = "bareboxenv"; | |
| 105 | − reg = <0x48000 0x8000>; | |
| 106 | − }; | |
| 107 | − | |
| 108 | − user_block@0x50000 { | |
| 109 | − label = "user_block"; | |
| 110 | − reg = <0x50000 0xb0000>; | |
| 95 | + reg = <0x0 0x58000>; | |
| 111 | 96 | }; |
| 112 | 97 | |
| 113 | − kernel@100000 { | |
| 114 | − label = "kernel"; | |
| 115 | − reg = <0x100000 0x1b0000>; | |
| 98 | + u_boot_env@58000 { | |
| 99 | + label = "u_boot_env"; | |
| 100 | + reg = <0x58000 0x8000>; | |
| 116 | 101 | }; |
| 117 | 102 | |
| 118 | − root@2b0000 { | |
| 119 | − label = "root"; | |
| 120 | − reg = <0x2b0000 0x1D50000>; | |
| 103 | + ubi@60000 { | |
| 104 | + label = "ubi"; | |
| 105 | + reg = <0x60000 0x1FA0000>; | |
| 121 | 106 | }; |
| 122 | 107 | }; |
| 123 | 108 | |
| @@ -74,13 +74,13 @@ · 73 unmodified lines | ||
| 74 | 74 | green_pwr_led { |
| 75 | 75 | label = "mirabox:green:pwr"; |
| 76 | 76 | gpios = <&gpio1 31 1>; |
| 77 | − linux,default-trigger = "heartbeat"; | |
| 77 | + default-state = "keep"; | |
| 78 | 78 | }; |
| 79 | 79 | |
| 80 | 80 | blue_stat_led { |
| 81 | 81 | label = "mirabox:blue:stat"; |
| 82 | 82 | gpios = <&gpio2 0 1>; |
| 83 | − linux,default-trigger = "cpu0"; | |
| 83 | + default-state = "off"; | |
| 84 | 84 | }; |
| 85 | 85 | |
| 86 | 86 | green_stat_led { |
| @@ -139,6 +139,27 @@ · 52 unmodified lines | ||
| 139 | 139 | reg = <0x25>; |
| 140 | 140 | }; |
| 141 | 141 | }; |
| 142 | + | |
| 143 | + nand@d0000 { | |
| 144 | + status = "okay"; | |
| 145 | + num-cs = <1>; | |
| 146 | + marvell,nand-keep-config; | |
| 147 | + marvell,nand-enable-arbiter; | |
| 148 | + nand-on-flash-bbt; | |
| 149 | + | |
| 150 | + partition@0 { | |
| 151 | + label = "U-Boot"; | |
| 152 | + reg = <0 0x400000>; | |
| 153 | + }; | |
| 154 | + partition@400000 { | |
| 155 | + label = "Linux"; | |
| 156 | + reg = <0x400000 0x400000>; | |
| 157 | + }; | |
| 158 | + partition@800000 { | |
| 159 | + label = "Filesystem"; | |
| 160 | + reg = <0x800000 0x3f800000>; | |
| 161 | + }; | |
| 162 | + }; | |
| 142 | 163 | }; |
| 143 | 164 | }; |
| 144 | 165 | }; |
| @@ -11,6 +11,8 @@ · 10 unmodified lines | ||
| 11 | 11 | |
| 12 | 12 | /dts-v1/; |
| 13 | 13 | |
| 14 | +#include <dt-bindings/input/input.h> | |
| 15 | +#include <dt-bindings/gpio/gpio.h> | |
| 14 | 16 | #include "armada-370.dtsi" |
| 15 | 17 | |
| 16 | 18 | / { |
| @@ -62,6 +64,7 @@ · 45 unmodified lines | ||
| 62 | 64 | marvell,pins = "mpp57"; |
| 63 | 65 | marvell,function = "gpio"; |
| 64 | 66 | }; |
| 67 | + | |
| 65 | 68 | sata1_led_pin: sata1-led-pin { |
| 66 | 69 | marvell,pins = "mpp15"; |
| 67 | 70 | marvell,function = "gpio"; |
| @@ -77,6 +80,21 @@ · 9 unmodified lines | ||
| 77 | 80 | marvell,function = "gpio"; |
| 78 | 81 | }; |
| 79 | 82 | |
| 83 | + backup_button_pin: backup-button-pin { | |
| 84 | + marvell,pins = "mpp58"; | |
| 85 | + marvell,function = "gpio"; | |
| 86 | + }; | |
| 87 | + | |
| 88 | + power_button_pin: power-button-pin { | |
| 89 | + marvell,pins = "mpp62"; | |
| 90 | + marvell,function = "gpio"; | |
| 91 | + }; | |
| 92 | + | |
| 93 | + reset_button_pin: reset-button-pin { | |
| 94 | + marvell,pins = "mpp6"; | |
| 95 | + marvell,function = "gpio"; | |
| 96 | + }; | |
| 97 | + | |
| 80 | 98 | poweroff: poweroff { |
| 81 | 99 | marvell,pins = "mpp8"; |
| 82 | 100 | marvell,function = "gpio"; |
| @@ -84,7 +102,7 @@ · 1 unmodified line | ||
| 84 | 102 | }; |
| 85 | 103 | |
| 86 | 104 | mdio { |
| 87 | − phy0: ethernet-phy@0 { | |
| 105 | + phy0: ethernet-phy@0 { /* Marvell 88E1318 */ | |
| 88 | 106 | reg = <0>; |
| 89 | 107 | }; |
| 90 | 108 | }; |
| @@ -104,6 +122,11 @@ · 13 unmodified lines | ||
| 104 | 122 | clock-frequency = <100000>; |
| 105 | 123 | status = "okay"; |
| 106 | 124 | |
| 125 | + isl12057: isl12057@68 { | |
| 126 | + compatible = "isl,isl12057"; | |
| 127 | + reg = <0x68>; | |
| 128 | + }; | |
| 129 | + | |
| 107 | 130 | g762: g762@3e { |
| 108 | 131 | compatible = "gmt,g762"; |
| 109 | 132 | reg = <0x3e>; |
| @@ -113,82 +136,116 @@ · 3 unmodified lines | ||
| 113 | 136 | pwm_polarity = <0>; |
| 114 | 137 | }; |
| 115 | 138 | }; |
| 139 | + | |
| 140 | + nand@d0000 { | |
| 141 | + status = "okay"; | |
| 142 | + num-cs = <1>; | |
| 143 | + marvell,nand-keep-config; | |
| 144 | + marvell,nand-enable-arbiter; | |
| 145 | + nand-on-flash-bbt; | |
| 146 | + | |
| 147 | + partition@0 { | |
| 148 | + label = "u-boot"; | |
| 149 | + reg = <0x0000000 0x180000>; /* 1.5MB */ | |
| 150 | + read-only; | |
| 151 | + }; | |
| 152 | + | |
| 153 | + partition@180000 { | |
| 154 | + label = "u-boot-env"; | |
| 155 | + reg = <0x180000 0x20000>; /* 128KB */ | |
| 156 | + read-only; | |
| 157 | + }; | |
| 158 | + | |
| 159 | + partition@200000 { | |
| 160 | + label = "uImage"; | |
| 161 | + reg = <0x0200000 0x600000>; /* 6MB */ | |
| 162 | + }; | |
| 163 | + | |
| 164 | + partition@800000 { | |
| 165 | + label = "minirootfs"; | |
| 166 | + reg = <0x0800000 0x400000>; /* 4MB */ | |
| 167 | + }; | |
| 168 | + | |
| 169 | + /* Last MB is for the BBT, i.e. not writable */ | |
| 170 | + partition@c00000 { | |
| 171 | + label = "ubifs"; | |
| 172 | + reg = <0x0c00000 0x7400000>; /* 116MB */ | |
| 173 | + }; | |
| 174 | + }; | |
| 116 | 175 | }; |
| 117 | 176 | }; |
| 118 | 177 | |
| 119 | 178 | clocks { |
| 120 | − #address-cells = <1>; | |
| 121 | − #size-cells = <0>; | |
| 122 | − | |
| 123 | − g762_clk: fixedclk { | |
| 179 | + g762_clk: g762-oscillator { | |
| 124 | 180 | compatible = "fixed-clock"; |
| 125 | 181 | #clock-cells = <0>; |
| 126 | 182 | clock-frequency = <8192>; |
| 127 | 183 | }; |
| 128 | 184 | }; |
| 129 | 185 | |
| 130 | − gpio_leds { | |
| 186 | + gpio-leds { | |
| 131 | 187 | compatible = "gpio-leds"; |
| 132 | − pinctrl-0 = < &power_led_pin | |
| 133 | − &sata1_led_pin | |
| 134 | − &sata2_led_pin | |
| 135 | − &backup_led_pin >; | |
| 188 | + pinctrl-0 = <&power_led_pin | |
| 189 | + &sata1_led_pin | |
| 190 | + &sata2_led_pin | |
| 191 | + &backup_led_pin>; | |
| 136 | 192 | pinctrl-names = "default"; |
| 137 | 193 | |
| 138 | − blue_power_led { | |
| 194 | + blue-power-led { | |
| 139 | 195 | label = "rn102:blue:pwr"; |
| 140 | − gpios = <&gpio1 25 1>; /* GPIO 57 Active Low */ | |
| 141 | − linux,default-trigger = "heartbeat"; | |
| 196 | + gpios = <&gpio1 25 GPIO_ACTIVE_LOW>; | |
| 197 | + default-state = "keep"; | |
| 142 | 198 | }; |
| 143 | 199 | |
| 144 | − green_sata1_led { | |
| 200 | + green-sata1-led { | |
| 145 | 201 | label = "rn102:green:sata1"; |
| 146 | − gpios = <&gpio0 15 1>; /* GPIO 15 Active Low */ | |
| 202 | + gpios = <&gpio0 15 GPIO_ACTIVE_LOW>; | |
| 147 | 203 | default-state = "on"; |
| 148 | 204 | }; |
| 149 | 205 | |
| 150 | − green_sata2_led { | |
| 206 | + green-sata2-led { | |
| 151 | 207 | label = "rn102:green:sata2"; |
| 152 | − gpios = <&gpio0 14 1>; /* GPIO 14 Active Low */ | |
| 208 | + gpios = <&gpio0 14 GPIO_ACTIVE_LOW>; | |
| 153 | 209 | default-state = "on"; |
| 154 | 210 | }; |
| 155 | 211 | |
| 156 | − green_backup_led { | |
| 212 | + green-backup-led { | |
| 157 | 213 | label = "rn102:green:backup"; |
| 158 | − gpios = <&gpio1 24 1>; /* GPIO 56 Active Low */ | |
| 214 | + gpios = <&gpio1 24 GPIO_ACTIVE_LOW>; | |
| 159 | 215 | default-state = "on"; |
| 160 | 216 | }; |
| 161 | 217 | }; |
| 162 | 218 | |
| 163 | − gpio_keys { | |
| 219 | + gpio-keys { | |
| 164 | 220 | compatible = "gpio-keys"; |
| 165 | − #address-cells = <1>; | |
| 166 | − #size-cells = <0>; | |
| 221 | + pinctrl-0 = <&power_button_pin | |
| 222 | + &reset_button_pin | |
| 223 | + &backup_button_pin>; | |
| 224 | + pinctrl-names = "default"; | |
| 167 | 225 | |
| 168 | − button@1 { | |
| 226 | + power-button { | |
| 169 | 227 | label = "Power Button"; |
| 170 | − linux,code = <116>; /* KEY_POWER */ | |
| 171 | − gpios = <&gpio1 30 0>; | |
| 228 | + linux,code = <KEY_POWER>; | |
| 229 | + gpios = <&gpio1 30 GPIO_ACTIVE_HIGH>; | |
| 172 | 230 | }; |
| 173 | 231 | |
| 174 | − button@2 { | |
| 232 | + reset-button { | |
| 175 | 233 | label = "Reset Button"; |
| 176 | − linux,code = <0x198>; /* KEY_RESTART */ | |
| 177 | − gpios = <&gpio0 6 1>; | |
| 234 | + linux,code = <KEY_RESTART>; | |
| 235 | + gpios = <&gpio0 6 GPIO_ACTIVE_LOW>; | |
| 178 | 236 | }; |
| 179 | 237 | |
| 180 | − button@3 { | |
| 238 | + backup-button { | |
| 181 | 239 | label = "Backup Button"; |
| 182 | − linux,code = <133>; /* KEY_COPY */ | |
| 183 | − gpios = <&gpio1 26 1>; | |
| 240 | + linux,code = <KEY_COPY>; | |
| 241 | + gpios = <&gpio1 26 GPIO_ACTIVE_LOW>; | |
| 184 | 242 | }; |
| 185 | 243 | }; |
| 186 | 244 | |
| 187 | − gpio_poweroff { | |
| 245 | + gpio-poweroff { | |
| 188 | 246 | compatible = "gpio-poweroff"; |
| 189 | 247 | pinctrl-0 = <&poweroff>; |
| 190 | 248 | pinctrl-names = "default"; |
| 191 | − gpios = <&gpio0 8 1>; | |
| 249 | + gpios = <&gpio0 8 GPIO_ACTIVE_LOW>; | |
| 192 | 250 | }; |
| 193 | − | |
| 194 | 251 | }; |
| @@ -11,6 +11,8 @@ · 10 unmodified lines | ||
| 11 | 11 | |
| 12 | 12 | /dts-v1/; |
| 13 | 13 | |
| 14 | +#include <dt-bindings/input/input.h> | |
| 15 | +#include <dt-bindings/gpio/gpio.h> | |
| 14 | 16 | #include "armada-370.dtsi" |
| 15 | 17 | |
| 16 | 18 | / { |
| @@ -58,12 +60,12 @@ · 41 unmodified lines | ||
| 58 | 60 | marvell,function = "gpio"; |
| 59 | 61 | }; |
| 60 | 62 | |
| 61 | − backup_key_pin: backup-key-pin { | |
| 63 | + backup_button_pin: backup-button-pin { | |
| 62 | 64 | marvell,pins = "mpp52"; |
| 63 | 65 | marvell,function = "gpio"; |
| 64 | 66 | }; |
| 65 | 67 | |
| 66 | − power_key_pin: power-key-pin { | |
| 68 | + power_button_pin: power-button-pin { | |
| 67 | 69 | marvell,pins = "mpp62"; |
| 68 | 70 | marvell,function = "gpio"; |
| 69 | 71 | }; |
| @@ -78,18 +80,18 @@ · 8 unmodified lines | ||
| 78 | 80 | marvell,function = "gpio"; |
| 79 | 81 | }; |
| 80 | 82 | |
| 81 | − reset_key_pin: reset-key-pin { | |
| 83 | + reset_button_pin: reset-button-pin { | |
| 82 | 84 | marvell,pins = "mpp65"; |
| 83 | 85 | marvell,function = "gpio"; |
| 84 | 86 | }; |
| 85 | 87 | }; |
| 86 | 88 | |
| 87 | 89 | mdio { |
| 88 | − phy0: ethernet-phy@0 { | |
| 90 | + phy0: ethernet-phy@0 { /* Marvell 88E1318 */ | |
| 89 | 91 | reg = <0>; |
| 90 | 92 | }; |
| 91 | 93 | |
| 92 | − phy1: ethernet-phy@1 { | |
| 94 | + phy1: ethernet-phy@1 { /* Marvell 88E1318 */ | |
| 93 | 95 | reg = <1>; |
| 94 | 96 | }; |
| 95 | 97 | }; |
| @@ -115,6 +117,11 @@ · 19 unmodified lines | ||
| 115 | 117 | clock-frequency = <100000>; |
| 116 | 118 | status = "okay"; |
| 117 | 119 | |
| 120 | + isl12057: isl12057@68 { | |
| 121 | + compatible = "isl,isl12057"; | |
| 122 | + reg = <0x68>; | |
| 123 | + }; | |
| 124 | + | |
| 118 | 125 | g762: g762@3e { |
| 119 | 126 | compatible = "gmt,g762"; |
| 120 | 127 | reg = <0x3e>; |
| @@ -123,71 +130,133 @@ · 2 unmodified lines | ||
| 123 | 130 | fan_startv = <1>; |
| 124 | 131 | pwm_polarity = <0>; |
| 125 | 132 | }; |
| 133 | + | |
| 134 | + pca9554: pca9554@23 { | |
| 135 | + compatible = "nxp,pca9554"; | |
153 more lines aren’t shown here.
This diff is large: its 28 lines aren’t shown here.
This diff is large: its 221 lines aren’t shown here.
This diff is large: its 110 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 328 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 146 lines aren’t shown here.
This diff is large: its 19 lines aren’t shown here.
This diff is large: its 123 lines aren’t shown here.
This diff is large: its 85 lines aren’t shown here.
This diff is large: its 186 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 87 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 79 lines aren’t shown here.
This diff is large: its 37 lines aren’t shown here.
This diff is large: its 148 lines aren’t shown here.
This diff is large: its 83 lines aren’t shown here.
This diff is large: its 28 lines aren’t shown here.
This diff is large: its 35 lines aren’t shown here.
This diff is large: its 82 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 238 lines aren’t shown here.
This diff is large: its 40 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 30 lines aren’t shown here.
This diff is large: its 228 lines aren’t shown here.
This diff is large: its 30 lines aren’t shown here.
This diff is large: its 211 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 28 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 540 lines aren’t shown here.
This diff is large: its 52 lines aren’t shown here.
This diff is large: its 2016 lines aren’t shown here.
This diff is large: its 87 lines aren’t shown here.
This diff is large: its 173 lines aren’t shown here.
This diff is large: its 60 lines aren’t shown here.
This diff is large: its 188 lines aren’t shown here.
This diff is large: its 25 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 47 lines aren’t shown here.
This diff is large: its 36 lines aren’t shown here.
This diff is large: its 27 lines aren’t shown here.
This diff is large: its 28 lines aren’t shown here.
This diff is large: its 94 lines aren’t shown here.
This diff is large: its 38 lines aren’t shown here.
This diff is large: its 47 lines aren’t shown here.
This diff is large: its 52 lines aren’t shown here.
This diff is large: its 46 lines aren’t shown here.
This diff is large: its 144 lines aren’t shown here.
This diff is large: its 131 lines aren’t shown here.
This diff is large: its 172 lines aren’t shown here.
This diff is large: its 48 lines aren’t shown here.
This diff is large: its 212 lines aren’t shown here.
This diff is large: its 67 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 40 lines aren’t shown here.
This diff is large: its 424 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 650 lines aren’t shown here.
This diff is large: its 566 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 168 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 144 lines aren’t shown here.
This diff is large: its 63 lines aren’t shown here.
This diff is large: its 34 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 64 lines aren’t shown here.
This diff is large: its 90 lines aren’t shown here.
This diff is large: its 61 lines aren’t shown here.
This diff is large: its 108 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 71 lines aren’t shown here.
This diff is large: its 40 lines aren’t shown here.
This diff is large: its 19 lines aren’t shown here.
This diff is large: its 31 lines aren’t shown here.
This diff is large: its 31 lines aren’t shown here.
This diff is large: its 53 lines aren’t shown here.
This diff is large: its 24 lines aren’t shown here.
This diff is large: its 32 lines aren’t shown here.
This diff is large: its 73 lines aren’t shown here.
This diff is large: its 51 lines aren’t shown here.
This diff is large: its 56 lines aren’t shown here.
This diff is large: its 75 lines aren’t shown here.
This diff is large: its 59 lines aren’t shown here.
This diff is large: its 19 lines aren’t shown here.
This diff is large: its 176 lines aren’t shown here.
This diff is large: its 92 lines aren’t shown here.
This diff is large: its 65 lines aren’t shown here.
This diff is large: its 39 lines aren’t shown here.
This diff is large: its 196 lines aren’t shown here.
This diff is large: its 269 lines aren’t shown here.
This diff is large: its 35 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 24 lines aren’t shown here.
This diff is large: its 24 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 79 lines aren’t shown here.
This diff is large: its 74 lines aren’t shown here.
This diff is large: its 40 lines aren’t shown here.
This diff is large: its 45 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 22 lines aren’t shown here.
This diff is large: its 24 lines aren’t shown here.
This diff is large: its 39 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 239 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 118 lines aren’t shown here.
This diff is large: its 149 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 100 lines aren’t shown here.
This diff is large: its 50 lines aren’t shown here.
This diff is large: its 55 lines aren’t shown here.
This diff is large: its 57 lines aren’t shown here.
This diff is large: its 105 lines aren’t shown here.
This diff is large: its 96 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 71 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 232 lines aren’t shown here.
This diff is large: its 41 lines aren’t shown here.
This diff is large: its 31 lines aren’t shown here.
This diff is large: its 44 lines aren’t shown here.
This diff is large: its 61 lines aren’t shown here.
This diff is large: its 209 lines aren’t shown here.
This diff is large: its 269 lines aren’t shown here.
This diff is large: its 22 lines aren’t shown here.
This diff is large: its 243 lines aren’t shown here.
This diff is large: its 91 lines aren’t shown here.
This diff is large: its 199 lines aren’t shown here.
This diff is large: its 22 lines aren’t shown here.
This diff is large: its 1661 lines aren’t shown here.
This diff is large: its 42 lines aren’t shown here.
This diff is large: its 65 lines aren’t shown here.
This diff is large: its 19 lines aren’t shown here.
This diff is large: its 41 lines aren’t shown here.
This diff is large: its 51 lines aren’t shown here.
This diff is large: its 28 lines aren’t shown here.
This diff is large: its 1652 lines aren’t shown here.
This diff is large: its 29 lines aren’t shown here.
This diff is large: its 29 lines aren’t shown here.
This diff is large: its 102 lines aren’t shown here.
This diff is large: its 1400 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 148 lines aren’t shown here.
This diff is large: its 111 lines aren’t shown here.
This diff is large: its 30 lines aren’t shown here.
This diff is large: its 7 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 98 lines aren’t shown here.
This diff is large: its 32 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 48 lines aren’t shown here.
This diff is large: its 31 lines aren’t shown here.
This diff is large: its 332 lines aren’t shown here.
This diff is large: its 148 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 249 lines aren’t shown here.
This diff is large: its 77 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 241 lines aren’t shown here.
This diff is large: its 73 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 229 lines aren’t shown here.
This diff is large: its 46 lines aren’t shown here.
This diff is large: its 80 lines aren’t shown here.
This diff is large: its 556 lines aren’t shown here.
This diff is large: its 116 lines aren’t shown here.
This diff is large: its 47 lines aren’t shown here.
This diff is large: its 491 lines aren’t shown here.
This diff is large: its 678 lines aren’t shown here.
This diff is large: its 21 lines aren’t shown here.
This diff is large: its 54 lines aren’t shown here.
This diff is large: its 40 lines aren’t shown here.
This diff is large: its 24 lines aren’t shown here.
This diff is large: its 24 lines aren’t shown here.
This diff is large: its 24 lines aren’t shown here.
This diff is large: its 33 lines aren’t shown here.
This diff is large: its 30 lines aren’t shown here.
This diff is large: its 55 lines aren’t shown here.
This diff is large: its 31 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 167 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 290 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 67 lines aren’t shown here.
This diff is large: its 746 lines aren’t shown here.
This diff is large: its 54 lines aren’t shown here.
This diff is large: its 112 lines aren’t shown here.
This diff is large: its 157 lines aren’t shown here.
This diff is large: its 104 lines aren’t shown here.
This diff is large: its 267 lines aren’t shown here.
This diff is large: its 119 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 317 lines aren’t shown here.
This diff is large: its 22 lines aren’t shown here.
This diff is large: its 50 lines aren’t shown here.
This diff is large: its 66 lines aren’t shown here.
This diff is large: its 49 lines aren’t shown here.
This diff is large: its 66 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 28 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 208 lines aren’t shown here.
This diff is large: its 171 lines aren’t shown here.
This diff is large: its 69 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 160 lines aren’t shown here.
This diff is large: its 89 lines aren’t shown here.
This diff is large: its 25 lines aren’t shown here.
This diff is large: its 286 lines aren’t shown here.
This diff is large: its 1132 lines aren’t shown here.
This diff is large: its 594 lines aren’t shown here.
This diff is large: its 1089 lines aren’t shown here.
This diff is large: its 484 lines aren’t shown here.
This diff is large: its 431 lines aren’t shown here.
This diff is large: its 446 lines aren’t shown here.
This diff is large: its 77 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 159 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 469 lines aren’t shown here.
This diff is large: its 135 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 156 lines aren’t shown here.
This diff is large: its 158 lines aren’t shown here.
This diff is large: its 177 lines aren’t shown here.
This diff is large: its 571 lines aren’t shown here.
This diff is large: its 265 lines aren’t shown here.
This diff is large: its 27 lines aren’t shown here.
This diff is large: its 26 lines aren’t shown here.
This diff is large: its 225 lines aren’t shown here.
This diff is large: its 682 lines aren’t shown here.
This diff is large: its 67 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 28 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 26 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 85 lines aren’t shown here.
This diff is large: its 27 lines aren’t shown here.
This diff is large: its 55 lines aren’t shown here.
This diff is large: its 103 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 117 lines aren’t shown here.
This diff is large: its 57 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 68 lines aren’t shown here.
This diff is large: its 44 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 52 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 26 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 55 lines aren’t shown here.
This diff is large: its 150 lines aren’t shown here.
This diff is large: its 66 lines aren’t shown here.
This diff is large: its 30 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 110 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 94 lines aren’t shown here.
This diff is large: its 29 lines aren’t shown here.
This diff is large: its 2 lines aren’t shown here.
This diff is large: its 82 lines aren’t shown here.
This diff is large: its 5 lines aren’t shown here.
This diff is large: its 70 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 44 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 34 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 68 lines aren’t shown here.
This diff is large: its 41 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 24 lines aren’t shown here.
This diff is large: its 69 lines aren’t shown here.
This diff is large: its 42 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 34 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 42 lines aren’t shown here.
This diff is large: its 137 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 47 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 160 lines aren’t shown here.
This diff is large: its 134 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 46 lines aren’t shown here.
This diff is large: its 29 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 49 lines aren’t shown here.
This diff is large: its 37 lines aren’t shown here.
This diff is large: its 146 lines aren’t shown here.
This diff is large: its 55 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 46 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 31 lines aren’t shown here.
This diff is large: its 267 lines aren’t shown here.
This diff is large: its 54 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 25 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 368 lines aren’t shown here.
This diff is large: its 63 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 6 lines aren’t shown here.
This diff is large: its 30 lines aren’t shown here.
This diff is large: its 2 lines aren’t shown here.
This diff is large: its 40 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 30 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 39 lines aren’t shown here.
This diff is large: its 2 lines aren’t shown here.
This diff is large: its 4 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 5 lines aren’t shown here.
This diff is large: its 4 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 153 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 32 lines aren’t shown here.
This diff is large: its 45 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 66 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 373 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 24 lines aren’t shown here.
This diff is large: its 51 lines aren’t shown here.
This diff is large: its 22 lines aren’t shown here.
This diff is large: its 63 lines aren’t shown here.
This diff is large: its 116 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 6 lines aren’t shown here.
This diff is large: its 80 lines aren’t shown here.
This diff is large: its 61 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 91 lines aren’t shown here.
This diff is large: its 201 lines aren’t shown here.
This diff is large: its 90 lines aren’t shown here.
This diff is large: its 124 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 39 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 25 lines aren’t shown here.
This diff is large: its 883 lines aren’t shown here.
This diff is large: its 19 lines aren’t shown here.
This diff is large: its 52 lines aren’t shown here.
This diff is large: its 24 lines aren’t shown here.
This diff is large: its 52 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 51 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 39 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 109 lines aren’t shown here.
This diff is large: its 31 lines aren’t shown here.
This diff is large: its 50 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 30 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 150 lines aren’t shown here.
This diff is large: its 32 lines aren’t shown here.
This diff is large: its 21 lines aren’t shown here.
This diff is large: its 27 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 75 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 7 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 32 lines aren’t shown here.
This diff is large: its 4 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 127 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 53 lines aren’t shown here.
This diff is large: its 53 lines aren’t shown here.
This diff is large: its 26 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 55 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 120 lines aren’t shown here.
This diff is large: its 33 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 25 lines aren’t shown here.
This diff is large: its 39 lines aren’t shown here.
This diff is large: its 45 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 52 lines aren’t shown here.
This diff is large: its 43 lines aren’t shown here.
This diff is large: its 274 lines aren’t shown here.
This diff is large: its 42 lines aren’t shown here.
This diff is large: its 366 lines aren’t shown here.
This diff is large: its 355 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 1065 lines aren’t shown here.
This diff is large: its 1736 lines aren’t shown here.
This diff is large: its 34 lines aren’t shown here.
This diff is large: its 27 lines aren’t shown here.
This diff is large: its 38 lines aren’t shown here.
This diff is large: its 147 lines aren’t shown here.
This diff is large: its 257 lines aren’t shown here.
This diff is large: its 27 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 7 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 128 lines aren’t shown here.
This diff is large: its 44 lines aren’t shown here.
This diff is large: its 68 lines aren’t shown here.
This diff is large: its 158 lines aren’t shown here.
This diff is large: its 73 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 691 lines aren’t shown here.
This diff is large: its 283 lines aren’t shown here.
This diff is large: its 794 lines aren’t shown here.
This diff is large: its 371 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 48 lines aren’t shown here.
This diff is large: its 317 lines aren’t shown here.
This diff is large: its 578 lines aren’t shown here.
This diff is large: its 339 lines aren’t shown here.
This diff is large: its 281 lines aren’t shown here.
This diff is large: its 19 lines aren’t shown here.
This diff is large: its 218 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 84 lines aren’t shown here.
This diff is large: its 38 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 35 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 31 lines aren’t shown here.
This diff is large: its 27 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 28 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 57 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 38 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 763 lines aren’t shown here.
This diff is large: its 162 lines aren’t shown here.
This diff is large: its 25 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 39 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 245 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 170 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 53 lines aren’t shown here.
This diff is large: its 86 lines aren’t shown here.
This diff is large: its 106 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 187 lines aren’t shown here.
This diff is large: its 27 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 27 lines aren’t shown here.
This diff is large: its 28 lines aren’t shown here.
This diff is large: its 61 lines aren’t shown here.
This diff is large: its 63 lines aren’t shown here.
This diff is large: its 50 lines aren’t shown here.
This diff is large: its 80 lines aren’t shown here.
This diff is large: its 216 lines aren’t shown here.
This diff is large: its 93 lines aren’t shown here.
This diff is large: its 63 lines aren’t shown here.
This diff is large: its 223 lines aren’t shown here.
This diff is large: its 66 lines aren’t shown here.
This diff is large: its 59 lines aren’t shown here.
This diff is large: its 35 lines aren’t shown here.
This diff is large: its 21 lines aren’t shown here.
This diff is large: its 28 lines aren’t shown here.
This diff is large: its 81 lines aren’t shown here.
This diff is large: its 34 lines aren’t shown here.
This diff is large: its 150 lines aren’t shown here.
This diff is large: its 63 lines aren’t shown here.
This diff is large: its 23 lines aren’t shown here.
This diff is large: its 52 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 52 lines aren’t shown here.
This diff is large: its 28 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 196 lines aren’t shown here.
This diff is large: its 106 lines aren’t shown here.
This diff is large: its 96 lines aren’t shown here.
This diff is large: its 217 lines aren’t shown here.
This diff is large: its 212 lines aren’t shown here.
This diff is large: its 207 lines aren’t shown here.
This diff is large: its 181 lines aren’t shown here.
This diff is large: its 223 lines aren’t shown here.
This diff is large: its 54 lines aren’t shown here.
This diff is large: its 168 lines aren’t shown here.
This diff is large: its 271 lines aren’t shown here.
This diff is large: its 24 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 3 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 125 lines aren’t shown here.
This diff is large: its 39 lines aren’t shown here.
This diff is large: its 25 lines aren’t shown here.
This diff is large: its 26 lines aren’t shown here.
This diff is large: its 87 lines aren’t shown here.
This diff is large: its 42 lines aren’t shown here.
This diff is large: its 311 lines aren’t shown here.
This diff is large: its 72 lines aren’t shown here.
This diff is large: its 33 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 98 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 51 lines aren’t shown here.
This diff is large: its 845 lines aren’t shown here.
This diff is large: its 21 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 79 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 55 lines aren’t shown here.
This diff is large: its 44 lines aren’t shown here.
This diff is large: its 29 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 27 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 53 lines aren’t shown here.
This diff is large: its 27 lines aren’t shown here.
This diff is large: its 106 lines aren’t shown here.
This diff is large: its 44 lines aren’t shown here.
This diff is large: its 42 lines aren’t shown here.
This diff is large: its 51 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 54 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 86 lines aren’t shown here.
This diff is large: its 42 lines aren’t shown here.
This diff is large: its 26 lines aren’t shown here.
This diff is large: its 88 lines aren’t shown here.
This diff is large: its 27 lines aren’t shown here.
This diff is large: its 346 lines aren’t shown here.
This diff is large: its 140 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 230 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 44 lines aren’t shown here.
This diff is large: its 35 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 22 lines aren’t shown here.
This diff is large: its 33 lines aren’t shown here.
This diff is large: its 22 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 57 lines aren’t shown here.
This diff is large: its 124 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 29 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 141 lines aren’t shown here.
This diff is large: its 61 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 35 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 59 lines aren’t shown here.
This diff is large: its 28 lines aren’t shown here.
This diff is large: its 29 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 109 lines aren’t shown here.
This diff is large: its 53 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 42 lines aren’t shown here.
This diff is large: its 141 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 28 lines aren’t shown here.
This diff is large: its 46 lines aren’t shown here.
This diff is large: its 95 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 36 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 25 lines aren’t shown here.
This diff is large: its 114 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 57 lines aren’t shown here.
This diff is large: its 25 lines aren’t shown here.
This diff is large: its 277 lines aren’t shown here.
This diff is large: its 305 lines aren’t shown here.
This diff is large: its 59 lines aren’t shown here.
This diff is large: its 310 lines aren’t shown here.
This diff is large: its 153 lines aren’t shown here.
This diff is large: its 63 lines aren’t shown here.
This diff is large: its 159 lines aren’t shown here.
This diff is large: its 185 lines aren’t shown here.
This diff is large: its 88 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 141 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 40 lines aren’t shown here.
This diff is large: its 19 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 51 lines aren’t shown here.
This diff is large: its 48 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 58 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 79 lines aren’t shown here.
This diff is large: its 5 lines aren’t shown here.
This diff is large: its 7 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 5 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 7 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 61 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 76 lines aren’t shown here.
This diff is large: its 25 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 85 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 27 lines aren’t shown here.
This diff is large: its 5 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 36 lines aren’t shown here.
This diff is large: its 5 lines aren’t shown here.
This diff is large: its 21 lines aren’t shown here.
This diff is large: its 502 lines aren’t shown here.
This diff is large: its 434 lines aren’t shown here.
This diff is large: its 58 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 237 lines aren’t shown here.
This diff is large: its 111 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 55 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 48 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 22 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 5 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 47 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 7 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 7 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 75 lines aren’t shown here.
This diff is large: its 70 lines aren’t shown here.
This diff is large: its 52 lines aren’t shown here.
This diff is large: its 103 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 5 lines aren’t shown here.
This diff is large: its 7 lines aren’t shown here.
This diff is large: its 25 lines aren’t shown here.
This diff is large: its 5 lines aren’t shown here.
This diff is large: its 5 lines aren’t shown here.
This diff is large: its 39 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 6 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 22 lines aren’t shown here.
This diff is large: its 55 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 2 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 52 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 117 lines aren’t shown here.
This diff is large: its 45 lines aren’t shown here.
This diff is large: its 100 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 462 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 32 lines aren’t shown here.
This diff is large: its 7 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 113 lines aren’t shown here.
This diff is large: its 532 lines aren’t shown here.
This diff is large: its 47 lines aren’t shown here.
This diff is large: its 543 lines aren’t shown here.
This diff is large: its 21 lines aren’t shown here.
This diff is large: its 156 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 86 lines aren’t shown here.
This diff is large: its 66 lines aren’t shown here.
This diff is large: its 175 lines aren’t shown here.
This diff is large: its 42 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 60 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 48 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 29 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 34 lines aren’t shown here.
This diff is large: its 29 lines aren’t shown here.
This diff is large: its 19 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 31 lines aren’t shown here.
This diff is large: its 29 lines aren’t shown here.
This diff is large: its 73 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 64 lines aren’t shown here.
This diff is large: its 33 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 667 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 189 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 5 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 56 lines aren’t shown here.
This diff is large: its 103 lines aren’t shown here.
This diff is large: its 114 lines aren’t shown here.
This diff is large: its 37 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 37 lines aren’t shown here.
This diff is large: its 54 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 86 lines aren’t shown here.
This diff is large: its 40 lines aren’t shown here.
This diff is large: its 153 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 29 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 7 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 83 lines aren’t shown here.
This diff is large: its 144 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 127 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 26 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 40 lines aren’t shown here.
This diff is large: its 21 lines aren’t shown here.
This diff is large: its 21 lines aren’t shown here.
This diff is large: its 153 lines aren’t shown here.
This diff is large: its 49 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 90 lines aren’t shown here.
This diff is large: its 74 lines aren’t shown here.
This diff is large: its 58 lines aren’t shown here.
This diff is large: its 144 lines aren’t shown here.
This diff is large: its 31 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 74 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 21 lines aren’t shown here.
This diff is large: its 39 lines aren’t shown here.
This diff is large: its 92 lines aren’t shown here.
This diff is large: its 24 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 22 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 151 lines aren’t shown here.
This diff is large: its 23 lines aren’t shown here.
This diff is large: its 7 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 68 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 28 lines aren’t shown here.
This diff is large: its 121 lines aren’t shown here.
This diff is large: its 180 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 62 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 118 lines aren’t shown here.
This diff is large: its 95 lines aren’t shown here.
This diff is large: its 116 lines aren’t shown here.
This diff is large: its 66 lines aren’t shown here.
This diff is large: its 117 lines aren’t shown here.
This diff is large: its 149 lines aren’t shown here.
This diff is large: its 429 lines aren’t shown here.
This diff is large: its 111 lines aren’t shown here.
This diff is large: its 24 lines aren’t shown here.
This diff is large: its 24 lines aren’t shown here.
This diff is large: its 431 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 48 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 129 lines aren’t shown here.
This diff is large: its 181 lines aren’t shown here.
This diff is large: its 524 lines aren’t shown here.
This diff is large: its 1345 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 207 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 93 lines aren’t shown here.
This diff is large: its 22 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 47 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 87 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 83 lines aren’t shown here.
This diff is large: its 48 lines aren’t shown here.
This diff is large: its 73 lines aren’t shown here.
This diff is large: its 275 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 42 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 115 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 135 lines aren’t shown here.
This diff is large: its 148 lines aren’t shown here.
This diff is large: its 36 lines aren’t shown here.
This diff is large: its 25 lines aren’t shown here.
This diff is large: its 5 lines aren’t shown here.
This diff is large: its 77 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 122 lines aren’t shown here.
This diff is large: its 64 lines aren’t shown here.
This diff is large: its 135 lines aren’t shown here.
This diff is large: its 166 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 34 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 6 lines aren’t shown here.
This diff is large: its 25 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 495 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 6 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 185 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 7 lines aren’t shown here.
This diff is large: its 7 lines aren’t shown here.
This diff is large: its 5 lines aren’t shown here.
This diff is large: its 71 lines aren’t shown here.
This diff is large: its 354 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 5 lines aren’t shown here.
This diff is large: its 7 lines aren’t shown here.
This diff is large: its 64 lines aren’t shown here.
This diff is large: its 73 lines aren’t shown here.
This diff is large: its 105 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 29 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 36 lines aren’t shown here.
This diff is large: its 22 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 83 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 22 lines aren’t shown here.
This diff is large: its 354 lines aren’t shown here.
This diff is large: its 157 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 23 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 26 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 23 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 26 lines aren’t shown here.
This diff is large: its 49 lines aren’t shown here.
This diff is large: its 34 lines aren’t shown here.
This diff is large: its 26 lines aren’t shown here.
This diff is large: its 26 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 186 lines aren’t shown here.
This diff is large: its 24 lines aren’t shown here.
This diff is large: its 86 lines aren’t shown here.
This diff is large: its 55 lines aren’t shown here.
This diff is large: its 36 lines aren’t shown here.
This diff is large: its 59 lines aren’t shown here.
This diff is large: its 67 lines aren’t shown here.
This diff is large: its 69 lines aren’t shown here.
This diff is large: its 80 lines aren’t shown here.
This diff is large: its 80 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 96 lines aren’t shown here.
This diff is large: its 281 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 23 lines aren’t shown here.
This diff is large: its 34 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 26 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 32 lines aren’t shown here.
This diff is large: its 32 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 28 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 189 lines aren’t shown here.
This diff is large: its 5 lines aren’t shown here.
This diff is large: its 5 lines aren’t shown here.
This diff is large: its 24 lines aren’t shown here.
This diff is large: its 24 lines aren’t shown here.
This diff is large: its 5 lines aren’t shown here.
This diff is large: its 5 lines aren’t shown here.
This diff is large: its 145 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 5 lines aren’t shown here.
This diff is large: its 7 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 22 lines aren’t shown here.
This diff is large: its 21 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 19 lines aren’t shown here.
This diff is large: its 35 lines aren’t shown here.
This diff is large: its 117 lines aren’t shown here.
This diff is large: its 45 lines aren’t shown here.
This diff is large: its 55 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 25 lines aren’t shown here.
This diff is large: its 87 lines aren’t shown here.
This diff is large: its 26 lines aren’t shown here.
This diff is large: its 55 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 148 lines aren’t shown here.
This diff is large: its 103 lines aren’t shown here.
This diff is large: its 30 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 198 lines aren’t shown here.
This diff is large: its 22 lines aren’t shown here.
This diff is large: its 28 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 176 lines aren’t shown here.
This diff is large: its 44 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 111 lines aren’t shown here.
This diff is large: its 35 lines aren’t shown here.
This diff is large: its 43 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 22 lines aren’t shown here.
This diff is large: its 121 lines aren’t shown here.
This diff is large: its 31 lines aren’t shown here.
This diff is large: its 26 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 6 lines aren’t shown here.
This diff is large: its 30 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 7 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 142 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 83 lines aren’t shown here.
This diff is large: its 73 lines aren’t shown here.
This diff is large: its 75 lines aren’t shown here.
This diff is large: its 65 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 38 lines aren’t shown here.
This diff is large: its 259 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 19 lines aren’t shown here.
This diff is large: its 70 lines aren’t shown here.
This diff is large: its 279 lines aren’t shown here.
This diff is large: its 23 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 328 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 338 lines aren’t shown here.
This diff is large: its 30 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 60 lines aren’t shown here.
This diff is large: its 353 lines aren’t shown here.
This diff is large: its 285 lines aren’t shown here.
This diff is large: its 25 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 59 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 291 lines aren’t shown here.
This diff is large: its 62 lines aren’t shown here.
This diff is large: its 89 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 79 lines aren’t shown here.
This diff is large: its 28 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 60 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 452 lines aren’t shown here.
This diff is large: its 41 lines aren’t shown here.
This diff is large: its 128 lines aren’t shown here.
This diff is large: its 5 lines aren’t shown here.
This diff is large: its 5 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 114 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 113 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 543 lines aren’t shown here.
This diff is large: its 47 lines aren’t shown here.
This diff is large: its 97 lines aren’t shown here.
This diff is large: its 29 lines aren’t shown here.
This diff is large: its 1667 lines aren’t shown here.
This diff is large: its 479 lines aren’t shown here.
This diff is large: its 286 lines aren’t shown here.
This diff is large: its 52 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 103 lines aren’t shown here.
This diff is large: its 19 lines aren’t shown here.
This diff is large: its 34 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 121 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 128 lines aren’t shown here.
This diff is large: its 22 lines aren’t shown here.
This diff is large: its 200 lines aren’t shown here.
This diff is large: its 449 lines aren’t shown here.
This diff is large: its 119 lines aren’t shown here.
This diff is large: its 36 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 85 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 23 lines aren’t shown here.
This diff is large: its 31 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 196 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 36 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 196 lines aren’t shown here.
This diff is large: its 224 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 1222 lines aren’t shown here.
This diff is large: its 755 lines aren’t shown here.
This diff is large: its 198 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 49 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 41 lines aren’t shown here.
This diff is large: its 46 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 48 lines aren’t shown here.
This diff is large: its 148 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 49 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 24 lines aren’t shown here.
This diff is large: its 5 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 222 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 5 lines aren’t shown here.
This diff is large: its 321 lines aren’t shown here.
This diff is large: its 38 lines aren’t shown here.
This diff is large: its 83 lines aren’t shown here.
This diff is large: its 147 lines aren’t shown here.
This diff is large: its 21 lines aren’t shown here.
This diff is large: its 7 lines aren’t shown here.
This diff is large: its 327 lines aren’t shown here.
This diff is large: its 53 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 276 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 47 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 22 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 314 lines aren’t shown here.
This diff is large: its 19 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 32 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 39 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 73 lines aren’t shown here.
This diff is large: its 26 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 7 lines aren’t shown here.
This diff is large: its 36 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 22 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 6 lines aren’t shown here.
This diff is large: its 28 lines aren’t shown here.
This diff is large: its 26 lines aren’t shown here.
This diff is large: its 142 lines aren’t shown here.
This diff is large: its 41 lines aren’t shown here.
This diff is large: its 5 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 24 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 26 lines aren’t shown here.
This diff is large: its 7 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 6 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 149 lines aren’t shown here.
This diff is large: its 44 lines aren’t shown here.
This diff is large: its 25 lines aren’t shown here.
This diff is large: its 211 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 63 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 5 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 53 lines aren’t shown here.
This diff is large: its 73 lines aren’t shown here.
This diff is large: its 25 lines aren’t shown here.
This diff is large: its 193 lines aren’t shown here.
This diff is large: its 105 lines aren’t shown here.
This diff is large: its 97 lines aren’t shown here.
This diff is large: its 233 lines aren’t shown here.
This diff is large: its 233 lines aren’t shown here.
This diff is large: its 54 lines aren’t shown here.
This diff is large: its 83 lines aren’t shown here.
This diff is large: its 51 lines aren’t shown here.
This diff is large: its 53 lines aren’t shown here.
This diff is large: its 31 lines aren’t shown here.
This diff is large: its 51 lines aren’t shown here.
This diff is large: its 123 lines aren’t shown here.
This diff is large: its 97 lines aren’t shown here.
This diff is large: its 26 lines aren’t shown here.
This diff is large: its 79 lines aren’t shown here.
This diff is large: its 157 lines aren’t shown here.
This diff is large: its 157 lines aren’t shown here.
This diff is large: its 157 lines aren’t shown here.
This diff is large: its 73 lines aren’t shown here.
This diff is large: its 76 lines aren’t shown here.
This diff is large: its 241 lines aren’t shown here.
This diff is large: its 61 lines aren’t shown here.
This diff is large: its 151 lines aren’t shown here.
This diff is large: its 189 lines aren’t shown here.
This diff is large: its 91 lines aren’t shown here.
This diff is large: its 27 lines aren’t shown here.
This diff is large: its 34 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 21 lines aren’t shown here.
This diff is large: its 5 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 35 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 6 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 19 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 5 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 47 lines aren’t shown here.
This diff is large: its 6 lines aren’t shown here.
This diff is large: its 53 lines aren’t shown here.
This diff is large: its 19 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 5 lines aren’t shown here.
This diff is large: its 19 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 43 lines aren’t shown here.
This diff is large: its 29 lines aren’t shown here.
This diff is large: its 22 lines aren’t shown here.
This diff is large: its 41 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 2812 lines aren’t shown here.
This diff is large: its 186 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 66 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 48 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 40 lines aren’t shown here.
This diff is large: its 32 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 28 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 48 lines aren’t shown here.
This diff is large: its 36 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 32 lines aren’t shown here.
This diff is large: its 37 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 40 lines aren’t shown here.
This diff is large: its 22 lines aren’t shown here.
This diff is large: its 29 lines aren’t shown here.
This diff is large: its 694 lines aren’t shown here.
This diff is large: its 318 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 39 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 89 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 29 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 80 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 22 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 134 lines aren’t shown here.
This diff is large: its 23 lines aren’t shown here.
This diff is large: its 50 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 50 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 196 lines aren’t shown here.
This diff is large: its 68 lines aren’t shown here.
This diff is large: its 54 lines aren’t shown here.
This diff is large: its 295 lines aren’t shown here.
This diff is large: its 85 lines aren’t shown here.
This diff is large: its 94 lines aren’t shown here.
This diff is large: its 114 lines aren’t shown here.
This diff is large: its 104 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 41 lines aren’t shown here.
This diff is large: its 6 lines aren’t shown here.
This diff is large: its 117 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 25 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 92 lines aren’t shown here.
This diff is large: its 67 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 148 lines aren’t shown here.
This diff is large: its 37 lines aren’t shown here.
This diff is large: its 32 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 26 lines aren’t shown here.
This diff is large: its 172 lines aren’t shown here.
This diff is large: its 47 lines aren’t shown here.
This diff is large: its 5 lines aren’t shown here.
This diff is large: its 26 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 55 lines aren’t shown here.
This diff is large: its 102 lines aren’t shown here.
This diff is large: its 21 lines aren’t shown here.
This diff is large: its 42 lines aren’t shown here.
This diff is large: its 69 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 69 lines aren’t shown here.
This diff is large: its 7 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 243 lines aren’t shown here.
This diff is large: its 294 lines aren’t shown here.
This diff is large: its 86 lines aren’t shown here.
This diff is large: its 255 lines aren’t shown here.
This diff is large: its 593 lines aren’t shown here.
This diff is large: its 115 lines aren’t shown here.
This diff is large: its 109 lines aren’t shown here.
This diff is large: its 40 lines aren’t shown here.
This diff is large: its 28 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 41 lines aren’t shown here.
This diff is large: its 100 lines aren’t shown here.
This diff is large: its 589 lines aren’t shown here.
This diff is large: its 26 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 61 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 195 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 89 lines aren’t shown here.
This diff is large: its 47 lines aren’t shown here.
This diff is large: its 27 lines aren’t shown here.
This diff is large: its 179 lines aren’t shown here.
This diff is large: its 51 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 221 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 145 lines aren’t shown here.
This diff is large: its 316 lines aren’t shown here.
This diff is large: its 57 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 103 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 285 lines aren’t shown here.
This diff is large: its 24 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 103 lines aren’t shown here.
This diff is large: its 69 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 57 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 31 lines aren’t shown here.
This diff is large: its 53 lines aren’t shown here.
This diff is large: its 21 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 37 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 22 lines aren’t shown here.
This diff is large: its 70 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 48 lines aren’t shown here.
This diff is large: its 68 lines aren’t shown here.
This diff is large: its 423 lines aren’t shown here.
This diff is large: its 309 lines aren’t shown here.
This diff is large: its 36 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 43 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 19 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 65 lines aren’t shown here.
This diff is large: its 142 lines aren’t shown here.
This diff is large: its 49 lines aren’t shown here.
This diff is large: its 79 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 121 lines aren’t shown here.
This diff is large: its 39 lines aren’t shown here.
This diff is large: its 63 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 233 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 61 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 56 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 181 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 83 lines aren’t shown here.
This diff is large: its 25 lines aren’t shown here.
This diff is large: its 100 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 32 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 928 lines aren’t shown here.
This diff is large: its 37 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 43 lines aren’t shown here.
This diff is large: its 22 lines aren’t shown here.
This diff is large: its 110 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 272 lines aren’t shown here.
This diff is large: its 168 lines aren’t shown here.
This diff is large: its 356 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 67 lines aren’t shown here.
This diff is large: its 41 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 39 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 62 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 136 lines aren’t shown here.
This diff is large: its 184 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 29 lines aren’t shown here.
This diff is large: its 383 lines aren’t shown here.
This diff is large: its 45 lines aren’t shown here.
This diff is large: its 32 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 246 lines aren’t shown here.
This diff is large: its 6 lines aren’t shown here.
This diff is large: its 30 lines aren’t shown here.
This diff is large: its 74 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 27 lines aren’t shown here.
This diff is large: its 114 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 27 lines aren’t shown here.
This diff is large: its 181 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 35 lines aren’t shown here.
This diff is large: its 19 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 28 lines aren’t shown here.
This diff is large: its 294 lines aren’t shown here.
This diff is large: its 38 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 47 lines aren’t shown here.
This diff is large: its 50 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 22 lines aren’t shown here.
This diff is large: its 133 lines aren’t shown here.
This diff is large: its 82 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 370 lines aren’t shown here.
This diff is large: its 38 lines aren’t shown here.
This diff is large: its 45 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 202 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 317 lines aren’t shown here.
This diff is large: its 43 lines aren’t shown here.
This diff is large: its 23 lines aren’t shown here.
This diff is large: its 727 lines aren’t shown here.
This diff is large: its 27 lines aren’t shown here.
This diff is large: its 50 lines aren’t shown here.
This diff is large: its 22 lines aren’t shown here.
This diff is large: its 138 lines aren’t shown here.
This diff is large: its 65 lines aren’t shown here.
This diff is large: its 27 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
File renamed without changes.
This diff is large: its 400 lines aren’t shown here.
This diff is large: its 85 lines aren’t shown here.
This diff is large: its 32 lines aren’t shown here.
This diff is large: its 67 lines aren’t shown here.
This diff is large: its 238 lines aren’t shown here.
This diff is large: its 63 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 27 lines aren’t shown here.
This diff is large: its 99 lines aren’t shown here.
This diff is large: its 70 lines aren’t shown here.
This diff is large: its 27 lines aren’t shown here.
This diff is large: its 6 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 47 lines aren’t shown here.
This diff is large: its 28 lines aren’t shown here.
This diff is large: its 59 lines aren’t shown here.
This diff is large: its 19 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 193 lines aren’t shown here.
This diff is large: its 24 lines aren’t shown here.
This diff is large: its 260 lines aren’t shown here.
This diff is large: its 31 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 33 lines aren’t shown here.
This diff is large: its 43 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 591 lines aren’t shown here.
This diff is large: its 35 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 149 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 214 lines aren’t shown here.
This diff is large: its 678 lines aren’t shown here.
This diff is large: its 319 lines aren’t shown here.
This diff is large: its 154 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 42 lines aren’t shown here.
This diff is large: its 62 lines aren’t shown here.
This diff is large: its 56 lines aren’t shown here.
This diff is large: its 64 lines aren’t shown here.
This diff is large: its 97 lines aren’t shown here.
This diff is large: its 62 lines aren’t shown here.
This diff is large: its 41 lines aren’t shown here.
This diff is large: its 42 lines aren’t shown here.
This diff is large: its 561 lines aren’t shown here.
This diff is large: its 88 lines aren’t shown here.
This diff is large: its 77 lines aren’t shown here.
This diff is large: its 6 lines aren’t shown here.
This diff is large: its 43 lines aren’t shown here.
This diff is large: its 80 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 188 lines aren’t shown here.
This diff is large: its 271 lines aren’t shown here.
This diff is large: its 411 lines aren’t shown here.
This diff is large: its 532 lines aren’t shown here.
This diff is large: its 136 lines aren’t shown here.
This diff is large: its 367 lines aren’t shown here.
This diff is large: its 172 lines aren’t shown here.
This diff is large: its 136 lines aren’t shown here.
This diff is large: its 399 lines aren’t shown here.
This diff is large: its 160 lines aren’t shown here.
This diff is large: its 396 lines aren’t shown here.
This diff is large: its 115 lines aren’t shown here.
This diff is large: its 49 lines aren’t shown here.
This diff is large: its 91 lines aren’t shown here.
This diff is large: its 166 lines aren’t shown here.
This diff is large: its 107 lines aren’t shown here.
This diff is large: its 19 lines aren’t shown here.
This diff is large: its 532 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 665 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 33 lines aren’t shown here.
This diff is large: its 6 lines aren’t shown here.
This diff is large: its 243 lines aren’t shown here.
This diff is large: its 172 lines aren’t shown here.
This diff is large: its 104 lines aren’t shown here.
This diff is large: its 131 lines aren’t shown here.
This diff is large: its 34 lines aren’t shown here.
This diff is large: its 59 lines aren’t shown here.
This diff is large: its 21 lines aren’t shown here.
This diff is large: its 7 lines aren’t shown here.
This diff is large: its 224 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 48 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 160 lines aren’t shown here.
This diff is large: its 57 lines aren’t shown here.
This diff is large: its 223 lines aren’t shown here.
This diff is large: its 67 lines aren’t shown here.
This diff is large: its 518 lines aren’t shown here.
This diff is large: its 160 lines aren’t shown here.
This diff is large: its 292 lines aren’t shown here.
This diff is large: its 115 lines aren’t shown here.
This diff is large: its 46 lines aren’t shown here.
This diff is large: its 2820 lines aren’t shown here.
This diff is large: its 2994 lines aren’t shown here.
This diff is large: its 2695 lines aren’t shown here.
This diff is large: its 2322 lines aren’t shown here.
This diff is large: its 2626 lines aren’t shown here.
This diff is large: its 64 lines aren’t shown here.
This diff is large: its 38 lines aren’t shown here.
This diff is large: its 207 lines aren’t shown here.
This diff is large: its 1114 lines aren’t shown here.
This diff is large: its 854 lines aren’t shown here.
This diff is large: its 818 lines aren’t shown here.
This diff is large: its 129 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 186 lines aren’t shown here.
This diff is large: its 105 lines aren’t shown here.
This diff is large: its 234 lines aren’t shown here.
This diff is large: its 299 lines aren’t shown here.
This diff is large: its 6 lines aren’t shown here.
This diff is large: its 32 lines aren’t shown here.
This diff is large: its 153 lines aren’t shown here.
This diff is large: its 366 lines aren’t shown here.
This diff is large: its 152 lines aren’t shown here.
This diff is large: its 26 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 91 lines aren’t shown here.
This diff is large: its 21 lines aren’t shown here.
This diff is large: its 630 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 236 lines aren’t shown here.
This diff is large: its 55 lines aren’t shown here.
This diff is large: its 127 lines aren’t shown here.
This diff is large: its 787 lines aren’t shown here.
This diff is large: its 216 lines aren’t shown here.
This diff is large: its 112 lines aren’t shown here.
This diff is large: its 675 lines aren’t shown here.
This diff is large: its 133 lines aren’t shown here.
This diff is large: its 150 lines aren’t shown here.
This diff is large: its 2024 lines aren’t shown here.
This diff is large: its 1425 lines aren’t shown here.
This diff is large: its 1137 lines aren’t shown here.
This diff is large: its 1808 lines aren’t shown here.
This diff is large: its 235 lines aren’t shown here.
This diff is large: its 260 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 224 lines aren’t shown here.
This diff is large: its 134 lines aren’t shown here.
This diff is large: its 162 lines aren’t shown here.
This diff is large: its 402 lines aren’t shown here.
This diff is large: its 119 lines aren’t shown here.
This diff is large: its 317 lines aren’t shown here.
This diff is large: its 256 lines aren’t shown here.
This diff is large: its 333 lines aren’t shown here.
This diff is large: its 168 lines aren’t shown here.
This diff is large: its 71 lines aren’t shown here.
This diff is large: its 270 lines aren’t shown here.
This diff is large: its 488 lines aren’t shown here.
This diff is large: its 559 lines aren’t shown here.
This diff is large: its 67 lines aren’t shown here.
This diff is large: its 250 lines aren’t shown here.
This diff is large: its 126 lines aren’t shown here.
This diff is large: its 247 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 6 lines aren’t shown here.
This diff is large: its 136 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 57 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 65 lines aren’t shown here.
This diff is large: its 21 lines aren’t shown here.
This diff is large: its 57 lines aren’t shown here.
This diff is large: its 170 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 61 lines aren’t shown here.
This diff is large: its 83 lines aren’t shown here.
This diff is large: its 324 lines aren’t shown here.
This diff is large: its 21 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 181 lines aren’t shown here.
This diff is large: its 46 lines aren’t shown here.
This diff is large: its 37 lines aren’t shown here.
This diff is large: its 76 lines aren’t shown here.
This diff is large: its 26 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 120 lines aren’t shown here.
This diff is large: its 135 lines aren’t shown here.
This diff is large: its 114 lines aren’t shown here.
This diff is large: its 207 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 209 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 62 lines aren’t shown here.
This diff is large: its 95 lines aren’t shown here.
This diff is large: its 40 lines aren’t shown here.
This diff is large: its 215 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 56 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 27 lines aren’t shown here.
This diff is large: its 50 lines aren’t shown here.
This diff is large: its 114 lines aren’t shown here.
This diff is large: its 67 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 41 lines aren’t shown here.
This diff is large: its 39 lines aren’t shown here.
This diff is large: its 109 lines aren’t shown here.
This diff is large: its 71 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 21 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 170 lines aren’t shown here.
This diff is large: its 239 lines aren’t shown here.
This diff is large: its 51 lines aren’t shown here.
This diff is large: its 42 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 197 lines aren’t shown here.
This diff is large: its 154 lines aren’t shown here.
This diff is large: its 189 lines aren’t shown here.
This diff is large: its 80 lines aren’t shown here.
This diff is large: its 25 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 366 lines aren’t shown here.
This diff is large: its 280 lines aren’t shown here.
This diff is large: its 370 lines aren’t shown here.
This diff is large: its 433 lines aren’t shown here.
This diff is large: its 518 lines aren’t shown here.
This diff is large: its 198 lines aren’t shown here.
This diff is large: its 596 lines aren’t shown here.
This diff is large: its 273 lines aren’t shown here.
This diff is large: its 2025 lines aren’t shown here.
This diff is large: its 362 lines aren’t shown here.
This diff is large: its 904 lines aren’t shown here.
This diff is large: its 1101 lines aren’t shown here.
This diff is large: its 37 lines aren’t shown here.
This diff is large: its 48 lines aren’t shown here.
This diff is large: its 45 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 21 lines aren’t shown here.
This diff is large: its 111 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 40 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 110 lines aren’t shown here.
This diff is large: its 25 lines aren’t shown here.
This diff is large: its 708 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 90 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 85 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 58 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 431 lines aren’t shown here.
This diff is large: its 95 lines aren’t shown here.
This diff is large: its 700 lines aren’t shown here.
This diff is large: its 54 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 171 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 34 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 322 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 85 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 151 lines aren’t shown here.
This diff is large: its 68 lines aren’t shown here.
This diff is large: its 753 lines aren’t shown here.
This diff is large: its 50 lines aren’t shown here.
This diff is large: its 23 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 74 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 72 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 118 lines aren’t shown here.
This diff is large: its 38 lines aren’t shown here.
This diff is large: its 142 lines aren’t shown here.
This diff is large: its 46 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 35 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 359 lines aren’t shown here.
This diff is large: its 50 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 70 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 243 lines aren’t shown here.
This diff is large: its 66 lines aren’t shown here.
This diff is large: its 79 lines aren’t shown here.
This diff is large: its 26 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 357 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 157 lines aren’t shown here.
This diff is large: its 23 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 568 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 109 lines aren’t shown here.
This diff is large: its 42 lines aren’t shown here.
This diff is large: its 433 lines aren’t shown here.
This diff is large: its 33 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 21 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 164 lines aren’t shown here.
This diff is large: its 67 lines aren’t shown here.
This diff is large: its 535 lines aren’t shown here.
This diff is large: its 47 lines aren’t shown here.
This diff is large: its 22 lines aren’t shown here.
This diff is large: its 25 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 63 lines aren’t shown here.
This diff is large: its 90 lines aren’t shown here.
This diff is large: its 27 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 5 lines aren’t shown here.
This diff is large: its 165 lines aren’t shown here.
This diff is large: its 179 lines aren’t shown here.
This diff is large: its 216 lines aren’t shown here.
This diff is large: its 178 lines aren’t shown here.
This diff is large: its 295 lines aren’t shown here.
This diff is large: its 547 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 19 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 47 lines aren’t shown here.
This diff is large: its 54 lines aren’t shown here.
This diff is large: its 96 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 38 lines aren’t shown here.
This diff is large: its 41 lines aren’t shown here.
This diff is large: its 45 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 629 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 32 lines aren’t shown here.
This diff is large: its 130 lines aren’t shown here.
This diff is large: its 40 lines aren’t shown here.
This diff is large: its 247 lines aren’t shown here.
This diff is large: its 53 lines aren’t shown here.
This diff is large: its 316 lines aren’t shown here.
This diff is large: its 101 lines aren’t shown here.
This diff is large: its 112 lines aren’t shown here.
This diff is large: its 19 lines aren’t shown here.
This diff is large: its 79 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 52 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 77 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 27 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 133 lines aren’t shown here.
This diff is large: its 19 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 27 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 114 lines aren’t shown here.
This diff is large: its 45 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 29 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 40 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 63 lines aren’t shown here.
This diff is large: its 30 lines aren’t shown here.
This diff is large: its 108 lines aren’t shown here.
This diff is large: its 691 lines aren’t shown here.
This diff is large: its 155 lines aren’t shown here.
This diff is large: its 297 lines aren’t shown here.
This diff is large: its 425 lines aren’t shown here.
This diff is large: its 289 lines aren’t shown here.
This diff is large: its 115 lines aren’t shown here.
This diff is large: its 51 lines aren’t shown here.
This diff is large: its 187 lines aren’t shown here.
This diff is large: its 154 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 95 lines aren’t shown here.
This diff is large: its 315 lines aren’t shown here.
This diff is large: its 551 lines aren’t shown here.
This diff is large: its 134 lines aren’t shown here.
This diff is large: its 159 lines aren’t shown here.
This diff is large: its 41 lines aren’t shown here.
This diff is large: its 191 lines aren’t shown here.
This diff is large: its 68 lines aren’t shown here.
This diff is large: its 215 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 231 lines aren’t shown here.
This diff is large: its 1169 lines aren’t shown here.
This diff is large: its 410 lines aren’t shown here.
This diff is large: its 130 lines aren’t shown here.
This diff is large: its 315 lines aren’t shown here.
This diff is large: its 35 lines aren’t shown here.
This diff is large: its 187 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 121 lines aren’t shown here.
This diff is large: its 195 lines aren’t shown here.
This diff is large: its 32 lines aren’t shown here.
This diff is large: its 118 lines aren’t shown here.
This diff is large: its 105 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 1163 lines aren’t shown here.
This diff is large: its 2584 lines aren’t shown here.
This diff is large: its 146 lines aren’t shown here.
This diff is large: its 117 lines aren’t shown here.
This diff is large: its 171 lines aren’t shown here.
This diff is large: its 71 lines aren’t shown here.
This diff is large: its 198 lines aren’t shown here.
This diff is large: its 579 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 36 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 22 lines aren’t shown here.
This diff is large: its 30 lines aren’t shown here.
This diff is large: its 21 lines aren’t shown here.
This diff is large: its 27 lines aren’t shown here.
This diff is large: its 27 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 34 lines aren’t shown here.
This diff is large: its 34 lines aren’t shown here.
This diff is large: its 160 lines aren’t shown here.
This diff is large: its 250 lines aren’t shown here.
This diff is large: its 341 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 212 lines aren’t shown here.
This diff is large: its 81 lines aren’t shown here.
This diff is large: its 30 lines aren’t shown here.
This diff is large: its 71 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 303 lines aren’t shown here.
This diff is large: its 68 lines aren’t shown here.
This diff is large: its 135 lines aren’t shown here.
This diff is large: its 99 lines aren’t shown here.
This diff is large: its 285 lines aren’t shown here.
This diff is large: its 158 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 265 lines aren’t shown here.
This diff is large: its 95 lines aren’t shown here.
This diff is large: its 27 lines aren’t shown here.
This diff is large: its 94 lines aren’t shown here.
This diff is large: its 158 lines aren’t shown here.
This diff is large: its 102 lines aren’t shown here.
This diff is large: its 27 lines aren’t shown here.
This diff is large: its 1037 lines aren’t shown here.
This diff is large: its 570 lines aren’t shown here.
This diff is large: its 259 lines aren’t shown here.
This diff is large: its 112 lines aren’t shown here.
This diff is large: its 351 lines aren’t shown here.
This diff is large: its 214 lines aren’t shown here.
This diff is large: its 390 lines aren’t shown here.
This diff is large: its 174 lines aren’t shown here.
This diff is large: its 42 lines aren’t shown here.
This diff is large: its 79 lines aren’t shown here.
This diff is large: its 47 lines aren’t shown here.
This diff is large: its 145 lines aren’t shown here.
This diff is large: its 98 lines aren’t shown here.
This diff is large: its 204 lines aren’t shown here.
This diff is large: its 222 lines aren’t shown here.
This diff is large: its 106 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 277 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 88 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 149 lines aren’t shown here.
This diff is large: its 69 lines aren’t shown here.
This diff is large: its 48 lines aren’t shown here.
This diff is large: its 43 lines aren’t shown here.
This diff is large: its 30 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 30 lines aren’t shown here.
This diff is large: its 120 lines aren’t shown here.
This diff is large: its 60 lines aren’t shown here.
This diff is large: its 75 lines aren’t shown here.
This diff is large: its 240 lines aren’t shown here.
This diff is large: its 210 lines aren’t shown here.
This diff is large: its 153 lines aren’t shown here.
This diff is large: its 103 lines aren’t shown here.
This diff is large: its 47 lines aren’t shown here.
This diff is large: its 44 lines aren’t shown here.
This diff is large: its 26 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 73 lines aren’t shown here.
This diff is large: its 19 lines aren’t shown here.
This diff is large: its 19 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 55 lines aren’t shown here.
This diff is large: its 38 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 609 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 1409 lines aren’t shown here.
This diff is large: its 35 lines aren’t shown here.
This diff is large: its 273 lines aren’t shown here.
This diff is large: its 324 lines aren’t shown here.
This diff is large: its 43 lines aren’t shown here.
This diff is large: its 474 lines aren’t shown here.
This diff is large: its 751 lines aren’t shown here.
This diff is large: its 813 lines aren’t shown here.
This diff is large: its 813 lines aren’t shown here.
This diff is large: its 813 lines aren’t shown here.
This diff is large: its 720 lines aren’t shown here.
This diff is large: its 41 lines aren’t shown here.
This diff is large: its 917 lines aren’t shown here.
This diff is large: its 1344 lines aren’t shown here.
This diff is large: its 1344 lines aren’t shown here.
This diff is large: its 1306 lines aren’t shown here.
This diff is large: its 1306 lines aren’t shown here.
This diff is large: its 191 lines aren’t shown here.
This diff is large: its 237 lines aren’t shown here.
This diff is large: its 232 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 24 lines aren’t shown here.
This diff is large: its 44 lines aren’t shown here.
This diff is large: its 39 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 38 lines aren’t shown here.
This diff is large: its 67 lines aren’t shown here.
This diff is large: its 32 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 52 lines aren’t shown here.
This diff is large: its 27 lines aren’t shown here.
This diff is large: its 47 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 27 lines aren’t shown here.
This diff is large: its 75 lines aren’t shown here.
This diff is large: its 68 lines aren’t shown here.
This diff is large: its 138 lines aren’t shown here.
This diff is large: its 98 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 73 lines aren’t shown here.
This diff is large: its 83 lines aren’t shown here.
This diff is large: its 24 lines aren’t shown here.
This diff is large: its 63 lines aren’t shown here.
This diff is large: its 60 lines aren’t shown here.
This diff is large: its 46 lines aren’t shown here.
This diff is large: its 61 lines aren’t shown here.
This diff is large: its 66 lines aren’t shown here.
This diff is large: its 19 lines aren’t shown here.
This diff is large: its 64 lines aren’t shown here.
This diff is large: its 63 lines aren’t shown here.
This diff is large: its 73 lines aren’t shown here.
This diff is large: its 64 lines aren’t shown here.
This diff is large: its 76 lines aren’t shown here.
This diff is large: its 46 lines aren’t shown here.
This diff is large: its 111 lines aren’t shown here.
This diff is large: its 30 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 43 lines aren’t shown here.
This diff is large: its 49 lines aren’t shown here.
This diff is large: its 58 lines aren’t shown here.
This diff is larger than a page shows: the files after these aren’t listed. Clone the repository to see all of it.