diff --git a/[refs] b/[refs] index 392e6d8dca05..fa1856ae20c3 100644 --- a/[refs] +++ b/[refs] @@ -1,2 +1,2 @@ --- -refs/heads/master: 5042ab91c4272e158748180ae70a2e097f9e90e3 +refs/heads/master: 514b1923e1549162f1597f81113c0e5b72aed691 diff --git a/trunk/CREDITS b/trunk/CREDITS index 370b4c7da39b..d8fe12a9421f 100644 --- a/trunk/CREDITS +++ b/trunk/CREDITS @@ -3814,8 +3814,8 @@ D: INFO-SHEET, former maintainer D: Author of the longest-living linux bug N: Jonathan Woithe -E: jwoithe@physics.adelaide.edu.au -W: http://www.physics.adelaide.edu.au/~jwoithe +E: jwoithe@just42.net +W: http:/www.just42.net/jwoithe D: ALS-007 sound card extensions to Sound Blaster driver S: 20 Jordan St S: Valley View, SA 5093 diff --git a/trunk/Documentation/ABI/testing/debugfs-pfo-nx-crypto b/trunk/Documentation/ABI/testing/debugfs-pfo-nx-crypto new file mode 100644 index 000000000000..685d5a448423 --- /dev/null +++ b/trunk/Documentation/ABI/testing/debugfs-pfo-nx-crypto @@ -0,0 +1,45 @@ +What: /sys/kernel/debug/nx-crypto/* +Date: March 2012 +KernelVersion: 3.4 +Contact: Kent Yoder +Description: + + These debugfs interfaces are built by the nx-crypto driver, built in +arch/powerpc/crypto/nx. + +Error Detection +=============== + +errors: +- A u32 providing a total count of errors since the driver was loaded. The +only errors counted here are those returned from the hcall, H_COP_OP. + +last_error: +- The most recent non-zero return code from the H_COP_OP hcall. -EBUSY is not +recorded here (the hcall will retry until -EBUSY goes away). + +last_error_pid: +- The process ID of the process who received the most recent error from the +hcall. + +Device Use +========== + +aes_bytes: +- The total number of bytes encrypted using AES in any of the driver's +supported modes. + +aes_ops: +- The total number of AES operations submitted to the hardware. + +sha256_bytes: +- The total number of bytes hashed by the hardware using SHA-256. + +sha256_ops: +- The total number of SHA-256 operations submitted to the hardware. + +sha512_bytes: +- The total number of bytes hashed by the hardware using SHA-512. + +sha512_ops: +- The total number of SHA-512 operations submitted to the hardware. diff --git a/trunk/Documentation/ABI/testing/dev-kmsg b/trunk/Documentation/ABI/testing/dev-kmsg new file mode 100644 index 000000000000..281ecc5f9709 --- /dev/null +++ b/trunk/Documentation/ABI/testing/dev-kmsg @@ -0,0 +1,90 @@ +What: /dev/kmsg +Date: Mai 2012 +KernelVersion: 3.5 +Contact: Kay Sievers +Description: The /dev/kmsg character device node provides userspace access + to the kernel's printk buffer. + + Injecting messages: + Every write() to the opened device node places a log entry in + the kernel's printk buffer. + + The logged line can be prefixed with a syslog prefix, which + carries the syslog priority and facility. The single decimal + prefix number is composed of the 3 lowest bits being the syslog + priority and the higher bits the syslog facility number. + + If no prefix is given, the priority number is the default kernel + log priority and the facility number is set to LOG_USER (1). It + is not possible to inject messages from userspace with the + facility number LOG_KERN (0), to make sure that the origin of + the messages can always be reliably determined. + + Accessing the buffer: + Every read() from the opened device node receives one record + of the kernel's printk buffer. + + The first read() directly following an open() always returns + first message in the buffer; there is no kernel-internal + persistent state; many readers can concurrently open the device + and read from it, without affecting other readers. + + Every read() will receive the next available record. If no more + records are available read() will block, or if O_NONBLOCK is + used -EAGAIN returned. + + Messages in the record ring buffer get overwritten as whole, + there are never partial messages received by read(). + + In case messages get overwritten in the circular buffer while + the device is kept open, the next read() will return -EPIPE, + and the seek position be updated to the next available record. + Subsequent reads() will return available records again. + + Unlike the classic syslog() interface, the 64 bit record + sequence numbers allow to calculate the amount of lost + messages, in case the buffer gets overwritten. And they allow + to reconnect to the buffer and reconstruct the read position + if needed, without limiting the interface to a single reader. + + The device supports seek with the following parameters: + SEEK_SET, 0 + seek to the first entry in the buffer + SEEK_END, 0 + seek after the last entry in the buffer + SEEK_DATA, 0 + seek after the last record available at the time + the last SYSLOG_ACTION_CLEAR was issued. + + The output format consists of a prefix carrying the syslog + prefix including priority and facility, the 64 bit message + sequence number and the monotonic timestamp in microseconds. + The values are separated by a ','. Future extensions might + add more comma separated values before the terminating ';'. + Unknown values should be gracefully ignored. + + The human readable text string starts directly after the ';' + and is terminated by a '\n'. Untrusted values derived from + hardware or other facilities are printed, therefore + all non-printable characters in the log message are escaped + by "\x00" C-style hex encoding. + + A line starting with ' ', is a continuation line, adding + key/value pairs to the log message, which provide the machine + readable context of the message, for reliable processing in + userspace. + + Example: + 7,160,424069;pci_root PNP0A03:00: host bridge window [io 0x0000-0x0cf7] (ignored) + SUBSYSTEM=acpi + DEVICE=+acpi:PNP0A03:00 + 6,339,5140900;NET: Registered protocol family 10 + 30,340,5690716;udevd[80]: starting version 181 + + The DEVICE= key uniquely identifies devices the following way: + b12:8 - block dev_t + c127:3 - char dev_t + n8 - netdev ifindex + +sound:card0 - subsystem:devname + +Users: dmesg(1), userspace kernel log consumers diff --git a/trunk/drivers/staging/iio/Documentation/sysfs-bus-iio b/trunk/Documentation/ABI/testing/sysfs-bus-iio similarity index 96% rename from trunk/drivers/staging/iio/Documentation/sysfs-bus-iio rename to trunk/Documentation/ABI/testing/sysfs-bus-iio index 46a995d6d261..5bc8a476c15e 100644 --- a/trunk/drivers/staging/iio/Documentation/sysfs-bus-iio +++ b/trunk/Documentation/ABI/testing/sysfs-bus-iio @@ -108,7 +108,7 @@ Description: physically equivalent inputs when non differential readings are separately available. In differential only parts, then all that is required is a consistent labeling. Units after application - of scale and offset are nanofarads.. + of scale and offset are nanofarads. What: /sys/bus/iio/devices/iio:deviceX/in_temp_raw What: /sys/bus/iio/devices/iio:deviceX/in_tempX_raw @@ -119,7 +119,7 @@ KernelVersion: 2.6.35 Contact: linux-iio@vger.kernel.org Description: Raw (unscaled no bias removal etc) temperature measurement. - It an axis is specified it generally means that the temperature + If an axis is specified it generally means that the temperature sensor is associated with one part of a compound device (e.g. a gyroscope axis). Units after application of scale and offset are milli degrees Celsuis. @@ -232,7 +232,7 @@ Description: If known for a device, scale to be applied to Y[_name]_raw post addition of [Y][_name]_offset in order to obtain the measured value in units as specified in - [Y][_name]_raw documentation.. If shared across all in + [Y][_name]_raw documentation. If shared across all in channels then Y and are not present and the value is called [Y][_name]_scale. The peak modifier means this value is applied to Y[_name]_peak_raw values. @@ -243,6 +243,8 @@ What: /sys/bus/iio/devices/iio:deviceX/in_accel_z_calibbias What: /sys/bus/iio/devices/iio:deviceX/in_anglvel_x_calibbias What: /sys/bus/iio/devices/iio:deviceX/in_anglvel_y_calibbias What: /sys/bus/iio/devices/iio:deviceX/in_anglvel_z_calibbias +What: /sys/bus/iio/devices/iio:deviceX/in_illuminance0_calibbias +What: /sys/bus/iio/devices/iio:deviceX/in_proximity0_calibbias KernelVersion: 2.6.35 Contact: linux-iio@vger.kernel.org Description: @@ -258,6 +260,8 @@ What /sys/bus/iio/devices/iio:deviceX/in_accel_z_calibscale What /sys/bus/iio/devices/iio:deviceX/in_anglvel_x_calibscale What /sys/bus/iio/devices/iio:deviceX/in_anglvel_y_calibscale What /sys/bus/iio/devices/iio:deviceX/in_anglvel_z_calibscale +what /sys/bus/iio/devices/iio:deviceX/in_illuminance0_calibscale +what /sys/bus/iio/devices/iio:deviceX/in_proximity0_calibscale KernelVersion: 2.6.35 Contact: linux-iio@vger.kernel.org Description: @@ -276,6 +280,13 @@ Description: If a discrete set of scale values are available, they are listed in this attribute. +What /sys/bus/iio/devices/iio:deviceX/out_voltageY_hardwaregain +KernelVersion: 2.6.35 +Contact: linux-iio@vger.kernel.org +Description: + Hardware applied gain factor. If shared across all channels, + _hardwaregain is used. + What: /sys/.../in_accel_filter_low_pass_3db_frequency What: /sys/.../in_magn_filter_low_pass_3db_frequency What: /sys/.../in_anglvel_filter_low_pass_3db_frequency @@ -453,10 +464,14 @@ What: /sys/.../events/in_magn_z_raw_thresh_rising_value What: /sys/.../events/in_magn_z_raw_thresh_falling_value What: /sys/.../events/in_voltageY_supply_raw_thresh_rising_value What: /sys/.../events/in_voltageY_supply_raw_thresh_falling_value +What: /sys/.../events/in_voltageY_raw_thresh_rising_value What: /sys/.../events/in_voltageY_raw_thresh_falling_value -What: /sys/.../events/in_voltageY_raw_thresh_falling_value -What: /sys/.../events/in_tempY_raw_thresh_falling_value +What: /sys/.../events/in_tempY_raw_thresh_rising_value What: /sys/.../events/in_tempY_raw_thresh_falling_value +What: /sys/.../events/in_illuminance0_thresh_falling_value +what: /sys/.../events/in_illuminance0_thresh_rising_value +what: /sys/.../events/in_proximity0_thresh_falling_value +what: /sys/.../events/in_proximity0_thresh_rising_value KernelVersion: 2.6.37 Contact: linux-iio@vger.kernel.org Description: @@ -490,9 +505,9 @@ What: /sys/.../events/in_magn_z_raw_roc_rising_value What: /sys/.../events/in_magn_z_raw_roc_falling_value What: /sys/.../events/in_voltageY_supply_raw_roc_rising_value What: /sys/.../events/in_voltageY_supply_raw_roc_falling_value +What: /sys/.../events/in_voltageY_raw_roc_rising_value What: /sys/.../events/in_voltageY_raw_roc_falling_value -What: /sys/.../events/in_voltageY_raw_roc_falling_value -What: /sys/.../events/in_tempY_raw_roc_falling_value +What: /sys/.../events/in_tempY_raw_roc_rising_value What: /sys/.../events/in_tempY_raw_roc_falling_value KernelVersion: 2.6.37 Contact: linux-iio@vger.kernel.org @@ -556,6 +571,8 @@ What: /sys/.../events/in_tempY_thresh_falling_period What: /sys/.../events/in_tempY_roc_rising_period What: /sys/.../events/in_tempY_roc_falling_period What: /sys/.../events/in_accel_x&y&z_mag_falling_period +What: /sys/.../events/in_intensity0_thresh_period +What: /sys/.../events/in_proximity0_thresh_period KernelVersion: 2.6.37 Contact: linux-iio@vger.kernel.org Description: @@ -718,24 +735,3 @@ Contact: linux-iio@vger.kernel.org Description: This attribute is used to read the amount of quadrature error present in the device at a given time. - -What: /sys/.../iio:deviceX/ac_excitation_en -KernelVersion: 3.1.0 -Contact: linux-iio@vger.kernel.org -Description: - This attribute, if available, is used to enable the AC - excitation mode found on some converters. In ac excitation mode, - the polarity of the excitation voltage is reversed on - alternate cycles, to eliminate DC errors. - -What: /sys/.../iio:deviceX/bridge_switch_en -KernelVersion: 3.1.0 -Contact: linux-iio@vger.kernel.org -Description: - This attribute, if available, is used to close or open the - bridge power down switch found on some converters. - In bridge applications, such as strain gauges and load cells, - the bridge itself consumes the majority of the current in the - system. To minimize the current consumption of the system, - the bridge can be disconnected (when it is not being used - using the bridge_switch_en attribute. diff --git a/trunk/Documentation/ABI/testing/sysfs-bus-usb b/trunk/Documentation/ABI/testing/sysfs-bus-usb index 7c22a532fdfb..6df4e6f57560 100644 --- a/trunk/Documentation/ABI/testing/sysfs-bus-usb +++ b/trunk/Documentation/ABI/testing/sysfs-bus-usb @@ -135,6 +135,17 @@ Description: for the device and attempt to bind to it. For example: # echo "8086 10f5" > /sys/bus/usb/drivers/foo/new_id + Reading from this file will list all dynamically added + device IDs in the same format, with one entry per + line. For example: + # cat /sys/bus/usb/drivers/foo/new_id + 8086 10f5 + dead beef 06 + f00d cafe + + The list will be truncated at PAGE_SIZE bytes due to + sysfs restrictions. + What: /sys/bus/usb-serial/drivers/.../new_id Date: October 2011 Contact: linux-usb@vger.kernel.org @@ -157,6 +168,10 @@ Description: match the driver to the device. For example: # echo "046d c315" > /sys/bus/usb/drivers/foo/remove_id + Reading from this file will list the dynamically added + device IDs, exactly like reading from the entry + "/sys/bus/usb/drivers/.../new_id" + What: /sys/bus/usb/device/.../avoid_reset_quirk Date: December 2009 Contact: Oliver Neukum @@ -189,7 +204,7 @@ Contact: Matthew Garrett Description: Some information about whether a given USB device is physically fixed to the platform can be inferred from a - combination of hub decriptor bits and platform-specific data + combination of hub descriptor bits and platform-specific data such as ACPI. This file will read either "removable" or "fixed" if the information is available, and "unknown" - otherwise. \ No newline at end of file + otherwise. diff --git a/trunk/Documentation/ABI/testing/sysfs-class-extcon b/trunk/Documentation/ABI/testing/sysfs-class-extcon new file mode 100644 index 000000000000..20ab361bd8c6 --- /dev/null +++ b/trunk/Documentation/ABI/testing/sysfs-class-extcon @@ -0,0 +1,97 @@ +What: /sys/class/extcon/.../ +Date: February 2012 +Contact: MyungJoo Ham +Description: + Provide a place in sysfs for the extcon objects. + This allows accessing extcon specific variables. + The name of extcon object denoted as ... is the name given + with extcon_dev_register. + + One extcon device denotes a single external connector + port. An external connector may have multiple cables + attached simultaneously. Many of docks, cradles, and + accessory cables have such capability. For example, + the 30-pin port of Nuri board (/arch/arm/mach-exynos) + may have both HDMI and Charger attached, or analog audio, + video, and USB cables attached simulteneously. + + If there are cables mutually exclusive with each other, + such binary relations may be expressed with extcon_dev's + mutually_exclusive array. + +What: /sys/class/extcon/.../name +Date: February 2012 +Contact: MyungJoo Ham +Description: + The /sys/class/extcon/.../name shows the name of the extcon + object. If the extcon object has an optional callback + "show_name" defined, the callback will provide the name with + this sysfs node. + +What: /sys/class/extcon/.../state +Date: February 2012 +Contact: MyungJoo Ham +Description: + The /sys/class/extcon/.../state shows and stores the cable + attach/detach information of the corresponding extcon object. + If the extcon object has an optional callback "show_state" + defined, the showing function is overriden with the optional + callback. + + If the default callback for showing function is used, the + format is like this: + # cat state + USB_OTG=1 + HDMI=0 + TA=1 + EAR_JACK=0 + # + In this example, the extcon device have USB_OTG and TA + cables attached and HDMI and EAR_JACK cables detached. + + In order to update the state of an extcon device, enter a hex + state number starting with 0x. + echo 0xHEX > state + + This updates the whole state of the extcon dev. + Inputs of all the methods are required to meet the + mutually_exclusive contidions if they exist. + + It is recommended to use this "global" state interface if + you need to enter the value atomically. The later state + interface associated with each cable cannot update + multiple cable states of an extcon device simultaneously. + +What: /sys/class/extcon/.../cable.x/name +Date: February 2012 +Contact: MyungJoo Ham +Description: + The /sys/class/extcon/.../cable.x/name shows the name of cable + "x" (integer between 0 and 31) of an extcon device. + +What: /sys/class/extcon/.../cable.x/state +Date: February 2012 +Contact: MyungJoo Ham +Description: + The /sys/class/extcon/.../cable.x/name shows and stores the + state of cable "x" (integer between 0 and 31) of an extcon + device. The state value is either 0 (detached) or 1 + (attached). + +What: /sys/class/extcon/.../mutually_exclusive/... +Date: December 2011 +Contact: MyungJoo Ham +Description: + Shows the relations of mutually exclusiveness. For example, + if the mutually_exclusive array of extcon_dev is + {0x3, 0x5, 0xC, 0x0}, the, the output is: + # ls mutually_exclusive/ + 0x3 + 0x5 + 0xc + # + + Note that mutually_exclusive is a sub-directory of the extcon + device and the file names under the mutually_exclusive + directory show the mutually-exclusive sets, not the contents + of the files. diff --git a/trunk/Documentation/ABI/testing/sysfs-devices-system-cpu b/trunk/Documentation/ABI/testing/sysfs-devices-system-cpu index e7be75b96e4b..5dab36448b44 100644 --- a/trunk/Documentation/ABI/testing/sysfs-devices-system-cpu +++ b/trunk/Documentation/ABI/testing/sysfs-devices-system-cpu @@ -9,31 +9,6 @@ Description: /sys/devices/system/cpu/cpu#/ -What: /sys/devices/system/cpu/sched_mc_power_savings - /sys/devices/system/cpu/sched_smt_power_savings -Date: June 2006 -Contact: Linux kernel mailing list -Description: Discover and adjust the kernel's multi-core scheduler support. - - Possible values are: - - 0 - No power saving load balance (default value) - 1 - Fill one thread/core/package first for long running threads - 2 - Also bias task wakeups to semi-idle cpu package for power - savings - - sched_mc_power_savings is dependent upon SCHED_MC, which is - itself architecture dependent. - - sched_smt_power_savings is dependent upon SCHED_SMT, which - is itself architecture dependent. - - The two files are independent of each other. It is possible - that one file may be present without the other. - - Introduced by git commit 5c45bf27. - - What: /sys/devices/system/cpu/kernel_max /sys/devices/system/cpu/offline /sys/devices/system/cpu/online diff --git a/trunk/Documentation/ABI/testing/sysfs-driver-wacom b/trunk/Documentation/ABI/testing/sysfs-driver-wacom index 0130d6683c14..56c54558c8a4 100644 --- a/trunk/Documentation/ABI/testing/sysfs-driver-wacom +++ b/trunk/Documentation/ABI/testing/sysfs-driver-wacom @@ -9,6 +9,14 @@ Description: or 0 otherwise. Writing to this file one of these values switches reporting speed. +What: /sys/class/leds/0005\:056A\:00BD.0001\:selector\:*/ +Date: May 2012 +Kernel Version: 3.5 +Contact: linux-bluetooth@vger.kernel.org +Description: + LED selector for Intuos4 WL. There are 4 leds, but only one LED + can be lit at a time. Max brightness is 127. + What: /sys/bus/usb/devices/-:./wacom_led/led Date: August 2011 Contact: linux-input@vger.kernel.org diff --git a/trunk/Documentation/DocBook/kernel-hacking.tmpl b/trunk/Documentation/DocBook/kernel-hacking.tmpl index 07a9c48de5a2..eee71426ecb8 100644 --- a/trunk/Documentation/DocBook/kernel-hacking.tmpl +++ b/trunk/Documentation/DocBook/kernel-hacking.tmpl @@ -1289,7 +1289,7 @@ static struct block_device_operations opt_fops = { * Sparc assembly will do this to ya. */ C_LABEL(cputypvar): - .asciz "compatability" + .asciz "compatibility" /* Tested on SS-5, SS-10. Probably someone at Sun applied a spell-checker. */ .align 4 diff --git a/trunk/Documentation/DocBook/libata.tmpl b/trunk/Documentation/DocBook/libata.tmpl index 31df1aa00710..deb71baed328 100644 --- a/trunk/Documentation/DocBook/libata.tmpl +++ b/trunk/Documentation/DocBook/libata.tmpl @@ -918,7 +918,7 @@ and other resources, etc. HSM violation This error is indicated when STATUS value doesn't match HSM - requirement during issuing or excution any ATA/ATAPI command. + requirement during issuing or execution any ATA/ATAPI command. diff --git a/trunk/Documentation/DocBook/media/v4l/controls.xml b/trunk/Documentation/DocBook/media/v4l/controls.xml index b84f25e9cc87..dd03cf4a6539 100644 --- a/trunk/Documentation/DocBook/media/v4l/controls.xml +++ b/trunk/Documentation/DocBook/media/v4l/controls.xml @@ -2023,7 +2023,7 @@ Possible values are: integer Cyclic intra macroblock refresh. This is the number of continuous macroblocks -refreshed every frame. Each frame a succesive set of macroblocks is refreshed until the cycle completes and starts from the +refreshed every frame. Each frame a successive set of macroblocks is refreshed until the cycle completes and starts from the top of the frame. Applicable to H264, H263 and MPEG4 encoder. @@ -2183,7 +2183,7 @@ Applicable to the MPEG4 and H264 encoders. integer The Video Buffer Verifier size in kilobytes, it is used as a limitation of frame skip. -The VBV is defined in the standard as a mean to verify that the produced stream will be succesfully decoded. +The VBV is defined in the standard as a mean to verify that the produced stream will be successfully decoded. The standard describes it as "Part of a hypothetical decoder that is conceptually connected to the output of the encoder. Its purpose is to provide a constraint on the variability of the data rate that an encoder or editing process may produce.". @@ -2196,7 +2196,7 @@ Applicable to the MPEG1, MPEG2, MPEG4 encoders. integer The Coded Picture Buffer size in kilobytes, it is used as a limitation of frame skip. -The CPB is defined in the H264 standard as a mean to verify that the produced stream will be succesfully decoded. +The CPB is defined in the H264 standard as a mean to verify that the produced stream will be successfully decoded. Applicable to the H264 encoder. diff --git a/trunk/Documentation/HOWTO b/trunk/Documentation/HOWTO index f7ade3b3b40d..59c080f084ef 100644 --- a/trunk/Documentation/HOWTO +++ b/trunk/Documentation/HOWTO @@ -218,16 +218,16 @@ The development process Linux kernel development process currently consists of a few different main kernel "branches" and lots of different subsystem-specific kernel branches. These different branches are: - - main 2.6.x kernel tree - - 2.6.x.y -stable kernel tree - - 2.6.x -git kernel patches + - main 3.x kernel tree + - 3.x.y -stable kernel tree + - 3.x -git kernel patches - subsystem specific kernel trees and patches - - the 2.6.x -next kernel tree for integration tests + - the 3.x -next kernel tree for integration tests -2.6.x kernel tree +3.x kernel tree ----------------- -2.6.x kernels are maintained by Linus Torvalds, and can be found on -kernel.org in the pub/linux/kernel/v2.6/ directory. Its development +3.x kernels are maintained by Linus Torvalds, and can be found on +kernel.org in the pub/linux/kernel/v3.x/ directory. Its development process is as follows: - As soon as a new kernel is released a two weeks window is open, during this period of time maintainers can submit big diffs to @@ -262,20 +262,20 @@ mailing list about kernel releases: released according to perceived bug status, not according to a preconceived timeline." -2.6.x.y -stable kernel tree +3.x.y -stable kernel tree --------------------------- -Kernels with 4-part versions are -stable kernels. They contain +Kernels with 3-part versions are -stable kernels. They contain relatively small and critical fixes for security problems or significant -regressions discovered in a given 2.6.x kernel. +regressions discovered in a given 3.x kernel. This is the recommended branch for users who want the most recent stable kernel and are not interested in helping test development/experimental versions. -If no 2.6.x.y kernel is available, then the highest numbered 2.6.x +If no 3.x.y kernel is available, then the highest numbered 3.x kernel is the current stable kernel. -2.6.x.y are maintained by the "stable" team , and +3.x.y are maintained by the "stable" team , and are released as needs dictate. The normal release period is approximately two weeks, but it can be longer if there are no pressing problems. A security-related problem, instead, can cause a release to happen almost @@ -285,7 +285,7 @@ The file Documentation/stable_kernel_rules.txt in the kernel tree documents what kinds of changes are acceptable for the -stable tree, and how the release process works. -2.6.x -git patches +3.x -git patches ------------------ These are daily snapshots of Linus' kernel tree which are managed in a git repository (hence the name.) These patches are usually released @@ -317,13 +317,13 @@ revisions to it, and maintainers can mark patches as under review, accepted, or rejected. Most of these patchwork sites are listed at http://patchwork.kernel.org/. -2.6.x -next kernel tree for integration tests +3.x -next kernel tree for integration tests --------------------------------------------- -Before updates from subsystem trees are merged into the mainline 2.6.x +Before updates from subsystem trees are merged into the mainline 3.x tree, they need to be integration-tested. For this purpose, a special testing repository exists into which virtually all subsystem trees are pulled on an almost daily basis: - http://git.kernel.org/?p=linux/kernel/git/sfr/linux-next.git + http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git http://linux.f-seidel.de/linux-next/pmwiki/ This way, the -next kernel gives a summary outlook onto what will be diff --git a/trunk/Documentation/Makefile b/trunk/Documentation/Makefile index 30b656ece7aa..31d302bc5863 100644 --- a/trunk/Documentation/Makefile +++ b/trunk/Documentation/Makefile @@ -1,3 +1,3 @@ obj-m := DocBook/ accounting/ auxdisplay/ connector/ \ filesystems/ filesystems/configfs/ ia64/ laptops/ networking/ \ - pcmcia/ spi/ timers/ watchdog/src/ + pcmcia/ spi/ timers/ watchdog/src/ misc-devices/mei/ diff --git a/trunk/Documentation/blackfin/bfin-gpio-notes.txt b/trunk/Documentation/blackfin/bfin-gpio-notes.txt index d36b01f778b9..d245f39c3d01 100644 --- a/trunk/Documentation/blackfin/bfin-gpio-notes.txt +++ b/trunk/Documentation/blackfin/bfin-gpio-notes.txt @@ -53,7 +53,7 @@ 3. But there are some exceptions - Kernel permit the identical GPIO be requested both as GPIO and GPIO - interrut. + interrupt. Some drivers, like gpio-keys, need this behavior. Kernel only print out warning messages like, bfin-gpio: GPIO 24 is already reserved by gpio-keys: BTN0, and you are diff --git a/trunk/Documentation/cgroups/resource_counter.txt b/trunk/Documentation/cgroups/resource_counter.txt index 95b24d766eab..f3c4ec3626a2 100644 --- a/trunk/Documentation/cgroups/resource_counter.txt +++ b/trunk/Documentation/cgroups/resource_counter.txt @@ -77,11 +77,11 @@ to work with it. where the charging failed. d. int res_counter_charge_locked - (struct res_counter *rc, unsigned long val) + (struct res_counter *rc, unsigned long val, bool force) The same as res_counter_charge(), but it must not acquire/release the res_counter->lock internally (it must be called with res_counter->lock - held). + held). The force parameter indicates whether we can bypass the limit. e. void res_counter_uncharge[_locked] (struct res_counter *rc, unsigned long val) diff --git a/trunk/Documentation/devices.txt b/trunk/Documentation/devices.txt index 00383186d8fb..5941f5136c6b 100644 --- a/trunk/Documentation/devices.txt +++ b/trunk/Documentation/devices.txt @@ -98,7 +98,8 @@ Your cooperation is appreciated. 8 = /dev/random Nondeterministic random number gen. 9 = /dev/urandom Faster, less secure random number gen. 10 = /dev/aio Asynchronous I/O notification interface - 11 = /dev/kmsg Writes to this come out as printk's + 11 = /dev/kmsg Writes to this come out as printk's, reads + export the buffered printk records. 12 = /dev/oldmem Used by crashdump kernels to access the memory of the kernel that crashed. diff --git a/trunk/Documentation/devicetree/bindings/arm/atmel-adc.txt b/trunk/Documentation/devicetree/bindings/arm/atmel-adc.txt new file mode 100644 index 000000000000..c63097d6afeb --- /dev/null +++ b/trunk/Documentation/devicetree/bindings/arm/atmel-adc.txt @@ -0,0 +1,65 @@ +* AT91's Analog to Digital Converter (ADC) + +Required properties: + - compatible: Should be "atmel,at91sam9260-adc" + - reg: Should contain ADC registers location and length + - interrupts: Should contain the IRQ line for the ADC + - atmel,adc-channel-base: Offset of the first channel data register + - atmel,adc-channels-used: Bitmask of the channels muxed and enable for this + device + - atmel,adc-drdy-mask: Mask of the DRDY interruption in the ADC + - atmel,adc-num-channels: Number of channels available in the ADC + - atmel,adc-startup-time: Startup Time of the ADC in microseconds as + defined in the datasheet + - atmel,adc-status-register: Offset of the Interrupt Status Register + - atmel,adc-trigger-register: Offset of the Trigger Register + - atmel,adc-vref: Reference voltage in millivolts for the conversions + +Optional properties: + - atmel,adc-use-external: Boolean to enable of external triggers + +Optional trigger Nodes: + - Required properties: + * trigger-name: Name of the trigger exposed to the user + * trigger-value: Value to put in the Trigger register + to activate this trigger + - Optional properties: + * trigger-external: Is the trigger an external trigger? + +Examples: +adc0: adc@fffb0000 { + compatible = "atmel,at91sam9260-adc"; + reg = <0xfffb0000 0x100>; + interrupts = <20 4>; + atmel,adc-channel-base = <0x30>; + atmel,adc-channels-used = <0xff>; + atmel,adc-drdy-mask = <0x10000>; + atmel,adc-num-channels = <8>; + atmel,adc-startup-time = <40>; + atmel,adc-status-register = <0x1c>; + atmel,adc-trigger-register = <0x08>; + atmel,adc-use-external; + atmel,adc-vref = <3300>; + + trigger@0 { + trigger-name = "external-rising"; + trigger-value = <0x1>; + trigger-external; + }; + trigger@1 { + trigger-name = "external-falling"; + trigger-value = <0x2>; + trigger-external; + }; + + trigger@2 { + trigger-name = "external-any"; + trigger-value = <0x3>; + trigger-external; + }; + + trigger@3 { + trigger-name = "continuous"; + trigger-value = <0x6>; + }; +}; diff --git a/trunk/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-mc.txt b/trunk/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-mc.txt new file mode 100644 index 000000000000..c25a0a55151d --- /dev/null +++ b/trunk/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-mc.txt @@ -0,0 +1,16 @@ +NVIDIA Tegra20 MC(Memory Controller) + +Required properties: +- compatible : "nvidia,tegra20-mc" +- reg : Should contain 2 register ranges(address and length); see the + example below. Note that the MC registers are interleaved with the + GART registers, and hence must be represented as multiple ranges. +- interrupts : Should contain MC General interrupt. + +Example: + mc { + compatible = "nvidia,tegra20-mc"; + reg = <0x7000f000 0x024 + 0x7000f03c 0x3c4>; + interrupts = <0 77 0x04>; + }; diff --git a/trunk/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra30-mc.txt b/trunk/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra30-mc.txt new file mode 100644 index 000000000000..e47e73f612f4 --- /dev/null +++ b/trunk/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra30-mc.txt @@ -0,0 +1,18 @@ +NVIDIA Tegra30 MC(Memory Controller) + +Required properties: +- compatible : "nvidia,tegra30-mc" +- reg : Should contain 4 register ranges(address and length); see the + example below. Note that the MC registers are interleaved with the + SMMU registers, and hence must be represented as multiple ranges. +- interrupts : Should contain MC General interrupt. + +Example: + mc { + compatible = "nvidia,tegra30-mc"; + reg = <0x7000f000 0x010 + 0x7000f03c 0x1b4 + 0x7000f200 0x028 + 0x7000f284 0x17c>; + interrupts = <0 77 0x04>; + }; diff --git a/trunk/Documentation/devicetree/bindings/misc/bmp085.txt b/trunk/Documentation/devicetree/bindings/misc/bmp085.txt new file mode 100644 index 000000000000..91dfda2e4e11 --- /dev/null +++ b/trunk/Documentation/devicetree/bindings/misc/bmp085.txt @@ -0,0 +1,20 @@ +BMP085/BMP18x digital pressure sensors + +Required properties: +- compatible: bosch,bmp085 + +Optional properties: +- chip-id: configurable chip id for non-default chip revisions +- temp-measurement-period: temperature measurement period (milliseconds) +- default-oversampling: default oversampling value to be used at startup, + value range is 0-3 with rising sensitivity. + +Example: + +pressure@77 { + compatible = "bosch,bmp085"; + reg = <0x77>; + chip-id = <10>; + temp-measurement-period = <100>; + default-oversampling = <2>; +}; diff --git a/trunk/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt b/trunk/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt index 1ad80d5865a9..f31b686d4556 100644 --- a/trunk/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt +++ b/trunk/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt @@ -1,4 +1,4 @@ -Flexcan CAN contoller on Freescale's ARM and PowerPC system-on-a-chip (SOC). +Flexcan CAN controller on Freescale's ARM and PowerPC system-on-a-chip (SOC). Required properties: diff --git a/trunk/Documentation/devicetree/bindings/staging/iio/adc/lpc32xx-adc.txt b/trunk/Documentation/devicetree/bindings/staging/iio/adc/lpc32xx-adc.txt new file mode 100644 index 000000000000..b3629d3a9adf --- /dev/null +++ b/trunk/Documentation/devicetree/bindings/staging/iio/adc/lpc32xx-adc.txt @@ -0,0 +1,16 @@ +* NXP LPC32xx SoC ADC controller + +Required properties: +- compatible: must be "nxp,lpc3220-adc" +- reg: physical base address of the controller and length of memory mapped + region. +- interrupts: The ADC interrupt + +Example: + + adc@40048000 { + compatible = "nxp,lpc3220-adc"; + reg = <0x40048000 0x1000>; + interrupt-parent = <&mic>; + interrupts = <39 0>; + }; diff --git a/trunk/Documentation/devicetree/bindings/staging/iio/adc/spear-adc.txt b/trunk/Documentation/devicetree/bindings/staging/iio/adc/spear-adc.txt new file mode 100644 index 000000000000..02ea23a63f20 --- /dev/null +++ b/trunk/Documentation/devicetree/bindings/staging/iio/adc/spear-adc.txt @@ -0,0 +1,26 @@ +* ST SPEAr ADC device driver + +Required properties: +- compatible: Should be "st,spear600-adc" +- reg: Address and length of the register set for the device +- interrupt-parent: Should be the phandle for the interrupt controller + that services interrupts for this device +- interrupts: Should contain the ADC interrupt +- sampling-frequency: Default sampling frequency + +Optional properties: +- vref-external: External voltage reference in milli-volts. If omitted + the internal voltage reference will be used. +- average-samples: Number of samples to generate an average value. If + omitted, single data conversion will be used. + +Examples: + + adc: adc@d8200000 { + compatible = "st,spear600-adc"; + reg = <0xd8200000 0x1000>; + interrupt-parent = <&vic1>; + interrupts = <6>; + sampling-frequency = <5000000>; + vref-external = <2500>; /* 2.5V VRef */ + }; diff --git a/trunk/Documentation/devicetree/bindings/usb/isp1301.txt b/trunk/Documentation/devicetree/bindings/usb/isp1301.txt new file mode 100644 index 000000000000..5405d99d9aaa --- /dev/null +++ b/trunk/Documentation/devicetree/bindings/usb/isp1301.txt @@ -0,0 +1,25 @@ +* NXP ISP1301 USB transceiver + +Required properties: +- compatible: must be "nxp,isp1301" +- reg: I2C address of the ISP1301 device + +Optional properties of devices using ISP1301: +- transceiver: phandle of isp1301 - this helps the ISP1301 driver to find the + ISP1301 instance associated with the respective USB driver + +Example: + + isp1301: usb-transceiver@2c { + compatible = "nxp,isp1301"; + reg = <0x2c>; + }; + + usbd@31020000 { + compatible = "nxp,lpc3220-udc"; + reg = <0x31020000 0x300>; + interrupt-parent = <&mic>; + interrupts = <0x3d 0>, <0x3e 0>, <0x3c 0>, <0x3a 0>; + transceiver = <&isp1301>; + status = "okay"; + }; diff --git a/trunk/Documentation/devicetree/bindings/usb/lpc32xx-udc.txt b/trunk/Documentation/devicetree/bindings/usb/lpc32xx-udc.txt new file mode 100644 index 000000000000..29f12a533f66 --- /dev/null +++ b/trunk/Documentation/devicetree/bindings/usb/lpc32xx-udc.txt @@ -0,0 +1,28 @@ +* NXP LPC32xx SoC USB Device Controller (UDC) + +Required properties: +- compatible: Must be "nxp,lpc3220-udc" +- reg: Physical base address of the controller and length of memory mapped + region. +- interrupts: The USB interrupts: + * USB Device Low Priority Interrupt + * USB Device High Priority Interrupt + * USB Device DMA Interrupt + * External USB Transceiver Interrupt (OTG ATX) +- transceiver: phandle of the associated ISP1301 device - this is necessary for + the UDC controller for connecting to the USB physical layer + +Example: + + isp1301: usb-transceiver@2c { + compatible = "nxp,isp1301"; + reg = <0x2c>; + }; + + usbd@31020000 { + compatible = "nxp,lpc3220-udc"; + reg = <0x31020000 0x300>; + interrupt-parent = <&mic>; + interrupts = <0x3d 0>, <0x3e 0>, <0x3c 0>, <0x3a 0>; + transceiver = <&isp1301>; + }; diff --git a/trunk/Documentation/devicetree/bindings/usb/ohci-nxp.txt b/trunk/Documentation/devicetree/bindings/usb/ohci-nxp.txt new file mode 100644 index 000000000000..71e28c1017ed --- /dev/null +++ b/trunk/Documentation/devicetree/bindings/usb/ohci-nxp.txt @@ -0,0 +1,24 @@ +* OHCI controller, NXP ohci-nxp variant + +Required properties: +- compatible: must be "nxp,ohci-nxp" +- reg: physical base address of the controller and length of memory mapped + region. +- interrupts: The OHCI interrupt +- transceiver: phandle of the associated ISP1301 device - this is necessary for + the UDC controller for connecting to the USB physical layer + +Example (LPC32xx): + + isp1301: usb-transceiver@2c { + compatible = "nxp,isp1301"; + reg = <0x2c>; + }; + + ohci@31020000 { + compatible = "nxp,ohci-nxp"; + reg = <0x31020000 0x300>; + interrupt-parent = <&mic>; + interrupts = <0x3b 0>; + transceiver = <&isp1301>; + }; diff --git a/trunk/Documentation/devicetree/bindings/usb/spear-usb.txt b/trunk/Documentation/devicetree/bindings/usb/spear-usb.txt new file mode 100644 index 000000000000..f8a464a25653 --- /dev/null +++ b/trunk/Documentation/devicetree/bindings/usb/spear-usb.txt @@ -0,0 +1,39 @@ +ST SPEAr SoC USB controllers: +----------------------------- + +EHCI: +----- + +Required properties: +- compatible: "st,spear600-ehci" +- interrupt-parent: Should be the phandle for the interrupt controller + that services interrupts for this device +- interrupts: Should contain the EHCI interrupt + +Example: + + ehci@e1800000 { + compatible = "st,spear600-ehci", "usb-ehci"; + reg = <0xe1800000 0x1000>; + interrupt-parent = <&vic1>; + interrupts = <27>; + }; + + +OHCI: +----- + +Required properties: +- compatible: "st,spear600-ohci" +- interrupt-parent: Should be the phandle for the interrupt controller + that services interrupts for this device +- interrupts: Should contain the OHCI interrupt + +Example: + + ohci@e1900000 { + compatible = "st,spear600-ohci", "usb-ohci"; + reg = <0xe1800000 0x1000>; + interrupt-parent = <&vic1>; + interrupts = <26>; + }; diff --git a/trunk/Documentation/devicetree/bindings/vendor-prefixes.txt b/trunk/Documentation/devicetree/bindings/vendor-prefixes.txt index 82ac057a24a9..107d8addf0e4 100644 --- a/trunk/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/trunk/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -8,6 +8,7 @@ amcc Applied Micro Circuits Corporation (APM, formally AMCC) apm Applied Micro Circuits Corporation (APM) arm ARM Ltd. atmel Atmel Corporation +bosch Bosch Sensortec GmbH cavium Cavium, Inc. chrp Common Hardware Reference Platform cortina Cortina Systems, Inc. diff --git a/trunk/Documentation/dvb/opera-firmware.txt b/trunk/Documentation/dvb/opera-firmware.txt index 93e784c2607b..fb6683188ef7 100644 --- a/trunk/Documentation/dvb/opera-firmware.txt +++ b/trunk/Documentation/dvb/opera-firmware.txt @@ -8,7 +8,7 @@ from the windriver disk into this directory. Then run -./get_dvb_firware opera1 +./get_dvb_firmware opera1 and after that you have 2 files: @@ -24,4 +24,4 @@ After that the driver can load the firmware in kernel config and have hotplug running). -Marco Gittler \ No newline at end of file +Marco Gittler diff --git a/trunk/Documentation/dynamic-debug-howto.txt b/trunk/Documentation/dynamic-debug-howto.txt index 74e6c7782678..6e1684981da2 100644 --- a/trunk/Documentation/dynamic-debug-howto.txt +++ b/trunk/Documentation/dynamic-debug-howto.txt @@ -2,17 +2,17 @@ Introduction ============ -This document describes how to use the dynamic debug (ddebug) feature. +This document describes how to use the dynamic debug (dyndbg) feature. -Dynamic debug is designed to allow you to dynamically enable/disable kernel -code to obtain additional kernel information. Currently, if -CONFIG_DYNAMIC_DEBUG is set, then all pr_debug()/dev_dbg() calls can be -dynamically enabled per-callsite. +Dynamic debug is designed to allow you to dynamically enable/disable +kernel code to obtain additional kernel information. Currently, if +CONFIG_DYNAMIC_DEBUG is set, then all pr_debug()/dev_dbg() calls can +be dynamically enabled per-callsite. Dynamic debug has even more useful features: - * Simple query language allows turning on and off debugging statements by - matching any combination of 0 or 1 of: + * Simple query language allows turning on and off debugging + statements by matching any combination of 0 or 1 of: - source filename - function name @@ -20,17 +20,19 @@ Dynamic debug has even more useful features: - module name - format string - * Provides a debugfs control file: /dynamic_debug/control which can be - read to display the complete list of known debug statements, to help guide you + * Provides a debugfs control file: /dynamic_debug/control + which can be read to display the complete list of known debug + statements, to help guide you Controlling dynamic debug Behaviour =================================== The behaviour of pr_debug()/dev_dbg()s are controlled via writing to a -control file in the 'debugfs' filesystem. Thus, you must first mount the debugfs -filesystem, in order to make use of this feature. Subsequently, we refer to the -control file as: /dynamic_debug/control. For example, if you want to -enable printing from source file 'svcsock.c', line 1603 you simply do: +control file in the 'debugfs' filesystem. Thus, you must first mount +the debugfs filesystem, in order to make use of this feature. +Subsequently, we refer to the control file as: +/dynamic_debug/control. For example, if you want to enable +printing from source file 'svcsock.c', line 1603 you simply do: nullarbor:~ # echo 'file svcsock.c line 1603 +p' > /dynamic_debug/control @@ -44,15 +46,15 @@ nullarbor:~ # echo 'file svcsock.c wtf 1 +p' > Viewing Dynamic Debug Behaviour =========================== -You can view the currently configured behaviour of all the debug statements -via: +You can view the currently configured behaviour of all the debug +statements via: nullarbor:~ # cat /dynamic_debug/control # filename:lineno [module]function flags format -/usr/src/packages/BUILD/sgi-enhancednfs-1.4/default/net/sunrpc/svc_rdma.c:323 [svcxprt_rdma]svc_rdma_cleanup - "SVCRDMA Module Removed, deregister RPC RDMA transport\012" -/usr/src/packages/BUILD/sgi-enhancednfs-1.4/default/net/sunrpc/svc_rdma.c:341 [svcxprt_rdma]svc_rdma_init - "\011max_inline : %d\012" -/usr/src/packages/BUILD/sgi-enhancednfs-1.4/default/net/sunrpc/svc_rdma.c:340 [svcxprt_rdma]svc_rdma_init - "\011sq_depth : %d\012" -/usr/src/packages/BUILD/sgi-enhancednfs-1.4/default/net/sunrpc/svc_rdma.c:338 [svcxprt_rdma]svc_rdma_init - "\011max_requests : %d\012" +/usr/src/packages/BUILD/sgi-enhancednfs-1.4/default/net/sunrpc/svc_rdma.c:323 [svcxprt_rdma]svc_rdma_cleanup =_ "SVCRDMA Module Removed, deregister RPC RDMA transport\012" +/usr/src/packages/BUILD/sgi-enhancednfs-1.4/default/net/sunrpc/svc_rdma.c:341 [svcxprt_rdma]svc_rdma_init =_ "\011max_inline : %d\012" +/usr/src/packages/BUILD/sgi-enhancednfs-1.4/default/net/sunrpc/svc_rdma.c:340 [svcxprt_rdma]svc_rdma_init =_ "\011sq_depth : %d\012" +/usr/src/packages/BUILD/sgi-enhancednfs-1.4/default/net/sunrpc/svc_rdma.c:338 [svcxprt_rdma]svc_rdma_init =_ "\011max_requests : %d\012" ... @@ -65,12 +67,12 @@ nullarbor:~ # grep -i rdma /dynamic_debug/control | wc -l nullarbor:~ # grep -i tcp /dynamic_debug/control | wc -l 42 -Note in particular that the third column shows the enabled behaviour -flags for each debug statement callsite (see below for definitions of the -flags). The default value, no extra behaviour enabled, is "-". So -you can view all the debug statement callsites with any non-default flags: +The third column shows the currently enabled flags for each debug +statement callsite (see below for definitions of the flags). The +default value, with no flags enabled, is "=_". So you can view all +the debug statement callsites with any non-default flags: -nullarbor:~ # awk '$3 != "-"' /dynamic_debug/control +nullarbor:~ # awk '$3 != "=_"' /dynamic_debug/control # filename:lineno [module]function flags format /usr/src/packages/BUILD/sgi-enhancednfs-1.4/default/net/sunrpc/svcsock.c:1603 [sunrpc]svc_send p "svc_process: st_sendto returned %d\012" @@ -103,15 +105,14 @@ specifications, followed by a flags change specification. command ::= match-spec* flags-spec -The match-spec's are used to choose a subset of the known dprintk() +The match-spec's are used to choose a subset of the known pr_debug() callsites to which to apply the flags-spec. Think of them as a query with implicit ANDs between each pair. Note that an empty list of -match-specs is possible, but is not very useful because it will not -match any debug statement callsites. +match-specs will select all debug statement callsites. -A match specification comprises a keyword, which controls the attribute -of the callsite to be compared, and a value to compare against. Possible -keywords are: +A match specification comprises a keyword, which controls the +attribute of the callsite to be compared, and a value to compare +against. Possible keywords are: match-spec ::= 'func' string | 'file' string | @@ -164,15 +165,15 @@ format characters (") or single quote characters ('). Examples: - format svcrdma: // many of the NFS/RDMA server dprintks - format readahead // some dprintks in the readahead cache + format svcrdma: // many of the NFS/RDMA server pr_debugs + format readahead // some pr_debugs in the readahead cache format nfsd:\040SETATTR // one way to match a format with whitespace format "nfsd: SETATTR" // a neater way to match a format with whitespace format 'nfsd: SETATTR' // yet another way to match a format with whitespace line The given line number or range of line numbers is compared - against the line number of each dprintk() callsite. A single + against the line number of each pr_debug() callsite. A single line number matches the callsite line number exactly. A range of line numbers matches any callsite between the first and last line number inclusive. An empty first number means @@ -188,51 +189,93 @@ The flags specification comprises a change operation followed by one or more flag characters. The change operation is one of the characters: -- - remove the given flags - -+ - add the given flags - -= - set the flags to the given flags + - remove the given flags + + add the given flags + = set the flags to the given flags The flags are: -f - Include the function name in the printed message -l - Include line number in the printed message -m - Include module name in the printed message -p - Causes a printk() message to be emitted to dmesg -t - Include thread ID in messages not generated from interrupt context + p enables the pr_debug() callsite. + f Include the function name in the printed message + l Include line number in the printed message + m Include module name in the printed message + t Include thread ID in messages not generated from interrupt context + _ No flags are set. (Or'd with others on input) + +For display, the flags are preceded by '=' +(mnemonic: what the flags are currently equal to). -Note the regexp ^[-+=][flmpt]+$ matches a flags specification. -Note also that there is no convenient syntax to remove all -the flags at once, you need to use "-flmpt". +Note the regexp ^[-+=][flmpt_]+$ matches a flags specification. +To clear all flags at once, use "=_" or "-flmpt". -Debug messages during boot process +Debug messages during Boot Process ================================== -To be able to activate debug messages during the boot process, -even before userspace and debugfs exists, use the boot parameter: -ddebug_query="QUERY" +To activate debug messages for core code and built-in modules during +the boot process, even before userspace and debugfs exists, use +dyndbg="QUERY", module.dyndbg="QUERY", or ddebug_query="QUERY" +(ddebug_query is obsoleted by dyndbg, and deprecated). QUERY follows +the syntax described above, but must not exceed 1023 characters. Your +bootloader may impose lower limits. + +These dyndbg params are processed just after the ddebug tables are +processed, as part of the arch_initcall. Thus you can enable debug +messages in all code run after this arch_initcall via this boot +parameter. -QUERY follows the syntax described above, but must not exceed 1023 -characters. The enablement of debug messages is done as an arch_initcall. -Thus you can enable debug messages in all code processed after this -arch_initcall via this boot parameter. On an x86 system for example ACPI enablement is a subsys_initcall and -ddebug_query="file ec.c +p" + dyndbg="file ec.c +p" will show early Embedded Controller transactions during ACPI setup if your machine (typically a laptop) has an Embedded Controller. PCI (or other devices) initialization also is a hot candidate for using this boot parameter for debugging purposes. +If foo module is not built-in, foo.dyndbg will still be processed at +boot time, without effect, but will be reprocessed when module is +loaded later. dyndbg_query= and bare dyndbg= are only processed at +boot. + + +Debug Messages at Module Initialization Time +============================================ + +When "modprobe foo" is called, modprobe scans /proc/cmdline for +foo.params, strips "foo.", and passes them to the kernel along with +params given in modprobe args or /etc/modprob.d/*.conf files, +in the following order: + +1. # parameters given via /etc/modprobe.d/*.conf + options foo dyndbg=+pt + options foo dyndbg # defaults to +p + +2. # foo.dyndbg as given in boot args, "foo." is stripped and passed + foo.dyndbg=" func bar +p; func buz +mp" + +3. # args to modprobe + modprobe foo dyndbg==pmf # override previous settings + +These dyndbg queries are applied in order, with last having final say. +This allows boot args to override or modify those from /etc/modprobe.d +(sensible, since 1 is system wide, 2 is kernel or boot specific), and +modprobe args to override both. + +In the foo.dyndbg="QUERY" form, the query must exclude "module foo". +"foo" is extracted from the param-name, and applied to each query in +"QUERY", and only 1 match-spec of each type is allowed. + +The dyndbg option is a "fake" module parameter, which means: + +- modules do not need to define it explicitly +- every module gets it tacitly, whether they use pr_debug or not +- it doesnt appear in /sys/module/$module/parameters/ + To see it, grep the control file, or inspect /proc/cmdline. + +For CONFIG_DYNAMIC_DEBUG kernels, any settings given at boot-time (or +enabled by -DDEBUG flag during compilation) can be disabled later via +the sysfs interface if the debug messages are no longer needed: + + echo "module module_name -p" > /dynamic_debug/control Examples ======== @@ -260,3 +303,18 @@ nullarbor:~ # echo -n 'func svc_process -p' > // enable messages for NFS calls READ, READLINK, READDIR and READDIR+. nullarbor:~ # echo -n 'format "nfsd: READ" +p' > /dynamic_debug/control + +// enable all messages +nullarbor:~ # echo -n '+p' > /dynamic_debug/control + +// add module, function to all enabled messages +nullarbor:~ # echo -n '+mf' > /dynamic_debug/control + +// boot-args example, with newlines and comments for readability +Kernel command line: ... + // see whats going on in dyndbg=value processing + dynamic_debug.verbose=1 + // enable pr_debugs in 2 builtins, #cmt is stripped + dyndbg="module params +p #cmt ; module sys +p" + // enable pr_debugs in 2 functions in a module loaded later + pc87360.dyndbg="func pc87360_init_device +p; func pc87360_find +p" diff --git a/trunk/Documentation/edac.txt b/trunk/Documentation/edac.txt index fdcc49fad8e1..03df2b020332 100644 --- a/trunk/Documentation/edac.txt +++ b/trunk/Documentation/edac.txt @@ -734,7 +734,7 @@ were done at i7core_edac driver. This chapter will cover those differences associated with a physical CPU socket. Each MC have 3 physical read channels, 3 physical write channels and - 3 logic channels. The driver currenty sees it as just 3 channels. + 3 logic channels. The driver currently sees it as just 3 channels. Each channel can have up to 3 DIMMs. The minimum known unity is DIMMs. There are no information about csrows. diff --git a/trunk/Documentation/extcon/porting-android-switch-class b/trunk/Documentation/extcon/porting-android-switch-class new file mode 100644 index 000000000000..eb0fa5f4fe88 --- /dev/null +++ b/trunk/Documentation/extcon/porting-android-switch-class @@ -0,0 +1,124 @@ + + Staging/Android Switch Class Porting Guide + (linux/drivers/staging/android/switch) + (c) Copyright 2012 Samsung Electronics + +AUTHORS +MyungJoo Ham + +/***************************************************************** + * CHAPTER 1. * + * PORTING SWITCH CLASS DEVICE DRIVERS * + *****************************************************************/ + +****** STEP 1. Basic Functionality + No extcon extended feature, but switch features only. + +- struct switch_dev (fed to switch_dev_register/unregister) + @name: no change + @dev: no change + @index: drop (not used in switch device driver side anyway) + @state: no change + If you have used @state with magic numbers, keep it + at this step. + @print_name: no change but type change (switch_dev->extcon_dev) + @print_state: no change but type change (switch_dev->extcon_dev) + +- switch_dev_register(sdev, dev) + => extcon_dev_register(edev, dev) + : no change but type change (sdev->edev) +- switch_dev_unregister(sdev) + => extcon_dev_unregister(edev) + : no change but type change (sdev->edev) +- switch_get_state(sdev) + => extcon_get_state(edev) + : no change but type change (sdev->edev) and (return: int->u32) +- switch_set_state(sdev, state) + => extcon_set_state(edev, state) + : no change but type change (sdev->edev) and (state: int->u32) + +With this changes, the ex-switch extcon class device works as it once +worked as switch class device. However, it will now have additional +interfaces (both ABI and in-kernel API) and different ABI locations. +However, if CONFIG_ANDROID is enabled without CONFIG_ANDROID_SWITCH, +/sys/class/switch/* will be symbolically linked to /sys/class/extcon/ +so that they are still compatible with legacy userspace processes. + +****** STEP 2. Multistate (no more magic numbers in state value) + Extcon's extended features for switch device drivers with + complex features usually required magic numbers in state + value of switch_dev. With extcon, such magic numbers that + support multiple cables ( + + 1. Define cable names at edev->supported_cable. + 2. (Recommended) remove print_state callback. + 3. Use extcon_get_cable_state_(edev, index) or + extcon_get_cable_state(edev, cable_name) instead of + extcon_get_state(edev) if you intend to get a state of a specific + cable. Same for set_state. This way, you can remove the usage of + magic numbers in state value. + 4. Use extcon_update_state() if you are updating specific bits of + the state value. + +Example: a switch device driver w/ magic numbers for two cables. + "0x00": no cables connected. + "0x01": cable 1 connected + "0x02": cable 2 connected + "0x03": cable 1 and 2 connected + 1. edev->supported_cable = {"1", "2", NULL}; + 2. edev->print_state = NULL; + 3. extcon_get_cable_state_(edev, 0) shows cable 1's state. + extcon_get_cable_state(edev, "1") shows cable 1's state. + extcon_set_cable_state_(edev, 1) sets cable 2's state. + extcon_set_cable_state(edev, "2") sets cable 2's state + 4. extcon_update_state(edev, 0x01, 0) sets the least bit's 0. + +****** STEP 3. Notify other device drivers + + You can notify others of the cable attach/detach events with +notifier chains. + + At the side of other device drivers (the extcon device itself +does not need to get notified of its own events), there are two +methods to register notifier_block for cable events: +(a) for a specific cable or (b) for every cable. + + (a) extcon_register_interest(obj, extcon_name, cable_name, nb) + Example: want to get news of "MAX8997_MUIC"'s "USB" cable + + obj = kzalloc(sizeof(struct extcon_specific_cable_nb), + GFP_KERNEL); + nb->notifier_call = the_callback_to_handle_usb; + + extcon_register_intereset(obj, "MAX8997_MUIC", "USB", nb); + + (b) extcon_register_notifier(edev, nb) + Call nb for any changes in edev. + + Please note that in order to properly behave with method (a), +the extcon device driver should support multistate feature (STEP 2). + +****** STEP 4. Inter-cable relation (mutually exclusive) + + You can provide inter-cable mutually exclusiveness information +for an extcon device. When cables A and B are declared to be mutually +exclusive, the two cables cannot be in ATTACHED state simulteneously. + + +/***************************************************************** + * CHAPTER 2. * + * PORTING USERSPACE w/ SWITCH CLASS DEVICE SUPPORT * + *****************************************************************/ + +****** ABI Location + + If "CONFIG_ANDROID" is enabled and "CONFIG_ANDROID_SWITCH" is +disabled, /sys/class/switch/* are created as symbolic links to +/sys/class/extcon/*. Because CONFIG_ANDROID_SWITCH creates +/sys/class/switch directory, we disable symboling linking if +CONFIG_ANDROID_SWITCH is enabled. + + The two files of switch class, name and state, are provided with +extcon, too. When the multistate support (STEP 2 of CHAPTER 1.) is +not enabled or print_state callback is supplied, the output of +state ABI is same with switch class. diff --git a/trunk/Documentation/feature-removal-schedule.txt b/trunk/Documentation/feature-removal-schedule.txt index e4b57756b9f5..1e69a81e99d4 100644 --- a/trunk/Documentation/feature-removal-schedule.txt +++ b/trunk/Documentation/feature-removal-schedule.txt @@ -2,7 +2,14 @@ The following is a list of files and features that are going to be removed in the kernel source tree. Every entry should contain what exactly is going away, why it is happening, and who is going to be doing the work. When the feature is removed from the kernel, it should also -be removed from this file. +be removed from this file. The suggested deprecation period is 3 releases. + +--------------------------- + +What: ddebug_query="query" boot cmdline param +When: v3.8 +Why: obsoleted by dyndbg="query" and module.dyndbg="query" +Who: Jim Cromie , Jason Baron --------------------------- @@ -549,3 +556,14 @@ Why: The V4L2_CID_VCENTER, V4L2_CID_HCENTER controls have been deprecated There are newer controls (V4L2_CID_PAN*, V4L2_CID_TILT*) that provide similar functionality. Who: Sylwester Nawrocki + +---------------------------- + +What: cgroup option updates via remount +When: March 2013 +Why: Remount currently allows changing bound subsystems and + release_agent. Rebinding is hardly useful as it only works + when the hierarchy is empty and release_agent itself should be + replaced with conventional fsnotify. + +---------------------------- diff --git a/trunk/Documentation/filesystems/nfs/pnfs.txt b/trunk/Documentation/filesystems/nfs/pnfs.txt index c7919c6e3bea..52ae07f5f578 100644 --- a/trunk/Documentation/filesystems/nfs/pnfs.txt +++ b/trunk/Documentation/filesystems/nfs/pnfs.txt @@ -93,7 +93,7 @@ The API to the login script is as follows: (allways exists) (More protocols can be defined in the future. The client does not interpret this string it is - passed unchanged as recieved from the Server) + passed unchanged as received from the Server) -o osdname of the requested target OSD (Might be empty) (A string which denotes the OSD name, there is a diff --git a/trunk/Documentation/filesystems/qnx6.txt b/trunk/Documentation/filesystems/qnx6.txt index 050223ea03c7..e59f2f09f56e 100644 --- a/trunk/Documentation/filesystems/qnx6.txt +++ b/trunk/Documentation/filesystems/qnx6.txt @@ -17,7 +17,7 @@ concepts of blocks, inodes and directories. On QNX it is possible to create little endian and big endian qnx6 filesystems. This feature makes it possible to create and use a different endianness fs for the target (QNX is used on quite a range of embedded systems) plattform -running on a different endianess. +running on a different endianness. The Linux driver handles endianness transparently. (LE and BE) Blocks @@ -26,7 +26,7 @@ Blocks The space in the device or file is split up into blocks. These are a fixed size of 512, 1024, 2048 or 4096, which is decided when the filesystem is created. -Blockpointers are 32bit, so the maximum space that can be adressed is +Blockpointers are 32bit, so the maximum space that can be addressed is 2^32 * 4096 bytes or 16TB The superblocks @@ -47,16 +47,16 @@ inactive superblock. Each superblock holds a set of root inodes for the different filesystem parts. (Inode, Bitmap and Longfilenames) Each of these root nodes holds information like total size of the stored -data and the adressing levels in that specific tree. -If the level value is 0, up to 16 direct blocks can be adressed by each +data and the addressing levels in that specific tree. +If the level value is 0, up to 16 direct blocks can be addressed by each node. -Level 1 adds an additional indirect adressing level where each indirect -adressing block holds up to blocksize / 4 bytes pointers to data blocks. -Level 2 adds an additional indirect adressig block level (so, already up -to 16 * 256 * 256 = 1048576 blocks that can be adressed by such a tree)a +Level 1 adds an additional indirect addressing level where each indirect +addressing block holds up to blocksize / 4 bytes pointers to data blocks. +Level 2 adds an additional indirect addressing block level (so, already up +to 16 * 256 * 256 = 1048576 blocks that can be addressed by such a tree). Unused block pointers are always set to ~0 - regardless of root node, -indirect adressing blocks or inodes. +indirect addressing blocks or inodes. Data leaves are always on the lowest level. So no data is stored on upper tree levels. @@ -64,7 +64,7 @@ The first Superblock is located at 0x2000. (0x2000 is the bootblock size) The Audi MMI 3G first superblock directly starts at byte 0. Second superblock position can either be calculated from the superblock information (total number of filesystem blocks) or by taking the highest -device address, zeroing the last 3 bytes and then substracting 0x1000 from +device address, zeroing the last 3 bytes and then subtracting 0x1000 from that address. 0x1000 is the size reserved for each superblock - regardless of the @@ -83,8 +83,8 @@ size, number of blocks used, access time, change time and modification time. Object mode field is POSIX format. (which makes things easier) There are also pointers to the first 16 blocks, if the object data can be -adressed with 16 direct blocks. -For more than 16 blocks an indirect adressing in form of another tree is +addressed with 16 direct blocks. +For more than 16 blocks an indirect addressing in form of another tree is used. (scheme is the same as the one used for the superblock root nodes) The filesize is stored 64bit. Inode counting starts with 1. (whilst long @@ -118,13 +118,13 @@ no block pointers and the directory file record pointing to the target file inode. Character and block special devices do not exist in QNX as those files -are handled by the QNX kernel/drivers and created in /dev independant of the +are handled by the QNX kernel/drivers and created in /dev independent of the underlaying filesystem. Long filenames -------------- -Long filenames are stored in a seperate adressing tree. The staring point +Long filenames are stored in a separate addressing tree. The staring point is the longfilename root node in the active superblock. Each data block (tree leaves) holds one long filename. That filename is limited to 510 bytes. The first two starting bytes are used as length field diff --git a/trunk/Documentation/hwmon/it87 b/trunk/Documentation/hwmon/it87 index 23b7def21ba8..fba745571684 100644 --- a/trunk/Documentation/hwmon/it87 +++ b/trunk/Documentation/hwmon/it87 @@ -63,7 +63,7 @@ Module Parameters Hardware Interfaces ------------------- -All the chips suported by this driver are LPC Super-I/O chips, accessed +All the chips supported by this driver are LPC Super-I/O chips, accessed through the LPC bus (ISA-like I/O ports). The IT8712F additionally has an SMBus interface to the hardware monitoring functions. This driver no longer supports this interface though, as it is slower and less reliable diff --git a/trunk/Documentation/hwmon/wm831x b/trunk/Documentation/hwmon/wm831x index 24f47d8f6a42..11446757c8c8 100644 --- a/trunk/Documentation/hwmon/wm831x +++ b/trunk/Documentation/hwmon/wm831x @@ -22,7 +22,7 @@ reporting of all the input values but does not provide any alarms. Voltage Monitoring ------------------ -Voltages are sampled by a 12 bit ADC. Voltages in milivolts are 1.465 +Voltages are sampled by a 12 bit ADC. Voltages in millivolts are 1.465 times the ADC value. Temperature Monitoring diff --git a/trunk/Documentation/ioctl/ioctl-number.txt b/trunk/Documentation/ioctl/ioctl-number.txt index e34b531dc316..915f28c470e9 100644 --- a/trunk/Documentation/ioctl/ioctl-number.txt +++ b/trunk/Documentation/ioctl/ioctl-number.txt @@ -120,6 +120,7 @@ Code Seq#(hex) Include File Comments 'G' 00-0F linux/gigaset_dev.h conflict! 'H' 00-7F linux/hiddev.h conflict! 'H' 00-0F linux/hidraw.h conflict! +'H' 01 linux/mei.h conflict! 'H' 00-0F sound/asound.h conflict! 'H' 20-40 sound/asound_fm.h conflict! 'H' 80-8F sound/sfnt_info.h conflict! diff --git a/trunk/Documentation/kernel-parameters.txt b/trunk/Documentation/kernel-parameters.txt index e275432ef2c7..62aba89b04a2 100644 --- a/trunk/Documentation/kernel-parameters.txt +++ b/trunk/Documentation/kernel-parameters.txt @@ -611,7 +611,7 @@ bytes respectively. Such letter suffixes can also be entirely omitted. ddebug_query= [KNL,DYNAMIC_DEBUG] Enable debug messages at early boot time. See Documentation/dynamic-debug-howto.txt for - details. + details. Deprecated, see dyndbg. debug [KNL] Enable kernel debugging (events log level). @@ -731,6 +731,11 @@ bytes respectively. Such letter suffixes can also be entirely omitted. dscc4.setup= [NET] + dyndbg[="val"] [KNL,DYNAMIC_DEBUG] + module.dyndbg[="val"] + Enable debug messages at boot time. See + Documentation/dynamic-debug-howto.txt for details. + earlycon= [KNL] Output early console device and options. uart[8250],io,[,options] uart[8250],mmio,[,options] diff --git a/trunk/Documentation/memory-devices/ti-emif.txt b/trunk/Documentation/memory-devices/ti-emif.txt new file mode 100644 index 000000000000..f4ad9a7d0f4b --- /dev/null +++ b/trunk/Documentation/memory-devices/ti-emif.txt @@ -0,0 +1,57 @@ +TI EMIF SDRAM Controller Driver: + +Author +======== +Aneesh V + +Location +============ +driver/memory/emif.c + +Supported SoCs: +=================== +TI OMAP44xx +TI OMAP54xx + +Menuconfig option: +========================== +Device Drivers + Memory devices + Texas Instruments EMIF driver + +Description +=========== +This driver is for the EMIF module available in Texas Instruments +SoCs. EMIF is an SDRAM controller that, based on its revision, +supports one or more of DDR2, DDR3, and LPDDR2 SDRAM protocols. +This driver takes care of only LPDDR2 memories presently. The +functions of the driver includes re-configuring AC timing +parameters and other settings during frequency, voltage and +temperature changes + +Platform Data (see include/linux/platform_data/emif_plat.h): +===================================================================== +DDR device details and other board dependent and SoC dependent +information can be passed through platform data (struct emif_platform_data) +- DDR device details: 'struct ddr_device_info' +- Device AC timings: 'struct lpddr2_timings' and 'struct lpddr2_min_tck' +- Custom configurations: customizable policy options through + 'struct emif_custom_configs' +- IP revision +- PHY type + +Interface to the external world: +================================ +EMIF driver registers notifiers for voltage and frequency changes +affecting EMIF and takes appropriate actions when these are invoked. +- freq_pre_notify_handling() +- freq_post_notify_handling() +- volt_notify_handling() + +Debugfs +======== +The driver creates two debugfs entries per device. +- regcache_dump : dump of register values calculated and saved for all + frequencies used so far. +- mr4 : last polled value of MR4 register in the LPDDR2 device. MR4 + indicates the current temperature level of the device. diff --git a/trunk/Documentation/memory-hotplug.txt b/trunk/Documentation/memory-hotplug.txt index 8f485d72cf25..6d0c2519cf47 100644 --- a/trunk/Documentation/memory-hotplug.txt +++ b/trunk/Documentation/memory-hotplug.txt @@ -341,7 +341,7 @@ Need more implementation yet.... -------------------------------- 8. Memory hotplug event notifier -------------------------------- -Memory hotplug has event notifer. There are 6 types of notification. +Memory hotplug has event notifier. There are 6 types of notification. MEMORY_GOING_ONLINE Generated before new memory becomes available in order to be able to diff --git a/trunk/Documentation/misc-devices/mei/.gitignore b/trunk/Documentation/misc-devices/mei/.gitignore new file mode 100644 index 000000000000..f356b81ca1ec --- /dev/null +++ b/trunk/Documentation/misc-devices/mei/.gitignore @@ -0,0 +1 @@ +mei-amt-version diff --git a/trunk/Documentation/misc-devices/mei/Makefile b/trunk/Documentation/misc-devices/mei/Makefile new file mode 100644 index 000000000000..00e8c3e836ff --- /dev/null +++ b/trunk/Documentation/misc-devices/mei/Makefile @@ -0,0 +1,8 @@ +# kbuild trick to avoid linker error. Can be omitted if a module is built. +obj- := dummy.o + +# List of programs to build +hostprogs-y := mei-amt-version +HOSTCFLAGS_mei-amt-version.o += -I$(objtree)/usr/include +# Tell kbuild to always build the programs +always := $(hostprogs-y) diff --git a/trunk/Documentation/misc-devices/mei/TODO b/trunk/Documentation/misc-devices/mei/TODO new file mode 100644 index 000000000000..6b3625d3058c --- /dev/null +++ b/trunk/Documentation/misc-devices/mei/TODO @@ -0,0 +1,2 @@ +TODO: + - Cleanup and split the timer function diff --git a/trunk/drivers/staging/mei/mei-amt-version.c b/trunk/Documentation/misc-devices/mei/mei-amt-version.c similarity index 99% rename from trunk/drivers/staging/mei/mei-amt-version.c rename to trunk/Documentation/misc-devices/mei/mei-amt-version.c index ac2a507be253..01804f216312 100644 --- a/trunk/drivers/staging/mei/mei-amt-version.c +++ b/trunk/Documentation/misc-devices/mei/mei-amt-version.c @@ -74,7 +74,7 @@ #include #include #include -#include "mei.h" +#include /***************************************************************************** * Intel Management Engine Interface diff --git a/trunk/drivers/staging/mei/mei.txt b/trunk/Documentation/misc-devices/mei/mei.txt similarity index 100% rename from trunk/drivers/staging/mei/mei.txt rename to trunk/Documentation/misc-devices/mei/mei.txt diff --git a/trunk/Documentation/networking/can.txt b/trunk/Documentation/networking/can.txt index 56ca3b75376e..ac295399f0d4 100644 --- a/trunk/Documentation/networking/can.txt +++ b/trunk/Documentation/networking/can.txt @@ -649,7 +649,7 @@ solution for a couple of reasons: The CAN device must be configured via netlink interface. The supported netlink message types are defined and briefly described in "include/linux/can/netlink.h". CAN link support for the program "ip" - of the IPROUTE2 utility suite is avaiable and it can be used as shown + of the IPROUTE2 utility suite is available and it can be used as shown below: - Setting CAN device properties: diff --git a/trunk/Documentation/parisc/debugging b/trunk/Documentation/parisc/debugging index d728594058e5..7d75223fa18d 100644 --- a/trunk/Documentation/parisc/debugging +++ b/trunk/Documentation/parisc/debugging @@ -34,6 +34,6 @@ registers interruption handlers read to find out where the machine was interrupted - so if you get an interruption between the instruction that clears the Q bit and the RFI that sets it again you don't know where exactly it happened. If you're lucky the IAOQ will point to the -instrucion that cleared the Q bit, if you're not it points anywhere +instruction that cleared the Q bit, if you're not it points anywhere at all. Usually Q bit problems will show themselves in unexplainable system hangs or running off the end of physical memory. diff --git a/trunk/Documentation/ramoops.txt b/trunk/Documentation/ramoops.txt index 8fb1ba7fe7bf..4ba7db231cb2 100644 --- a/trunk/Documentation/ramoops.txt +++ b/trunk/Documentation/ramoops.txt @@ -3,7 +3,7 @@ Ramoops oops/panic logger Sergiu Iordache -Updated: 8 August 2011 +Updated: 17 November 2011 0. Introduction @@ -30,6 +30,11 @@ variable while setting 0 in that variable dumps only the panics. The module uses a counter to record multiple dumps but the counter gets reset on restart (i.e. new dumps after the restart will overwrite old ones). +Ramoops also supports software ECC protection of persistent memory regions. +This might be useful when a hardware reset was used to bring the machine back +to life (i.e. a watchdog triggered). In such cases, RAM may be somewhat +corrupt, but usually it is restorable. + 2. Setting the parameters Setting the ramoops parameters can be done in 2 different manners: @@ -38,7 +43,7 @@ Setting the ramoops parameters can be done in 2 different manners: 2. Use a platform device and set the platform data. The parameters can then be set through that platform data. An example of doing that is: -#include +#include [...] static struct ramoops_platform_data ramoops_data = { @@ -46,6 +51,7 @@ static struct ramoops_platform_data ramoops_data = { .mem_address = <...>, .record_size = <...>, .dump_oops = <...>, + .ecc = <...>, }; static struct platform_device ramoops_dev = { @@ -71,6 +77,6 @@ timestamp and a new line. The dump then continues with the actual data. 4. Reading the data -The dump data can be read from memory (through /dev/mem or other means). -Getting the module parameters, which are needed in order to parse the data, can -be done through /sys/module/ramoops/parameters/* . +The dump data can be read from the pstore filesystem. The format for these +files is "dmesg-ramoops-N", where N is the record number in memory. To delete +a stored record from RAM, simply unlink the respective pstore file. diff --git a/trunk/Documentation/scheduler/sched-design-CFS.txt b/trunk/Documentation/scheduler/sched-design-CFS.txt index 91ecff07cede..d529e02d928d 100644 --- a/trunk/Documentation/scheduler/sched-design-CFS.txt +++ b/trunk/Documentation/scheduler/sched-design-CFS.txt @@ -130,7 +130,7 @@ CFS implements three scheduling policies: idle timer scheduler in order to avoid to get into priority inversion problems which would deadlock the machine. -SCHED_FIFO/_RR are implemented in sched_rt.c and are as specified by +SCHED_FIFO/_RR are implemented in sched/rt.c and are as specified by POSIX. The command chrt from util-linux-ng 2.13.1.1 can set all of these except @@ -145,9 +145,9 @@ Classes," an extensible hierarchy of scheduler modules. These modules encapsulate scheduling policy details and are handled by the scheduler core without the core code assuming too much about them. -sched_fair.c implements the CFS scheduler described above. +sched/fair.c implements the CFS scheduler described above. -sched_rt.c implements SCHED_FIFO and SCHED_RR semantics, in a simpler way than +sched/rt.c implements SCHED_FIFO and SCHED_RR semantics, in a simpler way than the previous vanilla scheduler did. It uses 100 runqueues (for all 100 RT priority levels, instead of 140 in the previous scheduler) and it needs no expired array. diff --git a/trunk/Documentation/scheduler/sched-domains.txt b/trunk/Documentation/scheduler/sched-domains.txt index b7ee379b651b..443f0c76bab4 100644 --- a/trunk/Documentation/scheduler/sched-domains.txt +++ b/trunk/Documentation/scheduler/sched-domains.txt @@ -61,10 +61,6 @@ The implementor should read comments in include/linux/sched.h: struct sched_domain fields, SD_FLAG_*, SD_*_INIT to get an idea of the specifics and what to tune. -For SMT, the architecture must define CONFIG_SCHED_SMT and provide a -cpumask_t cpu_sibling_map[NR_CPUS], where cpu_sibling_map[i] is the mask of -all "i"'s siblings as well as "i" itself. - Architectures may retain the regular override the default SD_*_INIT flags while using the generic domain builder in kernel/sched.c if they wish to retain the traditional SMT->SMP->NUMA topology (or some subset of that). This diff --git a/trunk/Documentation/sound/alsa/compress_offload.txt b/trunk/Documentation/sound/alsa/compress_offload.txt index c83a835350f0..90e9b3a11abc 100644 --- a/trunk/Documentation/sound/alsa/compress_offload.txt +++ b/trunk/Documentation/sound/alsa/compress_offload.txt @@ -18,7 +18,7 @@ processing. Support for such hardware has not been very good in Linux, mostly because of a lack of a generic API available in the mainline kernel. -Rather than requiring a compability break with an API change of the +Rather than requiring a compatibility break with an API change of the ALSA PCM interface, a new 'Compressed Data' API is introduced to provide a control and data-streaming interface for audio DSPs. diff --git a/trunk/Documentation/sound/oss/ALS b/trunk/Documentation/sound/oss/ALS index d01ffbfd5808..bf10bed4574b 100644 --- a/trunk/Documentation/sound/oss/ALS +++ b/trunk/Documentation/sound/oss/ALS @@ -57,10 +57,10 @@ The resulting sound driver will provide the following capabilities: DSP/PCM/audio out (L&R), FM (L&R) and Mic in (mono). Jonathan Woithe -jwoithe@physics.adelaide.edu.au +jwoithe@just42.net 30 March 1998 Modified 2000-02-26 by Dave Forrest, drf5n@virginia.edu to add ALS100/ALS200 Modified 2000-04-10 by Paul Laufer, pelaufer@csupomona.edu to add ISAPnP info. -Modified 2000-11-19 by Jonathan Woithe, jwoithe@physics.adelaide.edu.au +Modified 2000-11-19 by Jonathan Woithe, jwoithe@just42.net - updated information for kernel 2.4.x. diff --git a/trunk/Documentation/static-keys.txt b/trunk/Documentation/static-keys.txt index d93f3c00f245..9f5263d3152c 100644 --- a/trunk/Documentation/static-keys.txt +++ b/trunk/Documentation/static-keys.txt @@ -235,7 +235,7 @@ label case adds: 6 (mov) + 2 (test) + 2 (jne) = 10 - 5 (5 byte jump 0) = 5 addition bytes. If we then include the padding bytes, the jump label code saves, 16 total bytes -of instruction memory for this small fucntion. In this case the non-jump label +of instruction memory for this small function. In this case the non-jump label function is 80 bytes long. Thus, we have have saved 20% of the instruction footprint. We can in fact improve this even further, since the 5-byte no-op really can be a 2-byte no-op since we can reach the branch with a 2-byte jmp. diff --git a/trunk/Documentation/usb/dwc3.txt b/trunk/Documentation/usb/dwc3.txt index 7b590edae145..1d02c01d1c7c 100644 --- a/trunk/Documentation/usb/dwc3.txt +++ b/trunk/Documentation/usb/dwc3.txt @@ -28,7 +28,7 @@ Please pick something while reading :) none - primary handler of the EP-interrupt - reads the event and tries to process it. Everything that requries + reads the event and tries to process it. Everything that requires sleeping is handed over to the Thread. The event is saved in an per-endpoint data-structure. We probably have to pay attention not to process events once we diff --git a/trunk/Documentation/usb/functionfs.txt b/trunk/Documentation/usb/functionfs.txt new file mode 100644 index 000000000000..eaaaea019fc7 --- /dev/null +++ b/trunk/Documentation/usb/functionfs.txt @@ -0,0 +1,67 @@ +*How FunctionFS works* + +From kernel point of view it is just a composite function with some +unique behaviour. It may be added to an USB configuration only after +the user space driver has registered by writing descriptors and +strings (the user space program has to provide the same information +that kernel level composite functions provide when they are added to +the configuration). + +This in particular means that the composite initialisation functions +may not be in init section (ie. may not use the __init tag). + +From user space point of view it is a file system which when +mounted provides an "ep0" file. User space driver need to +write descriptors and strings to that file. It does not need +to worry about endpoints, interfaces or strings numbers but +simply provide descriptors such as if the function was the +only one (endpoints and strings numbers starting from one and +interface numbers starting from zero). The FunctionFS changes +them as needed also handling situation when numbers differ in +different configurations. + +When descriptors and strings are written "ep#" files appear +(one for each declared endpoint) which handle communication on +a single endpoint. Again, FunctionFS takes care of the real +numbers and changing of the configuration (which means that +"ep1" file may be really mapped to (say) endpoint 3 (and when +configuration changes to (say) endpoint 2)). "ep0" is used +for receiving events and handling setup requests. + +When all files are closed the function disables itself. + +What I also want to mention is that the FunctionFS is designed in such +a way that it is possible to mount it several times so in the end +a gadget could use several FunctionFS functions. The idea is that +each FunctionFS instance is identified by the device name used +when mounting. + +One can imagine a gadget that has an Ethernet, MTP and HID interfaces +where the last two are implemented via FunctionFS. On user space +level it would look like this: + +$ insmod g_ffs.ko idVendor= iSerialNumber= functions=mtp,hid +$ mkdir /dev/ffs-mtp && mount -t functionfs mtp /dev/ffs-mtp +$ ( cd /dev/ffs-mtp && mtp-daemon ) & +$ mkdir /dev/ffs-hid && mount -t functionfs hid /dev/ffs-hid +$ ( cd /dev/ffs-hid && hid-daemon ) & + +On kernel level the gadget checks ffs_data->dev_name to identify +whether it's FunctionFS designed for MTP ("mtp") or HID ("hid"). + +If no "functions" module parameters is supplied, the driver accepts +just one function with any name. + +When "functions" module parameter is supplied, only functions +with listed names are accepted. In particular, if the "functions" +parameter's value is just a one-element list, then the behaviour +is similar to when there is no "functions" at all; however, +only a function with the specified name is accepted. + +The gadget is registered only after all the declared function +filesystems have been mounted and USB descriptors of all functions +have been written to their ep0's. + +Conversely, the gadget is unregistered after the first USB function +closes its endpoints. + diff --git a/trunk/Documentation/usb/wusb-cbaf b/trunk/Documentation/usb/wusb-cbaf index 426ddaaef96f..8b3d43efce90 100644 --- a/trunk/Documentation/usb/wusb-cbaf +++ b/trunk/Documentation/usb/wusb-cbaf @@ -36,7 +36,7 @@ COMMAND/ARGS are get-cdid DEVICE - Get the device ID associated to the HOST-CHDI we sent with + Get the device ID associated to the HOST-CHID we sent with 'set-chid'. We might not know about it. set-cc DEVICE diff --git a/trunk/Documentation/video4linux/README.cpia2 b/trunk/Documentation/video4linux/README.cpia2 index ce8213d28b67..38e742fd0df7 100644 --- a/trunk/Documentation/video4linux/README.cpia2 +++ b/trunk/Documentation/video4linux/README.cpia2 @@ -12,7 +12,7 @@ gqcam application to view this stream. The driver is implemented as two kernel modules. The cpia2 module contains the camera functions and the V4L interface. The cpia2_usb module contains usb specific functions. The main reason for this was the size of the -module was getting out of hand, so I separted them. It is not likely that +module was getting out of hand, so I separated them. It is not likely that there will be a parallel port version. FEATURES: diff --git a/trunk/drivers/staging/vme/vme_api.txt b/trunk/Documentation/vme_api.txt similarity index 100% rename from trunk/drivers/staging/vme/vme_api.txt rename to trunk/Documentation/vme_api.txt diff --git a/trunk/Documentation/zh_CN/magic-number.txt b/trunk/Documentation/zh_CN/magic-number.txt index f606ba8598cf..4263022f5002 100644 --- a/trunk/Documentation/zh_CN/magic-number.txt +++ b/trunk/Documentation/zh_CN/magic-number.txt @@ -160,7 +160,7 @@ QUEUE_MAGIC_USED 0xf7e1cc33 queue_entry drivers/scsi/arm/queue.c HTB_CMAGIC 0xFEFAFEF1 htb_class net/sched/sch_htb.c NMI_MAGIC 0x48414d4d455201 nmi_s arch/mips/include/asm/sn/nmi.h -请注意，在声音记忆管理中仍然有每一些被定义的驱动魔术值。查看include/sound/sndmagic.h来获取他们完整的列表信息。很多OSS声音驱动拥有自己从声卡PCI ID构建的魔术值-他们也没有被列在这里。 +请注意，在声音记忆管理中仍然有一些特殊的为每个驱动定义的魔术值。查看include/sound/sndmagic.h来获取他们完整的列表信息。很多OSS声音驱动拥有自己从声卡PCI ID构建的魔术值-他们也没有被列在这里。 IrDA子系统也使用了大量的自己的魔术值，查看include/net/irda/irda.h来获取他们完整的信息。 diff --git a/trunk/MAINTAINERS b/trunk/MAINTAINERS index 17360c7ac27b..9c293bf340b1 100644 --- a/trunk/MAINTAINERS +++ b/trunk/MAINTAINERS @@ -1826,6 +1826,12 @@ L: linux-kernel@zh-kernel.org (moderated for non-subscribers) S: Maintained F: Documentation/zh_CN/ +CHIPIDEA USB HIGH SPEED DUAL ROLE CONTROLLER +M: Alexander Shishkin +L: linux-usb@vger.kernel.org +S: Maintained +F: drivers/usb/chipidea/ + CISCO VIC ETHERNET NIC DRIVER M: Christian Benvenuti M: Roopa Prabhu @@ -2906,7 +2912,7 @@ S: Maintained F: arch/frv/ FUJITSU LAPTOP EXTRAS -M: Jonathan Woithe +M: Jonathan Woithe L: platform-driver-x86@vger.kernel.org S: Maintained F: drivers/platform/x86/fujitsu-laptop.c @@ -3400,6 +3406,7 @@ IIO SUBSYSTEM AND DRIVERS M: Jonathan Cameron L: linux-iio@vger.kernel.org S: Maintained +F: drivers/iio/ F: drivers/staging/iio/ IKANOS/ADI EAGLE ADSL USB DRIVER @@ -3619,6 +3626,14 @@ S: Supported W: http://wireless.kernel.org/en/users/Drivers/iwmc3200wifi F: drivers/net/wireless/iwmc3200wifi/ +INTEL MANAGEMENT ENGINE (mei) +M: Tomas Winkler +L: linux-kernel@vger.kernel.org +S: Supported +F: include/linux/mei.h +F: drivers/misc/mei/* +F: Documentation/mei/* + IOC3 ETHERNET DRIVER M: Ralf Baechle L: linux-mips@linux-mips.org @@ -6558,7 +6573,7 @@ M: Paul Mundt L: linux-sh@vger.kernel.org W: http://www.linux-sh.org Q: http://patchwork.kernel.org/project/linux-sh/list/ -T: git git://git.kernel.org/pub/scm/linux/kernel/git/lethal/sh-2.6.git sh-latest +T: git git://github.com/pmundt/linux-sh.git sh-latest S: Supported F: Documentation/sh/ F: arch/sh/ @@ -7053,6 +7068,14 @@ W: http://pegasus2.sourceforge.net/ S: Maintained F: drivers/net/usb/pegasus.* +USB PHY LAYER +M: Felipe Balbi +L: linux-usb@vger.kernel.org +T: git git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git +S: Maintained +F: drivers/usb/phy/ +F: drivers/usb/otg/ + USB PRINTER DRIVER (usblp) M: Pete Zaitcev L: linux-usb@vger.kernel.org @@ -7336,6 +7359,18 @@ S: Maintained F: drivers/vlynq/vlynq.c F: include/linux/vlynq.h +VME SUBSYSTEM +M: Martyn Welch +M: Manohar Vanga +M: Greg Kroah-Hartman +L: devel@driverdev.osuosl.org +S: Maintained +T: git git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git +F: Documentation/vme_api.txt +F: drivers/staging/vme/ +F: drivers/vme/ +F: include/linux/vme* + VMWARE VMXNET3 ETHERNET DRIVER M: Shreyas Bhatewara M: "VMware, Inc." diff --git a/trunk/Makefile b/trunk/Makefile index a6879630a3ea..546515cd07f3 100644 --- a/trunk/Makefile +++ b/trunk/Makefile @@ -400,8 +400,10 @@ export MODVERDIR := $(if $(KBUILD_EXTMOD),$(firstword $(KBUILD_EXTMOD))/).tmp_ve # Files to ignore in find ... statements -RCS_FIND_IGNORE := \( -name SCCS -o -name BitKeeper -o -name .svn -o -name CVS -o -name .pc -o -name .hg -o -name .git \) -prune -o -export RCS_TAR_IGNORE := --exclude SCCS --exclude BitKeeper --exclude .svn --exclude CVS --exclude .pc --exclude .hg --exclude .git +RCS_FIND_IGNORE := \( -name SCCS -o -name BitKeeper -o -name .svn -o -name CVS \ + -o -name .pc -o -name .hg -o -name .git \) -prune -o +export RCS_TAR_IGNORE := --exclude SCCS --exclude BitKeeper --exclude .svn \ + --exclude CVS --exclude .pc --exclude .hg --exclude .git # =========================================================================== # Rules shared between *config targets and build targets @@ -966,7 +968,7 @@ prepare3: include/config/kernel.release ifneq ($(KBUILD_SRC),) @$(kecho) ' Using $(srctree) as source for kernel' $(Q)if [ -f $(srctree)/.config -o -d $(srctree)/include/config ]; then \ - echo " $(srctree) is not clean, please run 'make mrproper'";\ + echo " $(srctree) is not clean, please run 'make mrproper'"; \ echo " in the '$(srctree)' directory.";\ /bin/false; \ fi; @@ -1003,8 +1005,8 @@ define filechk_utsrelease.h endef define filechk_version.h - (echo \#define LINUX_VERSION_CODE $(shell \ - expr $(VERSION) \* 65536 + 0$(PATCHLEVEL) \* 256 + 0$(SUBLEVEL)); \ + (echo \#define LINUX_VERSION_CODE $(shell \ + expr $(VERSION) \* 65536 + 0$(PATCHLEVEL) \* 256 + 0$(SUBLEVEL)); \ echo '#define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + (c))';) endef @@ -1471,6 +1473,13 @@ kernelrelease: kernelversion: @echo $(KERNELVERSION) +# Clear a bunch of variables before executing the submake +tools/: FORCE + $(Q)$(MAKE) LDFLAGS= MAKEFLAGS= -C $(src)/tools/ + +tools/%: FORCE + $(Q)$(MAKE) LDFLAGS= MAKEFLAGS= -C $(src)/tools/ $* + # Single targets # --------------------------------------------------------------------------- # Single targets are compatible with: diff --git a/trunk/README b/trunk/README index 0d5a7ddbe3ee..9beaed0ed620 100644 --- a/trunk/README +++ b/trunk/README @@ -1,4 +1,4 @@ - Linux kernel release 3.x + Linux kernel release 3.x These are the release notes for Linux version 3. Read them carefully, as they tell you what this is all about, explain how to install the @@ -62,13 +62,13 @@ INSTALLING the kernel source: directory where you have permissions (eg. your home directory) and unpack it: - gzip -cd linux-3.X.tar.gz | tar xvf - + gzip -cd linux-3.X.tar.gz | tar xvf - or - bzip2 -dc linux-3.X.tar.bz2 | tar xvf - + bzip2 -dc linux-3.X.tar.bz2 | tar xvf - - Replace "XX" with the version number of the latest kernel. + Replace "X" with the version number of the latest kernel. Do NOT use the /usr/src/linux area! This area has a (usually incomplete) set of kernel headers that are used by the library header @@ -78,49 +78,43 @@ INSTALLING the kernel source: - You can also upgrade between 3.x releases by patching. Patches are distributed in the traditional gzip and the newer bzip2 format. To install by patching, get all the newer patch files, enter the - top level directory of the kernel source (linux-3.x) and execute: + top level directory of the kernel source (linux-3.X) and execute: - gzip -cd ../patch-3.x.gz | patch -p1 + gzip -cd ../patch-3.x.gz | patch -p1 or - bzip2 -dc ../patch-3.x.bz2 | patch -p1 - (repeat xx for all versions bigger than the version of your current - source tree, _in_order_) and you should be ok. You may want to remove - the backup files (xxx~ or xxx.orig), and make sure that there are no - failed patches (xxx# or xxx.rej). If there are, either you or me has - made a mistake. + bzip2 -dc ../patch-3.x.bz2 | patch -p1 + + Replace "x" for all versions bigger than the version "X" of your current + source tree, _in_order_, and you should be ok. You may want to remove + the backup files (some-file-name~ or some-file-name.orig), and make sure + that there are no failed patches (some-file-name# or some-file-name.rej). + If there are, either you or I have made a mistake. Unlike patches for the 3.x kernels, patches for the 3.x.y kernels (also known as the -stable kernels) are not incremental but instead apply - directly to the base 3.x kernel. Please read - Documentation/applying-patches.txt for more information. + directly to the base 3.x kernel. For example, if your base kernel is 3.0 + and you want to apply the 3.0.3 patch, you must not first apply the 3.0.1 + and 3.0.2 patches. Similarly, if you are running kernel version 3.0.2 and + want to jump to 3.0.3, you must first reverse the 3.0.2 patch (that is, + patch -R) _before_ applying the 3.0.3 patch. You can read more on this in + Documentation/applying-patches.txt Alternatively, the script patch-kernel can be used to automate this process. It determines the current kernel version and applies any patches found. - linux/scripts/patch-kernel linux + linux/scripts/patch-kernel linux The first argument in the command above is the location of the kernel source. Patches are applied from the current directory, but an alternative directory can be specified as the second argument. - - If you are upgrading between releases using the stable series patches - (for example, patch-3.x.y), note that these "dot-releases" are - not incremental and must be applied to the 3.x base tree. For - example, if your base kernel is 3.0 and you want to apply the - 3.0.3 patch, you do not and indeed must not first apply the - 3.0.1 and 3.0.2 patches. Similarly, if you are running kernel - version 3.0.2 and want to jump to 3.0.3, you must first - reverse the 3.0.2 patch (that is, patch -R) _before_ applying - the 3.0.3 patch. - You can read more on this in Documentation/applying-patches.txt - - Make sure you have no stale .o files and dependencies lying around: - cd linux - make mrproper + cd linux + make mrproper You should now have the sources correctly installed. @@ -137,21 +131,23 @@ SOFTWARE REQUIREMENTS BUILD directory for the kernel: - When compiling the kernel all output files will per default be + When compiling the kernel, all output files will per default be stored together with the kernel source code. Using the option "make O=output/dir" allow you to specify an alternate place for the output files (including .config). Example: - kernel source code: /usr/src/linux-3.N - build directory: /home/name/build/kernel - To configure and build the kernel use: - cd /usr/src/linux-3.N - make O=/home/name/build/kernel menuconfig - make O=/home/name/build/kernel - sudo make O=/home/name/build/kernel modules_install install + kernel source code: /usr/src/linux-3.X + build directory: /home/name/build/kernel + + To configure and build the kernel, use: - Please note: If the 'O=output/dir' option is used then it must be + cd /usr/src/linux-3.X + make O=/home/name/build/kernel menuconfig + make O=/home/name/build/kernel + sudo make O=/home/name/build/kernel modules_install install + + Please note: If the 'O=output/dir' option is used, then it must be used for all invocations of make. CONFIGURING the kernel: @@ -163,61 +159,78 @@ CONFIGURING the kernel: new version with minimal work, use "make oldconfig", which will only ask you for the answers to new questions. - - Alternate configuration commands are: - "make config" Plain text interface. - "make menuconfig" Text based color menus, radiolists & dialogs. - "make nconfig" Enhanced text based color menus. - "make xconfig" X windows (Qt) based configuration tool. - "make gconfig" X windows (Gtk) based configuration tool. - "make oldconfig" Default all questions based on the contents of - your existing ./.config file and asking about - new config symbols. - "make silentoldconfig" - Like above, but avoids cluttering the screen - with questions already answered. - Additionally updates the dependencies. - "make defconfig" Create a ./.config file by using the default - symbol values from either arch/$ARCH/defconfig - or arch/$ARCH/configs/${PLATFORM}_defconfig, - depending on the architecture. - "make ${PLATFORM}_defconfig" - Create a ./.config file by using the default - symbol values from - arch/$ARCH/configs/${PLATFORM}_defconfig. - Use "make help" to get a list of all available - platforms of your architecture. - "make allyesconfig" - Create a ./.config file by setting symbol - values to 'y' as much as possible. - "make allmodconfig" - Create a ./.config file by setting symbol - values to 'm' as much as possible. - "make allnoconfig" Create a ./.config file by setting symbol - values to 'n' as much as possible. - "make randconfig" Create a ./.config file by setting symbol - values to random values. + - Alternative configuration commands are: + + "make config" Plain text interface. + + "make menuconfig" Text based color menus, radiolists & dialogs. + + "make nconfig" Enhanced text based color menus. + + "make xconfig" X windows (Qt) based configuration tool. + + "make gconfig" X windows (Gtk) based configuration tool. + + "make oldconfig" Default all questions based on the contents of + your existing ./.config file and asking about + new config symbols. + + "make silentoldconfig" + Like above, but avoids cluttering the screen + with questions already answered. + Additionally updates the dependencies. + + "make defconfig" Create a ./.config file by using the default + symbol values from either arch/$ARCH/defconfig + or arch/$ARCH/configs/${PLATFORM}_defconfig, + depending on the architecture. + + "make ${PLATFORM}_defconfig" + Create a ./.config file by using the default + symbol values from + arch/$ARCH/configs/${PLATFORM}_defconfig. + Use "make help" to get a list of all available + platforms of your architecture. + + "make allyesconfig" + Create a ./.config file by setting symbol + values to 'y' as much as possible. + + "make allmodconfig" + Create a ./.config file by setting symbol + values to 'm' as much as possible. + + "make allnoconfig" Create a ./.config file by setting symbol + values to 'n' as much as possible. + + "make randconfig" Create a ./.config file by setting symbol + values to random values. You can find more information on using the Linux kernel config tools in Documentation/kbuild/kconfig.txt. - NOTES on "make config": - - having unnecessary drivers will make the kernel bigger, and can - under some circumstances lead to problems: probing for a - nonexistent controller card may confuse your other controllers - - compiling the kernel with "Processor type" set higher than 386 - will result in a kernel that does NOT work on a 386. The - kernel will detect this on bootup, and give up. - - A kernel with math-emulation compiled in will still use the - coprocessor if one is present: the math emulation will just - never get used in that case. The kernel will be slightly larger, - but will work on different machines regardless of whether they - have a math coprocessor or not. - - the "kernel hacking" configuration details usually result in a - bigger or slower kernel (or both), and can even make the kernel - less stable by configuring some routines to actively try to - break bad code to find kernel problems (kmalloc()). Thus you - should probably answer 'n' to the questions for - "development", "experimental", or "debugging" features. + - NOTES on "make config": + + - Having unnecessary drivers will make the kernel bigger, and can + under some circumstances lead to problems: probing for a + nonexistent controller card may confuse your other controllers + + - Compiling the kernel with "Processor type" set higher than 386 + will result in a kernel that does NOT work on a 386. The + kernel will detect this on bootup, and give up. + + - A kernel with math-emulation compiled in will still use the + coprocessor if one is present: the math emulation will just + never get used in that case. The kernel will be slightly larger, + but will work on different machines regardless of whether they + have a math coprocessor or not. + + - The "kernel hacking" configuration details usually result in a + bigger or slower kernel (or both), and can even make the kernel + less stable by configuring some routines to actively try to + break bad code to find kernel problems (kmalloc()). Thus you + should probably answer 'n' to the questions for "development", + "experimental", or "debugging" features. COMPILING the kernel: @@ -230,7 +243,7 @@ COMPILING the kernel: possible to do "make install" if you have lilo installed to suit the kernel makefiles, but you may want to check your particular lilo setup first. - To do the actual install you have to be root, but none of the normal + To do the actual install, you have to be root, but none of the normal build should require that. Don't take the name of root in vain. - If you configured any of the parts of the kernel as `modules', you @@ -238,13 +251,13 @@ COMPILING the kernel: - Verbose kernel compile/build output: - Normally the kernel build system runs in a fairly quiet mode (but not + Normally, the kernel build system runs in a fairly quiet mode (but not totally silent). However, sometimes you or other kernel developers need to see compile, link, or other commands exactly as they are executed. For this, use "verbose" build mode. This is done by inserting "V=1" in the "make" command. E.g.: - make V=1 all + make V=1 all To have the build system also tell the reason for the rebuild of each target, use "V=2". The default is "V=0". @@ -256,6 +269,7 @@ COMPILING the kernel: are installing a new kernel with the same version number as your working kernel, make a backup of your modules directory before you do a "make modules_install". + Alternatively, before compiling, use the kernel config option "LOCALVERSION" to append a unique suffix to the regular kernel version. LOCALVERSION can be set in the "General Setup" menu. @@ -267,7 +281,7 @@ COMPILING the kernel: - Booting a kernel directly from a floppy without the assistance of a bootloader such as LILO, is no longer supported. - If you boot Linux from the hard drive, chances are you use LILO which + If you boot Linux from the hard drive, chances are you use LILO, which uses the kernel image as specified in the file /etc/lilo.conf. The kernel image file is usually /vmlinuz, /boot/vmlinuz, /bzImage or /boot/bzImage. To use the new kernel, save a copy of the old image @@ -306,21 +320,21 @@ IF SOMETHING GOES WRONG: - If the bug results in a message like - unable to handle kernel paging request at address C0000010 - Oops: 0002 - EIP: 0010:XXXXXXXX - eax: xxxxxxxx ebx: xxxxxxxx ecx: xxxxxxxx edx: xxxxxxxx - esi: xxxxxxxx edi: xxxxxxxx ebp: xxxxxxxx - ds: xxxx es: xxxx fs: xxxx gs: xxxx - Pid: xx, process nr: xx - xx xx xx xx xx xx xx xx xx xx + unable to handle kernel paging request at address C0000010 + Oops: 0002 + EIP: 0010:XXXXXXXX + eax: xxxxxxxx ebx: xxxxxxxx ecx: xxxxxxxx edx: xxxxxxxx + esi: xxxxxxxx edi: xxxxxxxx ebp: xxxxxxxx + ds: xxxx es: xxxx fs: xxxx gs: xxxx + Pid: xx, process nr: xx + xx xx xx xx xx xx xx xx xx xx or similar kernel debugging information on your screen or in your system log, please duplicate it *exactly*. The dump may look incomprehensible to you, but it does contain information that may help debugging the problem. The text above the dump is also important: it tells something about why the kernel dumped code (in - the above example it's due to a bad kernel pointer). More information + the above example, it's due to a bad kernel pointer). More information on making sense of the dump is in Documentation/oops-tracing.txt - If you compiled the kernel with CONFIG_KALLSYMS you can send the dump @@ -328,7 +342,7 @@ IF SOMETHING GOES WRONG: sense of the dump (but compiling with CONFIG_KALLSYMS is usually preferred). This utility can be downloaded from ftp://ftp..kernel.org/pub/linux/utils/kernel/ksymoops/ . - Alternately you can do the dump lookup by hand: + Alternatively, you can do the dump lookup by hand: - In debugging dumps like the above, it helps enormously if you can look up what the EIP value means. The hex value as such doesn't help @@ -342,7 +356,7 @@ IF SOMETHING GOES WRONG: the file 'linux/vmlinux'. To extract the namelist and match it against the EIP from the kernel crash, do: - nm vmlinux | sort | less + nm vmlinux | sort | less This will give you a list of kernel addresses sorted in ascending order, from which it is simple to find the function that contains the @@ -361,7 +375,7 @@ IF SOMETHING GOES WRONG: kernel image or similar), telling me as much about your setup as possible will help. Please read the REPORTING-BUGS document for details. - - Alternately, you can use gdb on a running kernel. (read-only; i.e. you + - Alternatively, you can use gdb on a running kernel. (read-only; i.e. you cannot change values or set break points.) To do this, first compile the kernel with -g; edit arch/i386/Makefile appropriately, then do a "make clean". You'll also need to enable CONFIG_PROC_FS (via "make config"). diff --git a/trunk/arch/alpha/kernel/pci_iommu.c b/trunk/arch/alpha/kernel/pci_iommu.c index cd634795aa9c..3f844d26d2c7 100644 --- a/trunk/arch/alpha/kernel/pci_iommu.c +++ b/trunk/arch/alpha/kernel/pci_iommu.c @@ -236,7 +236,7 @@ static int pci_dac_dma_supported(struct pci_dev *dev, u64 mask) ok = 0; /* If both conditions above are met, we are fine. */ - DBGA("pci_dac_dma_supported %s from %p\n", + DBGA("pci_dac_dma_supported %s from %pf\n", ok ? "yes" : "no", __builtin_return_address(0)); return ok; @@ -268,7 +268,7 @@ pci_map_single_1(struct pci_dev *pdev, void *cpu_addr, size_t size, && paddr + size <= __direct_map_size) { ret = paddr + __direct_map_base; - DBGA2("pci_map_single: [%p,%zx] -> direct %llx from %p\n", + DBGA2("pci_map_single: [%p,%zx] -> direct %llx from %pf\n", cpu_addr, size, ret, __builtin_return_address(0)); return ret; @@ -279,7 +279,7 @@ pci_map_single_1(struct pci_dev *pdev, void *cpu_addr, size_t size, if (dac_allowed) { ret = paddr + alpha_mv.pci_dac_offset; - DBGA2("pci_map_single: [%p,%zx] -> DAC %llx from %p\n", + DBGA2("pci_map_single: [%p,%zx] -> DAC %llx from %pf\n", cpu_addr, size, ret, __builtin_return_address(0)); return ret; @@ -316,7 +316,7 @@ pci_map_single_1(struct pci_dev *pdev, void *cpu_addr, size_t size, ret = arena->dma_base + dma_ofs * PAGE_SIZE; ret += (unsigned long)cpu_addr & ~PAGE_MASK; - DBGA2("pci_map_single: [%p,%zx] np %ld -> sg %llx from %p\n", + DBGA2("pci_map_single: [%p,%zx] np %ld -> sg %llx from %pf\n", cpu_addr, size, npages, ret, __builtin_return_address(0)); return ret; @@ -385,14 +385,14 @@ static void alpha_pci_unmap_page(struct device *dev, dma_addr_t dma_addr, && dma_addr < __direct_map_base + __direct_map_size) { /* Nothing to do. */ - DBGA2("pci_unmap_single: direct [%llx,%zx] from %p\n", + DBGA2("pci_unmap_single: direct [%llx,%zx] from %pf\n", dma_addr, size, __builtin_return_address(0)); return; } if (dma_addr > 0xffffffff) { - DBGA2("pci64_unmap_single: DAC [%llx,%zx] from %p\n", + DBGA2("pci64_unmap_single: DAC [%llx,%zx] from %pf\n", dma_addr, size, __builtin_return_address(0)); return; } @@ -424,7 +424,7 @@ static void alpha_pci_unmap_page(struct device *dev, dma_addr_t dma_addr, spin_unlock_irqrestore(&arena->lock, flags); - DBGA2("pci_unmap_single: sg [%llx,%zx] np %ld from %p\n", + DBGA2("pci_unmap_single: sg [%llx,%zx] np %ld from %pf\n", dma_addr, size, npages, __builtin_return_address(0)); } @@ -447,7 +447,7 @@ static void *alpha_pci_alloc_coherent(struct device *dev, size_t size, cpu_addr = (void *)__get_free_pages(gfp, order); if (! cpu_addr) { printk(KERN_INFO "pci_alloc_consistent: " - "get_free_pages failed from %p\n", + "get_free_pages failed from %pf\n", __builtin_return_address(0)); /* ??? Really atomic allocation? Otherwise we could play with vmalloc and sg if we can't find contiguous memory. */ @@ -466,7 +466,7 @@ static void *alpha_pci_alloc_coherent(struct device *dev, size_t size, goto try_again; } - DBGA2("pci_alloc_consistent: %zx -> [%p,%llx] from %p\n", + DBGA2("pci_alloc_consistent: %zx -> [%p,%llx] from %pf\n", size, cpu_addr, *dma_addrp, __builtin_return_address(0)); return cpu_addr; @@ -486,7 +486,7 @@ static void alpha_pci_free_coherent(struct device *dev, size_t size, pci_unmap_single(pdev, dma_addr, size, PCI_DMA_BIDIRECTIONAL); free_pages((unsigned long)cpu_addr, get_order(size)); - DBGA2("pci_free_consistent: [%llx,%zx] from %p\n", + DBGA2("pci_free_consistent: [%llx,%zx] from %pf\n", dma_addr, size, __builtin_return_address(0)); } diff --git a/trunk/arch/alpha/kernel/perf_event.c b/trunk/arch/alpha/kernel/perf_event.c index 0dae252f7a33..d821b17047e0 100644 --- a/trunk/arch/alpha/kernel/perf_event.c +++ b/trunk/arch/alpha/kernel/perf_event.c @@ -824,7 +824,6 @@ static void alpha_perf_event_irq_handler(unsigned long la_ptr, idx = la_ptr; - perf_sample_data_init(&data, 0); for (j = 0; j < cpuc->n_events; j++) { if (cpuc->current_idx[j] == idx) break; @@ -848,7 +847,7 @@ static void alpha_perf_event_irq_handler(unsigned long la_ptr, hwc = &event->hw; alpha_perf_event_update(event, hwc, idx, alpha_pmu->pmc_max_period[idx]+1); - data.period = event->hw.last_period; + perf_sample_data_init(&data, 0, hwc->last_period); if (alpha_perf_event_set_period(event, hwc, idx)) { if (perf_event_overflow(event, &data, regs)) { diff --git a/trunk/arch/arm/Kconfig b/trunk/arch/arm/Kconfig index 0a2fc01891a9..76edcfe8b56f 100644 --- a/trunk/arch/arm/Kconfig +++ b/trunk/arch/arm/Kconfig @@ -1914,10 +1914,10 @@ choice default ZBOOT_ROM_NONE help Include experimental SD/MMC loading code in the ROM-able zImage. - With this enabled it is possible to write the the ROM-able zImage + With this enabled it is possible to write the ROM-able zImage kernel image to an MMC or SD card and boot the kernel straight from the reset vector. At reset the processor Mask ROM will load - the first part of the the ROM-able zImage which in turn loads the + the first part of the ROM-able zImage which in turn loads the rest the kernel image to RAM. config ZBOOT_ROM_NONE diff --git a/trunk/arch/arm/boot/dts/at91sam9g45.dtsi b/trunk/arch/arm/boot/dts/at91sam9g45.dtsi index c8042147eaa2..7dbccaf199f7 100644 --- a/trunk/arch/arm/boot/dts/at91sam9g45.dtsi +++ b/trunk/arch/arm/boot/dts/at91sam9g45.dtsi @@ -199,6 +199,43 @@ interrupts = <25 4>; status = "disabled"; }; + + adc0: adc@fffb0000 { + compatible = "atmel,at91sam9260-adc"; + reg = <0xfffb0000 0x100>; + interrupts = <20 4>; + atmel,adc-use-external-triggers; + atmel,adc-channels-used = <0xff>; + atmel,adc-vref = <3300>; + atmel,adc-num-channels = <8>; + atmel,adc-startup-time = <40>; + atmel,adc-channel-base = <0x30>; + atmel,adc-drdy-mask = <0x10000>; + atmel,adc-status-register = <0x1c>; + atmel,adc-trigger-register = <0x08>; + + trigger@0 { + trigger-name = "external-rising"; + trigger-value = <0x1>; + trigger-external; + }; + trigger@1 { + trigger-name = "external-falling"; + trigger-value = <0x2>; + trigger-external; + }; + + trigger@2 { + trigger-name = "external-any"; + trigger-value = <0x3>; + trigger-external; + }; + + trigger@3 { + trigger-name = "continuous"; + trigger-value = <0x6>; + }; + }; }; nand0: nand@40000000 { diff --git a/trunk/arch/arm/boot/dts/at91sam9x5.dtsi b/trunk/arch/arm/boot/dts/at91sam9x5.dtsi index dd4ed748469a..6b3ef4339ae7 100644 --- a/trunk/arch/arm/boot/dts/at91sam9x5.dtsi +++ b/trunk/arch/arm/boot/dts/at91sam9x5.dtsi @@ -190,6 +190,44 @@ interrupts = <27 4>; status = "disabled"; }; + + adc0: adc@f804c000 { + compatible = "atmel,at91sam9260-adc"; + reg = <0xf804c000 0x100>; + interrupts = <19 4>; + atmel,adc-use-external; + atmel,adc-channels-used = <0xffff>; + atmel,adc-vref = <3300>; + atmel,adc-num-channels = <12>; + atmel,adc-startup-time = <40>; + atmel,adc-channel-base = <0x50>; + atmel,adc-drdy-mask = <0x1000000>; + atmel,adc-status-register = <0x30>; + atmel,adc-trigger-register = <0xc0>; + + trigger@0 { + trigger-name = "external-rising"; + trigger-value = <0x1>; + trigger-external; + }; + + trigger@1 { + trigger-name = "external-falling"; + trigger-value = <0x2>; + trigger-external; + }; + + trigger@2 { + trigger-name = "external-any"; + trigger-value = <0x3>; + trigger-external; + }; + + trigger@3 { + trigger-name = "continuous"; + trigger-value = <0x6>; + }; + }; }; nand0: nand@40000000 { diff --git a/trunk/arch/arm/configs/bcmring_defconfig b/trunk/arch/arm/configs/bcmring_defconfig index 795374d48f81..9e6a8fe13164 100644 --- a/trunk/arch/arm/configs/bcmring_defconfig +++ b/trunk/arch/arm/configs/bcmring_defconfig @@ -11,7 +11,7 @@ CONFIG_KALLSYMS_EXTRA_PASS=y # CONFIG_TIMERFD is not set # CONFIG_EVENTFD is not set # CONFIG_AIO is not set -CONFIG_PERF_COUNTERS=y +CONFIG_PERF_EVENTS=y # CONFIG_VM_EVENT_COUNTERS is not set # CONFIG_SLUB_DEBUG is not set # CONFIG_COMPAT_BRK is not set diff --git a/trunk/arch/arm/kernel/perf_event_v6.c b/trunk/arch/arm/kernel/perf_event_v6.c index b78af0cc6ef3..ab627a740fa3 100644 --- a/trunk/arch/arm/kernel/perf_event_v6.c +++ b/trunk/arch/arm/kernel/perf_event_v6.c @@ -489,8 +489,6 @@ armv6pmu_handle_irq(int irq_num, */ armv6_pmcr_write(pmcr); - perf_sample_data_init(&data, 0); - cpuc = &__get_cpu_var(cpu_hw_events); for (idx = 0; idx < cpu_pmu->num_events; ++idx) { struct perf_event *event = cpuc->events[idx]; @@ -509,7 +507,7 @@ armv6pmu_handle_irq(int irq_num, hwc = &event->hw; armpmu_event_update(event, hwc, idx); - data.period = event->hw.last_period; + perf_sample_data_init(&data, 0, hwc->last_period); if (!armpmu_event_set_period(event, hwc, idx)) continue; diff --git a/trunk/arch/arm/kernel/perf_event_v7.c b/trunk/arch/arm/kernel/perf_event_v7.c index 00755d82e2f2..d3c536068162 100644 --- a/trunk/arch/arm/kernel/perf_event_v7.c +++ b/trunk/arch/arm/kernel/perf_event_v7.c @@ -1077,8 +1077,6 @@ static irqreturn_t armv7pmu_handle_irq(int irq_num, void *dev) */ regs = get_irq_regs(); - perf_sample_data_init(&data, 0); - cpuc = &__get_cpu_var(cpu_hw_events); for (idx = 0; idx < cpu_pmu->num_events; ++idx) { struct perf_event *event = cpuc->events[idx]; @@ -1097,7 +1095,7 @@ static irqreturn_t armv7pmu_handle_irq(int irq_num, void *dev) hwc = &event->hw; armpmu_event_update(event, hwc, idx); - data.period = event->hw.last_period; + perf_sample_data_init(&data, 0, hwc->last_period); if (!armpmu_event_set_period(event, hwc, idx)) continue; diff --git a/trunk/arch/arm/kernel/perf_event_xscale.c b/trunk/arch/arm/kernel/perf_event_xscale.c index 71a21e6712f5..e34e7254e652 100644 --- a/trunk/arch/arm/kernel/perf_event_xscale.c +++ b/trunk/arch/arm/kernel/perf_event_xscale.c @@ -248,8 +248,6 @@ xscale1pmu_handle_irq(int irq_num, void *dev) regs = get_irq_regs(); - perf_sample_data_init(&data, 0); - cpuc = &__get_cpu_var(cpu_hw_events); for (idx = 0; idx < cpu_pmu->num_events; ++idx) { struct perf_event *event = cpuc->events[idx]; @@ -263,7 +261,7 @@ xscale1pmu_handle_irq(int irq_num, void *dev) hwc = &event->hw; armpmu_event_update(event, hwc, idx); - data.period = event->hw.last_period; + perf_sample_data_init(&data, 0, hwc->last_period); if (!armpmu_event_set_period(event, hwc, idx)) continue; @@ -588,8 +586,6 @@ xscale2pmu_handle_irq(int irq_num, void *dev) regs = get_irq_regs(); - perf_sample_data_init(&data, 0); - cpuc = &__get_cpu_var(cpu_hw_events); for (idx = 0; idx < cpu_pmu->num_events; ++idx) { struct perf_event *event = cpuc->events[idx]; @@ -603,7 +599,7 @@ xscale2pmu_handle_irq(int irq_num, void *dev) hwc = &event->hw; armpmu_event_update(event, hwc, idx); - data.period = event->hw.last_period; + perf_sample_data_init(&data, 0, hwc->last_period); if (!armpmu_event_set_period(event, hwc, idx)) continue; diff --git a/trunk/arch/arm/mach-at91/at91sam9260.c b/trunk/arch/arm/mach-at91/at91sam9260.c index a27bbec50ca3..2b1e438ed878 100644 --- a/trunk/arch/arm/mach-at91/at91sam9260.c +++ b/trunk/arch/arm/mach-at91/at91sam9260.c @@ -55,6 +55,13 @@ static struct clk adc_clk = { .pmc_mask = 1 << AT91SAM9260_ID_ADC, .type = CLK_TYPE_PERIPHERAL, }; + +static struct clk adc_op_clk = { + .name = "adc_op_clk", + .type = CLK_TYPE_PERIPHERAL, + .rate_hz = 5000000, +}; + static struct clk usart0_clk = { .name = "usart0_clk", .pmc_mask = 1 << AT91SAM9260_ID_US0, @@ -166,6 +173,7 @@ static struct clk *periph_clocks[] __initdata = { &pioB_clk, &pioC_clk, &adc_clk, + &adc_op_clk, &usart0_clk, &usart1_clk, &usart2_clk, diff --git a/trunk/arch/arm/mach-at91/at91sam9260_devices.c b/trunk/arch/arm/mach-at91/at91sam9260_devices.c index d556de141114..0ded951f785a 100644 --- a/trunk/arch/arm/mach-at91/at91sam9260_devices.c +++ b/trunk/arch/arm/mach-at91/at91sam9260_devices.c @@ -17,12 +17,15 @@ #include #include +#include + #include #include #include #include #include #include +#include #include "generic.h" @@ -1340,6 +1343,93 @@ void __init at91_add_device_cf(struct at91_cf_data *data) void __init at91_add_device_cf(struct at91_cf_data * data) {} #endif +/* -------------------------------------------------------------------- + * ADCs + * -------------------------------------------------------------------- */ + +#if IS_ENABLED(CONFIG_AT91_ADC) +static struct at91_adc_data adc_data; + +static struct resource adc_resources[] = { + [0] = { + .start = AT91SAM9260_BASE_ADC, + .end = AT91SAM9260_BASE_ADC + SZ_16K - 1, + .flags = IORESOURCE_MEM, + }, + [1] = { + .start = AT91SAM9260_ID_ADC, + .end = AT91SAM9260_ID_ADC, + .flags = IORESOURCE_IRQ, + }, +}; + +static struct platform_device at91_adc_device = { + .name = "at91_adc", + .id = -1, + .dev = { + .platform_data = &adc_data, + }, + .resource = adc_resources, + .num_resources = ARRAY_SIZE(adc_resources), +}; + +static struct at91_adc_trigger at91_adc_triggers[] = { + [0] = { + .name = "timer-counter-0", + .value = AT91_ADC_TRGSEL_TC0 | AT91_ADC_TRGEN, + }, + [1] = { + .name = "timer-counter-1", + .value = AT91_ADC_TRGSEL_TC1 | AT91_ADC_TRGEN, + }, + [2] = { + .name = "timer-counter-2", + .value = AT91_ADC_TRGSEL_TC2 | AT91_ADC_TRGEN, + }, + [3] = { + .name = "external", + .value = AT91_ADC_TRGSEL_EXTERNAL | AT91_ADC_TRGEN, + .is_external = true, + }, +}; + +static struct at91_adc_reg_desc at91_adc_register_g20 = { + .channel_base = AT91_ADC_CHR(0), + .drdy_mask = AT91_ADC_DRDY, + .status_register = AT91_ADC_SR, + .trigger_register = AT91_ADC_MR, +}; + +void __init at91_add_device_adc(struct at91_adc_data *data) +{ + if (!data) + return; + + if (test_bit(0, &data->channels_used)) + at91_set_A_periph(AT91_PIN_PC0, 0); + if (test_bit(1, &data->channels_used)) + at91_set_A_periph(AT91_PIN_PC1, 0); + if (test_bit(2, &data->channels_used)) + at91_set_A_periph(AT91_PIN_PC2, 0); + if (test_bit(3, &data->channels_used)) + at91_set_A_periph(AT91_PIN_PC3, 0); + + if (data->use_external_triggers) + at91_set_A_periph(AT91_PIN_PA22, 0); + + data->num_channels = 4; + data->startup_time = 10; + data->registers = &at91_adc_register_g20; + data->trigger_number = 4; + data->trigger_list = at91_adc_triggers; + + adc_data = *data; + platform_device_register(&at91_adc_device); +} +#else +void __init at91_add_device_adc(struct at91_adc_data *data) {} +#endif + /* -------------------------------------------------------------------- */ /* * These devices are always present and don't need any board-specific diff --git a/trunk/arch/arm/mach-at91/at91sam9g45.c b/trunk/arch/arm/mach-at91/at91sam9g45.c index f2054495a655..4792682d52b9 100644 --- a/trunk/arch/arm/mach-at91/at91sam9g45.c +++ b/trunk/arch/arm/mach-at91/at91sam9g45.c @@ -176,6 +176,12 @@ static struct clk vdec_clk = { .type = CLK_TYPE_PERIPHERAL, }; +static struct clk adc_op_clk = { + .name = "adc_op_clk", + .type = CLK_TYPE_PERIPHERAL, + .rate_hz = 13200000, +}; + static struct clk *periph_clocks[] __initdata = { &pioA_clk, &pioB_clk, @@ -204,6 +210,7 @@ static struct clk *periph_clocks[] __initdata = { &isi_clk, &udphs_clk, &mmc1_clk, + &adc_op_clk, // irq0 }; @@ -242,6 +249,8 @@ static struct clk_lookup periph_clocks_lookups[] = { CLKDEV_CON_ID("pioC", &pioC_clk), CLKDEV_CON_ID("pioD", &pioDE_clk), CLKDEV_CON_ID("pioE", &pioDE_clk), + /* Fake adc clock */ + CLKDEV_CON_ID("adc_clk", &tsc_clk), }; static struct clk_lookup usart_clocks_lookups[] = { diff --git a/trunk/arch/arm/mach-at91/at91sam9g45_devices.c b/trunk/arch/arm/mach-at91/at91sam9g45_devices.c index 35bd42d02195..f6747246d649 100644 --- a/trunk/arch/arm/mach-at91/at91sam9g45_devices.c +++ b/trunk/arch/arm/mach-at91/at91sam9g45_devices.c @@ -19,9 +19,12 @@ #include #include +#include + #include #include